On Tue, Sep 22, 2015 at 9:23 AM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote: > 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"?
Exactly. Upper-level layers can do the analysis to indicate when compression contexts can be shared. TLS cannot as it doesn't have access to the relevant information. > > 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 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
