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

Julien ÉLIE <> Tue, 22 September 2015 18:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 824F31A906F for <>; Tue, 22 Sep 2015 11:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.649
X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AV_HOBljoB-7 for <>; Tue, 22 Sep 2015 11:16:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BC1B1A9069 for <>; Tue, 22 Sep 2015 11:16:50 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([]) by mwinf5d06 with ME id LJGn1r0044E7NBX03JGnDt; Tue, 22 Sep 2015 20:16:48 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Tue, 22 Sep 2015 20:16:48 +0200
References: <> <>
To: "" <>
From: Julien ÉLIE <>
Organization: TrigoFACILE --
Message-ID: <>
Date: Tue, 22 Sep 2015 20:16:47 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Tue, 22 Sep 2015 18:16:52 -0000

Hi Tony,

> Keeping compression in TLS endorses unsafe usage of a feature known
> to introduce compression sidechannels.
> Whether other protocols decide to introduce their own secondary
> compression layer is their own prerogative. But an unsafe feature
> shouldn't be kept in TLS just because some protocols want to do unsafe
> things and are too lazy to implement their own compression.

What for protocols that aren't subject to unsafe usage and that were 
relying on the compression facility provided by TLS?
Unconditionally removing TLS compression leads to a regression for them.

As others already mentioned in this list, even with NNTP we can use a 
safe SASL mechanism to authenticate.  No password sent in plain-text.

Regarding vulnerable protocols, clients (and/or servers) could very well 
disable compression in TLS.  And either never use compression or 
implement their own compression, according to their needs.
It is what happened with BEAST:  Firefox and Chrome disabled TLS 

Julien ÉLIE

« Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix)