4. Recommendations: Cipher Suites

TLS 1.2 provided considerable flexibility in the selection of cipher suites. Unfortunately, the security of some of these cipher suites has degraded over time to the point where some are known to be insecure (this is one reason why TLS 1.3 restricted such flexibility). Incorrectly configuring a server leads to no or reduced security. This section includes recommendations on the selection and negotiation of cipher suites.

4.1. General Guidelines

Cryptographic algorithms weaken over time as cryptanalysis improves: algorithms that were once considered strong become weak. Consequently, cipher suites using weak algorithms need to be phased out and replaced with more secure cipher suites. This helps to ensure that the desired security properties still hold. SSL/TLS has been in existence for well over 20 years and many of the cipher suites that have been recommended in various versions of SSL/TLS are now considered weak or at least not as strong as desired. Therefore, this section modernizes the recommendations concerning cipher suite selection.

• Implementations MUST NOT negotiate the cipher suites with NULL encryption.

  Rationale: The NULL cipher suites do not encrypt traffic and so provide no confidentiality services. Any entity in the network with access to the connection can view the plaintext of contents being exchanged by the client and server. Nevertheless, this document does not discourage software from implementing NULL cipher suites, since they can be useful for testing and debugging.

• Implementations MUST NOT negotiate RC4 cipher suites.

  Rationale: The RC4 stream cipher has a variety of cryptographic weaknesses, as documented in [RFC7465]. Note that DTLS specifically forbids the use of RC4 already.

• Implementations MUST NOT negotiate cipher suites offering less than 112 bits of security, including so-called "export-level" encryption (which provides 40 or 56 bits of security).

  Rationale: Based on [RFC3766], at least 112 bits of security is needed. 40-bit and 56-bit security (found in so-called "export ciphers") are considered insecure today.

• Implementations SHOULD NOT negotiate cipher suites that use algorithms offering less than 128 bits of security.

  Rationale: Cipher suites that offer 112 or more bits but less than 128 bits of security are not considered weak at this time; however, it is expected that their useful lifespan is short enough to justify supporting stronger cipher suites at this time. 128-bit ciphers are expected to remain secure for at least several years and 256-bit ciphers until the next fundamental technology breakthrough. Note that, because of so-called "meet-in-the-middle" attacks [Multiple-Encryption], some legacy cipher suites (e.g., 168-bit Triple DES (3DES)) have an effective key length that is smaller than their nominal key length (112 bits in the case of 3DES). Such cipher suites should be evaluated according to their effective key length.

• Implementations SHOULD NOT negotiate cipher suites based on RSA key transport, a.k.a. "static RSA".

  Rationale: These cipher suites, which have assigned values starting with the string "TLS_RSA_WITH_*", have several drawbacks, especially the fact that they do not support forward secrecy.

• Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral (static) finite-field Diffie-Hellman (DH) key agreement. Similarly, implementations SHOULD NOT negotiate non-ephemeral Elliptic Curve DH key agreement.

  Rationale: The former cipher suites, which have assigned values prefixed by "TLS_DH_", have several drawbacks, especially the fact that they do not support forward secrecy. The latter ("TLS_ECDH_") also lack forward secrecy and are subject to invalid curve attacks [Jager2015].

• Implementations MUST support and prefer to negotiate cipher suites offering forward secrecy. However, TLS 1.2 implementations SHOULD NOT negotiate cipher suites based on ephemeral finite-field Diffie-Hellman key agreement (i.e., "TLS_DHE_*" suites). This is justified by the known fragility of the construction (see [RACCOON]) and the limitation around negotiation, including using [RFC7919], which has seen very limited uptake.

  Rationale: Forward secrecy (sometimes called "perfect forward secrecy") prevents the recovery of information that was encrypted with older session keys, thus limiting how far back in time data can be decrypted when an attack is successful. See Sections 7.3 and 7.4 for a detailed discussion.

4.2. Cipher Suites for TLS 1.2

Given the foregoing considerations, implementation and deployment of the following cipher suites is RECOMMENDED:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

As these are Authenticated Encryption with Associated Data (AEAD) algorithms [RFC5116], these cipher suites are supported only in TLS 1.2 and not in earlier protocol versions.

Typically, to prefer these suites, the order of suites needs to be explicitly configured in server software. It would be ideal if server software implementations were to prefer these suites by default.

Some devices have hardware support for AES Counter Mode with CBC-MAC (AES-CCM) but not AES Galois/Counter Mode (AES-GCM), so they are unable to follow the foregoing recommendations regarding cipher suites. There are even devices that do not support public key cryptography at all, but these are out of scope entirely.

A cipher suite that operates in CBC (cipher block chaining) mode (e.g., TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) SHOULD NOT be used unless the encrypt_then_mac extension [RFC7366] is also successfully negotiated. This requirement applies to both client and server implementations.

When using ECDSA signatures for authentication of TLS peers, it is RECOMMENDED that implementations use the NIST curve P-256. In addition, to avoid predictable or repeated nonces (which could reveal the long-term signing key), it is RECOMMENDED that implementations implement "deterministic ECDSA" as specified in [RFC6979] and in line with the recommendations in [RFC8446].

Note that implementations of "deterministic ECDSA" may be vulnerable to certain side-channel and fault injection attacks precisely because of their determinism. While most fault injection attacks described in the literature assume physical access to the device (and therefore are more relevant in Internet of Things (IoT) deployments with poor or non-existent physical security), some can be carried out remotely [Poddebniak2017], e.g., as Rowhammer [Kim2014] variants. In deployments where side-channel attacks and fault injection attacks are a concern, implementation strategies combining both randomness and determinism (for example, as described in [CFRG-DET-SIGS]) can be used to avoid the risk of successful extraction of the signing key.

4.2.1. Implementation Details

Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server. Servers MUST prefer this cipher suite over weaker cipher suites whenever it is proposed, even if it is not the first proposal. Clients are of course free to offer stronger cipher suites, e.g., using AES-256; when they do, the server SHOULD prefer the stronger cipher suite unless there are compelling reasons (e.g., seriously degraded performance) to choose otherwise.

The previous version of the TLS recommendations [RFC7525] implicitly allowed the old RFC 5246 mandatory-to-implement cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA. At the time of writing, this cipher suite does not provide additional interoperability, except with very old clients. As with other cipher suites that do not provide forward secrecy, implementations SHOULD NOT support this cipher suite. Other application protocols specify other cipher suites as mandatory to implement (MTI).

[RFC8422] allows clients and servers to negotiate ECDH parameters (curves). Both clients and servers SHOULD include the "Supported Elliptic Curves Extension" [RFC8422]. Clients and servers SHOULD support the NIST P-256 (secp256r1) [RFC8422] and X25519 (x25519) [RFC7748] curves. Note that [RFC8422] deprecates all but the uncompressed point format. Therefore, if the client sends an ec_point_formats extension, the ECPointFormatList MUST contain a single element, "uncompressed".

4.3. Cipher Suites for TLS 1.3

This document does not specify any cipher suites for TLS 1.3. Readers are referred to Section 9.1 of [RFC8446] for cipher suite recommendations.

4.4. Limits on Key Usage

All ciphers have an upper limit on the amount of traffic that can be securely protected with any given key. In the case of AEAD cipher suites, two separate limits are maintained for each key:

1. Confidentiality limit (CL), i.e., the number of records that can be encrypted.

2. Integrity limit (IL), i.e., the number of records that are allowed to fail authentication.

The latter applies to DTLS (and also to QUIC) but not to TLS itself, since TLS connections are torn down on the first decryption failure.

When a sender is approaching CL, the implementation SHOULD initiate a new handshake (in TLS 1.3, this can be achieved by sending a KeyUpdate message on the established session) to rotate the session key. When a receiver has reached IL, the implementation SHOULD close the connection. Although these recommendations are a best practice, implementers need to be aware that it is not always easy to accomplish them in protocols that are built on top of TLS/DTLS without introducing coordination across layer boundaries. See Section 6 of [RFC9001] for an example of the cooperation that was necessary in QUIC between the crypto and transport layers to support key updates. Note that in general, application protocols might not be able to emulate that method given their more constrained interaction with TLS/DTLS. As a result of these complexities, these recommendations are not mandatory.

For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of [RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher suites, readers are referred to Section 4.5.3 of [RFC9147].

For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in this document, CL can be derived by plugging the corresponding parameters into the inequalities in Section 6.1 of [AEAD-LIMITS] that apply to random, partially implicit nonces, i.e., the nonce construction used in TLS 1.2. Although the obtained figures are slightly higher than those for TLS 1.3, it is RECOMMENDED that the same limit of 2^24.5 records is used for both versions.

For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained from the same inequalities referenced above) is 2^28.

4.5. Public Key Length

When using the cipher suites recommended in this document, two public keys are normally used in the TLS handshake: one for the Diffie-Hellman key agreement and one for server authentication. Where a client certificate is used, a third public key is added.

With a key exchange based on modular exponential (MODP) Diffie-Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 bits are REQUIRED.

Rationale: For various reasons, in practice, DH keys are typically generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits would be roughly equivalent to only an 80-bit symmetric key [RFC3766], it is better to use keys longer than that for the "DHE" family of cipher suites. A DH key of 1926 bits would be roughly equivalent to a 100-bit symmetric key [RFC3766]. A DH key of 2048 bits (equivalent to a 112-bit symmetric key) is the minimum allowed by the latest revision of [NIST.SP.800-56A] as of this writing (see in particular Appendix D of that document).

As noted in [RFC3766], correcting for the emergence of The Weizmann Institute Relation Locator (TWIRL) machine [TWIRL] would imply that 1024-bit DH keys yield about 61 bits of equivalent strength and that a 2048-bit DH key would yield about 92 bits of equivalent strength. The Logjam attack [Logjam] further demonstrates that 1024-bit Diffie-Hellman parameters should be avoided.

With regard to ECDH keys, implementers are referred to the IANA "TLS Supported Groups" registry (formerly known as the "EC Named Curve Registry") within the "Transport Layer Security (TLS) Parameters" registry [IANA_TLS] and in particular to the "recommended" groups. Curves of less than 224 bits MUST NOT be used. This recommendation is in line with the latest revision of [NIST.SP.800-56A].

When using RSA, servers MUST authenticate using certificates with at least a 2048-bit modulus for the public key. In addition, the use of the SHA-256 hash algorithm is RECOMMENDED and SHA-1 or MD5 MUST NOT be used [RFC9155] (for more details, see also [CAB-Baseline], for which the current version at the time of writing is 1.8.4). Clients MUST indicate to servers that they request SHA-256 by using the "Signature Algorithms" extension defined in TLS 1.2. For TLS 1.3, the same requirement is already specified by [RFC8446].

4.6. Truncated HMAC

Implementations MUST NOT use the Truncated HMAC Extension, defined in Section 7 of [RFC6066].

Rationale: The extension does not apply to the AEAD cipher suites recommended above. However, it does apply to most other TLS cipher suites. Its use has been shown to be insecure in [PatersonRS11].