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

Douglas Stebila <> Tue, 06 October 2015 05:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C66101B3785 for <>; Mon, 5 Oct 2015 22:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ynoTmlwgUXvG for <>; Mon, 5 Oct 2015 22:27:07 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E31B41B335D for <>; Mon, 5 Oct 2015 22:27:06 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 6 Oct 2015 05:26:49 +0000
Received: from ([]) by ([]) with mapi id 15.01.0280.017; Tue, 6 Oct 2015 05:26:49 +0000
From: Douglas Stebila <>
To: Eric Rescorla <>
Thread-Topic: [TLS] TLS 1.3 - Support for compression to be removed
Date: Tue, 06 Oct 2015 05:26:49 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.2104)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; CY1PR0101MB1147; 5:L1PwcuEATiTuKRi2kGO0BUwqdGSIQdYftjHnWDgMVuxyMnbJkRIsFiDi5zeAxH6qDxg7xalVWoH2F3t8sRLPuU6yNOoLm+0+EHlv1+Fy1fMzVpZxqUvCFIwReuY9i8CjEPMujat69XS3zlYSiS8RQg==; 24:1rxTKQWzGzW1QY2wTZq1QpCisppJKEiCw+Z0W9lHhR1JOFFEzrhXHXJ5W81mIBQA9kjtk4QQ/HKroi8yw4KihVqnYFSkqc3h7lyfM8mz1Nk=; 20:4oWAMAOGHPGC8++dnN41zZ+qxTTqZe3vS9+9zeFRRBqmkdNor3dITmzhkogAKs0FBJYU7HBd9AdrHQQ2ATnRDA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0101MB1147;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:CY1PR0101MB1147; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB1147;
x-forefront-prvs: 07215D0470
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(377454003)(24454002)(93886004)(87936001)(33656002)(82746002)(5004730100002)(40100003)(81156007)(74482002)(77096005)(19580405001)(88552001)(5002640100001)(5008740100001)(97736004)(110136002)(19580395003)(36756003)(5001960100002)(11100500001)(189998001)(106356001)(5007970100001)(101416001)(76176999)(105586002)(66066001)(64706001)(2900100001)(50226001)(102836002)(106116001)(46102003)(50986999)(86362001)(92566002)(57306001)(10400500002)(122556002)(2950100001)(74826001)(83716003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0101MB1147;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2015 05:26:49.8915 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dc0b52a3-68c5-44f7-881d-9383d8850b96
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1147
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: Tue, 06 Oct 2015 05:27:14 -0000

On Oct 5, 2015, at 5:17 AM, Eric Rescorla <> wrote:
> 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 it's
> desirable doesn't mean we have an answer.

A very very limited answer is that, if you use a compression method with a fixed, small dictionary and non-adaptive compression (i.e., the dictionary is not updated), then recovery of a high entropy secret from a compressed-then-encrypted value is hard, even with an adversary adaptively choosing the prefix/suffix of the plaintext.  This is a much weaker security property than the standard indistinguishability / semantic security of encryption, and would be unsuitable for general encryption purposes.  Being a non-adaptive technique, the compression rate is also quite poor, but can be better than nothing for a dictionary that's chosen well for the typical document.