Subject: Re: [NNTP] Last Call: <draft-elie-nntp-tls-recommendations-01.txt> (Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)) to Proposed Standard

From: Julien ÉLIE <[email-masked]>
Date: Fri, 2 Dec 2016 23:13:39 +0100

Hi Sabahattin,

>> As strict TLS over a dedicated port is the current TLS best
>> practice to use, what should we do for transit servers?  We
>> currently have no NNSP/TLS port.  Do you believe we should ask to
>> register a new port NNSP/TLS? Otherwise, what should we recommend?
>> (My fear is that adoption and use of that new port by news servers
>> will be slow, or even will never be happening...)
>
> Not for me to argue with the wisdom of the crowd, I'm sure, but I've
> never liked the idea of going back to TLS "wrapper" ports; it just
> wastes precious IANA resources for absolutely no reason whatsoever
> and, as you just highlighted, is in any event unlikely to make a
> meaningful impact in practice.
>
> Maybe you could compromise; describe the use of the secure port, give
> it a name, but then only register that port when implementers go
> looking for it.  Downside is that the RFC cannot specify a fixed port
> number.

Thanks for your valuable comment.

Would the following wording suit you?

   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.  Regarding the transit server, though TCP port 433 is
   registered for NNSP (Network News Streaming Protocol), no dedicated
   port is currently registered for NNSP over TLS.  If a transit server
   offers strict TLS, it SHOULD either use TCP port 433 if it does not
   accept connections without TLS, or another unused port of its choice
   communicated to all its clients using strict TLS.

Question to all:  is NNSP still a name to be used?  I do not see it in 
RFCs, but only in the IANA service name registry.
Maybe we should ask to rename that port to NNTP?

FYI, RFC 3977 uses the following wording:

    The official TCP port for the NNTP service is 119.  However, if a
    host wishes to offer separate servers for transit and reading
    clients, port 433 SHOULD be used for the transit server and 119 for
    the reading server.

-- 
Julien ÉLIE

« – Tu n'as rien remarqué d'étrange chez cet Arverne ?
   – Oui, son accent. » (Astérix)

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 03 Dec 2016 15:13:20 +0000

>  communicated to all its clients using strict TLS.

This is pretty neat, but I'd like to make the last point unambiguous, like this:

If a transit server offers strict TLS, it SHOULD use TCP port 433 if it does not accept connections without TLS, but can alternatively use another unused port of its choice.  In either case, the port used should be clearly communicated to the client as the port used for strict TLS, and specifically that no plain-text communication occurs before the TLS session is negotiated.

If you can make that clearer, be my guest. :)

Cheers,
Sabahattin

---

From: Julien ÉLIE <[email-masked]>
Date: Sat, 17 Dec 2016 15:16:28 +0100

Hi Sabahattin,

> This is pretty neat, but I'd like to make the last point
> unambiguous,like this:
>
> If a transit server offers strict TLS, it SHOULD use TCP port 433 if
> it does not accept connections without TLS, but can alternatively use
> another unused port of its choice. In either case, the port used should
> be clearly communicated to the client as the port used for strict TLS,
> and specifically that no plain-text communication occurs before the TLS
> session is negotiated.
>

Thanks for your proposal, that I suggested to the reviewer from the 
security directorate during Last Call.  It finally appeared 
over-complicated to use port 433 sometimes for strict TLS, and sometimes 
not, only depending on how the configuration of the server is done.

Here is the current text.  I hope you're fine with it.  Otherwise, 
please tell what you reckon is wrong.

    The third and fourth paragraphs in Section 1 of [RFC4642] are
    replaced with the following text:

       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.

       As some existing implementations negotiate TLS via a dynamic
       upgrade from unencrypted to TLS-protected traffic during an NNTP
       session on well-known TCP ports 119 or 433, this specification
       formalizes the STARTTLS command in use for that purpose.  However,
       as already mentioned above, implementations SHOULD use strict TLS
       on a separate port.

       Note: a common alternative to protect NNTP exchanges with transit
       servers that do not implement TLS is the use of IPsec with
       encryption [RFC4301].

I've also added your name in the Acknowledgments Section.

-- 
Julien ÉLIE

« Ma parole… Vous êtes soûls ! Heu ! Sourds… » (Astérix)

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 17 Dec 2016 18:18:36 +0000

Hi,

On 17 Dec 2016, at 14:16, Julien ÉLIE <[email-masked]> wrote:
> Thanks for your proposal, that I suggested to the reviewer from the security directorate during Last Call.  It finally appeared over-complicated to use port 433 sometimes for strict TLS, and sometimes not, only depending on how the configuration of the server is done.

This is completely understandable. :)  It would have been a matter of mutual agreement only, which is always going to risk confusion.

> Here is the current text.  I hope you're fine with it.  Otherwise, please tell what you reckon is wrong.
> 
> 

This is very reasonable.  No confusion about existing ports and clear that arranged strict TLS is preferable.  I don't have any objection at all.  Peering arrangements always make it possible to arrange the ports in use.

> I've also added your name in the Acknowledgments Section.

Thanks.

Cheers,
Sabahattin

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 20 Dec 2016 23:08:13 +0100

Hi Sabahattin,

> This is very reasonable.  No confusion about existing ports and clear
> that arranged strict TLS is preferable.  I don't have any objection
> at all.  Peering arrangements always make it possible to arrange the
> ports in use.

Thanks for the confirmation that the text is fine, and also clear enough 
about the two main points you noted.
Have a nice day,

-- 
Julien ÉLIE

« Chaque fois que je vois le nombre 1, j'ai envie de l'aider à
   s'échapper… Il a constamment à ses trousses, derrière, le zéro
   qui veut le rattraper et devant, toute la mafia des grands nombres qui
   le guettent. » (Romain Gary)