7. Security Considerations

This entire document discusses the security practices directly affecting applications using the TLS protocol. This section contains broader security considerations related to technologies used in conjunction with or by TLS. The reader is referred to the Security Considerations sections of TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], TLS 1.2 [RFC5246], and DTLS 1.2 [RFC6347] for further context.

7.1. Host Name Validation

Application authors should take note that some TLS implementations do not validate host names. If the TLS implementation they are using does not validate host names, authors might need to write their own validation code or consider using a different TLS implementation.

It is noted that the requirements regarding host name validation (and, in general, binding between the TLS layer and the protocol that runs above it) vary between different protocols. For HTTPS, these requirements are defined by Sections 4.3.3, 4.3.4, and 4.3.5 of [RFC9110].

Host name validation is security-critical for all common TLS use cases. Without it, TLS ensures that the certificate is valid and guarantees possession of the private key but does not ensure that the connection terminates at the desired endpoint. Readers are referred to [RFC6125] for further details regarding generic host name validation in the TLS context. In addition, that RFC contains a long list of application protocols, some of which implement a policy very different from HTTPS.

If the host name is discovered indirectly and insecurely (e.g., by a cleartext DNS query for an SRV or Mail Exchange (MX) record), it SHOULD NOT be used as a reference identifier [RFC6125] even when it matches the presented certificate. This proviso does not apply if the host name is discovered securely (for further discussion, see [RFC7673] and [RFC7672]).

Host name validation typically applies only to the leaf "end entity" certificate. Naturally, in order to ensure proper authentication in the context of the PKI, application clients need to verify the entire certification path in accordance with [RFC5280].

7.2. AES-GCM

Section 4.2 recommends the use of the AES-GCM authenticated encryption algorithm. Please refer to Section 6 of [RFC5288] for security considerations that apply specifically to AES-GCM when used with TLS.

7.2.1. Nonce Reuse in TLS 1.2

The existence of deployed TLS stacks that mistakenly reuse the AES-GCM nonce is documented in [Boeck2016], showing there is an actual risk of AES-GCM getting implemented insecurely and thus making TLS sessions that use an AES-GCM cipher suite vulnerable to attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE-2016-10213, CVE-2016-10212, and CVE-2017-5933.)

While this problem has been fixed in TLS 1.3, which enforces a deterministic method to generate nonces from record sequence numbers and shared secrets for all its AEAD cipher suites (including AES-GCM), TLS 1.2 implementations could still choose their own (potentially insecure) nonce generation methods.

It is therefore RECOMMENDED that TLS 1.2 implementations use the 64-bit sequence number to populate the nonce_explicit part of the GCM nonce, as described in the first two paragraphs of Section 5.3 of [RFC8446]. This stronger recommendation updates Section 3 of [RFC5288], which specifies that the use of 64-bit sequence numbers to populate the nonce_explicit field is optional.

We note that at the time of writing, there are no cipher suites defined for nonce-reuse-resistant algorithms such as AES-GCM-SIV [RFC8452].

7.3. Forward Secrecy

Forward secrecy (also called "perfect forward secrecy" or "PFS" and defined in [RFC4949]) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the communicating parties' long-term keys.

Should the attacker be able to obtain these long-term keys at some point later in time, the session keys and thus the entire conversation could be decrypted.

In the context of TLS and DTLS, such compromise of long-term keys is not entirely implausible. It can happen, for example, due to:

• A client or server being attacked by some other attack vector, and the private key retrieved.

• A long-term key retrieved from a device that has been sold or otherwise decommissioned without prior wiping.

• A long-term key used on a device as a default key [Heninger2012].

• A key generated by a trusted third party like a CA and later retrieved from it by either extortion or compromise [Soghoian2011].

• A cryptographic breakthrough or the use of asymmetric keys with insufficient length [Kleinjung2010].

• Social engineering attacks against system administrators.

• Collection of private keys from inadequately protected backups.

Forward secrecy ensures in such cases that it is not feasible for an attacker to determine the session keys even if the attacker has obtained the long-term keys some time after the conversation. It also protects against an attacker who is in possession of the long-term keys but remains passive during the conversation.

Forward secrecy is generally achieved by using the Diffie-Hellman scheme to derive session keys. The Diffie-Hellman scheme has both parties maintain private secrets and send parameters over the network as modular powers over certain cyclic groups. The properties of the so-called Discrete Logarithm Problem (DLP) allow the parties to derive the session keys without an eavesdropper being able to do so. There is currently no known attack against DLP if sufficiently large parameters are chosen. A variant of the Diffie-Hellman scheme uses elliptic curves instead of the originally proposed modular arithmetic. Given the current state of the art, Elliptic Curve Diffie-Hellman appears to be more efficient, permits shorter key lengths, and allows less freedom for implementation errors than finite-field Diffie-Hellman.

Unfortunately, many TLS/DTLS cipher suites were defined that do not feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This document therefore advocates strict use of forward-secrecy-only ciphers.

7.4. Diffie-Hellman Exponent Reuse

For performance reasons, it is not uncommon for TLS implementations to reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multiple connections. Such reuse can result in major security issues:

• If exponents are reused for too long (in some cases, even as little as a few hours), an attacker who gains access to the host can decrypt previous connections. In other words, exponent reuse negates the effects of forward secrecy.

• TLS implementations that reuse exponents should test the DH public key they receive for group membership, in order to avoid some known attacks. These tests are not standardized in TLS at the time of writing, although general guidance in this area is provided by [NIST.SP.800-56A] and available in many protocol implementations.

• Under certain conditions, the use of static finite-field DH keys, or of ephemeral finite-field DH keys that are reused across multiple connections, can lead to timing attacks (such as those described in [RACCOON]) on the shared secrets used in Diffie-Hellman key exchange.

• An "invalid curve" attack can be mounted against Elliptic Curve DH if the victim does not verify that the received point lies on the correct curve. If the victim is reusing the DH secrets, the attacker can repeat the probe varying the points to recover the full secret (see [Antipa2003] and [Jager2015]).

To address these concerns:

• TLS implementations SHOULD NOT use static finite-field DH keys and SHOULD NOT reuse ephemeral finite-field DH keys across multiple connections.

• Server implementations that want to reuse Elliptic Curve DH keys SHOULD either use a "safe curve" [SAFECURVES] (e.g., X25519) or perform the checks described in [NIST.SP.800-56A] on the received points.

7.5. Certificate Revocation

The following considerations and recommendations represent the current state of the art regarding certificate revocation, even though no complete and efficient solution exists for the problem of checking the revocation status of common public key certificates [RFC5280]:

• Certificate revocation is an important tool when recovering from attacks on the TLS implementation as well as cases of misissued certificates. TLS implementations MUST implement a strategy to distrust revoked certificates.

• Although Certificate Revocation Lists (CRLs) are the most widely supported mechanism for distributing revocation information, they have known scaling challenges that limit their usefulness, despite workarounds such as partitioned CRLs and delta CRLs. The more modern [CRLite] and the follow-on Let's Revoke [LetsRevoke] build on the availability of Certificate Transparency [RFC9162] logs and aggressive compression to allow practical use of the CRL infrastructure, but at the time of writing, neither solution is deployed for client-side revocation processing at scale.

• Proprietary mechanisms that embed revocation lists in the web browser's configuration database cannot scale beyond the few most heavily used web servers.

• The Online Certification Status Protocol (OCSP) [RFC6960] in its basic form presents both scaling and privacy issues. In addition, clients typically "soft-fail", meaning that they do not abort the TLS connection if the OCSP server does not respond. (However, this might be a workaround to avoid denial-of-service attacks if an OCSP responder is taken offline.) For a recent survey of the status of OCSP deployment in the web PKI, see [Chung18].

• The TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling", resolves the operational issues with OCSP. However, it is still ineffective in the presence of an active on-path attacker because the attacker can simply ignore the client's request for a stapled OCSP response.

• [RFC7633] defines a certificate extension that indicates that clients must expect stapled OCSP responses for the certificate and must abort the handshake ("hard-fail") if such a response is not available.

• OCSP stapling as used in TLS 1.2 does not extend to intermediate certificates within a certificate chain. The Multiple Certificate Status extension [RFC6961] addresses this shortcoming, but it has seen little deployment and had been deprecated by [RFC8446]. As a result, although this extension was recommended for TLS 1.2 in [RFC7525], it is no longer recommended by this document.

• TLS 1.3 (Section 4.4.2.1 of [RFC8446]) allows the association of OCSP information with intermediate certificates by using an extension to the CertificateEntry structure. However, using this facility remains impractical because many certification authorities (CAs) either do not publish OCSP for CA certificates or publish OCSP reports with a lifetime that is too long to be useful.

• Both CRLs and OCSP depend on relatively reliable connectivity to the Internet, which might not be available to certain kinds of nodes. A common example is newly provisioned devices that need to establish a secure connection in order to boot up for the first time.

For the common use cases of public key certificates in TLS, servers SHOULD support the following as a best practice given the current state of the art and as a foundation for a possible future solution: OCSP [RFC6960] and OCSP stapling using the status_request extension defined in [RFC6066]. Note that the exact mechanism for embedding the status_request extension differs between TLS 1.2 and 1.3. As a matter of local policy, server operators MAY request that CAs issue must-staple [RFC7633] certificates for the server and/or for client authentication, but we recommend reviewing the operational conditions before deciding on this approach.

The considerations in this section do not apply to scenarios where the DNS-Based Authentication of Named Entities (DANE) TLSA resource record [RFC6698] is used to signal to a client which certificate a server considers valid and good to use for TLS connections.