Summary

  • On 10 September 2026, the IESG denied an appeal, released a publication hold and sent approval for draft-ietf-tls-mldsa-05, which specifies the use of the FIPS 204 ML-DSA signature schemes for authentication in TLS 1.3. Its intended RFC status is Informational; at the time checked it was still an Internet-Draft without an RFC number.
  • The live IANA TLS SignatureScheme registry contains mldsa44, mldsa65 and mldsa87 at 0x0904, 0x0905 and 0x0906. Each is marked N. Under RFC 9847, N means the IETF makes no suitability statement or has no consensus; it is not the D marker for discouragement.
  • Publication, registry allocation and deployment recommendation are therefore separate acts. The appeal decision closes a process dispute about publication; it does not choose pure versus composite ML-DSA for every operator.
  • Any adopter should issue a local deployment receipt recording the protocol surface, chosen profile, peer and certificate populations, evidence, failure limits, rollback owner and review date. A codepoint is an interoperability handle, not an instruction to turn a feature on.

One decision has finished

The IETF Datatracker history now has a clean dated event: on 10 September, the IESG denied the appeal that had held the document, released the hold and returned the draft to the approved-announcement state. The approval announcement describes a TLS Working Group product and an intended Informational RFC.

The process was not frictionless. The shepherd summary reports roughly 275 messages and characterizes support for moving forward at about four to one. It also records a real design disagreement. Some participants opposed publishing pure ML-DSA; some wanted composite schemes recommended; others supported publishing both paths. The IESG’s appeal response says it examined the Working Group Last Call feedback, found broad support, and concluded that the objections had been considered and discussed. It denied the appeal; Security Area Director Deb Cooley did not participate in that decision.

That outcome establishes the authority to publish this document. It does not convert every supportive message into an operational mandate, nor does denial of an appeal prove that every technical concern has expired. Rough consensus answers whether work may progress despite unresolved objections. A relying party still owns the consequences of enabling the mechanism in a particular certificate and peer population.

The document’s current state matters too. The Datatracker record says Approved-announcement sent, but still labels revision 05 an active Internet-Draft. Its intended status is Informational, IANA review is Version Changed - Review Needed, and IANA action remains In Progress. Until the RFC Editor assigns a number, calling it an RFC without qualification would erase a live production step.

Three names make interoperation possible

The draft’s technical contribution is narrow and concrete. It explains how ML-DSA, standardized by NIST in FIPS 204, can be negotiated for TLS 1.3 authentication through the signature-algorithm extensions. It maps three parameter sets to three TLS SignatureScheme values: mldsa44 at 0x0904, mldsa65 at 0x0905, and mldsa87 at 0x0906.

The names join two existing layers. RFC 9881 supplies the X.509 AlgorithmIdentifiers for ML-DSA-44, ML-DSA-65 and ML-DSA-87. The TLS draft tells peers what the corresponding negotiation values mean. When a value is used in CertificateVerify, signing and verification follow FIPS 204 with an empty ctx; the end-entity certificate must carry the matching AlgorithmIdentifier. The draft does not use the HashML-DSA pre-hashed variants.

These details remove ambiguity between independent implementations. They do not demonstrate that a certificate authority will issue the needed certificates, that a browser or service will accept them, that a hardware boundary handles the keys safely, or that a heterogeneous fleet can roll back after partial enablement. Syntax and wire compatibility are necessary evidence. They are not the whole deployment case.

The distinction can be seen in the live IANA registry. It already displays all three values, each with Recommended: N. The registry currently cites an earlier draft revision even while Datatracker reports IANA work in progress. The prudent description is therefore that the values are assigned and visible, while publication and reference cleanup are still moving—not that the full editorial chain has finished.

N is not a red light

The letter is easy to misread because ordinary language invites a yes-or-no interpretation. RFC 9847 defines a three-state governance field instead. Y means the IETF has consensus that an item is recommended and fit for its defined purpose, subject to its applicability limits. D means discouraged and requires a reason. N says the IETF has made no suitability statement or that no consensus exists; it may also reflect limited applicability or usage constraints.

RFC 9847 is unusually explicit: N does not necessarily mean the mechanism is flawed. Nor does an Informational publication silently turn N into Y. The registry answers whether parties can name the same mechanism and what recommendation state the IETF has recorded. It does not answer whether one bank, CDN, government gateway or experimental service should enable it tomorrow.

This separation protects both sides of the decision. Treating assignment as endorsement would make registry maintenance an accidental deployment authority. Treating N as rejection would make interoperable experimentation look non-compliant and would erase the difference between unevaluated and discouraged. The current record permits implementation and study without pretending that a universal suitability judgment has been reached.

The pure-versus-composite question remains local

The approved document describes pure ML-DSA. A separate active individual Internet-Draft describes composite ML-DSA for TLS, combining a post-quantum signature with a traditional one. Datatracker states that the individual draft has no IETF-stream endorsement. Its existence is evidence of an active design option, not evidence that the composite path has won.

An operator’s choice depends on the threat model it is prepared to defend. Pure ML-DSA avoids requiring a second signature to validate but concentrates assurance in the post-quantum scheme and its implementation. A composite design can preserve a traditional component if the new scheme or its code fails, while adding certificate, message-size, processing and interoperability costs. Those are categories to test, not a verdict this article can supply for every system.

The implementation list in the approval announcement should be read with the same discipline. Code in OpenSSL, BoringSSL, rustls-post-quantum, s2n-tls, wolfSSL, Bouncy Castle or GnuTLS can establish that engineers have built concrete paths. It does not establish default enablement, production traffic, compatible certificate chains, common configuration, acceptable latency or a tested reversal across a real fleet.

A deployment receipt closes the authority gap

The smallest useful control is not another global position paper. It is a local receipt attached to the actor that will bear the failure. The record should identify the exact TLS surface—server authentication, client authentication, a constrained private service or another bounded use—and name the chosen parameter set. It should say whether the profile is pure or composite rather than hiding that decision under the generic label “post-quantum ready.”

It should then define the population: which issuers, certificate profiles, endpoints, clients, libraries and hardware boundaries are included. Negotiation behavior belongs in the same record. What happens when a peer does not advertise the new value? Can an endpoint fall back, and under what policy? Will a partial certificate chain fail closed, fall back to another chain or route traffic elsewhere?

Evidence must be dated. Interoperability tests should cross implementation families, not merely connect two builds of the same library. Performance thresholds should include handshake size, CPU and latency at realistic concurrency. Security evidence should cover key generation, signing, verification, randomness or deterministic mode, and implementation leakage within the actual operating boundary. Certificate issuance and validation must be tested as a chain rather than assumed from a successful isolated signature.

Finally, the receipt needs an owner and an exit. It should name who can expand the rollout, who can disable it, what telemetry triggers rollback, how distributed certificates and keys are retired, when the evidence expires, and when the decision will be reviewed. None of this changes the IETF registry. It localizes the future decision to the party with the relevant system and loss function.

Evidence boundaries

No cited source shows that the three schemes are enabled by default or used for general production traffic. The sources do not establish that pure or composite ML-DSA is universally preferable. The appeal response is a process judgment, not a cryptographic proof. NIST’s standardization of ML-DSA is not a TLS deployment assessment. The live registry does not prove that IANA and RFC Editor work is complete.

The bounded finding is simpler. The IETF has authorized publication of a specification that gives three ML-DSA parameter sets interoperable meanings in TLS 1.3. Its registry deliberately retains N, a state that is neither recommendation nor discouragement. The next accountable decision belongs to each adopter, and it deserves its own evidence-bearing record.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Approval announcement for Use of ML-DSA in TLS 1.3
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — document history
  7. IESG — Response to the appeal, artifact 320
  8. IANA — Transport Layer Security Parameters
  9. RFC 9847 — IANA Registry Updates for TLS and DTLS
  10. NIST — FIPS 204, Module-Lattice-Based Digital Signature Standard
  11. RFC 9881 — Algorithm Identifiers for ML-DSA
  12. RFC 9846 — The Transport Layer Security Protocol Version 1.3
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3