Summary

  • On 3 September 2026, the IESG announced approval of draft-ietf-tls-mlkem-10 for publication as an Informational RFC. The document defines standalone ML-KEM-512, ML-KEM-768 and ML-KEM-1024 as TLS 1.3 NamedGroups; no RFC number had yet been assigned in the reviewed record.
  • All three proposed registry rows say DTLS-OK=Y and Recommended=N. Under RFC 9847, N is neither an endorsement nor a finding that the mechanism is flawed or discouraged. Publication, registration, recommendation, local configuration and observed operation require separate receipts.

The most consequential character in the newly approved ML-KEM document is not a lattice parameter or a hexadecimal code point. It is the letter N.

The IESG announced on 3 September that revision 10 of ML-KEM Post-Quantum Key Agreement for TLS 1.3 had been approved for publication as an Informational RFC. The document gives three standalone ML-KEM parameter sets a complete TLS 1.3 mapping. Yet its IANA table leaves every Recommended cell at N.

Those facts coexist without contradiction. Approval says the document may proceed to publication in the IETF stream. The registration gives implementations stable numbers and shared wire semantics. The recommendation column answers a different question: has the IETF made a suitability recommendation for the item? In this case, it has not.

The distinction begins on the wire. ML-KEM is a key encapsulation mechanism with three relevant operations. KeyGen creates a public encapsulation key and a secret decapsulation key. Encaps takes the public key and produces a ciphertext plus a shared secret. Decaps takes the secret key and ciphertext and recovers the same shared secret.

The approved draft maps that asymmetric exchange onto the existing TLS 1.3 supported_groups and key_share extensions. Values 512, 513 and 514 identify MLKEM512, MLKEM768 and MLKEM1024. In the ClientHello, the client's key share contains the public encapsulation key. In the ServerHello, the server's key share contains the ciphertext. The recovered 32-byte secret enters the TLS key schedule where the (EC)DHE shared secret would ordinarily go.

That is a real interoperability contract. It specifies fixed lengths and failure behavior. For ML-KEM-512, the public key is 800 bytes and the ciphertext 768 bytes. The corresponding figures are 1,184 and 1,088 bytes for ML-KEM-768, and 1,568 bytes for both fields in ML-KEM-1024. All three produce a 32-byte shared secret.

The server must perform the FIPS 203 encapsulation-key check and abort with illegal_parameter if it fails. The client must reject a ciphertext whose length does not match the selected parameter set with the same alert. Other decapsulation failures end the connection with internal_error. The transcript includes the key-share fields, binding the encapsulation key and ciphertext into the handshake and addressing the re-encapsulation attack considered by the document.

None of this makes implementation quality automatic. The draft forbids reuse of ciphertext-generation randomness and therefore forbids ciphertext reuse. It also calls out a less obvious exposure: the peer holding the decapsulation key recovers the encapsulation randomness exactly. If a generator is insecure and that output reveals information about other outputs or internal state, the peer gains that information.

FIPS 203 defines the algorithm; NIST SP 800-227 and RFC 8937 provide implementation and randomness guidance. They do not attest to a particular TLS library, build, process fork, entropy source, hardware module or deployment. Formal analysis of the protocol construction is evidence about the construction under its assumptions, not a production receipt for every implementation that carries the name.

The registry makes a second set of distinctions. In the live IANA TLS Supported Groups table reviewed on 5 September, values 512, 513 and 514 were already present. Each row said DTLS-OK=Y and Recommended=N. The reference column still pointed to revision 05 of the earlier individual draft, while Datatracker showed revision 10 approved and IANA action in progress. That is a dated projection state, not a permanent criticism; the reference can change when IANA completes its work.

DTLS-OK=Y and Recommended=N describe different dimensions. The first says the group is suitable for use in DTLS under that registry field. It does not mean the IETF recommends enabling the group in a fleet. A two-column dashboard that compresses both values into one green badge would erase the very decision the registry preserves.

RFC 9847 gives Recommended three possible meanings. Y records IETF consensus that the item is recommended and fit for its defined purpose, subject to any stated limits. D says the item is discouraged and requires a reason in the reference or comment. N says the IETF has made no statement about suitability. It may reflect absence of consensus, limited applicability or usage constraints. It does not necessarily mean the mechanism is flawed.

That vocabulary prevents two symmetrical governance errors. The first is recommendation laundering: an organization reads “IESG approved” or sees an assigned code point and turns it into “IETF says deploy this by default.” The second is prohibition laundering: another organization reads N and turns it into “IETF says this is unsafe.” Neither conclusion is present in the record.

The comparison with hybrid TLS groups clarifies the point without deciding it. RFC 10024 defines combinations of ML-KEM and traditional elliptic-curve exchange. In the current IANA table, X25519MLKEM768 is marked Y, while other hybrid rows are N. The standalone draft explicitly tells implementers to evaluate their own security, performance and operational constraints when choosing standalone ML-KEM or a hybrid construction. It does not create one universal answer.

A responsible deployment record therefore needs more than a standards citation. It should preserve the document revision and registry snapshot consulted; the library and cryptographic-module build; RNG source, reseed and fork controls; configured group list and priority at every termination point; ClientHello offers and key shares; ServerHello selection; parameter-check and abort telemetry; a completed handshake; and an application request and response.

These receipts answer different questions. Configuration shows intent, not traffic. A ClientHello offer shows client capability or policy, not server selection. A ServerHello records a selected group, not a completed handshake. A handshake proves neither application continuity nor authorization. An application probe says nothing about fleet coverage unless the population and observation window are recorded.

Heng Lu's running-code doctrine is useful because it does not ask a registry to make the operator's decision. The minimum shared specification should be strong enough to coordinate bytes and failure behavior. The local actor that carries compatibility, capacity and security consequences should own enablement, exception and rollback. Reality-layer discipline then stops the approved document, registry row and successful canary from collapsing into one claim.

The approved draft has done important work. It has made three standalone post-quantum exchanges describable and negotiable inside TLS 1.3. The restraint is equally important. Three code points can be real, the wire format can be complete and the publication decision can be final while the recommendation remains N. The empty recommendation is not a void to fill with institutional prestige. It is the place where accountable local judgment begins.

Sources