RFC 8143

Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)

📅 published April 2017, from ietf

RFC 8143: Using TLS with NNTP 🎀

Okay bestie, so this is RFC 8143, titled "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)" 💅. It came out in April 2017 from the Internet Engineering Task Force (IETF), it's written by J. Elie, and it's a Standards Track document, so it's the real deal 🔥. It updates RFC 4642. The ISSN is 2070-1721 ✨.

Abstract 🦋

So this doc gives recommendations for making NNTP (Network News Transfer Protocol) more secure when it's using TLS (Transport Layer Security) 🔐. It basically glows up how NNTP uses TLS so it matches TLS best current practices 💖. It also updates RFC 4642 🫶.

Status of This Memo 📜

This is an Internet Standards Track document 🌸.

It's a product of the Internet Engineering Task Force (IETF), and it has the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚.

Info about the current status, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc8143 💌.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the date it was published 📚. Read these carefully, because they explain your rights and restrictions for this doc 🙈. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come without warranty, as described in the Simplified BSD License 💀.

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 ✨

Okay so NNTP [RFC3977] has been vibing with TLS [RFC5246] (and its older sibling, SSL) since at least the year 2000 🕰️. [RFC4642] is the doc that officially formalized TLS in NNTP, and it dropped some implementation tips at the same time 🍓. But the threat landscape on the Internet today is a whole different beast, so this doc comes in with stronger recommendations about that use 💪.

In particular, this doc updates [RFC4642] by saying that NNTP implementations and deployments MUST follow the best current practices documented in [BCP195]. Right now that's RFC 7525 ("Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)") 📖. This brings in stronger guidance on 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 stuff about using TLS with NNTP 🫶.

1.1. Conventions Used in This Document 🎀

Any term that isn't defined here has the same meaning it has in [RFC4642] or the NNTP core spec [RFC3977] 📚.

When this doc says "implicit TLS", it means TLS negotiation starts right away when you connect, 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 doc updates [RFC4642] in the following ways 💅:

  • NNTP implementations and deployments SHOULD disable TLS-level compression (Section 3.3 of RFC 7525 [BCP195]), so they stop using TLS to provide data compression. That goes against the Abstract and Section 2.2.2 of [RFC4642] 🙅‍♀️.
  • NNTP implementations and deployments SHOULD prefer implicit TLS, which means they use strict TLS configuration (Section 3.2 of RFC 7525 [BCP195]). In other words, they SHOULD use a port dedicated to NNTP over TLS and start the TLS negotiation right away when you connect. That's different from upgrading an unencrypted connection to TLS with the STARTTLS command, which Section 1 of [RFC4642] was encouraging 🔐. Implicit TLS is the preferred way to use TLS with NNTP, for the same reasons Appendix A of [MUA-STS] gives, just transposed to NNTP 🧚. (Fun fact: [MUA-STS] and [RFC4642] have one author in common 👀.)
  • NNTP implementations and deployments MUST NOT negotiate RC4 cipher suites ([RFC7465]). This goes against Section 5 of [RFC4642], which required them to implement the TLS_RSA_WITH_RC4_128_MD5 cipher suite so that any two NNTP-compliant implementations could be configured to interoperate. This doc removes that requirement, so NNTP client and server implementations follow the recommendations in Sections 4.2 and 4.2.1 of RFC 7525 [BCP195] instead 🚫. The mandatory-to-implement cipher suite or 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]) 🔥.
  • 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] 🙈.
  • NNTP implementations and deployments MUST follow the rules and guidelines defined in [RFC6125] and [RFC5280] for hostname validation and certificate verification 🔍. So part of Section 5 of [RFC4642] gets rationalized in favor of following those two docs 🎀.

Appendix A of this doc gives the detailed changes to the wording of [RFC4642] 📝.

3. Recommendations 💜

The best current practices in [BCP195] apply here. So NNTP implementations and deployments that comply with this doc are REQUIRED to comply with [BCP195] as well 🫶.

Instead of repeating those recommendations here, this doc mostly gives supplementary info about securely implementing and deploying NNTP tech ✨.

3.1. Compression 🫧

NNTP supports the COMPRESS command, defined in Section 2.2 of [RFC8054], for compressing data between an NNTP client and server 🗜️. This NNTP extension might have slightly stronger security properties than TLS-level compression [RFC3749]. That's because NNTP compression can be turned on after authentication finishes, which lowers the chances that authentication credentials get leaked through something like a Compression Ratio Info-leak Made Easy (CRIME) attack, as described in Section 2.6 of [CRIME] 😭. Even so, this doc neither encourages nor discourages using the NNTP COMPRESS extension 🤷‍♀️.

3.2. Protocol Versions and Security Preferences 🔧

News server implementations of NNTP are encouraged to support options that let admins configure 1) the minimum TLS protocol version to accept and 2) which cipher suites, signature algorithms, or groups (like elliptic curves) to use for incoming connections 🛡️. Other options can naturally be supported too. The goal is to let news server admins strengthen security quickly and easily if they need to, like by rejecting cipher suites that local policy considers unsafe 💪.

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. Without it, a server with several hostnames can't present the right certificate to the client 🥺.

3.4. Prevention of SSL Stripping 🚨

To help prevent SSL Stripping attacks (Section 2.1 of [RFC7457]), NNTP implementations and deployments MUST follow the recommendations in Section 3.2 of RFC 7525 [BCP195] 🛑. Notably, if implicit TLS isn't used, news clients SHOULD attempt to negotiate TLS even when the server doesn't advertise the STARTTLS capability label in response to the CAPABILITIES command (Section 2.1 of [RFC4642]) 🔐✨.

3.5. Authenticated Connections ✨

okay so [RFC4642] already has recommendations and requirements for checking certificates, whether you're checking the client's identity or the server's. Those requirements get 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:

  • Clients authenticate servers. 🔐
  • Servers authenticate clients. 🫶
  • 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" 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, bestie:

  • 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). 🔍
  • Be warned if the version of TLS used for encryption of a given stream is not secure enough. ⚠️
  • If authenticated encryption is used, determine how the connection was authenticated or verified. 🕵️‍♀️
  • Be warned if the certificate offered by an NNTP server cannot be verified. 🙈
  • Be warned if the cipher suite used to encrypt a connection is not secure enough. 🔒
  • Be warned if the certificate changes for a given server. 🚨
  • 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.) 🥲
  • Be warned if a failure response to the STARTTLS command is received from the server, whereas the STARTTLS capability label was advertised. 💀

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. 😱 This part is seriously important, so please don't skip it, periodt. 💀

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 💜

6.2. Informative References 🌈

Appendix A. Detailed Changes to RFC 4642 🎀

This section lists the detailed changes that this document applies to [RFC4642]. 🍓

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.

okay so the third and fourth paragraphs in Section 1 of [RFC4642] get swapped out for new text, and honestly it's giving clarity 💅

Port 563 is reserved for NNTP over TLS and it's registered in the IANA Service Name and Transport Protocol Port Number Registry for exactly that. NNTP implementations on port 563 start TLS the second the connection opens, and only then do they move on to the first steps of an NNTP session. This immediate TLS handshake on its own port (called "implicit TLS" in this doc) is the preferred way to use TLS with NNTP 💖

If a host wants separate servers for transit and reading clients (Section 3.4.1 of [NNTP]), port 563 SHOULD be used for implicit TLS with the reading server. The transit server should use an unused port of its choice, and that port is NOT 433 🙈 (sorry, I mean the port SHOULD be different than TCP port 433). Clients need to be clearly told which ports are implicit TLS, and they need to know that no plaintext gets sent before the TLS session is negotiated 🔥

Some existing setups upgrade from plain to TLS mid-session on the old well-known ports 119 or 433. This spec formalizes the STARTTLS command for that. BUT, as I said above, implementations SHOULD use implicit TLS on a separate port ✨

Note: a common alternative for protecting NNTP exchanges with transit servers that don't implement TLS is IPsec with encryption [RFC4301].

Because of all that, an extra informative reference to [RFC4301] gets added to Section 7.2 of [RFC4642] 🧚

The third paragraph in Section 5 of [RFC4642] is removed, so the RC4 stuff is gone. That means NNTP doesn't require implementing any cipher suites beyond what TLS prescribes (Section 9 of [RFC5246]) and Sections 4.2 and 4.2.1 of RFC 7525 [BCP195] 🎀

The last two sentences of the seventh paragraph in Section 2.2.2 of [RFC4642] are deleted. Section 3.6 of RFC 7525 [BCP195] applies instead 💜

Okay, this is the big one. The text between "During the TLS negotiation" and "identity bindings)." in Section 5 of [RFC4642] gets replaced with new text, and it's super important:

During TLS negotiation, the client MUST verify the server's identity so man-in-the-middle attacks don't happen 😭 The client MUST follow the rules and guidelines in [RFC6125]. The reference identifier MUST be the server hostname the client used to open the connection, and that hostname also has to show up in the TLS "server_name" extension [RFC6066]. There's one NNTP-specific wrinkle: DNS names in server certificates MAY contain the wildcard character "*" as the complete leftmost label in the identifier 🍓

If the match fails, the client MUST follow the recommendations in Section 6.6 of [RFC6125] about certificate pinning and fallback 💀

Beyond checking server identity, clients also MUST apply the procedures in [RFC5280] for general certificate validation, like certificate integrity, signing, and path validation 👑

Because of this, extra normative references to [RFC5280] (which replaces [PKI-CERT], since it obsoletes it), [RFC6066], and [RFC6125] get added to Section 7.1 of [RFC4642] ✨

The first two sentences of the seventh paragraph in Section 2.2.2 of [RFC4642] get deleted. There's no special requirement for NNTP about TLS Client Hello messages, so Section 7.4.1.2 and Appendix E of [RFC5246] apply 🫶

Acknowledgments 🌈

This document really leans on ideas from [RFC7590] by Peter Saint-Andre and Thijs Alkemade, and a big chunk of its text was borrowed from that spec 💜

The author would like to thank these lovely people for their ideas and support: 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 made its quality way better 🙌

Author's Address 🦋

Julien Elie 10 allee Clovis Noisy-le-Grand 93160 France

Email: julien@trigofacile.com URI: http://www.trigofacile.com/

📦 where this page comes from