rfc9750v3.txt   rfc9750.txt 
skipping to change at line 19 skipping to change at line 19
A. Duric A. Duric
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 designed 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
skipping to change at line 129 skipping to change at line 129
Sign Messages Sign Messages
8.3.3. Compromise of Authentication with Access to a Signature 8.3.3. Compromise of Authentication with Access to a 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. No Protection against Replay by Insiders 8.6. No Protection Against Replay by Insiders
8.7. Cryptographic Analysis of the MLS Protocol 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
skipping to change at line 196 skipping to change at line 196
object). A _Welcome_ message provides a new member to the group with object). A _Welcome_ message provides a new member to the group with
the information to initialize their state for the epoch in which they the information to initialize their state for the epoch in which they
were added. 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 DS may
delivery service may also be responsible for acting as a also be responsible for acting as a "broadcaster" where the sender
"broadcaster" where the sender sends a single message which is sends a single message which is then forwarded to each recipient
then forwarded to each recipient in the group by the DS. The DS in the group by the DS. The DS is also responsible for storing
is also responsible for storing and delivering initial public key and delivering initial public key material required by MLS clients
material required by MLS clients in order to proceed with the in order to proceed with the group secret key establishment that
group secret key establishment that is part of the MLS protocol. 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
specific implementation for the AS or DS. These services may reside specific implementation for the AS or DS. These services may reside
on the same server or different servers, they may be distributed on the same server or different servers, they may be distributed
between server and client components, and they may even involve some between server and client components, and they may even involve some
action by users. For example: action by users. For example:
* Several secure messaging services today provide a centralized DS * Several secure messaging services today provide a centralized DS
and rely on manual comparison of clients' public keys as the AS. and rely on manual comparison of clients' public keys as the AS.
skipping to change at line 553 skipping to change at line 553
* A credential from the AS attesting to the binding between the * A credential from the AS attesting to 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 cipher suite, but a client may want to offer support for multiple
protocol versions and ciphersuites. As such, there may be multiple protocol versions and cipher suites. 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. cipher suites, 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 DS to request KeyPackages for each of the other it first contacts the DS to request KeyPackages for each of the other
clients, authenticates the KeyPackages using the signature keys, clients, authenticates the KeyPackages using the signature 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
public encryption key (init_key) from each KeyPackage. When a client public encryption key (init_key) from each KeyPackage. When a client
requests a KeyPackage in order to add a user to a group, the DS requests a KeyPackage in order to add a user to a group, the DS
should provide the minimum number of KeyPackages necessary to satisfy should provide the minimum number of KeyPackages necessary to satisfy
the request. For example, if the request specifies the MLS version, the request. For example, if the request specifies the MLS version,
the DS might provide one KeyPackage per supported ciphersuite, even the DS might provide one KeyPackage per supported cipher suite, even
if it has multiple such KeyPackages to enable the corresponding if it has multiple such KeyPackages to enable the corresponding
client to be added to multiple groups before needing to upload more client to be added to multiple groups before needing to upload more
fresh 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, and init_key is intended to be deleted intended to be used only once, and init_key is intended to be deleted
by the client after decryption of the Welcome message. The DS is by the client after decryption of the Welcome message. The DS is
responsible for ensuring that each KeyPackage is only used to add its responsible for ensuring that each KeyPackage is only used to add its
client to a single group, with the possible exception of a "last client to a single group, with the possible exception of a "last
skipping to change at line 598 skipping to change at line 598
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 *Recommendation:* Ensure that clients delete the private component
of their init_key after processing a Welcome message, or after the of their init_key after processing a Welcome message, or after the
rotation of "last resort" KeyPackage. rotation of the "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 DS is to ensure delivery of messages. The main responsibility of the DS is to ensure delivery of messages.
Some MLS messages need only be delivered to specific clients (e.g., a Some MLS messages need only be delivered to specific clients (e.g., a
Welcome message initializing a new member's state), while others need Welcome message initializing a new member's state), while others need
to be delivered to all the members of a group. The DS may enable the to be delivered to all the members of a group. The DS may enable the
skipping to change at line 731 skipping to change at line 731
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.
This is particularly important when groups are being reinitialized. This is particularly important when groups are being reinitialized.
When a group is reinitialized, it is restarted with a different When a group is reinitialized, it is restarted with a different
protocol version and/or ciphersuite but identical membership. protocol version and/or cipher suite but identical membership.
Whenever an authorized member sends and commits a ReInit proposal, Whenever an authorized member sends and commits a ReInit proposal,
this immediately freezes the existing group and triggers the creation this immediately freezes the existing group and triggers the creation
of a new group with a new group_id. of a new group with a new group_id.
Ideally, the new group would be created by the same member that Ideally, the new group would be created by the same member that
committed the ReInit proposal (including sending Welcome messages for committed the ReInit proposal (including sending Welcome messages for
the new group to all of the previous group's members). However, this the new group to all of the previous group's members). However, this
operation is not always atomic, so it's possible for a member to go operation is not always atomic, so it's possible for a member to go
offline after committing a ReInit proposal but before creating the offline after committing a ReInit proposal but before creating the
new group. If this happens, it's necessary for another member to new group. If this happens, it's necessary for another member to
skipping to change at line 1057 skipping to change at line 1057
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
required for federation, multiple MLS implementations can required for federation, multiple MLS implementations can
interoperate to form federated systems if they use compatible interoperate to form federated systems if they use compatible
authentication mechanisms, ciphersuites, application content, and authentication mechanisms, cipher suites, application content, and
infrastructure functionalities. Federation is described in more infrastructure functionalities. Federation is described in more
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
creator is able to select the best version out of those suported in creator is able to select the best version out of those suported in
common 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 cipher suite supported across clients. Each client is able to
verify availability of protocol version, ciphersuites, and extensions verify availability of protocol version, cipher suites, and
at all times once it has at least received the first group operation extensions at all times once it has at least received the first group
message. operation 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
member of a group. Thus, in addition to preventing downgrade member of a group. Thus, in addition to preventing downgrade
attacks, the members of a group can also observe when it is safe to attacks, the members of a group can also observe when it is safe to
upgrade to a new ciphersuite or protocol version. upgrade to a new cipher suite or protocol version.
7. Operational Requirements 7. Operational Requirements
MLS is a security layer that needs to be integrated with an MLS is a security layer that needs to be integrated with an
application. A fully functional deployment of MLS will have to make application. A fully functional deployment of MLS will have to make
a number of decisions about how MLS is configured and operated. a number of decisions about how MLS is configured and operated.
Deployments that wish to interoperate will need to make compatible Deployments that wish to interoperate will need to make compatible
decisions. This section lists all of the dependencies of an MLS decisions. This section lists all of the dependencies of an MLS
deployment that are external to the protocol specification, but would deployment that are external to the protocol specification, but would
still need to be aligned within a given MLS deployment, or for two still need to be aligned within a given MLS deployment, or for two
deployments to potentially interoperate. deployments to potentially interoperate.
The protocol has a built-in ability to negotiate protocol versions, The protocol has a built-in ability to negotiate protocol versions,
ciphersuites, extensions, credential types, and additional proposal cipher suites, extensions, credential types, and additional proposal
types. For two deployments to interoperate, they must have types. For two deployments to interoperate, they must have
overlapping support in each of these categories. The overlapping support in each of these categories. The
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.
skipping to change at line 1218 skipping to change at line 1218
identify a group. identify a group.
* Application-level identifiers of public key material * Application-level identifiers of public key material
(specifically, the application_id extension as defined in (specifically, the application_id extension as defined in
Section 5.3.3 of [RFC9420]). Section 5.3.3 of [RFC9420]).
MLS requires the following policies to be defined, which restrict the MLS requires the following policies to be defined, which restrict the
set of acceptable behaviors in a group. These policies must be set of acceptable behaviors in a group. These policies must be
consistent between deployments for them to interoperate: consistent between deployments for them to interoperate:
* A policy on which ciphersuites are acceptable. * A policy on which cipher suites are acceptable.
* A policy on any mandatory or forbidden MLS extensions. * A policy on any mandatory or forbidden MLS extensions.
* A policy on when to send proposals and commits in plaintext * A policy on when to send proposals and commits in plaintext
instead of encrypted. instead of encrypted.
* A policy for which proposals are valid to have in a commit, * A policy for which proposals are valid to have in a commit,
including but not limited to: including but not limited to:
- When a member is allowed to add or remove other members of the - When a member is allowed to add or remove other members of the
skipping to change at line 1957 skipping to change at line 1957
Note that historically some systems generate signature keys on the AS Note that historically some systems generate signature keys on the AS
and distribute the private keys to clients along with their and distribute the private keys to clients along with their
credential. This is a dangerous practice because it allows the AS or credential. This is a dangerous practice because it allows the AS or
an attacker who has compromised the AS to silently impersonate the an attacker who has compromised the AS to silently impersonate the
client. client.
8.4.3.1. Authentication Compromise: Ghost Users and Impersonation 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 AS are honest, no parties other than the members of the
members of the current group can read and write messages protected by current group can read and write messages protected by the protocol
the protocol for that group. 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
skipping to change at line 2082 skipping to change at line 2082
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. No Protection against Replay by Insiders 8.6. No Protection Against Replay by Insiders
MLS does not protect against one group member replaying a MLS does not protect against one group member replaying a
PrivateMessage sent by another group member within the same epoch PrivateMessage sent by another group member within the same epoch
that the message was originally sent. Similarly, MLS does not that the message was originally sent. Similarly, MLS does not
protect against the replay (by a group member or otherwise) of a protect against the replay (by a group member or otherwise) of a
PublicMessage within the same epoch that the message was originally PublicMessage within the same epoch that the message was originally
sent. Applications for whom replay is an important risk should apply sent. Applications for whom replay is an important risk should apply
mitigations at the application layer, as discussed below. mitigations at the application layer, as discussed below.
In addition to the risks discussed in Section 8.3.1, an attacker with In addition to the risks discussed in Section 8.3.1, an attacker with
 End of changes. 16 change blocks. 
28 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.48.