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

Julien ÉLIE <> Sat, 19 September 2015 13:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 230DA1B5CDE for <>; Sat, 19 Sep 2015 06:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.45
X-Spam-Level: *
X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RWEAoaEzrAz3 for <>; Sat, 19 Sep 2015 06:09:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 083431B5CDB for <>; Sat, 19 Sep 2015 06:09:36 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([]) by mwinf5d22 with ME id K19Z1r00R4E7NBX0319aQj; Sat, 19 Sep 2015 15:09:35 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Sat, 19 Sep 2015 15:09:35 +0200
References: <> <> <>
From: Julien ÉLIE <>
Organization: TrigoFACILE --
Message-ID: <>
Date: Sat, 19 Sep 2015 15:09:33 +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="windows-1252"; 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: Sat, 19 Sep 2015 13:09:39 -0000

Hi Loganaden,

>     If compression is dropped at the TLS layer, you can still do it at
>     the layer above it.
> Indeed. And, it's probably a better idea to do it in the layer above.

Then how will the news server know that the client is compressing data 
after the use of STARTTLS where a security layer without compression has 
been negotiated?
It cannot guess it; and it won't try all uncompression methods to see 
which one has been used.

Unless you are speaking of an update of the NNTP protocol to add a new 
compression capability (for instance with the use of a new COMPRESS 
command with possible arguments), that could be used by clients?
Well, it will require some work to specify it.  Not to speak of its 
implementation afterwards.

I bet other protocols would also need similar new specifications to 
explain how compression can be enabled.

Julien ÉLIE

« Etna : lave dévalante. »