Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Hi Mike, On 12/2/15 4:14 PM, Mike Copley wrote: > [...] Not sure if this is the right place to consider, but would DTLS 1.3(?) > be able to encrypt headers and still handle packet loss and re-ordering? If > DTLS needs cleartext headers, would it be better to advise one approach for > both

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

On 12/2/15 4:45 PM, Watson Ladd wrote: > On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum wrote: >> On 12/2/15, Eric Rescorla wrote: >>> It's not really clear to me what the anti-traffic-analysis benefit of your >>> proposal >>> is over and above just padding

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/2/15 9:13 PM, Dave Garrett wrote: > On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: >> Encrypted SNI doesn't give you the kind of protection you think that it >> does. We (me and a colleague) did a pretty thorough analysis that showed >> this. It was not a conclusion we

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Hi Jens, On 12/2/15 11:47 AM, GUBALLA, JENS (JENS) wrote: >> Fortunately the solution is fairly simple: the receiver simply pre- >> computes and keeps in a small hash table the encrypted sequence numbers >> of all packets with sequence numbers between H-W and H+W, where H is >> the highest

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

Hi Dmitry, On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > Dear Bryan, > > On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford <brynosau...@gmail.com > <mailto:brynosau...@gmail.com>> wrote: > > DTLS: > > Now there's still the important question of whe

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/1/15 4:02 AM, Fabrice Gautier wrote: > 1) What would be the implications of this for DTLS? (Knowing that one > difference between TLS and DTLS is the record header) Good question. Fortunately my proposal should be fairly easy to adapt to DTLS, with one small trick. The main issue is that

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/1/15 10:12 AM, Yoav Nir wrote: >> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote: >> On 12/1/15, Viktor Dukhovni wrote: >>>* Interoperable in the field with various capital-intensive >>> middle boxen. >> >> Which would those be? And

[TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

Some of the parallel discussion on the SSH list - especially comments by Simon Tatham and Niels Möller - made me think of an alternative design that would not only hide TLS headers but also ensure that they are integrity-checked by the receiver *before* the receiver attempts to interpret the

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 11/30/15 2:40 AM, Peter Gutmann wrote: > Nikos Mavrogiannopoulos writes: > >> I believe your proposal is a nice example of putting the cart before the >> horse. Before proposing something it should be clear what do you want to >> protect from, what is the threat? > >

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Thanks Bill for the feedback. On 11/29/15 6:11 PM, Bill Cox wrote: > Thanks for the detailed description of why we might want to obfuscate > TLS record lengths. From a security point of view, the only potential > attack vector this might create is that the attacker will know in many > cases the

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 11/30/15 2:54 AM, Short, Todd wrote: > This brings up an interesting point; having a record length that corresponds > to the TCP segment size can help hardware implementations such that they > don't need to deal with scatter/gather; i.e. one TCP segment corresponds to a > single TLS

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 11/30/15 2:26 AM, Peter Gutmann wrote: > Bryan A Ford <brynosau...@gmail.com> writes: > >> Feel free to attack my proposal but then please attack *my* proposal, not >> the old broken SSH approach. > > I was actually commenting on the concept of

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Hi Peter, On 11/28/15 12:15 PM, Peter Gutmann wrote: > Bryan A Ford <brynosau...@gmail.com> writes: > SSL/TLS have used unencrypted lengths for twenty years without there being any > (known) attack or weakness based on this. Leaving all headers in the clear (and in particular

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 11/27/15 5:21 PM, Henrick Hellström wrote: > On 2015-11-27 15:35, Bryan A Ford wrote: >> The idea of encrypting TLS record headers has come up before, the most >> important purpose being to hide record lengths and boundaries and make >> fingerprinting and traffic anal

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 11/29/15 12:29 PM, Henrick Hellström wrote: > On 2015-11-29 10:48, Bryan A Ford wrote: >> In short, leaving TLS headers in cleartext basically hands any >> eavesdropper a huge information side-channel unnecessarily and precludes >> anyone*but* the TLS implementation i

[TLS] Encrypting record headers: practical for TLS 1.3 after all?

The idea of encrypting TLS record headers has come up before, the most important purpose being to hide record lengths and boundaries and make fingerprinting and traffic analysis harder. I had convinced myself that goal this would be "too hard" to accomplish in TLS 1.3, but after further thought