Loading story…
The IETF has moved draft-ietf-tls-mlkem to IETF-wide Last Call, advancing a specification that defines pure ML-KEM-512, ML-KEM-768, and ML-KEM-1024 NamedGroups for key establishment in TLS 1.3. If approved, the document would become an Informational RFC and give implementers a stable reference for standalone ML-KEM in TLS, while the IANA registry would continue to mark the pure ML-KEM groups as Recommended = N and the hybrid X25519MLKEM768 group as Recommended = Y.
The proposal remains contentious after multiple Working Group Last Calls, appeals, and objections from cryptographers who argue that pure ML-KEM lacks the resilience of hybrid key exchange if one component later proves weak. The latest draft adds clarification on the meaning of the registry recommendation flag and expands security considerations around randomness exposure in ML-KEM. Despite the debate, downstream standards bodies including O-RAN, IEEE 802.11, and 3GPP have backed publication to obtain a stable post-quantum reference for their own specifications.
Track how attackers are adapting to this technology.
9 events from the most recent confirmed update back to the earliest known activity.
The IESG issued an IETF-wide Last Call for draft-ietf-tls-mlkem, which defines pure ML-KEM-512, ML-KEM-768, and ML-KEM-1024 NamedGroups for key establishment in TLS 1.3 as an Informational RFC.
Joseph Salowey requested publication of draft-ietf-tls-mlkem, moving the document forward after the working group process.
Joseph Salowey replied that the mailing list is public, rough consensus has no fixed threshold, and the chairs would not release further detailed analysis of numbers, weights, or methods.
Draft-09 was posted with clarifications including RFC 9847's definition of the IANA 'N' registry marking and new security-considerations text about ML-KEM randomness exposure.
TLS working group co-chair Joseph Salowey declared rough consensus to advance the draft after the third Working Group Last Call, despite sustained objections from some cryptographers.
Tanja Lange wrote that none of her concerns had been addressed and that she did not support publication of the draft.
The third Working Group Last Call for draft-ietf-tls-mlkem ran in the TLS working group as part of the prolonged dispute over publishing pure ML-KEM NamedGroups for TLS 1.3.
The first Working Group Last Call on the pure ML-KEM TLS draft ended with the chairs finding no consensus to publish the document.
NIST standardized ML-KEM as FIPS 203, providing the underlying post-quantum KEM referenced in the TLS draft.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
IETF RFC `10024` establishes three hybrid post-quantum TLS 1.3 key-agreement groups that combine ML-KEM with elliptic-curve Diffie-Hellman. `X25519MLKEM768` is the only group designated **Recommended** in IANA’s TLS Supported Groups registry; NIST-curve variants remain available for compliance-focused deployments. The standard formalizes an approach already used by browsers, CDNs, and TLS libraries and discourages use of earlier Kyber768 draft code points, reducing a standards barrier to mitigating harvest-now-decrypt-later exposure. Cloudflare has deployed Automatic Key Exchange to probe origin-server capabilities and select the strongest mutually supported TLS 1.3 group, prioritizing `X25519MLKEM768`. The rollout increased post-quantum traffic across scanned origins from roughly 25 billion to 45 billion daily connections, with 99.2% of post-quantum handshakes completing in one network round trip; retry-dependent handshakes fell from about 52% to 3.7%, cutting 90th-percentile handshake latency by more than 150 ms. Organizations still need origins that support `X25519MLKEM768` to receive end-to-end hybrid key-establishment protection, while post-quantum TLS authentication remains constrained by limited public WebPKI support for ML-DSA certificates and trusted roots.
Sep 13, 2026
Let's Encrypt said it will use **Merkle Tree Certificates (MTCs)** as its preferred approach for post-quantum authentication on the public web, arguing that conventional post-quantum signatures such as `ML-DSA` would make standard TLS certificate chains too large for reliable internet-scale handshakes. The model batches certificate issuance under a single signed Merkle tree head and delivers compact inclusion proofs, reducing handshake overhead while making Certificate Transparency inherent to issuance. Let’s Encrypt said current subscribers do not need to take immediate action, but future ACME clients and related tooling will need updates as the ecosystem moves toward the new format. The move aligns Let’s Encrypt with broader work by **Google, Cloudflare, Chrome, DigiCert, and the IETF**, as browser and infrastructure vendors push for scalable post-quantum TLS ahead of government migration deadlines from the NSA, NIST, and the EU. Let’s Encrypt plans a staging environment for MTC issuance in late 2026 and a production-ready deployment in 2027, while continuing to track `ML-DSA` support for traditional X.509 use cases outside the browser ecosystem. It also said the more urgent near-term defense remains post-quantum encryption against harvest-now-decrypt-later threats, urging operators to enable hybrid key exchange such as: ```text X25519MLKEM768 ```
Jun 29, 2026
Post-quantum cryptography support has been added to Python through the widely used `pyca/cryptography` library, bringing NIST-standard algorithms into the ecosystem ahead of broader migration pressure. The update introduces **ML-KEM** for key establishment and **ML-DSA** for digital signatures, giving Python developers access to standardized post-quantum primitives as organizations prepare for future quantum-era risks. Trail of Bits reported shipping the capability with funding from the **Sovereign Tech Agency**, while subsequent coverage highlighted the move as a practical step toward greater crypto agility in mainstream software. The addition is intended to help developers begin testing, integrating, and planning for post-quantum transitions now, rather than waiting for an emergency replacement cycle once quantum threats become more immediate.
Aug 10, 2026