RFC 9750

The Messaging Layer Security (MLS) Architecture 🎀 (Part 1 of 11)

Okay bestie, this is RFC 9750, the architecture doc for MLS, which is the thing that keeps group chats private 💜✨

• Document: RFC 9750, The Messaging Layer Security (MLS) Architecture
• Date: April 2025
• Category: Informational 🦋 (it's published for info purposes, not as a Standards Track spec)
• ISSN: 2070-1721
• Authors: B. Beurdouche (Inria & Mozilla), E. Rescorla, E. Omara, S. Inguva, A. Duric
• Obsoletes / Updates: nothing listed in the title block

Abstract ✨

The MLS protocol (RFC 9420) gives messaging apps a way to agree on group keys 🔑 It's built to stop eavesdropping, tampering, and message forgery, and it gives you forward secrecy (FS) and post-compromise security (PCS) 🛡️

This doc describes the architecture for using MLS in a general secure group messaging setup and defines the security goals for MLS. It gives guidance on building a group messaging system and talks about the security and privacy trade-offs of the different mechanisms in the MLS protocol (e.g., how often public encryption keys get rotated 🔄). It also gives guidance on the parts of the infrastructure that MLS doesn't standardize and leaves to the app.

The recommendations here aren't mandatory if you just want to interoperate at the protocol level. BUT they still change the overall security guarantees a messaging app ends up with 👀 This matters most against active adversaries that can compromise clients, the Delivery Service (DS), or the Authentication Service (AS). Lowkey terrifying, so pay attention 💀

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9750.

Copyright Notice ©️

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🗂️

1.  Introduction
2.  General Setting
  2.1.  Protocol Overview
  2.2.  Abstract Services
3.  Overview of Operation
  3.1.  Step 1: Account Creation
  3.2.  Step 2: Initial Keying Material
  3.3.  Step 3: Adding Bob to the Group
  3.4.  Step 4: Adding Charlie to the Group
  3.5.  Other Group Operations
  3.6.  Proposals and Commits
  3.7.  Users, Clients, and Groups
4.  Authentication Service
5.  Delivery Service
  5.1.  Key Storage and Retrieval
  5.2.  Delivery of Messages
    5.2.1.  Strongly Consistent
    5.2.2.  Eventually Consistent
    5.2.3.  Welcome Messages
  5.3.  Invalid Commits
6.  Functional Requirements
  6.1.  Membership Changes
  6.2.  Parallel Groups
  6.3.  Asynchronous Usage
  6.4.  Access Control
  6.5.  Handling Authentication Failures
  6.6.  Recovery After State Loss
  6.7.  Support for Multiple Devices
  6.8.  Extensibility
  6.9.  Application Data Framing and Type Advertisements
  6.10. Federation
  6.11. Compatibility with Future Versions of MLS
7.  Operational Requirements
8.  Security and Privacy Considerations
  8.1.  Assumptions on Transport Security Links
    8.1.1.  Integrity and Authentication of Custom Metadata
    8.1.2.  Metadata Protection for Unencrypted Group Operations
    8.1.3.  DoS Protection
    8.1.4.  Message Suppression and Error Correction
  8.2.  Intended Security Guarantees
    8.2.1.  Message Secrecy and Authentication
    8.2.2.  Forward Secrecy and Post-Compromise Security
    8.2.3.  Non-Repudiation vs. Deniability
    8.2.4.  Associating a User's Clients
  8.3.  Endpoint Compromise
    8.3.1.  Compromise of Symmetric Keying Material
    8.3.2.  Compromise by an Active Adversary with the Ability to
            Sign Messages
    8.3.3.  Compromise of Authentication with Access to a Signature
            Key
    8.3.4.  Security Considerations in the Context of a Full State
            Compromise
  8.4.  Service Node Compromise
    8.4.1.  General Considerations
    8.4.2.  Delivery Service Compromise
    8.4.3.  Authentication Service Compromise
  8.5.  Considerations for Attacks Outside of the Threat Model
  8.6.  No Protection Against Replay by Insiders
  8.7.  Cryptographic Analysis of the MLS Protocol
9.  IANA Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Contributors
Authors' Addresses

1. Introduction 🌈

End-to-end security is the default in most instant messaging systems, and it also shows up in calling and conferencing systems 📞 In this context, "end-to-end" means users still get some level of security, with the exact level depending on the system design, even when the operator of the messaging system is acting maliciously 😤

Messaging Layer Security (MLS) specifies an architecture (this document) and a protocol [RFC9420] for end-to-end security in this setting. MLS is not meant to be a full instant messaging protocol. It's meant to be embedded in concrete protocols, like the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] 🧚 Implementations of the MLS protocol will interoperate at the cryptographic level, even though they may differ in how protected messages get delivered, what's inside protected messages, and their identity/authentication infrastructure. The MLS protocol is designed to give the same security guarantees to everyone, for every group size, including groups of only two clients 💖

2. General Setting 🎀

2.1. Protocol Overview 🦋

MLS lets clients form groups where they can talk securely 💬 For example, a bunch of users might use clients on their phones or laptops to join a group and chat 📱💻 A group can be as small as two clients (think simple person-to-person messaging) or as big as hundreds of thousands 🤯 A client that's part of a group is a member of that group. When groups change membership or group or member properties, they move from one epoch to the next, and the group's cryptographic state evolves with them ✨

The group is represented as a tree, with the members as the leaves of that tree 🌳 The tree is how MLS efficiently encrypts to subsets of the members. Each member has a state called a LeafNode object, which holds the client's identity, credentials, and capabilities 🪪

Various messages are involved in moving from epoch to epoch. A Proposal message proposes a change for the next epoch, like adding or removing a member ➕➖ A Commit message starts a new epoch by telling the group members to carry out a collection of proposals 🎬 Proposals and Commits are collectively called handshake messages. A KeyPackage provides the keys used to add a client to a group, including a public encryption key and a signature key (both stored in the KeyPackage's LeafNode object) 🔐 A Welcome message gives a new member the info they need to set up their state for the epoch they were added in 🎉

Of course, most (but not all) apps use MLS to send encrypted group messages 💌 An application message is an MLS message with an arbitrary application payload.

Finally, a PublicMessage contains an integrity-protected MLS handshake message, while a PrivateMessage contains a confidential, integrity-protected handshake or application message 🔒

For a more detailed explanation of these terms, check out the MLS protocol specification [RFC9420] 📖 that's the end of part 1!!

2.2. Abstract Services ✨

okay so MLS is built to run inside a messaging service, and that service could be one single provider, a federated system, or some kind of peer-to-peer setup 🌈 no cap, MLS doesn't care which. The service has to provide two things so clients can actually talk to each other with MLS 💅

• An Authentication Service (AS) 🔐 is the one that vouches for the link between application-meaningful identifiers and the public key material MLS uses for authentication. It also has to be able to make credentials that encode those links, and check the credentials that MLS clients hand over ✔️
• A Delivery Service (DS) 🚚 receives messages and passes them along to group members. For group messaging, the DS may also act as a "broadcaster" 📣, which is when the sender sends one message and the DS forwards it to each recipient in the group. The DS is also responsible for storing and delivering the initial public key material that MLS clients need before they can get started on the group secret key establishment that's part of MLS 🗝️

For presentation purposes, this document treats the AS and DS as conventional network services. 🎀 But MLS does NOT require a specific implementation for either one. Like, they can live on the same server or on different servers, they can be split between server and client components, and they might even involve some action from users 🙈 For example:

• Several secure messaging services today give you a centralized DS and rely on manually comparing clients' public keys as the AS 🤳
• MLS clients connected to a peer-to-peer network could set up a decentralized DS by sending MLS messages over that network 🦋
• In an MLS group using a Public Key Infrastructure (PKI) for authentication, the AS would be made up of the certificate issuance and validation processes. Both of those involve logic inside MLS clients plus various existing PKI roles (e.g., Certification Authorities) 🏛️

It's important to note that the AS can be completely abstract if the service provider lets MLS clients generate, distribute, and validate credentials themselves 💜 Same goes for the DS: it can be completely abstract if users are able to distribute credentials and messages without relying on a central DS (as in a peer-to-peer system). Note, though, that in those scenarios, clients will need to implement logic that assures the delivery properties required of the DS (see Section 5.2). 🧚

Figure 1 shows how these concepts relate, with three clients and one group. Clients 2 and 3 are part of the group, and client 1 isn't part of any group 🌸

    +----------------+    +--------------+
    | Authentication |    |   Delivery   |
    |  Service (AS)  |    | Service (DS) |
    +----------------+    +-------+------+
                         /        |       \            Group
                        / ........|........\................
                       /  .       |         \              .
             +--------+-+ .  +----+-----+    +----------+  .
             | Client 1 | .  | Client 2 |    | Client 3 |  .
             +----------+ .  +----------+    +----------+  .
                          .   Member 1        Member 2     .
                          .                                .
                          ..................................

              Figure 1: A Simplified Messaging System

---

3. Overview of Operation 🍓

Figure 2 shows how an example group gets formed with Alice, Bob, and Charlie, where Alice is the one driving the creation of the group 👑

Alice     Bob       Charlie                     AS        DS

Create account --------------------------------->               |
<------------------------------------- Credential               |
          Create account ----------------------->               | Step 1
          <--------------------------- Credential               |
                    Create account ------------->               |
                    <----------------- Credential               |

Initial Keying Material ----------------------------------->    |
          Initial Keying Material ------------------------->    | Step 2
                    Initial Keying Material --------------->    |

Get Bob Initial Keying Material --------------------------->    |
<------------------------------- Bob Initial Keying Material    |
Add Bob to group ------------------------------------------>    | Step 3
Welcome(Bob) ---------------------------------------------->    |
          <-------------------------------- Add Bob to group    |
          <------------------------------------ Welcome(Bob)    |

Get Charlie Initial Keying Material ----------------------->    |
<--------------------------- Charlie Initial Keying Material    |
Add Charlie to group -------------------------------------->    |
Welcome(Charlie) ------------------------------------------>    | Step 4
          <---------------------------- Add Charlie to group    |
                     <----------------- Add Charlie to group    |
                     <--------------------- Welcome(Charlie)    |

                  Figure 2: Group Formation Example

This process goes like this 💖

3.1. Step 1: Account Creation 🪪

Alice, Bob, and Charlie create accounts with a service provider and get credentials from the AS. This is a one-time setup phase ✨

3.2. Step 2: Initial Keying Material 🗝️

Alice, Bob, and Charlie authenticate to the DS and store some initial keying material, which is used to send them encrypted messages for the first time. This keying material is authenticated with their long-term credentials. In principle this keying material can be reused for multiple senders, but for forward secrecy it's way better to refresh it regularly so each sender can use a new key and delete older keys 🔄

3.3. Step 3: Adding Bob to the Group 🧁

When Alice wants to create a group that includes Bob, she first uses the DS to look up his initial keying material. Then she generates two messages:

• A message to the entire group (which at this point is just her and Bob) that adds Bob to the group.
• A Welcome message just to Bob, encrypted with his initial keying material, that includes the secret keying information he needs to join the group 🔑

She sends both of these messages to the DS, which is responsible for sending them to the right people. Note that MLS security does NOT depend on the DS forwarding the Welcome message only to Bob, since it's encrypted for him. It's just not necessary for the other group members to receive it 🙃

3.4. Step 4: Adding Charlie to the Group 🌷

If Alice then wants to add Charlie, she follows a similar procedure to Bob's. She first uses the DS to look up his initial keying material, then generates two messages:

• A message to the entire group (consisting of her, Bob, and Charlie) adding Charlie to the group.
• A Welcome message just to Charlie, encrypted with his initial keying material, that includes the secret keying information he needs to join the group 🎁

When this is done, we have a group with Alice, Bob, and Charlie, which means they share a single encryption key that can be used to send messages or to key other protocols 🌈

3.5. Other Group Operations 🛠️

Once the group exists, clients can do other stuff too, like:

• sending a message to everyone in the group 💌
• receiving a message from someone in the group 📥
• adding one or more clients to an existing group ➕
• removing one or more members from an existing group ➖
• updating their own key material 🔁
• leaving a group (by asking to be removed) 👋

Importantly, MLS does NOT enforce any access control on group operations itself. For instance, any member of the group can send a message to add a new member or to evict an existing one. This is different from designs where there's a single group controller who can modify the group 👑 MLS-using applications are responsible for setting their own access control policies. For example, if only the group administrator is allowed to change group members, then it's the application's job to tell members about this policy and who the administrator is 📢

3.6. Proposals and Commits 📜

The general pattern for any change to the group state (e.g., adding or removing a user) is two messages 👯

Proposal: This message describes the change to be made (e.g., add Bob to the group) but does NOT actually change anything 🙅

Commit: This message changes the group state to include the changes described in a set of proposals 🎉

The simplest pattern is for a client to just send a Commit that contains one or more Proposals. For instance, Alice could send a Commit with the Proposal Add(Bob) embedded to add Bob to the group. But sometimes one client sends a Proposal and another sends the matching Commit. For example, Bob might want to remove himself from the group and send a Remove proposal to do it (see Section 12.1.3 of [RFC9420]). Because Bob cannot send the Commit, an existing member has to do that 🫶 Commits can apply to multiple valid Proposals, in which case all the listed changes get applied 💅

A Commit can also apply to an empty set of Proposals, in which case it just updates the cryptographic state of the group without changing its membership 🔐

3.7. Users, Clients, and Groups 🦋

It's natural to think of a messaging system as groups of users, maybe using different devices, but in MLS the basic unit is not the user, it's the "client" 📱 Formally, a client is a set of cryptographic objects made of public values like a name (an identity), a public encryption key, and a public signature key. As usual, a user shows they own a client by demonstrating knowledge of the associated secret values 🕵️

In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does NOT assume this. Instead, a user may have multiple clients with the same identity and different keys. In that case, each client has its own cryptographic state, and it's up to the application to decide how to show this to users. For instance, it might render messages to and from a given user identically no matter which client they're tied to, or it might choose to tell them apart 💁 It's also possible for multiple clients belonging to the same user to share state, as described in Section 8.2.4 🤝

When a client is part of a group, it's called a member. A group in MLS is defined as the set of clients that know the shared group secret established in the group key establishment phase. Note that until a client has been added to the group and contributed to the group secret in a way other members can verify, the other members cannot assume that client is a member of the group. For example, the newly added member might not have received the Welcome message, or might have been unable to decrypt it for some reason 😭

4. Authentication Service ✨

okay so the Authentication Service (AS) has to do three jobs, and they're all lowkey so important 🔐💖

1. Issue credentials to clients that attest to bindings between identities and signature key pairs. 🎀
2. Enable a client to verify that a credential presented by another client is valid with respect to a reference identifier. 🔍
3. Enable a group member to verify that a credential represents the same client as another credential. 🫶

A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key bound by its credential. that's the whole vibe of signing, bestie 🖋️✨

The AS is considered an abstract layer by the MLS specification 🦋. Part of this service could be, for instance, running on the members' devices, while another part is a separate entity entirely. The following examples show how wide this concept can go:

• A PKI could be used as an AS [RFC5280]. The issuance function would be provided by the certificate authorities in the PKI, and the verification function would correspond to certificate verification by clients. 🏛️
• Several current messaging applications rely on users verifying each other's key fingerprints for authentication. In this scenario, the issuance function is simply the generation of a key pair (i.e., a credential is just an identifier and public key, with no information to assist in verification). The verification function is the application function that enables users to verify keys. 🙈
• In a system based on end-user Key Transparency (KT) [KT], the issuance function would correspond to the insertion of a key in a KT log under a user's identity. The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to monitor and control which keys are associated with their identity. 📜

By the nature of its role in MLS authentication, the AS is invested with a large amount of trust 👑, and the compromise of the AS could allow an adversary to, among other things, impersonate group members. 💀 We discuss security considerations regarding the compromise of the different AS functions in detail in Section 8.4.3. Please go read that one, it's serious.

The association between members' identities and their signature keys is fairly flexible in MLS. As noted above, there is no requirement that all clients belonging to a given user have the same signature key (in fact, having duplicate signature keys in a group is forbidden 🚫). A member can also rotate the signature key they use within a group. These mechanisms allow clients to use different signature keys in different contexts and at different points in time, providing unlinkability and post-compromise security benefits. ✨ Some security trade-offs related to this flexibility are discussed in Section 8.

In many applications, there are multiple MLS clients that represent a single entity, such as a human user with a mobile and desktop version of an application 📱💻. Often, the same set of clients is represented in exactly the same list of groups. In applications where this is the intended situation, other clients can check that a user is consistently represented by the same set of clients. This would make it more difficult for a malicious AS to issue fake credentials for a particular user, because clients would expect the credential to appear in all groups of which the user is a member. 🕵️‍♀️ If a client credential does not appear in all groups after some relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge. 🚩 Due to the asynchronous nature of MLS, however, there may be transient inconsistencies in a user's client set, so correlating users' clients across groups is more of a detection mechanism than a prevention mechanism. 🌸

5. Delivery Service 🚚

okay the Delivery Service (DS) plays two major roles in MLS 💅

• As a directory service, providing the initial keying material for clients to use. This allows a client to establish a shared key and send encrypted messages to other clients even if they're offline. 📬
• Routing MLS messages among clients. 🗺️

While MLS depends on correct behavior by the AS in order to provide endpoint authentication and hence confidentiality of the group key, these properties do not depend on correct behavior by the DS. Even a malicious DS cannot add itself to groups or recover the group key. 🛡️ However, depending precisely on how MLS is used, the DS may be able to determine group membership or prevent changes to the group from taking place (e.g., by blocking group change messages). 🙃

5.1. Key Storage and Retrieval 🗄️

Upon joining the system, each client stores its initial cryptographic key material with the DS. This key material, called a KeyPackage, advertises the functional abilities of the client (e.g., supported protocol versions, supported extensions, etc.) and the following cryptographic information:

• A credential from the AS attesting to the binding between the identity and the client's signature key.
• The client's asymmetric encryption public key.

All the parameters in the KeyPackage are signed with the signature private key corresponding to the credential. As noted in Section 3.7, users may own multiple clients, each with their own keying material. Each KeyPackage is specific to an MLS version and cipher suite, but a client may want to offer support for multiple protocol versions and cipher suites. So there may be multiple KeyPackages stored by each user for a mix of protocol versions, cipher suites, and end-user devices. 🧩

When a client wishes to establish a group or add clients to a group, it first contacts the DS to request KeyPackages for each of the other clients, authenticates the KeyPackages using the signature keys, includes the KeyPackages in Add proposals, and encrypts the information needed to join the group (the _GroupInfo_ object) with an ephemeral key. It then separately encrypts the ephemeral key with the public encryption key (init_key) from each KeyPackage. 🔑 When a client requests a KeyPackage in order to add a user to a group, the DS should provide the minimum number of KeyPackages necessary to satisfy the request. For example, if the request specifies the MLS version, the DS might provide one KeyPackage per supported cipher suite, even if it has multiple such KeyPackages, so the corresponding client can be added to multiple groups before needing to upload more fresh KeyPackages. 🧁

In order to avoid replay attacks and provide forward secrecy for messages sent using the initial keying material, KeyPackages are intended to be used only once, and init_key is intended to be deleted by the client after decryption of the Welcome message. ⏳ The DS is responsible for ensuring that each KeyPackage is only used to add its client to a single group, with the possible exception of a "last resort" KeyPackage that is specially designated by the client to be used multiple times. Clients are responsible for providing new KeyPackages as necessary in order to minimize the chance that the "last resort" KeyPackage will be used. 🆘

Recommendation: Ensure that "last resort" KeyPackages don't get used by provisioning enough standard KeyPackages. 💡

Recommendation: Rotate "last resort" KeyPackages as soon as possible after being used or if they have been stored for a prolonged period of time. Overall, avoid reusing "last resort" KeyPackages as much as possible. 🔄

Recommendation: Ensure that the client for which a "last resort" KeyPackage has been used is updating leaf keys as early as possible. 🍃

Recommendation: Ensure that clients delete the private component of their init_key after processing a Welcome message, or after the rotation of the "last resort" KeyPackage. 🧹

Overall, it needs to be noted that KeyPackages need to be updated when signature keys are changed. 📝

5.2. Delivery of Messages 📨

The main responsibility of the DS is to ensure delivery of messages. Some MLS messages need only be delivered to specific clients (e.g., a Welcome message initializing a new member's state), while others need to be delivered to all the members of a group. The DS may enable the latter delivery pattern via unicast channels (sometimes known as "client fanout"), broadcast channels ("server fanout"), or a mix of both. 📡

For the most part, MLS does not require the DS to deliver messages in any particular order. Applications can set policies that control their tolerance for out-of-order messages (see Section 7), and messages that arrive significantly out of order can be dropped without otherwise affecting the protocol. There are two exceptions to this. First, Proposal messages should all arrive before the Commit that references them. Second, because an MLS group has a linear history of epochs, the members of the group must agree on the order in which changes are applied. Concretely, the group must agree on a single MLS Commit message that ends each epoch and begins the next one. 🧵

In practice, there's a realistic risk of two members generating Commit messages at the same time, based on the same epoch, and both attempting to send them to the group at the same time. 😬 The extent to which this is a problem, and the appropriate solution, depend on the design of the DS. Per the CAP theorem [CAPBR], there are two general classes of distributed systems that the DS might fall into:

• Consistent and Partition-tolerant, or Strongly Consistent, systems, which can provide a globally consistent view of data but have the inconvenience of clients needing to handle rejected messages. 🧱
• Available and Partition-tolerant, or Eventually Consistent, systems, which continue working despite network issues but may return different views of data to different users. 🌊

Strategies for sequencing messages in strongly and eventually consistent systems are described in the next two subsections. Most DSs will use the strongly consistent paradigm, but this remains a choice that can be handled in coordination with the client and advertised in the KeyPackages. 🤝

However, note that a malicious DS could also reorder messages or provide an inconsistent view to different users. The "generation" counter in MLS messages provides per-sender loss detection and ordering that cannot be manipulated by the DS, but this does not provide complete protection against partitioning. A DS can cause a partition in the group by partitioning key exchange messages. This can be detected only by out-of-band comparison (e.g., confirming that all clients have the same epoch_authenticator value). A mechanism for more robust protections is discussed in [EXTENSIONS]. 🕳️

Other forms of DS misbehavior are still possible that are not easy to detect. For instance, a DS can simply refuse to relay messages to and from a given client. Without some sort of side information, other clients cannot generally detect this form of Denial-of-Service (DoS) attack. 🙀

5.2.1. Strongly Consistent ✨

okay so with this approach 💖 the DS makes sure some types of incoming messages have a linear order, and every member agrees on that order 🔥. The Delivery Service is trusted to break ties when two members send a Commit at the same time 👑.

As an example, there could be an "ordering server" DS that broadcasts every message it receives to all users and makes sure every client sees messages in the same order 🦋. This lets clients apply only the first valid Commit for an epoch and ignore any later Commits 💅. Clients that send a Commit then wait to apply it until the Delivery Service broadcasts it back to them, assuming they don't receive another Commit first 🫶.

Alternatively, the DS can rely on the epoch and content_type fields of an MLSMessage to give an order only to handshake messages. It can also filter or reject redundant Commit messages proactively so they never get broadcast 🙈. There is some risk with filtering (lowkey a big one 💀), and we'll dig into that more in Section 5.3.

5.2.2. Eventually Consistent

this one is giving flexible energy 🌈. With this approach, the DS is built in a way that can be way more available or performant than a strongly consistent system, but it offers weaker consistency guarantees. Messages may reach different clients in different orders and with different amounts of latency, so clients are responsible for reconciling things themselves 🧚.

This type of DS might show up when group members send each message to each other member individually, or when a distributed peer-to-peer network is used to broadcast messages 🍓.

Upon receiving a Commit from the DS, clients can either:

1. Pause sending new messages for a short amount of time to account for a reasonable degree of network latency, and see if any other Commits arrive for the same epoch. If multiple Commits arrive, clients can use a deterministic tie-breaking policy to decide which one to accept, and then resume sending messages as normal 🎀.
2. Accept the Commit immediately, but keep a copy of the previous group state for a short period of time. If another Commit for a past epoch arrives, clients use a deterministic tie-breaking policy to decide whether to keep using the Commit they originally accepted or revert and use the later one. Note that any copies of previous or forked group states must be deleted within a reasonable amount of time to ensure that the protocol provides forward secrecy. 🚨

If the Commit references an unknown proposal, group members may need to ask the DS or other group members individually for the contents of the proposal 🔍.

5.2.3. Welcome Messages

this part is so important bestie 😭. Whenever a commit adds new members to a group, MLS requires the committer to send a Welcome message to the new members. Applications should ensure that Welcome messages are coupled with the tie-breaking logic for commits (see Sections 5.2.1 and 5.2.2). That means when multiple commits are sent for the same epoch, applications need to make sure that only Welcome messages corresponding to the commit that "succeeded" get processed by new members ✨.

This matters extra when groups are being reinitialized. When a group is reinitialized, it restarts with a different protocol version and/or cipher suite but identical membership 🦋. Whenever an authorized member sends and commits a ReInit proposal, the existing group is immediately frozen, and a new group with a new group_id gets created 🧊.

Ideally, the same member who committed the ReInit proposal would create the new group, including sending Welcome messages for the new group to all of the previous group's members 💅. However, this operation isn't always atomic. That means a member could go offline after committing a ReInit proposal but before creating the new group. If that happens, another member needs to continue the reinitialization by creating the new group and sending out Welcome messages 🫶.

Here's the tricky bit: this can create a race condition, where multiple members try to continue the reinitialization at the same time, and members receive multiple Welcome messages for each attempt at reinitializing the same group 😵. Making sure everyone agrees on which reinitialization attempt is "correct" is the key to stopping this from causing forks 🔥.

---

5.3. Invalid Commits

okay this section is serious, so read it carefully 🚨. Sometimes a malicious or buggy client sends a Commit that not every group member accepts, and the DS can't detect this and reject the Commit. For example, a buggy client might send an encrypted Commit with an invalid set of proposals. Or a malicious client might send a malformed Commit of the form described in Section 16.12 of [RFC9420] 🙈.

When the DS is trying to filter redundant Commits, it might update its internal state under the assumption that a Commit succeeded. That can leave it out of sync with the group members 💀. For example, the DS might think the current epoch is now n+1 and reject any commits from other epochs, while the members think the epoch is n. As a result, the group gets stuck, and no member can send a Commit that the DS will accept 😭.

These "desynchronization" problems can happen even when the DS takes no stance on which Commit is "correct" for an epoch. The DS can let clients choose between Commits, for example by providing Commits in the order received and letting clients reject any Commits that violate their view of the group's policies 🦋. That way, all honest and correctly implemented clients arrive at the same "first valid Commit" and choose to process it. Malicious or buggy clients that process a different Commit end up with a forked view of the group 🌸.

When these desynchronizations happen, the application may choose to take action to restore the functionality of the group. Those actions can have security implications too 👀. For example, a client developer might have a client automatically rejoin a group using an external join when it processes an invalid Commit. In that case, though, the client trusts that the GroupInfo provided by the DS faithfully represents the state of the group, and not, say, an earlier state containing a compromised leaf node. The DS may also be able to trigger this condition by deliberately sending the victim an invalid Commit. In certain scenarios, this trust can let the DS or a malicious insider undermine the post-compromise security guarantees provided by MLS 💔.

Recovery actions can also have availability and DoS implications 🚫. For example, if a recovery mechanism relies on external joins, a malicious member who deliberately posts an invalid Commit could also post a corrupted GroupInfo object to stop victims from rejoining the group. So careful analysis of security implications should be made for any system that recovers from desynchronization 🛡️.

---

6. Functional Requirements 👑

MLS is designed as a large-scale group messaging protocol, so it aims to provide both performance and security (e.g., integrity and confidentiality) to its users 💜. Messaging systems that implement MLS support conversations with two or more members, and they aim to scale to groups with tens of thousands of members, which typically include many users with multiple devices 🌈.

6.1. Membership Changes

membership is the main character of this section ✨. MLS aims to provide agreement on group membership, meaning all group members have agreed on the list of current group members 📋.

Some applications may want to enforce Access Control Lists (ACLs) to limit adding or removing group members to privileged clients or users 🔐. Others may want to require authorization from the current group members or a subset of them. Such policies can be implemented at the application layer, on top of MLS. Either way, MLS does not allow or support adding or removing group members without informing all other members 📣.

Membership of an MLS group is managed at the level of individual clients. In most cases, a client corresponds to a specific device a user has 📱. If a user has multiple devices, they'll generally be represented in a group by multiple clients (although applications could choose to have devices share keying material). If an application wants to do operations at the level of users, it's up to the application to track which clients belong to a given user and make sure they're added or removed consistently 🧩.

MLS provides two mechanisms for changing the membership of a group. The primary mechanism is for an authorized member of the group to send a Commit that adds or removes other members 👑. A secondary mechanism is an "external join": a member of the group publishes certain information about the group, which a new member can use to construct an "external" Commit message that adds the new member to the group 🦋. (There's no similarly unilateral way for a member to leave the group. They must be removed by a remaining member 🙃.)

With both mechanisms, membership changes are initiated from inside the group. When members make changes directly, that's obvious. External joins are authorized indirectly: a member publishing a GroupInfo object authorizes anyone who has access to that GroupInfo object to join, subject to whatever access control policies the application applies for external joins 🔑.

Both types of joins are done via a Commit message, which could be blocked by the DS or rejected by clients if the join isn't authorized. The former approach requires that Commits be visible to the DS. The latter approach requires that clients all share a consistent policy. In the unfortunate event that an unauthorized member gets in, MLS lets any member remove them 🚪.

Application setup may also determine other criteria for membership validity. For example, per-device signature keys can be signed by an identity key recognized by other participants. If a certificate chain is used to authenticate device signature keys, then revocation by the owner adds another way to prompt membership removal 📜.

An MLS group's secrets change on every change of membership, so each client only has access to the secrets used by the group while they're a member 🔒. Messages sent before a client joins, or after they're removed, are protected with keys the client can't access 🚫. Compromising a member who was removed from a group doesn't affect the security of messages sent after their removal 💪. Messages sent during the client's membership are also secure, as long as the client has properly implemented the MLS deletion schedule. That schedule calls for the secrets used to encrypt or decrypt a message to be deleted after use, along with any secrets that could be used to derive them 🗑️✨.

6.2. Parallel Groups 👯

okay so any user or client can be in several groups at once, and that's totally normal 💅 The members of one group may or may not overlap with the members of another, whatever the vibe is ✨ MLS guarantees that the FS and PCS goals within a given group stay maintained and aren't weakened just because a user is also in other groups 🫶 However, actions in other groups don't strengthen those FS and PCS guarantees inside a given group either 🙈 For example, a key update in one group after a device compromise does not give PCS healing in other groups. Each group has to be updated separately to hit these security goals 😭 This also applies to future groups a member hasn't joined yet, which are unaffected by updates in the current groups 🧚

Applications can level up connectivity among parallel groups by asking for periodic key updates from a user across every group they're in 💖

MLS has a pre-shared key (PSK) mechanism that can link healing properties among parallel groups ⭐ Say a common member M of two groups A and B does a key update in group A but not in group B. That update gives M PCS in group A 🦋 If a PSK is exported from group A and injected into group B, then some of those PCS properties carry over to group B, since the PSK and the secrets derived from it are only known to the new, updated version of M, not the old, possibly compromised version of M 👑

6.3. Asynchronous Usage 🕰️

Nothing in MLS requires two distinct clients or members to be online at the same time 🌙 Members in MLS-protected chats can update the group's keys, add or remove new members, and send messages without waiting for another user to reply 💌

Messaging systems that implement MLS have to provide a transport layer that delivers messages asynchronously and reliably 📬

6.4. Access Control 🔐

Because every client in a group (a member) has access to the shared cryptographic material, the MLS protocol lets each member of the messaging group perform operations 👀 Still, every service or infrastructure controls the policies applied to its own clients 💅 Applications that manage MLS clients can be configured to allow specific group operations. On one hand, an app could decide that a group administrator is the only member allowed to perform Add and Remove operations 🎀 On the other hand, in settings like open discussion forums, joining can be allowed for anyone 🌈

MLS application messages are always encrypted 🔒 MLS handshake messages, though, can be sent either encrypted (in an MLS PrivateMessage) or unencrypted (in an MLS PublicMessage) 🤷‍♀️ Applications may be designed so that intermediaries need to see handshake messages, for example to enforce policy on which commits are allowed, or to provide MLS ratchet tree data in a central location 🧚 If handshake messages are unencrypted, it's especially important that they be sent over a channel with strong transport encryption (see Section 8) in order to prevent external attackers from monitoring the status of the group 😱 Applications that use unencrypted handshake messages may take additional steps to reduce the amount of metadata exposed to the intermediary 🫧 Everything else being equal, encrypted handshake messages provide stronger privacy properties than unencrypted ones, since they stop intermediaries from learning about the structure of the group 🔐

If handshake messages are encrypted, any access control policies must be applied at the client. So the application must make sure the access control policies are consistent across all clients to keep them in sync 🔄 If two different policies were applied, the clients might not accept or reject a group operation and end up in different cryptographic states, which breaks their ability to communicate 💀

Recommendation: Avoid using inconsistent access control policies, especially when using encrypted group operations.

MLS allows actors outside the group to influence it in two ways: external signers can submit proposals for changes to the group, and new joiners can use an external join to add themselves 🚪 The external_senders extension makes sure all members agree on which signers are allowed to send proposals, but any other policies must be assured to be consistent, as noted above 📋

Recommendation: Have an explicit group policy setting the conditions under which external joins are allowed.

6.5. Handling Authentication Failures 🚨

Within an MLS group, every member is authenticated to every other member by means of credentials issued and verified by the AS 🪪 MLS doesn't prescribe what actions, if any, an application should take when a group member presents an invalid credential 🤔 For example, an application may require that member to be immediately evicted, or it may allow some grace period for the problem to be fixed. To avoid operational problems, it's important for all clients in a group to have a consistent view of which credentials in the group are valid and how to respond to invalid ones 📏

Recommendation: Have a uniform credential validation process to ensure that all group members evaluate other members' credentials in the same way.

Recommendation: Have a uniform policy for how invalid credentials are handled.

In some authentication systems, a previously valid credential can become invalid over time 📆 For example, in a system based on X.509 certificates, credentials can expire or be revoked. The MLS update mechanisms let a client replace an old credential with a new one, and this is best done before the old credential becomes invalid ⏰

Recommendation: Proactively rotate credentials, especially if a credential is about to become invalid.

6.6. Recovery After State Loss 🩹

Group members whose local MLS state is lost or corrupted can reinitialize their state by rejoining the group as a new member and removing the member representing their earlier state 🔁 An application can require that a client performing such a reinitialization prove its prior membership with a PSK that was exported from the previous state 🔑

There are a few practical challenges to this approach 🧗 For example, the application needs to make sure all members have the required PSK, including any new members who joined since the epoch in which the PSK was issued. And of course, if the PSK is lost or corrupted along with the member's other state, it can't be used to recover 😩

Reinitializing this way does not give the member access to group messages exchanged during the state loss window, but it does enable proof of prior membership in the group 🪞 Applications may choose various configurations for providing lost messages to valid group members who are able to prove prior membership 💌

6.7. Support for Multiple Devices 📱💻

It's common for users within a group to own multiple devices 📱 A new device can be added to a group and be considered a new client by the protocol. This client won't get access to the history, even if it's owned by someone who owns another member of the group 🙅‍♀️ MLS doesn't directly support restoring history in this case, but applications can choose to provide such a mechanism outside of MLS 🛠️ If used, such mechanisms may reduce the FS and PCS guarantees provided by MLS 💔

6.8. Extensibility 🧩

The MLS protocol provides several extension points where additional information can be provided. Extensions to KeyPackages let clients disclose additional information about their capabilities 🛎️ Groups can also have extension data associated with them, and the group agreement properties of MLS will confirm that all members of the group agree on the content of these extensions 🤝

6.9. Application Data Framing and Type Advertisements 🖼️

Application messages carried by MLS are opaque to the protocol and can contain arbitrary data 📦 Each application that uses MLS needs to define the format of its application_data and any mechanism necessary to determine the format of that content over the lifetime of an MLS group 📜 In many applications, this means managing format migrations for groups with multiple members who may each be offline at unpredictable times 😴

Recommendation: Use the content mechanism defined in [EXTENSIONS], unless the specific application defines another mechanism that more appropriately addresses the same requirements for that application of MLS.

The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted 🏷️ Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with 🛡️

6.10. Federation 🌐

The protocol aims to be compatible with federated environments 🌍 While this document doesn't specify all the mechanisms required for federation, multiple MLS implementations can interoperate to form federated systems if they use compatible authentication mechanisms, cipher suites, application content, and infrastructure functionalities 🤝 Federation is described in more detail in [FEDERATION] 📖

6.11. Compatibility with Future Versions of MLS 🔮

It's important that multiple versions of MLS be able to coexist in the future 🦋 So MLS offers a version negotiation mechanism. This mechanism prevents version downgrade attacks, where an attacker would actively rewrite messages with a lower protocol version than the messages originally offered by the endpoints 🚫 When multiple versions of MLS are available, the negotiation protocol guarantees that the creator is able to select the best version out of those supported in common by the group 👑

In MLS 1.0, the creator of the group is responsible for selecting the best cipher suite supported across clients 🧁 Each client is able to verify availability of protocol version, cipher suites, and extensions at all times once it has at least received the first group operation message ✅

Each member of an MLS group advertises the protocol functionality they support 📣 These capability advertisements can be updated over time, e.g., if client software is updated while the client is a member of a group 🆙 Thus, in addition to preventing downgrade attacks, the members of a group can also observe when it is safe to upgrade to a new cipher suite or protocol version 🌟

7. Operational Requirements ✨

Okay so, MLS is a security layer, and it has to be plugged into an actual application 🔌 A fully working MLS deployment has to make a bunch of decisions about how it gets configured and run. And if two deployments want to talk to each other, they need to make compatible decisions 🫶 This section is the list of everything outside the protocol spec that still has to line up inside one deployment, or between two deployments that want to interoperate. Bestie, this is the boring-but-essential homework 📚💅

The protocol can negotiate protocol versions, cipher suites, extensions, credential types, and extra proposal types, which is honestly so iconic 👑 For two deployments to interoperate, they MUST have overlapping support in each of these categories. The required_capabilities extension (Section 7.2 of [RFC9420]) is the clever bit here: it can keep a group supporting certain functionality even if the clients in it aren't actually using that functionality right now, so you can reach a wider set of clients 🦋

MLS also leans on some network services. They need to be compatible too, or two deployments built on them won't interoperate 🌸

• An Authentication Service, which is fully described in Section 4, defines which credential types can be used in a deployment and gives you ways to:
  1. Issue new credentials with a relevant credential lifetime,
  2. Validate a credential against a reference identifier,
  3. Validate whether two credentials represent the same client, and
  4. Optionally revoke credentials that are no longer authorized.
• A Delivery Service, which is fully described in Section 5, gives you ways to:
  1. Deliver messages for a group to all members of the group.
  2. Deliver Welcome messages to new members of a group.
  3. Upload new KeyPackages for a user's own clients.
  4. Download KeyPackages for specific clients. Typically, KeyPackages are used once and then consumed 🍓
• Additional services may or may not be needed, depending on the app design:
  • When group operations aren't encrypted, the DS can observe and keep a copy of the public group state 👀 This is handy for either (1) clients that can't put the full public state in a Welcome message when inviting someone, or (2) clients that need to recover after losing their state. Public state can include privacy-sensitive stuff like group members' credentials and related public keys, so services need to think carefully about the privacy impact of storing that data on the DS 🙈
  • If external joiners are allowed, there MUST be a way to publish a serialized GroupInfo object (with an external_pub extension) that corresponds to a specific group and epoch, and a way to keep that object in sync with the group's state 🔄
  • If an application doesn't allow external joining, it MAY instead provide a way for outside users to ask group members (or a designated service) to add them to the group 🙋‍♀️
  • If the application uses PSKs that members might not have access to (for example, to control entry into the group, or to prove membership in the group in the past, as discussed in Section 6.6), there MUST be a way to distribute these PSKs to group members who might not have them, like if they joined after the PSK was generated 🔐
  • If an application wants to detect and possibly discipline members who send malformed commits with the goal of corrupting a group's state, there MUST be a way to report and validate malformed commits 🚨

MLS REQUIRES a set of parameters to be defined, and they MUST be the same for two implementations to interoperate 📏

• The maximum total lifetime that's acceptable for a KeyPackage.
• How long to store the resumption PSK for past epochs of a group.
• The degree of tolerance allowed for out-of-order message delivery:
  • How long to keep unused nonce and key pairs for a sender.
  • A maximum number of unused key pairs to keep.
  • A maximum number of steps that clients will move a secret tree ratchet forward in response to a single message before rejecting it.
  • Whether to buffer messages that can't be understood yet because other messages haven't arrived first and, if so, how many and for how long. For example, Commit messages that arrive before a proposal they reference, or application messages that arrive before the Commit starting an epoch 🌀

If implementations differ in these parameters, they'll still kinda interoperate, but they may run into unexpected failures in certain situations, like extensive message reordering 😭

MLS provides the following places where an application can store arbitrary data. The format and intention of any data in these places MUST align for two deployments to interoperate 🗂️

• Application data, sent as the payload of an encrypted message.
• Additional authenticated data, sent unencrypted inside an otherwise encrypted message.
• Group IDs, chosen by group creators and used to uniquely identify a group.
• Application-level identifiers of public key material (specifically, the application_id extension as defined in Section 5.3.3 of [RFC9420]).

MLS REQUIRES a set of policies to be defined, which restrict the acceptable behaviors in a group. These policies MUST be consistent between deployments for them to interoperate 📜

• A policy on which cipher suites are acceptable.
• A policy on any mandatory or forbidden MLS extensions.
• A policy on when to send proposals and commits in plaintext instead of encrypted.
• A policy on which proposals are valid to have in a commit, including but not limited to:
  • When a member is allowed to add or remove other members of the group.
  • When, and under what circumstances, a reinitialization proposal is allowed.
  • When proposals from external senders are allowed, and how to authorize those proposals.
  • When external joiners are allowed, and how to authorize those external commits.
  • Which other proposal types are allowed.
• A policy on when members SHOULD commit pending proposals in a group.
• A policy on how to protect and share the GroupInfo objects needed for external joins.
• A policy for when two credentials represent the same client, distinguishing the following two cases:
  • When there are multiple devices for a given user.
  • When a single device has multiple signature keys, for instance if the device has keys corresponding to multiple overlapping time periods.
• A policy on how long to let a member stay in a group without updating its leaf keys before removing them 🕰️

Finally, there are some additional application-defined behaviors that are partly up to each app's own call, but may overlap with interoperability 🎀

• When and how to pad messages.
• When to send a reinitialization proposal.
• How often clients should update their leaf keys.
• Whether to prefer sending full commits or partial/empty commits.
• Whether there should be a required_capabilities extension in groups.

---

8. Security and Privacy Considerations 🔐

Okay, this is the part where we get serious 🫣 MLS adopts the Internet threat model [RFC3552], which means it assumes the attacker has complete control of the network. The security services described in Section 8.2 are meant to hold up even against attackers who can:

• Monitor the entire network.
• Read unprotected messages.
• Generate, inject, and delete any message in the unprotected transport layer.

MLS SHOULD be run over a secure transport such as QUIC [RFC9000] or TLS [RFC8446], but the security guarantees of MLS do NOT depend on the transport. Yes, this is a departure from the usual design practice of trusting the transport 🙃 It's built this way because MLS is designed to stay secure even when network elements are compromised, especially the DS 💀

Generally, MLS is designed so the transport layer is there to keep metadata private from network observers, while the MLS protocol itself provides confidentiality, integrity, and authentication for the application data (which could pass through multiple systems). Extra properties like partial anonymity or deniability could also be achieved in specific architecture designs 🦋

And these guarantees are meant to degrade gracefully if the transport security links are compromised, or if clients and elements of the messaging system are compromised, as described in the rest of this section 🌈

8.1. Assumptions on Transport Security Links

As we said above, MLS gives the highest level of security when its messages are delivered over an encrypted transport. That stops attackers from selectively messing with MLS communications and protects the already limited metadata 🛡️ There's very little information in the unencrypted header of the MLS protocol message format for group operation messages, and application messages are always encrypted in MLS 💖

Recommendation: Use transports that provide reliability and metadata confidentiality whenever possible, e.g., by transmitting MLS messages over a protocol such as TLS [RFC8446] or QUIC [RFC9000].

MLS avoids needing to send the full list of recipients to the server for dispatching messages, because that list could contain tens of thousands of recipients 🤯 Header metadata in MLS messages typically consists of an opaque group_id, a numerical value that determines the epoch of the group (the number of changes that have been made to the group), and whether the message is an application message, a proposal, or a commit.

Even though some of this metadata isn't sensitive by itself, when it's correlated with other data, a network observer might be able to reconstruct sensitive information 👀 Using a secure channel to transfer this information stops a network attacker from accessing this MLS protocol metadata, as long as they can't compromise the secure channel 🔒

8.1.1. Integrity and Authentication of Custom Metadata

MLS provides an authenticated "Additional Authenticated Data" (AAD) field so applications can make data available outside a PrivateMessage while cryptographically binding it to the message 🎀

Recommendation: Use the "Additional Authenticated Data" field of the PrivateMessage instead of other unauthenticated ways of sending metadata through the infrastructure. If the data should be kept private, the infrastructure should use encrypted application messages instead 🫶

8.1.2. Metadata Protection for Unencrypted Group Operations

okay so, having no secure channel to swap MLS messages is a big deal for privacy 😬. if group operation messages go out unencrypted, anyone watching can look at the contents and signatures and start piecing together who's actually in the group 👀. not it! 🙅‍♀️

Recommendation: Never use the unencrypted mode for group operations without using a secure channel for the transport layer. 🔒💅

8.1.3. DoS Protection

ngl, we don't really think DoS resistance is the protocol's job 🤷‍♀️. still, it should not be possible for anyone besides the DS to pull off a trivial DoS attack that's hard to recover from 😤. the secure transport layer helps here, since it stops network attackers from selectively attacking MLS communications 🛡️.

in the centralized setting, DoS protection can usually be handled with tickets or cookies that identify users to a service for a certain number of connections 🎟️. this is lowkey iconic because it keeps anonymous clients from flooding the DS or the MLS clients with a ton of group operation messages 🌊.

Recommendation: Use credentials uncorrelated with specific users to help prevent DoS attacks, in a privacy-preserving manner. 🦋 Note that the privacy of these mechanisms has to be adjusted in accordance with the privacy expected from secure transport links. (See more discussion in the next section.) ✨

8.1.4. Message Suppression and Error Correction

as we said above, MLS is built to be pretty robust even when someone tampers within the secure transport, like if the DS is the one messing around 🧚. the confidentiality and authenticity properties of MLS stop the DS from reading or writing messages 🔐. MLS also has a few tools for spotting message suppression, with one caveat: suppression can't always be told apart from a plain transport failure 📡.

every encrypted MLS message carries a per-sender incrementing "generation" number 🔢. if a group member sees a gap in the generation sequence for a sender, they know they missed a message from that sender 👀. MLS also gives group members a way to send authenticated acknowledgments of application messages received within a group 💌.

as discussed in Section 5, the DS is trusted to pick the single Commit message that gets applied in each epoch from among the Commits sent by group members 👑. since only one Commit per epoch is meaningful, there's no point in the DS sending multiple Commits to clients 🙅. the risk still remains that the DS could misuse that power 😭.

8.2. Intended Security Guarantees

MLS aims to provide a bunch of security guarantees 💖. these cover authentication, plus confidentiality guarantees that vary in strength depending on the scenario 🌈.

8.2.1. Message Secrecy and Authentication

MLS enforces encryption of application messages, so it generally guarantees authentication and confidentiality for application messages sent in a group 🔐✨.

in particular, only other members of a given group can decrypt the payload of a given application message, and that payload includes info about the sender 🫶.

group members who get a message from another group member can authenticate that member as the sender and verify the message's integrity 🦋.

message content can be deniable if the signature keys are exchanged over a deniable channel before messages get signed 🎭.

depending on the group settings, handshake messages can be encrypted too. if they are, the same security guarantees apply 🔒.

MLS optionally lets you add padding to messages, which helps reduce how much an observer on the network can learn about the length of the plaintext 🎀.

8.2.2. Forward Secrecy and Post-Compromise Security

MLS gives extra protection for the secrecy of both past and future messages 🧁. the two cryptographic security properties behind this are forward secrecy (FS) and post-compromise security (PCS) 💜.

FS means that having access to all the encrypted traffic history, plus all current keying material on clients, still won't break the secrecy of messages older than the oldest key of the compromised client 🕰️. the catch: clients have to delete keys as soon as they've been used with the expected message 🗑️. otherwise, the secrecy of the messages and the security of MLS get considerably weakened 💀.

PCS means that if a group member's state gets compromised at some time t1 but that member does an update at some later time t2, then all MLS guarantees apply to messages the member sends after t2, and to messages other members send after they've processed the update 🔄🌸. for example, if an attacker learns all secrets Alice knows at time t1, including her long-term secret keys and all shared group keys, but Alice does a key update at time t2, then the attacker can't violate any of the MLS security properties once the updates are processed 🙌.

both of these properties hold even against compromised DSs and ASes, as long as some other mechanism for verifying keys is in use, such as Key Transparency [KT] 🔍✨.

confidentiality is mainly ensured on the client side 💅. because FS and PCS depend on actively deleting and replacing keying material, any client that stays offline for a long time may still be holding old keying material 😳. if that client gets compromised later, it becomes a threat to both FS and PCS 🚨.

MLS partly defends against this by having active members include new keying material 🌷. still, not much can be done on the inactive side, especially when the client hasn't processed messages 😔.

Recommendation: Mandate key updates from clients that are not otherwise sending messages, and evict clients that are idle for too long. 🧹✨

these recommendations cut down how well idle compromised clients can decrypt a potentially long run of messages sent after the compromise 🛑.

the precise details of such mechanisms are a matter of local policy and beyond the scope of this document 📋.

8.2.3. Non-Repudiation vs. Deniability

MLS gives strong authentication within a group, so a group member can't send a message that looks like it came from another group member 🙅‍♀️💯. some services also need a recipient to be able to prove to the service provider that a message came from a given client, so abuse can be reported 🚩. MLS supports both of these use cases 🫶. in some deployments, these services use mechanisms that let the receiver prove a message's origin to a third party, which is often called "non-repudiation" 📜.

roughly speaking, "deniability" is the opposite of "non-repudiation" 🎭. it's the property that you can't prove to a third party that a message came from a given sender 🤫. MLS doesn't make any claims about deniability 🙈. it may be possible to run MLS in ways that give certain deniability properties, but pinning down the specific requirements and the resulting notions of deniability needs further analysis 🔬.

8.2.4. Associating a User's Clients

when a user has multiple devices, the base MLS protocol only describes how to run each device as a separate client in the MLS groups the user belongs to 📱📱. so other group members can tell which of the user's devices sent each message, and therefore which device the user was on at the time 👀. they could also notice when the user adds or removes authorized devices from their account 😬. for some apps, that's an unacceptable breach of privacy 🚫.

this risk only shows up when the leaf nodes for the clients in question provide data that can be used to correlate the clients 🧩. one way to lower the risk is to only do client-level authentication within MLS 🎯. if user-level authentication is still wanted, the application would have to provide it through some other mechanism 🗝️.

it's also possible to keep user-level authentication while hiding info about the clients a user owns 🦋. this works by having the clients share cryptographic state, so they look like a single client within the MLS group 🫧. appearing as one client has privacy perks: it stops leaking which device sent a particular message and stops leaking the user's authorized devices 🙌. however, the application would need a synchronization mechanism so each client's state stays consistent across changes to the MLS group 🔁. flaws in that synchronization mechanism may hurt the user's ability to recover from a compromise of one of their devices 😱. in particular, state synchronization may make it easier for an attacker who has one compromised device to take exclusive control of a user's account, locking them out entirely and stopping them from recovering 🚨💀.

8.3. Endpoint Compromise

the MLS protocol takes a threat model that includes several forms of endpoint or client compromise 🧠. yes, adversaries are in a strong position once they've compromised an MLS client 😰. but there are still situations where security guarantees can be recovered, thanks to the PCS properties MLS achieves 🌈🔧.

in this section, we'll look at the consequences and recommendations for these compromise scenarios 📝:

• The attacker has access to a symmetric encryption key. 🔑
• The attacker has access to an application ratchet secret. 🪜
• The attacker has access to the group secrets for one group. 👥
• The attacker has access to a signature oracle for any group. 🔮
• The attacker has access to the signature key for one group. ✍️
• The attacker has access to all secrets of a user for all groups (full state compromise). 💥

8.3.1. Compromise of Symmetric Keying Material

as described above, each MLS epoch creates a new group secret 🗝️.

those group secrets are then used to create a per-sender ratchet secret, which in turn is used to create a per-sender Authenticated Encryption with Associated Data (AEAD) [RFC5116] key. that AEAD key is what encrypts MLS plaintext messages 🔐. each time a message is sent, the ratchet secret is used to create a new ratchet secret and a new matching AEAD key 🪜✨. thanks to the properties of the key derivation function, you can't compute a ratchet secret from its corresponding AEAD key, or compute ratchet secret n-1 from ratchet secret n 🙅‍♀️🧮.

we'll look at what happens when each of these pieces of keying material is compromised, one at a time, in ascending order of severity 📈. this is a limited kind of compromise, but it's realistic when implementation vulnerabilities leak only part of the memory to the adversary 🫣💔.

8.3.1.1. Compromise of AEAD Keys

okay so sometimes bad actors can get their hands on specific AEAD keys and nonces 👀 that protect an application message or a group operation message. Compromising these keys lets the attacker decrypt just that one message encrypted with that key, and nothing else 🔒. Why? Because the AEAD keys come from the ratchet secret, and the attacker can't generate the next ratchet secret, so they also can't get the next AEAD key. Not them 🙅‍♀️

For an application message, an AEAD key compromise means the encrypted application message gets leaked, and so does the signature over that message. That's giving confidentiality AND privacy problems for the future AEAD encryptions of that chain 😭. For a group operation message, only the privacy is affected, because the signature gets revealed. The secrets themselves are still protected by Hybrid Public Key Encryption (HPKE), so they're safe 🫶. Note that in both of these cases, authentication is not affected.

Here's the tea 🍵. Every member of the group can compute the AEAD keys for all the chains (they have access to the group secrets) so they can send and receive messages. That means the authentication from the AEAD encryption layer of the common framing mechanism is weak. When an AEAD encrypted message decrypts successfully, all you actually know is that some member of the group sent it, or in this case, an attacker who compromised the AEAD keys did 🥲.

Compromising the AEAD keys lets the attacker send an encrypted message using that key. But they can't send a message to a group that looks like it came from a valid client, because they can't forge the signature 💅. This applies to all the forms of symmetric key compromise described in Section 8.3.1.

8.3.1.2. Compromise of Ratchet Secret Material

When a ratchet secret gets compromised, the adversary can compute both the current AEAD keys for a given sender and any future keys for that sender in this epoch. So they can decrypt current and future messages from that sender 😬. The good news? They don't have previous ratchet secrets, so they can't decrypt past messages as long as those secrets and keys have been deleted 🧚.

Because of its forward secrecy guarantees, MLS will also keep the secrecy of all other AEAD keys generated for other MLS clients, outside this dedicated chain of AEAD keys and nonces, even within the epoch of the compromise 🛡️. MLS provides post-compromise security against an active adaptive attacker across epochs for AEAD encryption. That means the moment the epoch changes, if the attacker doesn't have access to more secret material, they won't be able to access any protected messages from future epochs. Main character recovery arc unlocked 🦋.

8.3.1.3. Compromise of the Group Secrets of a Single Group for One or More Group Epochs

An adversary who gains access to a set of group secrets (say, when a member of the group gets compromised) is way more powerful 😈. In this section, we look at the case where the signature keys are not compromised. That can happen if the attacker can reach part of the memory holding the group secrets but not the signature keys, which might be stored in a secure enclave 🔐.

In this scenario, the adversary can compute any number of ratchet secrets for the epoch and their corresponding AEAD encryption keys. So they can encrypt and decrypt all messages for the compromised epochs 💀.

If the adversary is passive, the PCS properties of the MLS protocol mean that as soon as the compromised party fixes the problem and sends an honest Commit message, the next epochs will provide message secrecy again 🌈.

If the adversary is active, they can join the protocol itself and perform updates on behalf of the compromised party. An honest group can't recover message secrecy in that case 😭. Luckily, MLS provides PCS against active adaptive attackers through its Remove group operation. So as long as the other members of the group are honest, the protocol guarantees message secrecy for all messages exchanged in the epochs after the compromised party has been removed 👑.

8.3.2. Compromise by an Active Adversary with the Ability to Sign Messages

If an active adversary has compromised an MLS client and can sign messages, there are two different scenarios 👀. In the strongest compromise scenario, the attacker has access to the signing key and can forge authenticated messages. In a weaker, yet realistic, scenario, the attacker has compromised a client, but the client's signature keys are protected with dedicated hardware features. Those features don't allow direct access to the value of the private key. Instead, they provide a signature API 🔏.

When you're dealing with an active adaptive attacker who has access to a signature oracle, the compromise has a big impact on both the secrecy and authentication guarantees of the protocol. That's especially true if the attacker also has access to the group secrets. In that case, both secrecy and authentication are broken 🙃. The attacker can generate any message for the current and future epochs until the compromise is remediated and the formerly compromised client sends an honest update.

Note that under this compromise scenario, the attacker can perform all operations available to a legitimate client, even without access to the actual value of the signature key 💅.

8.3.3. Compromise of Authentication with Access to a Signature Key

The difference between having access to the value of the signature key and only having access to a signing oracle isn't about what an active adaptive network attacker can do during the time of the compromise. The attacker can perform every operation available to a legitimate client in both cases 🤷‍♀️.

The real difference shows up in recovery after a compromise 🪄.

Because of the PCS guarantees provided by the MLS protocol, when a previously compromised client recovers and performs an honest Commit, both secrecy and authentication of future messages can be recovered, as long as the attacker doesn't otherwise get access to the key. Since the adversary doesn't have the signing key, they can't authenticate messages on behalf of the compromised party. That's true even if they still control some group keys by colluding with other members of the group 🫶.

This is in contrast with the case where the signature key is leaked. In that case, the compromised endpoint needs to refresh its credentials and invalidate the old ones before the attacker is unable to authenticate messages 🧹.

Beware! In both oracle and private key access, an active adaptive attacker can follow the protocol and request to update its own credential. This induces a signature key rotation, which could give the attacker part or all of the private key value, depending on the architecture of the service provider 🚨.

Recommendation: Signature private keys should be compartmentalized from other secrets and preferably protected by a Hardware Security Module (HSM) or dedicated hardware features. This allows recovery of the authentication for future messages after a compromise 🔐.

Recommendation: When the credential type supports revocation, the users of a group should check for revoked keys 👀.

8.3.4. Security Considerations in the Context of a Full State Compromise

In real-world compromise scenarios, adversaries often target specific devices to get parts of the memory, or even the ability to execute arbitrary code on the targeted device 📱💀.

Also, remember that in this setting, the application will often keep the unencrypted messages. If it does, the adversary doesn't have to break encryption at all to access sent and received messages 😱. Messages may also be sent by using the application to instruct the protocol implementation.

Recommendation: If messages are stored on the device, they should be protected using encryption at rest. The keys used should be stored securely using dedicated mechanisms on the device 🔑.

Recommendation: If the threat model of the system includes an adversary that can access the messages on the device without even needing to attack MLS, the application should delete plaintext and ciphertext messages as soon as practical after encryption or decryption 🗑️.

This document makes a clear distinction between the way signature keys and other group shared secrets must be handled 🧐. In particular, a large set of group secrets can't necessarily be assumed to be protected by an HSM or secure enclave features. This is especially true because these keys are frequently used and changed with each message a client receives.

The signature private keys, however, are mostly used by clients to send a message. They also provide strong authentication guarantees to other clients. So we consider that protecting them with additional security mechanisms should be a priority 🛡️.

Overall, there's no way to detect or prevent these compromises, as discussed in the previous sections. Separating the application secret states can help with recovery after a compromise. This is the case for signature keys, but similar concerns exist for a client's encryption private keys 🧩.

Recommendation: The secret keys used for public key encryption should be stored similarly to the way the signature keys are stored. Those keys can decrypt the group operation messages and contain the secret material used to compute all the group secrets 🔐.

Even if secure enclaves aren't perfectly secure or are even completely broken, adding protections for these keys can make it easier to recover the secrecy and authentication guarantees after a compromise. This is true where, for instance, an attacker can sign messages without having access to the key. In certain contexts, the rotation of credentials might only be triggered by the AS through ACLs, which puts it beyond the attacker's capabilities 🌸.

8.4. Service Node Compromise

8.4.1. General Considerations

8.4.1.1. Privacy of the Network Connections

There are many scenarios leading to communication between the application on a device and the DS or the AS. In particular, when:

• The application connects to the AS to generate or validate a new credential before distributing it.
• The application fetches credentials at the DS prior to creating a messaging group (one-to-one or more than two clients).
• The application fetches service provider information or messages on the DS.
• The application sends service provider information or messages to the Delivery Service.

In all these cases, the application will often connect to the device via a secure transport which leaks information about the origin of the request, such as the IP address and -- depending on the protocol -- the MAC address of the device.

Similar concerns exist in the peer-to-peer use cases for MLS.

Recommendation: In the case where privacy or anonymity is important, using adequate protection such as Multiplexed Application Substrate over QUIC Encryption (MASQUE) [MASQUE-PROXY], Tor [Tor], or a VPN can improve metadata protection.

More generally, using anonymous credentials in an MLS-based architecture might not be enough to provide strong privacy or anonymity properties.

8.4.1.2. Storage of Metadata and Encryption at Rest on the Servers

In the case where private data or metadata has to be persisted on the servers for functionality (mappings between identities and push tokens, group metadata, etc.), it should be stored encrypted at rest and only decrypted upon need during the execution. Honest service providers can rely on such "encryption at rest" mechanisms to be able to prevent access to the data when not using it.

Recommendation: Store cryptographic material used for server- side decryption of sensitive metadata on the clients and only send it when needed. The server can use the secret to open and update encrypted data containers after which they can delete these keys until the next time they need it, in which case those can be provided by the client.

Recommendation: Rely on group secrets exported from the MLS session for server-side encryption at rest and update the key after each removal from the group. Otherwise, rotate those keys on a regular basis.

8.4.2. Delivery Service Compromise

MLS is intended to provide strong guarantees in the face of compromise of the DS. Even a totally compromised DS should not be able to read messages or inject messages that will be acceptable to legitimate clients. It should also not be able to undetectably remove, reorder, or replay messages.

However, a malicious DS can mount a variety of DoS attacks on the system, including total DoS attacks (where it simply refuses to forward any messages) and partial DoS attacks (where it refuses to forward messages to and from specific clients). As noted in Section 5.2, these attacks are only partially detectable by clients without an out-of-band channel. Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology.

Because the DS is responsible for providing the initial keying material to clients, it can provide stale keys. This does not inherently lead to compromise of the message stream, but does allow the DS to attack post-compromise security to a limited extent. This threat can be mitigated by having initial keys expire.

Initial keying material (KeyPackages) using the basic credential type is more vulnerable to replacement by a malicious or compromised DS, as there is no built-in cryptographic binding between the identity and the public key of the client.

Recommendation: Prefer a credential type in KeyPackages which includes a strong cryptographic binding between the identity and its key (for example, the x509 credential type). When using the basic credential type, take extra care to verify the identity (typically out of band).

8.4.2.1. Privacy of Delivery and Push Notifications

Push tokens provide an important mechanism that is often ignored from the standpoint of privacy considerations. In many modern messaging architectures, applications are using push notification mechanisms typically provided by OS vendors. This is to make sure that when messages are available at the DS (or via other mechanisms if the DS is not a central server), the recipient application on a device knows about it. Sometimes the push notification can contain the application message itself, which saves a round trip with the DS.

To "push" this information to the device, the service provider and the OS infrastructures use unique per-device, per-application identifiers called push tokens. This means that the push notification provider and the service provider have information on which devices receive information and at which point in time. Alternatively, non-mobile applications could use a WebSocket or persistent connection for notifications directly from the DS.

Even though the service provider and the push notification provider can't necessarily access the content (typically encrypted MLS messages), no technical mechanism in MLS prevents them from determining which devices are recipients of the same message.

For secure messaging systems, push notifications are often sent in real time, as it is not acceptable to create artificial delays for message retrieval.

Recommendation: If real-time notifications are not necessary, one can delay notifications randomly across recipient devices using a mixnet or other techniques.

Note that with a legal request to ask the service provider for the push token associated with an identifier, it is easy to correlate the token with a second request to the company operating the push notification system to get information about the device, which is often linked with a real identity via a cloud account, a credit card, or other information.

Recommendation: If stronger privacy guarantees are needed with regard to the push notification provider, the client can choose to periodically connect to the DS without the need of a dedicated push notification infrastructure.

Applications can also consider anonymous systems for server fanout (for example, [Loopix]).

8.4.3. Authentication Service Compromise

The Authentication Service design is left to the infrastructure designers. In most designs, a compromised AS is a serious matter, as the AS can serve incorrect or attacker-provided identities to clients.

• The attacker can link an identity to a credential.
• The attacker can generate new credentials.
• The attacker can sign new credentials.
• The attacker can publish or distribute credentials.

An attacker that can generate or sign new credentials may or may not have access to the underlying cryptographic material necessary to perform such operations. In that last case, it results in windows of time for which all emitted credentials might be compromised.

Recommendation: Use HSMs to store the root signature keys to limit the ability of an adversary with no physical access to extract the top-level signature private key.

Note that historically some systems generate signature keys on the AS and distribute the private keys to clients along with their credential. This is a dangerous practice because it allows the AS or an attacker who has compromised the AS to silently impersonate the client.

8.4.3.1. Authentication Compromise: Ghost Users and Impersonation

One important property of MLS is that all members know which other members are in the group at all times. If all members of the group and the AS are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that group.

This guarantee applies to the cryptographic identities of the members. Details about how to verify the identity of a client depend on the MLS credential type used. For example, cryptographic verification of credentials can be largely performed autonomously (e.g., without user interaction) by the clients themselves for the x509 credential type.

In contrast, when MLS clients use the basic credential type, some other mechanism must be used to verify identities. For instance, the Authentication Service could operate some sort of directory server to provide keys, or users could verify keys via an out-of-band mechanism.

Recommendation: Select the MLS credential type with the strongest security which is supported by all target members of an MLS group.

Recommendation: Do not use the same signature key pair across groups. Update all keys for all groups on a regular basis. Do not preserve keys in different groups when suspecting a compromise.

If the AS is compromised, it could validate a signature key pair (or generate a new one) for an attacker. The attacker could then use this key pair to join a group as if it were another of the user's clients. Because a user can have many MLS clients running the MLS protocol, it possibly has many signature key pairs for multiple devices. These attacks could be very difficult to detect, especially in large groups where the UI might not reflect all the changes back to the users. If the application participates in a key transparency mechanism in which it is possible to determine every key for a given user, then this would allow for detection of surreptitiously created false credentials.

Recommendation: Make sure that MLS clients reflect all the membership changes to the users as they happen. If a choice has to be made because the number of notifications is too high, the client should provide a log of state of the device so that the user can examine it.

Recommendation: Provide a key transparency mechanism for the AS to allow public verification of the credentials authenticated by this service.

While the ways to handle MLS credentials are not defined by the protocol or the architecture documents, the MLS protocol has been designed with a mechanism that can be used to provide out-of-band authentication to users. The authentication_secret generated for each user at each epoch of the group is a one-time, per-client authentication secret which can be exchanged between users to prove their identities to each other. This can be done, for instance, using a QR code that can be scanned by the other parties.

Recommendation: Provide one or more out-of-band authentication mechanisms to limit the impact of an AS compromise.

We note, again, that the AS may not be a centralized system and could be realized by many mechanisms such as establishing prior one-to-one deniable channels, gossiping, or using trust on first use (TOFU) for credentials used by the MLS protocol.

Another important consideration is the ease of redistributing new keys on client compromise, which helps recovering security faster in various cases.

8.4.3.2. Privacy of the Group Membership 🎀

okay so group membership is literally sensitive info, and MLS is designed to keep persistent metadata to a minimum 🫶 but big groups usually need infrastructure that does server fanout 🌸 with client fanout, every client already knows where a message is going, so the server usually doesn't need that info 🧚 BUT servers can still figure stuff out through traffic analysis 👀 and in a server-side fanout setup, the Delivery Service can notice that one client is sending the same message to a bunch of other clients 💀 there may also be apps where the group membership list gets stored on some server tied to the DS 😭

this isn't a break in MLS's authentication or confidentiality guarantees, ngl, but it's a seriously big deal for privacy 🙈

some setups keep a mapping between the keys used in MLS and actual user identities 🔥 so if an attacker gets that info (through a compromise or because of regulation), they can connect unencrypted group messages (like Commits and Proposals) to a specific user 😱

Recommendation: Use encrypted group operation messages to limit privacy risks whenever possible. 💜

sometimes the adversary can see specific bindings between public keys and identities 👑 and if signature keys get reused across groups, they can learn way more about the targeted user 👀

Recommendation: Ensure that linking between public keys and identities only happens in expected scenarios. 🦋

---

8.5. Considerations for Attacks Outside of the Threat Model 🌈

okay bestie, physical attacks on devices that store and run MLS principals aren't covered in depth in the MLS threat model 🧚 even though non-permanent, non-invasive attacks can sometimes act just like software attacks, physical attacks are still considered outside the MLS threat model 💅

compromise scenarios usually involve a software adversary, who can keep up active adaptive compromise and arbitrarily change how the client or service behaves 😭

on the flip side, the security goals assume honest clients always run the protocol exactly as specified ✨ this relies on implementations securely implementing the spec, which is still non-trivial 💀

Recommendation: Additional steps should be taken to protect the device and the MLS clients from physical compromise. In such settings, HSMs and secure enclaves can be used to protect signature keys. 🔥

---

8.6. No Protection Against Replay by Insiders 🙈

MLS does not protect against one group member replaying a PrivateMessage sent by another group member within the same epoch that the message was originally sent 💀 similarly, MLS does not protect against the replay (by a group member or otherwise) of a PublicMessage within the same epoch it was originally sent 😭 apps where replay is a real risk should apply mitigations at the application layer, as discussed below 🫶

in addition to the risks in Section 8.3.1, an attacker with access to an endpoint's ratchet secrets can replay PrivateMessage objects sent by other group members 👀 they just take the signed content of the message and re-encrypt it with a new generation of the original sender's ratchet 🔥 if the other members interpret a message with a new generation as a fresh message, then it'll look fresh 💅 (this is possible because the message signature doesn't cover the generation field of the message 🤯) messages sent as PublicMessage objects similarly lack replay protections 🙈 and there's no message counter comparable to the generation field in PrivateMessage 💜

apps can detect replay by including a unique identifier for the message (like a counter) in either the message payload or the authenticated_data field 🌸 both of those are included in the signatures for PublicMessage and PrivateMessage ✨

---

8.7. Cryptographic Analysis of the MLS Protocol 🦋

okay so various academic works have analyzed MLS and the security guarantees it aims to provide 🧠 the security of large parts of the protocol has been analyzed by [BBN19] (for MLS Draft 7), [ACDT21] (for MLS Draft 11), and [AJM20] (for MLS Draft 12) 📚

individual components of various drafts of MLS have been analyzed in isolation and with different adversarial models 🌈 for example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20], [ACJM20], [AHKM21], [CGWZ25], and [WPB25] analyze the ratcheting tree sub-protocol of MLS that facilitates key agreement 🌳 [WPBB22] analyzes the sub-protocol for group state agreement and authentication 🫶 and [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule 🔑 finally, [CHK21] analyzes the authentication and cross-group healing guarantees provided by MLS 💖

---

9. IANA Considerations ✨

This document has no IANA actions. 🧚

10. References 📚

10.1. Normative References 💜

[RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
           Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
           <https://www.rfc-editor.org/info/rfc5116>.

[RFC9420]  Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
           Omara, E., and K. Cohn-Gordon, "The Messaging Layer
           Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
           July 2023, <https://www.rfc-editor.org/info/rfc9420>.

10.2. Informative References 📚

okay bestie, these are the background reads 🦋 Not required to build the thing, but they're where the receipts live. The ePrint papers are the ones that dig into the security math, and the drafts are the MLS spin-offs. Literally a whole reading list 🤓💜

   [ACCKKMPPWY19]
              Alwen, J., Capretto, M., Cueto, M., Kamath, C., Klein, K.,
              Markov, I., Pascual-Perez, G., Pietrzak, K., Walter, M.,
              and M. Yeo, "Keep the Dirt: Tainted TreeKEM, Adaptively
              and Actively Secure Continuous Group Key Agreement",
              Cryptology ePrint Archive, 2019,
              <https://eprint.iacr.org/2019/1489>.

   [ACDT19]   Alwen, J., Coretti, S., Dodis, Y., and Y. Tselekounis,
              "Security Analysis and Improvements for the IETF MLS
              Standard for Group Messaging", Cryptology ePrint Archive,
              2019, <https://eprint.iacr.org/2019/1189.pdf>.

   [ACDT21]   Alwen, J., Coretti, S., Dodis, Y., and Y. Tselekounis,
              "Modular Design of Secure Group Messaging Protocols and
              the Security of MLS", Cryptology ePrint Archive, 2021,
              <https://eprint.iacr.org/2021/1083.pdf>.

   [ACJM20]   Alwen, J., Coretti, S., Jost, D., and M. Mularczyk,
              "Continuous Group Key Agreement with Active Security",
              Cryptology ePrint Archive, 2020,
              <https://eprint.iacr.org/2020/752.pdf>.

   [AHKM21]   Alwen, J., Hartmann, D., Kiltz, E., and M. Mularczyk,
              "Server-Aided Continuous Group Key Agreement", Cryptology
              ePrint Archive, 2021,
              <https://eprint.iacr.org/2021/1456.pdf>.

   [AJM20]    Alwen, J., Jost, D., and M. Mularczyk, "On The Insider
              Security of MLS", Cryptology ePrint Archive, 2020,
              <https://eprint.iacr.org/2020/1327.pdf>.

   [BBN19]    Bhargavan, K., Beurdouche, B., and P. Naldurg, "Formal
              Models and Verified Protocols for Group Messaging: Attacks
              and Proofs for IETF MLS", HAL ID hal-02425229, 2019,
              <https://inria.hal.science/hal-02425229/document>.

   [BBR18]    Bhargavan, K., Barnes, R., and E. Rescorla, "TreeKEM:
              Asynchronous Decentralized Key Management for Large
              Dynamic Groups - A protocol proposal for Messaging Layer
              Security (MLS)", HAL ID hal-02425247, 2018,
              <https://hal.inria.fr/hal-02425247/file/
              treekem+%281%29.pdf>.

   [BCK21]    Brzuska, C., Cornelissen, E., and K. Kohbrok, "Security
              Analysis of the MLS Key Distribution", Cryptology ePrint
              Archive, 2021, <https://eprint.iacr.org/2021/137.pdf>.

   [CAPBR]    Brewer, E. A., "Towards robust distributed systems
              (abstract)", Proceedings of the nineteenth annual ACM
              symposium on Principles of distributed computing, p. 7,
              DOI 10.1145/343477.343502, July 2000,
              <https://dl.acm.org/doi/10.1145/343477.343502>.

   [CGWZ25]   Cremers, C., Günsay, E., Wesselkamp, V., and M. Zhao,
              "ETK: External-Operations TreeKEM and the Security of MLS
              in RFC 9420", 2025,
              <https://eprint.iacr.org/2025/229.pdf>.

   [CHK21]    Cremers, C., Hale, B., and K. Kohbrok, "The Complexities
              of Healing in Secure Group Messaging: Why Cross-Group
              Effects Matter", Proceedings of the 30th USENIX Security
              Symposium, August 2021,
              <https://www.usenix.org/system/files/sec21-cremers.pdf>.

   [EXTENSIONS]
              Robert, R., "The Messaging Layer Security (MLS)
              Extensions", Work in Progress, Internet-Draft, draft-ietf-
              mls-extensions-06, 19 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
              extensions-06>.

   [FEDERATION]
              Omara, E. and R. Robert, "The Messaging Layer Security
              (MLS) Federation", Work in Progress, Internet-Draft,
              draft-ietf-mls-federation-03, 9 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
              federation-03>.

   [KT]       McMillion, B., "Key Transparency Architecture", Work in
              Progress, Internet-Draft, draft-ietf-keytrans-
              architecture-03, 25 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-
              keytrans-architecture-03>.

   [Loopix]   Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and
              G. Danezis, "The Loopix Anonymity System", Proceedings of
              the 26th USENIX Security Symposium, August 2017.

   [MASQUE-PROXY]
              Schinazi, D., "The MASQUE Proxy", Work in Progress,
              Internet-Draft, draft-schinazi-masque-proxy-05, 18
              February 2025, <https://datatracker.ietf.org/doc/html/
              draft-schinazi-masque-proxy-05>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
              March 2011, <https://www.rfc-editor.org/info/rfc6120>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [Tor]      "The Tor Project", <https://torproject.org/>.

   [WPB25]    Wallez, T., Protzenko, J., and K. Bhargavan, "TreeKEM: A
              Modular Machine-Checked Symbolic Security Analysis of
              Group Key Agreement in Messaging Layer Security", 2025,
              <https://eprint.iacr.org/2025/410.pdf>.

   [WPBB22]   Wallez, T., Protzenko, J., Beurdouche, B., and K.
              Bhargavan, "TreeSync: Authenticated Group Management for
              Messaging Layer Security", Cryptology ePrint Archive,
              2022, <https://eprint.iacr.org/2022/1732.pdf>.

---

Contributors ✨

huge shoutout to the squad who helped make this happen 🫶💖 here's who's on the team:

   Richard Barnes
   Cisco
   Email: rlb@ipv.sx


   Katriel Cohn-Gordon
   Meta Platforms
   Email: me@katriel.co.uk


   Cas Cremers
   CISPA Helmholtz Center for Information Security
   Email: cremers@cispa.de


   Britta Hale
   Naval Postgraduate School
   Email: britta.hale@nps.edu


   Albert Kwon
   Badge Inc.
   Email: kwonalbert@badgeinc.com


   Konrad Kohbrok
   Phoenix R&D
   Email: konrad.kohbrok@datashrine.de


   Rohan Mahy
   Wire
   Email: rohan.mahy@wire.com


   Brendan McMillion
   Email: brendanmcmillion@gmail.com


   Thyla van der Merwe
   Email: tjvdmerwe@gmail.com


   Jon Millican
   Meta Platforms
   Email: jmillican@meta.com


   Raphael Robert
   Phoenix R&D
   Email: ietf@raphaelrobert.com

---

Authors' Addresses 💜

and last but definitely not least, the authors who did the heavy lifting 👑🌈 reach out if you want to chat about MLS, they're all very reachable:

   Benjamin Beurdouche
   Inria & Mozilla
   Email: ietf@beurdouche.com


   Eric Rescorla
   Email: ekr@rtfm.com


   Emad Omara
   Email: emad.omara@gmail.com


   Srinivas Inguva
   Email: singuva@yahoo.com


   Alan Duric
   Email: alan@duric.net