Bryan A Ford <[email protected]> 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. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
