Group chats are the last post-quantum holdout. The IETF just moved to fix that.

On November 1, a document most developers will never read was submitted to the IESG for publication as a Proposed Standard. It is called draft-ietf-mls-pq-ciphersuites-07, and it registers new cipher suites for Messaging Layer Security, the IETF standard for end-to-end encrypted group messaging. If you build messengers, this is the document that decides whether your group chats survive the post-quantum transition, or whether only your one-to-one chats do.

That split is real, and it is the reason this draft matters.

One-to-one went post-quantum years ago. Groups did not.

Signal added PQXDH, a post-quantum key agreement for one-to-one chats, in September 2023. TLS 1.3 has hybrid ML-KEM key exchange in browsers. AWS KMS shipped ML-KEM in October. The one-to-one problem is, by now, a solved engineering task with a deployment schedule.

Group messaging never got the same treatment, because groups are a different problem. In a one-to-one chat, two people agree on a key. In a group chat, fifty people need to agree on a key, members join and leave, people are offline for days, and the whole thing still has to give you forward secrecy and post-compromise security. When someone leaves the group, the keys have to rotate so they cannot read future messages. When someone's phone is compromised, the group has to heal. Doing all of that with keys that are thirty times larger than the ones you used before is not a matter of swapping one algorithm for another. It is a redesign of the plumbing.

MLS, published as RFC 9420 in 2023, is the protocol built for exactly this. It uses a structure called TreeKEM, where group members sit at the leaves of a tree and key updates travel up the tree instead of being sent to every member one by one. That is what makes it scale to groups of thousands. Until now, though, every MLS cipher suite was classical. A quantum computer that could break the key agreement would break the group.

What the draft actually registers

Version 07 of the draft defines eleven cipher suites. They come in two groups, and the difference between them is the honest part of this story.

The first eight combine a post-quantum or hybrid key encapsulation mechanism with a traditional signature algorithm. The KEM options are ML-KEM-768 paired with X25519, ML-KEM-768 paired with P-256, ML-KEM-1024 paired with P-384, and pure ML-KEM-768 or ML-KEM-1024 on their own. The signatures in these eight are classical, Ed25519 and its NIST equivalents.

That means these eight suites give you post-quantum confidentiality but not post-quantum authentication. The encryption keys are safe against a quantum attacker. The signatures that prove who sent a message are not. A future attacker with a quantum computer could forge a group member's signature. The draft says this plainly, and any honest write-up should too: these suites protect the content of your messages, not the identity of the sender.

The last three suites fix that. They pair the same KEMs with ML-DSA signatures, the post-quantum signature scheme NIST standardized as FIPS 204. Those three are fully post-quantum, key agreement and signatures alike. And version 07 changed something important here compared to earlier versions: suites with post-quantum signatures can now use a hybrid KEM as well, not only a pure post-quantum one. In earlier drafts, if you wanted ML-DSA signatures, you had to take a pure ML-KEM key agreement with them. Now you can have the hybrid too, which is the combination most careful deployments will want: ML-KEM plus a classical algorithm, so that if either one turns out to be broken, the other still holds.

The draft also changed its own standing. Earlier versions were informational, a registry entry with no expectation that anyone had to follow it. Version 07 is on the Standards Track, submitted to the IESG for publication as a Proposed Standard. That is the IETF saying this is the way group messaging goes post-quantum, not just one way.

The price is measured in bytes

None of this is free, and the cost is the part that will shape real implementations. An X25519 public key is 32 bytes. An ML-KEM-768 public key is 1,184 bytes, and its ciphertext is 1,088 bytes. An Ed25519 signature is 64 bytes. An ML-DSA-44 signature is 2,420 bytes.

In MLS, those numbers multiply. Every member publishes a key package when they join. Every group update carries new key material. In a group of a hundred people, the difference between 32-byte keys and 1,184-byte keys is the difference between a message that fits comfortably in a push notification payload and one that does not. TreeKEM keeps the scaling logarithmic instead of linear, which is why MLS can absorb this at all, but the constant factor still lands on every phone in the group, on every join, on every key rotation, on every spotty connection.

This is not a reason to avoid the migration. It is a reason to plan it as a protocol change, not a library upgrade. If your messenger treats key sizes as a fixed assumption anywhere, in message size limits, in database columns, in the way you serialize a key package, the post-quantum group chat will find that assumption and break it.

What this means if you build a messenger

I build an encrypted messenger of my own, with a post-quantum ratchet I designed myself: ML-KEM-768 for key exchange, ML-DSA-65 signatures, and group key rotation on member changes. I know this problem from the inside, because I had to solve the same pieces MLS is standardizing: what happens to the group key when someone leaves, how you rotate without breaking offline members, how you keep signatures verifiable when the signature alone is bigger than the message it signs.

So my advice to anyone building in this space is simple. Do not build your own post-quantum group protocol now. The standard is here, it is on the Standards Track, and it has already made the hard choices: which hybrids to bless, how to handle the signature question, how to keep the tree efficient when the keys get big. Your job is to watch this draft become an RFC, and to make your implementation ready for the key sizes it brings.

There are two things to do while you wait. First, measure. Take your current group implementation and run it with ML-KEM-768 key packages, and see where it breaks: message size limits, storage, the time a phone spends parsing a commit. Second, decide your position on the eight versus the three. If you adopt the hybrid suites with classical signatures, you get post-quantum confidentiality now and you accept that authentication stays classical until you move to the ML-DSA suites. That is a defensible choice, and it is probably the right one for most messengers in the next year. Just make it deliberately, and say so in your own documentation, instead of letting your users assume the word post-quantum covers everything.

The direction is set

The draft expires on May 5, 2027, and drafts can still change. The IESG review could ask for revisions. None of that changes the shape of what happened on November 1: the IETF's group messaging standard now has a post-quantum path, on the Standards Track, with hybrid and pure options and with the signature question answered honestly instead of hidden.

One-to-one chats went post-quantum in 2023. The group chat, the harder problem, the one most of us actually live in, finally has its answer on paper. Now it needs to ship.