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

Julien ÉLIE <julien@trigofacile.com> Sat, 19 September 2015 13:09 UTC

Return-Path: <julien@trigofacile.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230DA1B5CDE for <tls@ietfa.amsl.com>; Sat, 19 Sep 2015 06:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWEAoaEzrAz3 for <tls@ietfa.amsl.com>; Sat, 19 Sep 2015 06:09:37 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083431B5CDB for <tls@ietf.org>; Sat, 19 Sep 2015 06:09:36 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([83.200.77.196]) 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
X-ME-IP: 83.200.77.196
To: tls@ietf.org
References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <20150919114649.GB4676@roeckx.be> <CAOp4FwSMqHBM1wzq3AcEK9ng305P5Ufn+0hwpHdzugcGMwiAoA@mail.gmail.com>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <55FD5E8D.7020000@trigofacile.com>
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: <CAOp4FwSMqHBM1wzq3AcEK9ng305P5Ufn+0hwpHdzugcGMwiAoA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PcS-kN1LvVP2vy4eOuZds09iK40>
Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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. »