3. General Recommendations

This section provides general recommendations on the secure use of TLS. Recommendations related to cipher suites are discussed in the following section.

3.1. Protocol Versions

3.1.1. SSL/TLS Protocol Versions

It is important both to stop using old, less secure versions of SSL/TLS and to start using modern, more secure versions; therefore, the following are the recommendations concerning TLS/SSL protocol versions:

• Implementations MUST NOT negotiate SSL version 2.

  Rationale: Today, SSLv2 is considered insecure [RFC6176].

• Implementations MUST NOT negotiate SSL version 3.

  Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and plugged some significant security holes but did not support strong cipher suites. SSLv3 does not support TLS extensions, some of which (e.g., renegotiation_info [RFC5746]) are security critical. In addition, with the emergence of the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack [POODLE], SSLv3 is now widely recognized as fundamentally insecure. See [RFC7568] for further details.

• Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].

  Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per-record Initialization Vector (IV) for cipher suites based on cipher block chaining (CBC) and does not warn against common padding errors. This and other recommendations in this section are in line with [RFC8996].

• Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].

  Rationale: TLS 1.1 (published in 2006) is a security improvement over TLS 1.0 but still does not support certain stronger cipher suites that were introduced with the standardization of TLS 1.2 in 2008, including the cipher suites recommended for TLS 1.2 by this document (see Section 4.2 below).

• Implementations MUST support TLS 1.2 [RFC5246].

  Rationale: TLS 1.2 is implemented and deployed more widely than TLS 1.3 at this time, and when the recommendations in this document are followed to mitigate known attacks, the use of TLS 1.2 is as safe as the use of TLS 1.3. In most application protocols that reuse TLS and DTLS, there is no immediate need to migrate solely to TLS 1.3. Indeed, because many application clients are dependent on TLS libraries or operating systems that do not yet support TLS 1.3, proactively deprecating TLS 1.2 would introduce significant interoperability issues, thus harming security more than helping it. Nevertheless, it is expected that a future version of this BCP will deprecate the use of TLS 1.2 when it is appropriate to do so.

• Implementations SHOULD support TLS 1.3 [RFC8446] and, if implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS.

  Rationale: TLS 1.3 is a major overhaul to the protocol and resolves many of the security issues with TLS 1.2. To the extent that an implementation supports TLS 1.2 (even if it defaults to TLS 1.3), it MUST follow the recommendations regarding TLS 1.2 specified in this document.

• New transport protocols that integrate the TLS/DTLS handshake protocol and/or record layer MUST use only TLS/DTLS 1.3 (for instance, QUIC [RFC9001] took this approach). New application protocols that employ TLS/DTLS for channel or session encryption MUST integrate with both TLS/DTLS versions 1.2 and 1.3; nevertheless, in rare cases where broad interoperability is not a concern, application protocol designers MAY choose to forego TLS 1.2.

  Rationale: Secure deployment of TLS 1.3 is significantly easier and less error prone than secure deployment of TLS 1.2. When designing a new secure transport protocol such as QUIC, there is no reason to support TLS 1.2. By contrast, new application protocols that reuse TLS need to support both TLS 1.3 and TLS 1.2 in order to take advantage of underlying library or operating system support for both versions.

This BCP applies to TLS 1.3, TLS 1.2, and earlier versions. It is not safe for readers to assume that the recommendations in this BCP apply to any future version of TLS.

3.1.2. DTLS Protocol Versions

DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 1.1 was published. The following are the recommendations with respect to DTLS:

• Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].

  Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).

• Implementations MUST support DTLS 1.2 [RFC6347].

  Version 1.2 of DTLS correlates to version 1.2 of TLS (see above). (There is no version 1.1 of DTLS.)

• Implementations SHOULD support DTLS 1.3 [RFC9147] and, if implemented, MUST prefer to negotiate DTLS version 1.3 over earlier versions of DTLS.

  Version 1.3 of DTLS correlates to version 1.3 of TLS (see above).

3.1.3. Fallback to Lower Versions

TLS/DTLS 1.2 clients MUST NOT fall back to earlier TLS versions, since those versions have been deprecated [RFC8996]. As a result, the downgrade-protection Signaling Cipher Suite Value (SCSV) mechanism [RFC7507] is no longer needed for clients. In addition, TLS 1.3 implements a new version-negotiation mechanism.

3.2. Strict TLS

The following recommendations are provided to help prevent "SSL Stripping" and STARTTLS command injection (attacks that are summarized in [RFC7457]):

• Many existing application protocols were designed before the use of TLS became common. These protocols typically support TLS in one of two ways: either via a separate port for TLS-only communication (e.g., port 443 for HTTPS) or via a method for dynamically upgrading a channel from unencrypted to TLS protected (e.g., STARTTLS, which is used in protocols such as IMAP and XMPP). Regardless of the mechanism for protecting the communication channel (TLS-only port or dynamic upgrade), what matters is the end state of the channel. When a protocol defines both a dynamic upgrade method and a separate TLS-only method, then the separate TLS-only method MUST be supported by implementations and MUST be configured by administrators to be used in preference to the dynamic upgrade method. When a protocol supports only a dynamic upgrade method, implementations MUST provide a way for administrators to set a strict local policy that forbids use of plaintext in the absence of a negotiated TLS channel, and administrators MUST use this policy.

• HTTP client and server implementations intended for use in the World Wide Web (see Section 5) MUST support the HTTP Strict Transport Security (HSTS) header field [RFC6797] so that web servers can advertise that they are willing to accept TLS-only clients. Web servers SHOULD use HSTS to indicate that they are willing to accept TLS-only clients, unless they are deployed in such a way that using HSTS would in fact weaken overall security (e.g., it can be problematic to use HSTS with self-signed certificates, as described in Section 11.3 of [RFC6797]). Similar technologies exist for non-HTTP application protocols, such as Mail Transfer Agent Strict Transport Security (MTA-STS) for mail transfer agents [RFC8461] and methods based on DNS-Based Authentication of Named Entities (DANE) [RFC6698] for SMTP [RFC7672] and XMPP [RFC7712].

Rationale: Combining unprotected and TLS-protected communication opens the way to SSL Stripping and similar attacks, since an initial part of the communication is not integrity protected and therefore can be manipulated by an attacker whose goal is to keep the communication in the clear.

3.3. Compression

In order to help prevent compression-related attacks (summarized in Section 2.6 of [RFC7457]) when using TLS 1.2, implementations and deployments SHOULD NOT support TLS-level compression (Section 6.2.2 of [RFC5246]); the only exception is when the application protocol in question has been proven not to be open to such attacks. However, even in this case, extreme caution is warranted because of the potential for future attacks related to TLS compression. More specifically, the HTTP protocol is known to be vulnerable to compression-related attacks. (This recommendation applies to TLS 1.2 only, because compression has been removed from TLS 1.3.)

Rationale: TLS compression has been subject to security attacks such as the Compression Ratio Info-leak Made Easy (CRIME) attack.

Implementers should note that compression at higher protocol levels can allow an active attacker to extract cleartext information from the connection. The Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) attack is one such case. These issues can only be mitigated outside of TLS and are thus outside the scope of this document. See Section 2.6 of [RFC7457] for further details.

3.3.1. Certificate Compression

Certificate chains often take up most of the bytes transmitted during the handshake. In order to manage their size, some or all of the following methods can be employed (see also Section 4 of [RFC9191] for further suggestions):

• Limit the number of names or extensions.

• Use keys with small public key representations, like the Elliptic Curve Digital Signature Algorithm (ECDSA).

• Use certificate compression.

To achieve the latter, TLS 1.3 defines the compress_certificate extension in [RFC8879]. See also Section 5 of [RFC8879] for security and privacy considerations associated with its use. For the avoidance of doubt, CRIME-style attacks on TLS compression do not apply to certificate compression.

Due to the strong likelihood of middlebox interference, compression in the style of [RFC8879] has not been made available in TLS 1.2. In theory, the cached_info extension defined in [RFC7924] could be used, but it is not supported widely enough to be considered a practical alternative.

3.4. TLS Session Resumption

Session resumption drastically reduces the number of full TLS handshakes and thus is an essential performance feature for most deployments.

Stateless session resumption with session tickets is a popular strategy. For TLS 1.2, it is specified in [RFC5077]. For TLS 1.3, a more secure mechanism based on the use of a pre-shared key (PSK) is described in Section 4.6.1 of [RFC8446]. See [Springall16] for a quantitative study of the risks induced by TLS cryptographic "shortcuts", including session resumption.

When it is used, the resumption information MUST be authenticated and encrypted to prevent modification or eavesdropping by an attacker. Further recommendations apply to session tickets:

• A strong cipher MUST be used when encrypting the ticket (at least as strong as the main TLS cipher suite).

• Ticket-encryption keys MUST be changed regularly, e.g., once every week, so as not to negate the benefits of forward secrecy (see Section 7.3 for details on forward secrecy). Old ticket-encryption keys MUST be destroyed at the end of the validity period.

• For similar reasons, session ticket validity MUST be limited to a reasonable duration (e.g., half as long as ticket-encryption key validity).

• TLS 1.2 does not roll the session key forward within a single session. Thus, to prevent an attack where the server's ticket-encryption key is stolen and used to decrypt the entire content of a session (negating the concept of forward secrecy), a TLS 1.2 server SHOULD NOT resume sessions that are too old, e.g., sessions that have been open longer than two ticket-encryption key rotation periods.

Rationale: Session resumption is another kind of TLS handshake and therefore must be as secure as the initial handshake. This document (Section 4) recommends the use of cipher suites that provide forward secrecy, i.e., that prevent an attacker who gains momentary access to the TLS endpoint (either client or server) and its secrets from reading either past or future communication. The tickets must be managed so as not to negate this security property.

TLS 1.3 provides the powerful option of forward secrecy even within a long-lived connection that is periodically resumed. Section 2.2 of [RFC8446] recommends that clients SHOULD send a "key_share" when initiating session resumption. In order to gain forward secrecy, this document recommends that server implementations SHOULD select the "psk_dhe_ke" PSK key exchange mode and respond with a "key_share" to complete an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) exchange on each session resumption. As a more performant alternative, server implementations MAY refrain from responding with a "key_share" until a certain amount of time (e.g., measured in hours) has passed since the last ECDHE exchange; this implies that the "key_share" operation would not occur for the presumed majority of session resumption requests (which would occur within a few hours) while still ensuring forward secrecy for longer-lived sessions.

TLS session resumption introduces potential privacy issues where the server is able to track the client, in some cases indefinitely. See [Sy2018] for more details.

3.5. Renegotiation in TLS 1.2

The recommendations in this section apply to TLS 1.2 only, because renegotiation has been removed from TLS 1.3.

Renegotiation in TLS 1.2 is a handshake that establishes new cryptographic parameters for an existing session. The mechanism existed in TLS 1.2 and in earlier protocol versions and was improved following several major attacks including a plaintext injection attack, CVE-2009-3555 [CVE].

TLS 1.2 clients and servers MUST implement the renegotiation_info extension, as defined in [RFC5746].

TLS 1.2 clients MUST send renegotiation_info in the Client Hello. If the server does not acknowledge the extension, the client MUST generate a fatal handshake_failure alert prior to terminating the connection.

Rationale: It is not safe for a client to connect to a TLS 1.2 server that does not support renegotiation_info regardless of whether either endpoint actually implements renegotiation. See also Section 4.1 of [RFC5746].

A related attack resulting from TLS session parameters not being properly authenticated is a Triple Handshake [Triple-Handshake]. To address this attack, TLS 1.2 implementations MUST support the extended_master_secret extension defined in [RFC7627].

3.6. Post-Handshake Authentication

Renegotiation in TLS 1.2 was (partially) replaced in TLS 1.3 by separate post-handshake authentication and key update mechanisms. In the context of protocols that multiplex requests over a single connection (such as HTTP/2 [RFC9113]), post-handshake authentication has the same problems as TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the advice provided for HTTP/2 in Section 9.2.3 of [RFC9113].

3.7. Server Name Indication (SNI)

TLS implementations MUST support the Server Name Indication (SNI) extension defined in Section 3 of [RFC6066] for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy. At the time of writing, a technology for encrypting the SNI (called Encrypted Client Hello) is being worked on in the TLS Working Group [TLS-ECH]. Once that method has been standardized and widely implemented, it will likely be appropriate to recommend its usage in a future version of this BCP.

Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single address, and therefore enables fine-grained security for these virtual servers, by allowing each one to have its own certificate. However, SNI also leaks the target domain for a given connection; this information leak will be closed by use of TLS Encrypted Client Hello once that method has been standardized.

In order to prevent the attacks described in [ALPACA], a server that does not recognize the presented server name SHOULD NOT continue the handshake and instead SHOULD fail with a fatal-level unrecognized_name(112) alert. Note that this recommendation updates Section 3 of [RFC6066], which stated:

| If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake.

Clients SHOULD abort the handshake if the server acknowledges the SNI extension but presents a certificate with a different hostname than the one sent by the client.

3.8. Application-Layer Protocol Negotiation (ALPN)

TLS implementations (both client- and server-side) MUST support the Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].

In order to prevent "cross-protocol" attacks resulting from failure to ensure that a message intended for use in one protocol cannot be mistaken for a message for use in another protocol, servers are advised to strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:

| In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal 'no_application_protocol' alert.

Clients SHOULD abort the handshake if the server acknowledges the ALPN extension but does not select a protocol from the client list. Failure to do so can result in attacks such those described in [ALPACA].

Protocol developers are strongly encouraged to register an ALPN identifier for their protocols. This applies both to new protocols and to well-established protocols; however, because the latter might have a large deployed base, strict enforcement of ALPN usage may not be feasible when an ALPN identifier is registered for a well-established protocol.

3.9. Multi-Server Deployment

Deployments that involve multiple servers or services can increase the size of the attack surface for TLS. Two scenarios are of interest:

1. Deployments in which multiple services handle the same domain name via different protocols (e.g., HTTP and IMAP). In this case, an attacker might be able to direct a connecting endpoint to the service offering a different protocol and mount a cross-protocol attack. In a cross-protocol attack, the client and server believe they are using different protocols, which the attacker might exploit if messages sent in one protocol are interpreted as messages in the other protocol with undesirable effects (see [ALPACA] for more detailed information about this class of attacks). To mitigate this threat, service providers SHOULD deploy ALPN (see Section 3.8). In addition, to the extent possible, they SHOULD ensure that multiple services handling the same domain name provide equivalent levels of security that are consistent with the recommendations in this document; such measures SHOULD include the handling of configurations across multiple TLS servers and protections against compromise of credentials held by those servers.

2. Deployments in which multiple servers providing the same service have different TLS configurations. In this case, an attacker might be able to direct a connecting endpoint to a server with a TLS configuration that is more easily exploitable (see [DROWN] for more detailed information about this class of attacks). To mitigate this threat, service providers SHOULD ensure that all servers providing the same service provide equivalent levels of security that are consistent with the recommendations in this document.

3.10. Zero Round-Trip Time (0-RTT) Data in TLS 1.3

The 0-RTT early data feature is new in TLS 1.3. It provides reduced latency when TLS connections are resumed, at the potential cost of certain security properties. As a result, it requires special attention from implementers on both the server and the client side. Typically, this extends to the TLS library as well as protocol layers above it.

For HTTP over TLS, refer to [RFC8470] for guidance.

For QUIC on TLS, refer to Section 9.2 of [RFC9001].

For other protocols, generic guidance is given in Section 8 and Appendix E.5 of [RFC8446]. To paraphrase Appendix E.5, applications MUST avoid this feature unless an explicit specification exists for the application protocol in question to clarify when 0-RTT is appropriate and secure. This can take the form of an IETF RFC, a non-IETF standard, or documentation associated with a non-standard protocol.