Re: [TLS] Headerless records (was: padding)
On 24 August 2015 at 21:04, Dave Garrett wrote: > uint16 length = TLSPlaintext.length; You can't recover the plaintext without knowing how long it is. This part at a minimum needs to be in the clear. At which point you need it to be based on TLSCiphertext.length ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
Hi a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt the client certificat with an extra key computed from the master secret see https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01 Rgs Pascal 2015-08-24 22:56 UTC+02:00, Viktor S. Wold Eide : > Hi, > > I am looking for a way to achieve identity hiding for DTLS 1.2, which also > hopefully can be used in (D)TLS 1.3, when available. > > >From what I understand, for (D)TLS 1.2 it would be possible to perform an > anonymous unencrypted handshake and then to renegotiate the connection with > authentication within the encrypted channel, e.g., according to the expired > draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation > will be removed in the upcoming 1.3 version. > > What is likely to be the recommended way to achieve identity hiding for > (D)TLS 1.3, if any? > > [1] Transport Layer Security (TLS) Encrypted Handshake Extension, > draft-ray-tls-encrypted-handshake-00, expired in 2012 > [2] The Transport Layer Security (TLS) Protocol Version 1.3, > draft-ietf-tls-tls13-07 > > > Best regards > Viktor S. Wold Eide > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] padding
> On Aug 25, 2015, at 2:22 AM, Tom Ritter wrote: > > On 22 August 2015 at 19:28, Dave Garrett wrote: >> Toggling solves the undesired bandwidth use concern stated by Tom by making >> it fully optional on both sides. The even simpler route of just having to >> check if there's bytes in the encrypted fragment other than the payload >> would avoid a little bit of complexity, but with no way for an endpoint to >> say no to increased bandwidth usage that it doesn't want to or can't handle. >> Given this constraint, I'd favor either easily toggleable or always-on, >> rather than a middle-ground where implementations won't know what they're >> going to get and can't do anything about it. >> >> A footnote: Negotiating via an extension is probably not a good idea because >> client extensions will generally be in the clear. That's why I suggest a >> simple message instead. (there's no need to pad the cleartext hello, so it's >> fine to wait until record protection is available) Note that I don't think >> allowing this to be decided after the handshake is a good idea. >> >> A more generalized way to handle throttling padding would be to set a low >> default and require each endpoint to send a message with a different value, >> in max bytes per record (or second, or both) of padding permitted, in order >> to use a different amount. Each endpoint could easily arbitrarily throttle >> its downstream padding bandwidth independently, if need be. > > > I have a not-very-hidden motive in not having it be negotiable: I want > to enable clients to want to send padding be able to do so to any > server, even if that server does not want to pad. (They can just > discard.) If it's negotiated, the server may say "I don't support > padding" and clients who want to use it out out of luck. I’m not sure having one side send a continuous stream of large record buys you much if the other side doesn’t. Suppose an HTTPS server has 100 resources, each with a different size, it won’t help if the client obscures the identity of the resource it’s asking for if the resource can be identified by its size. Same goes for the existence of traffic. If the server stays quiet until there’s an actual request, the client’s continuous stream of padding-only records is just wasted effort. IMO this is an argument for negotiation, although even with negotiation we can never be assured that the other side is doing TFC well. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Headerless records (was: padding)
>> uint16 length = TLSPlaintext.length; > > You can't recover the plaintext without knowing how long it is. This > part at a minimum needs to be in the clear. At which point you need > it to be based on TLSCiphertext.length Is that really true? You could decrypt the first block/few bytes to get the length (without authentication, of course) and then decrypt the remainder according to this candidate length. Then authenticate the entire record to make sure the candidate length was correct. (I am not claiming anything about the purity of this approach, only that it is technically feasible.) Kyle ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Headerless records (was: padding)
On Tue, Aug 25, 2015 at 10:26:24AM -0400, Kyle Rose wrote: > (I am not claiming anything about the purity of this approach, only > that it is technically feasible.) SSH now has ciphersuites where the payload length is encrypted, IIRC via a key that is different from the payload key. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Headerless records (was: padding)
On Aug 25, 2015 7:26 AM, "Kyle Rose" wrote: > > >> uint16 length = TLSPlaintext.length; > > > > You can't recover the plaintext without knowing how long it is. This > > part at a minimum needs to be in the clear. At which point you need > > it to be based on TLSCiphertext.length > > Is that really true? You could decrypt the first block/few bytes to > get the length (without authentication, of course) and then decrypt > the remainder according to this candidate length. Then authenticate > the entire record to make sure the candidate length was correct. That depends on the aead - and the implementation. GCM can - maybe - be broken apart that way*, but I can't think that going to all the trouble of formulating an aead just to break it open at the first point that it becomes inconvenient. You could imagine an aead that made that difficult or impossible (just reverse the order of the bytes...). Or, without imagining at all, you can have hardware module that enforce authentication before releasing plaintext. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Headerless records (was: padding)
On Aug 25, 2015 7:42 AM, "Viktor Dukhovni" wrote: > SSH now has ciphersuites where the payload length is encrypted, > IIRC via a key that is different from the payload key. Yeah, I'm not that enthusiastic about that feature, but if you want more complexity, it is possible. The authentication properties are interesting there, of course. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
