MLS (Messaging Layer Security)
Protocolo P2P
Comunidade
Detalhes
Licença 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)
Status de Dev 🏁 Final
Proprietário 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
Proprietário - Lista
- Internet Engineering Task Force
Órgão de Governança IETF (Messaging Layer Security Working Group)
País International (IETF process; contributing organizations span the USA, France, Germany and the UK)
Ano de Início 2018
Stack Language-agnostic specification. Reference and production implementations in Rust (OpenMLS) and C++ (MLS++); bindings widely available
Financiamento Open standards process — participant organizations fund their own contributors; no central budget
Última Investigação 31 de jul. de 2026
Protocolo P2P Atributos
Proprietário - Lista
- Internet Engineering Task Force
Origens 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
Banco de Dados N/A — a security protocol; group state is held by clients. No storage layer defined
Linguagem de Consulta N/A — no query interface
Formatos de Dados 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
Edição Colaborativa em Tempo Real N/A — a security layer, not an editing protocol; it can secure the transport of collaborative traffic but defines nothing about it
Edição de Texto Rico N/A — content-agnostic; MLS protects opaque application messages
Suporte Móvel Library-level — implementations are embedded in mobile messaging clients; no standalone application
Suporte Web Library-level — implementations compile to WebAssembly and are used in browser clients; the protocol itself is transport-independent
Aplicativos Nativos Library-level — embedded in native messaging clients
Termos Free / open standard — no licensing fees; RFC freely published
Fundos N/A — IETF working groups are not separately funded entities
Baseado Em 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
Arquitetura 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
Rede de Sobreposição N/A — defined at the group level rather than the network level; group membership is the only topology MLS defines
Endereçamento por Conteúdo 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
Criptografia de Ponta a Ponta (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
Tolerância a Falhas Bizantinas 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
Assinatura Ed25519, ECDSA (P-256/P-384/P-521) depending on ciphersuite; credentials bind signature keys to identities via the external Authentication Service
Permissões 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
Compatibilidade com a Web Semântica N/A — binary wire protocol with no semantic layer
Contrato Inteligente N/A — no ledger or contract component
Posição na Pilha de Protocolo Application-layer (built on TCP/IP) — sits above transport and below the messaging application; deliberately independent of the underlying network
Incorporação de Ativo / Valor None — no token, ledger, or value-transfer mechanism
Maturidade / Padronização do Protocolo 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
Relacionamentos
Como esta ferramenta se conecta a outras ferramentas e organizações, a partir de relacionamentos revisados pelo responsável pelos dados do OpenHaven. Descrevem como os projetos se conectam, não a qualidade deles.
- Desenvolvido por
- Internet Engineering Task Force
- Base de
- Hospeda