Subject: [NNTP] Fwd: 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: Mon, 28 Nov 2016 22:28:01 +0100

Hi all,

An update to RFC 4642 (use of TLS with NNTP) is currently in IETF Last Call.
You can see the current document here:
     https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-01

In case you have any comments, please tell me.

Thanks beforehand for your review.

-- 
Julien ÉLIE

« Ça n'a été qu'un coup de glaive dans l'eau. » (Astérix)

-------- Message transféré --------
Sujet : 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
Date : Mon, 28 Nov 2016 08:45:30 -0800
De : The IESG
Pour : IETF-Announce

The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of Transport Layer Security (TLS) in the Network News Transfer
    Protocol (NNTP)'
   <draft-elie-nntp-tls-recommendations-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-12-26. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

    This document provides recommendations for improving the security of
    the Network News Transfer Protocol (NNTP) when using Transport Layer
    Security (TLS).  It modernizes the NNTP usage of TLS to be consistent
    with TLS best current practices.  If approved, this document updates
    RFC 4642.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-elie-nntp-tls-recommendations/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-elie-nntp-tls-recommendations/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 28 Nov 2016 22:44:01 +0100

Hi all,

>     https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-01

Does anyone have an opinion about the third issue in Appendix E?

Basically, news servers use either port 119 (NNTP) or port 433 (NNSP); 
news clients use either port 119 (NNTP) or 563 (NNTP/TLS).  The use of 
119/433 ports is described in Sections 3.4.1 and 3.4.2 of RFC 3977:

    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.

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...)

-- 
Julien ÉLIE

« Love is blind but marriage is an eye-opener. »

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 29 Nov 2016 11:52:19 +0000

On 28 Nov 2016, at 21:44, Julien ÉLIE <[email-masked]> wrote:
> 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.