Skip to main content

Shepherd writeup
draft-elie-nntp-tls-recommendations

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 <mailto:michael.baeuerle@stz-e.de>
(The "ae" in "Baeuerle" is an ASCII transcription for the umlaut U+00E4)
Area Director    : Alexey Melnikov <mailto:aamelnikov@fastmail.fm>

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 <news:news.software.nntp>.
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
==========================
<https://datatracker.ietf.org/doc/review-elie-nntp-tls-recommendations-01-secdir-lc-mandelberg-2016-12-08/>


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