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

Eric Rescorla <> Sun, 04 October 2015 20:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 81C3A1A1B34 for <>; Sun, 4 Oct 2015 13:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z8jnCQEFJ68m for <>; Sun, 4 Oct 2015 13:18:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A59901A00DB for <>; Sun, 4 Oct 2015 13:18:16 -0700 (PDT)
Received: by wicge5 with SMTP id ge5so94396545wic.0 for <>; Sun, 04 Oct 2015 13:18:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=y7znLVpNp8H4UNuW4mR4IvdgAJ1q1JUQa3Fnwx9U06E=; b=IJjemytlrYAro7cKnsn0Gvka1ZCiURmz4bzRMpHgHp69GwTwNYTqsBFJm6xW1JVAUT GcbVqeUatsXIIFUMSjnyzjxegOJ+lx8iO7jV22NlFjC9AzR1PDFzEjY31cWs5DaktNyd N5HkuATaAHv1aG620n4GyOM3+m+YGq/CSsLJgOYxVfZLgfF6tisxLmJMs52xK/Uqb99i bWB630+5z1ibmsRMzcTvcQt1lSzPVfjk2zWnrfzvWb/HdqkbOkxm/l6xuHd2NyRbBJKq BkhK3LoY7/MyyH0jgk1limG0JN11iCdwPULV/vo9SsLcEb2eyqp5Q9x+EQfWEPbu/kZJ 4Cng==
X-Gm-Message-State: ALoCoQlNOuViwwB+0lvfbg2IehXG9LVHDZjX1iTfyiKiWtr47NFQ13BPwBtMMZ0POaVA4VZScYM4
X-Received: by with SMTP id gt2mr8115220wib.31.1443989895207; Sun, 04 Oct 2015 13:18:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 4 Oct 2015 13:17:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Eric Rescorla <>
Date: Sun, 04 Oct 2015 13:17:35 -0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="f46d04428f1cc3794405214d18a3"
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: Sun, 04 Oct 2015 20:18:19 -0000

On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton <> wrote:

> >> Typically compression is used to lower the overall size of data,
> working on
> >> a wide class of inputs. In the perceptual coding case the class of
> inputs
> >> is constrained, and the goal is to keep the data rate constant, not
> >> optimally small.
> >
> > Yep. You could do this in bursts with different caps each time to get it
> to work with bursty things like HTTP & other general data transfer
> protocols. Without a really good modern compression algorithm, though, it
> isn't that appealing. Once these caveats and tweaks start getting added to
> the simple concept, it starts treading into the territory that is better
> handled by the application protocol that actually *knows what it's
> sending*. This seems to be the logical wall we keep hitting, which is why
> TLS doesn't seem like the place to do this.
> >
> I think two concepts are blending into one.... You appear to be
> arguing for efficiency, and I'm more concerned with safely/securely.
> I'm fairly certain the internet community at large would benefit from
> "compression done safely/securely", even if its not the most
> efficient. If the application layer wants to provide a more efficient
> implementations, then that's fine too.
> I think this I where things now stand (if I am surveying correctly):
> (1) TLS WG did not fix the problem (bad); (2) users don't have a
> choice (bad); (3) applications will have to provide their own
> compression when desired, which will likely increase overall risk for
> users (bad). For (3) keep in mind browsers are not the only user
> agents or consumers of web services.

The problem is that we don't know how to generically provide compression
safely. To take a concrete example: HTTP2's solution to header compression,
HPACK, is extremely limited compared to a generic compression system
like gzip, LZ77, etc., as well as being tightly-coupled to HTTP, and yet we
still know that there are potential security problems [0]. Doing something
generically secure is much harder.

If you have a solution to this problem, then great. But the mere fact that
desirable doesn't mean we have an answer.


[0] Specifically, that the attacker can confirm specific guesses about the
of a header field.

> All-in-all, I think its a win for NSA, GCHQ and other miscreants; and
> an overall loss for user.
> Jeff
> _______________________________________________
> TLS mailing list