(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:¶
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).¶
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.¶
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].¶
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].¶
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:¶
RSA key exchange offers no forward secrecy, by construction.¶
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]).¶
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶