]> Phoenix R&D

konrad@ratchet.ing

Security Messaging Layer Security mls The Messaging Layer Security (MLS) protocol defined in is an asynchronous secure group messaging protocol, which allows group members to propose their removal from a group. However, in some cases MLS clients can't reliably use regular Remove or SelfRemove proposals to leave a group because they don't have an up-to-date group state. This document specifies a LeafOperationIntent, which does not need an up-to-date group state but which retains sufficient binding to the client's current state to avoid replay attacks. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction To leave an MLS group, a member cannot create a commit, but rather has to propose its own removal. This can create difficulties, some of which have been solved by the introduction of the SelfRemove proposal, which may be included in external commits. One drawback of Remove and SelfRemove proposals is that they (like other proposals) are bound to a specific group epoch. This means that authors of such proposals must have an up-to-date group state to send such a proposal and continue to keep track of that group state both to re-send the proposal if necessary. This can be a problem if an application wants to cleanly leave a group and immediately delete the associated group state, e.g., to erase the associated metadata. The deletion of the group state makes it impossible for the client to re-send the proposal in case it's not covered by the next commit. Similarly, the client might be offline at the time and the group state might not be up-to-date. The LeafOperationIntent specified in this document allows a client to bind an intent to leave a group to the leaf's current state. That intent can then be proposed by any party (e.g. an external sender) in any subsequent epoch, provided the leaf remains unchanged As users often have more than one client that needs to be removed from the group as part of the user leaving, the intent allows expanding the leaf operation to associated leaves.

LeafOperationIntent A LeafOperationIntent can be created by clients and distributed either to other group members or to one or more external senders. ; uint32 sender_index; LeafNodeRef sender_leaf_ref; RemovalMode removal_mode; } LeafOperationIntentTBS struct { opaque group_id; uint32 sender_index; LeafNodeRef sender_leaf_ref; RemovalMode removal_mode; /* SignWithLabel(., "LeafOperationIntentTBS", LeafOperationIntentTBS) */ opaque signature; } LeafOperationIntent struct { LeafOperationIntent intent; } LeafOperationProposal ]]> RefHash and SignWithLabel are as defined in .

• group_id: The ID of the MLS group in which context the LeafOperationIntent was sent
• sender_index: The index of the sender's leaf in the group
• sender_leaf_ref: Hash computed over the LeafNode of the sending client using the MakeLeafNodeRef function
• removal_mode: Indicates whether only the sender should be removed, or whether additionally any other, associated members should be removed as well.
• signature: A signature over all fields except the signature itself using the sender's leaf signature key

The purpose of the removal_mode is to allow the sender to signal that other members associated with the sender should be removed as part of this operation. This can be useful if the sender is part of a group of associated devices, e.g., multiple devices belonging to the same user, to facilitate the leaving of the entire user as opposed to just the sending client.

LeafOperationIntent WireFormat A LeafOperationIntent is an MLS WireFormat and extends the select statement in the definition of MLSMessage as follows:

Creating and proposing a LeafOperationIntent A group member creates a LeafOperationIntent by populating the group_id, sender_index and sender_leaf_ref according to the current state of the group and the sender's leaf. If the sender wants to signal the removal of any associated members, it can set the removal_mode accordingly. Finally the sender creates the signature by calling SignWithLabel on the LeafOperationIntentTBS populated as described above with "LeafOperationIntentTBS" as label.

Processing a LeafOperationIntent Recipients of a LeafOperationIntent MUST perform the following steps:

• Verify that the group_id matches the group in which the proposal was sent
• Verify that the sender_leaf_ref is the LeafRef of the leaf at the sender_index
• Verify the signature over the intent using the signature public key in the leaf at the sender_index

If any of the validation steps fail, the recipient MUST consider the proposal invalid. If the validation was successful, the recipient MAY create a LeafOperationProposal containing the intent and either commit it directly or send it to the group.

Processing a LeafOperationProposal Recipients of a LeafOperationProposal MUST perform the checks listed in on the intent contained in the proposal. If any of the validation steps fail, the recipient MUST consider the proposal invalid. After that, the proposal MUST be validated and processed as if it were set of Remove proposals originating from the sender of the intent (not the sender of the proposal). The set of Remove proposals consists of one Remove proposal targeting the intent's sender_index. Additionally, if removal_mode is remove_associated_members, the recipient MUST check with the authentication service (AS, see ) whether any other members of the group are associated with the sender (see ). If there are any such members, the set of Remove proposals additionally contains one Remove proposal per associated targeting that member's leaf index. External commits may include one or more LeafOperationProposals. Any Removes validated as described above MUST thus be considered valid in this context.

Additional AS role When using LeafOperationIntents, the AS gains the additional role of having to identify other members in a group that are associated with the sender of a LeafOperationIntent. The sole purpose of association in this document is to determine whether other clients should be removed when a given client communicates its intent to leave a group. In most cases, association is determined by Credentials of the individual group members. A set of clients could, for example, be considered associated if all clients belong to the same user.

Security Considerations In contrast to proposals, LeafOperationIntents are not bound to an epoch and thus remain valid as long as the creator's leaf doesn't change its state. Each LeafOperationIntent can thus be proposed and committed to until the sender is either removed from the group or updates its own leaf. This allows scenarios, where, for example, members get added to or removed from a group in the time between the creation and the proposal of the intent. If a tighter bound to the epoch, i.e. the current group state is required, clients should use regular Remove or SelfRemove proposals instead. Epoch independence incurs a certain risk of replay attacks. The bound of the intent to the hash of the sender's LeafNode limits that risk significantly. However, a replay is possible, for example, if the sender's leaf still contains the LeafNode from a KeyPackage. In that case, if the sender is later added again with the same KeyPackage, the intent can be replayed.

IANA Considerations

MLS Proposal Types This document requests the addition of a new Proposal Type under the heading of "Messaging Layer Security". The leaf_operation_intent MLS Proposal Type is used to allow members or external senders to convey the intent of a leaf owner to perform an operation on their leaf.

• Value: TBD
• Name: leaf_operation_intent
• Recommended: Y
• External: Y
• Path Required: Y
• Reference: RFCXXXX

MLS WireFormats This document requests the addition of a new Wire Format under the heading of "Messaging Layer Security". The mls_leaf_operation_intent MLS WireFormat allows parties to send MLSMessages containing a LeafOperationIntent.

• Value: TBD
• Name: mls_leaf_operation_intent
• Recommended: Y
• Reference: RFCXXXX

Normative References Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy trade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the Delivery Service (DS), or the Authentication Service (AS).

Acknowledgments TODO acknowledge.

Contributors Phoenix R&D

ietf@raphaelrobert.com