This blog post introduces the new Messaging Layer Security (MLS) cryptographic protocol for end-to-end secure group messaging. I’ll talk about what it is, who is behind it, how Wickr is involved, and why we believe it matters.
1. What is MLS?
With the growing use of instant messaging — not just by end-consumers, but also increasingly by industry, NGOs, political organizations, and by the military and many other government sectors — the need for better messaging platforms is steadily increasing. By “better,” I really mean a whole host of things, like more secure, robust, functional, integrated, open, and distributed.
Secure messaging protocols, such as Wickr’s messaging protocol and the double ratchet family of protocols, have given rise to powerful tools for one-on-one and small (<300) group messaging. However, there remains a growing need for similarly secure protocols for larger groups, especially in enterprise, organizational, and government settings where reasonable expectations of privacy for information shared across larger groups are commonplace. Moreover, as the secure messaging space grows in complexity and importance, it is becoming ever more important for us to agree on open and thoroughly vetted flexible standards, not to mention an open process for steadily improving on the standard. Especially in terms of the latter, we currently have nothing even close. Getting these sorts of things right is really, really hard. (See the history of attacks on Wi-Fi, TLS/SSL, or GSM protocols for examples of just how hard it really is.) I personally — and Wickr as a company — believe strongly that we all stand to benefit if we pool our resources and know-how in order to build stronger foundations for us all.
Nor are we alone in holding this opinion. This concern has inspired a growing collection of cryptographers, engineers, activists, and enthusiasts from the open-source/hacker community, from the messaging industry, and from various academic institutions to work together as part of the MLS Working Group under the auspices of the IETF. In a nutshell, the working group’s purpose is to produce a practical, well-specified, carefully vetted open standard for federated secure messaging. The final product will be a series of RFC documents fully specifying the protocol. Basically, the MLS WG should do for (asynchronous) secure messaging what the SSL/TLS WG is doing for (synchronous) secure transport.
2. How is Wickr Involved?
Wickr has been deeply involved in this effort since its early days. We’re active contributors, we regularly propose extensions and improvements exploring the boundaries of what MLS (or MMS-like) protocols can achieve, and we’ve been doing lots of rigorous mathematical analysis of MLS’s various cryptographic properties. For much more on our work, I encourage you to look at our Crypto Research @ Wickr site. There you’ll find tons of resources around our work on MLS (as well as our other crypto research programs): things like detailed descriptions of individual projects, links to more resources such as blog posts, related RFCs we’re contributing to or authoring, videos of MLS-related talks we’ve given, slide decks, and of course, our peer-reviewed cryptographic research.
3. Security Goals for MLS
Secure federated group messaging is a complicated beast with all kinds of different actors, devices, threat models, engineering constraints, etc. So, I’d like to talk a bit more about some of the most important and interesting security goals for MLS.
E2E Privacy: Two of the most important and basic security properties in the MLS protocol revolve around the (very strong) flavor of E2E privacy provided by MLS. Namely, MLS will provide both forward secrecy (FS) and post compromise security (PCS). The latter, in the past, has also been called “backward security” and even (somewhat confusingly) “future security.” In this post, we’ll stick to the more modern (and domain-specific) term of PCS. FS has, in the past, also been called “perfect forward secrecy” but I (and many other cryptographers) prefer to avoid claims of “perfection.” It just seems unwise. (E.g. the vast majority of “PFS” protocols deployed today would actually lose forward security again if someone were to build a powerful enough general-purpose quantum computer, making their FS properties rather less than perfect.)
Either way, on an intuitive level, FS guarantees that today’s ciphertexts (i.e. today’s communication between users) remain private regardless of future compromise. In particular, that means any decryption keys (and values from which the keys could be derived) have to be updated — or at least deleted — as soon as possible so that future compromises don’t reveal anything useful to the adversary.
Conversely, PCS guarantees that even after a participant’s key material has leaked, continued normal usage of the messaging protocol will eventually result in updating all leaked keys to completely random new values. Moreover, the mechanism via which this is done must ensure that the updated keys can’t be derived using the leaked keys and the network traffic. So, for example, it would not be okay to simply send out updated keys encrypted under the leaked ones.) The idea is that such a key update mechanism eventually restores the security of subsequent communications once the healing process is complete. Concretely, this means that the protocol should be constantly refreshing its secrets with fresh entropy. Both Wickr’s messaging protocol and the double ratchet family of protocols exhibit flavors of FS and PCS. For more on this, check out Wickr’s recent research project on the FS/PCS properties of MLS, in which we uncovered some weaknesses with the current design and proposed a new version with a fix. In fact, in the two-party case, our new version achieves PCS even faster than the double ratchet does!
Authenticity: Another set of security properties MLS aims for revolves around authenticity. Naturally, MLS must ensure that both the content and the source messages can be reliably determined by all intended recipients. But MLS also aims to provide guarantees to members joining an existing group, allowing them to authenticate the existing group state without having to trust whoever invites them.
For very large groups involving very resource-poor devices, it will be helpful (in some deployments) to offload some public group states to a central delivery server. In line with the guiding principle of E2E security, the server is untrusted, so this state must be authenticated. What makes this non-trivial is that the state may be rather large and constantly changing, yet we have strict engineering constraints, so finding efficiency is particularly important.
Meta-Data Hiding: Along with content privacy, MLS also aims to minimize the amount and type of data exposed to the network and servers. On the one hand, this means minimizing the data required by, say, the delivery service to fulfill its role. This allows privacy-conscious MLS providers to implement their servers so that they store as little data as possible about their MLS network. On the other hand, MLS is also trying to minimize the data available to the network and servers. This means that even malicious servers will not be able to collect this type of data. The exact meta-data hiding properties and mechanisms of MLS remain very much a work in progress and a great topic for more R&D.
Deniability: Another great topic for more R&D revolves around the deniability goals for MLS. Intuitively, deniability means that honest users can deny things about their past interactions, much like having an (un-recorded) real-life conversation with someone is deniable after the fact.
Deniability is really an entire spectrum of security notions with various axes to consider. What types of facts should be deniable? (Group membership? Who sent a message? If the same person is in multiple groups or authored multiple messages? Etc.) Another axis concerns what information is available to the judge determining the veracity of the deniable claims. Does the judge know the users’ long-term secrets? The transcript? The randomness used? Does the judge have a trusted informant in the group? Is the informant following the protocol or deviating in order to create incriminating evidence? Deniability can also be “online” or “offline” depending on whether the judge witnesses the network communication as it unfolds or only receives a (supposed) copy of it after the fact. MLS designers are currently in the process of navigating these (and more) subtleties to explore what the best (achievable) variant of deniability is. Given its complexity, I expect this to be a security property of MLS that will evolve in future versions.