doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc8143.txt b/doc/rfc/rfc8143.txt
new file mode 100644
index 0000000..3e59ac4
--- /dev/null
+++ b/doc/rfc/rfc8143.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           J. Elie
+Request for Comments: 8143                                    April 2017
+Updates: 4642
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                  Using Transport Layer Security (TLS)
+               with Network News Transfer Protocol (NNTP)
+
+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.  This document updates RFC 4642.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8143.
+
+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
+   (http://trustee.ietf.org/license-info) 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                         Standards Track                    [Page 1]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
+   2.  Updates/Changes to RFC 4642 . . . . . . . . . . . . . . . . .   3
+   3.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   4
+     3.1.  Compression . . . . . . . . . . . . . . . . . . . . . . .   4
+     3.2.  Protocol Versions and Security Preferences  . . . . . . .   4
+     3.3.  Server Name Indication  . . . . . . . . . . . . . . . . .   5
+     3.4.  Prevention of SSL Stripping . . . . . . . . . . . . . . .   5
+     3.5.  Authenticated Connections . . . . . . . . . . . . . . . .   5
+     3.6.  Human Factors . . . . . . . . . . . . . . . . . . . . . .   6
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
+   Appendix A.  Detailed Changes to RFC 4642 . . . . . . . . . . . .  11
+     A.1.  Related to TLS-Level Compression  . . . . . . . . . . . .  11
+     A.2.  Related to Implicit TLS . . . . . . . . . . . . . . . . .  11
+     A.3.  Related to RC4 Cipher Suites  . . . . . . . . . . . . . .  12
+     A.4.  Related to Server Name Indication . . . . . . . . . . . .  12
+     A.5.  Related to Certificate Verification . . . . . . . . . . .  12
+     A.6.  Related to Other Obsolete Wording . . . . . . . . . . . .  13
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13
+
+1.  Introduction
+
+   The Network News Transfer Protocol (NNTP) [RFC3977] has been using
+   Transport Layer Security (TLS) [RFC5246] along with its precursor,
+   Secure Sockets Layer (SSL), since at least the year 2000.  The use of
+   TLS in NNTP was formalized in [RFC4642], providing implementation
+   recommendations at the same time.  In order to address the evolving
+   threat model on the Internet today, this document provides stronger
+   recommendations regarding that use.
+
+   In particular, this document updates [RFC4642] by specifying that
+   NNTP implementations and deployments MUST follow the best current
+   practices documented in [BCP195], which currently consists of RFC
+   7525 ("Recommendations for Secure Use of Transport Layer Security
+   (TLS) and Datagram Transport Layer Security (DTLS)").  This includes
+   stronger recommendations regarding SSL/TLS protocol versions,
+   fallback to lower versions, TLS negotiation, TLS-level compression,
+   TLS session resumption, cipher suites, public key lengths, forward
+   secrecy, hostname validation, certificate verification, and other
+   aspects of using TLS with NNTP.
+
+
+
+
+Elie                         Standards Track                    [Page 2]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+1.1.  Conventions Used in This Document
+
+   Any term not defined in this document has the same meaning as it does
+   in [RFC4642] or the NNTP core specification [RFC3977].
+
+   When this document uses the term "implicit TLS", it refers to TLS
+   negotiation immediately upon connection on a separate port.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in RFC
+   2119 [BCP14].
+
+2.  Updates/Changes to RFC 4642
+
+   This document updates [RFC4642] in the following aspects:
+
+   o  NNTP implementations and deployments SHOULD disable TLS-level
+      compression (Section 3.3 of RFC 7525 [BCP195]), thus no longer
+      using TLS as a means to provide data compression (contrary to the
+      Abstract and Section 2.2.2 of [RFC4642]).
+
+   o  NNTP implementations and deployments SHOULD prefer implicit TLS,
+      and therefore use strict TLS configuration (Section 3.2 of RFC
+      7525 [BCP195]).  That is to say, they SHOULD use a port dedicated
+      to NNTP over TLS and begin the TLS negotiation immediately upon
+      connection (contrary to a dynamic upgrade from unencrypted to TLS-
+      protected traffic via the use of the STARTTLS command, as
+      Section 1 of [RFC4642] was encouraging).  Implicit TLS is the
+      preferred way of using TLS with NNTP for the same reasons,
+      transposed to NNTP, as those given in Appendix A of [MUA-STS].
+      (Note that [MUA-STS] and [RFC4642] have one author in common.)
+
+   o  NNTP implementations and deployments MUST NOT negotiate RC4 cipher
+      suites ([RFC7465]); this is contrary to Section 5 of [RFC4642],
+      which 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 given in Sections 4.2
+      and 4.2.1 of RFC 7525 [BCP195] instead.  The mandatory-to-
+      implement cipher suite or cipher suites depend on the TLS protocol
+      version.  For instance, when TLS 1.2 is used, the
+      TLS_RSA_WITH_AES_128_CBC_SHA cipher suite MUST be implemented
+      (Section 9 of [RFC5246]).
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 3]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+   o  All NNTP clients and any NNTP server that is known by multiple
+      names MUST support the Server Name Indication (SNI) extension
+      defined in Section 3 of [RFC6066], in conformance with Section 3.6
+      of RFC 7525 [BCP195].  It was only a "SHOULD" in Section 2.2.2 of
+      [RFC4642].
+
+   o  NNTP implementations and deployments MUST follow the rules and
+      guidelines defined in [RFC6125] and [RFC5280] for hostname
+      validation and certificate verification.  Part of Section 5 of
+      [RFC4642] is, therefore, rationalized in favor of following those
+      two documents.
+
+   Appendix A of this document gives detailed changes with regard to the
+   wording of [RFC4642].
+
+3.  Recommendations
+
+   The best current practices documented in [BCP195] apply here.
+   Therefore, NNTP implementations and deployments compliant with this
+   document are REQUIRED to comply with [BCP195] as well.
+
+   Instead of repeating those recommendations here, this document mostly
+   provides supplementary information regarding secure implementation
+   and deployment of NNTP technologies.
+
+3.1.  Compression
+
+   NNTP supports the use of the COMPRESS command, defined in Section 2.2
+   of [RFC8054], to compress data between an NNTP client and server.
+   Although this NNTP extension might have slightly stronger security
+   properties than TLS-level compression [RFC3749] (since NNTP
+   compression can be activated after authentication has completed, thus
+   reducing the chances that authentication credentials can be leaked
+   via, for instance, a Compression Ratio Info-leak Made Easy (CRIME)
+   attack, as described in Section 2.6 of [CRIME]), this document
+   neither encourages nor discourages the use of the NNTP COMPRESS
+   extension.
+
+3.2.  Protocol Versions and Security Preferences
+
+   NNTP implementations of news servers are encouraged to support
+   options to configure 1) the minimal TLS protocol version to accept
+   and 2) which cipher suites, signature algorithms, or groups (like
+   elliptic curves) to use for incoming connections.  Additional options
+   can naturally also be supported.  The goal is to enable
+   administrators of news servers to easily and quickly strengthen
+   security, if needed (for instance, by rejecting cipher suites
+   considered unsafe with regard to local policy).
+
+
+
+Elie                         Standards Track                    [Page 4]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+   News clients may also support similar options, either configurable by
+   the user or enforced by the news reader.
+
+3.3.  Server Name Indication
+
+   The TLS extension for Server Name Indication (SNI) defined in
+   Section 3 of [RFC6066] MUST be implemented by all news clients.  It
+   also MUST be implemented by any news server that is known by multiple
+   names.  (Otherwise, it is not possible for a server with several
+   hostnames to present the correct certificate to the client.)
+
+3.4.  Prevention of SSL Stripping
+
+   In order to help prevent SSL Stripping attacks (Section 2.1 of
+   [RFC7457]), NNTP implementations and deployments MUST follow the
+   recommendations provided in Section 3.2 of RFC 7525 [BCP195].
+   Notably, in case implicit TLS is not used, news clients SHOULD
+   attempt to negotiate TLS even if the server does not advertise the
+   STARTTLS capability label in response to the CAPABILITIES command
+   (Section 2.1 of [RFC4642]).
+
+3.5.  Authenticated Connections
+
+   [RFC4642] already provides recommendations and requirements for
+   certificate validation in the context of checking the client or the
+   server's identity.  Those requirements are strengthened by
+   Appendix A.5 of this document.
+
+   Wherever possible, it is best to prefer certificate-based
+   authentication (along with Simple Authentication and Security Layer
+   (SASL) [RFC4422]), and ensure that:
+
+   o  Clients authenticate servers.
+
+   o  Servers authenticate clients.
+
+   o  Servers authenticate other peer servers.
+
+   This document does not mandate certificate-based authentication,
+   although such authentication is strongly preferred.  As mentioned in
+   Section 2.2.2 of [RFC4642], the AUTHINFO SASL command (Section 2.4 of
+   [RFC4643]) with the EXTERNAL mechanism (Appendix A of [RFC4422]) MAY
+   be used to authenticate a client once its TLS credentials have been
+   successfully exchanged.
+
+   Given the pervasiveness of eavesdropping [RFC7258], even an encrypted
+   but unauthenticated connection might be better than an unencrypted
+   connection (this is similar to the "better-than-nothing security"
+
+
+
+Elie                         Standards Track                    [Page 5]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+   approach for IPsec [RFC5386], and in accordance with opportunistic
+   security principles [RFC7435]).  Encrypted but unauthenticated
+   connections include connections negotiated using anonymous Diffie-
+   Hellman mechanisms or using self-signed certificates, among others.
+
+   Note: when an NNTP server receives a Netnews article, it MAY add a
+   <diag-match> (Section 3.1.5 of [RFC5536]), which appears as "!!" in
+   the Path header field of that article, to indicate that it verified
+   the identity of the client or peer server.  This document encourages
+   the construction of such Path header fields, as described in
+   Section 3.2.1 of [RFC5537].
+
+3.6.  Human Factors
+
+   NNTP clients SHOULD provide ways for end users (and NNTP servers
+   SHOULD provide ways for administrators) to complete at least the
+   following tasks:
+
+   o  Determine if a given incoming or outgoing connection is encrypted
+      using a security layer (either using TLS or an SASL mechanism that
+      negotiates a security layer).
+
+   o  Be warned if the version of TLS used for encryption of a given
+      stream is not secure enough.
+
+   o  If authenticated encryption is used, determine how the connection
+      was authenticated or verified.
+
+   o  Be warned if the certificate offered by an NNTP server cannot be
+      verified.
+
+   o  Be warned if the cipher suite used to encrypt a connection is not
+      secure enough.
+
+   o  Be warned if the certificate changes for a given server.
+
+   o  When a security layer is not already in place, be warned if a
+      given server stops advertising the STARTTLS capability label in
+      response to the CAPABILITIES command (Section 2.1 of [RFC4642]),
+      whereas it advertised the STARTTLS capability label during any
+      previous connection within a (possibly configurable) time frame.
+      (Otherwise, a human might not see the warning the first time, and
+      the warning would disappear immediately after that.)
+
+   o  Be warned if a failure response to the STARTTLS command is
+      received from the server, whereas the STARTTLS capability label
+      was advertised.
+
+
+
+
+Elie                         Standards Track                    [Page 6]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+   Note that the last two tasks cannot occur when implicit TLS is used,
+   and that the penultimate task helps prevent an attack known as "SSL
+   Stripping" (Section 2.1 of [RFC7457]).
+
+4.  Security Considerations
+
+   Beyond the security considerations already described in [RFC4642],
+   [RFC6125], and [BCP195], the following caveat is worth mentioning
+   when not using implicit TLS: NNTP servers need to ensure that they
+   are not vulnerable to the STARTTLS command injection vulnerability
+   (Section 2.2 of [RFC7457]).  Though this command MUST NOT be
+   pipelined, an attacker could pipeline it.  Therefore, NNTP servers
+   MUST discard any NNTP command received between the use of STARTTLS
+   and the end of TLS negotiation.
+
+5.  IANA Considerations
+
+   This document does not change the formal definition of the STARTTLS
+   extension (Section 6 of [RFC4642]).  Nonetheless, as implementations
+   of the STARTTLS extension should follow this document, IANA has added
+   reference to this document to the existing STARTTLS label in the
+   "NNTP Capability Labels" registry contained in the "Network News
+   Transfer Protocol (NNTP) Parameters" registry:
+
+       +----------+--------------------------+--------------------+
+       | Label    | Meaning                  | Reference          |
+       +----------+--------------------------+--------------------+
+       | STARTTLS | Transport layer security | [RFC4642][RFC8143] |
+       +----------+--------------------------+--------------------+
+
+6.  References
+
+6.1.  Normative References
+
+   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/bcp14>.
+
+   [BCP195]   Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, May 2015,
+              <https://www.rfc-editor.org/info/bcp195>.
+
+   [RFC3977]  Feather, C., "Network News Transfer Protocol (NNTP)",
+              RFC 3977, DOI 10.17487/RFC3977, October 2006,
+              <http://www.rfc-editor.org/info/rfc3977>.
+
+
+
+
+Elie                         Standards Track                    [Page 7]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422,
+              DOI 10.17487/RFC4422, June 2006,
+              <http://www.rfc-editor.org/info/rfc4422>.
+
+   [RFC4642]  Murchison, K., Vinocur, J., and C. Newman, "Using
+              Transport Layer Security (TLS) with Network News Transfer
+              Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October
+              2006, <http://www.rfc-editor.org/info/rfc4642>.
+
+   [RFC4643]  Vinocur, J. and K. Murchison, "Network News Transfer
+              Protocol (NNTP) Extension for Authentication", RFC 4643,
+              DOI 10.17487/RFC4643, October 2006,
+              <http://www.rfc-editor.org/info/rfc4643>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <http://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5536]  Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
+              Article Format", RFC 5536, DOI 10.17487/RFC5536, November
+              2009, <http://www.rfc-editor.org/info/rfc5536>.
+
+   [RFC5537]  Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and
+              Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009,
+              <http://www.rfc-editor.org/info/rfc5537>.
+
+   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
+              Extensions: Extension Definitions", RFC 6066,
+              DOI 10.17487/RFC6066, January 2011,
+              <http://www.rfc-editor.org/info/rfc6066>.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+              2011, <http://www.rfc-editor.org/info/rfc6125>.
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 8]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+6.2.  Informative References
+
+   [CRIME]    Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty
+              Security Conference, 2012.
+
+   [MUA-STS]  Moore, K. and C. Newman, "Mail User Agent Strict Transport
+              Security (MUA-STS)", Work in Progress,
+              draft-ietf-uta-email-deep-06, March 2017.
+
+   [PKI-CERT] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              DOI 10.17487/RFC3280, April 2002,
+              <http://www.rfc-editor.org/info/rfc3280>.
+
+   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
+              Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May
+              2004, <http://www.rfc-editor.org/info/rfc3749>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <http://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC5386]  Williams, N. and M. Richardson, "Better-Than-Nothing
+              Security: An Unauthenticated Mode of IPsec", RFC 5386,
+              DOI 10.17487/RFC5386, November 2008,
+              <http://www.rfc-editor.org/info/rfc5386>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+              2014, <http://www.rfc-editor.org/info/rfc7258>.
+
+   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
+              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
+              December 2014, <http://www.rfc-editor.org/info/rfc7435>.
+
+   [RFC7457]  Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
+              Known Attacks on Transport Layer Security (TLS) and
+              Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
+              February 2015, <http://www.rfc-editor.org/info/rfc7457>.
+
+   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
+              DOI 10.17487/RFC7465, February 2015,
+              <http://www.rfc-editor.org/info/rfc7465>.
+
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 9]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+   [RFC7590]  Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
+              Security (TLS) in the Extensible Messaging and Presence
+              Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
+              2015, <http://www.rfc-editor.org/info/rfc7590>.
+
+   [RFC8054]  Murchison, K. and J. Elie, "Network News Transfer Protocol
+              (NNTP) Extension for Compression", RFC 8054,
+              DOI 10.17487/RFC8054, January 2017,
+              <http://www.rfc-editor.org/info/rfc8054>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 10]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+Appendix A.  Detailed Changes to RFC 4642
+
+   This section lists the detailed changes that this document applies to
+   [RFC4642].
+
+A.1.  Related to TLS-Level Compression
+
+   The second sentence in the Abstract in [RFC4642] is replaced with the
+   following text:
+
+      The primary goal is to provide encryption for single-link
+      confidentiality purposes, but data integrity, and (optional)
+      certificate-based peer entity authentication are also possible.
+
+   The second sentence of the first paragraph in Section 2.2.2 of
+   [RFC4642] is replaced with the following text:
+
+      The STARTTLS command is usually used to initiate session security,
+      although it can also be used for client and/or server certificate
+      authentication.
+
+A.2.  Related to Implicit TLS
+
+   The third and fourth paragraphs in Section 1 of [RFC4642] are
+   replaced with the following text:
+
+      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
+      plaintext 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
+
+
+
+
+
+Elie                         Standards Track                   [Page 11]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+      formalizes the STARTTLS command in use for that purpose.  However,
+      as already mentioned above, implementations SHOULD use implicit
+      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].
+
+   An additional informative reference to [RFC4301] is, therefore, added
+   to Section 7.2 of [RFC4642].
+
+A.3.  Related to RC4 Cipher Suites
+
+   The third paragraph in Section 5 of [RFC4642] is removed.
+   Consequently, NNTP no longer requires the implementation of any
+   cipher suites, other than those prescribed by TLS (Section 9 of
+   [RFC5246]), and Sections 4.2 and 4.2.1 of RFC 7525 [BCP195].
+
+A.4.  Related to Server Name Indication
+
+   The last two sentences of the seventh paragraph in Section 2.2.2 of
+   [RFC4642] are removed.  Section 3.6 of RFC 7525 [BCP195] applies.
+
+A.5.  Related to Certificate Verification
+
+   The text between "During the TLS negotiation" and "identity
+   bindings)." in Section 5 of [RFC4642] is replaced with the following
+   text:
+
+      During TLS negotiation, the client MUST verify the server's
+      identity in order to prevent man-in-the-middle attacks.  The
+      client MUST follow the rules and guidelines defined in [RFC6125],
+      where the reference identifier MUST be the server hostname that
+      the client used to open the connection, and that is also specified
+      in the TLS "server_name" extension [RFC6066].  The following NNTP-
+      specific consideration applies: DNS domain names in server
+      certificates MAY contain the wildcard character "*" as the
+      complete leftmost label within the identifier.
+
+      If the match fails, the client MUST follow the recommendations in
+      Section 6.6 of [RFC6125] regarding certificate pinning and
+      fallback.
+
+      Beyond server identity checking, clients also MUST apply the
+      procedures specified in [RFC5280] for general certificate
+      validation (e.g., certificate integrity, signing, and path
+      validation).
+
+
+
+
+Elie                         Standards Track                   [Page 12]
+
+RFC 8143                   Using TLS with NNTP                April 2017
+
+
+   Additional normative references to [RFC5280] (replacing [PKI-CERT],
+   which it obsoletes), [RFC6066], and [RFC6125] are, therefore, added
+   to Section 7.1 of [RFC4642].
+
+A.6.  Related to Other Obsolete Wording
+
+   The first two sentences of the seventh paragraph in Section 2.2.2 of
+   [RFC4642] are removed.  There is no special requirement for NNTP with
+   regard to TLS Client Hello messages.  Section 7.4.1.2 and Appendix E
+   of [RFC5246] apply.
+
+Acknowledgments
+
+   This document draws heavily on ideas in [RFC7590] by Peter Saint-
+   Andre and Thijs Alkemade; a large portion of this text was borrowed
+   from that specification.
+
+   The author would like to thank the following individuals for
+   contributing their ideas and support for writing this specification:
+   Stephane Bortzmeyer, Ben Campbell, Viktor Dukhovni, Stephen Farrell,
+   Sabahattin Gucukoglu, Richard Kettlewell, Jouni Korhonen, Mirja
+   Kuehlewind, David Eric Mandelberg, Matija Nalis, Chris Newman, and
+   Peter Saint-Andre.
+
+   Special thanks to Michael Baeuerle, for shepherding this document,
+   and to the Responsible Area Director, Alexey Melnikov, for sponsoring
+   it.  They both significantly helped to increase its quality.
+
+Author's Address
+
+   Julien Elie
+   10 allee Clovis
+   Noisy-le-Grand  93160
+   France
+
+   Email: julien@trigofacile.com
+   URI:   http://www.trigofacile.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 13]
+