For two-party end-to-end encrypted messaging, Signal Protocol has been the de facto standard for over a decade. WhatsApp, Signal, Wire, and others all use Signal Protocol or close variants. But two-party messaging is the easy case. Group messaging, where ten or a thousand or a hundred thousand people share an encrypted conversation, is much harder. Adding a member, removing a member, recovering from a compromised device, all become complex when the group is large and members come and go.
IETF RFC 9420, published in July 2023, standardizes Messaging Layer Security (MLS): a protocol for end-to-end encrypted group messaging that scales to large groups while maintaining strong security properties. MLS uses a tree-based key derivation structure that makes member changes efficient. It is being adopted by major messaging platforms and underlies new collaborative tools.
This post explains how MLS works, what its security properties are, and how the protocol is being prepared for post-quantum cryptography. For anyone building or operating secure group messaging, RFC 9420 is the modern standard.
The Group Messaging Problem
Two-party messaging has a clean solution: each party has a long-term identity key, a session is established with key exchange and a Double Ratchet for forward secrecy. Each message is encrypted with a fresh key. Loss of a key compromises only past messages from that key onward (forward secrecy) and recovery happens after the next ratchet step (post-compromise security).
Group messaging breaks this cleanly. Naive approaches:
- Pairwise: each pair of members runs Signal Protocol. Sending a group message requires N-1 separate encryptions. O(N^2) for the whole group's pairwise sessions. Expensive at scale.
- Sender keys: each sender has a key shared with the group. Adding/removing a member requires regenerating all sender keys. O(N) on each membership change.
- Tree-based: organize members in a binary tree, derive keys from the tree structure. O(log N) for membership changes.
MLS uses the tree-based approach with a specific structure called a "TreeKEM."
The TreeKEM Structure
MLS arranges group members as leaves of a binary tree. Each leaf is a member; each internal node has a key derived from its children. The root key is shared by all members and is the basis for encryption.
Concretely:
- Each leaf has a public/private key pair
- Each internal node has a public key
- Member's "direct path" to the root is the sequence of nodes from their leaf upward
- A member can derive secrets along their direct path; other members can update their copy of those secrets when changes happen
When a member is added:
- New leaf is created
- Direct path keys are updated
- Other members receive the public key updates and incorporate them
When a member is removed:
- The leaf is replaced with a "blank" node
- Affected internal nodes get fresh keys
- Removed member can no longer derive secrets along the affected path
The key insight: only members whose direct path overlaps with the change need to do work. For a balanced tree with N members, this is O(log N) work per change.
Forward Secrecy and Post-Compromise Security
MLS provides:
- Forward secrecy: compromise of current keys does not reveal past messages, because past keys have been deleted
- Post-compromise security: after a member is compromised, future messages become secure again once the member updates their leaf key
Together these are sometimes called the "double ratchet" properties for groups. The TreeKEM achieves them by regular leaf key updates ("commits") that propagate through the tree.
Epochs and Commits
MLS organizes group state into epochs. Each epoch has a specific tree structure and key set. Membership changes create new epochs.
A "commit" message:
- Proposes changes (adds, removes, updates)
- Resolves the proposals into a new epoch
- Distributes the new epoch's keys
Members receive commits, update their tree state, and derive the new epoch's keys. Messages within an epoch are encrypted with keys from that epoch.
This structure makes forward secrecy concrete: when an epoch ends, the old keys are deleted. Past messages remain readable only as long as the encrypted-at-rest copy is preserved.
Welcome Messages
When a member is added to a group, they receive a "Welcome" message containing the current group state. The Welcome message is encrypted under the new member's public key (using HPKE; see IETF RFC 9180 HPKE).
The Welcome contains:
- Current epoch information
- Group members' identities
- The new member's path keys
- Information needed to participate in subsequent epochs
The Welcome is the bootstrapping mechanism. Once received, the new member can decrypt messages and participate in commits.
Application Messages
Once a member has the current epoch keys, they can send application messages. Each application message is:
- Encrypted with an AEAD (default AES-128-GCM, alternatives include AES-256-GCM and ChaCha20-Poly1305)
- Authenticated to the sender via a per-sender chain of keys
- Identified by sender, generation, and content type
The chain of keys per sender is similar to the Double Ratchet's symmetric ratchet. Each message uses a fresh key derived from the sender's current chain key.
Cipher Suites
MLS defines cipher suites combining KEM, KDF, AEAD, and signature algorithms. Examples:
- MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519: classical, AES-128
- MLS_256_DHKEMP521_AES256GCM_SHA512_P521: classical, AES-256
- MLS_128_DHKEMX25519_CHACHA20POLY1305_SHA256_Ed25519: classical, ChaCha20
These are the published cipher suites in RFC 9420. The KEM is from the HPKE family (DHKEM in classical setting). The AEAD is for application messages. The signature is for authenticating commits and welcomes.
PQC for MLS
MLS does not yet have a published PQC cipher suite. Drafts in progress add ML-KEM and ML-DSA:
- MLS with hybrid HPKE KEM: replace DHKEM with hybrid (X25519+ML-KEM)
- MLS with PQ signatures: replace Ed25519 with ML-DSA or hybrid (Ed25519+ML-DSA)
- Pure PQC MLS: ML-KEM and ML-DSA throughout
The IETF MLS working group is coordinating with CFRG (Crypto Forum Research Group) on the PQC cipher suite definitions. Expected publication: 2026 to 2027.
The cryptographic structure of MLS does not need to change for PQC; only the algorithms in the cipher suite swap. This is intentional design: cryptographic agility from day one.
Why MLS Matters for Post-Quantum
MLS being the modern standard for group messaging means PQC migration is concentrated. Once PQC cipher suites are published and implemented in MLS libraries (OpenMLS, MLSpp, etc.), every MLS-based product gains PQC support. This is more efficient than each messaging product migrating independently.
Products using or planning to use MLS:
- Wire (already uses MLS for groups)
- Signal (researching MLS for large groups)
- WhatsApp (Meta has stated MLS interest)
- Cisco Webex (uses MLS)
- New collaborative tools (various)
When these products migrate to PQC MLS, billions of users gain post-quantum group messaging.
MLS vs Signal Protocol
A common question: should new products use MLS or Signal Protocol?
- Signal Protocol: optimized for two-party messaging, well-deployed, simpler in spirit
- MLS: optimized for groups, scales to large memberships, more complex but more capable
For pure two-party use, Signal is often simpler. For groups of any size, MLS is the better fit. Some products use both: Signal for direct messages, MLS for groups.
QNSQY's qs-chat (in development) is targeting military-grade voice/video. The roadmap considers MLS for group calls and broadcast scenarios. PQC MLS would be a natural fit.
Implementation: OpenMLS
The reference Rust implementation of MLS is OpenMLS (developed primarily by Wire). It supports the published cipher suites and is being extended for PQC.
Key features of OpenMLS:
- Pure Rust, memory-safe
- Pluggable cryptographic backends (RustCrypto, OpenSSL)
- Active PQC integration work
- Used in production by Wire and others
Other implementations exist (MLSpp in C++, mls-rs in Rust by AWS). The protocol is interoperable across implementations.
Practical Considerations
Group Size Limits
MLS scales but not without limits. Practical group sizes today are up to ~10,000 members. Larger groups need additional protocol layers (for example, signaling subgroups). Beyond ~50,000, naive MLS becomes expensive.
State Synchronization
MLS state must be synchronized among members. Out-of-order delivery, network partitions, and dropped commits require careful state management. Application designers must handle these cases.
Identity and Key Distribution
MLS itself does not specify how member identities are bound to long-term keys. This is left to the application or a federation protocol. PKI, blockchain identities, or platform-specific systems all work.
TreeKEM Bandwidth and PQ Implications
The bandwidth profile of TreeKEM under PQ algorithms is a major design consideration. In classical MLS:
- Each leaf has an X25519 public key (32 bytes)
- Each internal node has an X25519 public key (32 bytes)
- A commit message touches O(log N) nodes for an N-member group
- For N = 1000, log N ≈ 10, so a commit touches about 10 nodes, total ~320 bytes of new keys
In PQ MLS with ML-KEM-768:
- Each leaf has an ML-KEM-768 public key (1184 bytes)
- Each internal node has an ML-KEM-768 public key (1184 bytes)
- A commit touches O(log N) nodes
- For N = 1000, log N ≈ 10, so a commit touches about 10 nodes, total ~12 KB of new keys
Hybrid MLS (X25519 + ML-KEM-768) carries both, roughly 12 KB + 320 bytes ≈ 12.3 KB per commit. Application messages still use AES-128-GCM symmetric encryption, so the per-message overhead is unchanged. Only the membership-change commits and welcomes carry the PQ size penalty.
For groups with frequent membership changes (corporate Slack channels, large game lobbies), the commit traffic adds up. For groups that are stable, PQ MLS feels much like classical MLS at the network level.
Welcome Message PQ Considerations
The Welcome message bootstraps a new member into the group. Its content includes the group's current epoch state, encrypted under the new member's public key.
For PQ MLS:
- The new member has an ML-KEM-768 public key
- The Welcome encrypts a session key for the new member using ML-KEM encapsulation
- The session key decrypts the Welcome's payload (group state, current keys, identity bindings)
The encapsulation step adds ~1 KB ciphertext (ML-KEM-768 ciphertext is 1088 bytes). The payload itself, which contains the group's current state, can be large for a busy group with many members and recent activity. For a group with 1000 members, the Welcome payload might be tens of KB plus the encapsulation overhead.
This is acceptable for messaging applications but matters for thin-client devices joining large groups. The MLS specification allows incremental join optimizations where a new member receives only the minimum state needed to participate going forward, deferring full historical state to background fetches.
Forward Secrecy Under PQ
MLS's forward secrecy property says that compromise of current keys does not reveal past messages. In a hybrid MLS deployment, both the X25519 layer and the ML-KEM layer must be broken to recover past message keys, applying the harvest-now-decrypt-later defense to messaging. For deployments where past message confidentiality is paramount (medical records messaging, military communications, journalist source protection), hybrid MLS is the prudent choice today. Pure PQ MLS adds confidence for the post-quantum era but requires the broader ecosystem to migrate.
FAQ
Does MLS replace Signal Protocol?
For groups, increasingly yes. For two-party messaging, Signal Protocol is still common and simpler. Some products use both: Signal Protocol for direct messages, MLS for groups.
When will PQC MLS be published?
IETF drafts on PQC cipher suites for MLS are active in 2025 and 2026. Expected RFC publication 2026 to 2027. Implementations (OpenMLS, etc.) are likely to follow within months of standardization.
Is MLS used in WhatsApp or Signal?
WhatsApp and Signal currently use Signal Protocol or close variants. Both have stated interest in MLS, particularly for very large groups, but adoption is still in progress. Wire has used MLS in production since 2022.
How does QNSQY relate to MLS?
QNSQY is file encryption, not messaging. The qs-chat extension under development targets military-grade voice/video communication and may incorporate MLS-style group keying for multi-party calls. Until then, QNSQY's primary product is file encryption with multi-recipient support. See pricing.
Is MLS post-quantum secure today?
Not without modification. The default cipher suites in RFC 9420 use classical algorithms. PQC cipher suites are being standardized. Until those are widely deployed, MLS messages are vulnerable to harvest-now-decrypt-later attacks against the KEM and signature components.
How does MLS handle device replacement?
When a user replaces a device (lost phone, new laptop), they must re-key into existing groups. The MLS protocol provides an "Update" mechanism where a member proposes a new leaf key, and the next commit incorporates the proposal. After the commit, the new device participates with fresh keys, and the old device's keys are no longer valid for the group.
For PQ MLS, the Update message carries a new ML-KEM public key (and optionally a new ML-DSA verification key for the member's identity). The size of the Update is dominated by the new public keys, around 2 KB for hybrid X25519 + ML-KEM-768 plus signature.
Will federation between platforms work for PQ MLS?
Federation between MLS platforms (so Wire users can talk to Signal users in shared MLS groups) requires both sides to agree on cipher suites and identity bindings. The IETF MIMI (More Instant Messaging Interoperability) working group is working on federation specifications that include PQ cipher suite negotiation. This work is independent of RFC 9420 itself but builds on top of it.
Sources
- IETF RFC 9420, "The Messaging Layer Security (MLS) Protocol," July 2023. https://datatracker.ietf.org/doc/html/rfc9420
- IETF MLS Working Group. https://datatracker.ietf.org/wg/mls/about/
- IETF RFC 9180, "Hybrid Public Key Encryption," February 2022. https://datatracker.ietf.org/doc/html/rfc9180
- RFC 9750, "The Messaging Layer Security (MLS) Architecture," March 2025. https://datatracker.ietf.org/doc/html/rfc9750
- OpenMLS implementation. https://github.com/openmls/openmls
- NIST FIPS 203, "Module-Lattice-Based KEM Standard." 2024. https://csrc.nist.gov/pubs/fips/203/final
- IETF MIMI Working Group, "More Instant Messaging Interoperability." https://datatracker.ietf.org/wg/mimi/about/
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.