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

Yoav Nir <> Tue, 22 September 2015 18:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BCD8C1A92F5 for <>; Tue, 22 Sep 2015 11:32:52 -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 qIMGHqVtkvIz for <>; Tue, 22 Sep 2015 11:32:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2BF41A92E3 for <>; Tue, 22 Sep 2015 11:32:50 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so37166341wic.0 for <>; Tue, 22 Sep 2015 11:32:49 -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=0EYod1O2ij4Z4DZzoPxYQqqKgBBgTErm610tKgcx1rc=; b=gkHUzkc7ONtmUSRr6YPNg7Vv0rDKesHE8Q69n55WmqdIL/X765fGTKZFyo7BHm6mL9 3vxPmFzXbkfQq3FmTC4h01/PzfsV5sDNWZvT+zG0IgypQXurDNsijM1a8AxlgOM1/xvg 5NK6yCLKdE05+kC3wKEi+Nz4L0xENWIVsYfwytAk5ZYtftqS5yLd20JtEZGXvxcatqG9 2GmxfsKBkgchlK+Hl+v8upw9TEWGeu9iLW57OFI/7cGWGpukfY2RXAaFR9Nm6xHzWSBg vkcH0K0L9MkL00aMdssWM+eI3dzOFNDR6yR5uerc0QDii95wsnYva3kdnUywp70TV8hr rR4Q==
X-Received: by with SMTP id q13mr27467540wjw.79.1442946769420; Tue, 22 Sep 2015 11:32:49 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id fz1sm4469475wic.8.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Sep 2015 11:32:48 -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: Tue, 22 Sep 2015 21:32:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "" <>, Simon Josefsson <>
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: Tue, 22 Sep 2015 18:32:52 -0000

> On Sep 22, 2015, at 8:35 PM, Stephen Farrell <> wrote:
> On 22/09/15 17:23, Tony Arcieri wrote:
>> But an unsafe feature shouldn't be kept in
>> TLS just because some protocols want to do unsafe things and are too lazy
>> to implement their own compression.
> Compression does have issues clearly, but it's not correct to describe
> people wanting TLS to compress as lazy. They're rather looking for the
> same features that TLS has offered for a couple of decades. So if there
> were a way to help them, that'd be good. And if not, the onus I think
> is on us in this WG to clearly explain why we're removing that feature
> in TLS1.3.
> That doesn't have to be text in the TLS1.3 specification but I would
> guess the question may keep coming up, so documenting the answer in
> some archival form (such as an RFC:-) might be a good plan.

Doesn’t this count?

3.3.  Compression

   In order to help prevent compression-related attacks (summarized in
   Section 2.6 of [RFC7457]), implementations and deployments SHOULD
   disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless
   the application protocol in question has been shown not to be open to
   such attacks.

   Rationale: TLS compression has been subject to security attacks, such
   as the CRIME attack.

(From RFC 7525)

Sure, we could leave compression in the spec, and recommend that HTTP MUST NOT use it while NNTP MAY. 

A protocol for multiple use-cases can be either one size fits all, or else have a bunch of knobs for the different uses. I prefer the one size fits all approach.

More specific to compression: people had been using TLS (and SSL) to encrypt HTTP for over two decades before the CRIME attack. That’s how long it took to realize that it is dangerous for HTTP. Are people that sure that a similar issue doesn’t exist for the much less analyzed NNTP?