RFC 10015: The End of RSA and DH Key Exchange in TLS 1.2

The IETF has published RFC 10015, a Standards Track document that officially deprecates RSA key exchange and finite-field Diffie-Hellman (DH) key exchange in TLS 1.2 and DTLS 1.2. It also discourages the use of static Elliptic Curve Diffie-Hellman (ECDH) cipher suites. The document updates 17 existing RFCs, including the core TLS 1.2 specification (RFC 5246) and the BCP 195 recommendations (RFC 9325).

This is a major shift. For years, RSA key exchange was the default for many TLS 1.2 connections. Now, the IETF is saying: stop using it. Finite-field DH (FFDH) and ephemeral finite-field DH (FFDHE) are also deprecated. The only key exchange methods left for TLS 1.2 are ephemeral elliptic curve (ECDHE) and, for some edge cases, pre-shared keys (PSK) or other mechanisms.

The deprecation is not just a suggestion. The document uses MUST-level language: "Clients MUST NOT offer and servers MUST NOT select" these cipher suites. This is a hard requirement for any implementation that claims conformance to the updated RFCs.

Why the IETF is pulling the plug

The rationale is a list of concrete security failures, not just theoretical concerns. For RSA key exchange, the problems are well-known:

  • No forward secrecy: If a server's private key is compromised, an attacker can decrypt all recorded traffic encrypted with that key. This is by design, but it's a fatal flaw in modern security posture.
  • Bleichenbacher's attack: This padding oracle attack has resurfaced multiple times (ROBOT, DROWN, etc.) because implementing the countermeasure correctly is notoriously difficult. The document notes that "experience shows that variants of this attack arise every few years."
  • Key reuse across endpoints: There's no domain separation in TLS 1.2 for RSA keys, so a single vulnerable endpoint can compromise all endpoints sharing the same key.

For finite-field DH, the issues are more varied:

  • Interoperability problems: There's no standard way to negotiate the DH group, and some implementations only support small groups (e.g., 1024-bit). This leaves a small security margin against the current discrete log record, which stands at 795 bits.
  • Small subgroup attacks: Custom DH groups are widespread due to prior advice based on the WEAK-DH research. Clients can't easily verify that a server's chosen group doesn't have small subgroups, which enables attacks.
  • Raccoon attack: This timing side-channel exploits reused public keys, even in ephemeral cipher suites if keys are not truly ephemeral. The document explicitly mentions this.
  • Mass decryption: A few large computations against standardized groups can cheaply decrypt a large fraction of traffic, as shown by the WEAK-DH paper.

What exactly is deprecated?

The document defines four categories of cipher suites:

  1. Non-ephemeral FFDH: MUST NOT be offered or selected. This includes all suites in Table 1, such as TLS_DH_RSA_WITH_AES_128_CBC_SHA and TLS_DH_DSS_WITH_AES_256_GCM_SHA384.
  2. Non-ephemeral ECDH: SHOULD NOT be offered or selected (Table 2). This is a weakening from the MUST for FFDH, but the recommendation is clear.
  3. Ephemeral FFDHE: MUST NOT be offered or selected in TLS 1.2 (Table 3). This includes suites like TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. However, FFDHE is still allowed in TLS 1.3, where the problems are mitigated.
  4. RSA key exchange: MUST NOT be offered or selected (Table 4). This includes TLS_RSA_WITH_AES_128_CBC_SHA and similar.

Additionally, the document deprecates the ClientCertificateType identifiers for fixed DH certificates: rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, and ecdsa_fixed_ecdh. Clients should not use, and servers should not accept, certificates with fixed DH parameters.

The IANA registry will mark these as "D" (deprecated) in the "Recommended" column, with a reference to RFC 10015.

Practical impact for developers

If you maintain a TLS 1.2 implementation, a library, or a server configuration, you need to act now:

  • Remove deprecated cipher suites from your default configuration. For example, in OpenSSL, you can use the CIPHERSUITES or ciphersuites directive to restrict to ECDHE. A typical configuration might be:

    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

  • Audit your certificate types: If you're using static DH certificates, switch to ephemeral key exchange. You'll need to generate new certificates without fixed DH parameters.

  • Update your TLS library: The major libraries (OpenSSL, BoringSSL, NSS, etc.) will likely update their defaults to reflect this RFC. Keep an eye on their release notes.

  • Test for compatibility: Some legacy clients may still attempt to use RSA key exchange. You'll need to decide whether to break those connections or maintain a separate configuration for legacy support.

The bigger picture

This RFC is a continuation of the IETF's push toward forward secrecy. It follows the deprecation of TLS 1.0 and 1.1 (RFC 8996) and the recommendation to use TLS 1.3. The message is clear: use ephemeral key exchange, preferably ECDHE, and move to TLS 1.3 if you can.

For developers, the immediate takeaway is to review your TLS configurations and remove any RSA or DH cipher suites. The transition may be painful for legacy systems, but the security benefits are undeniable. As the document states, "the problems affecting FFDHE in (D)TLS 1.2" are numerous, and the same applies to RSA. It's time to move on.

What you should do now

  1. Check your server's cipher suite list using tools like sslscan or nmap --script ssl-enum-ciphers. Remove any suite that starts with TLS_RSA_, TLS_DH_, or TLS_DHE_.
  2. Update your TLS library to the latest version that implements RFC 10015. For OpenSSL, that's likely version 3.x or later.
  3. Plan for TLS 1.3 migration: TLS 1.3 does not support RSA key exchange or FFDH, so moving to it eliminates the problem entirely.
  4. Monitor your logs for clients that fail after you remove deprecated suites. You may need to maintain a temporary fallback for compatibility, but do so with a clear deprecation timeline.

RFC 10015 is a strong signal: the era of RSA key exchange in TLS is over. Embrace ephemeral key exchange and forward secrecy.