Summary

  • RFC 10015 says TLS 1.2 and DTLS 1.2 clients must not offer, and servers must not select, several obsolete finite-field Diffie–Hellman and static RSA key exchanges. Static ECDH and fixed-DH client certificate types remain “should not”, a distinction that operations must preserve.
  • IANA’s D flag records a standards judgment. It does not demonstrate that code, configuration, reloads, edge listeners, client offers, server choices or exception paths have changed. A deprecation-closure receipt can join those separate facts.

The registry row had changed. The security dashboard turned green. Yet one forgotten TLS terminator behind an old hostname could still negotiate the suite that the dashboard now called “deprecated”. Nothing in the colour change had touched that process.

That is the governance problem exposed by RFC 10015. The document is a Standards Track update to the security posture for TLS 1.2 and DTLS 1.2 key exchange. It sharpens the normative answer to a well-understood set of cryptographic risks. It does not claim to measure deployments, remove implementations or verify a fleet. A standards state and a running state are different objects.

The distinction matters because registry metadata is unusually easy to automate. A compliance system can ingest an IANA table, see D, map it to a policy rule and mark a control complete. That workflow is useful only if “complete” means that the policy source was updated. If it is taken to mean that no exposed endpoint can offer or select the mechanism, the dashboard has promoted a classification into a measurement.

The standard did not retire one undifferentiated thing

RFC 10015 deals with several families, and its verbs are not interchangeable. For TLS 1.2 and DTLS 1.2, clients MUST NOT offer and servers MUST NOT select non-ephemeral finite-field Diffie–Hellman suites. The same prohibition applies to ephemeral finite-field DHE suites in those protocol versions. Static RSA key-exchange suites are also MUST NOT offer/select.

Static ECDH suites have a different status: SHOULD NOT. The fixed Diffie–Hellman client certificate types covered by the document are also SHOULD NOT. An exception to a SHOULD NOT needs a reason that survives review, but it is not semantically identical to violating a MUST NOT. A control that flattens both into the same red cell destroys information that the standard deliberately retained.

The version boundary is equally important. RFC 8996 had already deprecated TLS 1.0 and TLS 1.1. RFC 5246 defines TLS 1.2, while RFC 8446 redesigned key agreement for TLS 1.3. RFC 10015 explicitly allows finite-field ephemeral Diffie–Hellman in TLS 1.3; the TLS 1.2 weaknesses it addresses do not make every FFDHE use in every version forbidden. RFC 7919 remains part of the history and mechanics of negotiated finite-field groups.

Static RSA key exchange also must not be confused with every use of RSA. A service may use an RSA certificate and an RSA signature in a protocol configuration that does not use static RSA key transport. Searching certificate inventories for the word “RSA” therefore answers the wrong question. The evidence must identify the negotiated key-exchange path.

The cryptographic reasons are not decorative. Non-forward-secret methods expose past sessions if a long-term key is later compromised. Reused finite-field DH keys bring timing and group-selection hazards; reused ECDH keys carry invalid-curve, side-channel and fault risks. Static RSA retains the long record of Bleichenbacher-class failure modes and creates damaging key-reuse and cross-protocol possibilities. RFC 9325 and RFC 9847 sit in the wider IETF effort to keep deployed TLS guidance aligned with accumulated evidence rather than with historical availability.

What the D flag proves

The IANA TLS Parameters registry now marks the affected cipher suites and four ClientCertificateType values with D in the Recommended column and cites RFC 10015. In IANA’s notation, D means discouraged. The precise normative strength comes from the referenced specification; it can reflect SHOULD NOT or MUST NOT.

That flag proves a bounded fact: the public registry’s recommendation state. It can drive linters, code review, procurement policy and migration queues. It cannot prove any of the following:

  1. the cryptographic library no longer implements the suite;
  2. the product’s shipped default no longer enables it;
  3. the local configuration removed it;
  4. the active process loaded that configuration;
  5. every listener, SNI name, proxy, load balancer and regional edge received the rollout;
  6. clients stopped offering it;
  7. servers stopped selecting it;
  8. no exception route or rollback image can restore it.

These are not variations of one fact. They are successive control surfaces with different owners and clocks.

Capability, offer, selection and observation

Four states deserve separate columns. Capability means code can perform the exchange. Offer is what a client puts into a particular handshake. Selection is what a server chooses from that offer. Observation is what a scanner or telemetry system happened to see.

A library can remain capable while policy prevents all offers. A server configuration can mention an obsolete suite yet never select it because a stronger rule wins. A probe can see no selection while missing an SNI-specific listener, a UDP DTLS service, an internal edge or a conditional legacy route. Conversely, a controlled negative test that deliberately offers only the prohibited family can establish much more than a normal modern-client connection, but only for the termination point and configuration path that it reached.

DTLS 1.3 in RFC 9147 reinforces why the inventory must include protocol and transport. A TLS-only scan of TCP listeners cannot close a DTLS control. Nor does a global configuration file prove what a managed appliance, embedded terminator or separately administered reverse proxy loaded.

Make deprecation a closure exercise

The useful artifact is a deprecation-closure receipt for each exposed service. Its first section names the RFC item, registry identifier, protocol version and normative strength. This prevents a static-ECDH SHOULD NOT from silently becoming the same exception class as a static-RSA MUST NOT, and prevents a TLS 1.3 FFDHE configuration from being removed merely because its name resembles the TLS 1.2 family.

The second section identifies the effective control point: repository or configuration authority, committed version, rendered policy, software build, container or appliance release, listener, SNI name, address, port, transport and upstream proxy. “Fleet policy updated” is not enough when termination is distributed.

The third section records activation: restart, reload, hot-policy refresh or managed rollout; time; change identifier; target population; completed population; failed targets; and rollback version. A file diff is evidence of intent. Process identity and loaded-policy evidence are closer to execution.

The fourth section records behaviour. A negative offer probe presents only the prohibited choice and expects refusal. A selection probe exercises realistic alternatives and records the negotiated result. Telemetry looks for offers and selections across time, but retains coverage boundaries and sampling loss. The receipt never converts “not observed” into “impossible”.

The final section owns exceptions and dependants. It names the client, business function, scope, compensating control, accountable owner, approval, expiry and exit test. It records the dependent client’s migration and the removal of the compatibility path. An exception without an expiry is not a bridge; it is a second policy.

This receipt is Daniel Kade’s governance proposal, not a requirement imposed by RFC 10015. Its purpose is to keep a machine-readable standards change from becoming a machine-generated fiction about deployment.

A safer automation verdict

Security automation should report the strongest fact it can support: “registry deprecated”, “configuration removed”, “reload verified”, “negative probe refused”, “no selection observed within stated coverage”, or “exception expired”. It should not compress those into “disabled” unless all relevant termination paths have closed.

That vocabulary also improves incident response. If a prohibited selection appears, the team can locate whether the failure lies in the source policy, rendering, rollout, listener inventory, exception control or dependency migration. A single compliance bit offers no such route back to causality.

The standards process has done its part by naming the obsolete mechanisms and stating what conforming TLS 1.2 and DTLS 1.2 peers must or should no longer do. Operational governance begins after that sentence. The question is no longer whether the suite is discouraged. It is which running endpoint can still make the forbidden choice, and what evidence will retire that possibility.

Sources