2.1.Protocol Overview

MLS provides a way forclients to formgroups within which they cancommunicate securely. For example, a set of users might use clients on theirphones or laptops to join a group and communicate with each other. A group maybe as small as two clients (e.g., for simple person-to-person messaging) or aslarge as hundreds of thousands. A client that is part of a group is amemberof that group. As groups change membership and group or member properties, theyadvance from oneepoch to another and the cryptographic state of the groupevolves.¶

The group is represented as a tree, which represents the members as the leavesof a tree. It is used to efficiently encrypt to subsets of the members. Eachmember has a state called aLeafNode object holding the client's identity,credentials, and capabilities.¶

Various messages are used in the evolution from epoch to epoch.AProposal message proposesa change to be made in the next epoch, such as adding or removing a member.ACommit message initiates a new epoch by instructing members of the group toimplement a collection of proposals. Proposals and Commits are collectivelycalledhandshake messages.AKeyPackage provides keys that can be used to add the client to a group,including a public encryption key and a signature key (both stored inthe KeyPackage'sLeafNode object).AWelcome message provides a new member to the group with the information toinitialize their state for the epoch in which they were added.¶

Of course most (but not all) applications use MLS to send encrypted group messages.Anapplication message is an MLS message with an arbitrary application payload.¶

Finally, aPublicMessage contains an integrity-protected MLS handshake message,while aPrivateMessage contains a confidential, integrity-protected handshakeor application message.¶

For a more detailed explanation of these terms, please consult the MLS protocolspecification[RFC9420].¶

2.2.Abstract Services

MLS is designed to operate within the context of a messaging service, whichmay be a single service provider, a federated system, or some kind ofpeer-to-peer system. The service needs to provide two services thatfacilitate client communication using MLS:¶

• An Authentication Service (AS), which is responsible forattesting to bindings between application-meaningful identifiers and thepublic key material used for authentication in the MLS protocol. TheAS must also be able to generate credentials that encode thesebindings and validate credentials provided by MLS clients.¶

• A Delivery Service (DS), which can receive and distributemessages between group members. In the case of group messaging, the DSmay also be responsible for acting as a "broadcaster" where the sendersends a single message which is then forwarded to each recipient in the groupby the DS. The DS is also responsible for storing and delivering initialpublic key material required by MLS clients in order to proceed with the groupsecret key establishment that is part of the MLS protocol.¶

For presentation purposes, this document treats the AS and DS as conventionalnetwork services. However, MLS does not require a specific implementationfor the AS or DS. These services may reside on the same server or differentservers, they may be distributed between server and client components, and theymay even involve some action by users. For example:¶

• Several secure messaging services today provide a centralized DS and rely onmanual comparison of clients' public keys as the AS.¶

• MLS clients connected to a peer-to-peer network could instantiate adecentralized DS by transmitting MLS messages over that network.¶

• In an MLS group using a Public Key Infrastructure (PKI) for authentication,the AS would comprise the certificate issuance and validation processes,both of which involve logic inside MLS clients as well as variousexisting PKI roles (e.g., Certification Authorities).¶

It is important to note that the AS can becompletely abstract in the case of a service provider which allows MLSclients to generate, distribute, and validate credentials themselves.As with the AS, the DS can be completely abstract ifusers are able to distribute credentials and messages without relyingon a central DS (as in a peer-to-peer system). Note,though, that in such scenarios, clients will need to implement logicthat assures the delivery properties required of the DS (seeSection 5.2).¶

Figure 1 shows the relationship of these concepts,with three clients and one group, and clients 2 and 3 beingpart of the group and client 1 not being part of any group.¶

3.1.Step 1: Account Creation

Alice, Bob, and Charlie create accounts with a service provider and obtaincredentials 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 initialkeying material which is used to send encrypted messages to themfor the first time. This keying material is authenticated with theirlong-term credentials. Although in principle this keying materialcan be reused for multiple senders, in order to provide forward secrecyit is better for this material to be regularly refreshed so that eachsender 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 including Bob, she first uses the DS to lookup his initial keying material. She then 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 thatincludes the secret keying information necessary to join the group.¶

She sends both of these messages to the DS, which is responsiblefor sending them to the appropriate people. Note that the security of MLSdoes not depend on the DS forwarding the Welcome message only to Bob, as itis encrypted for him; it is simply not necessary for other group membersto receive it.¶

3.4.Step 4: Adding Charlie to the Group

If Alice then wants to add Charlie to the group, she follows a similar procedureas with Bob. She first uses the DS to lookup his initial keying material and then generates two messages:¶

• A message to the entire group (consisting of her, Bob, and Charlie) addingCharlie to the group.¶

• A Welcome message just to Charlie encrypted with his initial keying material thatincludes the secret keying information necessary to join the group.¶

At the completion of this process, we have a group with Alice, Bob, and Charlie,which means that they share a single encryption key which can be used tosend messages or to key other protocols.¶

3.5.Other Group Operations

Once the group has been created, clients can perform other actions,such as:¶

• 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 itself enforce any access control on groupoperations. For instance, any member of the group can send a messageto add a new member or to evict an existing member.This is in contrast to some designs in which there is a single groupcontroller who can modify the group. MLS-using applications areresponsible for setting their own access control policies. For instance,if only the group administrator is allowed to change group members,then it is the responsibility of the application to inform membersof this policy and who the administrator is.¶

3.6.Proposals and Commits

The general pattern for any change in the group state (e.g., to add or removea user) is that it consists of two messages:¶

Proposal:

This message describes the change to be made (e.g., add Bob to the group)but does not effect a change.¶

Commit:

This message changes the group state to include the changes described ina set of proposals.¶

The simplest pattern is for a client to just send a Commit which contains one ormore Proposals. For instance, Alice could send a Commit with the ProposalAdd(Bob) embedded to add Bob to the group. However, there are situations inwhich one client might send a Proposal and another might send the corresponding Commit. Forinstance, Bob might wish to remove himself from the group and send a Removeproposal to do so (seeSection 12.1.3 of [RFC9420]). Because Bob cannot sendthe Commit, an existing member must do so. Commits can apply to multiple validProposals, in which case all the listed changes are applied.¶

It is also possible for a Commit to apply to an empty set of Proposals,in which case it just updates the cryptographic state of the groupwithout changing its membership.¶

3.7.Users, Clients, and Groups

While it's natural to think of a messaging system as consisting of groups ofusers, possibly using different devices, in MLS the basic unit of operation isnot the user but rather the "client". Formally, a client is a set ofcryptographic objects composed of public values such as a name (an identity), apublic encryption key, and a public signature key. As usual, a user demonstratesownership of the client by demonstrating knowledge of the associated secretvalues.¶

In some messaging systems, clients belonging to the same user must all share thesame signature key pair, but MLS does not assume this; instead, a user may havemultiple clients with the same identity and different keys. In this case, eachclient will have its own cryptographic state, and it is up to the application todetermine how to present this situation to users. For instance, it may rendermessages to and from a given user identically regardless of which client theyare associated with, or it may choose to distinguish them.It is also possible to have multiple clients associated withthe same user share state, as described inSection 8.2.4.¶

When a client is part of a group, it is called a member. A group in MLS isdefined as the set of clients that have knowledge of the shared group secretestablished in the group key establishment phase. Note that until a client hasbeen added to the group and contributed to the group secret in a mannerverifiable by other members of the group, other members cannot assume that theclient is a member of the group; for instance, the newly added member might nothave received the Welcome message or been unable to decrypt it for some reason.¶

5.1.Key Storage and Retrieval

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

• A credential from the AS attesting to the binding betweenthe identity and the client's signature key.¶

• The client's asymmetric encryption public key.¶

All the parameters in the KeyPackage are signed with the signatureprivate key corresponding to the credential.As noted inSection 3.7, users may own multiple clients, eachwith their own keying material. Each KeyPackage is specific to an MLS versionand cipher suite, but a client may want to offer support for multiple protocolversions and cipher suites. As such, there may be multiple KeyPackages stored byeach 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 firstcontacts the DS to request KeyPackages for each of the other clients,authenticates the KeyPackages using the signature keys, includes the KeyPackagesin Add proposals, and encrypts the information needed to join the group(theGroupInfo object) with an ephemeral key; it then separately encrypts theephemeral 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, theDS should provide the minimum number of KeyPackages necessary tosatisfy the request. For example, if the request specifies the MLS version, theDS might provide one KeyPackage per supported cipher suite, even if it hasmultiple such KeyPackages to enable the corresponding client to be added tomultiple groups before needing to upload more fresh KeyPackages.¶

In order to avoid replay attacks and provide forward secrecy for messages sentusing the initial keying material, KeyPackages are intended to be used onlyonce, andinit_key is intended to be deleted by the client after decryptionof the Welcome message. The DS is responsible for ensuring thateach KeyPackage is only used to add its client to a single group, with thepossible exception of a "last resort" KeyPackage that is specially designatedby the client to be used multiple times. Clients are responsible for providingnew KeyPackages as necessary in order to minimize the chance that the "lastresort" KeyPackage will be used.¶

Recommendation: Ensure that "last resort" KeyPackages don't get used byprovisioning enough standard KeyPackages.¶

Recommendation: Rotate "last resort" KeyPackages as soon as possibleafter 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" KeyPackagehas been used is updating leaf keys as early as possible.¶

Recommendation: Ensure that clients delete the private componentof theirinit_key after processing a Welcome message, or after therotation of the "last resort" KeyPackage.¶

Overall, it needs to be noted that key packages need to be updated whensignature keys are changed.¶

5.2.Delivery of Messages

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

For the most part, MLS does not require the DS to deliver messagesin any particular order. Applications can set policies that control theirtolerance for out-of-order messages (seeSection 7), andmessages that arrive significantly out of order can be dropped without otherwiseaffecting the protocol. There are two exceptions to this. First, Proposalmessages should all arrive before the Commit that references them. Second,because an MLS group has a linear history of epochs, the members of the groupmust agree on the order in which changes are applied. Concretely, the groupmust agree on a single MLS Commit message that ends each epoch and begins thenext one.¶

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

• Consistent and Partition-tolerant, or Strongly Consistent, systems, which can providea globally consistent view of data but have the inconvenience of clients needingto handle rejected messages.¶

• Available and Partition-tolerant, or Eventually Consistent, systems, which continueworking despite network issues but may return different views of data todifferent users.¶

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

However, note that a malicious DS could also reorder messages orprovide an inconsistent view to different users. The "generation" counter inMLS messages provides per-sender loss detection and ordering that cannot bemanipulated by the DS, but this does not provide complete protection againstpartitioning. A DS can cause a partition in the group by partitioning keyexchange messages; this can be detected only by out-of-band comparison (e.g.,confirming that all clients have the sameepoch_authenticator value). Amechanism for more robust protections is discussed in[EXTENSIONS].¶

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

5.3.Invalid Commits

Situations can arise where a malicious or buggy client sends a Commit that isnot accepted by all members of the group, and the DS is not able to detect thisand reject the Commit. For example, a buggy client might send an encryptedCommit with an invalid set of proposals, or a malicious client might send amalformed Commit of the form described inSection 16.12 of [RFC9420].¶

In situations where the DS is attempting to filter redundant Commits, the DSmight update its internal state under the assumption that a Commit has succeededand thus end up in a state inconsistent with the members of the group. Forexample, the DS might think that the current epoch is nown+1 and reject anycommits from other epochs, while the members think the epoch isn, and as aresult, the group is stuck -- no member can send a Commit that the DS willaccept.¶

Such "desynchronization" problems can arise even when the DS takesno stance on which Commit is "correct" for an epoch. The DS can enable clientsto choose between Commits, for example by providing Commits in the orderreceived and allowing clients to reject any Commits thatviolate their view of the group's policies. As such, all honest andcorrectly implemented clients will arrive at the same "first valid Commit" andchoose to process it. Malicious or buggy clients that process a different Commitwill end up in a forked view of the group.¶

When these desynchronizations happen, the application may choose to take actionto restore the functionality of the group. These actions themselves can havesecurity implications. For example, a client developer might have a clientautomatically rejoin a group, using an external join, when it processes aninvalid Commit. In this operation, however, the client trusts that theGroupInfo provided by the DS faithfully represents the state of the group, andnot, say, an earlier state containing a compromised leaf node. In addition, theDS may be able to trigger this condition by deliberately sending the victim aninvalid Commit. In certain scenarios, this trust can enable the DS or amalicious insider to undermine the post-compromise security guarantees providedby MLS.¶

Actions to recover from desynchronization can also have availability and DoSimplications. For example, if a recovery mechanism relies on external joins, amalicious member that deliberately posts an invalid Commit could also post acorrupted GroupInfo object in order to prevent victims from rejoining the group.Thus, careful analysis of security implications should be made for any systemfor recovering from desynchronization.¶

6.1.Membership Changes

MLS aims to provide agreement on group membership, meaning that all groupmembers have agreed on the list of current group members.¶

Some applications may wish to enforce Access Control Lists (ACLs) to limit addition or removal of groupmembers to privileged clients or users. Others may wish to requireauthorization from the current group members or a subset thereof. Such policiescan be implemented at the application layer, on top of MLS. Regardless, MLS doesnot allow for or support addition or removal of group members without informingall other members.¶

Membership of an MLS group is managed at the level of individual clients. Inmost cases, a client corresponds to a specific device used by a user. If a userhas multiple devices, the user will generally be represented in a group bymultiple clients (although applications could choose to have devices sharekeying material). If an application wishes to implement operations at the levelof users, it is up to the application to track which clients belong to a givenuser and ensure that they are added/removed consistently.¶

MLS provides two mechanisms for changing the membership of a group. The primarymechanism is for an authorized member of the group to send a Commit that adds orremoves other members. A secondary mechanism is an "external join": A member ofthe group publishes certain information about the group, which a new member canuse to construct an "external" Commit message that adds the new member to thegroup. (There is no similarly unilateral way for a member to leave the group;they must be removed by a remaining member.)¶

With both mechanisms, changes to the membership are initiated from inside thegroup. When members perform changes directly, this is clearly the case.External joins are authorized indirectly, in the sense that a member publishinga GroupInfo object authorizes anyone to join who has access to the GroupInfoobject, subject to whatever access control policies the application appliesfor external joins.¶

Both types of joins are done via a Commit message, which could beblocked by the DS or rejected by clients if the join is not authorized. Theformer approach requires that Commits be visible to the DS; the latter approachrequires that clients all share a consistent policy. In the unfortunate eventthat an unauthorized member is able to join, MLS enables any member to removethem.¶

Application setup may also determine other criteria for membership validity. Forexample, per-device signature keys can be signed by an identity key recognizedby other participants. If a certificate chain is used to authenticate devicesignature keys, then revocation by the owner adds an alternative mechanism to promptmembership removal.¶

An MLS group's secrets change on every change of membership, so each client onlyhas access to the secrets used by the group while they are a member. Messagessent before a client joins or after they are removed are protected with keysthat are not accessible to the client. Compromise of a member removed from agroup does not affect the security of messages sent after their removal.Messages sent during the client's membership are also secure as long as theclient has properly implemented the MLS deletion schedule, which calls for thesecrets used to encrypt or decrypt a message to be deleted after use, along withany secrets that could be used to derive them.¶

6.2.Parallel Groups

Any user or client may have membership in several groups simultaneously. Theset of members of any group may or may not overlap with the members ofanother group. MLS guarantees that the FS and PCS goals within a given group aremaintained and not weakened by user membership in multiple groups. However,actions in other groups likewise do not strengthen the FS and PCS guaranteeswithin a given group, e.g., key updates within a given group following a devicecompromise do not provide PCS healing in other groups; each group must beupdated separately to achieve these security objectives. This also applies tofuture groups that a member has yet to join, which are likewise unaffected byupdates performed in current groups.¶

Applications can strengthen connectivity among parallel groups by requiringperiodic key updates from a user across all groups in which they havemembership.¶

MLS provides a pre-shared key (PSK) mechanism that can be used to link healing propertiesamong parallel groups. For example, suppose a common member M of two groups Aand B has performed a key update in group A but not in group B. The key updateprovides PCS with regard to M in group A. If a PSK is exported from group A andinjected into group B, then some of these PCS properties carry over to group B,since the PSK and secrets derived from it are only known to the new, updatedversion of M, not to the old, possibly compromised version of M.¶

6.3.Asynchronous Usage

No operation in MLS requires two distinct clients or members to be onlinesimultaneously. In particular, members participating in conversations protectedusing MLS can update the group's keys, add or remove new members, and sendmessages without waiting for another user's reply.¶

Messaging systems that implement MLS have to provide a transport layer fordelivering messages asynchronously and reliably.¶

6.4.Access Control

Because all clients within a group (members) have access to the sharedcryptographic material, the MLS protocol allows each member of the messaging groupto perform operations. However, every service/infrastructure has control overpolicies applied to its own clients. Applications managing MLS clients can beconfigured to allow for specific group operations. On the one hand, anapplication could decide that a group administrator will be the only member toperform Add and Remove operations. On the other hand, in many settings such asopen discussion forums, joining can be allowed for anyone.¶

While MLS application messages are always encrypted,MLS handshake messages can be sent either encrypted (in an MLSPrivateMessage) or unencrypted (in an MLS PublicMessage). Applicationsmay be designed such that intermediaries need to see handshakemessages, for example to enforce policy on which commits are allowed,or to provide MLS ratchet tree data in a central location. Ifhandshake messages are unencrypted, it is especially important thatthey be sent over a channel with strong transport encryption(seeSection 8) in order to prevent externalattackers from monitoring the status of the group. Applications thatuse unencrypted handshake messages may take additional steps to reducethe amount of metadata that is exposed to the intermediary. Everythingelse being equal, using encrypted handshake messages provides strongerprivacy properties than using unencrypted handshake messages,as it prevents intermediaries from learning about the structureof the group.¶

If handshake messages are encrypted, any accesscontrol policies must be applied at the client, so the application must ensurethat the access control policies are consistent across all clients to make surethat they remain in sync. If two different policies were applied, the clientsmight not accept or reject a group operation and end up in differentcryptographic states, breaking 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 the group in two ways: Externalsigners can submit proposals for changes to the group, and new joiners can usean external join to add themselves to the group. Theexternal_sendersextension ensures that all members agree on which signers are allowed to sendproposals, but any other policies must be assured to be consistent, as noted above.¶

Recommendation: Have an explicit group policy setting the conditions underwhich external joins are allowed.¶

6.5.Handling Authentication Failures

Within an MLS group, every member is authenticated to every other member bymeans of credentials issued and verified by the AS. MLSdoes not prescribe what actions, if any, an application should take in the eventthat a group member presents an invalid credential. For example, an applicationmay require such a member to be immediately evicted or may allow some graceperiod for the problem to be remediated. To avoid operational problems, it isimportant for all clients in a group to have a consistent view of whichcredentials in a group are valid, and how to respond to invalid credentials.¶

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

Recommendation: Have a uniform policy for how invalid credentials arehandled.¶

In some authentication systems, it is possible for a previously valid credentialto become invalid over time. For example, in a system based on X.509certificates, credentials can expire or be revoked. The MLS update mechanismsallow a client to replace an old credential with a new one. This is best donebefore the old credential becomes invalid.¶

Recommendation: Proactively rotate credentials, especially if a credentialis about to become invalid.¶

6.6.Recovery After State Loss

Group members whose local MLS state is lost or corrupted can reinitialize theirstate by rejoining the group as a new member and removing the memberrepresenting their earlier state. An application can require that a clientperforming such a reinitialization prove its prior membership with a PSK thatwas exported from the previous state.¶

There are a few practical challenges to this approach. For example, theapplication will need to ensure that all members have the required PSK,including any new members that have joined the group since the epoch in whichthe PSK was issued. And of course, if the PSK is lost or corrupted along withthe member's other state, then it cannot be used to recover.¶

Reinitializing in this way does not provide the member with access to groupmessages exchanged during the state loss window, but enables proof of priormembership in the group. Applications may choose various configurations forproviding lost messages to valid group members that are able to prove priormembership.¶

6.7.Support for Multiple Devices

It is common for users within a group to own multiple devices. A newdevice can be added to a group and be considered as a new client by theprotocol. This client will not gain access to the history even if it is owned bysomeone who owns another member of the group. MLS does not provide directsupport for restoring history in this case, but applications can elect toprovide such a mechanism outside of MLS. Such mechanisms, if used, may reducethe FS and PCS guarantees provided by MLS.¶

6.8.Extensibility

The MLS protocol provides several extension points where additional informationcan be provided. Extensions to KeyPackages allow clients to disclose additionalinformation about their capabilities. Groups can also have extension dataassociated with them, and the group agreement properties of MLS will confirmthat 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 containarbitrary data. Each application that uses MLS needs to define the format ofitsapplication_data and any mechanism necessary to determine the format ofthat content over the lifetime of an MLS group. In many applications, this meansmanaging format migrations for groups with multiple members who may each beoffline at unpredictable times.¶

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

The MLS framing for application messages also provides a field where clients cansend information that is authenticated but not encrypted. Such information canbe used by servers that handle the message, but group members are assured thatit has not been tampered with.¶

6.10.Federation

The protocol aims to be compatible with federated environments. While thisdocument does not specify all necessary mechanisms required for federation,multiple MLS implementations can interoperate to form federated systems if theyuse compatible authentication mechanisms, cipher suites, application content, andinfrastructure functionalities. Federation is described in more detail in[FEDERATION].¶

6.11.Compatibility with Future Versions of MLS

It is important that multiple versions of MLS be able to coexist in thefuture. Thus, MLS offers a version negotiation mechanism; this mechanismprevents version downgrade attacks where an attacker would actively rewritemessages with a lower protocol version than the messages originally offered by theendpoints. When multiple versions of MLS are available, the negotiation protocolguarantees that the creator is able to select the best version out of thosesupported in common by the group.¶

In MLS 1.0, the creator of the group is responsible for selecting the bestcipher suite supported across clients. Each client is able to verify availabilityof protocol version, cipher suites, and extensions at all times once it has atleast 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 clientsoftware is updated while the client is a member of a group. Thus, in additionto preventing downgrade attacks, the members of a group can also observe when itis safe to upgrade to a new cipher suite or protocol version.¶

8.1.Assumptions on Transport Security Links

As discussed above, MLS provides the highest level of security when its messagesare delivered over an encrypted transport, thus preventing attackers fromselectively interfering with MLS communications as well asprotecting the already limited amount of metadata. Very littleinformation is contained in the unencrypted header of the MLS protocol messageformat for group operation messages, and application messages are alwaysencrypted in MLS.¶

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

MLS avoids the need to send the full list of recipients to the server fordispatching messages because that list could potentially contain tens ofthousands of recipients. Header metadata in MLS messages typically consists ofan opaquegroup_id, a numerical value to determine the epoch of the group (thenumber of changes that have been made to the group), and whether the message isan application message, a proposal, or a commit.¶

Even though some of this metadata information does not consist of sensitiveinformation, when correlated with other data a network observer might be able toreconstruct sensitive information. Using a secure channel to transfer thisinformation will prevent a network attacker from accessing this MLS protocolmetadata if it cannot compromise the secure channel.¶

8.2.Intended Security Guarantees

MLS aims to provide a number of security guarantees, covering authentication, aswell as confidentiality guarantees to different degrees in different scenarios.¶

8.3.Endpoint Compromise

The MLS protocol adopts a threat model which includes multiple forms ofendpoint/client compromise. While adversaries are in a strong position ifthey have compromised an MLS client, there are still situations where securityguarantees can be recovered thanks to the PCS properties achieved by the MLSprotocol.¶

In this section we will explore the consequences and recommendations regardingthe following 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 statecompromise).¶

8.4.Service Node Compromise

8.5.Considerations for Attacks Outside of the Threat Model

Physical attacks on devices storing and executing MLS principals are notconsidered in depth in the threat model of the MLS protocol. Whilenon-permanent, non-invasive attacks can sometimes be equivalent to softwareattacks, physical attacks are considered outside of the MLS threat model.¶

Compromise scenarios typically consist of a software adversary, which canmaintain active adaptive compromise and arbitrarily change the behavior of theclient or service.¶

On the other hand, security goals consider that honest clients will always runthe protocol according to its specification. This relies on implementations ofthe protocol to securely implement the specification, which remains non-trivial.¶

Recommendation: Additional steps should be taken to protect the device andthe MLS clients from physical compromise. In such settings, HSMs and secureenclaves 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 anothergroup member within the same epoch that the message was originally sent. Similarly, MLSdoes not protect against the replay (by a group member or otherwise) of a PublicMessagewithin the same epoch that the message was originally sent. Applications forwhom replay is an important risk should apply mitigations at the application layer, asdiscussed below.¶

In addition to the risks discussed inSection 8.3.1, an attackerwith access to the ratchet secrets for an endpoint can replay PrivateMessageobjects sent by other members of the group by taking the signed content of themessage and re-encrypting it with a new generation of the original sender'sratchet. If the other members of the group interpret a message with a newgeneration as a fresh message, then this message will appear fresh. (This ispossible because the message signature does not cover thegeneration fieldof the message.) Messages sent as PublicMessage objects similarly lack replayprotections. There is no message counter comparable to thegeneration fieldin PrivateMessage.¶

Applications can detect replay by including a unique identifier for the message(e.g., a counter) in either the message payload or theauthenticated_datafield, both of which are included in the signatures forPublicMessage and PrivateMessage.¶

8.7.Cryptographic Analysis of the MLS Protocol

Various academic works have analyzed MLS and the different security guaranteesit 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 the MLS protocol have beenanalyzed in isolation and with differing adversarial models. Forexample,[BBR18],[ACDT19],[ACCKKMPPWY19],[AJM20],[ACJM20],[AHKM21],[CGWZ25], and[WPB25] analyze theratcheting tree sub-protocol of MLS that facilitates key agreement;[WPBB22] analyzes the sub-protocol of MLS for group state agreementand authentication; and[BCK21] analyzes the key derivation paths inthe ratchet tree and key schedule. Finally,[CHK21] analyzes theauthentication and cross-group healing guarantees provided by MLS.¶

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., andK. 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

[ACCKKMPPWY19]

Alwen, J.,Capretto, M.,Cueto, M.,Kamath, C.,Klein, K.,Markov, I.,Pascual-Perez, G.,Pietrzak, K.,Walter, M., andM. 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., andY. 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., andY. 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., andM. 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., andM. Mularczyk,"Server-Aided Continuous Group Key Agreement",Cryptology ePrint Archive,2021,<https://eprint.iacr.org/2021/1456.pdf>.

[AJM20]

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

[BBN19]

Bhargavan, K.,Beurdouche, B., andP. 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., andE. 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., andK. 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., andM. 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., andK. 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. andR. 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., andG. 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. andB. 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., andW. 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. andM. 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., andK. 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., andK. Bhargavan,"TreeSync: Authenticated Group Management for Messaging Layer Security",Cryptology ePrint Archive,2022,<https://eprint.iacr.org/2022/1732.pdf>.