Modernization of RFC 4642

Document Type Active Internet-Draft (individual)
Last updated 2017-01-04
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Independent Submission                                           J. Elie
Internet-Draft                                           January 4, 2017
Intended status: Standards Track
Expires: July 8, 2017

                       Modernization of RFC 4642


   This document shows the sections that changed between RFC 4642 and
   draft-elie-nntp-tls-recommendations.  The -00 version contains the
   wording in RFC 4642.  The -01 version contains the wording in draft-

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 8, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Elie                      Expires July 8, 2017                  [Page 1]
Internet-Draft          Modernization of RFC 4642           January 2017

1.  Wording updated by draft-elie-nntp-tls-recommendations-04


   This memo defines an extension to the Network News Transfer Protocol
   (NNTP) that allows an NNTP client and server to use Transport Layer
   Security (TLS).  The primary goal is to provide encryption for
   single-link confidentiality purposes, but data integrity, and
   (optional) certificate-based peer entity authentication are also

1. Introduction

   Historically, unencrypted NNTP [NNTP] connections were satisfactory
   for most purposes.  However, sending passwords unencrypted over the
   network is no longer appropriate, and sometimes integrity and/or
   confidentiality protection are desired for the entire connection.

   The TLS protocol (formerly known as SSL) provides a way to secure an
   application protocol from tampering and eavesdropping.  Although
   advanced SASL authentication mechanisms [NNTP-AUTH] can provide a
   lightweight version of this service, TLS is complimentary to both
   simple authentication-only SASL mechanisms and deployed clear-text
   password login commands.

   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 immediate TLS negotiation
   on a separate port (referred to in this document as "implicit
   TLS") is the preferred way of using TLS with NNTP.

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

   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 implicit
   TLS on a separate port.

Elie                      Expires July 8, 2017                  [Page 2]
Internet-Draft          Modernization of RFC 4642           January 2017

   Note: a common alternative to protect NNTP exchanges with transit
Show full document text