Glonce

IETF deprecates RSA and Diffie-Hellman key exchange in TLS 1.2

securityThe Glonce editorsHacker News🔥55Glonce rating55Impact55Novelty35Relevance80Surprise20Players30Credibility95

The IETF has published RFC 10015, an Internet Standards Track document approved by the Internet Engineering Steering Group (IESG) and representing the consensus of the IETF community. It deprecates two key exchange methods in (D)TLS 1.2: finite-field Diffie-Hellman (both the ephemeral FFDHE and static DH variants) and RSA key exchange. It also discourages static, non-ephemeral Elliptic Curve Diffie-Hellman (ECDH) cipher suites. The document updates a series of earlier TLS RFCs, including RFC 9325 (BCP 195, the IETF's main TLS recommendations document).

The rules apply only to (D)TLS 1.2. TLS 1.0 and TLS 1.1 were already deprecated by RFC 8996, and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options, so it is untouched by this document.

The reasoning: non-ephemeral cipher suites lack forward secrecy by design. The Raccoon attack, demonstrated against finite-field DH, showed that reusing a public key, whether through a non-ephemeral cipher suite or a reused ephemeral key, can create timing side channels that leak connection secrets. Invalid curve attacks against static ECDH similarly exploit key reuse to break security. RSA key exchange offers no forward secrecy at all and can be vulnerable to Bleichenbacher's attack; variants of that attack have kept resurfacing every few years, including the ROBOT and DROWN cases, because implementing the countermeasure correctly is hard. Because (D)TLS 1.2 has no mechanism to separate keys by domain, a single endpoint vulnerable to Bleichenbacher's attack can put every other endpoint sharing the same RSA key at risk.

Finite-field DH carries its own separate problems: there is no mechanism to negotiate the group, so some implementations support only small group sizes; custom, non-standardized FFDHE groups are widespread in practice, may contain small subgroups that enable attacks, and a client has no practical way to verify a server-chosen custom group is safe, nor any fallback if it refuses one. Some operators still use 1024-bit FFDHE groups, the largest size that keeps broad client support, but that leaves only a small security margin against the current discrete-log computation record of 795 bits. A handful of very large computations against the small number of standardized groups would let an attacker cheaply decrypt a large share of FFDHE-protected traffic.

The normative requirements: clients must not offer and servers must not select non-ephemeral finite-field DH cipher suites, or certificates with fixed DH or ECDH parameters (the rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh and ecdsa_fixed_ecdh types). Clients should not offer and servers should not select static ECDH cipher suites, a weaker recommendation already present in RFC 9325. Clients must not offer and servers must not select ephemeral FFDHE cipher suites or RSA cipher suites in (D)TLS 1.2; FFDHE remains permitted in TLS 1.3, where these particular problems do not apply. IANA has marked the affected entries in the TLS Cipher Suites and TLS ClientCertificateType Identifiers registries as "D" (deprecated) and added RFC 10015 as their reference.

Key facts

  • RFC 10015 deprecates RSA and finite-field Diffie-Hellman key exchange, both ephemeral FFDHE and static DH, in (D)TLS 1.2, and discourages static ECDH cipher suites.
  • The Raccoon attack showed reused finite-field DH keys create timing side channels that leak connection secrets; RSA key exchange remains exposed to variants of Bleichenbacher's attack, including ROBOT and DROWN.
  • Some deployments still use 1024-bit FFDHE groups, leaving only a small security margin against the current discrete-log computation record of 795 bits.
  • The rules cover only (D)TLS 1.2: TLS 1.0/1.1 were already deprecated by RFC 8996, and TLS 1.3 is unaffected since it doesn't use these algorithms; FFDHE stays allowed there.
  • IANA has marked the affected cipher suites as deprecated ("D") in the TLS Cipher Suites registry, and the document updates RFC 9325 (BCP 195) among other prior TLS RFCs.

Why it matters

TLS 1.2 is still widely deployed alongside 1.3, and its key exchange menu has long included options known to be risky. RFC 10015 turns years of informal advice (avoid static DH and ECDH, watch for Bleichenbacher) into IETF standards-track requirements with the force of MUST NOT, and gets IANA to mark the affected cipher suites as deprecated in the official registry rather than merely discouraged.

Who it affects

TLS and DTLS library maintainers, server operators who still configure RSA key exchange or static DH/ECDH certificates for compatibility with older clients, and anyone running (D)TLS 1.2 endpoints. Deployments that only speak TLS 1.3 are unaffected, since the document does not touch that version.

How to use it

There is no product or price attached. Server operators and library maintainers should consult the cipher-suite and certificate-type tables in RFC 10015, stop offering or selecting RSA and finite-field DH cipher suites (ephemeral and static alike), and stop accepting certificates with fixed DH or ECDH parameters. The IANA TLS Cipher Suites registry now marks the affected entries with a "D" for a quick check.

How solid is it

This is an Internet Standards Track RFC, approved by the IESG after IETF community review, so procedurally it carries as much weight as this kind of guidance gets. Its technical case rests on previously documented attacks, the Raccoon attack, invalid curve attacks, and Bleichenbacher's attack with its recurring variants, rather than new research; the document formalizes known risk into a deprecation rather than disclosing a new vulnerability.

Risks and caveats

The document sets no enforcement deadline: it states MUST NOT and SHOULD NOT requirements, not a shutoff date, so servers and embedded devices can keep negotiating these cipher suites until someone actually updates them. It names N. Aviram (Nimrod Aviram) as its sole author and gives a publication date of July 2026 in its header. And its scope is narrow by design, covering only (D)TLS 1.2; anything still on (D)TLS 1.0/1.1 already needed to move under RFC 8996, and TLS 1.3 was never exposed to these particular key-exchange weaknesses.

“Clients MUST NOT offer and servers MUST NOT select RSA cipher suites in (D)TLS 1.2 connections.”

— RFC 10015