IETF MLS draft splits eleven quantum suites into two promises

The Quantum Door Has a Classical Lock in Eight MLS Suites

Why it matters

An IETF draft offers eleven new cipher suites for secure group messaging. Eight use post-quantum key encapsulation but keep traditional signatures; three add ML-DSA signatures. The November revision now spells out what a forged classical signature could do to a later group epoch, and exactly which key bytes the ML-DSA suites put on the wire.

Daniel Kade3 November 2026 at 19:30 UTCReading Time 3 minLast update: 3 November 2026

Eight proposed MLS suites protect key exchange but retain classical signatures; three add ML-DSA. Conceptual editorial illustration based on IETF draft revision 07.

Summary

The IETF's 1 November revision 07 requests eleven Messaging Layer Security cipher-suite entries. The first eight combine a post-quantum or hybrid KEM with a traditional signature; the final three use ML-DSA signatures as well.
Revision 07 adds a precise ML-DSA wire rule: an MLS signature public key is the algorithm's pkEncode bytes, the signature is the direct ML-DSA output, and MLS SignContent carries the label while ML-DSA's context parameter is empty.

The convenient phrase “post-quantum MLS” hides two different promises. A July revision already separated the proposed suites by signature type. The November text makes the consequence harder to miss: suite IDs 0x0010 through 0x0017 use ML-KEM or a hybrid KEM for key encapsulation, while retaining Ed25519 or ECDSA signatures. They address a passive adversary collecting ciphertext now to decrypt later. Their authentication still rests on classical signatures.

The draft names the failure path. If an attacker can forge those traditional signatures, or the credentials that bind signing keys to identities, the attacker can inject a KeyPackage or a group operation. That can compromise confidentiality in later MLS epochs. The lock on yesterday's captured messages and the authority to shape tomorrow's group state sit on different algorithms. A product claiming the stronger property has to identify its actual cipher suite, not merely say that ML-KEM appears somewhere in the stack.

The other three requested entries, 0x0020 through 0x0022, add ML-DSA signatures. The first of those pairs ML-DSA-44 with a hybrid ML-KEM/X25519 KEM and ChaCha20-Poly1305; the other two use ML-DSA-65 or ML-DSA-87 with pure ML-KEM. In revision 07, the authors also pin down their byte-level contract. Under the MLS specification, RFC 9420, SignaturePublicKey is a protocol field. For ML-DSA it must contain pkEncode output, rather than a SubjectPublicKeyInfo wrapper. SignWithLabel signs serialized SignContent; the ML-DSA ctx is empty because the MLS label inside that content already separates the signing purpose. A sender and verifier that choose different wrappers or contexts will disagree even if they display the same suite name.

The IETF tracker records revision 07 as an active draft in Publication Requested state, intended for Proposed Standard. The public record does not yet list an approved RFC or measured application deployment; a named implementation and interoperable test would show whether these exact bytes and suite claims survive contact with software.