Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2

RFC 10015 Deprecating Obsolete Key Exchanges in (D July 2026 Aviram Standards Track [Page] RFC 10015 Abstract For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman (DH) over a finite field and RSA. It also discourages the use of static Elliptic Curve Diffie-Hellman (ECDH) cipher suites.¶ These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.)¶ This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 to either deprecate or discourage the use of cipher suites using the above key exchange methods in (D)TLS 1.2 connections.¶ Status of This Memo This is an Internet Standards Track document.¶ This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶ Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10015.¶ Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶ This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶ ▲ Table of Contents 1.  Introduction 1.1.  Requirements Language 2.  Non-Ephemeral Diffie-Hellman 3.  Ephemeral Finite Field Diffie-Hellman 4.  RSA 5.  Updates to Cipher Suites and TLS ClientCertificateType Identifiers 5.1.  DH Cipher Suites Deprecated by This Document 5.2.  ECDH Cipher Suites Whose Use Is Discouraged by This Document 5.3.  DHE Cipher Suites Deprecated by This Document 5.4.  RSA Cipher Suites Deprecated by This Document 5.5.  TLS ClientCertificateType Identifiers Deprecated by This Document 6.  Updates to RFC 9325 7.  IANA Considerations 8.  Security Considerations 9.  References 9.1.  Normative References 9.2.  Informative References Acknowledgments Author's Address 1. Introduction (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.¶ 1.1. Requirements Language 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.¶ 2. Non-Ephemeral Diffie-Hellman Clients MUST NOT offer and servers MUST NOT select non-ephemeral FFDH cipher suites in (D)TLS 1.2 connections. (Note that (D)TLS 1.0 and TLS 1.1 are deprecated by [RFC8996], and (D)TLS 1.3 does not support FFDH [RFC9846] [RFC9147].) This includes all cipher suites listed in Table 1 in Section 5.1.¶ Clients SHOULD NOT offer and servers SHOULD NOT select non-ephemeral ECDH cipher suites in (D)TLS 1.2 connections. (This requirement is already present in [RFC9325]. Note that (D)TLS 1.0 and TLS 1.1 are deprecated by [RFC8996], and (D)TLS 1.3 does not support ECDH [RFC9846] [RFC9147].) This includes all cipher suites listed in Table 2 in Section 5.2.¶ In addition, to avoid the use of non-ephemeral DH, clients SHOULD NOT use and servers SHOULD NOT accept certificates with fixed DH parameters. These certificate types are rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, and ecdsa_fixed_ecdh as listed in Section 5.5. These values only apply to (D)TLS versions of 1.2 and below.¶ 3. Ephemeral Finite Field Diffie-Hellman Clients MUST NOT offer and servers MUST NOT select FFDHE cipher suites in (D)TLS 1.2 connections. This includes all cipher suites listed in Table 3 in Section 5.3. (Note that (D)TLS 1.0 and TLS 1.1 are deprecated by [RFC8996].) FFDHE cipher suites in (D)TLS 1.3 do not suffer from the problems presented in Section 1; see [RFC9846] and [RFC9147]. Therefore, clients and servers MAY offer FFDHE cipher suites in (D)TLS 1.3 connections.¶ 4. RSA Clients MUST NOT offer and servers MUST NOT select RSA cipher suites in (D)TLS 1.2 connections. (Note that (D)TLS 1.0 and TLS 1.1 are deprecated by [RFC8996], and (D)TLS 1.3 does not support static RSA [RFC9846] [RFC9147].) This includes all cipher suites listed in Table 4 in Section 5.4. Note that these cipher suites were previously marked as not recommended in the "TLS Cipher Suites" registry [TLS-REGISTRY].¶ 5. Updates to Cipher Suites and TLS ClientCertificateType Identifiers The following subsections mention the use of "D" in the "Recommended" column of the "TLS Cipher Suites" and "TLS ClientCertificateType Identifiers" registries [TLS-REGISTRY]. See [RFC9847] for information on the use of the "D".¶ 5.1. DH Cipher Suites Deprecated by This Document