Light Clients for MLS

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 5 September 2024.¶

Copyright Notice

Copyright (c) 2024 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

The Messaging Layer Security protocol [RFC9420] enables continuous group authenticated key exchange among a group of clients. The design of MLS implicitly requires all members to download and maintain the full MLS tree, validate the credentials and signatures of all members, and process full commit messages. The size of the MLS tree is linear in the size of the group, and each commit message can also grow to be linear in the group size. Consequently, the MLS design results in high latency and performance bottlenecks at new members seeking to join a large group, or processing commits in large groups.¶

This document defines an extension to MLS to allow for "light clients" -- clients that do not download, validate, or maintain the entire ratchet tree for the group. On the one hand, this "lightness" allows a light client to participate in the group with much significantly lower communication and computation complexity (logarithmic in the group size in the worst case). On the other hand, without the full ratchet tree, the light client cannot create Commit messages to put changes to the group into effect. Light clients also only have authentication information for the parts of the tree they download, not the whole group.¶

We note that this document does not change the structure of the MLS tree, or the contents of messages sent in the course of an MLS session. It only modifies the local state stored at light clients, and changes how each light client downloads and checks group messages. The only modifications required for standard clients are related to the negotiation of an MLS extension, and additional data they need to send with each commit. Furthermore, we note that the changes in this document only affects the component of MLS that manages, synchronizes, and authenticates the public group state. It does not affect the TreeKEM key establishment or the application message sub-protocols.¶

The rest of the documemt defines the behavior of light clients, and the required modifications to standard MLS clients and the MLS infrastructure.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

This document introduces the following new concepts¶

• Tree Slice: A tree slice is the direct path from a leaf node to the root, together with the tree hashes on the co-path.¶

• Proof of Membership: A proof of membership for leaf A is a tree slice that proves that leaf A is in the tree with the tree hash in the root of the tree slice.¶

• Light Commit: A light commit is a commit that the server stripped down to hold only the encrypted path secret for the receiver.¶

• Light client: A light client is a client that does not know the MLS tree but only its own tree slice.¶

• Full client: A full client is conversely a client that is running the full MLS protocol from [RFC9420].¶

4. Protocol Overview

Figure 1 illustrates the three main changes introduced by Light MLS:¶

1. Light clients are always added to the group with a "light" Welcome message, i.e., one that does not include the ratchet_tree extension.¶

2. The MLS Delivery Service splits each Commit message into a set of LightCommit messages, one per light client.¶

3. Light clients can download "slices" of the tree to authenticate individual other users (here, A authenticates B).¶

MLS groups that support light clients must use the light_clients extension (Section 7.2) in the required capabilities. When this extension is present in the group context, all messages, except for application messages, MUST use public messages.¶

The changes are primarily on light clients. When joining a group as a light client, the client downloads the proof of memberships for the sender (committer) and the receiver (the light client). The sender's proof of membership can be discarded after being checked such that only the client's direct path and hashes on the co-path are stored.¶

Light clients do not process proposals that modify the structure of the tree, in particular Add, Update, or Remove proposals.¶

When processing a commit, the client retrieves¶

• the light commit that contains only the path secret encrypted for the client¶

• the sender's proof of membership¶

• the signed group info¶

The client MUST NOT check the signature and membership tag on the framed content, but MUST check the sender's proof of membership, the signed group info, and the confirmation tag.¶

In groups with light_clients support, committers MUST send a signed group info with every commit.¶

The server MUST track the public group state together with the signed group info, and provide endpoints for clients to retrieve light commits and light welcomes. Further, it SHOULD provide an API to retrieve proof of memberships for arbitrary leaves, and an API to retrieve the full tree.¶

5. Open Questions

Proposals: In this document, we have assumed that light clients don't need to see or validate proposals. This is clearly true for proposals that just modify the tree, e.g., Add/Update/Remove, but less clear for proposals such as PreSharedKey and GroupContextExtensions, and even less clear for custom proposals. We may want to define a way that an application could enable light clients to verify some proposals. A light client can verify the signature on a proposal given a tree slice for the signer, but more mechanism might be needed to allow a light client to verify that a proposal was actually included in a Commit.¶

Slimming Down Further: We have assumed that LeafNode and GroupInfo messages are small enough that it's acceptable for light clients to have to download them. However, these messages themselves can be large, e.g., due to large extensions. It may be desireable to define lighter variants of these structs, for example:¶

• Defining a variant of GroupInfo that is intended for members of the group, who do not need to receive a copy of the GroupContext extensions.¶

• Updating the tree hash algorithm for leaf nodes so that a light client could receive and verify a subset of a leaf node (e.g. only the signature key and credential)¶

6. Tree Slices

A light client does not download or store the whole MLS ratchet tree, but still needs to download parts of the tree to verify the membership and identity of specific members. For example, the client needs to verify that it is in fact a member of the group, and that the sender of a Welcome adding it to the group is a member.¶

A tree slice provides one or more leaf nodes from the tree, together with the nodes and node hashes that are required to verify that those leaves are included in a tree with a given tree hash. A tree slice can thus function as a proof of membership for the members at the included leaf nodes.¶

struct {
  uint32 index;
  opaque tree_hash<V>;
} Hashes;

enum {
  reserved(0),
  xnode(1),
  hashes(2),
  (255)
} XNodeType;

struct {
  optional<Node> node;
  uint32 index;
} XNode;

struct {
  XNodeType node_type;
  select (XNode.node_type) {
    case xnode:  XNode xnode;
    case hashes: Hashes hashes;
  }
} SliceNode;

struct {
  SliceNode nodes<V>;
  uint32 leaf_index;
  uint32 n_leaves;
} TreeSlice;

Tree slices are used to prove group membership of leaves. The tree_info in light MLS messages always contains the sender's and may contain the receiver's tree slices to allow the receiver to check the proof of membership.¶

To verify the correctness of the group on a light client, the client checks its tree hash and parent hashes. For each direct path from a leaf to the root that the client has (tree slices), it checks the parent hash value on each node by using original_tree_hash of the co-path nodes. The tree hash on the root node is computed similarly, using the tree_hash values for all nodes where the client does not have the full nodes.¶

The delivery service should allow to query TreeSlice for proof of memberships at any point for any member in the tree.¶

7. Light MLS

Light MLS is a variant of MLS run by light clients.¶

For light welcomes the necessary tree information can be retrieved from the delivery server, or provided via the tree_info GroupInfo extension.¶

struct {
    TreeSlice tree_info<V>;
} TreeInfo

Light commit messages are defined as a new content type for the FramedContent. A light commit contains a GroupInfo with a LightPathSecret extension, which contains the commit secret for the receiving light client and the corresponding node index. In addition, the GroupInfo contains a TreeInfo extension with the committer's direct paths.¶

enum {
    reserved(0),
    application(1),
    proposal(2),
    commit(3),
    light_commit(4),
    (255)
} ContentType;

struct {
    HPKECiphertext encrypted_path_secret;
    uint32 decryption_node_index;
} LightPathSecret;

struct {
    GroupInfo group_info;
} LightCommit;

Full MLS clients do not need to implement these types. The delivery service can build these messages instead.¶

The committer's new leaf node is not part of the LightCommit message. Instead, it is part of the tree_info extension in the GroupInfo.¶

enum LightClientType {
  reserved(0),
  no_upgrade(1),
  resync_upgrade(2),
  self_upgrade(3),
  any_upgrade(4),
  (255)
}

struct {
  LightClientType upgrade_policy;
} LightMlsExtension;

struct {

} LightMlsClient;

8. Full Members

Full MLS members in groups with light clients don't need significant changes. Any changes can always be built on top of regular MLS clients. In particular, full MLS clients are required to send a GroupInfo alongside every commit message to the delivery service. Depending on the deployment, the delivery service might also ask the client to send a ratchet tree for each commit. But the delivery service can track the tree based on commit messages such that sending ratchet trees with commits is not recommended.¶

9. Operational Considerations

The delivery service for MLS groups with light clients must provide additional endpoints for Light Welcome and Light Commit messages. In order to provide these endpoints the server must keep track of the public group state.¶

10. Security Considerations

The MLS protocol in [RFC9420] has a number of security analyses attached. To describe the security of light MLS and how it relates to the security of full MLS we summarize the following main high-level guarantees of MLS as follows:¶

• Membership Agreement: If a client B has a local group state for group G in epoch N, and it receives (and accepts) an application message from a sender A for group G in epoch N, then A must be a member of G in epoch N at B, and if A is honest, then A and B agree on the full membership of the group G in epoch N.¶

• Member Identity Authentication: If a client B has a local group state for group G in epoch N, and B believes that A is a member of G in epoch N, and that A is linked to a user identity U, then either the signature key of U’s credential is compromised, or A belongs to U.¶

• Group Key Secrecy: If B has a local group state for group G in epoch N with group key K (init secret), then K can only be known to members of G in epoch N. That is, if the attacker knows K, then one of the signature or decryption keys corresponding to one of the leaves of the tree stored at B for G in epoch N must be compromised. To obtain these properties, each member in MLS verifies a number of signatures and MACs, and seeks to preserve the TreeKEM Tree Invariants:¶

• Public Key Tree Invariant: At each node of the tree at a member B, the public key, if set, was set by one of the members currently underneath that node¶

• Path Secret Invariant: At each node, the path secret stored at a member B, if set, was created by one of the members currently underneath that node¶

As a corollary of Group Key Secrecy, we also obtain authentication and confidentiality guarantees for application messages sent and received within a group.¶

To verify the security guarantees provided by light members, a new security analysis is needed. We have analyzed the security of the protocol using two verification tools ProVerif and F*. The security analysis, and design of the security mechanisms, are inspired by work from Alwen et al. [AHKM22].¶

Light MLS preserves the invariants above and thereby all the security goals of MLS continue to hold at full members. However, a light member may not know the identities of all other members in the group, and it may only discover these identities on-demand. Consequently, the Member Identity Authentication guarantee is weaker on light clients. Furthermore, since light members do not store the MLS tree, membership agreement only holds for the hash of the MLS tree:¶

• Light Membership Agreement: If a light client B has a local group state for group G in epoch N, and it receives (and accepts) an application message from a sender A for group G in epoch N, then A must be a member of G in epoch N at B, and if A is honest, then A and B agree on the GroupContext of the group G in epoch N.¶

• Light Member Identity Authentication: If a light client B has a local group state for group G in epoch N, and B has verified A’s membership proof in G, and A is linked to a user identity U, then either the signature key of U’s credential is compromised, or A belongs to U.¶

• Light Group Key Secrecy: If a light client B has a local group state for group G in epoch N with group key K (init secret), and if the tree hash at B corresponds to a full tree, then K can only be known to members at the leaves of this tree. That is, if the attacker knows K, then the signature or decryption keys at one of the leaves must have been compromised.¶

Another technical caveat is that since light members do not have the full tree, they cannot validate the uniqueness of all HPKE and signature keys in the tree, as required by RFC MLS. The exact security implications of removing this uniqueness check is not clear but is not expected to be significant.¶

11. IANA Considerations

This document defines two new message types for MLS Wire Formats, and a new MLS Extension Type¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses