Also, if compression is moved from TLS to upper layer(s) - how would it mitigate compression-related attacks? Besides "now it's somebody else's problem"?
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Simon Josefsson Sent: Tuesday, September 22, 2015 04:07 To: Julien ÉLIE Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed Julien ÉLIE <jul...@trigofacile.com> writes: > Hi Karthik, > >> It may well be true that some (typically unauthenticated) application >> protocols on top of TLS can survive TLS compression, but it is >> unlikely. > [...] >> HTTP is a particularly bad case because the attacker can potentially >> inject arbitrary data before (and after) the secret. With NNTP you >> may escape the worst of this adversary, but you probably won’t find >> any TLS expert willing to say that compressing the password is ok. > > OK, many thanks for the illustration! > > So in fact, to be safer, authentication commands should either be sent > uncompressed or be more complex than they currently are (for instance > with the insertion of random data with random length along with the > authentication command). I believe the general recommendation is to not send passwords in cleartext at all, even in encrypted tunnels. I'm sure you are aware of it, but you may SASL in NNTP as described in RFC 4643. /Simon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
