Implicit TLS (immediate negotiation on a dedicated port) is preferred over STARTTLS because it eliminates the opportunity for SSL Stripping attacks that exist when a dynamic upgrade path from plaintext is available, and aligns with best practices for other protocols (e.g., email MUA-STS).

tls, security

The mandatory-to-implement RC4 cipher suite (TLS_RSA_WITH_RC4_128_MD5) required by RFC 4642 for interoperability is removed because RC4 is now prohibited by RFC 7465; implementations must instead follow BCP195 cipher suite guidance.

tls, crypto, security

The RFC neither encourages nor discourages the NNTP COMPRESS extension (RFC 8054) because it has slightly stronger security properties than TLS-level compression: NNTP compression can be activated after authentication, reducing the risk of credential leakage via CRIME-style attacks.

tls, security

When an NNTP server receives a Netnews article and has verified the identity of the client or peer server, it MAY add a <diag-match> ('!!' in the Path header field per RFC 5536 Section 3.1.5) to signal authenticated receipt.

tls, security

While implicit TLS is preferred, this specification retains and formalizes the STARTTLS command for deployments that dynamically upgrade from unencrypted NNTP on TCP ports 119 or 433, acknowledging existing implementations.

tls

All NNTP clients and any NNTP server known by multiple names MUST support the SNI extension defined in Section 3 of RFC 6066, upgrading from the SHOULD in RFC 4642.

tls, security

DNS domain names in NNTP server certificates MAY contain the wildcard character '*' as the complete leftmost label within the identifier, and if a match fails the client MUST follow RFC 6125 Section 6.6 on certificate pinning and fallback.

tls, pkix, security

During TLS negotiation, the client MUST verify the server's identity per RFC 6125, where the reference identifier MUST be the server hostname used to open the connection and specified in the TLS server_name extension.

tls, pkix, security

If a host wishes to offer separate servers for transit and reading clients, TCP port 563 SHOULD be used for implicit TLS with the reading server, and a different unused port (not 433) SHOULD be used for implicit TLS with the transit server.

tls

NNTP clients SHOULD provide ways for end users and NNTP servers SHOULD provide ways for administrators to view connection encryption status, TLS version warnings, certificate verification status, and STARTTLS capability disappearance warnings.

tls, security

NNTP implementations and deployments MUST comply with BCP195 (RFC 7525, 'Recommendations for Secure Use of TLS and DTLS'), covering protocol versions, cipher suites, compression, session resumption, public key lengths, forward secrecy, hostname validation, and certificate verification.

tls, security

NNTP implementations and deployments MUST follow RFC 6125 and RFC 5280 for hostname validation and certificate verification, replacing the partial certificate guidance in RFC 4642 Section 5.

tls, pkix, security

NNTP implementations and deployments MUST NOT negotiate RC4 cipher suites (RFC 7465), removing the former RFC 4642 requirement to implement TLS_RSA_WITH_RC4_128_MD5 for interoperability.

tls, crypto, security

NNTP implementations and deployments SHOULD disable TLS-level compression (per Section 3.3 of RFC 7525), overriding the earlier RFC 4642 guidance that encouraged using TLS as a means to provide data compression.

tls, security

NNTP implementations and deployments SHOULD prefer implicit TLS (immediate negotiation upon connection on a dedicated port, TCP 563) over STARTTLS-based dynamic upgrade from unencrypted to TLS-protected traffic.

tls, security

NNTP servers MUST discard any NNTP command received between the use of the STARTTLS command and the end of TLS negotiation, to prevent STARTTLS command injection attacks (RFC 7457 Section 2.2).

tls, security

To prevent SSL Stripping attacks, when 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.

tls, security

News servers are encouraged to expose configuration options for the minimum acceptable TLS protocol version, cipher suites, signature algorithms, and groups (e.g., elliptic curves) for incoming connections, enabling administrators to quickly tighten security policy.

tls, security

The STARTTLS capability label in NNTP signals server support for upgrading a plaintext connection to TLS. Clients should attempt STARTTLS even when this label is absent, and be warned when it disappears after having been previously advertised.

tls

IANA updated the existing STARTTLS entry in the 'NNTP Capability Labels' registry (within the 'Network News Transfer Protocol (NNTP) Parameters' registry) to add RFC 8143 as an additional reference alongside RFC 4642.

registry, tls

Clients and servers are strongly encouraged to use certificate-based mutual authentication (clients authenticate servers, servers authenticate clients, servers authenticate peer servers) using SASL EXTERNAL with the AUTHINFO SASL command, though it is not mandated.

tls, security, pkix

Given the pervasiveness of eavesdropping (RFC 7258), even an encrypted but unauthenticated connection (e.g., anonymous Diffie-Hellman or self-signed certificates) is preferable to an unencrypted connection, consistent with opportunistic security principles (RFC 7435).

tls, security, privacy

NNTP servers using STARTTLS must guard against the STARTTLS command injection vulnerability (RFC 7457 Section 2.2): although STARTTLS MUST NOT be pipelined, an attacker could pipeline it, so servers MUST discard all NNTP commands received between STARTTLS and the end of TLS negotiation.

tls, security