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

Yoav Nir <> Sat, 03 October 2015 23:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A27F61A897B for <>; Sat, 3 Oct 2015 16:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cPTCY2yTGh3N for <>; Sat, 3 Oct 2015 16:54:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08F931A8974 for <>; Sat, 3 Oct 2015 16:54:31 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so75321280wic.1 for <>; Sat, 03 Oct 2015 16:54:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0ki9W8GU2CibD9Eho/OjVRUPk6F3Rd77n73wWY8182o=; b=FEUMLGm+8EOgWAIZLf8jSGmm06Yi01RuLVxVoGXyRJ7lpIRC8iHSMlhdVXU6gJpNyc LwcmKJGKR4AMYmBnj6ZExF+50wBBasjDUYHw3erFY1y79zNPxc4JatH2YgzZYDLZs49W cUC1j93nkCq6ghlSZ02oOZ13diT2hGXen/LbDgAi9yUmKZwEwdcX1oH4IBl3V07xX+01 3xCX2am0F2/AafRRvoi8Q9qHRbDOWIlYXB9mU8ofC4wot0TqXCKIoUsq2i1iTUANINJI W5tapIu7YSG/QSGNUM++si+lSzdTPJXwJLaoAJo58WFcwHA2yDXU7D98KVqdkWtyWKe/ m12g==
X-Received: by with SMTP id gb9mr3947657wic.44.1443916470436; Sat, 03 Oct 2015 16:54:30 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id mc20sm6442936wic.16.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Oct 2015 16:54:29 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Sun, 04 Oct 2015 02:54:26 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: takamichi saito <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Oct 2015 23:54:33 -0000

> On Oct 4, 2015, at 1:44 AM, takamichi saito <> 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.