The terms on this page
- ML-KEMModule-Lattice-based Key Encapsulation Mechanism
- the standardised post-quantum replacement for RSA and ECDH key exchange, published as FIPS 203
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab) are defined in the glossary.
Read this first
The RFC Editor placed draft-ietf-tls-mlkem-11 on Stream Hold on 24 September 2026 while IETF working-group chairs and the responsible area director review complaints and appeals about how the document was processed. The hold pauses publication of the standalone ML-KEM TLS specification. It is not a finding that ML-KEM is broken, and it does not change RFC 10024, the separate hybrid X25519MLKEM768 specification already used in deployments.
The IETF's document history records two linked changes on 24 September: the RFC Editor state moved from In Progress to Blocked, and its production status became blocked: Stream Hold. The accompanying note says the TLS working-group chairs and area director received complaints or appeals about the document's processing and are holding it in the RFC Editor queue while they review them.
That is a publication-process event, not a cryptographic verdict. The current version 11 draft still defines standalone ML-KEM-512, ML-KEM-768 and ML-KEM-1024 as TLS 1.3 Supported Groups. Its technical text has not been replaced by a new revision since 16 September, and the Datatracker still lists the intended RFC status as Informational.
What stopped, and what did not
| Item | Status after 24 September | Practical meaning |
|---|---|---|
| draft-ietf-tls-mlkem-11 | Blocked: Stream Hold | RFC publication waits while the complaints and appeals are reviewed |
| FIPS 203 ML-KEM | Unchanged | The NIST algorithm standard remains final |
| RFC 10024 X25519MLKEM768 | Unchanged | The hybrid TLS specification remains published |
| Existing experimental implementations | Not automatically withdrawn | Operators still have to follow their own risk, compatibility and support gates |
The distinction matters because the held draft is about standalone ML-KEM key establishment. RFC 10024 specifies the hybrid X25519MLKEM768 group, combining an X25519 share with ML-KEM-768. A hold on the standalone document does not amend, obsolete or suspend that RFC. Our TLS hybrid key-exchange reference now records this boundary explicitly.
FIPS 203 is also outside the dispute. NIST's ML-KEM standard defines the key-encapsulation algorithm and parameter sets. The IETF draft concerns how standalone ML-KEM parameter sets are carried and negotiated in TLS 1.3. Algorithm standardization and protocol publication are separate layers, even when they use the same names.
The complaints challenge the standalone choice and the process
The linked public complaints argue that publishing standalone post-quantum groups throws away the classical half of a hybrid construction and that the working group did not adequately resolve objections to that choice. One filing frames the dispute as a TLS working-group charter issue. Another argues that implementation bugs in new post-quantum software make retaining the classical component a practical hedge.
A complaint is not a decision
Those claims are the complainant's position. The Stream Hold confirms that the process is under review; it does not confirm the complaint's technical conclusions. Until the responsible IETF bodies publish an outcome, avoid describing the draft as rejected, unsafe, withdrawn or approved without qualification.
IETF conflict procedures deliberately separate an objection from its resolution. RFC 2026 section 6.5 describes review and escalation paths for working-group disputes, including review by area directors, the IESG and, if needed, the IAB. The Datatracker does not yet record a final outcome for these complaints.
What migration teams should change now
- Label standalone ML-KEM TLS support as draft-based and pin the exact revision in test evidence. Do not present an anticipated RFC number or publication date as settled.
- Keep hybrid X25519MLKEM768 evidence separate from standalone ML-KEM evidence. A successful hybrid negotiation does not prove that a standalone group is enabled, and the Stream Hold does not invalidate the hybrid result.
- Record why a deployment needs standalone ML-KEM rather than hybrid key exchange. Compliance profiles, peer requirements and interoperability constraints should be explicit rather than inferred from an algorithm name.
- Watch the Datatracker history and the linked TLS mailing-list record for the review outcome. Recheck the document version, status and IANA references before promoting a prototype.
- Preserve a rollback path and representative interoperability tests. A standards-state change is one more reason not to couple migration evidence to a single experimental code path.
For most internet-facing teams, this reinforces the staged approach in our hybrid TLS migration guide: inventory termination points, offer a classical fallback, capture the negotiated group, and test the real path. It does not justify switching off working hybrid protection while the IETF reviews a different document.
For environments considering standalone ML-KEM, the immediate task is governance. Add the Stream Hold to the decision record, state which requirement cannot be met by hybrid TLS, and keep the implementation behind the organization's normal change and post-quantum audit gates. A draft can still be useful test material without being treated as a finished deployment contract.
The next reliable signal is the recorded outcome
The meaningful next event will be an IETF status change or published resolution, not speculation about how long the hold might last. The document previously reached the RFC Editor queue after IESG approval, so the hold is consequential. But its duration and outcome are not stated in the record available today.
That uncertainty should appear in technical plans in plain language: standalone ML-KEM for TLS is specified in an active Internet-Draft whose RFC publication is currently blocked during review. Hybrid X25519MLKEM768 remains an RFC. Keeping those two facts together prevents both overreaction and false reassurance.
References
- IETF Datatracker history for draft-ietf-tls-mlkem, including the 24 September 2026 Stream Hold and review note.
- draft-ietf-tls-mlkem-11, the current standalone ML-KEM key-agreement specification for TLS 1.3.
- TLS working-group charter complaint, one of the public complaints linked from the document history.
- TLS working-group jeopardy complaint, the linked filing setting out the complainant's technical argument.
- RFC 2026 section 6.5, IETF conflict-resolution and appeals procedures.
- RFC 10024, the published X25519MLKEM768 hybrid key-exchange specification for TLS 1.3.