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

Daniel Kahn Gillmor <> Sun, 20 September 2015 21:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC19C1A8829 for <>; Sun, 20 Sep 2015 14:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.26
X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wk3VldZYFuLm for <>; Sun, 20 Sep 2015 14:02:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 00A361A87DF for <>; Sun, 20 Sep 2015 14:02:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id B5BCAF984; Sun, 20 Sep 2015 17:01:54 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 5663A2087C; Sat, 19 Sep 2015 15:04:05 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: "Salz, Rich" <>, Julien ÉLIE <>, "" <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Notmuch/0.20.2 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Sat, 19 Sep 2015 15:04:05 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
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: Sun, 20 Sep 2015 21:02:25 -0000

On Fri 2015-09-18 15:47:27 -0400, "Salz, Rich" <> wrote:
> Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression
> feature you need?  What TLS 1.3 feature is compelling here?

I think this line of argument is worrisome -- we should try to avoid
leaving behind protocols that need TLS, if we ever want to be able to
deprecate TLS 1.2 the way we've (finally) deprecated SSLv3.

That said, i think there are multiple approaches for NNTP and HOB/VPN
that don't involve using compression at the TLS layer.

For instance, with NNTP, if they're certain that CRIME isn't a risk for
their use case, they could introduce a STARTCOMPRESSION verb by analogy
to STARTTLS.  If the only reason they're using TLS in the first place is
for compression, this would be a simpler and less-risky approach in
terms of software dependencies as well.  I don't know enough about HOB's
use of TLS to know whether they could shim their own compression layer
in between the VPN traffic or not.

The TLS WG knows that compression represents a serious risk to encrypted
traffic, especially in situations like browsers where an adversary can
direct a peer to initiate protocol action.  Compression itself also
represents added complexity for protocol analysis.

I think we should remove compression and we should also explicitly warn
users of the protocol about the risks of combining compression with TLS.