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

[Yoav Nir <[e-mail]>]

> On Oct 4, 2015, at 1:44 AM, takamichi saito <[e-mail]> wrote:
> 
> 
> On 2015/10/03, at 0:24, Salz, Rich wrote:
> 
>> 
>>> 1) We know CRIME threat, but it can not be risk for everyone.
>>> e.g., CVSS v2 Base Score: 2.6 (LOW)
>> 
>> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called it 7.5
>> 
> 
> We know it, but one of indicators.
> How can you say the dangerous or risk instead of it? 
> My point is, CRIME is risk for every case?  

I don’t know. Probably not. 

But consider that we had been using HTTP with TLS for over 15 years before we found out about CRIME. It’s a subtle attack that relies on specific structures in HTTP and the peculiar way that browsers allow a script from one site to issue requests on behalf of another site. But still, it took researches all these years to find it. 

There are many lessons to be learned from this: that a bearer token that is repeated many times is not a good idea; that the trust model in the web is not great; but also that blindly compressing content with no regard to its structure and sources is dangerous and reveals information about the cleartext.  A security protocol should not do that. 

An even more executive-level lesson might be that security layers should not provide non-security services, but that is not really convincing because if there was a separate compression layer that you could compose with the security layer in TLS, CRIME would still be possible. To compress HTTP without the danger of CRIME you need to either not compress header fields with sensitive information, not compress header fields that might be controlled by an attacker, or at least delegate those to a separate compression state. That is not something that any transport layer shim can provide.

Yoav