Re: [secdir] secdir review of draft-elie-nntp-tls-recommendations-01

Julien ÉLIE <julien@trigofacile.com> Fri, 09 December 2016 22:27 UTC

Return-Path: <julien@trigofacile.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E15129570 for <secdir@ietfa.amsl.com>; Fri, 9 Dec 2016 14:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=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 iRpucnGrtpNx for <secdir@ietfa.amsl.com>; Fri, 9 Dec 2016 14:27:34 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by ietfa.amsl.com (Postfix) with ESMTP id AD42E12953C for <secdir@ietf.org>; Fri, 9 Dec 2016 14:27:33 -0800 (PST)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d83 with ME id HyL11u00117Lgi403yL1zh; Fri, 09 Dec 2016 23:20:02 +0100
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Fri, 09 Dec 2016 23:20:02 +0100
X-ME-IP: 92.170.5.52
To: David Mandelberg <david@mandelberg.org>
References: <022c6479-4bac-f18e-928a-796a0d7ebde3@mandelberg.org> <6eb3ef06-c3f0-462e-0cc1-573e585cc221@trigofacile.com> <6d25826996009a1792e721b6de78a1fd@mail.mandelberg.org>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <9cb07e03-fd9f-a9ee-2409-1cafe164007e@trigofacile.com>
Date: Fri, 09 Dec 2016 23:20:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <6d25826996009a1792e721b6de78a1fd@mail.mandelberg.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/OlXLlsx2NuspPAJ6kG8ljpxhI-o>
Cc: draft-elie-nntp-tls-recommendations.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-elie-nntp-tls-recommendations-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 22:27:35 -0000

Hi David,

> On 2016-12-08 16:47, Julien ÉLIE wrote:
>> I believe it is OK to take the following text into account for the
>> ports to use for NNTP over TLS, but I prefer to share with you the
>> wording in case you have any comments about it.  (Maybe it is not
>> clear enough!)
>> We would then have in Appendix A of the document:
>>
>>  The third and fourth paragraphs in Section 1 of [RFC4642] are
>>  replaced with the following text:
>>
>>   TCP port 563 is dedicated to NNTP over TLS, and registered in the
>>   IANA Service Name and Transport Protocol Port Number Registry for
>>   that usage.  NNTP implementations using TCP port 563 begin the TLS
>>   negotiation immediately upon connection and then continue with the
>>   initial steps of an NNTP session.  This use of strict TLS on a
>>   separate port is the preferred way of using TLS with NNTP.
>>
>>   If a host wishes to offer separate servers for transit and reading
>>   clients, TCP port 563 SHOULD be used for the reading server using
>>   strict TLS.  If a transit server offers strict TLS, it SHOULD use TCP
>>   port 433 if it does not accept unencrypted connections, but can
>>   alternatively use another unused port of its choice.  If it accepts
>>   dynamic upgrade from unencrypted to TLS-protected traffic, it SHOULD
>>   use TCP port 433 for that usage, and another unused port of its
>>   choice for strict TLS.  In either case, the port used for strict TLS
>>   should be clearly communicated to the client, and specifically that
>>   no plain-text communication occurs before the TLS session is
>>   negotiated.
>
> From a security point of view, I have no objection to this text.

... unless if it can lead to "protocol switching attack between TLS and 
NNTP" as you hint at below:


> I'm a bit surprised that you're using the same port (433) for both plain
> TLS and for STARTTLS, but as long as clients and servers are configured
> correctly, that should work. I assume there's no protocol switching
> attack between TLS and NNTP?

Well, you're right there's something weird here.
In fact, I was suggesting to use port 433 for strict TLS when the 
transit server only allows encrypted connections.  If some clients use 
unencrypted connections and some other clients use TLS-protected 
connections, then port 433 was to be used for unencrypted connections as 
well as connections using dynamic upgrade from unencrypted to 
TLS-protected traffic; and another port of its choice for strict TLS.
I agree it finally looks weird and inconsistent.

The rationale behind was:
- the common case is both reading&transit via port 119 (unencrypted, 
with possible use of STARTTLS), and strict TLS for reading via port 563;
- servers handling reading&transit on the same port can of course use 
strict TLS for transit via port 563;
- a few servers offer transit via port 433 (unencrypted, with possible 
use of STARTTLS), and keep ports 119/563 for reading.

Note that there is no IANA registered port for transit-only exchanges 
over TLS.  IANA registered ports are 119 (NNTP), 433 (NNSP) and 563 
(NNTP/TLS).


So I believe we have two alternatives right now:
a/ asking IANA to register a new port for NNSP/TLS and then explicitly 
say to use that port for transit with strict TLS;
b/ explicitly say to use another port than 433 for transit with strict TLS.

Alternative a/ is cleanest but maybe that new port will never be used in 
practice...
That's why I suggest b/ but of course I would be OK if a/ is chosen.
** Alexey, do you have any opinion about that?

Considering b/ (that I will adopt unless decided otherwise), the text 
becomes:

    TCP port 563 is dedicated to NNTP over TLS, and registered in the
    IANA Service Name and Transport Protocol Port Number Registry for
    that usage.  NNTP implementations using TCP port 563 begin the TLS
    negotiation immediately upon connection and then continue with the
    initial steps of an NNTP session.  This use of strict TLS on a
    separate port is the preferred way of using TLS with NNTP.

    If a host wishes to offer separate servers for transit and reading
    clients, TCP port 563 SHOULD be used for strict TLS with the reading
    server, and an unused port of its choice different than TCP port 433
    SHOULD be used for strict TLS with the transit server.  The ports
    used for strict TLS should be clearly communicated to the clients,
    and specifically that no plain-text communication occurs before the
    TLS session is negotiated.


I hope that's better in a security point of view (we do not rely on the 
quality of the configuration, and there cannot be any protocol switching 
attacks).

-- 
Julien ÉLIE

« – Poussez pas derrière !
   – Pas si vite devant ! » (Astérix)