Re: [TLS] TLS 1.3 - Support for compression to be removed

[Watson Ladd <[e-mail]>]

On Tue, Sep 22, 2015 at 9:23 AM, Blumenthal, Uri - 0553 - MITLL
<[e-mail]> 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: [e-mail]
> Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed
>
> Julien ÉLIE <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.