up:: In the Protocols MOC

MLS (Messaging Layer Security)

MLS, Messaging Layer Security, is the IETF standard for end-to-end-encrypted group messaging, published as RFC 9420 in July 2023. It solves the hard problem that pairwise protocols like Signal do not: agreeing on a shared group key among anywhere from two to thousands of members who may never be online at the same time, and keeping that key fresh as people join and leave. The mechanism at its core is a ratchet tree running a scheme called TreeKEM, which lets any member update the group key by encrypting to just the tree paths that need it, so a key change costs logarithmic work instead of one encryption per member. MLS does all of its public-key encryption through HPKE, and that is exactly where its post-quantum story lives: swap HPKE’s KEM slot for an ML-KEM KEM and the group key agreement inherits quantum resistance.

Source: R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon, “The Messaging Layer Security (MLS) Protocol,” RFC 9420, July 2023, rfc-editor.org/rfc/rfc9420.

The short version:

• MLS is the standardized way to run end-to-end encryption for a group, scaling from a pair to thousands of members, with forward secrecy and post-compromise security built in. RFC 9420 is a Standards Track document, unlike the Signal and Apple protocols, which are vendor specifications.
• The engine is a ratchet tree using TreeKEM. Arranging members as leaves of a binary tree lets an update reach everyone with about log(N) encryptions instead of N-1, which is what makes large-group rekeying affordable.
• Every public-key operation in MLS is an HPKE operation. The group’s ciphersuite names the KEM, KDF, and AEAD that HPKE uses, so the cryptographic slots are explicit and swappable.
• MLS gives forward secrecy and post-compromise security by having members periodically update their keys, so a stolen key stops decrypting past traffic and stops helping the attacker after the next update.
• RFC 9420 ships with classical elliptic-curve ciphersuites, so a stock MLS deployment is not post-quantum. The path to PQC is a ciphersuite whose HPKE KEM is ML-KEM, carried through the same TreeKEM machinery.

Picture a phone tree for a large organization, redrawn as a balanced pyramid instead of one long chain. When a single person needs to push a new secret to everyone, they do not call all thousand members one by one. They hand it up their branch of the pyramid, and it fans out down the other branches, so the number of calls grows with the height of the pyramid rather than its width. TreeKEM is that pyramid built out of encryption keys. A member who changes the group secret encrypts the update only to the handful of sub-branches that sit along their path, and every other member derives the new secret from what they already hold. That structure is why a group of thousands can rekey without the cost exploding.

What is MLS?

MLS is an IETF Standards Track protocol, RFC 9420, for establishing and maintaining a shared cryptographic key across a group so the group can exchange end-to-end-encrypted messages. Its abstract states the target directly: MLS provides “efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.” The word “asynchronous” is load-bearing, because the hard part of group messaging is that members are rarely all online together, so the protocol has to let keys advance without requiring a live meeting of everyone.

MLS occupies a specific layer. It is the group key agreement and the ratchet, and it deliberately leaves the message transport, the membership policy, and the identity service to the application around it. That separation is why it is a standard rather than a product: many messengers can build on the same audited group-key core. The properties it guarantees are the two that matter for a group whose membership churns:

1. Forward secrecy. Compromising a member’s current keys does not expose the messages that were sent before the compromise, because the keys that protected those messages have already been ratcheted away.
2. Post-compromise security. After a compromise, once the affected member performs a key update, the attacker is locked back out and future messages are secure again, so a breach is recoverable rather than permanent.

Source: R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon, RFC 9420, abstract and §3.2, July 2023, rfc-editor.org/rfc/rfc9420.

How does the TreeKEM ratchet tree work?

The ratchet tree is what makes MLS scale, and understanding it is understanding MLS. RFC 9420 §4 defines it as “an arrangement of secrets and key pairs among the members of a group in a way that allows for secrets to be efficiently updated.” Each member sits at a leaf of a binary tree, each internal node holds a key pair, and every member knows the private keys along the path from their own leaf up to the root. The root secret is the group secret everyone shares.

The efficiency comes from that path structure. When a member wants to change the group key, they generate fresh secrets up their own path and encrypt each new secret to the subtree hanging off the sibling at that level. RFC 9420 §4 states the payoff: “encrypting to all but one member of the group requires only log(N) encryptions to subtrees, instead of the N-1 encryptions” a naive pairwise scheme would need. A member who receives such an update decrypts only the one node their leaf sits under, then derives the rest of the path up to the new root on their own.

Every one of those encryptions is an HPKE operation. RFC 9420 §5.1 makes the dependency explicit: “MLS uses HPKE for public key encryption,” and the KEM inside HPKE is what does the encapsulation to each subtree. That single sentence is the hinge for the entire post-quantum question, because whatever KEM HPKE is configured with is the KEM that protects the group’s key tree.

Source: R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon, RFC 9420, §4 and §5.1, July 2023, rfc-editor.org/rfc/rfc9420.

What primitives does an MLS ciphersuite name?

MLS bundles its cryptographic choices into a single ciphersuite that every member of a group agrees on, and knowing what that ciphersuite pins down is what makes the migration question concrete. RFC 9420 §5.1 says each session uses “a single cipher suite that specifies the following primitives,” and the set is:

Slot	Role
HPKE KEM	Encapsulates secrets to subtrees in the ratchet tree
HPKE KDF	Derives keying material from the KEM secret
HPKE AEAD	Encrypts the actual message and update payloads
Hash	Binds tree structure and transcripts
MAC	Authenticates protocol messages
Signature	Signs member commitments and identity assertions

The three HPKE slots are the confidentiality engine, and the signature slot is the authentication engine. That division matters for quantum planning because the two face the threat on different clocks: the KEM protects secrets an attacker can record and decrypt later, while the signature only helps a live attacker at the moment of forgery. The ciphersuite is where a post-quantum MLS deployment declares both its ML-KEM KEM and, eventually, its post-quantum signature.

Source: R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon, RFC 9420, §5.1, July 2023, rfc-editor.org/rfc/rfc9420.

Is MLS post-quantum?

MLS as published in RFC 9420 is not post-quantum. Its standardized ciphersuites use classical elliptic-curve primitives, so the HPKE KEM protecting the ratchet tree is an ECDH-based DHKEM that Shor’s algorithm breaks, and RFC 9420 itself does not specify a post-quantum ciphersuite. The important structural fact is that the protocol was built to make that swap clean rather than to hardcode a classical assumption.

The path to a quantum-safe MLS runs through the ciphersuite’s HPKE KEM slot. Because HPKE is defined as a swappable KEM, KDF, and AEAD, an MLS ciphersuite whose KEM is ML-KEM makes the entire TreeKEM key agreement quantum-resistant, and the tree machinery, the forward secrecy, and the post-compromise security all carry over untouched. This is the same lesson as TLS hybrid key exchange and Signal PQXDH: the confidentiality of a group’s keys migrates by changing a KEM, and it is the harvest-now-decrypt-later-urgent half. Group-message authentication, which rests on the signature slot, is the Non-HNDL half that migrates later. A CBOM for a messaging platform has to record the MLS KEM and the MLS signature separately, or it will mark a group-key-migrated deployment as finished while its member identities stay classically forgeable.

Source: R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon, RFC 9420, §5.1 and §13.1, July 2023, rfc-editor.org/rfc/rfc9420.

How does MLS relate to Signal and Apple’s PQ3?

MLS solves group key agreement as an open standard, while Signal PQXDH and Apple PQ3 are vendor protocols centered on the pairwise conversation. They are not competitors so much as different scopes, and they share the same underlying cryptographic move.

1. Scope. Signal PQXDH hardens the initial two-party key agreement, and PQ3 extends post-quantum protection into the ongoing pairwise ratchet. MLS is built for the group case, where the challenge is reaching many members efficiently rather than securing one channel.
2. Standardization. MLS is an IETF Standards Track RFC that any application can implement and interoperate on. PQXDH and PQ3 are published specifications tied to their own products.
3. The shared mechanism. All three protect confidentiality by mixing a KEM secret into their key schedule. In MLS that KEM lives inside HPKE and runs through the TreeKEM tree, which is what lets the same post-quantum swap that helps a pairwise protocol also cover a group of thousands.

Source: R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon, RFC 9420, July 2023, rfc-editor.org/rfc/rfc9420.

Common misconceptions

• “MLS is a messaging app.” MLS is the group key agreement and ratchet layer, not a product. It provides the shared group key and leaves transport, identity, and membership policy to the application built on top of it.
• “MLS is just Signal for groups.” It is a separate IETF standard with a different core, the TreeKEM ratchet tree, engineered for logarithmic-cost updates across thousands of members. Signal and Apple PQ3 are pairwise protocols published by their vendors.
• “MLS is post-quantum because it is new.” RFC 9420’s ciphersuites use classical elliptic-curve KEMs that Shor’s algorithm breaks. MLS becomes quantum-safe only through a ciphersuite whose HPKE KEM is ML-KEM.
• “Making MLS post-quantum means redesigning TreeKEM.” The tree structure stays. The change is confined to the HPKE KEM slot in the ciphersuite, so the ratchet, forward secrecy, and post-compromise security carry over unchanged.
• “Post-quantum group keys make the whole group quantum-safe.” They make the key agreement quantum-safe. Member authentication runs on the signature slot, which is a separate Non-HNDL migration that has to be tracked on its own.

Questions people ask

What is MLS? It is the IETF standard, RFC 9420, for end-to-end-encrypted group messaging, providing a shared group key with forward secrecy and post-compromise security for groups from two to thousands of members.

What is TreeKEM? It is the ratchet tree at the heart of MLS. Arranging members as leaves of a binary tree lets any member update the group key with about log(N) HPKE encryptions to subtrees instead of one per member, which is what makes large-group rekeying affordable.

Is MLS quantum-safe? Not as standardized, because RFC 9420 uses classical elliptic-curve ciphersuites whose KEM Shor’s algorithm breaks. It becomes quantum-safe through a ciphersuite whose HPKE KEM is ML-KEM.

How does MLS become post-quantum? By selecting a ciphersuite whose HPKE KEM slot holds a post-quantum KEM like ML-KEM. The TreeKEM tree and its security properties stay the same, so the migration is a KEM swap rather than a redesign.

How is MLS different from Signal PQXDH? Signal PQXDH hardens a two-party key agreement, while MLS is built for group key agreement across many members using the TreeKEM tree. Both mix a KEM secret into their key schedule, so both migrate through the same kind of KEM swap.

Does MLS give forward secrecy? Yes, along with post-compromise security. Members periodically update their keys, so a stolen key stops decrypting earlier messages and, after the next update, stops helping the attacker on future ones.

---

Everything here is the map, given freely. When your team needs its own messaging, key-exchange, and authentication surfaces sorted into what already resists a harvesting quantum adversary and what still has to move, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.