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

Julien ÉLIE <julien@trigofacile.com> Sun, 20 September 2015 18:10 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 37B581A0149 for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 11:10:48 -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 vcoV-WUm9ImC for <tls@ietfa.amsl.com>; Sun, 20 Sep 2015 11:10:46 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A921A0117 for <tls@ietf.org>; Sun, 20 Sep 2015 11:10:45 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([83.200.77.196]) by mwinf5d37 with ME id KWAi1r00N4E7NBX03WAjJs; Sun, 20 Sep 2015 20:10:43 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Sun, 20 Sep 2015 20:10:43 +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> <55FD5E8D.7020000@trigofacile.com> <m2pp1e8a8m.fsf@localhost.localdomain>
From: =?UTF-8?Q?Julien_=c3=89LIE?= <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <55FEF6A2.5060305@trigofacile.com>
Date: Sun, 20 Sep 2015 20:10:42 +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: <m2pp1e8a8m.fsf@localhost.localdomain>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sRbCh-O-clEVgvust-xvSA0eBX8>
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: Sun, 20 Sep 2015 18:10:48 -0000

Hi Geoffrey,

>> I bet other protocols would also need similar new specifications to
>> explain how compression can be enabled.
>
> I think that's the idea.  TLS compression only works for NNTP because no
> confidentiality is required.  In other protocols, there's at least
> something (if not everything) where confidentality is desirable and so
> compression needs to be specified very carefully if at all.

OK, understood.


> Even in NNTP, you don't want compression if you're using
> AUTHINFO---and how do you know AUTHINFO will or won't be used at the
> time of STARTTLS?

Note that AUTHINFO can also use any available SASL mechanisms instead of 
sending plain user/pass.  (Depending on the SASL mechanism, a security 
layer can be negotiated during the SASL exchange.)  Unfortunately, that 
facility is not wide-spread in news clients and servers.

To respond to your question, STARTTLS is not available after a 
successful authentication.  Therefore, it cannot be used after STARTTLS. 
  RFC 4642 states:

    A server supporting the STARTTLS command as defined in this document
    will advertise the "STARTTLS" capability label in response to the
    CAPABILITIES command ([NNTP] Section 5.2).  However, this capability
    MUST NOT be advertised once a TLS layer is active (see Section 2.2.2)
    or after successful authentication [NNTP-AUTH].

However, though that practice is discouraged, most of news clients still 
connect to port 563 (dedicated to NNTPS) and negotiate a TLS security 
layer upon connection.  They do not use STARTTLS in that case; and 
clients can authenticate with AUTHINFO, with an active TLS layer.

-- 
Julien ÉLIE

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