----- 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

Reply via email to