Published in July 2026, RFC 10015 represents the IETF's most sweeping cipher suite deprecation effort since RFC 8996 removed TLS 1.0 and 1.1 from acceptable use. Authored by N. Aviram and published on the Standards Track, the document formally deprecates finite-field Diffie-Hellman (both ephemeral DHE and non-ephemeral DH variants) and RSA key exchange within TLS 1.2 and DTLS 1.2 connections. It also upgrades the existing SHOULD NOT guidance on static ECDH cipher suites to a formal deprecation marker in the IANA registry. The scope is significant: over 150 cipher suite entries across 17 previously published RFCs are now marked deprecated.
The timing is deliberate. TLS 1.3, standardised in RFC 8446 (and now re-published as RFC 9846), eliminates these key exchange mechanisms entirely by design. TLS 1.0 and 1.1 were already removed by RFC 8996. RFC 10015 therefore targets the narrow but still widely deployed window of TLS 1.2 deployments that have not yet migrated fully to 1.3. The practical question is not whether these algorithms are broken in theory, but whether the formal deprecation changes operational behaviour in practice.
The Technical Case Against Finite-Field Diffie-Hellman in TLS 1.2
The RFC's treatment of FFDHE is unusually thorough, cataloguing several distinct failure modes that interact badly with the TLS 1.2 negotiation model. The core problem is that TLS 1.2 gives the server unilateral authority to choose the DH group, with no mechanism for the client to negotiate acceptable parameters. This asymmetry, tolerable when groups were standardised, became a genuine security liability once operators were widely advised (following the WEAK-DH analysis) to generate their own custom groups.
The consequences compound. A client that advertises DHE cipher suites cannot, upon receiving a server's custom group, verify group safety without a prohibitively expensive primality and subgroup structure check. Nor can it fall back gracefully: TLS 1.2 has no mechanism for mid-handshake parameter renegotiation of this kind. The RFC notes that some operators still use 1024-bit groups because that is the maximum size with broad implementation support, leaving a security margin of only a few hundred bits above the current discrete logarithm record of 795 bits. This is not a theoretical concern.
The Raccoon attack (Merget et al., 2021) sharpened the urgency. By exploiting timing differences in how TLS implementations process the leading zero bytes of a DH premaster secret, an attacker positioned to make repeated connections can reconstruct the premaster secret. Non-ephemeral DH is inherently vulnerable because the server's static key is reused across all connections. Ephemeral DHE is vulnerable whenever the server reuses its ephemeral key, a practice that was common as a performance optimisation. RFC 10015 strengthens the existing SHOULD NOT to a MUST NOT for both variants, removing any ambiguity about whether key reuse is permissible.
RSA Key Exchange: Structural Problems, Not Just Implementation Bugs
The RFC's treatment of RSA key exchange is equally unambiguous. The core issue is that RSA key exchange in TLS works by having the client encrypt a random premaster secret under the server's public key. This provides no forward secrecy by construction: anyone who later obtains the server's private key can decrypt all previously recorded sessions. This has been understood for decades, but the formal deprecation had not previously been issued.
The more acute problem is Bleichenbacher's attack, first published in 1998. The attack exploits the PKCS#1 v1.5 padding scheme used in RSA encryption to mount an adaptive chosen-ciphertext attack, recovering the plaintext through a series of oracle queries. The countermeasure, constant-time padding validation with a synthetic random premaster secret on failure, is notoriously difficult to implement correctly. The ROBOT disclosure in 2017 found that a significant fraction of major TLS deployments remained vulnerable nearly two decades after the original attack was published. Subsequent variants (NEW-BLEI, DROWN) demonstrated that the vulnerability space is larger than a single implementation bug: cross-protocol attacks via SSLv2 and shared key material across endpoints mean that a single vulnerable server can compromise connections to entirely separate services.
RFC 10015 also highlights a TLS 1.2-specific aggravating factor: the absence of any domain separation mechanism for RSA keys. A key used for both authentication and key exchange, shared across multiple virtual hosts or services, creates a situation where one vulnerable endpoint weakens all others sharing that key. TLS 1.3 avoids this by removing static RSA key exchange entirely and using separate key material for authentication and session establishment.
The Nuanced Position on Static ECDH
The RFC's handling of non-ephemeral ECDH is slightly softer than its treatment of FFDHE and RSA. The MUST NOT language is not applied here; instead, the existing SHOULD NOT from RFC 9325 is preserved, but the IANA registry entries are updated from "N" (not recommended) to "D" (deprecated) to align with the new registry semantics introduced by RFC 9847. The RFC explains the rationale carefully.
Static ECDH shares the forward secrecy problem of all non-ephemeral key exchange. Beyond that, key reuse in ECDH opens a family of attacks that exploit the static nature of the key to extract it incrementally. Invalid curve attacks, demonstrated practically against real TLS implementations, work by submitting points not on the specified curve; if the server processes these without validation, repeated queries can reveal the private key. Side-channel and fault attack variants extend this further. The RFC cites specific practical demonstrations (ICA, MAY4, PARIS256) to ground the analysis in demonstrated rather than merely theoretical risk.
The decision not to escalate to MUST NOT for ECDH likely reflects the relative scarcity of static ECDH deployments compared to RSA and DHE, combined with the fact that the attack surface, while real, requires a more capable adversary than the Bleichenbacher oracle or Raccoon timing channel.
Operational and Ecosystem Implications
The practical impact of RFC 10015 depends heavily on how quickly TLS library maintainers and operators respond. Several observations are worth making:
- Major TLS libraries (OpenSSL, BoringSSL, NSS, mbedTLS) have already been moving in this direction. BoringSSL removed static RSA key exchange support years ago. OpenSSL deprecated DHE cipher suites in 3.x. RFC 10015 provides the formal IETF mandate that enterprise and compliance frameworks require before removing support.
- The MUST NOT language creates a compliance obligation, not merely guidance. For organisations operating under frameworks that reference BCP 195 (which now includes RFC 10015 via its updates to RFC 9325), continued use of deprecated cipher suites is a policy violation, not just a best-practice gap.
- The update to RFC 9325 (Table 6 in the document) is precise: non-ephemeral FFDH moves from SHOULD NOT to MUST NOT, ephemeral FFDH moves from SHOULD NOT to MUST NOT, and static RSA moves from SHOULD NOT to MUST NOT. Fixed DH certificate types, previously unspecified in RFC 9325, are now explicitly SHOULD NOT.
- DTLS 1.2 is explicitly in scope. This matters for IoT and real-time communication deployments that have been slower to migrate than web-facing TLS infrastructure.
One limitation worth noting is that RFC 10015 does not address the question of what TLS 1.2 cipher suites remain acceptable. That positive guidance remains in RFC 9325. The document is purely a deprecation instrument, which is appropriate given its scope, but operators looking for a complete picture of compliant TLS 1.2 configuration still need to read both documents together.
Where This Leaves TLS 1.2
After RFC 10015, the only cipher suites remaining recommended for TLS 1.2 are those built around ECDHE key exchange, specifically the ECDHE-RSA and ECDHE-ECDSA families with AEAD ciphers (AES-GCM, ChaCha20-Poly1305). This is a small, well-understood set. The effect is to make TLS 1.2 look, from a key exchange perspective, much closer to TLS 1.3, which supports only ephemeral key exchange modes.
The broader trajectory is clear. RFC 8996 removed TLS 1.0 and 1.1. RFC 10015 removes the cryptographically weak key exchange methods from TLS 1.2. The remaining path for the protocol is either continued operation with ECDHE-only cipher suites or migration to TLS 1.3. Given that TLS 1.3 also removes renegotiation, compression, and a range of other legacy mechanisms that have generated vulnerabilities, the case for migration rather than continued TLS 1.2 operation is strong.
RFC 10015 is not a dramatic technical announcement; the attacks it cites have been known for years. Its value is administrative and normative: it converts accumulated cryptographic consensus into formal protocol requirements, updating the IANA registry and 17 existing RFCs in a single coherent action. For security engineers maintaining TLS configurations, it provides the formal citation needed to justify removing these cipher suites from production systems. That kind of consolidation, unglamorous as it is, is how protocol security actually improves at scale.