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

Dave Garrett <> Sun, 04 October 2015 19:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E06CA1A6FB6 for <>; Sun, 4 Oct 2015 12:27:09 -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 rlGsUVgoUL33 for <>; Sun, 4 Oct 2015 12:27:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 712D21A21C0 for <>; Sun, 4 Oct 2015 12:27:08 -0700 (PDT)
Received: by qgt47 with SMTP id 47so133565500qgt.2 for <>; Sun, 04 Oct 2015 12:27:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=swUu1P98lhUY9Ex2eggxuEhiPIwXSfKodRVpQbEL2g4=; b=M65eWaG8pSkMIJxRc4ccXjkTwGbzUfVTVpXA/MEfcN1c9ZrG55enNERRUit4ggHekY /rg7zjzs/sPImxAVmLGZWCLuv8xCG2bhiWAypZeS7Tr1AjGsK+b0GepOxHL0aBkHhm5B ayv2TWw+x71t322Uko6483mu7RQxdoseYMUdXXFsII796zUwaqsQfTIMOfI7yCc1HSBU L67YyrL8sNmEjqPID0Ij+zohPkYwwE3uGg9ljIsJWAaslYsvydqYr0Kt+5QtWD6RZ6tf oVAMyv4cPABSP5OQMqIE+5Y+SFgWbc8U6/EMy1kgh+H3Qa0714bRcNU/e22FmoxIXr2c 4H/g==
X-Received: by with SMTP id 2mr34973774qgx.72.1443986827296; Sun, 04 Oct 2015 12:27:07 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id w78sm9574849qge.42.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 04 Oct 2015 12:27:06 -0700 (PDT)
From: Dave Garrett <>
To: Tony Arcieri <>
Date: Sun, 04 Oct 2015 15:27:04 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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: Sun, 04 Oct 2015 19:27:10 -0000

On Sunday, October 04, 2015 03:00:33 pm Tony Arcieri wrote:
> On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett <>
> wrote:
> > I can think of a way to do this, but the people who want compression badly
> > probably won't like it due to the need to pad heavily.
> >
> > 1) Pick a fixed bandwidth
> > 2) Compress & encrypt the stream
> > 3) Send the compressed stream at a rate blocked to the cap
> > 4) Whenever below the cap, pad the stream to the cap
> >
> > Maintain a fixed transmission of data per unit time and there's no way to
> > tell the size of anything (even if delivery doesn't match the rate).
> This sounds like Constant Bitrate (CBR) compression, which works for
> encrypted media (e.g. encrypted voice and video), but probably isn't
> particularly useful outside the realm of realtime media. It was a solution
> that seems to work for attacks that could e.g. transcribe encrypted phone
> calls by studying patterns in Variable Bitrate (VBR) compression on speech.
> 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.

Maybe some new transport protocol could be fed information to tell it how to handle compression safely, but TLS is not a transport protocol nor a young one that can be fundamentally changed to accommodate everything.