Field Notes

entity

Messaging Layer Security

StatusStableReviewdue UpdatedStands on3 sourcesSupportsnotes

Messaging Layer Security is an Internet standard for asynchronous group key agreement. It supplies E2EE key establishment with PFS and PCS for groups ranging from two clients to very large memberships.

Scope

MLS represents group members as leaves in a tree. Membership changes advance the group to a new epoch, allowing key updates to scale more efficiently than encrypting every group operation separately for every member.

The protocol does not define a complete messenger. RFC 9750 explicitly leaves delivery, application content, identity and authentication infrastructure, metadata handling, backups, and user-facing verification to the embedding system. Cryptographic interoperability therefore does not ensure application or identity interoperability.

Security boundary

MLS protects application data against a compromised delivery service, but assumes that another layer protects transport metadata from ordinary network observers. Endpoint compromise, credential replacement, message suppression, and insider replay require system-level handling.

Jaeger and Kumar group chat encryption analysis identifies replay and reordering attacks available to group insiders in the analyzed construction. Secure and decentralized communication stacks uses MLS to distinguish a cryptographic substrate from a deployed communication product.

Comparison with the Signal Protocol

MLS and the Signal Protocol are the same kind of thing: reusable cryptographic constructions an application embeds, not messengers. Comparing “MLS” with “Signal” therefore mismatches the levels. The right pairing is MLS against the Signal Protocol, the construction behind Signal the app — the PQXDH handshake and the Double Ratchet, now extended by the SPQR-based Triple Ratchet — whose reference library, libsignal, also encrypts WhatsApp, Google Messages RCS chats, and the opt-in modes of Facebook Messenger and Skype.1

The two differ on what they standardize rather than on openness. The Signal Protocol is published, its reference library libsignal is open source, and independent reimplementations exist, since the design itself is not copyrightable. What it lacks is an interoperability standard. There is no specified wire format guaranteeing that one implementation interoperates with another, and the historical under-specification and absence of a permissive license pushed vendors toward divergent reimplementations rather than toward a shared interoperable protocol. MLS instead is an IETF standard designed for cross-provider interoperability, where specification conformance, not a shared codebase, is what lets its several independent implementations interoperate, across deployments spanning Cisco Webex, Discord, RingCentral, Wire, and the RCS Universal Profile.

RCS shows the distinction in one system. Google Messages secures its own app-to-app RCS traffic with the Signal Protocol, but interoperable end-to-end encryption between iPhone and Android needed a standard multiple vendors could implement, so the GSMA built Universal Profile 3.0 E2EE on MLS rather than on the Signal Protocol.2 The classic feature contrast still holds: MLS provides native, tree-based group state that scales membership changes across large groups, while the Signal Protocol carries a more mature, more fully post-quantum pairwise path and far longer deployment history.

Cryptographic guarantees

On the guarantees themselves the two are peers, not opposites. Both provide confidentiality, forward secrecy, and post-compromise security, and both do so asynchronously. The differences are in granularity, in what the guarantee natively covers, and in post-quantum posture.

The sharpest distinction is the granularity of forward secrecy and PCS. The Double Ratchet heals per message: a new message key for every message, and a Diffie-Hellman ratchet step on each round-trip, so a compromised pairwise session recovers continuously as the conversation flows. MLS heals per epoch: the group re-keys when a member commits an update or when membership changes, so PCS is only as frequent as those updates.3 A member who never issues an update can leave that member’s key un-refreshed longer than a Double Ratchet session would tolerate. MLS trades some of the Double Ratchet’s pairwise granularity for group scalability.

The comparison therefore flips with the conversation size. For a two-party chat the Signal Protocol is the stronger guarantee today: finer-grained ratcheting plus a deployed, formally verified post-quantum ratchet, where MLS supplies two-party FS and PCS but no required post-quantum ciphersuite. For a large group MLS is the cleaner guarantee: FS and PCS are native to the ratchet tree and scale to thousands, whereas the Signal Protocol’s group modes are an application-level construction over pairwise or sender-key machinery, and post-compromise security is the hard part to preserve in the sender-key approach.

Implementations and deployments

OpenMLS is a Rust implementation of the standard co-maintained by Phoenix R&D and Cryspen; Phoenix R&D’s Raphael Robert is a listed author of RFC 9420. Its consumer messenger Air and the Nostr-based Marmot Protocol and White Noise stacks are current examples of MLS embedded in a full product, each of which still has to supply the identity, delivery, metadata, and recovery layers the standard leaves open.

  1. The Signal Protocol overview inventories the WhatsApp, Google Messages, Facebook Messenger, and Skype deployments of the shared construction and its libsignal library. ↩

  2. The GSMA Universal Profile 3.0 announcement (14 March 2025) selected MLS for interoperable cross-provider RCS E2EE, with iPhone-to-Android encrypted messaging shipping in 2026. ↩

  3. The Double Ratchet specification describes per-message symmetric-key ratcheting and the Diffie-Hellman ratchet advanced on each round-trip, while RFC 9420 describes MLS forward secrecy and post-compromise security advancing at epoch boundaries as the key schedule progresses. ↩

Built on 3 sources (3 external).

Working out connections…