rfc9750v1.txt   rfc9750.txt 
Internet Engineering Task Force (IETF) B. Beurdouche Internet Engineering Task Force (IETF) B. Beurdouche
Request for Comments: 9750 Inria & Mozilla Request for Comments: 9750 Inria & Mozilla
Category: Informational E. Rescorla Category: Informational E. Rescorla
ISSN: 2070-1721 Windy Hill Systems, LLC ISSN: 2070-1721
E. Omara E. Omara
S. Inguva S. Inguva
A. Duric A. Duric
Wire
February 2025 February 2025
The Messaging Layer Security (MLS) Architecture The Messaging Layer Security (MLS) Architecture
Abstract Abstract
The Messaging Layer Security (MLS) protocol (RFC 9420) provides a The Messaging Layer Security (MLS) protocol (RFC 9420) provides a
Group Key Agreement protocol for messaging applications. MLS is group key agreement protocol for messaging applications. MLS is
meant to protect against eavesdropping, tampering, and message meant to protect against eavesdropping, tampering, and message
forgery and to provide Forward Secrecy (FS) and Post-Compromise forgery, and to provide forward secrecy (FS) and post-compromise
Security (PCS). security (PCS).
This document describes the architecture for using MLS in a general This document describes the architecture for using MLS in a general
secure group messaging infrastructure and defines the security goals secure group messaging infrastructure and defines the security goals
for MLS. It provides guidance on building a group messaging system for MLS. It provides guidance on building a group messaging system
and discusses security and privacy trade-offs offered by multiple and discusses security and privacy trade-offs offered by multiple
security mechanisms that are part of the MLS protocol (e.g., security mechanisms that are part of the MLS protocol (e.g.,
frequency of public encryption key rotation). The document also frequency of public encryption key rotation). The document also
provides guidance for parts of the infrastructure that are not provides guidance for parts of the infrastructure that are not
standardized by MLS and are instead left to the application. standardized by MLS and are instead left to the application.
While the recommendations of this document are not mandatory to While the recommendations of this document are not mandatory to
follow in order to interoperate at the protocol level, they affect follow in order to interoperate at the protocol level, they affect
the overall security guarantees that are achieved by a messaging the overall security guarantees that are achieved by a messaging
application. This is especially true in the case of active application. This is especially true in the case of active
adversaries that are able to compromise clients, the delivery adversaries that are able to compromise clients, the Delivery Service
service, or the authentication service. (DS), or the Authentication Service (AS).
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents Internet Engineering Steering Group (IESG). Not all documents
skipping to change at line 114 skipping to change at line 113
6.11. Compatibility with Future Versions of MLS 6.11. Compatibility with Future Versions of MLS
7. Operational Requirements 7. Operational Requirements
8. Security and Privacy Considerations 8. Security and Privacy Considerations
8.1. Assumptions on Transport Security Links 8.1. Assumptions on Transport Security Links
8.1.1. Integrity and Authentication of Custom Metadata 8.1.1. Integrity and Authentication of Custom Metadata
8.1.2. Metadata Protection for Unencrypted Group Operations 8.1.2. Metadata Protection for Unencrypted Group Operations
8.1.3. DoS Protection 8.1.3. DoS Protection
8.1.4. Message Suppression and Error Correction 8.1.4. Message Suppression and Error Correction
8.2. Intended Security Guarantees 8.2. Intended Security Guarantees
8.2.1. Message Secrecy and Authentication 8.2.1. Message Secrecy and Authentication
8.2.2. Forward and Post-Compromise Security 8.2.2. Forward Secrecy and Post-Compromise Security
8.2.3. Non-Repudiation vs. Deniability 8.2.3. Non-Repudiation vs. Deniability
8.2.4. Associating a User's Clients 8.2.4. Associating a User's Clients
8.3. Endpoint Compromise 8.3. Endpoint Compromise
8.3.1. Compromise of Symmetric Keying Material 8.3.1. Compromise of Symmetric Keying Material
8.3.2. Compromise by an Active Adversary with the Ability to 8.3.2. Compromise by an Active Adversary with the Ability to
Sign Messages Sign Messages
8.3.3. Compromise of the Authentication with Access to a 8.3.3. Compromise of Authentication with Access to a Signature
Signature Key Key
8.3.4. Security Considerations in the Context of a Full State 8.3.4. Security Considerations in the Context of a Full State
Compromise Compromise
8.4. Service Node Compromise 8.4. Service Node Compromise
8.4.1. General Considerations 8.4.1. General Considerations
8.4.2. Delivery Service Compromise 8.4.2. Delivery Service Compromise
8.4.3. Authentication Service Compromise 8.4.3. Authentication Service Compromise
8.5. Considerations for Attacks Outside of the Threat Model 8.5. Considerations for Attacks Outside of the Threat Model
8.6. Cryptographic Analysis of the MLS Protocol 8.6. No Protection against Replay by Insiders
8.7. Cryptographic Analysis of the MLS Protocol
9. IANA Considerations 9. IANA Considerations
10. References 10. References
10.1. Normative References 10.1. Normative References
10.2. Informative References 10.2. Informative References
Contributors Contributors
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
End-to-end security is used in the vast majority of instant messaging End-to-end security is used in the vast majority of instant messaging
skipping to change at line 183 skipping to change at line 183
The group is represented as a tree, which represents the members as The group is represented as a tree, which represents the members as
the leaves of a tree. It is used to efficiently encrypt to subsets the leaves of a tree. It is used to efficiently encrypt to subsets
of the members. Each member has a state called a _LeafNode_ object of the members. Each member has a state called a _LeafNode_ object
holding the client's identity, credentials, and capabilities. holding the client's identity, credentials, and capabilities.
Various messages are used in the evolution from epoch to epoch. A Various messages are used in the evolution from epoch to epoch. A
_Proposal_ message proposes a change to be made in the next epoch, _Proposal_ message proposes a change to be made in the next epoch,
such as adding or removing a member. A _Commit_ message initiates a such as adding or removing a member. A _Commit_ message initiates a
new epoch by instructing members of the group to implement a new epoch by instructing members of the group to implement a
collection of proposals. Proposals and Commits are collectively collection of proposals. Proposals and Commits are collectively
called _Handshake messages_. A _KeyPackage_ provides keys that can called _handshake messages_. A _KeyPackage_ provides keys that can be
be used to add the client to a group, including its LeafNode, and used to add the client to a group, including a public encryption key
_Signature Key_. A _Welcome_ message provides a new member to the and a signature key (both stored in the KeyPackage's LeafNode
group with the information to initialize their state for the epoch in object). A _Welcome_ message provides a new member to the group with
which they were added. the information to initialize their state for the epoch in which they
were added.
Of course most (but not all) applications use MLS to send encrypted Of course most (but not all) applications use MLS to send encrypted
group messages. An _application message_ is an MLS message with an group messages. An _application message_ is an MLS message with an
arbitrary application payload. arbitrary application payload.
Finally, a _PublicMessage_ contains an integrity-protected MLS Finally, a _PublicMessage_ contains an integrity-protected MLS
Handshake message, while a _PrivateMessage_ contains a confidential, handshake message, while a _PrivateMessage_ contains a confidential,
integrity-protected Handshake or application message. integrity-protected Handshake or application message.
For a more detailed explanation of these terms, please consult the For a more detailed explanation of these terms, please consult the
MLS protocol specification [RFC9420]. MLS protocol specification [RFC9420].
2.2. Abstract Services 2.2. Abstract Services
MLS is designed to operate within the context of a messaging service, MLS is designed to operate within the context of a messaging service,
which may be a single service provider, a federated system, or some which may be a single service provider, a federated system, or some
kind of peer-to-peer system. The service needs to provide two kind of peer-to-peer system. The service needs to provide two
services that facilitate client communication using MLS: services that facilitate client communication using MLS:
* An Authentication Service (AS) which is responsible for attesting * An Authentication Service (AS), which is responsible for attesting
to bindings between application-meaningful identifiers and the to bindings between application-meaningful identifiers and the
public key material used for authentication in the MLS protocol. public key material used for authentication in the MLS protocol.
The AS must also be able to generate credentials that encode these The AS must also be able to generate credentials that encode these
bindings and validate credentials provided by MLS clients. bindings and validate credentials provided by MLS clients.
* A Delivery Service (DS) which can receive and distribute messages * A Delivery Service (DS), which can receive and distribute messages
between group members. In the case of group messaging, the between group members. In the case of group messaging, the
delivery service may also be responsible for acting as a delivery service may also be responsible for acting as a
"broadcaster" where the sender sends a single message which is "broadcaster" where the sender sends a single message which is
then forwarded to each recipient in the group by the DS. The DS then forwarded to each recipient in the group by the DS. The DS
is also responsible for storing and delivering initial public key is also responsible for storing and delivering initial public key
material required by MLS clients in order to proceed with the material required by MLS clients in order to proceed with the
group secret key establishment that is part of the MLS protocol. group secret key establishment that is part of the MLS protocol.
For presentation purposes, this document treats the AS and DS as For presentation purposes, this document treats the AS and DS as
conventional network services. However, MLS does not require a conventional network services. However, MLS does not require a
skipping to change at line 241 skipping to change at line 242
* MLS clients connected to a peer-to-peer network could instantiate * MLS clients connected to a peer-to-peer network could instantiate
a decentralized DS by transmitting MLS messages over that network. a decentralized DS by transmitting MLS messages over that network.
* In an MLS group using a Public Key Infrastructure (PKI) for * In an MLS group using a Public Key Infrastructure (PKI) for
authentication, the AS would comprise the certificate issuance and authentication, the AS would comprise the certificate issuance and
validation processes, both of which involve logic inside MLS validation processes, both of which involve logic inside MLS
clients as well as various existing PKI roles (e.g., Certification clients as well as various existing PKI roles (e.g., Certification
Authorities). Authorities).
It is important to note that the Authentication Service can be It is important to note that the AS can be completely abstract in the
completely abstract in the case of a Service Provider that allows MLS case of a service provider which allows MLS clients to generate,
clients to generate, distribute, and validate credentials themselves. distribute, and validate credentials themselves. As with the AS, the
As with the AS, the Delivery Service can be completely abstract if DS can be completely abstract if users are able to distribute
users are able to distribute credentials and messages without relying credentials and messages without relying on a central DS (as in a
on a central Delivery Service (as in a peer-to-peer system). Note, peer-to-peer system). Note, though, that in such scenarios, clients
though, that in such scenarios, clients will need to implement logic will need to implement logic that assures the delivery properties
that assures the delivery properties required of the DS (see required of the DS (see Section 5.2).
Section 5.2).
Figure 1 shows the relationship of these concepts, with three clients Figure 1 shows the relationship of these concepts, with three clients
and one group, and clients 2 and 3 being part of the group and client and one group, and clients 2 and 3 being part of the group and client
1 not being part of any group. 1 not being part of any group.
+----------------+ +--------------+ +----------------+ +--------------+
| Authentication | | Delivery | | Authentication | | Delivery |
| Service (AS) | | Service (DS) | | Service (AS) | | Service (DS) |
+----------------+ +-------+------+ +----------------+ +-------+------+
/ | \ Group / | \ Group
skipping to change at line 278 skipping to change at line 278
Figure 1: A Simplified Messaging System Figure 1: A Simplified Messaging System
3. Overview of Operation 3. Overview of Operation
Figure 2 shows the formation of an example group consisting of Alice, Figure 2 shows the formation of an example group consisting of Alice,
Bob, and Charlie, with Alice driving the creation of the group. Bob, and Charlie, with Alice driving the creation of the group.
Alice Bob Charlie AS DS Alice Bob Charlie AS DS
Create account ---------------------------------> | Create account ---------------------------------> |
<------------------------------------- Credential | <------------------------------------- Credential |
Create account -----------------------> | Step 1 Create account -----------------------> | Step 1
<--------------------------- Credential | <--------------------------- Credential |
Create account -------------> | Create account -------------> |
<----------------- Credential | <----------------- Credential |
Initial Keying Material -----------------------------------> | Initial Keying Material -----------------------------------> |
Initial Keying Material -------------------------> | Step 2 Initial Keying Material -------------------------> | Step 2
Initial Keying Material ---------------> | Initial Keying Material ---------------> |
Get Bob Initial Keying Material ---------------------------> | Get Bob Initial Keying Material ---------------------------> |
<------------------------------- Bob Initial Keying Material | <------------------------------- Bob Initial Keying Material |
Add Bob to Group ------------------------------------------> | Step 3 Add Bob to group ------------------------------------------> | Step 3
Welcome (Bob) ---------------------------------------------> | Welcome(Bob) ----------------------------------------------> |
<-------------------------------- Add Bob to Group | <-------------------------------- Add Bob to group |
<----------------------------------- Welcome (Bob) | <------------------------------------ Welcome(Bob) |
Get Charlie Initial Keying Material -----------------------> | Get Charlie Initial Keying Material -----------------------> |
<--------------------------- Charlie Initial Keying Material | <--------------------------- Charlie Initial Keying Material |
Add Charlie to Group --------------------------------------> | Add Charlie to group --------------------------------------> |
Welcome (Charlie) -----------------------------------------> | Step 4 Welcome(Charlie) ------------------------------------------> | Step 4
<---------------------------- Add Charlie to Group | <---------------------------- Add Charlie to group |
<----------------- Add Charlie to Group | <----------------- Add Charlie to group |
<-------------------- Welcome (Charlie) | <--------------------- Welcome(Charlie) |
Figure 2: Group Formation Example Figure 2: Group Formation Example
This process proceeds as follows. This process proceeds as follows.
3.1. Step 1: Account Creation 3.1. Step 1: Account Creation
Alice, Bob, and Charlie create accounts with a service provider and Alice, Bob, and Charlie create accounts with a service provider and
obtain credentials from the AS. This is a one-time setup phase. obtain credentials from the AS. This is a one-time setup phase.
3.2. Step 2: Initial Keying Material 3.2. Step 2: Initial Keying Material
Alice, Bob, and Charlie authenticate to the DS and store some initial Alice, Bob, and Charlie authenticate to the DS and store some initial
keying material which can be used to send encrypted messages to them keying material which is used to send encrypted messages to them for
for the first time. This keying material is authenticated with their the first time. This keying material is authenticated with their
long-term credentials. Although in principle this keying material long-term credentials. Although in principle this keying material
can be reused for multiple senders, in order to provide forward can be reused for multiple senders, in order to provide forward
secrecy it is better for this material to be regularly refreshed so secrecy it is better for this material to be regularly refreshed so
that each sender can use a new key. that each sender can use a new key and delete older keys.
3.3. Step 3: Adding Bob to the Group 3.3. Step 3: Adding Bob to the Group
When Alice wants to create a group including Bob, she first uses the When Alice wants to create a group including Bob, she first uses the
DS to look up his initial keying material. She then generates two DS to look up his initial keying material. She then generates two
messages: messages:
* A message to the entire group (which at this point is just her and * A message to the entire group (which at this point is just her and
Bob) that adds Bob to the group. Bob) that adds Bob to the group.
* A _Welcome_ message just to Bob encrypted with his initial keying * A Welcome message just to Bob encrypted with his initial keying
material that includes the secret keying information necessary to material that includes the secret keying information necessary to
join the group. join the group.
She sends both of these messages to the Delivery Service, which is She sends both of these messages to the DS, which is responsible for
responsible for sending them to the appropriate people. Note that sending them to the appropriate people. Note that the security of
the security of MLS does not depend on the DS forwarding the Welcome MLS does not depend on the DS forwarding the Welcome message only to
message only to Bob, as it is encrypted for him; it is simply not Bob, as it is encrypted for him; it is simply not necessary for other
necessary for other group members to receive it. group members to receive it.
3.4. Step 4: Adding Charlie to the Group 3.4. Step 4: Adding Charlie to the Group
If Alice then wants to add Charlie to the group, she follows a If Alice then wants to add Charlie to the group, she follows a
similar procedure as with Bob: She first uses the DS to look up his similar procedure as with Bob. She first uses the DS to look up his
initial keying material and then generates two messages: initial keying material and then generates two messages:
* A message to the entire group (consisting of her, Bob, and * A message to the entire group (consisting of her, Bob, and
Charlie) adding Charlie to the group. Charlie) adding Charlie to the group.
* A _Welcome_ message just to Charlie encrypted with his initial * A Welcome message just to Charlie encrypted with his initial
keying material that includes the secret keying information keying material that includes the secret keying information
necessary to join the group. necessary to join the group.
At the completion of this process, we have a group with Alice, Bob, At the completion of this process, we have a group with Alice, Bob,
and Charlie, which means that they share a single encryption key that and Charlie, which means that they share a single encryption key
can be used to send messages or to key other protocols. which can be used to send messages or to key other protocols.
3.5. Other Group Operations 3.5. Other Group Operations
Once the group has been created, clients can perform other actions, Once the group has been created, clients can perform other actions,
such as: such as:
* sending a message to everyone in the group * sending a message to everyone in the group
* receiving a message from someone in the group * receiving a message from someone in the group
skipping to change at line 398 skipping to change at line 398
The general pattern for any change in the group state (e.g., to add The general pattern for any change in the group state (e.g., to add
or remove a user) is that it consists of two messages: or remove a user) is that it consists of two messages:
Proposal: This message describes the change to be made (e.g., add Proposal: This message describes the change to be made (e.g., add
Bob to the group) but does not effect a change. Bob to the group) but does not effect a change.
Commit: This message changes the group state to include the changes Commit: This message changes the group state to include the changes
described in a set of proposals. described in a set of proposals.
The simplest pattern is for a client to just send a Commit which The simplest pattern is for a client to just send a Commit which
contains one or more Proposals; for instance, Alice could send a contains one or more Proposals. For instance, Alice could send a
Commit with the Proposal Add(Bob) embedded to add Bob to the group. Commit with the Proposal Add(Bob) embedded to add Bob to the group.
However, there are situations in which one client might send a However, there are situations in which one client might send a
proposal and another might send the commit. For instance, Bob might Proposal and another might send the corresponding Commit. For
wish to remove himself from the group and send a Remove Proposal to instance, Bob might wish to remove himself from the group and send a
do so (see Section 12.1.3 of [RFC9420]). Because Bob cannot send the Remove proposal to do so (see Section 12.1.3 of [RFC9420]). Because
Commit, an existing member must do so. Commits can apply to multiple Bob cannot send the Commit, an existing member must do so. Commits
valid Proposals, in which case all the listed changes are applied. can apply to multiple valid Proposals, in which case all the listed
changes are applied.
It is also possible for a Commit to apply to an empty set of 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 Proposals, in which case it just updates the cryptographic state of
the group without changing its membership. the group without changing its membership.
3.7. Users, Clients, and Groups 3.7. Users, Clients, and Groups
While it's natural to think of a messaging system as consisting of While it's natural to think of a messaging system as consisting of
groups of users, possibly using different devices, in MLS the basic groups of users, possibly using different devices, in MLS the basic
unit of operation is not the user but rather the "client". Formally, unit of operation is not the user but rather the "client". Formally,
skipping to change at line 429 skipping to change at line 430
by demonstrating knowledge of the associated secret values. by demonstrating knowledge of the associated secret values.
In some messaging systems, clients belonging to the same user must In some messaging systems, clients belonging to the same user must
all share the same signature key pair, but MLS does not assume this; 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 instead, a user may have multiple clients with the same identity and
different keys. In this case, each client will have its own different keys. In this case, each client will have its own
cryptographic state, and it is up to the application to determine how cryptographic state, and it is up to the application to determine how
to present this situation to users. For instance, it may render to present this situation to users. For instance, it may render
messages to and from a given user identically regardless of which messages to and from a given user identically regardless of which
client they are associated with, or it may choose to distinguish client they are associated with, or it may choose to distinguish
them. them. It is also possible to have multiple clients associated with
the same user share state, as described in Section 8.2.4.
When a client is part of a Group, it is called a Member. A group in When a client is part of a group, it is called a member. A group in
MLS is defined as the set of clients that have knowledge of the MLS is defined as the set of clients that have knowledge of the
shared group secret established in the group key establishment phase. shared group secret established in the group key establishment phase.
Note that until a client has been added to the group and contributed Note that until a client has been added to the group and contributed
to the group secret in a manner verifiable by other members of the to the group secret in a manner verifiable by other members of the
group, other members cannot assume that the client is a member of the group, other members cannot assume that the client is a member of the
group; for instance, the newly added member might not have received group; for instance, the newly added member might not have received
the Welcome message or might not have been able to decrypt it for the Welcome message or been unable to decrypt it for some reason.
some reason.
4. Authentication Service 4. Authentication Service
The Authentication Service (AS) has to provide three services: The Authentication Service (AS) has to provide three services:
1. Issue credentials to clients that attest to bindings between 1. Issue credentials to clients that attest to bindings between
identities and signature key pairs. identities and signature key pairs.
2. Enable a client to verify that a credential presented by another 2. Enable a client to verify that a credential presented by another
client is valid with respect to a reference identifier. client is valid with respect to a reference identifier.
skipping to change at line 476 skipping to change at line 477
verification by clients. verification by clients.
* Several current messaging applications rely on users verifying * Several current messaging applications rely on users verifying
each other's key fingerprints for authentication. In this each other's key fingerprints for authentication. In this
scenario, the issuance function is simply the generation of a key scenario, the issuance function is simply the generation of a key
pair (i.e., a credential is just an identifier and public key, pair (i.e., a credential is just an identifier and public key,
with no information to assist in verification). The verification with no information to assist in verification). The verification
function is the application function that enables users to verify function is the application function that enables users to verify
keys. keys.
* In a system based on end-user Key Transparency (KT) [CONIKS] [KT], * In a system based on end-user Key Transparency (KT) [KT], the
the issuance function would correspond to the insertion of a key issuance function would correspond to the insertion of a key in a
in a KT log under a user's identity. The verification function KT log under a user's identity. The verification function would
would correspond to verifying a key's inclusion in the log for a correspond to verifying a key's inclusion in the log for a claimed
claimed identity, together with the KT log's mechanisms for a user identity, together with the KT log's mechanisms for a user to
to monitor and control which keys are associated with their monitor and control which keys are associated with their identity.
identity.
By the nature of its roles in MLS authentication, the AS is invested 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 with a large amount of trust and the compromise of the AS could allow
an adversary to, among other things, impersonate group members. We an adversary to, among other things, impersonate group members. We
discuss security considerations regarding the compromise of the discuss security considerations regarding the compromise of the
different AS functions in detail in Section 8.4.3. different AS functions in detail in Section 8.4.3.
The association between members' identities and their signature keys The association between members' identities and their signature keys
is fairly flexible in MLS. As noted above, there is no requirement is fairly flexible in MLS. As noted above, there is no requirement
that all clients belonging to a given user have the same signature that all clients belonging to a given user have the same signature
key (in fact, having duplicate signature keys in a group is key (in fact, having duplicate signature keys in a group is
forbidden). A member can also rotate the signature key they use forbidden). A member can also rotate the signature key they use
within a group. These mechanisms allow clients to use different within a group. These mechanisms allow clients to use different
signature keys in different contexts and at different points in time, signature keys in different contexts and at different points in time,
providing unlinkability and post-compromise security benefits. Some providing unlinkability and post-compromise security benefits. Some
security trade-offs related to this flexibility are discussed in the security trade-offs related to this flexibility are discussed in
security considerations. Section 8.
In many applications, there are multiple MLS clients that represent a In many applications, there are multiple MLS clients that represent a
single entity -- for example, a human user with a mobile and desktop single entity, such as a human user with a mobile and desktop version
version of an application. Often, the same set of clients is of an application. Often, the same set of clients is represented in
represented in exactly the same list of groups. In applications exactly the same list of groups. In applications where this is the
where this is the intended situation, other clients can check that a intended situation, other clients can check that a user is
user is consistently represented by the same set of clients. This consistently represented by the same set of clients. This would make
would make it more difficult for a malicious AS to issue fake it more difficult for a malicious AS to issue fake credentials for a
credentials for a particular user because clients would expect the particular user because clients would expect the credential to appear
credential to appear in all groups of which the user is a member. If in all groups of which the user is a member. If a client credential
a client credential does not appear in all groups after some does not appear in all groups after some relatively short period of
relatively short period of time, clients have an indication that the time, clients have an indication that the credential might have been
credential might have been created without the user's knowledge. Due created without the user's knowledge. Due to the asynchronous nature
to the asynchronous nature of MLS, however, there may be transient of MLS, however, there may be transient inconsistencies in a user's
inconsistencies in a user's client set, so correlating users' clients client set, so correlating users' clients across groups is more of a
across groups is more of a detection mechanism than a prevention detection mechanism than a prevention mechanism.
mechanism.
5. Delivery Service 5. Delivery Service
The Delivery Service (DS) plays two major roles in MLS: The Delivery Service (DS) plays two major roles in MLS:
* As a directory service providing the initial keying material for * As a directory service, providing the initial keying material for
clients to use. This allows a client to establish a shared key clients to use. This allows a client to establish a shared key
and send encrypted messages to other clients even if they're and send encrypted messages to other clients even if they're
offline. offline.
* Routing MLS messages among clients. * Routing MLS messages among clients.
While MLS depends on correct behavior by the Authentication Service While MLS depends on correct behavior by the AS in order to provide
in order to provide endpoint authentication and hence confidentiality endpoint authentication and hence confidentiality of the group key,
of the group key, these properties do not depend on correct behavior these properties do not depend on correct behavior by the DS; even a
by the DS; even a malicious DS cannot add itself to groups or recover malicious DS cannot add itself to groups or recover the group key.
the group key. However, depending precisely on how MLS is used, the However, depending precisely on how MLS is used, the DS may be able
DS may be able to determine group membership or prevent changes to to determine group membership or prevent changes to the group from
the group from taking place (e.g., by blocking group change taking place (e.g., by blocking group change messages).
messages).
5.1. Key Storage and Retrieval 5.1. Key Storage and Retrieval
Upon joining the system, each client stores its initial cryptographic Upon joining the system, each client stores its initial cryptographic
key material with the Delivery Service. This key material, called a key material with the DS. This key material, called a KeyPackage,
KeyPackage, advertises the functional abilities of the client such as advertises the functional abilities of the client (e.g., supported
supported protocol versions, supported extensions, and the following protocol versions, supported extensions, etc.) and the following
cryptographic information: cryptographic information:
* A credential from the Authentication Service attesting to the * A credential from the AS attesting to the binding between the
binding between the identity and the client's signature key. identity and the client's signature key.
* The client's asymmetric encryption public key. * The client's asymmetric encryption public key.
All the parameters in the KeyPackage are signed with the signature All the parameters in the KeyPackage are signed with the signature
private key corresponding to the credential. As noted in private key corresponding to the credential. As noted in
Section 3.7, users may own multiple clients, each with their own Section 3.7, users may own multiple clients, each with their own
keying material. Each KeyPackage is specific to an MLS version and keying material. Each KeyPackage is specific to an MLS version and
ciphersuite, but a client may want to offer support for multiple ciphersuite, but a client may want to offer support for multiple
protocol versions and ciphersuites. As such, there may be multiple protocol versions and ciphersuites. As such, there may be multiple
KeyPackages stored by each user for a mix of protocol versions, KeyPackages stored by each user for a mix of protocol versions,
ciphersuites, and end-user devices. ciphersuites, and end-user devices.
When a client wishes to establish a group or add clients to a group, When a client wishes to establish a group or add clients to a group,
it first contacts the Delivery Service to request KeyPackages for it first contacts the DS to request KeyPackages for each of the other
each other client, authenticates the KeyPackages using the signature clients, authenticates the KeyPackages using the signature keys,
keys, includes the KeyPackages in Add Proposals, and encrypts the includes the KeyPackages in Add proposals, and encrypts the
information needed to join the group (the _GroupInfo_ object) with an information needed to join the group (the _GroupInfo_ object) with an
ephemeral key; it then separately encrypts the ephemeral key with the ephemeral key; it then separately encrypts the ephemeral key with the
init_key from each KeyPackage. When a client requests a KeyPackage public encryption key (init_key) from each KeyPackage. When a client
in order to add a user to a group, the Delivery Service should requests a KeyPackage in order to add a user to a group, the DS
provide the minimum number of KeyPackages necessary to satisfy the should provide the minimum number of KeyPackages necessary to satisfy
request. For example, if the request specifies the MLS version, the the request. For example, if the request specifies the MLS version,
DS might provide one KeyPackage per supported ciphersuite, even if it the DS might provide one KeyPackage per supported ciphersuite, even
has multiple such KeyPackages to enable the corresponding client to if it has multiple such KeyPackages to enable the corresponding
be added to multiple groups before needing to upload more fresh client to be added to multiple groups before needing to upload more
KeyPackages. fresh KeyPackages.
In order to avoid replay attacks and provide forward secrecy for In order to avoid replay attacks and provide forward secrecy for
messages sent using the initial keying material, KeyPackages are messages sent using the initial keying material, KeyPackages are
intended to be used only once. The Delivery Service is responsible intended to be used only once, and init_key is intended to be deleted
for ensuring that each KeyPackage is only used to add its client to a by the client after decryption of the Welcome message. The DS is
single group, with the possible exception of a "last resort" responsible for ensuring that each KeyPackage is only used to add its
KeyPackage that is specially designated by the client to be used client to a single group, with the possible exception of a "last
multiple times. Clients are responsible for providing new 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 KeyPackages as necessary in order to minimize the chance that the
"last resort" KeyPackage will be used. "last resort" KeyPackage will be used.
*RECOMMENDATION:* Ensure that "last resort" KeyPackages don't get *Recommendation:* Ensure that "last resort" KeyPackages don't get
used by provisioning enough standard KeyPackages. used by provisioning enough standard KeyPackages.
*RECOMMENDATION:* Rotate "last resort" KeyPackages as soon as *Recommendation:* Rotate "last resort" KeyPackages as soon as
possible after being used or if they have been stored for a possible after being used or if they have been stored for a
prolonged period of time. Overall, avoid reusing "last resort" prolonged period of time. Overall, avoid reusing "last resort"
KeyPackages as much as possible. KeyPackages as much as possible.
*RECOMMENDATION:* Ensure that the client for which a "last resort" *Recommendation:* Ensure that the client for which a "last resort"
KeyPackage has been used is updating leaf keys as early as KeyPackage has been used is updating leaf keys as early as
possible. possible.
*Recommendation:* Ensure that clients delete the private component
of their init_key after processing a Welcome message, or after the
rotation of "last resort" KeyPackage.
Overall, it needs to be noted that key packages need to be updated Overall, it needs to be noted that key packages need to be updated
when signature keys are changed. when signature keys are changed.
5.2. Delivery of Messages 5.2. Delivery of Messages
The main responsibility of the Delivery Service is to ensure delivery The main responsibility of the DS is to ensure delivery of messages.
of messages. Some MLS messages need only be delivered to specific Some MLS messages need only be delivered to specific clients (e.g., a
clients (e.g., a Welcome message initializing a new member's state), Welcome message initializing a new member's state), while others need
while others need to be delivered to all the members of a group. The to be delivered to all the members of a group. The DS may enable the
Delivery Service may enable the latter delivery pattern via unicast latter delivery pattern via unicast channels (sometimes known as
channels (sometimes known as "client fanout"), broadcast channels "client fanout"), broadcast channels ("server fanout"), or a mix of
("server fanout"), or a mix of both. both.
For the most part, MLS does not require the Delivery Service to For the most part, MLS does not require the DS to deliver messages in
deliver messages in any particular order. Applications can set any particular order. Applications can set policies that control
policies that control their tolerance for out-of-order messages (see their tolerance for out-of-order messages (see Section 7), and
Section 7), and messages that arrive significantly out of order can messages that arrive significantly out of order can be dropped
be dropped without otherwise affecting the protocol. There are two without otherwise affecting the protocol. There are two exceptions
exceptions to this. First, Proposal messages should all arrive to this. First, Proposal messages should all arrive before the
before the Commit that references them. Second, because an MLS group Commit that references them. Second, because an MLS group has a
has a linear history of epochs, the members of the group must agree linear history of epochs, the members of the group must agree on the
on the order in which changes are applied. Concretely, the group order in which changes are applied. Concretely, the group must agree
must agree on a single MLS Commit message that ends each epoch and on a single MLS Commit message that ends each epoch and begins the
begins the next one. next one.
In practice, there's a realistic risk of two members generating In practice, there's a realistic risk of two members generating
Commit messages at the same time, based on the same epoch, and both 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 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 which this is a problem, and the appropriate solution, depend on the
design of the Delivery Service. Per the CAP theorem [CAPBR], there design of the DS. Per the CAP theorem [CAPBR], there are two general
are two general classes of distributed systems that the Delivery classes of distributed systems that the DS might fall into:
Service might fall into:
* Consistent and Partition-tolerant, or Strongly Consistent, * Consistent and Partition-tolerant, or Strongly Consistent,
systems, which can provide a globally consistent view of data but systems, which can provide a globally consistent view of data but
have the inconvenience of clients needing to handle rejected have the inconvenience of clients needing to handle rejected
messages. messages.
* Available and Partition-tolerant, or Eventually Consistent, * Available and Partition-tolerant, or Eventually Consistent,
systems, which continue working despite network issues but may systems, which continue working despite network issues but may
return different views of data to different users. return different views of data to different users.
Strategies for sequencing messages in strongly and eventually Strategies for sequencing messages in strongly and eventually
consistent systems are described in the next two subsections. Most consistent systems are described in the next two subsections. Most
Delivery Services will use the Strongly Consistent paradigm, but this DSs will use the strongly consistent paradigm, but this remains a
remains a choice that can be handled in coordination with the client choice that can be handled in coordination with the client and
and advertised in the KeyPackages. advertised in the KeyPackages.
However, note that a malicious Delivery Service could also reorder However, note that a malicious DS could also reorder messages or
messages or provide an inconsistent view to different users. The provide an inconsistent view to different users. The "generation"
"generation" counter in MLS messages provides per-sender loss counter in MLS messages provides per-sender loss detection and
detection and ordering that cannot be manipulated by the DS, but this ordering that cannot be manipulated by the DS, but this does not
does not provide complete protection against partitioning. A DS can provide complete protection against partitioning. A DS can cause a
cause a partition in the group by partitioning key exchange messages; partition in the group by partitioning key exchange messages; this
this can be detected only by out-of-band comparison (e.g., confirming can be detected only by out-of-band comparison (e.g., confirming that
that all clients have the same epoch_authenticator value). A all clients have the same epoch_authenticator value). A mechanism
mechanism for more robust protections is discussed in [EXTENSIONS]. for more robust protections is discussed in [EXTENSIONS].
Other forms of Delivery Service misbehavior are still possible that Other forms of DS misbehavior are still possible that are not easy to
are not easy to detect. For instance, a Delivery Service can simply detect. For instance, a DS can simply refuse to relay messages to
refuse to relay messages to and from a given client. Without some and from a given client. Without some sort of side information,
sort of side information, other clients cannot generally detect this other clients cannot generally detect this form of Denial-of-Service
form of Denial-of-Service (DoS) attack. (DoS) attack.
5.2.1. Strongly Consistent 5.2.1. Strongly Consistent
With this approach, the Delivery Service ensures that some types of With this approach, the DS ensures that some types of incoming
incoming messages have a linear order and all members agree on that messages have a linear order and all members agree on that order.
order. The Delivery Service is trusted to break ties when two The Delivery Service is trusted to break ties when two members send a
members send a Commit message at the same time. Commit message at the same time.
As an example, there could be an "ordering server" Delivery Service As an example, there could be an "ordering server" DS that broadcasts
that broadcasts all messages received to all users and ensures that all messages received to all users and ensures that all clients see
all clients see messages in the same order. This would allow clients messages in the same order. This would allow clients to only apply
to only apply the first valid Commit for an epoch and ignore the first valid Commit for an epoch and ignore subsequent Commits.
subsequent Commits. Clients that send a Commit would then wait to Clients that send a Commit would then wait to apply it until it is
apply it until it is broadcast back to them by the Delivery Service, broadcast back to them by the Delivery Service, assuming that they do
assuming that they do not receive another Commit first. not receive another Commit first.
Alternatively, the Delivery Service can rely on the epoch and Alternatively, the DS can rely on the epoch and content_type fields
content_type fields of an MLSMessage to provide an order only to of an MLSMessage to provide an order only to handshake messages, and
handshake messages, and possibly even filter or reject redundant possibly even filter or reject redundant Commit messages proactively
Commit messages proactively to prevent them from being broadcast. to prevent them from being broadcast. There is some risk associated
There is some risk associated with filtering; this is discussed with filtering; this is discussed further in Section 5.3.
further in Section 5.3.
5.2.2. Eventually Consistent 5.2.2. Eventually Consistent
With this approach, the Delivery Service is built in a way that may With this approach, the DS is built in a way that may be
be significantly more available or performant than a strongly significantly more available or performant than a strongly consistent
consistent system, but offers weaker consistency guarantees. system, but where it offers weaker consistency guarantees. Messages
Messages may arrive to different clients in different orders and with may arrive to different clients in different orders and with varying
varying amounts of latency, which means clients are responsible for amounts of latency, which means clients are responsible for
reconciliation. reconciliation.
This type of Delivery Service might arise, for example, when group This type of DS might arise, for example, when group members are
members are sending each message to each other member individually or sending each message to each other member individually or when a
when a distributed peer-to-peer network is used to broadcast distributed peer-to-peer network is used to broadcast messages.
messages.
Upon receiving a Commit from the Delivery Service, clients can do Upon receiving a Commit from the DS, clients can either:
either of the following:
1. Pause sending new messages for a short amount of time to account 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 for a reasonable degree of network latency and see if any other
Commits are received for the same epoch. If multiple Commits are Commits are received for the same epoch. If multiple Commits are
received, the clients can use a deterministic tie-breaking policy received, the clients can use a deterministic tie-breaking policy
to decide which to accept, and then resume sending messages as to decide which to accept, and then resume sending messages as
normal. normal.
2. Accept the Commit immediately but keep a copy of the previous 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 group state for a short period of time. If another Commit for a
past epoch is received, clients use a deterministic tie-breaking past epoch is received, clients use a deterministic tie-breaking
policy to decide if they should continue using the Commit they policy to decide if they should continue using the Commit they
originally accepted or revert and use the later one. Note that originally accepted or revert and use the later one. Note that
any copies of previous or forked group states must be deleted any copies of previous or forked group states must be deleted
within a reasonable amount of time to ensure that the protocol within a reasonable amount of time to ensure that the protocol
provides forward secrecy. provides forward secrecy.
If the Commit references an unknown proposal, group members may need If the Commit references an unknown proposal, group members may need
to solicit the Delivery Service or other group members individually to solicit the DS or other group members individually for the
for the contents of the proposal. contents of the proposal.
5.2.3. Welcome Messages 5.2.3. Welcome Messages
Whenever a commit adds new members to a group, MLS requires the Whenever a commit adds new members to a group, MLS requires the
committer to send a Welcome message to the new members. Applications committer to send a Welcome message to the new members. Applications
should ensure that Welcome messages are coupled with the tie-breaking should ensure that Welcome messages are coupled with the tie-breaking
logic for commits (see Sections 5.2.1 and 5.2.2). That is, when logic for commits (see Sections 5.2.1 and 5.2.2). That is, when
multiple commits are sent for the same epoch, applications need to multiple commits are sent for the same epoch, applications need to
ensure that only Welcome messages corresponding to the commit that ensure that only Welcome messages corresponding to the commit that
"succeeded" are processed by new members. "succeeded" are processed by new members.
skipping to change at line 770 skipping to change at line 769
form described in Section 16.12 of [RFC9420]. form described in Section 16.12 of [RFC9420].
In situations where the DS is attempting to filter redundant Commits, In situations where the DS is attempting to filter redundant Commits,
the DS might update its internal state under the assumption that a the DS might update its internal state under the assumption that a
Commit has succeeded and thus end up in a state inconsistent with the Commit has succeeded and thus end up in a state inconsistent with the
members of the group. For example, the DS might think that the members of the group. For example, the DS might think that the
current epoch is now n+1 and reject any commits from other epochs, current epoch is now n+1 and reject any commits from other epochs,
while the members think the epoch is n, and as a result, the group is while the members think the epoch is n, and as a result, the group is
stuck -- no member can send a Commit that the DS will accept. stuck -- no member can send a Commit that the DS will accept.
Such "desynchronization" problems can arise even when the Delivery Such "desynchronization" problems can arise even when the DS takes no
Service takes no stance on which Commit is "correct" for an epoch. stance on which Commit is "correct" for an epoch. The DS can enable
The DS can enable clients to choose between Commits, for example by clients to choose between Commits, for example by providing Commits
providing Commits in the order received and allow clients to reject in the order received and allowing clients to reject any Commits that
any Commits that violate their view of the group's policies. As violate their view of the group's policies. As such, all honest and
such, all honest and correctly implemented clients will arrive at the correctly implemented clients will arrive at the same "first valid
same "first valid Commit" and choose to process it. Malicious or Commit" and choose to process it. Malicious or buggy clients that
buggy clients that process a different Commit will end up in a forked process a different Commit will end up in a forked view of the group.
view of the group.
When these desynchronizations happen, the application may choose to When these desynchronizations happen, the application may choose to
take action to restore the functionality of the group. These actions take action to restore the functionality of the group. These actions
themselves can have security implications. For example, a client themselves can have security implications. For example, a client
developer might have a client automatically rejoin a group, using an developer might have a client automatically rejoin a group, using an
external join, when it processes an invalid Commit. In this external join, when it processes an invalid Commit. In this
operation, however, the client trusts that the GroupInfo provided by operation, however, the client trusts that the GroupInfo provided by
the DS faithfully represents the state of the group, and not, say, an the DS faithfully represents the state of the group, and not, say, an
earlier state containing a compromised leaf node. In addition, the earlier state containing a compromised leaf node. In addition, the
DS may be able to trigger this condition by deliberately sending the DS may be able to trigger this condition by deliberately sending the
skipping to change at line 807 skipping to change at line 805
prevent victims from rejoining the group. Thus, careful analysis of prevent victims from rejoining the group. Thus, careful analysis of
security implications should be made for any system for recovering security implications should be made for any system for recovering
from desynchronization. from desynchronization.
6. Functional Requirements 6. Functional Requirements
MLS is designed as a large-scale group messaging protocol and hence MLS is designed as a large-scale group messaging protocol and hence
aims to provide both performance and security (e.g., integrity and aims to provide both performance and security (e.g., integrity and
confidentiality) to its users. Messaging systems that implement MLS confidentiality) to its users. Messaging systems that implement MLS
provide support for conversations involving two or more members, and provide support for conversations involving two or more members, and
they aim to scale to groups with tens of thousands of members, aim to scale to groups with tens of thousands of members, typically
typically including many users using multiple devices. including many users using multiple devices.
6.1. Membership Changes 6.1. Membership Changes
MLS aims to provide agreement on group membership, meaning that all MLS aims to provide agreement on group membership, meaning that all
group members have agreed on the list of current group members. group members have agreed on the list of current group members.
Some applications may wish to enforce Access Control Lists (ACLs) to Some applications may wish to enforce Access Control Lists (ACLs) to
limit addition or removal of group members, to privileged clients or limit addition or removal of group members to privileged clients or
users. Others may wish to require authorization from the current users. Others may wish to require authorization from the current
group members or a subset thereof. Such policies can be implemented group members or a subset thereof. Such policies can be implemented
at the application layer, on top of MLS. Regardless, MLS does not at the application layer, on top of MLS. Regardless, MLS does not
allow for or support addition or removal of group members without allow for or support addition or removal of group members without
informing all other members. informing all other members.
Membership of an MLS group is managed at the level of individual Membership of an MLS group is managed at the level of individual
clients. In most cases, a client corresponds to a specific device clients. In most cases, a client corresponds to a specific device
used by a user. If a user has multiple devices, the user will used by a user. If a user has multiple devices, the user will
generally be represented in a group by multiple clients (although generally be represented in a group by multiple clients (although
applications could choose to have devices share keying material). If applications could choose to have devices share keying material). If
an application wishes to implement operations at the level of users, an application wishes to implement operations at the level of users,
it is up to the application to track which clients belong to a given it is up to the application to track which clients belong to a given
user and ensure that they are added/removed consistently. user and ensure that they are added/removed consistently.
MLS provides two mechanisms for changing the membership of a group. MLS provides two mechanisms for changing the membership of a group.
The primary mechanism is for an authorized member of the group to The primary mechanism is for an authorized member of the group to
send a Commit that adds or removes other members. The second send a Commit that adds or removes other members. A secondary
mechanism is an "external join": A member of the group publishes mechanism is an "external join": A member of the group publishes
certain information about the group, which a new member can use to certain information about the group, which a new member can use to
construct an "external" Commit message that adds the new member to construct an "external" Commit message that adds the new member to
the group. (There is no similarly unilateral way for a member to the group. (There is no similarly unilateral way for a member to
leave the group; they must be removed by a remaining member.) leave the group; they must be removed by a remaining member.)
With both mechanisms, changes to the membership are initiated from With both mechanisms, changes to the membership are initiated from
inside the group. When members perform changes directly, this is inside the group. When members perform changes directly, this is
clearly the case. External joins are authorized indirectly, in the clearly the case. External joins are authorized indirectly, in the
sense that a member publishing a GroupInfo object authorizes anyone sense that a member publishing a GroupInfo object authorizes anyone
skipping to change at line 876 skipping to change at line 874
client. Compromise of a member removed from a group does not affect client. Compromise of a member removed from a group does not affect
the security of messages sent after their removal. Messages sent the security of messages sent after their removal. Messages sent
during the client's membership are also secure as long as the client during the client's membership are also secure as long as the client
has properly implemented the MLS deletion schedule, which calls for has properly implemented the MLS deletion schedule, which calls for
the secrets used to encrypt or decrypt a message to be deleted after 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. use, along with any secrets that could be used to derive them.
6.2. Parallel Groups 6.2. Parallel Groups
Any user or client may have membership in several groups Any user or client may have membership in several groups
simultaneously. The set of members of any group may or may not form simultaneously. The set of members of any group may or may not
a subset of the members of another group. MLS guarantees that the FS overlap with the members of another group. MLS guarantees that the
and PCS goals within a given group are maintained and not weakened by FS and PCS goals within a given group are maintained and not weakened
user membership in multiple groups. However, actions in other groups by user membership in multiple groups. However, actions in other
likewise do not strengthen the FS and PCS guarantees within a given groups likewise do not strengthen the FS and PCS guarantees within a
group, e.g., key updates within a given group following a device given group, e.g., key updates within a given group following a
compromise do not provide PCS healing in other groups; each group device compromise do not provide PCS healing in other groups; each
must be updated separately to achieve these security objectives. group must be updated separately to achieve these security
This also applies to future groups that a member has yet to join, objectives. This also applies to future groups that a member has yet
which are likewise unaffected by updates performed in current groups. to join, which are likewise unaffected by updates performed in
current groups.
Applications can strengthen connectivity among parallel groups by Applications can strengthen connectivity among parallel groups by
requiring periodic key updates from a user across all groups in which requiring periodic key updates from a user across all groups in which
they have membership. they have membership.
MLS provides a pre-shared key (PSK) that can be used to link healing MLS provides a pre-shared key (PSK) mechanism that can be used to
properties among parallel groups. For example, suppose a common link healing properties among parallel groups. For example, suppose
member M of two groups A and B has performed a key update in group A a common member M of two groups A and B has performed a key update in
but not in group B. The key update provides PCS with regard to M in group A but not in group B. The key update provides PCS with regard
group A. If a PSK is exported from group A and injected into group to M in group A. If a PSK is exported from group A and injected into
B, then some of these PCS properties carry over to group B, since the group B, then some of these PCS properties carry over to group B,
PSK and secrets derived from it are only known to the new, updated since the PSK and secrets derived from it are only known to the new,
version of M, not to the old, possibly compromised version of M. updated version of M, not to the old, possibly compromised version of
M.
6.3. Asynchronous Usage 6.3. Asynchronous Usage
No operation in MLS requires two distinct clients or members to be No operation in MLS requires two distinct clients or members to be
online simultaneously. In particular, members participating in online simultaneously. In particular, members participating in
conversations protected using MLS can update the group's keys, add or conversations protected using MLS can update the group's keys, add or
remove new members, and send messages without waiting for another remove new members, and send messages without waiting for another
user's reply. user's reply.
Messaging systems that implement MLS have to provide a transport Messaging systems that implement MLS have to provide a transport
skipping to change at line 920 skipping to change at line 920
6.4. Access Control 6.4. Access Control
Because all clients within a group (members) have access to the Because all clients within a group (members) have access to the
shared cryptographic material, the MLS protocol allows each member of shared cryptographic material, the MLS protocol allows each member of
the messaging group to perform operations. However, every service/ the messaging group to perform operations. However, every service/
infrastructure has control over policies applied to its own clients. infrastructure has control over policies applied to its own clients.
Applications managing MLS clients can be configured to allow for Applications managing MLS clients can be configured to allow for
specific group operations. On the one hand, an application could specific group operations. On the one hand, an application could
decide that a group administrator will be the only member to perform decide that a group administrator will be the only member to perform
add and remove operations. On the other hand, in many settings such Add and Remove operations. On the other hand, in many settings such
as open discussion forums, joining can be allowed for anyone. as open discussion forums, joining can be allowed for anyone.
While MLS Application messages are always encrypted, MLS handshake While MLS application messages are always encrypted, MLS handshake
messages can be sent either encrypted (in an MLS PrivateMessage) or messages can be sent either encrypted (in an MLS PrivateMessage) or
unencrypted (in an MLS PublicMessage). Applications may be designed unencrypted (in an MLS PublicMessage). Applications may be designed
such that intermediaries need to see handshake messages, for example such that intermediaries need to see handshake messages, for example
to enforce policy on which commits are allowed, or to provide MLS to enforce policy on which commits are allowed, or to provide MLS
ratchet tree data in a central location. If handshake messages are ratchet tree data in a central location. If handshake messages are
unencrypted, it is especially important that they be sent over a unencrypted, it is especially important that they be sent over a
channel with strong transport encryption (see Section 8) in order to channel with strong transport encryption (see Section 8) in order to
prevent external attackers from monitoring the status of the group. prevent external attackers from monitoring the status of the group.
Applications that use unencrypted handshake messages may take Applications that use unencrypted handshake messages may take
additional steps to reduce the amount of metadata that is exposed to additional steps to reduce the amount of metadata that is exposed to
skipping to change at line 947 skipping to change at line 947
learning about the structure of the group. learning about the structure of the group.
If handshake messages are encrypted, any access control policies must If handshake messages are encrypted, any access control policies must
be applied at the client, so the application must ensure that the be applied at the client, so the application must ensure that the
access control policies are consistent across all clients to make access control policies are consistent across all clients to make
sure that they remain in sync. If two different policies were sure that they remain in sync. If two different policies were
applied, the clients might not accept or reject a group operation and applied, the clients might not accept or reject a group operation and
end up in different cryptographic states, breaking their ability to end up in different cryptographic states, breaking their ability to
communicate. communicate.
*RECOMMENDATION:* Avoid using inconsistent access control policies *Recommendation:* Avoid using inconsistent access control
in the case of encrypted group operations. policies, especially when using encrypted group operations.
MLS allows actors outside the group to influence the group in two MLS allows actors outside the group to influence the group in two
ways: External signers can submit proposals for changes to the group, ways: External signers can submit proposals for changes to the group,
and new joiners can use an external join to add themselves to the and new joiners can use an external join to add themselves to the
group. The external_senders extension ensures that all members agree group. The external_senders extension ensures that all members agree
on which signers are allowed to send proposals, but any other on which signers are allowed to send proposals, but any other
policies must be assured to be consistent, as noted above. policies must be assured to be consistent, as noted above.
*RECOMMENDATION:* Have an explicit group policy setting the *Recommendation:* Have an explicit group policy setting the
conditions under which external joins are allowed. conditions under which external joins are allowed.
6.5. Handling Authentication Failures 6.5. Handling Authentication Failures
Within an MLS group, every member is authenticated to every other Within an MLS group, every member is authenticated to every other
member by means of credentials issued and verified by the member by means of credentials issued and verified by the AS. MLS
Authentication Service. MLS does not prescribe what actions, if any, does not prescribe what actions, if any, an application should take
an application should take in the event that a group member presents in the event that a group member presents an invalid credential. For
an invalid credential. For example, an application may require such example, an application may require such a member to be immediately
a member to be immediately evicted or may allow some grace period for evicted or may allow some grace period for the problem to be
the problem to be remediated. To avoid operational problems, it is remediated. To avoid operational problems, it is important for all
important for all clients in a group to have a consistent view of clients in a group to have a consistent view of which credentials in
which credentials in a group are valid, and how to respond to invalid a group are valid, and how to respond to invalid credentials.
credentials.
*RECOMMENDATION:* Have a uniform credential validation process to *Recommendation:* Have a uniform credential validation process to
ensure that all group members evaluate other members' credentials ensure that all group members evaluate other members' credentials
in the same way. in the same way.
*RECOMMENDATION:* Have a uniform policy for how invalid *Recommendation:* Have a uniform policy for how invalid
credentials are handled. credentials are handled.
In some authentication systems, it is possible for a previously valid In some authentication systems, it is possible for a previously valid
credential to become invalid over time. For example, in a system credential to become invalid over time. For example, in a system
based on X.509 certificates, credentials can expire or be revoked. based on X.509 certificates, credentials can expire or be revoked.
The MLS update mechanisms allow a client to replace an old credential The MLS update mechanisms allow a client to replace an old credential
with a new one. This is best done before the old credential becomes with a new one. This is best done before the old credential becomes
invalid. invalid.
*RECOMMENDATION:* Proactively rotate credentials, especially if a *Recommendation:* Proactively rotate credentials, especially if a
credential is about to become invalid. credential is about to become invalid.
6.6. Recovery After State Loss 6.6. Recovery After State Loss
Group members whose local MLS state is lost or corrupted can Group members whose local MLS state is lost or corrupted can
reinitialize their state by rejoining the group as a new member and reinitialize their state by rejoining the group as a new member and
removing the member representing their earlier state. An application removing the member representing their earlier state. An application
can require that a client performing such a reinitialization prove can require that a client performing such a reinitialization prove
its prior membership with a PSK that was exported from the previous its prior membership with a PSK that was exported from the previous
state. state.
There are a few practical challenges to this approach. For example, There are a few practical challenges to this approach. For example,
the application will need to ensure that all members have the the application will need to ensure that all members have the
required PSK, including any new members that have joined the group required PSK, including any new members that have joined the group
since the epoch in which the PSK was issued. And of course, if the 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, then it PSK is lost or corrupted along with the member's other state, then it
cannot be used to recover. cannot be used to recover.
Reinitializing in this way does not provide the member with access to Reinitializing in this way does not provide the member with access to
group messages exchanged during the state loss window, but it enables group messages exchanged during the state loss window, but enables
proof of prior membership in the group. Applications may choose proof of prior membership in the group. Applications may choose
various configurations for providing lost messages to valid group various configurations for providing lost messages to valid group
members that are able to prove prior membership. members that are able to prove prior membership.
6.7. Support for Multiple Devices 6.7. Support for Multiple Devices
It is typically expected that users within a group will own various It is common for users within a group to own multiple devices. A new
devices. A new device can be added to a group and be considered as a device can be added to a group and be considered as a new client by
new client by the protocol. This client will not gain access to the the protocol. This client will not gain access to the history even
history even if it is owned by someone who owns another member of the if it is owned by someone who owns another member of the group. MLS
group. MLS does not provide direct support for restoring history in does not provide direct support for restoring history in this case,
this case, but applications can elect to provide such a mechanism but applications can elect to provide such a mechanism outside of
outside of MLS. Such mechanisms, if used, may reduce the FS and PCS MLS. Such mechanisms, if used, may reduce the FS and PCS guarantees
guarantees provided by MLS. provided by MLS.
6.8. Extensibility 6.8. Extensibility
The MLS protocol provides several extension points where additional The MLS protocol provides several extension points where additional
information can be provided. Extensions to KeyPackages allow clients information can be provided. Extensions to KeyPackages allow clients
to disclose additional information about their capabilities. Groups to disclose additional information about their capabilities. Groups
can also have extension data associated with them, and the group can also have extension data associated with them, and the group
agreement properties of MLS will confirm that all members of the agreement properties of MLS will confirm that all members of the
group agree on the content of these extensions. group agree on the content of these extensions.
6.9. Application Data Framing and Type Advertisements 6.9. Application Data Framing and Type Advertisements
Application messages carried by MLS are opaque to the protocol; they Application messages carried by MLS are opaque to the protocol and
can contain arbitrary data. Each application that uses MLS needs to can contain arbitrary data. Each application that uses MLS needs to
define the format of its application_data and any mechanism necessary define the format of its application_data and any mechanism necessary
to determine the format of that content over the lifetime of an MLS to determine the format of that content over the lifetime of an MLS
group. In many applications, this means managing format migrations group. In many applications, this means managing format migrations
for groups with multiple members who may each be offline at for groups with multiple members who may each be offline at
unpredictable times. unpredictable times.
*RECOMMENDATION:* Use the default content mechanism defined in *Recommendation:* Use the content mechanism defined in
Section 3.3 of [EXTENSIONS], unless the specific application [EXTENSIONS], unless the specific application defines another
defines another mechanism that more appropriately addresses the mechanism that more appropriately addresses the same requirements
same requirements for that application of MLS. for that application of MLS.
The MLS framing for application messages also provides a field where The MLS framing for application messages also provides a field where
clients can send information that is authenticated but not encrypted. clients can send information that is authenticated but not encrypted.
Such information can be used by servers that handle the message, but Such information can be used by servers that handle the message, but
group members are assured that it has not been tampered with. group members are assured that it has not been tampered with.
6.10. Federation 6.10. Federation
The protocol aims to be compatible with federated environments. The protocol aims to be compatible with federated environments.
While this document does not specify all necessary mechanisms While this document does not specify all necessary mechanisms
skipping to change at line 1070 skipping to change at line 1069
detail in [FEDERATION]. detail in [FEDERATION].
6.11. Compatibility with Future Versions of MLS 6.11. Compatibility with Future Versions of MLS
It is important that multiple versions of MLS be able to coexist in It is important that multiple versions of MLS be able to coexist in
the future. Thus, MLS offers a version negotiation mechanism; this the future. Thus, MLS offers a version negotiation mechanism; this
mechanism prevents version downgrade attacks where an attacker would mechanism prevents version downgrade attacks where an attacker would
actively rewrite messages with a lower protocol version than the actively rewrite messages with a lower protocol version than the
messages originally offered by the endpoints. When multiple versions messages originally offered by the endpoints. When multiple versions
of MLS are available, the negotiation protocol guarantees that the of MLS are available, the negotiation protocol guarantees that the
version agreed upon will be the highest version supported in common creator is able to select the best version out of those suported in
by the group. common by the group.
In MLS 1.0, the creator of the group is responsible for selecting the In MLS 1.0, the creator of the group is responsible for selecting the
best ciphersuite supported across clients. Each client is able to best ciphersuite supported across clients. Each client is able to
verify availability of protocol version, ciphersuites, and extensions verify availability of protocol version, ciphersuites, and extensions
at all times once it has at least received the first group operation at all times once it has at least received the first group operation
message. message.
Each member of an MLS group advertises the protocol functionality Each member of an MLS group advertises the protocol functionality
they support. These capability advertisements can be updated over they support. These capability advertisements can be updated over
time, e.g., if client software is updated while the client is a time, e.g., if client software is updated while the client is a
skipping to change at line 1111 skipping to change at line 1110
required_capabilities extension (Section 7.2 of [RFC9420]) can required_capabilities extension (Section 7.2 of [RFC9420]) can
promote interoperability with a wider set of clients by ensuring that promote interoperability with a wider set of clients by ensuring that
certain functionality continues to be supported by a group, even if certain functionality continues to be supported by a group, even if
the clients in the group aren't currently relying on it. the clients in the group aren't currently relying on it.
MLS relies on the following network services, which need to be MLS relies on the following network services, which need to be
compatible in order for two different deployments based on them to compatible in order for two different deployments based on them to
interoperate. interoperate.
* An *Authentication Service*, described fully in Section 4, defines * An *Authentication Service*, described fully in Section 4, defines
the types of credentials that may be used in a deployment and the types of credentials which may be used in a deployment and
provides methods for: provides methods for:
1. Issuing new credentials with a relevant credential lifetime, 1. Issuing new credentials with a relevant credential lifetime,
2. Validating a credential against a reference identifier, 2. Validating a credential against a reference identifier,
3. Validating whether or not two credentials represent the same 3. Validating whether or not two credentials represent the same
client, and client, and
4. Optionally revoking credentials that are no longer authorized. 4. Optionally revoking credentials which are no longer
authorized.
* A *Delivery Service*, described fully in Section 5, provides * A *Delivery Service*, described fully in Section 5, provides
methods for: methods for:
1. Delivering messages for a group to all members in the group. 1. Delivering messages for a group to all members in the group.
2. Delivering Welcome messages to new members of a group. 2. Delivering Welcome messages to new members of a group.
3. Uploading new KeyPackages for a user's own clients. 3. Uploading new KeyPackages for a user's own clients.
4. Downloading KeyPackages for specific clients. Typically, 4. Downloading KeyPackages for specific clients. Typically,
KeyPackages are used once and consumed. KeyPackages are used once and consumed.
* Additional services may or may not be required, depending on the * Additional services may or may not be required, depending on the
application design: application design:
- In cases where group operations are not encrypted, the DS has - In cases where group operations are not encrypted, the DS has
the ability to observe and maintain a copy of the public group the ability to observe and maintain a copy of the public group
state. In particular, this is useful for (1) clients that do state. In particular, this is useful for either (1) clients
not have the ability to send the full public state in a Welcome that do not have the ability to send the full public state in a
message when inviting a user or (2) a client that needs to Welcome message when inviting a user or (2) clients that need
recover from losing their state. Such public state can contain to recover from losing their state. Such public state can
privacy-sensitive information such as group members' contain privacy-sensitive information such as group members'
credentials and related public keys; hence, services need to credentials and related public keys; hence, services need to
carefully evaluate the privacy impact of storing this data on carefully evaluate the privacy impact of storing this data on
the DS. the DS.
- If external joiners are allowed, there must be a method for - If external joiners are allowed, there must be a method for
publishing a serialized GroupInfo object (with an external_pub publishing a serialized GroupInfo object (with an external_pub
extension) that corresponds to a specific group and epoch, and extension) that corresponds to a specific group and epoch, and
for keeping that object in sync with the state of the group. for keeping that object in sync with the state of the group.
- If an application chooses not to allow external joining, it may - If an application chooses not to allow external joining, it may
skipping to change at line 1189 skipping to change at line 1189
- How long to keep unused nonce and key pairs for a sender. - 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 unused key pairs to keep.
- A maximum number of steps that clients will move a secret tree - A maximum number of steps that clients will move a secret tree
ratchet forward in response to a single message before ratchet forward in response to a single message before
rejecting it. rejecting it.
- Whether to buffer messages that aren't yet able to be - Whether to buffer messages that aren't yet able to be
understood due to other messages not arriving first and, if so, understood due to other messages not arriving first, and, if
how many and for how long -- for example, Commit messages that so, how many and for how long -- for example, Commit messages
arrive before a proposal they reference or application messages that arrive before a proposal they reference or application
that arrive before the Commit starting an epoch. messages that arrive before the Commit starting an epoch.
If implementations differ in these parameters, they will interoperate If implementations differ in these parameters, they will interoperate
to some extent but may experience unexpected failures in certain to some extent but may experience unexpected failures in certain
situations, such as extensive message reordering. situations, such as extensive message reordering.
MLS provides the following locations where an application may store MLS provides the following locations where an application may store
arbitrary data. The format and intention of any data in these arbitrary data. The format and intention of any data in these
locations must align for two deployments to interoperate: locations must align for two deployments to interoperate:
* Application data, sent as the payload of an encrypted message. * Application data, sent as the payload of an encrypted message.
skipping to change at line 1248 skipping to change at line 1248
external commits. external commits.
- Which other proposal types are allowed. - Which other proposal types are allowed.
* A policy of when members should commit pending proposals in a * A policy of when members should commit pending proposals in a
group. group.
* A policy of how to protect and share the GroupInfo objects needed * A policy of how to protect and share the GroupInfo objects needed
for external joins. for external joins.
* A policy for when two credentials represent the same client. Note * A policy for when two credentials represent the same client,
that many credentials may be issued attesting the same identity distinguishing the following two cases:
but for different signature keys, because each credential
corresponds to a different client owned by the same application - When there are multiple devices for a given user.
user. However, one device may control multiple signature keys --
for instance, if the device has keys corresponding to multiple - When a single device has multiple signature keys -- for
overlapping time periods -- but should still only be considered a instance, if the device has keys corresponding to multiple
single client. overlapping time periods.
* A policy on how long to allow a member to stay in a group without * A policy on how long to allow a member to stay in a group without
updating its leaf keys before removing them. updating its leaf keys before removing them.
Finally, there are some additional application-defined behaviors that Finally, there are some additional application-defined behaviors that
are partially an individual application's decision but may overlap are partially an individual application's decision but may overlap
with interoperability: with interoperability:
* When and how to pad messages. * When and how to pad messages.
skipping to change at line 1311 skipping to change at line 1311
architecture designs. architecture designs.
In addition, these guarantees are intended to degrade gracefully in In addition, these guarantees are intended to degrade gracefully in
the presence of compromise of the transport security links as well as the presence of compromise of the transport security links as well as
of both clients and elements of the messaging system, as described in of both clients and elements of the messaging system, as described in
the remainder of this section. the remainder of this section.
8.1. Assumptions on Transport Security Links 8.1. Assumptions on Transport Security Links
As discussed above, MLS provides the highest level of security when As discussed above, MLS provides the highest level of security when
its messages are delivered over an encrypted transport. The main use its messages are delivered over an encrypted transport, thus
of the secure transport layer for MLS is to protect the already- preventing attackers from selectively interfering with MLS
limited amount of metadata. Very little information is contained in communications as well as protecting the already limited amount of
the unencrypted header of the MLS protocol message format for group metadata. Very little information is contained in the unencrypted
operation messages, and application messages are always encrypted in header of the MLS protocol message format for group operation
MLS. messages, and application messages are always encrypted in MLS.
*RECOMMENDATION:* Use transports that provide reliability and *Recommendation:* Use transports that provide reliability and
metadata confidentiality whenever possible, e.g., by transmitting metadata confidentiality whenever possible, e.g., by transmitting
MLS messages over a protocol such as TLS [RFC8446] or QUIC MLS messages over a protocol such as TLS [RFC8446] or QUIC
[RFC9000]. [RFC9000].
MLS avoids needing to send the full list of recipients to the server MLS avoids the need to send the full list of recipients to the server
for dispatching messages because that list could potentially contain for dispatching messages because that list could potentially contain
tens of thousands of recipients. Header metadata in MLS messages tens of thousands of recipients. Header metadata in MLS messages
typically consists of an opaque group_id, a numerical value to typically consists of an opaque group_id, a numerical value to
determine the epoch of the group (the number of changes that have determine the epoch of the group (the number of changes that have
been made to the group), and whether the message is an application been made to the group), and whether the message is an application
message, a proposal, or a commit. message, a proposal, or a commit.
Even though some of this metadata information does not consist of Even though some of this metadata information does not consist of
sensitive information, in correlation with other data a network sensitive information, when correlated with other data a network
observer might be able to reconstruct sensitive information. Using a observer might be able to reconstruct sensitive information. Using a
secure channel to transfer this information will prevent a network secure channel to transfer this information will prevent a network
attacker from accessing this MLS protocol metadata if it cannot attacker from accessing this MLS protocol metadata if it cannot
compromise the secure channel. compromise the secure channel.
8.1.1. Integrity and Authentication of Custom Metadata 8.1.1. Integrity and Authentication of Custom Metadata
MLS provides an authenticated "Additional Authenticated Data" (AAD) MLS provides an authenticated "Additional Authenticated Data" (AAD)
field for applications to make data available outside a field for applications to make data available outside a
PrivateMessage, while cryptographically binding it to the message. PrivateMessage, while cryptographically binding it to the message.
*RECOMMENDATION:* Use the "Additional Authenticated Data" field of *Recommendation:* Use the "Additional Authenticated Data" field of
the PrivateMessage instead of using other unauthenticated means of the PrivateMessage instead of using other unauthenticated means of
sending metadata throughout the infrastructure. If the data sending metadata throughout the infrastructure. If the data
should be kept private, the infrastructure should use encrypted should be kept private, the infrastructure should use encrypted
Application messages instead. application messages instead.
8.1.2. Metadata Protection for Unencrypted Group Operations 8.1.2. Metadata Protection for Unencrypted Group Operations
Having no secure channel to exchange MLS messages can have a serious Having no secure channel to exchange MLS messages can have a serious
impact on privacy when transmitting unencrypted group operation impact on privacy when transmitting unencrypted group operation
messages. Observing the contents and signatures of the group messages. Observing the contents and signatures of the group
operation messages may lead an adversary to extract information about operation messages may lead an adversary to extract information about
the group membership. the group membership.
*RECOMMENDATION:* Never use the unencrypted mode for group *Recommendation:* Never use the unencrypted mode for group
operations without using a secure channel for the transport layer. operations without using a secure channel for the transport layer.
8.1.3. DoS Protection 8.1.3. DoS Protection
In general, we do not consider DoS resistance to be the In general, we do not consider DoS resistance to be the
responsibility of the protocol. However, it should not be possible responsibility of the protocol. However, it should not be possible
for anyone aside from the Delivery Service to perform a trivial DoS for anyone aside from the DS to perform a trivial DoS attack from
attack from which it is hard to recover. This can be achieved which it is hard to recover. This can be achieved through the secure
through the secure transport layer. transport layer, which prevents selective attack on MLS
communications by network attackers.
In the centralized setting, DoS protection can typically be performed In the centralized setting, DoS protection can typically be performed
by using tickets or cookies which identify users to a service for a by using tickets or cookies which identify users to a service for a
certain number of connections. Such a system helps in preventing certain number of connections. Such a system helps in preventing
anonymous clients from sending arbitrary numbers of group operation anonymous clients from sending arbitrary numbers of group operation
messages to the Delivery Service or the MLS clients. messages to the DS or the MLS clients.
*RECOMMENDATION:* Use credentials uncorrelated with specific users *Recommendation:* Use credentials uncorrelated with specific users
to help prevent DoS attacks, in a manner that preserves privacy. to help prevent DoS attacks, in a privacy-preserving manner. Note
Note that the privacy of these mechanisms has to be adjusted in that the privacy of these mechanisms has to be adjusted in
accordance with the privacy expected from secure transport links. accordance with the privacy expected from secure transport links.
(See more discussion in the next section.) (See more discussion in the next section.)
8.1.4. Message Suppression and Error Correction 8.1.4. Message Suppression and Error Correction
As noted above, MLS is designed to provide some robustness in the As noted above, MLS is designed to provide some robustness in the
face of tampering within the secure transport, i.e., tampering by the face of tampering within the secure transport, e.g., tampering by the
Delivery Service. The confidentiality and authenticity properties of DS. The confidentiality and authenticity properties of MLS prevent
MLS prevent the DS from reading or writing messages. MLS also the DS from reading or writing messages. MLS also provides a few
provides a few tools for detecting message suppression, with the tools for detecting message suppression, with the caveat that message
caveat that message suppression cannot always be distinguished from suppression cannot always be distinguished from transport failure.
transport failure.
Each encrypted MLS message carries a "generation" number which is a Each encrypted MLS message carries a per-sender incrementing
per-sender incrementing counter. If a group member observes a gap in "generation" number. If a group member observes a gap in the
the generation sequence for a sender, then they know that they have generation sequence for a sender, then they know that they have
missed a message from that sender. MLS also provides a facility for missed a message from that sender. MLS also provides a facility for
group members to send authenticated acknowledgments of application group members to send authenticated acknowledgments of application
messages received within a group. messages received within a group.
As discussed in Section 5, the Delivery Service is trusted to select As discussed in Section 5, the DS is trusted to select the single
the single Commit message that is applied in each epoch from among Commit message that is applied in each epoch from among the Commits
the Commits sent by group members. Since only one Commit per epoch sent by group members. Since only one Commit per epoch is
is meaningful, it's not useful for the DS to transmit multiple meaningful, it's not useful for the DS to transmit multiple Commits
Commits to clients. The risk remains that the DS will use the to clients. The risk remains that the DS will use the ability
ability maliciously. maliciously.
While it is difficult or impossible to prevent a network adversary
from suppressing payloads in transit, in certain infrastructures such
as banks or government settings, unidirectional transports can be
used and be enforced via electronic or physical devices such as
diodes. This can lead to payload corruption, which does not affect
the security or privacy properties of the MLS protocol but does
affect the reliability of the service. In that case, specific
measures can be taken to ensure the appropriate level of redundancy
and quality of service for MLS.
8.2. Intended Security Guarantees 8.2. Intended Security Guarantees
MLS aims to provide a number of security guarantees, covering MLS aims to provide a number of security guarantees, covering
authentication, as well as confidentiality guarantees to different authentication, as well as confidentiality guarantees to different
degrees in different scenarios. degrees in different scenarios.
8.2.1. Message Secrecy and Authentication 8.2.1. Message Secrecy and Authentication
MLS enforces the encryption of application messages and thus MLS enforces the encryption of application messages and thus
skipping to change at line 1445 skipping to change at line 1435
Message content can be deniable if the signature keys are exchanged Message content can be deniable if the signature keys are exchanged
over a deniable channel prior to signing messages. over a deniable channel prior to signing messages.
Depending on the group settings, handshake messages can be encrypted Depending on the group settings, handshake messages can be encrypted
as well. If that is the case, the same security guarantees apply. as well. If that is the case, the same security guarantees apply.
MLS optionally allows the addition of padding to messages, mitigating MLS optionally allows the addition of padding to messages, mitigating
the amount of information leaked about the length of the plaintext to the amount of information leaked about the length of the plaintext to
an observer on the network. an observer on the network.
8.2.2. Forward and Post-Compromise Security 8.2.2. Forward Secrecy and Post-Compromise Security
MLS provides additional protection regarding secrecy of past messages MLS provides additional protection regarding secrecy of past messages
and future messages. These cryptographic security properties are and future messages. These cryptographic security properties are
Forward Secrecy (FS) and Post-Compromise Security (PCS). forward secrecy (FS) and post-compromise security (PCS).
FS means that access to all encrypted traffic history combined with FS means that access to all encrypted traffic history combined with
access to all current keying material on clients will not defeat the access to all current keying material on clients will not defeat the
secrecy properties of messages older than the oldest key of the secrecy properties of messages older than the oldest key of the
compromised client. Note that this means that clients have to delete compromised client. Note that this means that clients have to delete
the appropriate keys as soon as they have been used with the expected the appropriate keys as soon as they have been used with the expected
message; otherwise, the secrecy of the messages and the security of message; otherwise, the secrecy of the messages and the security of
MLS are considerably weakened. MLS are considerably weakened.
PCS means that if a group member's state is compromised at some time PCS means that if a group member's state is compromised at some time
t1 but the group member subsequently performs an update at some time t1 but the group member subsequently performs an update at some time
t2, then all MLS guarantees apply to messages sent by the member t2, then all MLS guarantees apply to messages sent by the member
after time t2 and sent by other members after they have processed the after time t2 and to messages sent by other members after they have
update. For example, if an attacker learns all secrets known to processed the update. For example, if an attacker learns all secrets
Alice at time t1, including both Alice's long-term secret keys and known to Alice at time t1, including both Alice's long-term secret
all shared group keys, but Alice performs a key update at time t2, keys and all shared group keys, but Alice performs a key update at
then the attacker is unable to violate any of the MLS security time t2, then the attacker is unable to violate any of the MLS
properties after the updates have been processed. security properties after the updates have been processed.
Both of these properties are satisfied even against compromised DSs Both of these properties are satisfied even against compromised DSs
and ASes in the case where some other mechanism for verifying keys is and ASes in the case where some other mechanism for verifying keys is
in use, such as Key Transparency [KT]. in use, such as Key Transparency [KT].
Confidentiality is mainly ensured on the client side. Because FS and Confidentiality is mainly ensured on the client side. Because FS and
PCS rely on the active deletion and replacement of keying material, PCS rely on the active deletion and replacement of keying material,
any client that is persistently offline may still be holding old any client which is persistently offline may still be holding old
keying material and thus be a threat to both FS and PCS if it is keying material and thus be a threat to both FS and PCS if it is
later compromised. later compromised.
MLS partially defends against this problem by active members MLS partially defends against this problem by active members
including freshness. However, not much can be done on the inactive including new keying material. However, not much can be done on the
side especially in the case where the client has not processed inactive side especially in the case where the client has not
messages. processed messages.
*RECOMMENDATION:* Mandate key updates from clients that are not *Recommendation:* Mandate key updates from clients that are not
otherwise sending messages and evict clients that are idle for too otherwise sending messages and evict clients that are idle for too
long. long.
These recommendations will reduce the ability of idle compromised These recommendations will reduce the ability of idle compromised
clients to decrypt a potentially long set of messages that might have clients to decrypt a potentially long set of messages that might have
been sent after the point of compromise. been sent after the point of compromise.
The precise details of such mechanisms are a matter of local policy The precise details of such mechanisms are a matter of local policy
and beyond the scope of this document. and beyond the scope of this document.
8.2.3. Non-Repudiation vs. Deniability 8.2.3. Non-Repudiation vs. Deniability
MLS provides strong authentication within a group, such that a group MLS provides strong authentication within a group, such that a group
member cannot send a message that appears to be from another group member cannot send a message that appears to be from another group
member. Additionally, some services require that a recipient be able member. Additionally, some services require that a recipient be able
to prove to the service provider that a message was sent by a given to prove to the service provider that a message was sent by a given
client, in order to report abuse. MLS supports both of these use client, in order to report abuse. MLS supports both of these use
cases. In some deployments, these services are provided by cases. In some deployments, these services are provided by
mechanisms that allow the receiver to prove a message's origin to a mechanisms which allow the receiver to prove a message's origin to a
third party. This is often called "non-repudiation". third party. This is often called "non-repudiation".
Roughly speaking, "deniability" is the opposite of "non-repudiation", Roughly speaking, "deniability" is the opposite of "non-repudiation",
i.e., the property that it is impossible to prove to a third party i.e., the property that it is impossible to prove to a third party
that a message was sent by a given sender. MLS does not make any that a message was sent by a given sender. MLS does not make any
claims with regard to deniability. It may be possible to operate MLS claims with regard to deniability. It may be possible to operate MLS
in ways that provide certain deniability properties, but defining the in ways that provide certain deniability properties, but defining the
specific requirements and resulting notions of deniability requires specific requirements and resulting notions of deniability requires
further analysis. further analysis.
skipping to change at line 1527 skipping to change at line 1517
describes how to operate each device as a distinct client in the MLS describes how to operate each device as a distinct client in the MLS
groups that the user is a member of. As a result, the other members groups that the user is a member of. As a result, the other members
of the group will be able to identify which of a user's devices sent of the group will be able to identify which of a user's devices sent
each message and, therefore, which device the user was using at the each message and, therefore, which device the user was using at the
time. Group members would also be able to detect when the user adds time. Group members would also be able to detect when the user adds
or removes authorized devices from their account. For some or removes authorized devices from their account. For some
applications, this may be an unacceptable breach of the user's applications, this may be an unacceptable breach of the user's
privacy. privacy.
This risk only arises when the leaf nodes for the clients in question This risk only arises when the leaf nodes for the clients in question
provide data that can be used to correlate the clients. So, one way provide data that can be used to correlate the clients. One way to
to mitigate this risk is by only doing client-level authentication mitigate this risk is by only doing client-level authentication
within MLS. If user-level authentication is still desirable, the within MLS. If user-level authentication is still desirable, the
application would have to provide it through some other mechanism. application would have to provide it through some other mechanism.
It is also possible to maintain user-level authentication while It is also possible to maintain user-level authentication while
hiding information about the clients that a user owns. This can be hiding information about the clients that a user owns. This can be
done by having the clients share cryptographic state, so that they done by having the clients share cryptographic state, so that they
appear as a single client within the MLS group. Appearing as a appear as a single client within the MLS group. Appearing as a
single client has the privacy benefits of no longer leaking which single client has the privacy benefits of no longer leaking which
device was used to send a particular message and no longer leaking device was used to send a particular message and no longer leaking
the user's authorized devices. However, the application would need the user's authorized devices. However, the application would need
to provide a synchronization mechanism so that the clients' state to provide a synchronization mechanism so that the state of each
remain consistent across changes to the MLS group. Flaws in this client remains consistent across changes to the MLS group. Flaws in
synchronization mechanism may impair the ability of the user to this synchronization mechanism may impair the ability of the user to
recover from a compromise of one of their devices. In particular, recover from a compromise of one of their devices. In particular,
state synchronization may make it easier for an attacker to use one state synchronization may make it easier for an attacker to use one
compromised device to establish exclusive control of a user's compromised device to establish exclusive control of a user's
account, locking them out entirely and preventing them from account, locking them out entirely and preventing them from
recovering. recovering.
8.3. Endpoint Compromise 8.3. Endpoint Compromise
The MLS protocol adopts a threat model that includes multiple forms The MLS protocol adopts a threat model which includes multiple forms
of endpoint/client compromise. While adversaries are in a strong of endpoint/client compromise. While adversaries are in a strong
position if they have compromised an MLS client, there are still position if they have compromised an MLS client, there are still
situations where security guarantees can be recovered thanks to the situations where security guarantees can be recovered thanks to the
PCS properties achieved by the MLS protocol. PCS properties achieved by the MLS protocol.
In this section, we will explore the consequences and recommendations In this section we will explore the consequences and recommendations
regarding the following compromise scenarios: regarding the following compromise scenarios:
* The attacker has access to a symmetric encryption key. * The attacker has access to a symmetric encryption key.
* The attacker has access to an application ratchet secret. * 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 the group secrets for one group.
* The attacker has access to a signature oracle for any 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 the signature key for one group.
* The attacker has access to all secrets of a user for all groups * The attacker has access to all secrets of a user for all groups
(full state compromise). (full state compromise).
8.3.1. Compromise of Symmetric Keying Material 8.3.1. Compromise of Symmetric Keying Material
As described above, each MLS epoch creates a new Group Secret. As described above, each MLS epoch creates a new group secret.
These group secrets are then used to create a per-sender Ratchet These group secrets are then used to create a per-sender ratchet
Secret, which in turn is used to create a per-sender with an secret, which in turn is used to create a per-sender Authenticated
additional data (Authenticated Encryption with Associated Data Encryption with Associated Data (AEAD) [RFC5116] key that is then
(AEAD)) key [RFC5116] that is then used to encrypt MLS Plaintext used to encrypt MLS plaintext messages. Each time a message is sent,
messages. Each time a message is sent, the Ratchet Secret is used to the ratchet secret is used to create a new ratchet secret and a new
create a new Ratchet Secret and a new corresponding AEAD key. corresponding AEAD key. Because of the properties of the key
Because of the properties of the key derivation function, it is not derivation function, it is not possible to compute a ratchet secret
possible to compute a Ratchet Secret from its corresponding AEAD key from its corresponding AEAD key or compute ratchet secret n-1 from
or compute Ratchet Secret n-1 from Ratchet Secret n. ratchet secret n.
Below, we consider the compromise of each of these pieces of keying Below, we consider the compromise of each of these pieces of keying
material in turn, in ascending order of severity. While this is a material in turn, in ascending order of severity. While this is a
limited kind of compromise, it can be realistic in cases of limited kind of compromise, it can be realistic in cases of
implementation vulnerabilities where only part of the memory leaks to implementation vulnerabilities where only part of the memory leaks to
the adversary. the adversary.
8.3.1.1. Compromise of AEAD Keys 8.3.1.1. Compromise of AEAD Keys
In some circumstances, adversaries may have access to specific AEAD In some circumstances, adversaries may have access to specific AEAD
keys and nonces that protect an Application message or a Group keys and nonces which protect an application message or a group
Operation message. Compromise of these keys allows the attacker to operation message. Compromise of these keys allows the attacker to
decrypt the specific message encrypted with that key but no other; decrypt the specific message encrypted with that key but no other;
because the AEAD keys are derived from the Ratchet Secret, it cannot because the AEAD keys are derived from the ratchet secret, it cannot
generate the next Ratchet Secret and hence not the next AEAD key. generate the next ratchet secret and hence not the next AEAD key.
In the case of an Application message, an AEAD key compromise means In the case of an application message, an AEAD key compromise means
that the encrypted application message will be leaked as well as the that the encrypted application message will be leaked as well as the
signature over that message. This means that the compromise has both signature over that message. This means that the compromise has both
confidentiality and privacy implications on the future AEAD confidentiality and privacy implications on the future AEAD
encryptions of that chain. In the case of a Group Operation message, encryptions of that chain. In the case of a group operation message,
only the privacy is affected, as the signature is revealed, because only the privacy is affected, as the signature is revealed, because
the secrets themselves are protected by Hybrid Public Key Encryption the secrets themselves are protected by Hybrid Public Key Encryption
(HPKE). Note that under that compromise scenario, authentication is (HPKE). Note that under that compromise scenario, authentication is
not affected in either of these cases. As every member of the group not affected in either of these cases. As every member of the group
can compute the AEAD keys for all the chains (they have access to the can compute the AEAD keys for all the chains (they have access to the
Group Secrets) in order to send and receive messages, the group secrets) in order to send and receive messages, the
authentication provided by the AEAD encryption layer of the common authentication provided by the AEAD encryption layer of the common
framing mechanism is weak. Successful decryption of an AEAD framing mechanism is weak. Successful decryption of an AEAD
encrypted message only guarantees that some member of the group sent encrypted message only guarantees that some member of the group -- or
in this case an attacker who has compromised the AEAD keys -- sent
the message. the message.
Compromise of the AEAD keys allows the attacker to send an encrypted Compromise of the AEAD keys allows the attacker to send an encrypted
message using that key, but the attacker cannot send a message to a message using that key, but the attacker cannot send a message to a
group that appears to be from any valid client because the attacker group that appears to be from any valid client because the attacker
cannot forge the signature. This applies to all the forms of cannot forge the signature. This applies to all the forms of
symmetric key compromise described in Section 8.3.1. symmetric key compromise described in Section 8.3.1.
8.3.1.2. Compromise of Ratchet Secret Material 8.3.1.2. Compromise of Ratchet Secret Material
When a Ratchet Secret is compromised, the adversary can compute both When a ratchet secret is compromised, the adversary can compute both
the current AEAD keys for a given sender as well as any future keys the current AEAD keys for a given sender and any future keys for that
for that sender in this epoch. Thus, it can decrypt current and sender in this epoch. Thus, it can decrypt current and future
future messages by the corresponding sender. However, because it messages by the corresponding sender. However, because it does not
does not have previous Ratchet Secrets, it cannot decrypt past have previous ratchet secrets, it cannot decrypt past messages as
messages as long as those secrets and keys have been deleted. long as those secrets and keys have been deleted.
Because of its Forward Secrecy guarantees, MLS will also retain Because of its forward secrecy guarantees, MLS will also retain
secrecy of all other AEAD keys generated for _other_ MLS clients, secrecy of all other AEAD keys generated for _other_ MLS clients,
outside this dedicated chain of AEAD keys and nonces, even within the outside this dedicated chain of AEAD keys and nonces, even within the
epoch of the compromise. MLS provides Post-Compromise Security epoch of the compromise. MLS provides post-compromise security
against an active adaptive attacker across epochs for AEAD against an active adaptive attacker across epochs for AEAD
encryption, which means that as soon as the epoch is changed, if the encryption, which means that as soon as the epoch is changed, if the
attacker does not have access to more secret material they won't be attacker does not have access to more secret material they won't be
able to access any protected messages from future epochs. able to access any protected messages from future epochs.
8.3.1.3. Compromise of the Group Secrets of a Single Group for One or 8.3.1.3. Compromise of the Group Secrets of a Single Group for One or
More Group Epochs More Group Epochs
An adversary who gains access to a set of Group secrets -- for An adversary who gains access to a set of group secrets -- as when a
example, when a member of the group is compromised -- is member of the group is compromised -- is significantly more powerful.
significantly more powerful. In this section, we consider the case In this section, we consider the case where the signature keys are
where the signature keys are not compromised, which can occur if the not compromised. This can occur if the attacker has access to part
attacker has access to part of the memory containing the group of the memory containing the group secrets but not to the signature
secrets but not to the signature keys which might be stored in a keys which might be stored in a secure enclave.
secure enclave.
In this scenario, the adversary gains the ability to compute any In this scenario, the adversary gains the ability to compute any
number of Ratchet Secrets for the epoch and their corresponding AEAD number of ratchet secrets for the epoch and their corresponding AEAD
encryption keys and thus can encrypt and decrypt all messages for the encryption keys and thus can encrypt and decrypt all messages for the
compromised epochs. compromised epochs.
If the adversary is passive, it is expected from the PCS properties If the adversary is passive, it is expected from the PCS properties
of the MLS protocol that as soon as the compromised party remediates of the MLS protocol that as soon as the compromised party remediates
the compromise and sends an honest Commit message, the next epochs the compromise and sends an honest Commit message, the next epochs
will provide message secrecy. will provide message secrecy.
If the adversary is active, the adversary can engage in the protocol If the adversary is active, the adversary can engage in the protocol
itself and perform updates on behalf of the compromised party with no itself and perform updates on behalf of the compromised party with no
skipping to change at line 1677 skipping to change at line 1667
group are honest, the protocol will guarantee message secrecy for all group are honest, the protocol will guarantee message secrecy for all
messages exchanged in the epochs after the compromised party has been messages exchanged in the epochs after the compromised party has been
removed. removed.
8.3.2. Compromise by an Active Adversary with the Ability to Sign 8.3.2. Compromise by an Active Adversary with the Ability to Sign
Messages Messages
If an active adversary has compromised an MLS client and can sign If an active adversary has compromised an MLS client and can sign
messages, two different scenarios emerge. In the strongest messages, two different scenarios emerge. In the strongest
compromise scenario, the attacker has access to the signing key and compromise scenario, the attacker has access to the signing key and
can forge authenticated messages. In a weaker but realistic can forge authenticated messages. In a weaker, yet realistic
scenario, the attacker has compromised a client but the client scenario, the attacker has compromised a client but the client
signature keys are protected with dedicated hardware features that do signature keys are protected with dedicated hardware features which
not allow direct access to the value of the private key and instead do not allow direct access to the value of the private key and
provide a signature API. instead provide a signature API.
When considering an active adaptive attacker with access to a When considering an active adaptive attacker with access to a
signature oracle, the compromise scenario implies a significant signature oracle, the compromise scenario implies a significant
impact on both the secrecy and authentication guarantees of the impact on both the secrecy and authentication guarantees of the
protocol, especially if the attacker also has access to the group protocol, especially if the attacker also has access to the group
secrets. In that case, both secrecy and authentication are broken. secrets. In that case, both secrecy and authentication are broken.
The attacker can generate any message, for the current and future The attacker can generate any message, for the current and future
epochs, until the compromise is remediated and the formerly epochs, until the compromise is remediated and the formerly
compromised client sends an honest update. compromised client sends an honest update.
Note that under this compromise scenario, the attacker can perform Note that under this compromise scenario, the attacker can perform
all operations that are available to a legitimate client even without all operations which are available to a legitimate client even
access to the actual value of the signature key. without access to the actual value of the signature key.
8.3.3. Compromise of the Authentication with Access to a 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 The difference between having access to the value of the signature
key and only having access to a signing oracle is not about the key and only having access to a signing oracle is not about the
ability of an active adaptive network attacker to perform different ability of an active adaptive network attacker to perform different
operations during the time of the compromise; the attacker can operations during the time of the compromise; the attacker can
perform every operation available to a legitimate client in both perform every operation available to a legitimate client in both
cases. cases.
There is a significant difference, however, in terms of recovery There is a significant difference, however, in terms of recovery
after a compromise. after a compromise.
skipping to change at line 1724 skipping to change at line 1714
if they still have control over some group keys by colluding with if they still have control over some group keys by colluding with
other members of the group. other members of the group.
This is in contrast with the case where the signature key is leaked. This is in contrast with the case where the signature key is leaked.
In that case, the compromised endpoint needs to refresh its In that case, the compromised endpoint needs to refresh its
credentials and invalidate the old credentials before the attacker credentials and invalidate the old credentials before the attacker
will be unable to authenticate messages. will be unable to authenticate messages.
Beware that in both oracle and private key access, an active adaptive Beware that in both oracle and private key access, an active adaptive
attacker can follow the protocol and request to update its own attacker can follow the protocol and request to update its own
credential. This in turn induces a signature key rotation which credential. This in turn induces a signature key rotation, which
could provide the attacker with part or the full value of the private could provide the attacker with part or the full value of the private
key, depending on the architecture of the service provider. key, depending on the architecture of the service provider.
*RECOMMENDATION:* Signature private keys should be *Recommendation:* Signature private keys should be
compartmentalized from other secrets and preferably protected by a compartmentalized from other secrets and preferably protected by a
Hardware Security Module (HSM) or dedicated hardware features to Hardware Security Module (HSM) or dedicated hardware features to
allow recovery of the authentication for future messages after a allow recovery of the authentication for future messages after a
compromise. compromise.
*RECOMMENDATION:* When the credential type supports revocation, *Recommendation:* When the credential type supports revocation,
the users of a group should check for revoked keys. the users of a group should check for revoked keys.
8.3.4. Security Considerations in the Context of a Full State 8.3.4. Security Considerations in the Context of a Full State
Compromise Compromise
In real-world compromise scenarios, it is often the case that In real-world compromise scenarios, it is often the case that
adversaries target specific devices to obtain parts of the memory or adversaries target specific devices to obtain parts of the memory or
even the ability to execute arbitrary code in the targeted device. even the ability to execute arbitrary code in the targeted device.
Also, recall that in this setting, the application will often retain Also, recall that in this setting, the application will often retain
the unencrypted messages. If so, the adversary does not have to the unencrypted messages. If so, the adversary does not have to
break encryption at all to access sent and received messages. break encryption at all to access sent and received messages.
Messages may also be sent by using the application to instruct the Messages may also be sent by using the application to instruct the
protocol implementation. protocol implementation.
*RECOMMENDATION:* If messages are stored on the device, they *Recommendation:* If messages are stored on the device, they
should be protected using encryption at rest, and the keys used should be protected using encryption at rest, and the keys used
should be stored securely using dedicated mechanisms on the should be stored securely using dedicated mechanisms on the
device. device.
*RECOMMENDATION:* If the threat model of the system is against an *Recommendation:* If the threat model of the system includes an
adversary that can access the messages on the device without even adversary that can access the messages on the device without even
needing to attack MLS, the application should delete plaintext and needing to attack MLS, the application should delete plaintext and
ciphertext messages as soon as practical after encryption or ciphertext messages as soon as practical after encryption or
decryption. decryption.
Note that this document makes a clear distinction between the way Note that this document makes a clear distinction between the way
signature keys and other group shared secrets must be handled. In signature keys and other group shared secrets must be handled. In
particular, a large set of group secrets cannot necessarily be particular, a large set of group secrets cannot necessarily be
assumed to be protected by an HSM or secure enclave features. This assumed to be protected by an HSM or secure enclave features. This
is especially true because these keys are frequently used and changed is especially true because these keys are frequently used and changed
skipping to change at line 1779 skipping to change at line 1769
send a message. They also provide strong authentication guarantees send a message. They also provide strong authentication guarantees
to other clients; hence, we consider that their protection by to other clients; hence, we consider that their protection by
additional security mechanisms should be a priority. additional security mechanisms should be a priority.
Overall, there is no way to detect or prevent these compromises, as Overall, there is no way to detect or prevent these compromises, as
discussed in the previous sections: Performing separation of the discussed in the previous sections: Performing separation of the
application secret states can help recovery after compromise; this is application secret states can help recovery after compromise; this is
the case for signature keys, but similar concerns exist for a the case for signature keys, but similar concerns exist for a
client's encryption private keys. client's encryption private keys.
*RECOMMENDATION:* The secret keys used for public key encryption *Recommendation:* The secret keys used for public key encryption
should be stored similarly to the way the signature keys are should be stored similarly to the way the signature keys are
stored, as keys can be used to decrypt the group operation stored, as keys can be used to decrypt the group operation
messages and contain the secret material used to compute all the messages and contain the secret material used to compute all the
group secrets. group secrets.
Even if secure enclaves are not perfectly secure or are even Even if secure enclaves are not perfectly secure or are even
completely broken, adopting additional protections for these keys can completely broken, adopting additional protections for these keys can
ease recovery of the secrecy and authentication guarantees after a ease recovery of the secrecy and authentication guarantees after a
compromise where, for instance, an attacker can sign messages without compromise where, for instance, an attacker can sign messages without
having access to the key. In certain contexts, the rotation of having access to the key. In certain contexts, the rotation of
credentials might only be triggered by the AS through ACLs and hence credentials might only be triggered by the AS through ACLs and hence
be beyond the capabilities of the attacker. be beyond the capabilities of the attacker.
8.4. Service Node Compromise 8.4. Service Node Compromise
8.4.1. General Considerations 8.4.1. General Considerations
8.4.1.1. Privacy of the Network Connections 8.4.1.1. Privacy of the Network Connections
There are many scenarios leading to communication between the There are many scenarios leading to communication between the
application on a device and the Delivery Service or the application on a device and the DS or the AS. In particular, when:
Authentication Service -- in particular, when:
* The application connects to the Authentication Service to generate * The application connects to the AS to generate or validate a new
or validate a new credential before distributing it. credential before distributing it.
* The application fetches credentials at the Delivery Service prior * The application fetches credentials at the DS prior to creating a
to creating a messaging group (one-to-one or more than two messaging group (one-to-one or more than two clients).
clients).
* The application fetches service provider information or messages * The application fetches service provider information or messages
on the Delivery Service. on the DS.
* The application sends service provider information or messages to * The application sends service provider information or messages to
the Delivery Service. the Delivery Service.
In all these cases, the application will often connect to the device In all these cases, the application will often connect to the device
via a secure transport that leaks information about the origin of the via a secure transport which leaks information about the origin of
request, such as the IP address and -- depending on the protocol -- the request, such as the IP address and -- depending on the protocol
the Media Access Control (MAC) address of the device. -- the MAC address of the device.
Similar concerns exist in the peer-to-peer use cases for MLS. Similar concerns exist in the peer-to-peer use cases for MLS.
*RECOMMENDATION:* In the case where privacy or anonymity is *Recommendation:* In the case where privacy or anonymity is
important, using adequate protection such as Multiplexed important, using adequate protection such as Multiplexed
Application Substrate over QUIC Encryption (MASQUE) Application Substrate over QUIC Encryption (MASQUE)
[MASQUE-PROXY], Top-of-Rack (ToR) switches, or a VPN can improve [MASQUE-PROXY], Tor [Tor], or a VPN can improve metadata
metadata protection. protection.
More generally, using anonymous credentials in an MLS-based More generally, using anonymous credentials in an MLS-based
architecture might not be enough to provide strong privacy or architecture might not be enough to provide strong privacy or
anonymity properties. anonymity properties.
8.4.1.2. Storage of Metadata and Encryption at Rest on the Servers 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 In the case where private data or metadata has to be persisted on the
servers for functionality (mappings between identities and push servers for functionality (mappings between identities and push
tokens, group metadata, etc.), it should be stored encrypted at rest tokens, group metadata, etc.), it should be stored encrypted at rest
and only decrypted upon need during the execution. Honest Service and only decrypted upon need during the execution. Honest service
Providers can rely on such an "encryption at rest" mechanism to be providers can rely on such "encryption at rest" mechanisms to be able
able to prevent access to the data when not using it. to prevent access to the data when not using it.
*RECOMMENDATION:* Store cryptographic material used for server- *Recommendation:* Store cryptographic material used for server-
side decryption of sensitive metadata on the clients and only send side decryption of sensitive metadata on the clients and only send
it when needed. The server can use the secret to open and update it when needed. The server can use the secret to open and update
encrypted data containers after which they can delete these keys encrypted data containers after which they can delete these keys
until the next time they need it, in which case those can be until the next time they need it, in which case those can be
provided by the client. provided by the client.
*RECOMMENDATION:* Rely on group secrets exported from the MLS *Recommendation:* Rely on group secrets exported from the MLS
session for server-side encryption at rest and update the key session for server-side encryption at rest and update the key
after each removal from the group. Otherwise, rotate those keys after each removal from the group. Otherwise, rotate those keys
on a regular basis. on a regular basis.
8.4.2. Delivery Service Compromise 8.4.2. Delivery Service Compromise
MLS is intended to provide strong guarantees in the face of MLS is intended to provide strong guarantees in the face of
compromise of the DS. Even a totally compromised DS should not be compromise of the DS. Even a totally compromised DS should not be
able to read messages or inject messages that will be acceptable to able to read messages or inject messages that will be acceptable to
legitimate clients. It should also not be able to undetectably legitimate clients. It should also not be able to undetectably
skipping to change at line 1873 skipping to change at line 1861
system, including total DoS attacks (where it simply refuses to system, including total DoS attacks (where it simply refuses to
forward any messages) and partial DoS attacks (where it refuses to forward any messages) and partial DoS attacks (where it refuses to
forward messages to and from specific clients). As noted in forward messages to and from specific clients). As noted in
Section 5.2, these attacks are only partially detectable by clients Section 5.2, these attacks are only partially detectable by clients
without an out-of-band channel. Ultimately, failure of the DS to without an out-of-band channel. Ultimately, failure of the DS to
provide reasonable service must be dealt with as a customer service provide reasonable service must be dealt with as a customer service
matter, not via technology. matter, not via technology.
Because the DS is responsible for providing the initial keying Because the DS is responsible for providing the initial keying
material to clients, it can provide stale keys. This does not material to clients, it can provide stale keys. This does not
inherently lead to compromise of the message stream, but it does inherently lead to compromise of the message stream, but does allow
allow it to attack forward security to a limited extent. This threat the DS to attack post-compromise security to a limited extent. This
can be mitigated by having initial keys expire. threat can be mitigated by having initial keys expire.
Initial keying material (KeyPackages) using the basic Credential type Initial keying material (KeyPackages) using the basic credential type
is more vulnerable to replacement by a malicious or compromised DS, is more vulnerable to replacement by a malicious or compromised DS,
as there is no built-in cryptographic binding between the identity as there is no built-in cryptographic binding between the identity
and the public key of the client. and the public key of the client.
*RECOMMENDATION:* Prefer a Credential type in KeyPackages that *Recommendation:* Prefer a credential type in KeyPackages which
includes a strong cryptographic binding between the identity and includes a strong cryptographic binding between the identity and
its key (for example, the x509 Credential type). When using the its key (for example, the x509 credential type). When using the
basic Credential type, take extra care to verify the identity basic credential type, take extra care to verify the identity
(typically out of band). (typically out of band).
8.4.2.1. Privacy of Delivery and Push Notifications 8.4.2.1. Privacy of Delivery and Push Notifications
Push-tokens provide an important mechanism that is often ignored from Push tokens provide an important mechanism that is often ignored from
the standpoint of privacy considerations. In many modern messaging the standpoint of privacy considerations. In many modern messaging
architectures, applications are using push notification mechanisms architectures, applications are using push notification mechanisms
typically provided by OS vendors. This is to make sure that when typically provided by OS vendors. This is to make sure that when
messages are available at the Delivery Service (or via other messages are available at the DS (or via other mechanisms if the DS
mechanisms if the DS is not a central server), the recipient is not a central server), the recipient application on a device knows
application on a device knows about it. Sometimes the push about it. Sometimes the push notification can contain the
notification can contain the application message itself; this saves a application message itself, which saves a round trip with the DS.
round trip with the DS.
To "push" this information to the device, the service provider and To "push" this information to the device, the service provider and
the OS infrastructures use unique per-device, per-application the OS infrastructures use unique per-device, per-application
identifiers called push-tokens. This means that the push identifiers called push tokens. This means that the push
notification provider and the service provider have information on notification provider and the service provider have information on
which devices receive information and at which point in time. which devices receive information and at which point in time.
Alternatively, non-mobile applications could use a WebSocket or Alternatively, non-mobile applications could use a WebSocket or
persistent connection for notifications directly from the DS. persistent connection for notifications directly from the DS.
Even though they can't necessarily access the content, which is Even though the service provider and the push notification provider
typically encrypted MLS messages, the service provider and the push can't necessarily access the content (typically encrypted MLS
notification provider have to be trusted to avoid making correlation messages), no technical mechanism in MLS prevents them from
on which devices are recipients of the same message. determining which devices are recipients of the same message.
For secure messaging systems, push notifications are often sent in For secure messaging systems, push notifications are often sent in
real time, as it is not acceptable to create artificial delays for real time, as it is not acceptable to create artificial delays for
message retrieval. message retrieval.
*RECOMMENDATION:* If real-time notifications are not necessary, *Recommendation:* If real-time notifications are not necessary,
one can delay notifications randomly across recipient devices one can delay notifications randomly across recipient devices
using a mixnet or other techniques. using a mixnet or other techniques.
Note that with a legal request to ask the service provider for the 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 push token associated with an identifier, it is easy to correlate the
token with a second request to the company operating the push- token with a second request to the company operating the push
notification system to get information about the device, which is notification system to get information about the device, which is
often linked with a real identity via a cloud account, a credit card, often linked with a real identity via a cloud account, a credit card,
or other information. or other information.
*RECOMMENDATION:* If stronger privacy guarantees are needed with *Recommendation:* If stronger privacy guarantees are needed with
regard to the push notification provider, the client can choose to regard to the push notification provider, the client can choose to
periodically connect to the Delivery Service without the need of a periodically connect to the DS without the need of a dedicated
dedicated push notification infrastructure. push notification infrastructure.
Applications can also consider anonymous systems for server fanout Applications can also consider anonymous systems for server fanout
(for example, [Loopix]). (for example, [Loopix]).
8.4.3. Authentication Service Compromise 8.4.3. Authentication Service Compromise
The Authentication Service design is left to the infrastructure The Authentication Service design is left to the infrastructure
designers. In most designs, a compromised AS is a serious matter, as designers. In most designs, a compromised AS is a serious matter, as
the AS can serve incorrect or attacker-provided identities to the AS can serve incorrect or attacker-provided identities to
clients. clients.
skipping to change at line 1956 skipping to change at line 1943
* The attacker can sign new credentials. * The attacker can sign new credentials.
* The attacker can publish or distribute credentials. * The attacker can publish or distribute credentials.
An attacker that can generate or sign new credentials may or may not An attacker that can generate or sign new credentials may or may not
have access to the underlying cryptographic material necessary to have access to the underlying cryptographic material necessary to
perform such operations. In that last case, it results in windows of perform such operations. In that last case, it results in windows of
time for which all emitted credentials might be compromised. time for which all emitted credentials might be compromised.
*RECOMMENDATION:* Use HSMs to store the root signature keys to *Recommendation:* Use HSMs to store the root signature keys to
limit the ability of an adversary with no physical access to limit the ability of an adversary with no physical access to
extract the top-level signature private key. extract the top-level signature private key.
Note that historically some systems generate signature keys on the Note that historically some systems generate signature keys on the AS
Authentication Service and distribute the private keys to clients and distribute the private keys to clients along with their
along with their credential. This is a dangerous practice because it credential. This is a dangerous practice because it allows the AS or
allows the AS or an attacker who has compromised the AS to silently an attacker who has compromised the AS to silently impersonate the
impersonate the client. client.
8.4.3.1. Authentication Compromise: Ghost Users and Impersonations 8.4.3.1. Authentication Compromise: Ghost Users and Impersonation
One important property of MLS is that all Members know which other 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 members are in the group at all times. If all members of the group
and the Authentication Service are honest, no parties other than the and the Authentication Service are honest, no parties other than the
members of the current group can read and write messages protected by members of the current group can read and write messages protected by
the protocol for that Group. the protocol for that group.
This guarantee applies to the cryptographic identities of the This guarantee applies to the cryptographic identities of the
members. Details about how to verify the identity of a client depend members. Details about how to verify the identity of a client depend
on the MLS Credential type used. For example, cryptographic on the MLS credential type used. For example, cryptographic
verification of credentials can be largely performed autonomously verification of credentials can be largely performed autonomously
(e.g., without user interaction) by the clients themselves for the (e.g., without user interaction) by the clients themselves for the
x509 Credential type. x509 credential type.
In contrast, when MLS clients use the basic Credential type, some In contrast, when MLS clients use the basic credential type, some
other mechanism must be used to verify identities. For instance, the other mechanism must be used to verify identities. For instance, the
Authentication Service could operate some sort of directory server to Authentication Service could operate some sort of directory server to
provide keys, or users could verify keys via an out-of-band provide keys, or users could verify keys via an out-of-band
mechanism. mechanism.
*RECOMMENDATION:* Select the MLS Credential type with the *Recommendation:* Select the MLS credential type with the
strongest security that is supported by all target members of an strongest security which is supported by all target members of an
MLS group. MLS group.
*RECOMMENDATION:* Do not use the same signature keypair across *Recommendation:* Do not use the same signature key pair across
groups. Update all keys for all groups on a regular basis. Do groups. Update all keys for all groups on a regular basis. Do
not preserve keys in different groups when suspecting a not preserve keys in different groups when suspecting a
compromise. compromise.
If the AS is compromised, it could validate a signature keypair (or 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 generate a new one) for an attacker. The attacker could then use
this keypair to join a group as if it were another of the user's 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 clients. Because a user can have many MLS clients running the MLS
protocol, it possibly has many signature keypairs for multiple protocol, it possibly has many signature key pairs for multiple
devices. These attacks could be very difficult to detect, especially devices. These attacks could be very difficult to detect, especially
in large groups where the UI might not reflect all the changes back in large groups where the UI might not reflect all the changes back
to the users. If the application participates in a key transparency to the users. If the application participates in a key transparency
mechanism in which it is possible to determine every key for a given mechanism in which it is possible to determine every key for a given
user, then this would allow for detection of surreptitiously created user, then this would allow for detection of surreptitiously created
false credentials. false credentials.
*RECOMMENDATION:* Make sure that MLS clients reflect all the *Recommendation:* Make sure that MLS clients reflect all the
membership changes to the users as they happen. If a choice has membership changes to the users as they happen. If a choice has
to be made because the number of notifications is too high, the 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 client should provide a log of state of the device so that the
user can examine it. user can examine it.
*RECOMMENDATION:* Provide a key transparency mechanism for the *Recommendation:* Provide a key transparency mechanism for the AS
Authentication Service to allow public verification of the to allow public verification of the credentials authenticated by
credentials authenticated by this service. this service.
While the ways to handle MLS credentials are not defined by the While the ways to handle MLS credentials are not defined by the
protocol or the architecture documents, the MLS protocol has been protocol or the architecture documents, the MLS protocol has been
designed with a mechanism that can be used to provide out-of-band designed with a mechanism that can be used to provide out-of-band
authentication to users. The "authentication_secret" generated for authentication to users. The authentication_secret generated for
each user at each epoch of the group is a one-time, per-client each user at each epoch of the group is a one-time, per-client
authentication secret that can be exchanged between users to prove authentication secret which can be exchanged between users to prove
their identities to each other. This can be done, for instance, their identities to each other. This can be done, for instance,
using a QR code that can be scanned by the other parties. using a QR code that can be scanned by the other parties.
*RECOMMENDATION:* Provide one or more out-of-band authentication *Recommendation:* Provide one or more out-of-band authentication
mechanisms to limit the impact of an Authentication Service mechanisms to limit the impact of an AS compromise.
compromise.
We note, again, that the Authentication Service may not be a We note, again, that the AS may not be a centralized system and could
centralized system and could be realized by many mechanisms such as be realized by many mechanisms such as establishing prior one-to-one
establishing prior one-to-one deniable channels, gossiping, or using deniable channels, gossiping, or using trust on first use (TOFU) for
trust on first use (TOFU) for credentials used by the MLS protocol. credentials used by the MLS protocol.
Another important consideration is the ease of redistributing new Another important consideration is the ease of redistributing new
keys on client compromise, which helps recovering security faster in keys on client compromise, which helps recovering security faster in
various cases. various cases.
8.4.3.2. Privacy of the Group Membership 8.4.3.2. Privacy of the Group Membership
Group membership is itself sensitive information, and MLS is designed Group membership is itself sensitive information, and MLS is designed
to limit the amount of persistent metadata. However, large groups to limit the amount of persistent metadata. However, large groups
often require an infrastructure that provides server fanout. In the often require an infrastructure that provides server fanout. In the
case of client fanout, the destination of a message is known by all case of client fanout, the destination of a message is known by all
clients; hence, the server usually does not need this information. clients; hence, the server usually does not need this information.
However, they may learn this information through traffic analysis. However, servers may learn this information through traffic analysis.
Unfortunately, in a server-side fanout model, the Delivery Service Unfortunately, in a server-side fanout model, the Delivery Service
can learn that a given client is sending the same message to a set of can learn that a given client is sending the same message to a set of
other clients. In addition, there may be applications of MLS in other clients. In addition, there may be applications of MLS in
which the group membership list is stored on some server associated which the group membership list is stored on some server associated
with the Delivery Service. with the DS.
While this knowledge is not a breach of the protocol's authentication While this knowledge is not a breach of the protocol's authentication
or confidentiality guarantees, it is a serious issue for privacy. or confidentiality guarantees, it is a serious issue for privacy.
Some infrastructures keep a mapping between keys used in the MLS Some infrastructures keep a mapping between keys used in the MLS
protocol and user identities. An attacker with access to this protocol and user identities. An attacker with access to this
information due to compromise or regulation can associate unencrypted information due to compromise or regulation can associate unencrypted
group messages (e.g., Commits and Proposals) with the corresponding group messages (e.g., Commits and Proposals) with the corresponding
user identity. user identity.
*RECOMMENDATION:* Use encrypted group operation messages to limit *Recommendation:* Use encrypted group operation messages to limit
privacy risks whenever possible. privacy risks whenever possible.
In certain cases, the adversary can access specific bindings between In certain cases, the adversary can access specific bindings between
public keys and identities. If the signature keys are reused across public keys and identities. If the signature keys are reused across
groups, the adversary can get more information about the targeted groups, the adversary can get more information about the targeted
user. user.
*RECOMMENDATION:* Ensure that linking between public keys and *Recommendation:* Ensure that linking between public keys and
identities only happens in expected scenarios. identities only happens in expected scenarios.
8.5. Considerations for Attacks Outside of the Threat Model 8.5. Considerations for Attacks Outside of the Threat Model
Physical attacks on devices storing and executing MLS principals are Physical attacks on devices storing and executing MLS principals are
not considered in depth in the threat model of the MLS protocol. not considered in depth in the threat model of the MLS protocol.
While non-permanent, non-invasive attacks can sometimes be equivalent While non-permanent, non-invasive attacks can sometimes be equivalent
to software attacks, physical attacks are considered outside of the to software attacks, physical attacks are considered outside of the
MLS threat model. MLS threat model.
Compromise scenarios typically consist of a software adversary, which Compromise scenarios typically consist of a software adversary, which
can maintain active adaptive compromise and arbitrarily change the can maintain active adaptive compromise and arbitrarily change the
behavior of the client or service. behavior of the client or service.
On the other hand, security goals consider that honest clients will On the other hand, security goals consider that honest clients will
always run the protocol according to its specification. This relies always run the protocol according to its specification. This relies
on implementations of the protocol to securely implement the on implementations of the protocol to securely implement the
specification, which remains non-trivial. specification, which remains non-trivial.
*RECOMMENDATION:* Additional steps should be taken to protect the *Recommendation:* Additional steps should be taken to protect the
device and the MLS clients from physical compromise. In such device and the MLS clients from physical compromise. In such
settings, HSMs and secure enclaves can be used to protect settings, HSMs and secure enclaves can be used to protect
signature keys. signature keys.
8.6. Cryptographic Analysis of the MLS Protocol 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 that the message was originally
sent. Applications for whom replay is an important risk should apply
mitigations at the application layer, as discussed below.
In addition to the risks discussed in Section 8.3.1, an attacker with
access to the ratchet secrets for an endpoint can replay
PrivateMessage objects sent by other members of the group by taking
the signed content of the message and re-encrypting it with a new
generation of the original sender's ratchet. If the other members of
the group interpret a message with a new generation as a fresh
message, then this message will appear fresh. (This is possible
because the message signature does not cover the generation field of
the message.) Messages sent as PublicMessage objects similarly lack
replay protections. There is no message counter comparable to the
generation field in PrivateMessage.
Applications can detect replay by including a unique identifier for
the message (e.g., a counter) in either the message payload or the
authenticated_data field, both of which are included in the
signatures for PublicMessage and PrivateMessage.
8.7. Cryptographic Analysis of the MLS Protocol
Various academic works have analyzed MLS and the different security Various academic works have analyzed MLS and the different security
guarantees it aims to provide. The security of large parts of the guarantees it aims to provide. The security of large parts of the
protocol has been analyzed by [BBN19] (regarding MLS Draft 7), protocol has been analyzed by [BBN19] (for MLS Draft 7), [ACDT21]
[ACDT21] (regarding MLS Draft 11), and [AJM20] (regarding MLS Draft (for MLS Draft 11), and [AJM20] (for MLS Draft 12).
12).
Individual components of various drafts of the MLS protocol have been Individual components of various drafts of the MLS protocol have been
analyzed in isolation and with differing adversarial models. For analyzed in isolation and with differing adversarial models. For
example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20], [ACJM20], and example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20], [ACJM20],
[AHKM21] analyze the ratcheting tree sub-protocol of MLS that [AHKM21], [CGWZ25], and [WPB25] analyze the ratcheting tree sub-
facilitates key agreement; [WPBB22] analyzes the sub-protocol of MLS protocol of MLS that facilitates key agreement; [WPBB22] analyzes the
for group state agreement and authentication; and [BCK21] analyzes sub-protocol of MLS for group state agreement and authentication; and
the key derivation paths in the ratchet tree and key schedule. [BCK21] analyzes the key derivation paths in the ratchet tree and key
Finally, [CHK21] analyzes the authentication and cross-group healing schedule. Finally, [CHK21] analyzes the authentication and cross-
guarantees provided by MLS. group healing guarantees provided by MLS.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
skipping to change at line 2187 skipping to change at line 2199
[BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok, "Security [BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok, "Security
Analysis of the MLS Key Distribution", Cryptology ePrint Analysis of the MLS Key Distribution", Cryptology ePrint
Archive, 2021, <https://eprint.iacr.org/2021/137.pdf>. Archive, 2021, <https://eprint.iacr.org/2021/137.pdf>.
[CAPBR] Brewer, E. A., "Towards robust distributed systems [CAPBR] Brewer, E. A., "Towards robust distributed systems
(abstract)", Proceedings of the nineteenth annual ACM (abstract)", Proceedings of the nineteenth annual ACM
symposium on Principles of distributed computing, p. 7, symposium on Principles of distributed computing, p. 7,
DOI 10.1145/343477.343502, July 2000, DOI 10.1145/343477.343502, July 2000,
<https://dl.acm.org/doi/10.1145/343477.343502>. <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 [CHK21] Cremers, C., Hale, B., and K. Kohbrok, "The Complexities
of Healing in Secure Group Messaging: Why Cross-Group of Healing in Secure Group Messaging: Why Cross-Group
Effects Matter", Proceedings of the 30th USENIX Security Effects Matter", Proceedings of the 30th USENIX Security
Symposium, August 2021, Symposium, August 2021,
<https://www.usenix.org/system/files/sec21-cremers.pdf>. <https://www.usenix.org/system/files/sec21-cremers.pdf>.
[CONIKS] Melara, M. S., Blankstein, A., Bonneau, J., Felten, E. W.,
and M. J. Freedman, "CONIKS: Bringing Key Transparency to
End Users", Proceedings of the 24th USENIX Security
Symposium, August 2015,
<https://www.usenix.org/system/files/conference/
usenixsecurity15/sec15-paper-melara.pdf>.
[EXTENSIONS] [EXTENSIONS]
Robert, R., "The Messaging Layer Security (MLS) Robert, R., "The Messaging Layer Security (MLS)
Extensions", Work in Progress, Internet-Draft, draft-ietf- Extensions", Work in Progress, Internet-Draft, draft-ietf-
mls-extensions-06, 19 February 2025, mls-extensions-06, 19 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls- <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
extensions-06>. extensions-06>.
[FEDERATION] [FEDERATION]
Omara, E. and R. Robert, "The Messaging Layer Security Omara, E. and R. Robert, "The Messaging Layer Security
(MLS) Federation", Work in Progress, Internet-Draft, (MLS) Federation", Work in Progress, Internet-Draft,
draft-ietf-mls-federation-03, 9 September 2023, draft-ietf-mls-federation-03, 9 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls- <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
federation-03>. federation-03>.
[KT] McMillion, B., "Key Transparency Architecture", Work in [KT] McMillion, B., "Key Transparency Architecture", Work in
Progress, Internet-Draft, draft-ietf-keytrans- Progress, Internet-Draft, draft-ietf-keytrans-
architecture-02, 26 August 2024, architecture-03, 25 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf- <https://datatracker.ietf.org/doc/html/draft-ietf-
keytrans-architecture-02>. keytrans-architecture-03>.
[Loopix] Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and [Loopix] Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and
G. Danezis, "The Loopix Anonymity System", Proceedings of G. Danezis, "The Loopix Anonymity System", Proceedings of
the 26th USENIX Security Symposium, August 2017. the 26th USENIX Security Symposium, August 2017.
[MASQUE-PROXY] [MASQUE-PROXY]
Schinazi, D., "The MASQUE Proxy", Work in Progress, Schinazi, D., "The MASQUE Proxy", Work in Progress,
Internet-Draft, draft-schinazi-masque-proxy-05, 18 Internet-Draft, draft-schinazi-masque-proxy-05, 18
February 2025, <https://datatracker.ietf.org/doc/html/ February 2025, <https://datatracker.ietf.org/doc/html/
draft-schinazi-masque-proxy-05>. draft-schinazi-masque-proxy-05>.
skipping to change at line 2254 skipping to change at line 2264
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[Tor] "The Tor Project", n.d., <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. [WPBB22] Wallez, T., Protzenko, J., Beurdouche, B., and K.
Bhargavan, "TreeSync: Authenticated Group Management for Bhargavan, "TreeSync: Authenticated Group Management for
Messaging Layer Security", Cryptology ePrint Archive, Messaging Layer Security", Cryptology ePrint Archive,
2022, <https://eprint.iacr.org/2022/1732.pdf>. 2022, <https://eprint.iacr.org/2022/1732.pdf>.
Contributors Contributors
Richard Barnes Richard Barnes
Cisco Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
skipping to change at line 2310 skipping to change at line 2327
Phoenix R&D Phoenix R&D
Email: ietf@raphaelrobert.com Email: ietf@raphaelrobert.com
Authors' Addresses Authors' Addresses
Benjamin Beurdouche Benjamin Beurdouche
Inria & Mozilla Inria & Mozilla
Email: ietf@beurdouche.com Email: ietf@beurdouche.com
Eric Rescorla Eric Rescorla
Windy Hill Systems, LLC
Email: ekr@rtfm.com Email: ekr@rtfm.com
Emad Omara Emad Omara
Email: emad.omara@gmail.com Email: emad.omara@gmail.com
Srinivas Inguva Srinivas Inguva
Email: singuva@yahoo.com Email: singuva@yahoo.com
Alan Duric Alan Duric
Wire Email: alan@duric.net
Email: alan@wire.com
 End of changes. 184 change blocks. 
495 lines changed or deleted 511 lines changed or added

This html diff was produced by rfcdiff 1.48.