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

Daniel Kahn Gillmor <> Sat, 03 October 2015 16:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B119F1B3690 for <>; Sat, 3 Oct 2015 09:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iaZRanxdoYs1 for <>; Sat, 3 Oct 2015 09:34:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 134D51B368F for <>; Sat, 3 Oct 2015 09:34:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id F2352F98B; Sat, 3 Oct 2015 12:34:14 -0400 (EDT)
Received: by (Postfix, from userid 1000) id D0249209D8; Sat, 3 Oct 2015 12:02:38 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To:, Eric Rescorla <>
In-Reply-To: <>
References: <>
User-Agent: Notmuch/0.20.2 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Sat, 03 Oct 2015 12:02:38 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
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: Sat, 03 Oct 2015 16:34:18 -0000

On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote:
> The value of real padding is highly dependent of whether and how it
> will actually get used, and is far from automatic.

Sure, but we have no existing mechanism to do that in TLS 1.2 or
earlier.  We need the mechanism before anyone can establish sensible
policy.  Understanding what policy is sensible is likely to be
endpoint-specific, and is definitely something that needs research.  But
we can't implement any policy at all without having the mechanism in

> Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2
> would be trivial, and work fine with TLSv1.2 AEAD.

"would be trivial" is not "has been specified".  It also requires
negotiation, whereas hopefully in 1.3, we will not need to negotiate
padding.  Furthermore, If you treat padding as a "compression alg" in
1.2, then the folks who started this thread who want 1.2 because of its
support for compression would not be able to use padding in conjunction
with compression (if someone has a use case for such a combination,
which seems counterintuitive at first glance).  So this proposal doesn't
really address the original reason for the suggestion of "stay on 1.2".

> 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.

I beg to differ -- if there is any interleaving of application_data and
other content types, and if records can be arbitrarily-sized, it's not
clear to me how a DPI can distinguish one from the other.  Can you be
more specific?

> 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.

We need to be looking at things the other way around: if there's a
sensible way to leak less metadata, we should be leaking less metadata,
even if there are other ways that the same information can be recovered
by a similar adversary.  "don't fix X because Y has the same problem" is
a great symmetric recipe for not getting anything done.  We should be
saying "we need to fix both X and Y" instead.

> 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.

Can you enumerate the stuff you expect to break from encrypted content
type that will cause a decade-long delay in adoption?  It would be great
to have a list of those things so we can evaluate them.