Summary

  • RFC 10015 says TLS and DTLS 1.2 clients must not offer, and servers must not select, finite-field DH and RSA key-exchange suites. Static ECDH is discouraged with a weaker SHOULD NOT.
  • The rule is version-specific: FFDHE remains permissible in TLS and DTLS 1.3. An RSA certificate may still authenticate an allowed ephemeral exchange; it is RSA key exchange, not the certificate label alone, that the RFC prohibits.
  • An RFC and an IANA D marker establish a common rule but do not edit runtime configuration. Completion requires inventory, canary negotiation, failure evidence, scoped exceptions and drift control at every termination point.

A successful connection that should no longer be possible

Picture a compatibility dashboard on the morning after a TLS hardening change. Ninety-nine per cent of handshakes are green. One old client still connects over TLS 1.2. Its certificate validates, the application responds and no alert fires. The success is reported as evidence that the migration preserved continuity.

The negotiated suite used RSA key exchange.

Under RFC 10015, published on the Standards Track in July 2026, that is not a harmless legacy success. For TLS or DTLS 1.2, the client must not offer and the server must not select an RSA key-exchange cipher suite. The same prohibition applies to finite-field ephemeral DH suites in 1.2, and the document separately prohibits non-ephemeral finite-field DH. Static ECDH receives a strong warning, but not the same absolute command.

The distinction matters because a version counter cannot see it. “TLS 1.2 accepted” describes a protocol envelope. It does not say which party authenticated, how the shared secret was established, whether the exchange was ephemeral, which group was used, or whether a supposedly removed suite remains reachable through a proxy override.

RFC 10015 therefore creates a retirement boundary inside a protocol version, not around it.

Four names that cannot be flattened into “old TLS”

TLS 1.2 accumulated a large cipher-suite catalogue. The suite name combines several decisions that operational dashboards often collapse. Certificate authentication is one decision. Key exchange is another. Bulk encryption and integrity are others. The negotiated protocol version supplies a further context.

The RFC distinguishes four DH families. FFDH is non-ephemeral finite-field Diffie-Hellman: a static DH public key is carried in the authenticating certificate. FFDHE is the ephemeral finite-field form: handshake messages carry a temporary public value authenticated by the certificate. ECDH and ECDHE make the analogous distinction over elliptic curves.

For TLS and DTLS 1.2, the normative split is exact:

  • clients MUST NOT offer and servers MUST NOT select non-ephemeral FFDH suites;
  • clients SHOULD NOT offer and servers SHOULD NOT select non-ephemeral ECDH suites;
  • clients MUST NOT offer and servers MUST NOT select FFDHE suites;
  • clients MUST NOT offer and servers MUST NOT select RSA key-exchange suites.

The document also says clients should not use and servers should not accept the fixed certificate types rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh and ecdsa_fixed_ecdh. Those certificate-type identifiers apply to (D)TLS 1.2 and below.

This is not a licence for string-based surgery. An RSA public key in a server certificate can authenticate ECDHE while the premaster secret comes from the ephemeral exchange. Disabling every suite or certificate containing the token “RSA” would retire a larger surface than the RFC defines. Conversely, leaving TLS_RSA_* suites enabled because the certificate is current would preserve the prohibited exchange.

The protocol version is equally decisive. RFC 10015 expressly says FFDHE may still be offered in TLS and DTLS 1.3. The 1.3 construction does not inherit the problems that led the document to retire the 1.2 suites. A configuration engine that disables “DHE everywhere” would erase that boundary and could reduce a modern deployment's legitimate choices.

Why finite-field ephemerality was not enough in 1.2

Ephemeral keys normally improve the story because compromise of a long-term authentication key should not reveal past session secrets. Yet RFC 10015's analysis explains why TLS 1.2 FFDHE still carries a set of structural and deployment problems.

The first is group choice. Earlier TLS 1.2 deployments had no dependable way for clients to negotiate a finite-field group with the precision operators now expect. Servers commonly supplied custom groups. Verifying an arbitrary group's mathematical safety is prohibitive during a handshake, and the client has no practical fallback to another acceptable parameter set once a dangerous or unsupported group appears.

RFC 7919 later standardized named FFDHE groups and described the compatibility pressure that had kept deployments at widely supported sizes. The RFC 10015 record notes the continuing operational use of 1024-bit groups and the narrow margin between that size and published discrete-log computations. It also recalls the shared-precomputation problem: expensive work against a popular group can be amortized across many connections.

Finally, “ephemeral” in a suite name does not prove that an implementation generated and discarded a fresh secret correctly. Secret reuse can reopen timing exposure such as the Raccoon class. Non-ephemeral FFDH carries that concern by construction unless demanding constant-time mitigations succeed. The standards decision is therefore about more than a dated algorithm label; it is about an awkward combination of parameter negotiation, group verification, compatibility pressure and secret lifecycle.

RSA key exchange turns one key into a historical liability

In TLS 1.2 RSA key exchange, the client constructs the premaster secret and encrypts it to the server's RSA key. The construction has no forward secrecy. If recorded traffic and the relevant private key later meet, yesterday's confidentiality can become today's incident.

The implementation problem is just as serious. Bleichenbacher-style oracle attacks exploit observable differences in how a server processes malformed RSA ciphertext. The countermeasures are famously difficult to make indistinguishable. RFC 10015 points to the repeated return of that family through work such as ROBOT and DROWN.

There is also an authority-amplification effect. TLS 1.2 offers no convenient domain separation for these keys. If several endpoints or protocols share one RSA private key, an oracle on the weakest endpoint may affect traffic handled by the others. A certificate inventory that lists subjects and expiry dates but omits private-key reuse cannot describe that blast radius.

Retiring TLS_RSA_* negotiation is consequently not the same task as rotating a certificate. It is the removal of a secret-establishment path, followed by evidence that every reachable termination point actually stopped selecting it.

The registry records a decision; it does not execute one

RFC 10015 updates seventeen earlier RFCs and changes the status of long tables of cipher suites and client-certificate types. The IANA TLS Parameters registry now carries D in the Recommended column for the affected entries and cites the new RFC. RFC 9847 defines that marker as discouraged for new implementations or deployments.

That is valuable coordination metadata. It gives implementers, purchasers and operators a stable shared classification. It can support defaults, linting and procurement tests. It cannot reach into a running load balancer.

Between registry and handshake lie libraries, compilation options, cryptographic providers, application frameworks, environment variables, proxy layers, cloud consoles, region-specific templates, device firmware and emergency overrides. A repository may contain a perfect policy while a sidecar supplies a different cipher string. A server may stop selecting an obsolete suite while an outbound client continues to offer it. A fleet-level average can hide a small endpoint population that carries the whole residual risk.

The control question is therefore local: which configuration and executable decided this handshake? The evidence question is equally local: what did the two peers actually negotiate, and which outcome followed when a prohibited offer was the only common choice?

Build a negotiation ledger before cutting the path

Start with termination discovery. Enumerate public listeners, internal services, datagram endpoints, outbound agents, proxies, service meshes, CDN edges, appliances and embedded clients. Attach an owner to each. Record the TLS library and provider, effective cipher configuration, protocol bounds, certificate-key use, SNI and ALPN rules, deployment region and client population.

Then inventory behavior, not merely files. For a representative interval, record the negotiated version, suite and key exchange for successful sessions. Sample client offers where privacy and volume controls permit. Record failed handshakes by the first actionable boundary: no shared suite, unsupported group, certificate rejection, protocol mismatch or application failure after transport success.

The target matrix must preserve RFC 10015's asymmetry. A TLS 1.2 RSA or FFDHE negotiation is a prohibition failure. A static ECDH path is an exception requiring justification under a SHOULD NOT. A TLS 1.3 FFDHE handshake is not a violation. An RSA-signed certificate authenticating ECDHE is not RSA key exchange.

Before the production change, run deterministic canaries. A client offering only a prohibited TLS 1.2 suite should fail. A client offering an allowed TLS 1.2 ephemeral suite should succeed. TLS 1.3 should remain available. A mixed offer should select the intended modern path, not silently fall to the wrong one. Repeat the probes at every termination layer because a successful origin test says nothing about an edge that negotiates independently.

Roll out in slices that correspond to ownership: one listener class, client cohort, region or proxy tier at a time. Preserve the before/after configuration fingerprint, sample handshakes, failure distribution, rollback package and approval. Completion is not “the setting was deployed.” It is “the prohibited path is absent from observed negotiation, allowed paths still work, and the effective configuration has not drifted.”

Running code sets the truth boundary

Heng Lu's running-code primacy is especially useful here because the difference between declaration and execution is measurable. An RFC can specify an invariant. IANA can catalogue it. Neither can supply the transcript of a production handshake.

His framework of a minimum initial specification, localized future decision and voluntary adoption also prevents the opposite mistake. A thin common rule can say which 1.2 exchanges should no longer interoperate. The participating owners still decide how to inventory their clients, sequence a change, isolate a legacy dependency, select an allowed replacement and prove continuity. Local authority does not mean pretending the compatibility sets are identical. It means the decision is explicit, bounded and answerable to evidence from the code actually running.

RFC 10015 is strongest when treated neither as a decorative recommendation nor as a remote command. It is a precise compatibility boundary whose operational force begins only when each endpoint owner implements and demonstrates it.