Leaf Operation Intents

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 April 2026.¶

Copyright Notice

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

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

Table of Contents

1. Introduction

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.¶

2. LeafOperationIntent

A LeafOperationIntent can be created by clients and distributed either to other group members or to one or more external senders.¶

HashReference LeafNodeRef;

MakeLeafNodeRef(value)
  = RefHash("MLS 1.0 LeafNode Reference", value)

enum {
  reserved(0),
  sender_removal_only(1),
  remove_associated_members(2),
  (255)
} RemovalMode

struct {
  opaque group_id<V>;
  uint32 sender_index;
  LeafNodeRef sender_leaf_ref;
  RemovalMode removal_mode;
} LeafOperationIntentTBS

struct {
  opaque group_id<V>;
  uint32 sender_index;
  LeafNodeRef sender_leaf_ref;
  RemovalMode removal_mode;
  /* SignWithLabel(., "LeafOperationIntentTBS", LeafOperationIntentTBS) */
  opaque signature<V>;
} LeafOperationIntent

struct {
  LeafOperationIntent intent;
} LeafOperationProposal

RefHash and SignWithLabel are as defined in [RFC9420].¶

• 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.¶

struct {
    ProtocolVersion version = mls10;
    WireFormat wire_format;
    select (MLSMessage.wire_format) {
      ...
      case mls_leaf_operation_intent:
        LeafOperationIntent leaf_operation_intent;
    };
} MLSMessage;

3. 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.¶

4. IANA Considerations

5. Normative References

[RFC9420]

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

[RFC9750]

Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and A. Duric, "The Messaging Layer Security (MLS) Architecture", RFC 9750, DOI 10.17487/RFC9750, April 2025, <https://www.rfc-editor.org/rfc/rfc9750>.

Acknowledgments

TODO acknowledge.¶

Contributors

Author's Address