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

[Peter Gutmann <[e-mail]>]

Bryan A Ford <[e-mail]> 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 encrypting headers in general,
not the specific case you'd given.  That is, I assumed you'd specifically 
chosen the one case where it's practical, an AEAD stream cipher, and used
that as a strawman.  Re-reading your post, it looks like "adding a stream
cipher to every TLS 1.3-compatible ciphersuite" should really be "require
that the only cipher type allowed for TLS be an AEAD stream cipher", 
because it's not going to work with anything else.

This breaks a fundamental principle of TLS, that you can drop in any 
algorithm or mechanism you like (well, within reason) and it'll still work.  
More importantly, if a flaw is found in one mechanism, you can switch to 
another.  In the past we've been able to switch between a KSG cipher (RC4), 
64-bit block ciphers, 128-bit block ciphers, and AEAD ciphers as required.
With this change, it looks like the only choice you have is an AEAD stream
cipher.

In addition, it doesn't actually achieve what you think it does, I'll 
expand on that in a separate message in reply to another post.

Peter.