From 1204e1a0207ad86925e2ed7911cea3ee5caa63d6 Mon Sep 17 00:00:00 2001 From: Rohan Mahy Date: Mon, 16 Jun 2025 07:11:18 +0200 Subject: [PATCH] Rename "Light MLS" to "Partial MLS" --- ...ls-light.md => draft-kiefer-mls-partial.md | 173 +++++++++--------- 1 file changed, 85 insertions(+), 88 deletions(-) rename draft-kiefer-mls-light.md => draft-kiefer-mls-partial.md (82%) diff --git a/draft-kiefer-mls-light.md b/draft-kiefer-mls-partial.md similarity index 82% rename from draft-kiefer-mls-light.md rename to draft-kiefer-mls-partial.md index 535c3e3..0a42601 100644 --- a/draft-kiefer-mls-light.md +++ b/draft-kiefer-mls-partial.md @@ -1,9 +1,9 @@ --- -title: "Light MLS" -abbrev: "Light MLS" +title: "Partial MLS" +abbrev: "Partial MLS" category: info -docname: draft-kiefer-mls-light-latest +docname: draft-kiefer-mls-partial-latest submissiontype: IETF # also: "independent", "IAB", or "IRTF" number: date: @@ -13,12 +13,9 @@ area: Security workgroup: Network Working Group keyword: Internet-Draft venue: - group: WG - type: Working Group - mail: WG@example.com - arch: https://example.com/WG - github: USER/REPO - latest: https://example.com/LATEST + group: MLS WG + mail: mls@ietf.org + github: cryspen/scalable-mls-id author: - ins: F. Kiefer @@ -54,11 +51,11 @@ group key establishment for large groups with up to thousands of clients. In MLS, any member can commit a change to the group, and consequently, all members must download, validate, and maintain the full group state, which can incur a significant communication and computational costs, especially when joining a -group. This document defines an MLS extension to support "light clients" that don't -undertake these costs. A light client cannot commit changes to the group, and +group. This document defines an MLS extension to support "partial MLS clients" that don't +undertake these costs. A partial client cannot commit changes to the group, and only has partial authentication information for the other members of the group, but is otherwise able to participate in the group. In exchange for these -limitations, a light client can participate in an MLS group with significantly +limitations, a partial MLS client can participate in an MLS group with significantly lower requirements in terms of download, memory, and processing. --- middle @@ -73,13 +70,13 @@ tree is linear in the size of the group. Consequently, the MLS design results in a performance bottleneck for new members seeking to join a large group, and significant storage and memory requirements once the member has joined. -This document defines an extension to MLS to allow for "light clients" -- +This document defines an extension to MLS to allow for "partial 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 +the group. On the one hand, this property allows a partial client to participate in the group with much significantly lower communication and computation complexity. 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 +partial client cannot create Commit messages to put changes to the group into +effect. Partial clients also only have authentication information for the parts of the tree they download, not the whole group. This document does not change the core logic of MLS, including: The structure of @@ -87,18 +84,18 @@ the ratchet tree and its associated algorithms, the key schedule, the secret tree, and application message protection. The messages sent and received by normal clients in the course of an MLS session are likewise unchanged. With proper modifications to the MLS Delivery Service, standard MLS clients can -participate in a group with light clients without any modification. +participate in a group with partial clients without any modification. The only modifications this document makes are to the local state stored at -light clients, namely the component of MLS that manages, synchronizes, and +partial clients, namely the component of MLS that manages, synchronizes, and authenticates the public group state. We also defines some "annotations" that -need to be appended to group messages so that they can be processed by light -clients. Light clients effectively run normal MLS algorithms, but with +need to be appended to group messages so that they can be processed by partial +clients. Partial clients effectively run normal MLS algorithms, but with just-in-time delivery of exactly the subset of the public group state needed by -a given algorithm. We achieve lightness due to the fact that aside from initial +a given algorithm. We achieve this property due to the fact that aside from initial tree validation and sending commits, a client only needs log-scale information. -In summary, Light MLS allows light clients to obtain greater efficiency, at the +In summary, Partial MLS allows partial clients to obtain greater efficiency, at the cost of lowering the authentication guarantees they receive and losing the ability to make Commits. We discuss a few scenarios that motivate this trade-off in {{use-cases}}. The difference in authentication properties, in @@ -116,9 +113,9 @@ Membership proof: : A tree slice that proves that a given leaf node is part of a ratchet tree with a given tree hash. -Light client: +Partial client: : An MLS client that does not download, validate, and maintain a copy of the -group's ratchet tree. A light client does not store any public data about the +group's ratchet tree. A partial client does not store any public data about the group's ratchet tree, only the HPKE decryption keys associated to nodes on the client's direct path. @@ -130,12 +127,12 @@ Sender-authenticated message: membership proof that proves the sender's membership in the group. Annotated Welcome: -: A Welcome message together with information that a light client needs to +: A Welcome message together with information that a partial client needs to process it. Annotated Commit: : A Commit message (as a PublicMessage or PrivateMessage) together with -information that a light client needs to process it. +information that a partial client needs to process it. As in MLS, message structures are defined using the TLS presentation syntax {{!RFC8446}}. Unlike most MLS messages, however, these structures are not @@ -144,9 +141,9 @@ applications to encode these structures in application-specific encodings. # Use Cases -Light MLS is intended to support use cases where MLS groups are very large, from +Partial MLS is intended to support use cases where MLS groups are very large, from thousands to millions of participants. Application-level constraints arising -from these use cases align well with the trade-offs introduced by Light MLS. It +from these use cases align well with the trade-offs introduced by Partial MLS. It is usually acceptable (even desirable) that only certain members are able to send Commit messages. And in such large groups, clients often do not care about authenticating all members of the group. @@ -161,15 +158,15 @@ they are admitted to a meeting. With normal MLS, the client is required to download and validate the entire ratchet tree before being able to derive media encryption keys. In meetings with a thousand or more participants, this process can take enough time that it introduces a noticeable delay in joining the -meeting. If a client joins as a light client, then they can download a +meeting. If a client joins as a partial client, then they can download a log-sized AnnotatedWelcome message and immediately obtain the media encryption keys. Such a client will not have authenticated the group when they join the meeting. However, applications often do not display identity information in such setting -anyway. In "webinar" settings, it is common attendee identities to be visible -only to panelists and administrators, not to other attendees. Light MLS allows -MLS to align with this privacy property. If attendees join as light clients, +anyway. In "webinar" settings, it is common for attendee identities to be visible +only to panelists and administrators, not to other attendees. Partial MLS allows +MLS to align with this privacy property. If attendees join as partial clients, they can be provided with membership proofs for attendees whom they are authorized to see, and not for others. Even in settings where attendees can all see each others' identities, user interface constraints usually cause only a @@ -194,7 +191,7 @@ over QUIC Transport protocol, designed to support streaming use cases, states as a goal ensuring that "the media content itself remains opaque and private" from the relays involved in its distribution {{?I-D.ietf-moq-transport}}. -In such settings, the light client / full client roles align with the viewer / +In such settings, the partial client / full client roles align with the viewer / owner roles, respectively. Viewers do not care about the identities of other viewers (at most, they care that the stream comes from an authentic source) and they aren't authorized to do anything in MLS besides join the group. Viewers @@ -204,16 +201,16 @@ authentication and the ability to Commit. # Protocol Overview -A light client does not receive or validate a full copy of the ratchet tree for +A partial client does not receive or validate a full copy of the ratchet tree for a group, but still possesses the group's secrets, including receiving updated -secrets as the group evolves. When MLS messages are sent to a light client, -they need dto be accompanied by annotations that provide the light client with +secrets as the group evolves. When MLS messages are sent to a partial client, +they need to be accompanied by annotations that provide the partial client with just enough of information about the ratchet tree to process the message. These annotations can be computed by any party with knowledge of the group's ratchet tree, including the committer and sometimes the DS. ~~~ aasvg - Full Delivery Light Light Full +Full Delivery Partial Partial Full Client A Service Client B Client C Client D | | | | | | Commit | | | | @@ -244,22 +241,22 @@ Client A Service Client B Client C Client D | +------------------------------------------>| | | | | | ~~~ -{: #fig-overview title="Overview of Light MLS" } +{: #fig-overview title="Overview of Partial MLS" } -{{fig-overview}} illustrates the main changes introduced by Light MLS: +{{fig-overview}} illustrates the main changes introduced by Partial MLS: -1. When a light client is added to the group, they are provided an +1. When a partial client is added to the group, they are provided an AnnotatedWelcome message, which comprises a normal Welcome message plus membership proofs for the sender and joiner. 2. From each Commit that is generated in the group, an individual - AnnotatedCommit is generated for each light client. An AnntatedCommit + AnnotatedCommit is generated for each partial client. An AnntatedCommit comprises a normal MLS Commit message, together with membership proofs and - the information that the light client needs in order to process the update + the information that the partial client needs in order to process the update path in the Commit. 3. When messages are sent in the group, e.g., carrying application data, - they are extended with a membership proofs so that light clients can + they are extended with a membership proofs so that partial clients can authenticate the sender's membership in the group. In this example, we have shown the required annotations being added by the DS. @@ -267,35 +264,35 @@ This allows full clients to behave as they would in normal MLS, but requires that the DS maintain a copy of the group's ratchet tree. It is also possible for committers to generate the required annotated messages. This document does not define who generates annotated messages from the base MLS messages, or how -this entity learns which clients are light or full clients. +this entity learns which clients are partial or full clients. -Light clients still need to be provided with access to any proposals sent in a -group outside of Commits. Light clients cannot process proposals that modify the +Partial clients still need to be provided with access to any proposals sent in a +group outside of Commits. Partial clients cannot process proposals that modify the structure of the tree, in particular Add, Update, or Remove proposals. They can, however, verify that these proposals were included in a given Commit. And they need to see proposals such as PreSharedKey or GroupContextExtensions so that they can update their state appropriately. -Depending on how Light MLS is deployed, a client might need to inform the DS or -other members of its status (light or full), so that the proper annotations can -be generated when it is light. It is harmless for a full client to receive an +Depending on how Partial MLS is deployed, a client might need to inform the DS or +other members of its status (partial or full), so that the proper annotations can +be generated when it is partial. It is harmless for a full client to receive an AnnotatedCommit; the annotations can simply be ignored. # Upgrading and Downgrading -A light client can upgrade to being a full client at any time by downloading the +A partial client can upgrade to being a full client at any time by downloading the full ratchet tree; a full client can downgrade by deleting its local copy of the -ratchet tree. Before a light client uses a copy of the ratchet tree to upgrade +ratchet tree. Before a partial client uses a copy of the ratchet tree to upgrade to being a full client, it MUST verify the integrity of the ratchet tree in the same way it would when joining as a full client, following the steps in {{Section 12.4.3.1 of RFC9420}}. # Membership Proofs and Partial Trees -Although light clients do not have a copy of the group's ratchet tree, they +Although partial clients do not have a copy of the group's ratchet tree, they still agree on the root tree hash of the ratchet tree, via the MLS key schedule as usual. This fact, together with the Merkle-tree-like structure of the MLS -tree hash, allows a light client to verify the legitimacy of partial information +tree hash, allows a partial client to verify the legitimacy of partial information about the ratchet tree. In particular, for any leaf in the tree, anyone in possession of the public data of the ratchet tree can construct a "membership proof" that proves that a leaf node with specific contents is located at a @@ -344,7 +341,7 @@ message with the private key corresponding to the `signature_key` in the leaf node. Full clients verify these messages by looking up the required signature verification key in their local copy of the ratchet tree. -Since light clients do not store the group's ratchet tree, they cannot perform +Since partial clients do not store the group's ratchet tree, they cannot perform this lookup. A SenderAuthenticatedMessage presents a message along with a membership proof for the sender of a message, which provides the required leaf node and a proof of its inclusion in the tree. @@ -388,7 +385,7 @@ Welcome. An AnnotatedWelcome can be generated by any party that knows the group's ratchet tree and the indices of the sender and joiner in the tree. -A light client processes an AnnotatedWelcome in the following way: +A partial client processes an AnnotatedWelcome in the following way: 1. Verify that the `sender_membership_proof` and `joiner_membership_proof` reference the same tree. @@ -410,19 +407,19 @@ A light client processes an AnnotatedWelcome in the following way: # Joining via External Commit -A light client cannot join via an external Commit, because light clients cannot +A partial client cannot join via an external Commit, because partial clients cannot generate commits. A client could, however, join as a full client via an -external commit, then transition to being a light client by deleting its copy of +external commit, then transition to being a partial client by deleting its copy of the tree. This would still require the client to download and validate the tree, but would save the client the effort of maintaining their copy of the tree. # Annotated Commit -There are two main challenges for a light client processing a Commit. First, -the light client cannot compute the resolution of the committer's copath, so +There are two main challenges for a partial client processing a Commit. First, +the partial client cannot compute the resolution of the committer's copath, so they cannot determine which of the HPKECiphertext objects in the UpdatePath they -should decrypt to obtain a path secret. Second, the light client cannot compute +should decrypt to obtain a path secret. Second, the partial client cannot compute the updated tree hash, since they don't have the full tree. An AnnotatedCommit provides these pieces of information, along with proof that the sender and receiver are both still in the group after the Commit. @@ -474,7 +471,7 @@ in the tree. It is safe for the recipient to accept the `tree_hash` supplied by an unauthenticated party because the tree hash is authenticated by the `confirmation_tag` in the Commit. -A light client processes an AnnotatedCommit in the following way: +A partial client processes an AnnotatedCommit in the following way: 1. Verify that the `sender_membership_proof` in the `commit` field, if present, is valid relative to the group's current tree hash. @@ -497,7 +494,7 @@ A light client processes an AnnotatedCommit in the following way: proposal, as normal. In this case, there is no further validation of the `leaf_index` field of of the `sender_membership_proof`. - * The proposal list validation step is omitted, because a light client doesn't + * The proposal list validation step is omitted, because a partial client doesn't have sufficient information to check all of the validation rules. * When applying proposals, only the proposals that do not modify the tree are @@ -537,9 +534,9 @@ A light client processes an AnnotatedCommit in the following way: # Application Messages MLS clients can exchange messages by sending application data within the -PrivateMessage framing. In a group where light clients are present, these +PrivateMessage framing. In a group where partial clients are present, these messages should be further encapsulated in a SenderAuthenticatedMessage, so that -light clients have the membership proof necessary to verify the sender's +partial clients have the membership proof necessary to verify the sender's membership, the public key necessary to verify the message signature, and the credential necessary to verify the sender's identity. @@ -554,33 +551,33 @@ metadata privacy. # Operational Considerations -The major operational challenge in deploying Light MLS is ensuring that light +The major operational challenge in deploying Partial MLS is ensuring that partial clients receive the proper annotations to Welcome and Commit messages. As discussed in {{protocol-overview}}, this is up to the application. Since full clients don't need the annotations, applications will be more robust if they send annotations in a way that they can be cleanly ignored by full clients. -Light MLS substantially reduces the amount of data required to join an MLS +Partial MLS substantially reduces the amount of data required to join an MLS group, since it replaces the linear-scale ratchet tree with two log-scale -membership proofs. Light MLS does not address the potentially linear scaling of -Commit messages; in fact, it makes Commits slightly bigger. There are other +membership proofs. Partial MLS does not address the potentially linear scaling of +Commit messages; in fact, it makes Commits spartially bigger. There are other approaches to reducing Commit sizes, e.g., the SplitCommit approach in {{?I-D.mularczyk-mls-splitmls}}. These approaches can be cleanly integrated -with Light MLS via the AnnotatedCommit structure. {{download-cost}} summarizes +with Partial MLS via the AnnotatedCommit structure. {{download-cost}} summarizes the scaling of the amount of data that a client needs to download in order to perform various MLS operations. Sending a Commit requires linear-scale work in any case. -| Operation | RFC MLS | Light MLS | Split Commits | Light + Split | -|:----------------|:-------:|:---------:|:-------------:|:-------------:| -| Join | O(N) | O(log N) | O(N) | O(log N) | -| Process Commit | O(N) | O(N) | O(log N) | O(log N) | +| Operation | RFC MLS | Partial MLS | Split Commits | Partial + Split | +|:----------------|:-------:|:-----------:|:-------------:|:---------------:| +| Join | O(N) | O(log N) | O(N) | O(log N) | +| Process Commit | O(N) | O(N) | O(log N) | O(log N) | {: #download-cost title="Download scaling under protocol variations" } # 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 +describe the security of Partial 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 @@ -613,51 +610,51 @@ 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 to light clients, a new security +To verify the security guarantees provided to partial clients, a new security analysis was 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=DOI.10.1145/3548606.3560632}}. -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 +Partial MLS preserves the invariants above and thereby all the security goals of +MLS continue to hold at full members. However, a partial 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 +guarantee is weaker on partial clients. Furthermore, since partial 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 +- **Partial Membership Agreement**: If a partial 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 +- **Partial Member Identity Authentication**: If a partial 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 +- **Partial Group Key Secrecy**: If a partial 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. -Note that the Light Membership Agreement property holds irrespective of whether +Note that the Partial Membership Agreement property holds irrespective of whether B has verified a membership proof from A. The membership proofs in this protocol are thus more about providing precise source authentication within the group, rather than simply proving membership in the group. Simply knowing the group's symmetric secrets suffices for the latter. -Another technical caveat is that since light members do not have the full tree, +Another technical caveat is that since partial 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. In a group where full clients are honest, there is no practical difference, since a full client will verify that all of the required uniqness properties hold before issuing a Commit. The main risk is that a malicious full client could cause a -light client to accept a tree hash representing a tree with duplicate keys. +partial client to accept a tree hash representing a tree with duplicate keys. ## Metadata Privacy @@ -671,11 +668,11 @@ normally encrypted as part of the SenderData. It is possible to operate this protocol in a more restrictive mode, where Commits are sent as PrivateMessage objects and the committer generates the -required annotations for any light clients in the group. However, because there +required annotations for any partial clients in the group. However, because there is no confidentiality protection for the annotations, they will leak information to the DS about the ratchet tree. -Fixing this leakage would require changes to logic at the committer and light +Fixing this leakage would require changes to logic at the committer and partial clients. The annotations attached to a Welcome message could be sent as GroupInfo extensions; effectively a partial version of the `ratchet_tree` extension. The annotations attached to a Commit could be moved inside the @@ -698,10 +695,10 @@ This document makes no request of IANA. {{operational-considerations}}, we should define a version of AnnotatedCommit that sends a SplitCommit instead of a normal Commit. -* There is no signaling within the group of whether any members are light +* There is no signaling within the group of whether any members are partial clients, and if so which ones. This was omitted because it didn't seem clearly necessary, but it could be useful. For example, if a client could - include a LeafNode extension that declares that it is a light client, then a + include a LeafNode extension that declares that it is a partial client, then a committer could use this signal to proactively generate AnnotatedCommits for the members. An approach like this might be necessary if we wanted to enable cases where annotations were confidential to the group.