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

Julien ÉLIE <julien@trigofacile.com> Fri, 18 September 2015 20:25 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 B1ECE1A037F for <tls@ietfa.amsl.com>; Fri, 18 Sep 2015 13:25:44 -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 AKeo7RXy_olh for <tls@ietfa.amsl.com>; Fri, 18 Sep 2015 13:25:42 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360C51A01FC for <tls@ietf.org>; Fri, 18 Sep 2015 13:25:42 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([83.200.77.196]) by mwinf5d57 with ME id JkRf1r00G4E7NBX03kRftY; Fri, 18 Sep 2015 22:25:40 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Fri, 18 Sep 2015 22:25:40 +0200
X-ME-IP: 83.200.77.196
To: "tls@ietf.org" <tls@ietf.org>
References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <55FC7343.3090301@trigofacile.com>
Date: Fri, 18 Sep 2015 22:25:39 +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: <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AoPLzTh6Ob_uNgQoPLFJ02EdV9A>
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: Fri, 18 Sep 2015 20:25:44 -0000

Hi Rich,

> Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression
> feature you need?  What TLS 1.3 feature is compelling here?

Reading latest draft-ietf-tls-rfc5246-bis, I think the relevant 
paragraph is:

    compression_methods
       Versions of TLS before 1.3 supported compression and the list of
       compression methods was supplied in this field.  For any TLS 1.3
       ClientHello, this field MUST contain only the "null" compression
       method with the code point of 0.  If a TLS 1.3 ClientHello is
       received with any other value in this field, the server MUST
       generate a fatal "illegal_parameter" alert.  Note that TLS 1.3
       servers may receive TLS 1.2 or prior ClientHellos which contain
       other compression methods and MUST follow the procedures for the
       appropriate prior version of TLS.


Well, it is true that NNTP can stay on TLS 1.2.  News clients and news 
servers can implement TLS 1.2 and use it.
The concern will be when TLS 1.2 is declared "flawed".  Maybe one day it 
will be considered insecure; and then, compliant TLS implementations 
won't be able to use compression.  That facility will then be lost.

I understand that a few protocols (like HTTPS) have vulnerabilities when 
compression is used.  Nonetheless, is it a sufficient reason to no 
longer support compression in TLS 1.3?
Wouldn't it be better to disable compression in implementation of 
vulnerable protocols?  (For instance Firefox, Apache...)

Do we know how many protocols currently suffer from CRIME?


Maybe a best practice could be suggested by UTA for the implementation 
of TLS in software, to disable compression if vulnerable.  And for the 
others, to implement a way to enable/disable compression in case one day 
a vulnerability is found.

-- 
Julien ÉLIE

« La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »