----- Original Message ----- > 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 I'm not so sure. So I would like to request comment on > one approach that strikes me as a practical and requires only a rather > minor change to the current spec.
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? Here you imply that the revealing the length is somehow a weakness. However, TLS isn't supposed to hide lengths and never did [0]. So will hiding the length _field_ of such a protocol, will really protect against attacks taking advantage of packet lengths? If you see the previous work of analyzing TLS packet lengths they don't even need to read that length field, they just use the packet length on the wire. There is already a solution for protecting packet lengths, and that's called padding [1]. regards, Nikos [0]. the cbc ciphersuite approach was a half baked approach which never worked. [1]. http://alfredo.pironti.eu/research/publications/full/identifying-website-users-tls-traffic-analysis-new-attacks-and-effective-counterme _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls