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

Julien ÉLIE <> Sun, 20 September 2015 18:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37B581A0149 for <>; Sun, 20 Sep 2015 11:10:48 -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 vcoV-WUm9ImC for <>; Sun, 20 Sep 2015 11:10:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77A921A0117 for <>; Sun, 20 Sep 2015 11:10:45 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([]) 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
References: <> <> <> <> <m2pp1e8a8m.fsf@localhost.localdomain>
From: Julien ÉLIE <>
Organization: TrigoFACILE --
Message-ID: <>
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: <>
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: 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)