Re: [TLS] TLS 1.3 - Support for compression to be removed (Martin Rex) Fri, 02 October 2015 16:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DBE671B2CB1 for <>; Fri, 2 Oct 2015 09:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n-sN-MKV3T5s for <>; Fri, 2 Oct 2015 09:24:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2DB21B2CB0 for <>; Fri, 2 Oct 2015 09:24:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C77D2A584; Fri, 2 Oct 2015 18:24:24 +0200 (CEST)
X-purgate-ID: 152705::1443803064-00005D2B-462C83B4/0/0
X-purgate-size: 1812
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ( []) by (Postfix) with ESMTP id 6D7844064E; Fri, 2 Oct 2015 18:24:24 +0200 (CEST)
Received: by (Postfix, from userid 10159) id 63B871A2BA; Fri, 2 Oct 2015 18:24:24 +0200 (CEST)
In-Reply-To: <>
To: Eric Rescorla <>
Date: Fri, 02 Oct 2015 18:24:24 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Archived-At: <>
Cc: "" <>
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: Fri, 02 Oct 2015 16:24:29 -0000

Eric Rescorla wrote:
> On Fri, Oct 2, 2015 at 8:24 AM, 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
>>> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?
>> They are equivalent.  If you use AES-GCM and ECDHE, and you don't need
>> 0RTT, then there is no compelling reason to use TLS 1.3.
> I don't want to take a position on what's compelling or not, but there are
> a number of other reasons to use TLS 1.3, including support for
>   real padding,
>   encrypted content types
>   privacy for client authentication, etc.

privacy for client authentication is the only real benefit on this list of 3.

The value of real padding is highly dependent of whether and how it
will actually get used, and is far from automatic.
Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2
would be trivial, and work fine with TLSv1.2 AEAD.

encrypted content types looks like lame duck with zero value to me.

"Is not readily distinguishable by existing deep packet inspection (DPI)
filter types" is pretty much the only thing--and adjusting DPI will be
far from rocket science.

Trying to make a single bit of information stick out less prominently
will only create a false sense of security whenever that bit of information
can be trivially detected from the traffic pattern.

But the collateral damage is that you break stuff that feeds on the
outer record layer structure and state, which can easily push adoption
of TLSv1.3 from the 5-years-spec-to-usage for TLSv1.2 to the
15-years-spec-to-marginal-use marginal use seen with IPv6.