MLS (Messaging Layer Security)

P2P Protocol

An IETF standards-track protocol (RFC 9420) providing end-to-end encrypted group messaging with forward secrecy and post-compromise security that scales efficiently to large groups. Its core mechanism is TreeKEM, a ratcheting binary key tree in which group key updates cost O(log n) rather than O(n), making E2EE practical for groups of thousands. MLS deliberately specifies only the security layer: it defines group formation, key agreement, membership changes and message protection, and assumes an external Delivery Service for ordering and transport and an Authentication Service for identity. That separation is what allows it to be layered onto very different networks.

Community
Links
Visit Community

Details

License Open specification (IETF, no licence fee; RFC text under IETF Trust terms). Independent open-source implementations: OpenMLS (Rust, MIT/Apache-2.0), MLS++ (C++, from Cisco)
Dev Status 🏁 Final
Owner IETF — Messaging Layer Security (MLS) Working Group. RFC 9420 authors: Richard Barnes, Benjamin Beurdouche, Raphael Robert, Jon Millican, Emad Omara, Katriel Cohn-Gordon. Contributors include Cisco, Mozilla, Wire, Meta, Google and academic cryptographers
Governing Body IETF (Messaging Layer Security Working Group)
Country International (IETF process; contributing organizations span the USA, France, Germany and the UK)
Start Year 2018
Stack Language-agnostic specification. Reference and production implementations in Rust (OpenMLS) and C++ (MLS++); bindings widely available
Funding Open standards process — participant organizations fund their own contributors; no central budget
Last Investigated Jul 1, 2026

Use Case Domains

Platform Evolution & Sovereignty

P2P Protocol Attributes

Origins Secure messaging / cryptography — motivated by the fact that pairwise ratchets such as Signal's Double Ratchet scale poorly to large groups, and that every major messenger had built its own incompatible group-encryption scheme. MLS was chartered to produce one interoperable, formally analysed standard
Database N/A — a security protocol; group state is held by clients. No storage layer defined
Query Language N/A — no query interface
Data Formats MLS wire formats defined in RFC 9420: MLSMessage, KeyPackage, Welcome, Commit, Proposal, GroupInfo and the ratchet tree encoding. Ciphersuites cover X25519/Ed25519, P-256/P-384/P-521 and X448 with AES-GCM or ChaCha20-Poly1305
Collaborative Live Editing N/A — a security layer, not an editing protocol; it can secure the transport of collaborative traffic but defines nothing about it
Rich Text Editing N/A — content-agnostic; MLS protects opaque application messages
Mobile Support Library-level — implementations are embedded in mobile messaging clients; no standalone application
Web Support Library-level — implementations compile to WebAssembly and are used in browser clients; the protocol itself is transport-independent
Native Apps Library-level — embedded in native messaging clients
Terms Free / open standard — no licensing fees; RFC freely published
Funds N/A — IETF working groups are not separately funded entities
Based On IETF cryptographic primitives (HPKE RFC 9180, HKDF, AEAD ciphers, Ed25519/ECDSA signatures); TreeKEM (ratcheting binary key tree, the protocol's core construction); builds conceptually on the Double Ratchet lineage while replacing its pairwise scaling model
P2P Architecture Transport-agnostic by design — MLS specifies no routing or peer discovery. It assumes an external Delivery Service responsible for message ordering and fan-out, which may be a centralized server, a federated network, or a decentralized relay network. This is precisely why it can be layered onto Nostr (Marmot Protocol), onto federated networks, or onto peer-to-peer transports
Overlay Network N/A — defined at the group level rather than the network level; group membership is the only topology MLS defines
Content Addressing No — messages are identified within group epochs, not by content hash
Local-First N/A — MLS requires ordered delivery of handshake messages, so group state advances only as commits are received. It is not offline-first in the CRDT sense, though message protection is fully client-side
E2EE Yes — this is the protocol's entire purpose: end-to-end encryption with forward secrecy and post-compromise security. The Delivery Service sees ciphertext and metadata but never plaintext or group secrets
CRDTs Lib N/A — MLS requires a total order on handshake messages and does not use CRDTs
Byzantine Fault Tolerance No — MLS assumes an honest-but-curious Delivery Service for liveness and does not provide consensus. It protects confidentiality and integrity against a malicious server, but a malicious Delivery Service can withhold or reorder messages
Signature Ed25519, ECDSA (P-256/P-384/P-521) depending on ciphersuite; credentials bind signature keys to identities via the external Authentication Service
Permissions Group membership and roles — Add, Update and Remove proposals committed by group members; the specification defines the mechanism and leaves authorization policy to the application
Semantic Web Compatibility N/A — binary wire protocol with no semantic layer
Smart Contract N/A — no ledger or contract component
Protocol Stack Position Application-layer (built on TCP/IP) — sits above transport and below the messaging application; deliberately independent of the underlying network
Asset / Value Embedding None — no token, ledger, or value-transfer mechanism
Protocol Maturity / Standardization IETF Proposed Standard — RFC 9420, published July 2023, with multiple independent interoperable implementations and formal security analysis conducted during standardisation. Among the most mature entries in this file