On Saturday, September 19, 2015 04:06:37 pm Salz, Rich wrote: > On Friday, September 18, 2015 04:25:39 pm Julien ÉLIE wrote: > > The concern will be when TLS 1.2 is declared "flawed". Maybe one day it > > will > > be considered insecure; and then, compliant TLS implementations won't be > > able to use compression. That facility will then be lost. > > Yes. > > It is widely recognized that in many cases, TLS-level compression is flawed > (for example NNTP authinfo?). TLS 1.3 does not have it. So NNTP that needs > compression can continue to use TLS 1.2, and if TLS 1.2 is "flawed" things > can change.
Contrary to its name, TLS is not a transport protocol. It's a security protocol, and compression is not a security feature. (though, when combined with padding, I could see how it could be useful) It didn't belong in the spec like it was, even if it worked safely. It might be doable in a TLS extension, but I don't think this is a great idea. Application protocols can handle compression better and more safely, as they can actually know what they're doing and how to properly compress it. Even if TLS compression could be fixed, the old insecure junk doesn't magically go away. It needs to be treated as ruined forever, just to be safe, as far as I'm concerned. If you need compression, I wouldn't recommend relying on it here. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
