MLS End-to-End Encryption Protocol Achieves Proposed Standard Status

The Internet Engineering Task Force (IETF), the organization responsible for developing internet protocols and architecture, has completed the RFC for the MLS (Messaging Layer Security) protocol and published the related specification, RFC 9420. The specification has been granted “Proposed Standard” status, after which work will begin to elevate the RFC to “Draft Standard” status, which effectively means the protocol is fully stabilized and all feedback has been addressed.

The MLS protocol is designed to provide end-to-end encryption in messaging applications. Its implementation is expected to unify the mechanisms for end-to-end encryption in group messaging (with two or more participants) and simplify the process of adding such support to applications. Companies including AWS, Cisco, Cloudflare, Google, Meta, Mozilla, Phoenix R&D, and Wire, as well as the Matrix Foundation (which develops the decentralized Matrix communication platform), have announced plans to implement MLS support in their products.

The main goal of creating the new protocol is to unify tools for end-to-end encryption and introduce a single, standardized, and verified protocol that can be used instead of various incompatible protocols developed by different vendors for the same tasks. MLS allows different applications to use proven, ready-made protocol implementations and enables their joint development and verification. Application-level portability is proposed to be implemented at the level of authentication, key retrieval, and confidentiality (compatibility at the transport and semantic levels is outside the scope of the standard).

MLS implementations are being developed in C++ (MLSpp, RingCentral), Go, TypeScript, and Rust (OpenMLS, Wickr). The development of MLS has drawn on the experience of existing protocols used to secure message transmission, such as S/MIME, OpenPGP, Off the Record, and Double Ratchet. MLS support is already available in communication platforms like Webex and RingCentral, and is planned for Wickr and Matrix projects.

Problems Addressed by the Protocol:

• Confidentiality – Messages can only be read by group participants.
• Integrity and Authentication Guarantees – Each message is sent by an authenticated sender and cannot be tampered with or altered in transit.
• Group Member Authentication – Each participant can verify the authenticity of other group members.
• Asynchronous Operation – Encryption keys can be set up without both participants being online at the same time.
• Forward Secrecy – Compromising one participant does not allow previously sent group messages to be decrypted.
• Post-Compromise Security – Compromising one participant does not allow future group messages to be decrypted.
• Scalability – Sublinear scalability in resource consumption relative to group size, where possible.