MLS (Messaging Layer Security)

Protocolo P2P

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.

Comunidad
Enlaces
Visitar Comunidad

Detalles

Licencia 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)
Estado de Desarrollo 🏁 Final
Propietario 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
Órgano de Gobierno IETF (Messaging Layer Security Working Group)
País International (IETF process; contributing organizations span the USA, France, Germany and the UK)
Año de Inicio 2018
Stack Language-agnostic specification. Reference and production implementations in Rust (OpenMLS) and C++ (MLS++); bindings widely available
Financiamiento Open standards process — participant organizations fund their own contributors; no central budget
Última Investigación 1 jul 2026

Dominios de Caso de Uso

Evolución de Plataformas y Soberanía

Protocolo P2P Atributos

Orígenes 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
Base de Datos N/A — a security protocol; group state is held by clients. No storage layer defined
Lenguaje de Consulta N/A — no query interface
Formatos de Datos 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
Edición Colaborativa en Vivo N/A — a security layer, not an editing protocol; it can secure the transport of collaborative traffic but defines nothing about it
Edición de Texto Enriquecido N/A — content-agnostic; MLS protects opaque application messages
Soporte Móvil Library-level — implementations are embedded in mobile messaging clients; no standalone application
Soporte Web Library-level — implementations compile to WebAssembly and are used in browser clients; the protocol itself is transport-independent
Aplicaciones Nativas Library-level — embedded in native messaging clients
Términos Free / open standard — no licensing fees; RFC freely published
Fondos N/A — IETF working groups are not separately funded entities
Basado En 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
Arquitectura P2P 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
Red de Superposición N/A — defined at the group level rather than the network level; group membership is the only topology MLS defines
Direccionamiento por Contenido 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
Cifrado de Extremo a Extremo (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
Biblioteca de CRDTs N/A — MLS requires a total order on handshake messages and does not use CRDTs
Tolerancia a Fallos Bizantinos 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
Firma Ed25519, ECDSA (P-256/P-384/P-521) depending on ciphersuite; credentials bind signature keys to identities via the external Authentication Service
Permisos 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
Compatibilidad con la Web Semántica N/A — binary wire protocol with no semantic layer
Contrato Inteligente N/A — no ledger or contract component
Posición en la Pila del Protocolo Application-layer (built on TCP/IP) — sits above transport and below the messaging application; deliberately independent of the underlying network
Incorporación de Activos/Valor None — no token, ledger, or value-transfer mechanism
Madurez del Protocolo / Estandarización 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