Summary:
The Messaging Layer Security (MLS) protocol is the latest evolution in secure messaging and the first cross-industry, secure messaging standard. MLS builds on previous secure messaging protocols by providing significantly improved privacy and data protection, particularly for group messaging. OTF supported Phoenix R&D (co-initiators and co-authors of MLS) to further the standardization of MLS components, facilitate adoption of MLS into existing products, and develop a technology stack around OpenMLS—an open-source implementation of MLS.
Since adoption as an internet standard in 2023, MLS has been widely embraced by the private sector: Google committed to using MLS for Android Messages; and there is active development to incorporate MLS into Android and Firefox, among others. The integration of MLS into these mainstream tools has the potential for profound impact by increasing the security and privacy of these technologies for billions of users worldwide.
As a next step, OTF is supporting the wide-scale adoption of MLS into tools that are user-facing and accessible for at-risk communities as part of a continuing prioritization of investments in open-source, security-enhancing technologies.
Contents:
- A Primer on End-to-End Encryption (E2EE)
- The Need for a Modern E2EE Protocol
- Messaging Layer Security (MLS): A Robust, Multi-Stakeholder Protocol for Digital Privacy
- The Impact of MLS
- Integrating MLS into Internet Freedom Tools
Intro: A Primer on End-to-End Encryption
To understand MLS, it’s essential to begin with a primer on encryption. The latter is essential to digital privacy and security, yet many messaging services don’t offer true, end-to-end encryption (E2EE). This form of encryption keeps messages private from everyone, including the messaging service—from the sender (one “end”) to the recipient (the other “end”). With E2EE, only the sender and recipient can access the message. Without E2EE, messages are only encrypted as they travel to and from the service’s server; when it reaches the server, it’s briefly decrypted. Malicious actors can take advantage of this vulnerability to read messages and target senders and recipients. E2EE protocols like the Off-the-Record protocol, the Wickr protocol, and the Signal protocol paved the way to modern security properties and asynchronous messaging capabilities. Since its inclusion into popular mobile messaging platforms, the Signal protocol has become the reference for practical and high-quality E2EE.
The Need for a Modern E2EE Protocol
Until 2023 a comprehensive specification for end-to-end encryption informed by industry-wide input didn’t exist. The Signal protocol catered to the Signal messaging app. In this sense, it was not an “open” specification that could be easily applied to other apps. A few derivatives emerged due to the lack of both a full specification and permissively licensed implementations. These derivatives have seen different levels of analysis and every provider has had to maintain their own libraries.
In addition, existing E2EE protocols were not designed for encryption in large group messages. They typically focused on end-to-end encryption between two peers. Using them to protect group chats with many peers proved difficult and either meant compromising on security properties or accepting high computational and bandwidth costs.
Various stakeholders from the industry and academia identified these gaps and, with ART and later TreeKEM (protocol proposals) as a foundation, started initial talks for an open standard for asynchronous group messaging with modern security properties. In 2018, an official working group formed at the Internet Engineering Task Force (IETF), a community that deals with standards for the technical development of the internet. This working group met to collaboratively develop the new standard. Members included Phoenix R&D, a team active in the area of secure messaging in both industry and academia for over 10 years.
During the protocol design process, the working group took an iterative approach that involved multiple rounds of review, feedback, and refinement. The team behind Phoenix R&D specifically was advocating to ensure a number of surveillance and censorship-resistant measures were represented in the MLS protocol. For example, encryption of message headers in MLS messages that are comparable to Encrypted Client Hello in TLS (which prevents networks from snooping on which websites a user is visiting) and hide the message sender’s identity.
The team also advocated for message padding, which leads to network-level indistinguishability of individual MLS messages (preventing fine-grained censorship). They benchmarked MLS against various privacy-preserving architectures and ensured the protocol wouldn’t require an inordinate amount of metadata for operation.
MLS: A Robust, Multi-Stakeholder Protocol for Digital Privacy
After five years of effort, MLS was published as RFC 9420—a standards track document by the IETF—in 2023. The specification is fully accessible, and its security has been analyzed in numerous academic publications.
Unlike earlier E2EE protocols, MLS is the first cross-industry standardization effort—meaning it contains properties with diverse applications so developers can easily integrate it into different apps. It’s also the first fully specified (or detailed) E2EE protocol, ensuring that the protocol is clear to developers implementing it. Together, these features make it easy for apps to provide the highest level of end-to-end security for their users. Standardization and full specification also assist academia and cybersecurity experts in engaging in security audits of the protocol.
Another key difference between MLS and other E2EE protocols is that MLS improves the security of group messaging. Existing protocols are fundamentally designed for encryption between exactly two endpoints (1:1 messages). Securing communications in group chats is possible but affects the efficiency and/or compromises some security. Designed with groups in mind, MLS can efficiently, fully encrypt group messages without significantly weakening security guarantees. Learn more about how MLS achieves this efficiency.
Caption: Performance projection: Number of operations required to calculate new group keys with MLS (blue) versus existing group messaging protocols (red).
The Impact of MLS
The development and implementation of IETF protocols has a profound impact on internet users worldwide. These protocols set the baseline for security and privacy that trickle down to users through integration into mainstream tools.
Twenty-four hours after IETF adopted MLS as a standard, Google committed to integrating MLS into its Android Messages/rich communication services—which would bring the protocol to one billion monthly active users. There is active development to incorporate MLS into browsers such as Firefox. Other companies, including AWS, Cisco, Cloudflare, Meta, Wire, and Matrix, also came out in support of MLS.
Integrating MLS into Internet Freedom Tools
Ensuring as many people as possible have access to the advancements that MLS brings and developers can contribute to its development requires accessible implementations (software code to implement the protocol). This is why Phoenix R&D (co-initiators and co-authors of MLS) developed OpenMLS, an open-source, easy-to-use, software library that can serve as a building block in applications that want to use the MLS protocol. The OpenMLS implementation is one of a handful of existing MLS implementations.
OpenMLS code is written in the Rust programming language. Rust has two advantages: 1) it’s “memory safe,” thereby avoiding erroneous memory access (with access to memory, threat actors can seize data or execute malicious code); and 2) it can be easily compiled for many platforms. The latter is important so that a software library can be used seamlessly on Android, iOS, Windows, Linux, macOS, and in the browser.
Creating the Foundation for Privacy-Preserving and Decentralized Messaging Technology
For human rights defenders, journalists, activists, and others at risk of repressive censorship and surveillance, E2EE is essential. Yet there is a dearth of messaging apps that fully cater to their threat model.
At-risk communities have to choose between two worlds: One is Matrix, which supports decentralized communication and allows users to self-host their communications platform. The downside of Matrix is that it aggregates a vast amount of metadata. If repressive regimes gain access to this metadata, they could potentially identify a message’s sender and recipient.
The second option for at-risk communities is Signal, which provides a high level of metadata protection, but is centralized and thus easily censored. In addition, Signal cannot efficiently provide E2EE for large-group communications.
To give these communities an even better option, Phoenix R&D’s research and development work has focused on the feasibility of combining Matrix’s decentralized and federated infrastructure with Signal’s low metadata footprint. This combination is unique and unifies two fundamental benefits for at-risk communities. The outcome of this effort is a technology stack (a set of technologies used to develop an application) that can serve as a foundation for messaging apps that have a strong focus on privacy, and cater to the needs of at-risk communities.
OTF is supporting the development of a tech stack built around OpenMLS for a new generation of open-source messaging technology that combines privacy, security, and decentralization. This major internet freedom initiative will benefit individuals living in the most digitally repressive environments.
What’s Next?
Creating the tech stack foundation for MLS-based messaging is another huge accomplishment for E2EE, yet there is still a lot of work ahead to achieve broad adoption. Phoenix R&D now aims to build a user-facing application on top of this tech stack.
The goals are twofold:
1) Upgrade the tech stack developed with OTF’s support to a level where other developers can rely on it to provide production-ready, end-to-end encryption in their applications. Phoenix R&D is already in contact with several apps and platforms about how they can integrate the technology into their products.
2) Build their own messaging service on top of their tech stack. This will allow at-risk individuals to use the messenger hosted by either Phoenix R&D, themselves, or by a tech collective they trust. The end-product will be a messenger that can be used similarly to WhatsApp or Signal on iOS, Android, Windows, macOS, and Linux. There will be no major barriers to use—no credit card, phone number, or email address required (allowing for better anonymity and accessibility).
To date, OTF has supported Phoenix R&D’s development of a technology stack built around OpenMLS for this new generation of open-source messaging technology that combines privacy, security, and decentralization. The new tech stack not only complements the MLS protocol, but it minimizes the need for metadata on the infrastructure side. This major internet freedom initiative will benefit individuals living in the most digitally repressive environments.
To date, OTF has supported Phoenix R&D’s development of a technology stack built around OpenMLS for this new generation of open-source messaging technology that combines privacy, security, and decentralization. The new tech stack not only complements the MLS protocol, but it minimizes the need for metadata on the infrastructure side. This major internet freedom initiative will benefit individuals living in the most digitally repressive environments.In addition to funding the tech-stack development, OTF also provided support through its Secure Usability and Accessibility Lab (SUA Lab)—helping Phoenix R&D develop their communication and branding strategy for an OpenMLS-based messaging app and the non-profit organization that will run it. Services from SUA Lab help improve a tool’s usability and accessibility, which in turn leads to greater adoption.
Help Support Phoenix R&D’s Work
Phoenix R&D works on the standardization, implementation, and development of secure messaging. OTF supports Phoenix on this mission and hopes other funders will also. Contact the team at Phoenix R&D to learn more.
References