The IETF Finally Kills RSA Key Exchange in TLS 1.2

The IETF published RFC 10015 in July, and on paper it's a bloodbath: roughly two hundred TLS 1.2 cipher-suite code points marked deprecated in one document, updating seventeen earlier RFCs going back to the original TLS 1.1 spec. Clients MUST NOT offer, and servers MUST NOT select, RSA key transport or any finite-field Diffie-Hellman suite — ephemeral or not — in TLS 1.2 and DTLS 1.2. Static ECDH gets a slightly gentler SHOULD NOT.

If your mental model is "browsers did this years ago," you're right, and that's exactly why the RFC is worth reading closely. Chrome dropped DHE-based suites back in 2016; Safari and Edge followed. The web didn't need this document. Enterprise networks, embedded fleets, and compliance auditors did — and for them, the details bite harder than the headline.

The surprise is that ephemeral DH dies too

Deprecating RSA key exchange surprises nobody. It has no forward secrecy, and it's been a Bleichenbacher-attack generator since 1998 — the ROBOT research showed in 2017 that the same padding-oracle attack still worked against stacks from major vendors nearly two decades after it was first published. Each fix produced a more intricate countermeasure, each countermeasure produced new timing side channels. The RFC's position is that the construction is unfixable in practice, and history backs it.

The genuinely interesting call is banning DHE — ephemeral finite-field Diffie-Hellman, the thing we spent the 2000s telling people to enable for forward secrecy. The reasoning is structural: TLS 1.2 has no mechanism for negotiating the DH group. The server picks whatever parameters it wants, the client can take them or abort, and in the wild that meant a long tail of 1024-bit and even weaker groups, some with small subgroups that enable key-recovery attacks. Logjam demonstrated in 2015 that a nation-state-scale precomputation against a single popular group pays off across a huge fraction of traffic, and the 2020 Raccoon attack showed that even honest servers reusing DH secrets leak via timing. RFC 7919 tried to retrofit vetted named groups onto TLS 1.2 in 2016; adoption never happened.

That's why the same math survives in TLS 1.3: there, FFDHE only exists as negotiated, standardized named groups with sane minimum sizes, and RFC 10015 explicitly says 1.3's FFDHE is fine. The deprecation isn't of Diffie-Hellman — it's of TLS 1.2's inability to constrain it.

What's actually left of TLS 1.2

Strip out the four deprecated families and a compliant TLS 1.2 config collapses to ECDHE with RSA or ECDSA signatures (plus PSK variants for the niches that use them). Combined with RFC 9325's existing AEAD guidance, "compliant TLS 1.2" now means a handful of ECDHE+AES-GCM and ECDHE+ChaCha20 suites — TLS 1.3's handshake diet, imposed retroactively. The Mozilla config generator's intermediate profile has looked like this for years; the floor of the standard just rose to meet it.

Checking where you stand takes one command per family, because OpenSSL will still happily negotiate plain-RSA suites out of the box:

# RSA key transport — should fail after you remediate
openssl s_client -connect internal-api.corp:443 -tls1_2 -cipher AES128-GCM-SHA256 </dev/null

# Ephemeral finite-field DH
openssl s_client -connect internal-api.corp:443 -tls1_2 -cipher DHE-RSA-AES128-GCM-SHA256 </dev/null

A handshake that completes is now a finding, not a preference. That's the real force of a standards-track MUST NOT: testssl.sh and SSL Labs will flag it, PCI and SOC 2 assessors will cite it, and procurement checklists will inherit it. Paper deprecations look toothless until you've watched RFC 8996 (the TLS 1.0/1.1 kill order) propagate through audit frameworks in about two years flat.

Who actually feels this? Three groups. Legacy clients that never learned ECDHE — old Java 6/7 stacks, payment terminals, industrial gear with decade-old TLS libraries — lose their last sanctioned handshake with a compliant server. Embedded vendors who shipped static-RSA-only firmware because it was small and certificate-cheap now have a gap that only a firmware update or a TLS-terminating proxy closes. And network security teams lose the last defensible version of a beloved trick: passive decryption. Static RSA key exchange is what let you load a server's private key into Wireshark or an out-of-band inspection appliance and read traffic after the fact. That workflow was already dead on TLS 1.3 — ETSI even forked the protocol into "Enterprise TLS" in 2018 to preserve it, over loud IETF objections — and RFC 10015 closes the TLS 1.2 loophole. Endpoint-side capture via SSLKEYLOGFILE, or inline termination, are what's left. That's the correct outcome, but if your monitoring architecture assumed decryptable TLS 1.2, this RFC is your migration deadline notice.

Five years to say the obvious, and worth it

The draft started life in early 2021 as a narrow FFDHE deprecation, absorbed RSA key transport along the way, and took five and a half years to become a Proposed Standard — for cipher suites the browser ecosystem abandoned a decade ago. It's fair to ask what the IETF is for if it ratifies reality this slowly.

But that framing misses what these documents do. "Everyone knows RSA key exchange is bad" doesn't survive contact with a vendor who needs a contractual reason to patch, or an auditor who needs a citation, or a middlebox salesperson insisting static keys are an enterprise requirement. A MUST NOT with an RFC number is leverage. The more useful reading: TLS 1.2 is now formally a frozen legacy protocol, permitted only in a configuration that imitates TLS 1.3 as closely as its handshake allows. If you're still choosing to deploy 1.2 in 2026 — rather than merely tolerating it at the edges — the standard's message is that there is no remaining configuration question. There's ECDHE with AEAD, and there's noncompliance. Spend the effort on the 1.3 migration instead; the transition budget you'd burn re-tuning 1.2 cipher strings buys most of the way there.