Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)
draft-elie-nntp-tls-recommendations-05

[Ballot comment]
I'm balloting YES, but I have a few comments:

Substantive:

-2, 4th bullet: The normative requirement to support SNI is stated 3 times, with a inconsistent requirements. The first sentence says all implementations must support SNI. The next says all clients and servers that can have multiple names must support it.  Section 3.3 says that all new clients and any server with multiple names must support it.

-3.4: The section says all implementations are encouraged to follow the recommendations in section 3.2 of 7525. But section 3 said all implementations are REQUIRED to follow the recommendations in 7525 (which I assume to include section 3.2).

- 3.6: Do people expect end users to be able to do anything useful with information like TLS version,certificate details, and  cyphersuite choices?

- 6.2: RFCs 4433, 4643, 5536, and 5537 should probably be normative references, since they are referred to using 2119 keywords.

Editorial:

- Q1: I believe the preference is to use the BCP number.

-2, 2nd bullet: The last sentence is convoluted--can it be broken into simpler sentences?

-2, third bullet: Missing article ("the") before RC4. Also, I suspect the REQUIRED should not be capitalized. It seems like a statement of fact.

-2, 4th bullet: "only a SHOULD": "SHOULD" should be in quotes.

-3.1: Please expand "CRIME"

-4, 2nd paragraph, first sentence: Missing world around "need ensure"

[Ballot comment]

- write up: did "[[confirm]]" happen? Just curious.

- 3.5, 2nd last para: A reference to RFC7435 might
be useful here.  Not needed, just useful.

[Ballot comment]
- Should section 3.6. maybe also talk about displaying to the user if content was encrypted but not authenticated?

- Nit: in section 4. (Security Considerations):

OLD:

„Beyond the security considerations already described in [RFC4642],
  [RFC6125] and [RFC7525], the author wishes to add the following
  caveat when not using implicit TLS.

  NNTP servers need ensure that […]“
NEW:
„Beyond the security considerations already described in [RFC4642],
  [RFC6125] and [RFC7525], NNTP servers need to ensure that […]“

Shepherd writeup (Date: 2017-01-20)
draft-elie-nntp-tls-recommendations-04


1) Type of RFC
==============
This document provides recommendations for improving the security of the Network
News Transfer Protocol (NNTP) when using Transport Layer Security (TLS).

The intended category of this document will be "Standards Track".
The intended status of this document will be "Proposed Standard".


2) Document Announcement Write-Up
=================================

Technical Summary
-----------------
Document Shepherd: Michael Baeuerle
(The "ae" in "Baeuerle" is an ASCII transcription for the umlaut U+00E4)
Area Director    : Alexey Melnikov

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


Working Group Summary
---------------------
The draft was reviewed by a few people in .
There were comments from the former NNTPEXT working group mailing list and private mails
from Peter Saint-Andre for the part about certificate validation.


Document Quality
----------------
The document drops some NNTP protocol specific requirements and recommendations
in favour of referencing general BCP for TLS as defined by RFC7525.
Obsolete algorithms (like RC4 and MD5) are no longer defined as mandatory for
NNTP, increasing interoperability with modern TLS implementations.


3) Briefly describe the review of this document
===============================================
I have supported the creation of this document.


4) Shepherd concerns
====================
No concerns.


5) Further document review
==========================



6) Document issues
==================
No issues.


7) IPR disclosures
==================
The author confirmed that there is no IPR involved.


8) Has an IPR disclosure been filed that references this document?
==================================================================
Nothing known.


9) Consensus of the interested community behind this document?
==============================================================
There is consensus that the old mandatory algorithms need to be phased out.
The reference to RFC7525 adopts the general BCP for TLS. RFC8054 compression
can be used as a replacement for TLS compression (that should no longer be
used according to RFC7525).


10) Anyone threatened an appeal or otherwise indicated extreme discontent?
==========================================================================
No.


11) ID nits
===========
== Missing Reference: 'RFC-to-be' is mentioned on line 340, but not defined
This is a reference to the document itself.

The other warnings are related to the changelog section that will be removed for
the final document.


12) Required formal review criteria
===================================
?


13) Have all references within this document been identified as either
======================================================================
    normative or informative?
    =========================
Yes.


14) Normative references to documents that are not ready for advancement?
=========================================================================
None.


15) Are there downward normative references (see RFC 3967)?
======================================================================
No. All normative references are on Standards Track or BCP level.


16) Will publication of this document change status of any existing RFCs?
=========================================================================
It updates RFC4642 as noted in the header and the abstract section.


17) Document Shepherd's review of the IANA considerations section
=================================================================
The protocol extension STARTTLS is not changed from RFC4642. An additional
reference to the document is suggested for the NNTP Parameters registry.
The referenced IANA registry is clearly identified.


18) IANA registries that require Expert Review for future allocations
=====================================================================
None.


19) Reviews and automated checks performed by to validate sections of the
=========================================================================
    document written in a formal language
    =====================================
None.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, draft-elie-nntp-tls-recommendations@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)) to Proposed Standard


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)'
  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
ietf@ietf.org mailing lists by 2016-12-26. Exceptionally, comments may be
sent to iesg@ietf.org 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.

My AD review:

The document looks good to me, but I would be more clear in the last paragraph of Section 1:

o  NNTP implementations and deployments MUST NOT negotiate RC4 cipher
      suites ([RFC7465]) contrary to Section 5 of [RFC4642] that
      REQUIRED them to implement the TLS_RSA_WITH_RC4_128_MD5 cipher
      suite so as to ensure that any two NNTP compliant implementations
      can be configured to interoperate.  This document removes that
      requirement, so that NNTP client and server implementations follow
      the recommendations of Section 4.2.1 of [RFC7525] instead.

which ciphersuites are now mandatory to implement. Did you mean all 4 listed in 4.2 of [RFC7525]

  o  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  o  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  o  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

?