Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2

(D)TLS 1.2 supports a variety of key exchange algorithms, including RSA, Diffie-Hellman (DH)
over a finite field, and Elliptic Curve Diffie-Hellman (ECDH).¶

DH key exchange, over any group, comes in ephemeral and non-ephemeral
varieties. Non-ephemeral DH algorithms use static DH public keys included in
the authenticating peer’s certificate; see [RFC4492] for discussion. In
contrast, ephemeral DH algorithms use ephemeral DH public keys sent in the
handshake and authenticated by the peer’s certificate. Ephemeral and non-ephemeral finite field DH
algorithms are called DHE and DH (or FFDHE and FFDH), respectively,
and ephemeral and non-ephemeral elliptic curve DH algorithms are
called ECDHE and ECDH, respectively [RFC4492].¶

In general, non-ephemeral cipher suites are not recommended due to their lack of
forward secrecy. Moreover, as demonstrated by the Raccoon attack [RACCOON] on finite field DH, public key reuse (either via non-ephemeral cipher suites or reused keys with
ephemeral cipher suites) can lead to timing side channels that may leak connection
secrets. For ECDH, invalid curve attacks similarly exploit secret
reuse in order to break security [ICA], further demonstrating the risk of reusing
public keys. While both side channels can be avoided in implementations, experience
shows that in practice, implementations may fail to thwart such attacks due to the
complexity and number of the required mitigations.¶

Additionally, RSA key exchange suffers from security problems that are independent
of implementation choices as well as problems that stem purely from the difficulty
of implementing security countermeasures correctly.¶

At a rough glance, the problems affecting FFDHE in (D)TLS 1.2 are as follows:¶

1. FFDHE suffers from interoperability problems because there is no mechanism for
   negotiating the group, and some implementations only support small group sizes
   (see [RFC7919], Section 1).¶

2. FFDHE groups may have small subgroups, which enables several attacks
   [SUBGROUPS]. When presented with a custom, non-standardized FFDHE group, a handshaking client cannot practically verify that the group chosen by the server does not suffer from this problem. There is also no mechanism for such handshakes to fall back to other key exchange parameters that are acceptable to the client.
   Custom FFDHE groups are widespread (as a result of advice based on [WEAK-DH]).
   Therefore, clients cannot simply reject handshakes that present custom, and thus potentially dangerous, groups.¶

3. In practice, some operators use 1024-bit FFDHE groups since this is the
   maximum size that ensures wide support (see [RFC7919], Section 1).
   This size leaves only a small security margin versus the current discrete log record,
   which stands at 795 bits [DLOG795].¶

4. Expanding on the previous point, just a handful of very large computations allow
   an attacker to cheaply decrypt a relatively large fraction of FFDHE traffic
   (namely, traffic encrypted using particular standardized groups) [WEAK-DH].¶

5. When secrets are not fully ephemeral, FFDHE suffers from the Raccoon side-channel attack [RACCOON]. (Note that FFDH is inherently vulnerable to the Raccoon attack
   unless constant-time mitigations are employed.)¶

The problems affecting RSA key exchange in (D)TLS 1.2 are as follows:¶

1. RSA key exchange offers no forward secrecy, by construction.¶

2. RSA key exchange may be vulnerable to Bleichenbacher’s attack [BLEI].
   Experience shows that variants of this attack arise every few years because
   implementing the relevant countermeasure correctly is difficult (see
   [ROBOT], [NEW-BLEI], and [DROWN]).¶

3. In addition to the above point, there is no convenient mechanism in (D)TLS 1.2 for
   the domain separation of keys. Therefore, a single endpoint that is vulnerable to
   Bleichenbacher’s attack would affect all endpoints sharing the same RSA key (see
   [XPROT] and [DROWN]).¶

This document updates
[RFC4162], [RFC4279], [RFC4346], [RFC4785], [RFC5246], [RFC5288], [RFC5289], [RFC5469], [RFC5487], [RFC5932], [RFC6209], [RFC6347], [RFC6367], [RFC6655], [RFC7905], [RFC8422], and [RFC9325] to remediate the above problems, by deprecating and discouraging the use of affected cipher suites, as listed in Sections 5.2, 5.3, 5.4, and 5.5.¶

BCP 195 [RFC8996] [RFC9325] contains the latest IETF recommendations for users of the (D)TLS protocol (and specifically, (D)TLS 1.2), and this
document updates [RFC9325] in several points. Section 6 details the exact differences.
All other recommendations in the BCP documents remain valid.¶