Skip to main content

Light Clients for MLS

Document Type Active Internet-Draft (individual)
Authors Franziskus Kiefer , Karthikeyan Bhargavan , Richard Barnes , Joël , Marta Mularczyk
Last updated 2024-03-04
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                          F. Kiefer
Internet-Draft                                              K. Bhargavan
Intended status: Informational                                   Cryspen
Expires: 5 September 2024                                   R. L. Barnes
                                                                J. Alwen
                                                            M. Mularczyk
                                                               AWS Wickr
                                                            4 March 2024

                         Light Clients for MLS


   The Messaging Layer Security (MLS) protocol provides efficient
   asynchronous 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 cost, especially when joining a

   This document defines Light MLS, an extension that allows for "light
   clients".  A light 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 lower requirements in terms of download,
   memory, and processing.

About This Document

   This note is to be removed before publishing as an RFC.

   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 WG Working Group
   mailing list (, which is archived at

   Source for this draft and an issue tracker can be found at

Kiefer, et al.          Expires 5 September 2024                [Page 1]
Internet-Draft                  Light MLS                     March 2024

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

   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 (
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Open Questions  . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Tree Slices . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Light MLS . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Verifying Group Validity  . . . . . . . . . . . . . . . .  10
       7.1.1.  Joining as a Light Client . . . . . . . . . . . . . .  10
       7.1.2.  Processing a Light Commit . . . . . . . . . . . . . .  10
     7.2.  Light MLS Extension . . . . . . . . . . . . . . . . . . .  11
       7.2.1.  Light MLS LeafNode  . . . . . . . . . . . . . . . . .  12
     7.3.  Committing with a Light Client  . . . . . . . . . . . . .  12
       7.3.1.  Maintaining state . . . . . . . . . . . . . . . . . .  13
   8.  Full Members  . . . . . . . . . . . . . . . . . . . . . . . .  13

Kiefer, et al.          Expires 5 September 2024                [Page 2]
Internet-Draft                  Light MLS                     March 2024

   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  13
     9.1.  Delivery Service Commit Processing  . . . . . . . . . . .  13
     9.2.  How to use Light MLS  . . . . . . . . . . . . . . . . . .  14
     9.3.  Light Messages from the Sender  . . . . . . . . . . . . .  14
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  MLS Wire Formats . . . . . . . . . . . . . . . . . . . .  16
     11.2.  MLS Extension Types  . . . . . . . . . . . . . . . . . .  16
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     12.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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

   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.

Kiefer, et al.          Expires 5 September 2024                [Page 3]
Internet-Draft                  Light MLS                     March 2024

   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

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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

Kiefer, et al.          Expires 5 September 2024                [Page 4]
Internet-Draft                  Light MLS                     March 2024

    Full           Delivery        Light      Light      Light
   Client          Service       Client A   Client B   Client C
     |                |              |          |          |
     | Commit         |              |          |          |
     | GroupInfo      |              |          |          |
     | Welcome        |              |          |          |
     +--------------->| Welcome      |          |          |
     |                +------------->|          |          |
     |                |              |          |          |
     |                | LightCommitB |          |          |
     |                +------------------------>|          |
     |                |              |          |          |
     |                | LightCommitC |          |          |
     |                +----------------------------------->|
     |                |              |          |          |
     |                | TreeSliceB   |          |          |
     |                +------------->|          |          |
     |                |              |          |          |

                      Figure 1: Overview of Light MLS

   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

   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

Kiefer, et al.          Expires 5 September 2024                [Page 5]
Internet-Draft                  Light MLS                     March 2024

   *  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

   *  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)

Kiefer, et al.          Expires 5 September 2024                [Page 6]
Internet-Draft                  Light MLS                     March 2024

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.

                 X = root
          /             \
         X               #
      /     \
     #       X
            / \
           X   #

   0   1   2   3   4   5   6   7

      Figure 2: Tree slice for leaf 2 in an 8-member tree.  For nodes
       with 'X', the full node is included; with '#', only the hash.

Kiefer, et al.          Expires 5 September 2024                [Page 7]
Internet-Draft                  Light MLS                     March 2024

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

   enum {
   } 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.

Kiefer, et al.          Expires 5 September 2024                [Page 8]
Internet-Draft                  Light MLS                     March 2024

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

   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 {
   } 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.

Kiefer, et al.          Expires 5 September 2024                [Page 9]
Internet-Draft                  Light MLS                     March 2024

7.1.  Verifying Group Validity

   A light client can not do all the checks that a client with the MLS
   tree can do.  We therefore update the checks performed on tree
   modifications.  Instead of verifying the MLS tree, light clients
   verify that they are in a group with a certain tree hash value.  In
   particular the validation of commits and welcome packages are
   modified compared to [RFC9420].

7.1.1.  Joining as a Light Client

   When a new member joins the group with a Light Welcome message
   (Section  [RFC9420]) without the ratchet tree extension the
   checks are updated as follows.

   1.  Verify the GroupInfo

       1.  signature

       2.  confirmation tag

       3.  tree hash

   2.  Verify the sender's membership (see Section 6).

   3.  Check the own direct path to the root (see Section 6).

   4.  Do _not_ verify leaves in the tree.

7.1.2.  Processing a Light Commit

   Because the the signature and membership tag on the FramedContent in
   Light Commit messages is broken, these MUST NOT be checked by the

   Instead, the proof of membership in the tree_info is verified for the

   Note that while a light client can check the parent hashes when
   verifying the new group state, it can not verify all points from Sec.
   7.9.2 in [RFC9420].  In particular, the check that "D is in the
   resolution of C, and the intersection of P's unmerged_leaves` with
   the subtree under C is equal to the resolution of C with D removed."
   can not be performed because the light client can not compute the
   resolution.  But this property always holds on correctly generated
   tree, which the light client has to trust, not knowing the MLS tree.

Kiefer, et al.          Expires 5 September 2024               [Page 10]
Internet-Draft                  Light MLS                     March 2024

   Taking the confirmed transcript hash from the GroupInfo, a light
   client checks the confirmation tag.  Otherwise, a Light Commit is
   applied like a regular commit.

   In summary, when a member receives a Light Commit message the checks
   are updated as follows.

   1.  Verify the sender's membership (see Section 6) and leaf node (see
       Section 7.3 [RFC9420]).

   2.  Verify the own path (see Section 6).

   3.  Verify the GroupInfo signature.

   4.  Check the tree hash in the GroupInfo matches the clients own tree

7.2.  Light MLS Extension

   The light_clients group context extension is used to signal that the
   group supports Light MLS clients.

   enum LightClientType {

   struct {
     LightClientType upgrade_policy;
   } LightMlsExtension;

   The extension must be present and set in the required capabilities of
   a group when supporting light clients.  It further defines ways light
   clients may upgrade to a full client.

   *  no_upgrade does not allow light clients to upgrade to full MLS.

   *  resync_upgrade allows light clients to upgrade to full MLS by
      using an external commit.  The resync removes the old client from
      the group and adds a new client with full MLS.

   *  self_upgrade allows light clients to upgrade to full MLS by
      retrieving the full tree from the server.  Together with the
      signed group info of the current epoch the client "silently"

Kiefer, et al.          Expires 5 September 2024               [Page 11]
Internet-Draft                  Light MLS                     March 2024

      upgrades to full MLS with security equivalent to joining a new
      group.  The client MUST perform all checks from Section

   *  any_upgrade allows light clients to use either of the two upgrade

7.2.1.  Light MLS LeafNode

   The light_client leaf node extension signals that a leaf node is a
   light client.  The extension is an empty struct.

   struct {

   } LightMlsClient;

7.3.  Committing with a Light Client

   A light client _cannot commit_ because it doesn't know the necessary
   public keys in the tree to encrypt to.  Therefore, if a light client
   wants to commit, it first has to upgrade to full MLS.  Because a
   light client is not able to fully verify incoming proposals, it MUST
   NOT commit to proposals it received while not holding a full tree.  A
   client that is upgrading to a full MLS tree is therefore considered
   to be a new client that has no knowledge of proposals before it
   joined.  Note that this restriction can not be enforced.  However,
   since each client in [RFC9420] must check the proposals, a
   misbehaving client that upgraded can only successfully commit bogus
   proposals when all other clients and the delivery service agree.

   The light clients extension (Section 7.2) defines the possible
   upgrade paths for light clients.

   In order to ensure that the tree retrieved from the server contains
   the tree slice known to the client, the upgrading client MUST perform
   the following checks:

   *  Verify that the tree hash of the tree slice and the full tree are

   *  Verify that all full nodes (XNode) in the client's state are
      equivalent to the corresponding nodes in the full tree.

   *  Perform all checks on the tree as if joining the group with a
      Welcome message (see Section in [RFC9420]).

   Note that the client already checked the signed group info.

Kiefer, et al.          Expires 5 September 2024               [Page 12]
Internet-Draft                  Light MLS                     March 2024

   To retrieve the full tree, the delivery service must provide an end
   point, equivalent to the one used to retrieve the full tree for a new
   member that wants to join with a commit.

7.3.1.  Maintaining state

   After committing, the client can decide to switch to regular MLS and
   process the full tree as described in [RFC9420].  This will cause the
   client's performance to degrade to the performance of regular MLS,
   but allows it to commit again without the necessity to download the
   full tree again.

   If the client does not expect to commit regularly, only the own tree
   slice should be kept after a commit.

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.

9.1.  Delivery Service Commit Processing

   The delivery service processes Commits for light clients and produces
   LightCommit messages for them.  To do this, the server creates the
   sender and receiver proof of memberships (tree_info), adds the
   group_info of the current epoch, and removes all information from the
   Commit struct that is not needed by the receiver.  In particular,
   only the required UpdatePathNode is kept from the nodes vector, and
   only the HPKECiphertext the receiver can process is kept from the
   encrypted_path_secret vector.  For the receiver to identify the
   decryption key for the ciphertext, the server adds the
   decryption_node_index to the LightCommit.

Kiefer, et al.          Expires 5 September 2024               [Page 13]
Internet-Draft                  Light MLS                     March 2024

9.2.  How to use Light MLS

   Bootstrapping large groups can be particularly costly in MLS.  Light
   MLS can be used to bootstrap large groups before lazily upgrading
   light clients to full clients.  This distributes the load on the
   server and clients.

   Light MLS may also be used on low powered devices that only
   occasionally upgrade to full MLS clients to commit to the group, for
   example when charging.

   Light clients can decide to store the tree slices and build up a tree
   over time when other members commit.  But client may decide to delete
   the sender paths it gets after verifying it's correctness.

9.3.  Light Messages from the Sender

   When the delivery service does not provide the necessary endpoints
   for light messages, the committer can build and end the light commit
   and welcome messages directly.

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:

Kiefer, et al.          Expires 5 September 2024               [Page 14]
Internet-Draft                  Light MLS                     March 2024

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

Kiefer, et al.          Expires 5 September 2024               [Page 15]
Internet-Draft                  Light MLS                     March 2024

   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

11.1.  MLS Wire Formats

            | Value  | Name              | R | Ref           |
            | 0x0006 | mls_light_welcome | - | This Document |
            | 0x0007 | mls_light_commit  | - | This Document |

                    Table 1: MLS Wire Formats Registry

11.2.  MLS Extension Types

        | Value  | Name          | Message(s) | R | Ref           |
        | 0x0006 | light_clients | GC         | - | This Document |

                   Table 2: MLS Extension Types Registry

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

Kiefer, et al.          Expires 5 September 2024               [Page 16]
Internet-Draft                  Light MLS                     March 2024

   [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, <>.

12.2.  Informative References

   [AHKM22]   Alwen, J., Hartmann, D., Kiltz, E., and M. Mularczyk,
              "Server-Aided Continuous Group Key Agreement", ACM,
              Proceedings of the 2022 ACM SIGSAC Conference on Computer
              and Communications Security, DOI 10.1145/3548606.3560632,
              November 2022, <>.


   TODO acknowledge.

Authors' Addresses

   Franziskus Kiefer

   Karthikeyan Bhargavan

   Richard L. Barnes

   Joël Alwen
   AWS Wickr

   Marta Mularczyk
   AWS Wickr

Kiefer, et al.          Expires 5 September 2024               [Page 17]