2.1.Presentation Language

We use the TLS presentation language[RFC8446] to describe the structure ofprotocol messages. In addition to the base syntax, we add two additionalfeatures: the ability for fields to be optional and the ability for vectors tohave variable-size length headers.¶

struct {    uint8 present;    select (present) {        case 0: struct{};        case 1: T value;    };} optional<T>;

struct {    uint32 fixed<0..255>;    opaque variable<V>;} StructWithVectors;

ReadVarint(data):  // The length of variable-length integers is encoded in the  // first two bits of the first byte.  v = data.next_byte()  prefix = v >> 6  if prefix == 3:    raise Exception('invalid variable length integer prefix')  length = 1 << prefix  // Once the length is known, remove these bits and read any  // remaining bytes.  v = v & 0x3f  repeat length-1 times:    v = (v << 8) + data.next_byte()  // Check if the value would fit in half the provided length.  if prefix >= 1 && v < (1 << (8*(length/2) - 2)):    raise Exception('minimum encoding was not used')  return v

3.1.Cryptographic State and Evolution

The cryptographic state at the core of MLS is divided into three areas of responsibility:¶

• Aratchet tree that represents the membership of the group, providing groupmembers a way to authenticate each other and efficiently encrypt messages tosubsets of the group. Each epoch has a distinct ratchet tree. It seeds thekey schedule.¶

• Akey schedule that describes the chain of key derivations used to progress fromepoch to epoch (mainly using theinit_secret andepoch_secret), as well as the derivation ofa variety of other secrets (seeTable 4). For example:¶

  • Anencryption secret that is used to initialize the secret tree for theepoch.¶
  • Anexporter secret that allows other protocols to leverage MLS as ageneric authenticated group key exchange.¶
  • Aresumption secret that members can use to prove their membership in thegroup, e.g., when creating a subgroup or a successor group.¶
• Asecret tree derived from the key schedule that represents shared secretsused by the members of the group for encrypting and authenticating messages.Each epoch has a distinct secret tree.¶

Each member of the group maintains a partial view of these components of the group'sstate. MLS messages are used to initialize these views and keep them in sync asthe group transitions between epochs.¶

Each new epoch is initiated with a Commit message. The Commit instructsexisting members of the group to update their views of the ratchet tree by applyinga set of Proposals, and uses the updated ratchet tree to distribute freshentropy to the group. This fresh entropy is provided only to members in the newepoch and not to members who have been removed. Commits thus maintain the property thatthe epoch secret is confidential to the members in the current epoch.¶

For each Commit that adds one or more members to the group, there are one or more correspondingWelcome messages. Each Welcome message provides new members with the informationthey need to initialize their views of the key schedule and ratchet tree, sothat these views align with the views held by other members of the groupin this epoch.¶

3.2.Example Protocol Execution

There are three major operations in the life of a group:¶

• Adding a member, initiated by a current member;¶
• Updating the keys that represent a member in the tree; and¶
• Removing a member.¶

Each of these operations is "proposed" by sending a message of the correspondingtype (Add / Update / Remove). The state of the group is not changed, however,until a Commit message is sent to provide the group with fresh entropy. In thissection, we show each proposal being committed immediately, but in more advanceddeployment cases, an application might gather several proposals beforecommitting them all at once. In the illustrations below, we show the Proposaland Commit messages directly, while in reality they would be sent encapsulated inPublicMessage or PrivateMessage objects.¶

Before the initialization of a group, clients publish KeyPackages to a directoryprovided by the DS (seeFigure 2).¶

Figure 3 shows how these pre-published KeyPackages are used to create a group.When client A wants to establish a group with clients B and C, it first initializes agroup state containing only itself and downloads KeyPackages for B and C. Foreach member, A generates an Add proposal and a Commit message to add that member and thenbroadcasts the two messages to the group. Client A also generates a Welcome message and sends itdirectly to the new member (there's no need to send it to the group). Only afterA has received its Commit message back from the Delivery Service does it update itsstate to reflect the new member's addition.¶

Once A has updated its state, the new member has processed the Welcome, and anyother group members have processed the Commit, they will all have consistentrepresentations of the group state, including a group secret that is known onlyto the members the group. The new member will be able to read and send newmessages to the group, but messages sent before they were added to the groupwill not be accessible.¶

Subsequent additions of group members proceed in the same way. Anymember of the group can download a KeyPackage for a new client,broadcast Add and Commit messages that the current group will use to updatetheir state, and send a Welcome message that the new client can use toinitialize its state and join the group.¶

To enforce the forward secrecy and post-compromise security of messages, eachmember periodically updates the keys that represent them to the group. A memberdoes this by sending a Commit (possibly with no proposals) or by sending anUpdate message that is committed by another member (seeFigure 4).Once the other members ofthe group have processed these messages, the group's secrets will be unknown toan attacker that had compromised the secrets corresponding to the sender's leaf in the tree.At the end of the scenario shown inFigure 4, the group haspost-compromise security with respect to both A and B.¶

Update messagesSHOULD be sent at regular intervals of time as long as the groupis active, and members that don't updateSHOULD eventually be removed from thegroup. It's left to the application to determine an appropriate amount of timebetween Updates. Since the purpose of sending an Update is to proactivelyconstrain a compromise window, the right frequency is usually on the order ofhours or days, not milliseconds. For example, an application might send anUpdate each time a member sends an application message after receiving anymessage from another member, or daily if no application messages are sent.¶

The MLS architecture recommends that MLS be operated over a secure transport(seeSection 7.1 of [MLS-ARCH]). Such transport protocolswill typically provide functions such as congestion control that manage theimpact of an MLS-using application on other applications sharing the samenetwork. Applications should take care that they do not send MLS messages at arate that will cause problems such as network congestion, especially if they arenot following the above recommendation (e.g., sending MLS directly over UDP instead).¶

Members are removed from the group in a similar way, as shown inFigure 5.Any member of the group can send a Remove proposal followed by aCommit message. The Commit message provides new entropy to all members of thegroup except the removed member. This new entropy is added to the epoch secretfor the new epoch so that it is not known to the removed member.Note that this does not necessarily imply that any memberis actually allowed to evict other members; groups canenforce access control policies on top of thesebasic mechanisms.¶

Note that the flows in this section are examples; applications can arrangemessage flows in other ways. For example:¶

• Welcome messages don't necessarily need to be sent directly to new joiners.Since they are encrypted to new joiners, they could be distributed morebroadly, say if the application only had access to a broadcast channel for thegroup.¶
• Proposal messages don't need to be immediately sent to all group members. They need tobe available to the committer before generating a Commit, and to other members beforeprocessing the Commit.¶
• The sender of a Commit doesn't necessarily have to wait to receive its ownCommit back before advancing its state. It only needs to know that its Commitwill be the next one applied by the group, say based on a promise from anorchestration server.¶

3.3.External Joins

In addition to the Welcome-based flow for adding a new member to the group, itis also possible for a new member to join by means of an "external Commit".This mechanism can be used when the existing members don't have a KeyPackage forthe new member, for example, in the case of an "open" group that can be joinedby new members without asking permission from existing members.¶

Figure 6 shows a typical message flow for an external join. To enablea new member to join the group in this way, a member of the group (A, B)publishes a GroupInfo object that includes the GroupContext for the group aswell as a public key that can be used to encrypt a secret to the existingmembers of the group. When the new member Z wishes to join, they download theGroupInfo object and use it to form a Commit of a special form that adds Z tothe group (as detailed inSection 12.4.3.2). The existingmembers of the group process this external Commit in a similar way to a normalCommit, advancing to a new epoch in which Z is now a member of the group.¶

                                                          GroupA              B              Z          Directory        Channel|              |              |              |              || GroupInfo    |              |              |              |+------------------------------------------->|              ||              |              | GroupInfo    |              ||              |              |<-------------+              ||              |              |              |              ||              |              | Commit(ExtZ) |              ||              |              +---------------------------->||              |              |              | Commit(ExtZ) ||<----------------------------------------------------------+|              |<-------------------------------------------+|              |              |<----------------------------+|              |              |              |              |

3.4.Relationships between Epochs

A group has a single linear sequence of epochs. Groups and epochs are generallyindependent of one another. However, it can sometimes be useful to link epochscryptographically, either within a group or across groups. MLS derives aresumption pre-shared key (PSK) from each epoch to allow entropy extracted fromone epoch to be injected into a future epoch. A group member that wishes toinject a PSK issues a PreSharedKey proposal (Section 12.1.4) describing thePSK to be injected. When this proposal is committed, the corresponding PSK willbe incorporated into the key schedule as described inSection 8.4.¶

Linking epochs in this wayguarantees that members entering the new epoch agree on a key if and only ifthey were members of the group during the epoch from which the resumption keywas extracted.¶

MLS supports two ways to tie a new group to an existing group, which are illustrated inFigures7 and8. Reinitializationcloses one group and creates a new group comprising the same members withdifferent parameters. Branching starts a new group with a subset of the originalgroup's participants (with no effect on the original group). In both cases,the new group is linked to the old group via a resumption PSK.¶

Applications may also choose to use resumption PSKs to link epochs in otherways. For example,Figure 9 shows a case where a resumption PSKfrom epochn is injected into epochn+k. This demonstrates that the membersof the group at epochn+k were also members at epochn, irrespective of anychanges to these members' keys due to Updates or Commits.¶

4.1.Ratchet Tree Terminology

Trees consist ofnodes. A node is aleaf if it has no children; otherwise, it is aparent.All parents in our trees have preciselytwo children, aleft child and aright child. A node is therootof a tree if it has no parent, andintermediate if it has bothchildren and a parent. Thedescendants of a node are that node'schildren, and the descendants of its children. We say a treecontains a node if that node is a descendant of the root of the tree,or if the node itself is the root of the tree. Nodes aresiblings if they share the same parent.¶

Asubtree of a tree is the tree given by any node (thehead of thesubtree) and its descendants. Thesize of a tree or subtree is thenumber of leaf nodes it contains. For a given parent node, itsleftsubtree is the subtree with its left child as head and itsright subtree is the subtree with its right child as head.¶

Every tree used in this protocol is a perfect binary tree, that is, a completebalanced binary tree with 2^d leaves all at the same depthd. Thisstructure is unique for a given depthd.¶

There are multiple ways that an implementation might represent a ratchet tree inmemory. A convenient property of left-balanced binary trees (including thecomplete trees used here) is that they can be represented as an array of nodes,with node relationships computed based on the nodes' indices in the array. Amore traditional representation based on linked node objects may also be used.AppendicesC andD provide some details on how toimplement the tree operations required for MLS in these representations. MLSplaces no requirements on implementations' internal representations of ratchettrees. An implementation may use any tree representation and associatedalgorithms, as long as they produce correct protocol messages.¶

               ...               /              _        ______|______       /             \      X[B]            _    __|__           __|__   /     \         /     \  _       _       Y       _ / \     / \     / \     / \A   B   _   D   E   F   _   H0   1   2   3   4   5   6   7

4.2.Views of a Ratchet Tree

We generally assume that each participant maintains a complete andup-to-date view of the public state of the group's ratchet tree,including the public keys for all nodes and the credentialsassociated with the leaf nodes.¶

No participant in an MLS group knows the private key associated withevery node in the tree. Instead, each member is assigned to a leaf of the tree,which determines the subset of private keys it knows. Thecredential stored at that leaf is one provided by the member.¶

In particular, MLS maintains the members' views of the tree in sucha way as to maintain thetree invariant:¶

The private key for a node in the tree is known to a member of the group only if the node's subtree contains that member's leaf.¶

In other words, if a node is not blank, then it holds a public key.The corresponding private key is known only to members occupyingleaves below that node.¶

The reverse implication is not true: A member may not know the private key ofan intermediate node above them. Such a member has anunmerged leaf at theintermediate node. Encrypting to an intermediate node requires encrypting tothe node's public key, as well as the public keys of all the unmerged leavesbelow it. A leaf is unmerged with regard to all of its ancestors when it isfirst added, because the process of adding the leaf does not give it access tothe private keys for all of the nodes above it in the tree. Leaves are "merged"as they receive the private keys for nodes, as described inSection 7.4.¶

For example, consider a four-member group (A, B, C, D) where the node above theright two members is blank. (This is what it would look like if A created agroup with B, C, and D.) Then the public state of the tree and the views of theprivate keys of the tree held by each participant would be as follows, where_represents a blank node,? represents an unknown private key, andpk(X)represents the public key corresponding to the private keyX:¶

         Public Tree============================            pk(ABCD)          /          \    pk(AB)            _     / \             / \pk(A)   pk(B)   pk(C)   pk(D) Private @ A       Private @ B       Private @ C       Private @ D=============     =============     =============     =============     ABCD              ABCD              ABCD              ABCD    /   \             /   \             /   \             /   \  AB      _         AB      _         ?       _         ?       _ / \     / \       / \     / \       / \     / \       / \     / \A   ?   ?   ?     ?   B   ?   ?     ?   ?   C   ?     ?   ?   ?   D

Note how the tree invariant applies: Each member knows only their own leaf,the private key AB is known only to A and B, and the private key ABCDis known to all four members. This also illustrates another importantpoint: it is possible for there to be "holes" on the path from a member's leafto the root in which the member knows the key both above and belowa given node, but not for that node, as in the case with D.¶

5.1.Cipher Suites

Each MLS session uses a single cipher suite that specifies thefollowing primitives to be used in group key computations:¶

• HPKE parameters:¶

  • A Key Encapsulation Mechanism (KEM)¶
  • A Key Derivation Function (KDF)¶
  • An Authenticated Encryption with Associated Data (AEAD) encryption algorithm¶
• A hash algorithm¶
• A Message Authentication Code (MAC) algorithm¶
• A signature algorithm¶

MLS uses HPKE for public key encryption[RFC9180]. TheDeriveKeyPair function associated to the KEM for the cipher suite maps octetstrings to HPKE key pairs. As in HPKE, MLS assumes that an AEAD algorithmproduces a single ciphertext output from AEAD encryption (aligning with[RFC5116]), as opposed to a separate ciphertext and tag.¶

Cipher suites are represented with the CipherSuite type. The cipher suites aredefined inSection 17.1.¶

opaque HPKEPublicKey<V>;

opaque SignaturePublicKey<V>;

SignWithLabel(SignatureKey, Label, Content) =    Signature.Sign(SignatureKey, SignContent)VerifyWithLabel(VerificationKey, Label, Content, SignatureValue) =    Signature.Verify(VerificationKey, SignContent, SignatureValue)

struct {    opaque label<V>;    opaque content<V>;} SignContent;

label = "MLS 1.0 " + Label;content = Content;

EncryptWithLabel(PublicKey, Label, Context, Plaintext) =  SealBase(PublicKey, EncryptContext, "", Plaintext)DecryptWithLabel(PrivateKey, Label, Context, KEMOutput, Ciphertext) =  OpenBase(KEMOutput, PrivateKey, EncryptContext, "", Ciphertext)

struct {  opaque label<V>;  opaque context<V>;} EncryptContext;

label = "MLS 1.0 " + Label;context = Context;

5.2.Hash-Based Identifiers

Some MLS messages refer to other MLS objects by hash. For example, Welcomemessages refer to KeyPackages for the members being welcomed, and Commits referto Proposals they cover. These identifiers are computed as follows:¶

opaque HashReference<V>;HashReference KeyPackageRef;HashReference ProposalRef;

MakeKeyPackageRef(value)  = RefHash("MLS 1.0 KeyPackage Reference", value)MakeProposalRef(value)  = RefHash("MLS 1.0 Proposal Reference", value)RefHash(label, value) = Hash(RefHashInput)

Where RefHashInput is defined as:¶

struct {  opaque label<V>;  opaque value<V>;} RefHashInput;

And its fields are set to:¶

label = label;value = value;

For a KeyPackageRef, thevalue input is the encoded KeyPackage, and thecipher suite specified in the KeyPackage determines the KDF used. For aProposalRef, thevalue input is the AuthenticatedContent carrying theProposal. In the latter two cases, the KDF is determined by the group'scipher suite.¶

5.3.Credentials

Each member of a group presents a credential that provides one or moreidentities for the member and associates them with the member's signing key.The identities and signing key are verified by the Authentication Service in usefor a group.¶

It is up to the application to decide which identifiers to use atthe application level. For example,a certificate in an X509Credential may attest to several domain names or emailaddresses in its subjectAltName extension. An application may decide topresent all of these to a user, or if it knows a "desired" domain name or emailaddress, it can check that the desired identifier is among those attested.Using the terminology from[RFC6125], a credential provides "presentedidentifiers", and it is up to the application to supply a "reference identifier"for the authenticated client, if any.¶

// See the "MLS Credential Types" IANA registry for valuesuint16 CredentialType;struct {    opaque cert_data<V>;} Certificate;struct {    CredentialType credential_type;    select (Credential.credential_type) {        case basic:            opaque identity<V>;        case x509:            Certificate certificates<V>;    };} Credential;

A "basic" credential is a bare assertion of an identity, without any additionalinformation. The format of the encoded identity is defined by the application.¶

For an X.509 credential, each entry in thecertificates field represents a single DER-encodedX.509 certificate. The chain is ordered such that the first entry (certificates[0]) isthe end-entity certificate. The public key encoded in thesubjectPublicKeyInfo of the end-entity certificateMUST be identical to thesignature_key in the LeafNode containing this credential. A chainMAY omit anynon-leaf certificates that supported peers are known to already possess.¶

opaque application_id<V>;

6.1.Content Authentication

FramedContent is authenticated using the FramedContentAuthData structure.¶

struct {    ProtocolVersion version = mls10;    WireFormat wire_format;    FramedContent content;    select (FramedContentTBS.content.sender.sender_type) {        case member:        case new_member_commit:            GroupContext context;        case external:        case new_member_proposal:            struct{};    };} FramedContentTBS;opaque MAC<V>;struct {    /* SignWithLabel(., "FramedContentTBS", FramedContentTBS) */    opaque signature<V>;    select (FramedContent.content_type) {        case commit:            /*              MAC(confirmation_key,                  GroupContext.confirmed_transcript_hash)            */            MAC confirmation_tag;        case application:        case proposal:            struct{};    };} FramedContentAuthData;

The signature is computed usingSignWithLabel with label"FramedContentTBS" and with a content that covers the message content andthe wire format that will be used for this message. If the sender'ssender_type ismember, the content also covers the GroupContext for thecurrent epoch so that signatures are specific to a given group and epoch.¶

The senderMUST use the private key corresponding to the following signature keydepending on the sender'ssender_type:¶

• member: The signature key contained in the LeafNode at the indexindicated byleaf_index in the ratchet tree.¶
• external: The signature key at the indexindicated bysender_index in theexternal_senders group contextextension (seeSection 12.1.8.1). Thecontent_type of the messageMUST beproposal and theproposal_typeMUST be a value that is allowed for external senders.¶
• new_member_commit: The signature key in the LeafNode in the Commit's path (seeSection 12.4.3.2). Thecontent_type of the messageMUST becommit.¶
• new_member_proposal: The signature key in the LeafNode in the KeyPackage embedded in an external Add proposal. Thecontent_type of the messageMUST beproposal and theproposal_type of the ProposalMUST beadd.¶

Recipients of an MLSMessageMUST verify the signature with the key depending onthesender_type of the sender as described above.¶

The confirmation tag value confirms that the members of the group have arrivedat the same state of the group. A FramedContentAuthData is said to be valid when boththesignature andconfirmation_tag fields are valid.¶

6.2.Encoding and Decoding a Public Message

Messages that are authenticated but not encrypted are encoded using the PublicMessage structure.¶

struct {    FramedContent content;    FramedContentAuthData auth;    select (PublicMessage.content.sender.sender_type) {        case member:            MAC membership_tag;        case external:        case new_member_commit:        case new_member_proposal:            struct{};    };} PublicMessage;

Themembership_tag field in the PublicMessage object authenticates the sender'smembership in the group. For messages sent by members, itMUST be set to thefollowing value:¶

struct {  FramedContentTBS content_tbs;  FramedContentAuthData auth;} AuthenticatedContentTBM;

membership_tag = MAC(membership_key, AuthenticatedContentTBM)

When decoding a PublicMessage into an AuthenticatedContent,the applicationMUST checkmembership_tag andMUST check that theFramedContentAuthData is valid.¶

6.3.Encoding and Decoding a Private Message

Authenticated and encrypted messages are encoded using the PrivateMessage structure.¶

struct {    opaque group_id<V>;    uint64 epoch;    ContentType content_type;    opaque authenticated_data<V>;    opaque encrypted_sender_data<V>;    opaque ciphertext<V>;} PrivateMessage;

encrypted_sender_data andciphertext are encrypted using the AEAD functionspecified by the cipher suite in use, using the SenderDataand PrivateMessageContent structures as input.¶

struct {    select (PrivateMessage.content_type) {        case application:          opaque application_data<V>;        case proposal:          Proposal proposal;        case commit:          Commit commit;    };    FramedContentAuthData auth;    opaque padding[length_of_padding];} PrivateMessageContent;

+-+-+-+-+---------...---+|   Key Schedule Nonce  |+-+-+-+-+---------...---+           XOR+-+-+-+-+---------...---+| Guard |       0       |+-+-+-+-+---------...---+           ===+-+-+-+-+---------...---+| Encrypt/Decrypt Nonce |+-+-+-+-+---------...---+

struct {    opaque group_id<V>;    uint64 epoch;    ContentType content_type;    opaque authenticated_data<V>;} PrivateContentAAD;

struct {    uint32 leaf_index;    uint32 generation;    opaque reuse_guard[4];} SenderData;

ciphertext_sample = ciphertext[0..KDF.Nh-1]sender_data_key = ExpandWithLabel(sender_data_secret, "key",                      ciphertext_sample, AEAD.Nk)sender_data_nonce = ExpandWithLabel(sender_data_secret, "nonce",                      ciphertext_sample, AEAD.Nn)

struct {    opaque group_id<V>;    uint64 epoch;    ContentType content_type;} SenderDataAAD;

7.1.Parent Node Contents

As discussed inSection 4.1.1, the nodes of a ratchet tree containseveral types of data describing individual members (for leaf nodes) orsubgroups of the group (for parent nodes). Parent nodes are simpler:¶

struct {    HPKEPublicKey encryption_key;    opaque parent_hash<V>;    uint32 unmerged_leaves<V>;} ParentNode;

Theencryption_key field contains an HPKE public key whose private key is held onlyby the members at the leaves among its descendants. Theparent_hash fieldcontains a hash of this node's parent node, as described inSection 7.9.Theunmerged_leaves field lists the leaves under this parent node that areunmerged, according to their indices among all the leaves in the tree. Theentries in theunmerged_leaves vectorMUST be sorted in increasing order.¶

7.2.Leaf Node Contents

A leaf node in the tree describes all the details of an individual client'sappearance in the group, signed by that client. It is also used in clientKeyPackage objects to store the information that will be needed to add aclient to a group.¶

enum {    reserved(0),    key_package(1),    update(2),    commit(3),    (255)} LeafNodeSource;struct {    ProtocolVersion versions<V>;    CipherSuite cipher_suites<V>;    ExtensionType extensions<V>;    ProposalType proposals<V>;    CredentialType credentials<V>;} Capabilities;struct {    uint64 not_before;    uint64 not_after;} Lifetime;// See the "MLS Extension Types" IANA registry for valuesuint16 ExtensionType;struct {    ExtensionType extension_type;    opaque extension_data<V>;} Extension;struct {    HPKEPublicKey encryption_key;    SignaturePublicKey signature_key;    Credential credential;    Capabilities capabilities;    LeafNodeSource leaf_node_source;    select (LeafNode.leaf_node_source) {        case key_package:            Lifetime lifetime;        case update:            struct{};        case commit:            opaque parent_hash<V>;    };    Extension extensions<V>;    /* SignWithLabel(., "LeafNodeTBS", LeafNodeTBS) */    opaque signature<V>;} LeafNode;struct {    HPKEPublicKey encryption_key;    SignaturePublicKey signature_key;    Credential credential;    Capabilities capabilities;    LeafNodeSource leaf_node_source;    select (LeafNodeTBS.leaf_node_source) {        case key_package:            Lifetime lifetime;        case update:            struct{};        case commit:            opaque parent_hash<V>;    };    Extension extensions<V>;    select (LeafNodeTBS.leaf_node_source) {        case key_package:            struct{};        case update:            opaque group_id<V>;            uint32 leaf_index;        case commit:            opaque group_id<V>;            uint32 leaf_index;    };} LeafNodeTBS;

Theencryption_key field contains an HPKE public key whose private key is held onlyby the member occupying this leaf (or in the case of a LeafNode in a KeyPackageobject, the issuer of the KeyPackage). Thesignature_key field contains themember's public signing key. Thecredential field contains informationauthenticating both the member's identity and the provided signing key, asdescribed inSection 5.3.¶

Thecapabilities field indicates the protocol features that the clientsupports, including protocol versions, cipher suites, credential types,non-default proposal types, and non-default extension types. The followingproposal and extension types are considered "default" andMUST NOT belisted:¶

• Proposal types:¶

  • 0x0001 -add¶
  • 0x0002 -update¶
  • 0x0003 -remove¶
  • 0x0004 -psk¶
  • 0x0005 -reinit¶
  • 0x0006 -external_init¶
  • 0x0007 -group_context_extensions¶

• Extension types:¶

  • 0x0001 -application_id¶
  • 0x0002 -ratchet_tree¶
  • 0x0003 -required_capabilities¶
  • 0x0004 -external_pub¶
  • 0x0005 -external_senders¶

There are no default values for the other fields of a capabilities object. TheclientMUST list all values for the respective parameters that it supports.¶

The types of any non-default extensions that appear in theextensions field of a LeafNodeMUST be included in theextensions field of thecapabilities field, and thecredential type used in the LeafNodeMUST be included in thecredentials fieldof thecapabilities field.¶

As discussed inSection 13, unknown valuesincapabilitiesMUST be ignored, and the creator of acapabilities fieldSHOULD include some random GREASE values to help ensure that other clients correctlyignore unknown values.¶

Theleaf_node_source field indicates how this LeafNode came to be added to thetree. This signal tells other members of the group whether the leaf node isrequired to have alifetime orparent_hash, and whether thegroup_id isadded as context to the signature.These fields are included selectively because the client creating a LeafNode isnot always able to compute all of them.For example, a KeyPackage is created before the client knows which group it willbe used with, so its signature can't bind to agroup_id.¶

In the case where the leaf was added to the tree based on a pre-publishedKeyPackage, thelifetime field represents the times between which clients willconsider a LeafNode valid. These times are represented as absolute times,measured in seconds since the Unix epoch (1970-01-01T00:00:00Z). ApplicationsMUST define a maximum total lifetime that is acceptable for a LeafNode, andreject any LeafNode where the total lifetime is longer than this duration. Inorder to avoid disagreements about whether a LeafNode has a valid lifetime, theclients in a groupSHOULD maintain time synchronization (e.g., using the NetworkTime Protocol[RFC5905]).¶

In the case where the leaf node was inserted into the tree via a Commit message,theparent_hash field contains the parent hash for this leaf node (seeSection 7.9).¶

The LeafNodeTBS structure covers the fields above the signature in the LeafNode.In addition, when the leaf node was created in the context of a group (theupdate andcommit cases), the group ID of the group is added as context to thesignature.¶

LeafNode objects stored in the group's ratchet treeare updated according to the evolution of the tree. Each modification ofLeafNode contentMUST be reflected by a change in its signature. This allows othermembers to verify the validity of the LeafNode at any time, particularly in thecase of a newcomer joining the group.¶

7.3.Leaf Node Validation

The validity of a LeafNode needs to be verified at the following stages:¶

• When a LeafNode is downloaded in a KeyPackage, before it is usedto add the client to the group¶
• When a LeafNode is received by a group member in an Add, Update, or Commitmessage¶
• When a client validates a ratchet tree, e.g., when joining a group or afterprocessing a Commit¶

The client verifies the validity of a LeafNode using the following steps:¶

• Verify that the credential in the LeafNode is valid, as described inSection 5.3.1.¶
• Verify that the signature on the LeafNode is valid usingsignature_key.¶
• Verify that the LeafNode is compatible with the group's parameters. If theGroupContext has arequired_capabilities extension, then the requiredextensions, proposals, and credential typesMUST be listed in the LeafNode'scapabilities field.¶
• Verify that the credential type is supported by all members of the group, asspecified by thecapabilities field of each member's LeafNode, and that thecapabilities field of this LeafNode indicates support for all the credentialtypes currently in use by other members.¶

• Verify thelifetime field:¶

  • If the LeafNode appears in a message being sent by the client, e.g., aProposal or a Commit, then the clientMUST verify that the current time is withinthe range of thelifetime field.¶
  • If instead the LeafNode appears in a message being received by the client, e.g.,a Proposal, a Commit, or a ratchet tree of the group the client is joining, it isRECOMMENDED that the client verifies that the current time is within the rangeof thelifetime field. (This check is not mandatory because the LeafNodemight have expired in the time between when the message was sent and when itwas received.)¶
• Verify that the extensions in the LeafNode are supported by checking that theID for each extension in theextensions field is listed in thecapabilities.extensions field of the LeafNode.¶

• Verify theleaf_node_source field:¶

  • If the LeafNode appears in a KeyPackage, verify thatleaf_node_source isset tokey_package.¶
  • If the LeafNode appears in an Update proposal, verify thatleaf_node_sourceis set toupdate and thatencryption_key represents a different publickey than theencryption_key in the leaf node being replaced by the Updateproposal.¶
  • If the LeafNode appears in theleaf_node value of the UpdatePath ina Commit, verify thatleaf_node_source is set tocommit.¶

• Verify that the following fields are unique among the members of the group:¶

  • signature_key¶
  • encryption_key¶

7.4.Ratchet Tree Evolution

Whenever a member initiates an epoch change (i.e., commits; seeSection 12.4),they may need to refresh the key pairs of their leaf and of the nodes on theirleaf's direct path in order to maintain forward secrecy and post-compromisesecurity.¶

The member initiating the epoch change generates the fresh key pairs using thefollowing procedure. The procedure is designed in a way that allows group members toefficiently communicate the fresh secret keys to other group members, asdescribed inSection 7.6.¶

A member updates the nodes along its direct path as follows:¶

• Blank all the nodes on the direct path from the leaf to the root.¶
• Generate a fresh HPKE key pair for the leaf.¶
• Generate a sequence of path secrets, one for each node on the leaf's filtered directpath, as follows. In this setting,path_secret[0] refers to the first parent nodein the filtered direct path,path_secret[1] to the second parent node, and so on.¶

path_secret[0] is sampled at randompath_secret[n] = DeriveSecret(path_secret[n-1], "path")

• Compute the sequence of HPKE key pairs(node_priv,node_pub), one for eachnode on the leaf's direct path, as follows.¶

node_secret[n] = DeriveSecret(path_secret[n], "node")node_priv[n], node_pub[n] = KEM.DeriveKeyPair(node_secret[n])

The node secret is derived as a temporary intermediate secret so that eachsecret is only used with one algorithm: The path secret is used as an input toDeriveSecret, and the node secret is used as an input to DeriveKeyPair.¶

For example, suppose there is a group with four members, with C an unmerged leafat Z:¶

If member B subsequently generates an UpdatePath based on a secret"leaf_secret", then it would generate the following sequenceof path secrets:¶

After applying the UpdatePath, the tree will have the following structure:¶

7.5.Synchronizing Views of the Tree

After generating fresh key material and applying it to update theirlocal tree state as described inSection 7.4, thegenerator broadcaststhis update to other members of the group in a Commit message, whoapply it to keep their local views of the tree insync with the sender's. More specifically, when a member commits a change tothe tree (e.g., to add or remove a member), it transmits an UpdatePathcontaining a set of public keys and encrypted path secretsfor intermediate nodes in the filtered direct path of its leaf. Theother members of the group use these values to updatetheir view of the tree, aligning their copy of the tree to thesender's.¶

An UpdatePath containsthe following information for each node in the filtered direct path of thesender's leaf, including the root:¶

• The public key for the node¶
• One or more encrypted copies of the path secret corresponding tothe node¶

The path secret value for a given node is encrypted to the subtreerooted at the parent's non-updated child, i.e., the childon the copath of the sender's leaf node.There is one encryption of the path secret to each public key in the resolutionof the non-updated child.¶

A member of the groupupdates their direct path by computing new values fortheir leaf node and the nodes along their filtered direct path as follows:¶

1. Blank all nodes along the direct path of the sender's leaf.¶

2. Compute updated path secrets and public keys for the nodes on the sender'sfiltered direct path.¶

   • Generate a sequence of path secrets of the same length as the filtereddirect path, as defined inSection 7.4.¶
   • For each node in the filtered direct path, replace the node's public keywith thenode_pub[n] value derived from the corresponding path secretpath_secret[n].¶
3. Compute the new parent hashes for the nodes along the filtered direct pathand the sender's leaf node.¶

4. Update the leaf node for the sender.¶

   • Set theleaf_node_source tocommit.¶
   • Set theencryption_key to the public key of a freshly sampled key pair.¶
   • Set the parent hash to the parent hash for the leaf.¶
   • Re-sign the leaf node with its new contents.¶

Since the new leaf node effectively updates an existing leaf node in the group,itMUST adhere to the same restrictions as LeafNodes used in Update proposals(aside fromleaf_node_source). The applicationMAY specify other changes tothe leaf node, e.g., providing a new signature key, updated capabilities, ordifferent extensions.¶

The member thenencrypts path secrets to the group. For each node in themember's filtered direct path, the member takes the following steps:¶

1. Compute the resolution of the node's child that is on the copath of thesender (the child that is not in the direct path of the sender). Any newmember (from an Add proposal) added in the same CommitMUST be excluded fromthis resolution.¶
2. For each node in the resolution, encrypt the path secret for the directpath node using the public key of the resolution node, as defined inSection 7.6.¶

The recipient of an UpdatePath performs the corresponding steps. First, therecipientmerges UpdatePath into the tree:¶

1. Blank all nodes on the direct path of the sender's leaf.¶

2. For all nodes on the filtered direct path of the sender's leaf,¶

   • Set the public key to the public key in the UpdatePath.¶
   • Set the list of unmerged leaves to the empty list.¶

3. Compute parent hashes for the nodes in the sender's filtered direct path,and verify that theparent_hash field of the leaf node matches the parenthash for the first node in its filtered direct path.¶

   • Note that these hashes are computed from root to leaf, so thateach hash incorporates all the non-blank nodes above it. The root nodealways has a zero-length hash for its parent hash.¶

Second, the recipientdecrypts the path secrets:¶

1. Identify a node in the filtered direct path for which the recipientis in the subtree of the non-updated child.¶
2. Identify a node in the resolution of the copath node forwhich the recipient has a private key.¶
3. Decrypt the path secret for the parent of the copath node usingthe private key from the resolution node.¶
4. Derive path secrets for ancestors of that node in the sender's filtereddirect path using the algorithm described above.¶
5. Derive the node secrets and node key pairs from the path secrets.¶
6. Verify that the derived public keys are the same as the corresponding publickeys sent in the UpdatePath.¶
7. Store the derived private keys in the corresponding ratchet tree nodes.¶

For example, in order to communicate the example update described inSection 7.4, the member at node B would transmit the followingvalues:¶

In this table, the value node_pub[i] represents the public keyderived from node_secret[i], pk(X) represents the current public keyof node X, and E(K, S) representsthe public key encryption of the path secret S to thepublic key K (using HPKE).¶

A recipient at node A would decryptE(pk(A), path_secret\[0\]) to obtainpath_secret\[0\], then use it to derivepath_secret[1] and the resultingnode secrets and key pairs. Thus, A would have the private keys to nodes X'and Y', in accordance with the tree invariant.¶

Similarly, a recipient at node D would decryptE(pk(Z), path_secret[1]) toobtainpath_secret[1], then use it to derive the node secret and key pairfor the node Y'. As required to maintain the tree invariant, node D does notreceive the private key for the node X', since X' is not an ancestor of D.¶

After processing the update, each recipientMUST delete outdated key material,specifically:¶

• The path secrets and node secrets used to derive each updated node key pair.¶
• Each outdated node key pair that was replaced by the update.¶

7.6.Update Paths

As described inSection 12.4, each Commit message may optionally contain anUpdatePath, with a new LeafNode and set of parent nodes for the sender'sfiltered direct path. For each parent node, the UpdatePath contains a newpublic key and encrypted path secret. The parent nodes are kept in the sameorder as the filtered direct path.¶

struct {    opaque kem_output<V>;    opaque ciphertext<V>;} HPKECiphertext;struct {    HPKEPublicKey encryption_key;    HPKECiphertext encrypted_path_secret<V>;} UpdatePathNode;struct {    LeafNode leaf_node;    UpdatePathNode nodes<V>;} UpdatePath;

For each UpdatePathNode, the resolution of the corresponding copath nodeMUSTexclude all new leaf nodes added as part of the current Commit. The length oftheencrypted_path_secret vectorMUST be equal to the length of the resolutionof the copath node (excluding new leaf nodes), with each ciphertext being theencryption to the respective resolution node.¶

The HPKECiphertext values are encrypted and decrypted as follows:¶

(kem_output, ciphertext) =  EncryptWithLabel(node_public_key, "UpdatePathNode",                   group_context, path_secret)path_secret =  DecryptWithLabel(node_private_key, "UpdatePathNode",                   group_context, kem_output, ciphertext)

Herenode_public_key is the public key of the node for which the path secret isencrypted,group_context is the provisional GroupContext object forthe group, and theEncryptWithLabel function is as defined inSection 5.1.3.¶

7.7.Adding and Removing Leaves

In addition to the path-based updates to the tree described above, it is alsonecessary to add and remove leaves of the tree in order to reflect changes tothe membership of the group (see Sections12.1.1 and12.1.3). Since the tree isalways full, adding or removing leaves corresponds to increasing or decreasingthe depth of the tree, resulting in the number of leaves being doubled orhalved. These operations are also known asextending andtruncating thetree.¶

Leaves are always added and removed at the right edge of the tree. When thesize of the tree needs to be increased, a new blank root node is added, whoseleft subtree is the existing tree and right subtree is a new all-blank subtree.This operation is typically done when adding a member to the group.¶

                  _ <-- new blank root                    _                __|__                                   __|__               /     \                                 /     \  X    ===>   X       _ <-- new blank subtree ===>    X       _ / \         / \     / \                             / \     / \A   B       A   B   _   _                           A   B   C   _                                                            ^                                                            |                                               new member --+

When the right subtree of the tree no longer has any non-blank nodes, it can besafely removed. The root of the tree and the right subtree are discarded(whether or not the root node is blank). The left child of the root becomes thenew root node, and the left subtree becomes the new tree. This operation istypically done after removing a member from the group.¶

               Y                  Y             __|__              __|__            /     \            /     \           X       _   ===>   X       _   ==>   X <-- new root          / \     / \        / \     / \       / \         A   B   C   _      A   B   _   _     A   B                 ^                 |removed member --+

Concrete algorithms for these operations on array-based and link-based trees areprovided in AppendicesC andD. The concretealgorithms are non-normative. An implementation may use any algorithm thatproduces the correct tree in its internal representation.¶

7.8.Tree Hashes

MLS hashes the contents of the tree in two ways to authenticate differentproperties of the tree.Tree hashes are defined in this section, andparenthashes are defined inSection 7.9.¶

Each node in a ratchet tree has a tree hash that summarizes the subtree belowthat node. The tree hash of the root is used in the GroupContext to confirmthat the group agrees on the whole tree. Tree hashes are computed recursivelyfrom the leaves up to the root.¶

The tree hash of an individual node is the hash of the node's TreeHashInputobject, which may contain either a LeafNodeHashInput or aParentNodeHashInput depending on the type of node. LeafNodeHashInput objectscontain theleaf_index and the LeafNode (if any). ParentNodeHashInputobjects contain the ParentNode (if any) and the tree hash of the node's leftand right children. For both parent and leaf nodes, the optional node valueMUST be absent if the node is blank and present if the node contains a value.¶

enum {    reserved(0),    leaf(1),    parent(2),    (255)} NodeType;struct {  NodeType node_type;  select (TreeHashInput.node_type) {    case leaf:   LeafNodeHashInput leaf_node;    case parent: ParentNodeHashInput parent_node;  };} TreeHashInput;struct {    uint32 leaf_index;    optional<LeafNode> leaf_node;} LeafNodeHashInput;struct {    optional<ParentNode> parent_node;    opaque left_hash<V>;    opaque right_hash<V>;} ParentNodeHashInput;

The tree hash of an entire tree corresponds to the tree hash of the root node,which is computed recursively by starting at the leaf nodes and building up.¶

7.9.Parent Hashes

While tree hashes summarize the state of a tree at point in time, parent hashescapture information about how keys in the tree were populated.¶

When a client sends a Commit to change a group, it can include an UpdatePath toassign new keys to the nodes along its filtered direct path. When a clientcomputes an UpdatePath (as defined inSection 7.5), itcomputes and signs a parent hash that summarizes the state of the tree after theUpdatePath has been applied. These summaries are constructed in a chain fromthe root to the member's leaf so that the part of the chain closer to the rootcan be overwritten as nodes set in one UpdatePath are reset by a laterUpdatePath.¶

As a result, the signature over the parent hash in each member's leafeffectively signs the subtree of the tree that hasn't been changed since thatleaf was last changed in an UpdatePath. A new member joining the group usesthese parent hashes to verify that the parent nodes in the tree were set bymembers of the group, not chosen by an external attacker. For an example of howthis works, seeAppendix B.¶

Consider a ratchet tree with a non-blank parent node P and children D and S (for"parent", "direct path", and "sibling"), with D and P in the direct path of aleaf node L (for "leaf"):¶

         ...         /        P      __|__     /     \    D       S   / \     / \ ... ... ... ... /L

The parent hash of P changes whenever an UpdatePath object is applied tothe ratchet tree along a path from a leaf L traversing node D (and hence alsoP). The new "Parent hash of P (with copath child S)" is obtained by hashing P'sParentHashInput struct.¶

struct {    HPKEPublicKey encryption_key;    opaque parent_hash<V>;    opaque original_sibling_tree_hash<V>;} ParentHashInput;

The fieldencryption_key contains the HPKE public key of P. If P is the root,then theparent_hash field is set to a zero-length octet string. Otherwise,parent_hash is the parent hash of the next node after P on the filtereddirect path of the leaf L. This way, P's parent hash fixesthe new HPKE public key of each non-blank node on the path from P to the root. Notethat the path from P to the root may contain some blank nodes that are notfixed by P's parent hash. However, for each node that has an HPKE key, this keyis fixed by P's parent hash.¶

Finally,original_sibling_tree_hash is the tree hash of S in the ratchet treemodified as follows: For each leaf L inP.unmerged_leaves, blank L and removeit from theunmerged_leaves sets of all parent nodes.¶

Observe thatoriginal_sibling_tree_hash does not change between updates of P.This property is crucial for the correctness of the protocol.¶

Note thatoriginal_sibling_tree_hash is the tree hash of S, not the parenthash. Theparent_hash field in ParentHashInput captures information about thenodes above P. theoriginal_sibling_tree_hash captures information about thesubtree under S that is not being updated (and thus the subtree to which a pathsecret for P would be encrypted according toSection 7.5).¶

For example, in the following tree:¶

              W [F]        ______|_____       /             \      U               Y [F]    __|__           __|__   /     \         /     \  T       _       _       _ / \     / \     / \     / \A   B   C   D   E   F   G   _

With P = W and S = Y,original_sibling_tree_hash is the tree hash of thefollowing tree:¶

      Y    __|__   /     \  _       _ / \     / \E   _   G   _

BecauseW.unmerged_leaves includes F, F is blanked and removed fromY.unmerged_leaves.¶

Note that no recomputation is needed if the tree hash of S is unchanged sincethe last time P was updated. This is the case for computing or processing aCommit whose UpdatePath traverses P, since the Commit itself resets P. (Inother words, it is only necessary to recompute the original sibling tree hashwhen validating a group's tree on joining.) More generally, if none of the entriesinP.unmerged_leaves are in the subtree under S (and thus no leaves were blanked),then the original tree hash at S is the tree hash of S in the current tree.¶

If it is necessary to recompute the original tree hash of a node, the efficiencyof recomputation can be improved by caching intermediate tree hashes, to avoidrecomputing over the subtree when the subtree is included in multiple parenthashes. A subtree hash can be reused as long as the intersection of theparent's unmerged leaves with the subtree is the same as in the earliercomputation.¶

8.1.Group Context

Each member of the group maintains a GroupContext object thatsummarizes the state of the group:¶

struct {    ProtocolVersion version = mls10;    CipherSuite cipher_suite;    opaque group_id<V>;    uint64 epoch;    opaque tree_hash<V>;    opaque confirmed_transcript_hash<V>;    Extension extensions<V>;} GroupContext;

The fields in this state have the following semantics:¶

• Thecipher_suite is the cipher suite used by the group.¶
• Thegroup_id field is an application-defined identifier for thegroup.¶
• Theepoch field represents the current version of the group.¶
• Thetree_hash field contains a commitment to the contents of thegroup's ratchet tree and the credentials for the members of thegroup, as described inSection 7.8.¶
• Theconfirmed_transcript_hash field contains a running hash overthe messages that led to this state.¶
• Theextensions field contains the details of any protocol extensions thatapply to the group.¶

When a new member is added to the group, an existing member of thegroup provides the new member with a Welcome message. The Welcomemessage provides the information the new member needs to initializeits GroupContext.¶

Different changes to the group will have different effects on the group state.These effects are described in their respective subsections ofSection 12.1.The following general rules apply:¶

• Thegroup_id field is constant.¶
• Theepoch field increments by one for each Commit message thatis processed.¶
• Thetree_hash is updated to represent the current tree andcredentials.¶
• Theconfirmed_transcript_hash field is updated with the data for anAuthenticatedContent encoding a Commit message, as described below.¶
• Theextensions field changes when a GroupContextExtensions proposal iscommitted.¶

8.2.Transcript Hashes

The transcript hashes computed in MLS represent a running hash over all Proposaland Commit messages that have ever been sent in a group. Commit messages areincluded directly. Proposal messages are indirectly included via the Commit thatapplied them. Messages of both types are included by hashing the AuthenticatedContentobject in which they were sent.¶

The transcript hash comprises two individual hashes:¶

• Aconfirmed_transcript_hash that represents a transcript over the wholehistory of Commit messages, up to and including the signature of the mostrecent Commit.¶
• Aninterim_transcript_hash that covers the confirmed transcript hash plustheconfirmation_tag of the most recent Commit.¶

New members compute the interim transcript hash using theconfirmation_tagfield of the GroupInfo struct, while existing members can compute it directly.¶

Each Commit message updates these hashes by way of its enclosingAuthenticatedContent. The AuthenticatedContent struct is split intoConfirmedTranscriptHashInput and InterimTranscriptHashInput. The former is used toupdate the confirmed transcript hash and the latter is used to update the interimtranscript hash.¶

struct {    WireFormat wire_format;    FramedContent content; /* with content_type == commit */    opaque signature<V>;} ConfirmedTranscriptHashInput;struct {    MAC confirmation_tag;} InterimTranscriptHashInput;

confirmed_transcript_hash_[0] = ""; /* zero-length octet string */interim_transcript_hash_[0] = ""; /* zero-length octet string */confirmed_transcript_hash_[epoch] =    Hash(interim_transcript_hash_[epoch - 1] ||        ConfirmedTranscriptHashInput_[epoch]);interim_transcript_hash_[epoch] =    Hash(confirmed_transcript_hash_[epoch] ||        InterimTranscriptHashInput_[epoch]);

In this notation,ConfirmedTranscriptHashInput_[epoch] andInterimTranscriptHashInput_[epoch] are based on the Commit that initiated theepoch with epoch numberepoch. (Note that theepoch field in thisCommit will be set toepoch - 1`, since it is sent within the previous epoch.)¶

The transcript hashConfirmedTranscriptHashInput_[epoch] is used as theconfirmed_transcript_hash input to theconfirmation_tag field for thisCommit. Each Commit thus confirms the whole transcript of Commits up to thatpoint, except for the latest Commit's confirmation tag.¶

8.3.External Initialization

In addition to initializing a new epoch via KDF invocations as described above,an MLS group can also initialize a new epoch via an asymmetric interaction usingthe external key pair for the previous epoch. This is done when a new memberis joining via an external commit.¶

In this process, the joiner sends a newinit_secret value to the group usingthe HPKE export method. The joiner then uses thatinit_secret withinformation provided in the GroupInfo and an external Commit to initializetheir copy of the key schedule for the new epoch.¶

kem_output, context = SetupBaseS(external_pub, "")init_secret = context.export("MLS 1.0 external init secret", KDF.Nh)

Members of the group receive thekem_output in an ExternalInit proposal andperform the corresponding calculation to retrieve theinit_secret value.¶

context = SetupBaseR(kem_output, external_priv, "")init_secret = context.export("MLS 1.0 external init secret", KDF.Nh)

8.4.Pre-Shared Keys

Groups that already have an out-of-band mechanism to generateshared group secrets can inject them into the MLS key schedule toincorporate this external entropy in the computation of MLS group secrets.¶

Injecting an external PSK can improve security in the casewhere having a full run of Updates across members is too expensive, or ifthe external group key establishment mechanism providesstronger security against classical or quantum adversaries.¶

Note that, as a PSK may have a different lifetime than an Update, it does notnecessarily provide the same forward secrecy or post-compromise securityguarantees as a Commit message. Unlike the key pairs populated in thetree by an Update or Commit, which are always freshly generated, PSKs may bepre-distributed and stored. This creates the risk that a PSK may be compromisedin the process of distribution and storage. The security that the group getsfrom injecting a PSK thus depends on both the entropy of the PSK and the risk ofcompromise. These factors are outside of the scope of this document, but they shouldbe considered by application designers relying on PSKs.¶

Each PSK in MLS has a type that designates how it was provisioned.External PSKs are provided by the application, while resumption PSKsare derived from the MLS key schedule and used in cases where it isnecessary to authenticate a member's participation in a prior epoch.¶

The injection of one or more PSKs into the key schedule is signaled in two ways:Existing members are informed via PreSharedKey proposals covered by a Commit,and new members added in the Commit are informed by the GroupSecrets object in theWelcome message corresponding to the Commit. To ensure that existing and newmembers compute the same PSK input to the key schedule, the Commit andGroupSecrets objectsMUST indicate the same set of PSKs, in the same order.¶

enum {  reserved(0),  external(1),  resumption(2),  (255)} PSKType;enum {  reserved(0),  application(1),  reinit(2),  branch(3),  (255)} ResumptionPSKUsage;struct {  PSKType psktype;  select (PreSharedKeyID.psktype) {    case external:      opaque psk_id<V>;    case resumption:      ResumptionPSKUsage usage;      opaque psk_group_id<V>;      uint64 psk_epoch;  };  opaque psk_nonce<V>;} PreSharedKeyID;

Each time a client injects a PSK into a group, thepsk_nonce of itsPreSharedKeyIDMUST be set to a fresh random value of lengthKDF.Nh, whereKDF is the KDF for the cipher suite of the group into which the PSK is beinginjected. This ensures that even when a PSK is used multiple times, the valueused as an input into the key schedule is different each time.¶

Upon receiving a Commit with a PreSharedKey proposal or a GroupSecrets objectwith thepsks field set, the receiving client includes them in the keyschedule in the order listed in the Commit, or in thepsks field, respectively.For resumption PSKs, the PSK is defined as theresumption_psk of the group andepoch specified in the PreSharedKeyID object. Specifically,psk_secret iscomputed as follows:¶

struct {    PreSharedKeyID id;    uint16 index;    uint16 count;} PSKLabel;

psk_extracted_[i] = KDF.Extract(0, psk_[i])psk_input_[i] = ExpandWithLabel(psk_extracted_[i], "derived psk",                  PSKLabel, KDF.Nh)psk_secret_[0] = 0psk_secret_[i] = KDF.Extract(psk_input_[i-1], psk_secret_[i-1])psk_secret     = psk_secret_[n]

Here0 represents the all-zero vector of lengthKDF.Nh. Theindex field inPSKLabel corresponds to the index of the PSK in thepsk array, while thecount field contains the total number of PSKs. In other words, the PSKs arechained together with KDF.Extract invocations (labeled "Extract" for brevityin the diagram), as follows:¶

In particular, if there are no PreSharedKey proposals in a given Commit, thenthe resultingpsk_secret ispsk_secret_[0], the all-zero vector.¶

8.5.Exporters

The main MLS key schedule provides anexporter_secret that canbe used by an application to derive new secrets for use outside of MLS.¶

MLS-Exporter(Label, Context, Length) =       ExpandWithLabel(DeriveSecret(exporter_secret, Label),                         "exported", Hash(Context), Length)

ApplicationsSHOULD provide a unique label toMLS-Exporter thatidentifies the secret's intended purpose. This is to help prevent the samesecret from being generated and used in two different places. To help avoidthe same label being used in different applications, an IANA registry for theselabels has been defined inSection 17.8.¶

The exported values are bound to the group epoch from which theexporter_secret is derived, and hence reflect a particular state ofthe group.¶

It isRECOMMENDED for the application generating exported valuesto refresh those values after a Commit is processed.¶

8.6.Resumption PSK

The main MLS key schedule provides aresumption_psk that is used as a PSKto inject entropy from one epoch into another. This functionality is used in thereinitialization and branching processes described in Sections11.2 and11.3, but it may be used by applications for other purposes.¶

Some uses of resumption PSKs might call for the use of PSKs from historicalepochs. The applicationSHOULD specify an upper limit on the number of pastepochs for which theresumption_psk may be stored.¶

8.7.Epoch Authenticators

The main MLS key schedule provides a per-epochepoch_authenticator. If onemember of the group is being impersonated by an active attacker, theepoch_authenticator computed by their client will differ from those computedby the other group members.¶

This property can be used to construct defenses against impersonation attacksthat are effective even if members' signature keys are compromised. As a trivialexample, if the users of the clients in an MLS group were to meet in person andreliably confirm that their epoch authenticator values were equal (using somesuitable user interface), then each user would be assured that the others werenot being impersonated in the current epoch. As soon as the epoch changed,though, they would need to redo this confirmation. The state of the group wouldhave changed, possibly introducing an attacker.¶

More generally, in order for the members of an MLS group to obtain concreteauthentication protections using theepoch_authenticator, they will need touse it in some secondary protocol (such as the face-to-face protocol above).The details of that protocol will then determine the specific authenticationprotections provided to the MLS group.¶

9.1.Encryption Keys

As described inSection 6, MLS encrypts three differenttypes of information:¶

• Metadata (sender information)¶
• Handshake messages (Proposal and Commit)¶
• Application messages¶

The sender information used to look up the key for content encryption isencrypted with an AEAD where the key and nonce are derived from bothsender_data_secret and a sample of the encrypted message content.¶

For handshake and application messages, a sequence of keys is derived via a"sender ratchet". Each sender has their own sender ratchet, and each step alongthe ratchet is called a "generation".¶

The following figure shows a secret tree for a four-member group, with thehandshake and application ratchets that member D will use for sending and thefirst two application keys and nonces.¶

A sender ratchet starts from a per-sender base secret derived from a SecretTree, as described inSection 9. The base secret initiates a symmetrichash ratchet, which generates a sequence of keys and nonces. The sender uses thej-th key/nonce pair in the sequence to encrypt (using the AEAD) the j-th messagethey send during that epoch. Each key/nonce pairMUST NOT be used to encryptmore than one message.¶

Keys, nonces, and the secrets in ratchets are derived usingDeriveTreeSecret. The context in a given call consists of the current positionin the ratchet.¶

DeriveTreeSecret(Secret, Label, Generation, Length) =    ExpandWithLabel(Secret, Label, Generation, Length)

WhereGeneration is encoded as a big endian uint32.¶

HereAEAD.Nn andAEAD.Nk denote the lengthsin bytes of the nonce and key for the AEAD scheme defined bythe cipher suite.¶

9.2.Deletion Schedule

It is important to delete all security-sensitive values as soon as they areconsumed. A sensitive value S is said to beconsumed if:¶

• S was used to encrypt or (successfully) decrypt a message, or¶
• a key, nonce, or secret derived from S has been consumed. (This goes forvalues derived via DeriveSecret as well as ExpandWithLabel.)¶

Here S may be theinit_secret,commit_secret,epoch_secret, orencryption_secret as well as any secret in a secret tree or one of theratchets.¶

As soon as a group member consumes a value, theyMUST immediately delete(all representations of) that value. This is crucial to ensuringforward secrecy for past messages. MembersMAY keep unconsumed values aroundfor some reasonable amount of time to handle out-of-order message delivery.¶

For example, suppose a group member encrypts or (successfully) decrypts anapplication message using the j-th key and nonce in the ratchet of leaf nodeL in some epoch n. Then, for that member, at least the followingvalues have been consumed andMUST be deleted:¶

• thecommit_secret,joiner_secret,epoch_secret, andencryption_secret ofthat epoch n as well as theinit_secret of the previous epoch n-1,¶
• all node secrets in the secret tree on the path from the root to the leaf withnode L,¶
• the first j secrets in the application data ratchet of node L, and¶
• application_ratchet_nonce_[L]_[j] andapplication_ratchet_key_[L]_[j].¶

Concretely, consider the secret tree shown inFigure 27. ClientA, B, or C would generate the illustrated values on receiving a message from Dwith generation equal to 1, having not received a message with generation 0(e.g., due to out-of-order delivery). In such a case, the following valueswould be consumed:¶

• The key K1 and nonce N1 used to decrypt the message¶
• The application ratchet secrets AR1 and AR0¶
• The tree secrets D, F, and G (recall that G is theencryption_secret for theepoch)¶
• Theepoch_secret,commit_secret,psk_secret, andjoiner_secret for thecurrent epoch¶

Other values may be retained (not consumed):¶

• K0 and N0 for decryption of an out-of-order message with generation 0¶
• AR2 for derivation of further message decryption keys and nonces¶
• HR0 for protection of handshake messages from D¶
• E and C for deriving secrets used by senders A, B, and C¶

10.1.KeyPackage Validation

The validity of a KeyPackage needs to be verified at a few stages:¶

• When a KeyPackage is downloaded by a group member, before it is usedto add the client to the group¶
• When a KeyPackage is received by a group member in an Add message¶

The client verifies the validity of a KeyPackage using the following steps:¶

• Verify that the cipher suite and protocol version of the KeyPackage matchthose in the GroupContext.¶
• Verify that theleaf_node of the KeyPackage is valid for a KeyPackageaccording toSection 7.3.¶
• Verify that the signature on the KeyPackage is valid using the public keyinleaf_node.credential.¶
• Verify that the value ofleaf_node.encryption_key is different from the value oftheinit_key field.¶

11.1.Required Capabilities

The configuration of a group imposes certain requirements on clients in thegroup. At a minimum, all members of the group need to support the cipher suiteand protocol version in use. Additional requirements can be imposed byincluding arequired_capabilities extension in the GroupContext.¶

struct {    ExtensionType extension_types<V>;    ProposalType proposal_types<V>;    CredentialType credential_types<V>;} RequiredCapabilities;

This extension lists the extensions, proposals, and credential types that must be supported byall members of the group. The "default" proposal and extension types defined in thisdocument are assumed to be implemented by all clients, and need not be listed inRequiredCapabilities in order to be safely used. Note that this is not true forcredential types.¶

For new members, support for required capabilities is enforced by existingmembers during the application of Add commits. Existing members should ofcourse be in compliance already. In order to ensure this continues to be thecase even as the group's extensions are updated, a GroupContextExtensionsproposal is deemed invalid if it contains arequired_capabilities extension thatrequires non-default capabilities not supported by all current members.¶

11.2.Reinitialization

A group may be reinitialized by creating a new group with the same membershipand different parameters, and linking it to the old group via a resumption PSK.The members of a group reinitialize it using the following steps:¶

1. A member of the old group sends a ReInit proposal (seeSection 12.1.5).¶
2. A member of the old group sends a Commit covering the ReInit proposal.¶

3. A member of the old group creates an initial Commit that sets up a new groupthat matches the ReInit and sends a Welcome message:¶

   • Theversion,cipher_suite,group_id, andextensions fields of the GroupContext object in the WelcomemessageMUST be the same as the corresponding fields in the ReInitproposal. Theepoch in the Welcome messageMUST be 1.¶
   • The Welcome messageMUST specify a PreSharedKeyID of typeresumption with usagereinit, where thegroup_id field matches the old group and theepochfield indicates the epoch after the Commit covering the ReInit.¶

Note that these three steps may be done by the same group member or differentmembers. For example, if a group member sends a Commit with an inline ReInitproposal (steps 1 and 2) but then goes offline, another group member mayrecreate the group instead. This flexibility avoids situations where a groupgets stuck between steps 2 and 3.¶

Resumption PSKs with usagereinitMUST NOT be used in other contexts. APreSharedKey proposal with typeresumption and usagereinitMUST beconsidered invalid.¶

11.3.Subgroup Branching

A new group can be formed from a subset of an existing group's members, usingthe same parameters as the old group.¶

A member can create a subgroup by performing the following steps:¶

1. Fetch a new KeyPackage for each group member that should be included in thesubgroup.¶
2. Create an initial Commit message that sets up the new group and contains aPreSharedKey proposal of typeresumption with usagebranch. To avoid keyreuse, thepsk_nonce included in the PreSharedKeyID objectMUST be arandomly sampled nonce of lengthKDF.Nh.¶
3. Send the corresponding Welcome message to the subgroup members.¶

A client receiving a Welcome message including a PreSharedKey of typeresumption withusagebranchMUST verify that the new group reflects a subgroup branched fromthe referenced group by checking that:¶

• Theversion andcipher_suite values in the Welcome message are the same asthose used by the old group.¶
• Theepoch in the Welcome messageMUST be 1.¶
• Each LeafNode in a new subgroupMUST match some LeafNode in the originalgroup. In this context, a pair of LeafNodes is said to "match" if theidentifiers presented by their respective credentials are consideredequivalent by the application.¶

Resumption PSKs with usagebranchMUST NOT be used in other contexts. APreSharedKey proposal with typeresumption and usagebranchMUST beconsidered invalid.¶

12.1.Proposals

Proposals are included in a FramedContent by way of a Proposal structurethat indicates their type:¶

// See the "MLS Proposal Types" IANA registry for valuesuint16 ProposalType;struct {    ProposalType proposal_type;    select (Proposal.proposal_type) {        case add:                      Add;        case update:                   Update;        case remove:                   Remove;        case psk:                      PreSharedKey;        case reinit:                   ReInit;        case external_init:            ExternalInit;        case group_context_extensions: GroupContextExtensions;    };} Proposal;

On receiving a FramedContent containing a Proposal, a clientMUST verify thesignature inside FramedContentAuthData and that theepoch field of the enclosingFramedContent is equal to theepoch field of the current GroupContext object.If the verification is successful, then the Proposal should be cached in such a waythat it can be retrieved by hash (as a ProposalOrRef object) in a later Commit message.¶

struct {    KeyPackage key_package;} Add;

struct {    LeafNode leaf_node;} Update;

struct {    uint32 removed;} Remove;

struct {    PreSharedKeyID psk;} PreSharedKey;

struct {    opaque group_id<V>;    ProtocolVersion version;    CipherSuite cipher_suite;    Extension extensions<V>;} ReInit;

struct {  opaque kem_output<V>;} ExternalInit;

struct {  Extension extensions<V>;} GroupContextExtensions;

struct {  SignaturePublicKey signature_key;  Credential credential;} ExternalSender;ExternalSender external_senders<V>;

12.2.Proposal List Validation

A group member creating a Commit and a group member processing a CommitMUST verify that the list of committed proposals is valid using one of the followingprocedures, depending on whether the Commit is external or not. If the list ofproposals is invalid, then the Commit messageMUST be rejected as invalid.¶

For a regular, i.e., not external, Commit, the list is invalid if any of thefollowing occurs:¶

• It contains an individual proposal that is invalid as specified inSection 12.1.¶
• It contains an Update proposal generated by the committer.¶
• It contains a Remove proposal that removes the committer.¶
• It contains multiple Update and/or Remove proposals that apply to the same leaf.If the committer has received multiple such proposals theySHOULD prefer any Removereceived, or the most recent Update if there are no Removes.¶
• It contains multiple Add proposals that contain KeyPackages that represent the sameclient according to the application (for example, identical signature keys).¶
• It contains an Add proposal with a KeyPackage that represents a client alreadyin the group according to the application, unless there is a Remove proposalin the list removing the matching client from the group.¶
• It contains multiple PreSharedKey proposals that reference the same PreSharedKeyID.¶
• It contains multiple GroupContextExtensions proposals.¶
• It contains a ReInit proposal together with any other proposal. If the committer hasreceived other proposals during the epoch, theySHOULD prefer them over theReInit proposal, allowing the ReInit to be resent and applied in a subsequentepoch.¶
• It contains an ExternalInit proposal.¶
• It contains a Proposal with a non-default proposal type that is not supported by somemembers of the group that will process the Commit (i.e., members being addedor removed by the Commit do not need to support the proposal type).¶
• After processing the Commit the ratchet tree is invalid, in particular, if itcontains any leaf node that is invalid according toSection 7.3.¶

An application may extend the above procedure by additional rules, for example,requiring application-level permissions to add members, or rules concerningnon-default proposal types.¶

For an external Commit, the list is valid if it contains only the following proposals(not necessarily in this order):¶

• Exactly one ExternalInit¶
• At most one Remove proposal, with which the joiner removes anold version of themselves. If a Remove proposal is present, then the LeafNode in thepath field of the external CommitMUST meet the same criteria as would the LeafNodein an Update for the removed leaf (seeSection 12.1.2). In particular, thecredentialin the LeafNodeMUST present a set of identifiers that is acceptable to theapplication for the removed participant.¶
• Zero or more PreSharedKey proposals¶
• No other proposals¶

Proposal types defined in the future may make updates to the above validationlogic to incorporate considerations related to proposals of the new type.¶

12.3.Applying a Proposal List

The sections above defining each proposal type describe how each individualproposal is applied. When creating or processing a Commit, a client applies alist of proposals to the ratchet tree and GroupContext. The clientMUST applythe proposals in the list in the following order:¶

• If there is a GroupContextExtensions proposal, replace theextensions fieldof the GroupContext for the group with the contents of the proposal. ThenewextensionsMUST be used when evaluating other proposals in this list. Forexample, if a GroupContextExtensions proposal adds arequired_capabilitiesextension, then any Add proposals need to indicate support for thosecapabilities.¶
• Apply any Update proposals to the ratchet tree, in any order.¶
• Apply any Remove proposals to the ratchet tree, in any order.¶
• Apply any Add proposals to the ratchet tree, in the order they appear in the list.¶
• Look up the PSK secrets for any PreSharedKey proposals, in the order theyappear in the list. These secrets are then used to advance the key schedulelater in Commit processing.¶
• If there is an ExternalInit proposal, use it to derive theinit_secret foruse later in Commit processing.¶
• If there is a ReInit proposal, note its parameters for application later inCommit processing.¶

Proposal types defined in the futureMUST specify how the above steps are to beadjusted to accommodate the application of proposals of the new type.¶

12.4.Commit

A Commit message initiates a new epoch for the group, based on a collection ofProposals. It instructs group members to update their representation of thestate of the group by applying the proposals and advancing the key schedule.¶

Each proposal covered by the Commit is included by a ProposalOrRef value, whichidentifies the proposal to be applied by value or by reference. Commits thatrefer to new Proposals from the committer can be included by value. Commitsfor previously sent proposals from anyone (including the committer) can be sentby reference. Proposals sent by reference are specified by including the hash ofthe AuthenticatedContent object in which the proposal was sent (seeSection 5.2).¶

enum {  reserved(0),  proposal(1),  reference(2),  (255)} ProposalOrRefType;struct {  ProposalOrRefType type;  select (ProposalOrRef.type) {    case proposal:  Proposal proposal;    case reference: ProposalRef reference;  };} ProposalOrRef;struct {    ProposalOrRef proposals<V>;    optional<UpdatePath> path;} Commit;

A group member that has observed one or more valid proposals within an epochMUST senda Commit message before sending application data. This ensures, for example,that any members whose removal was proposed during the epoch are actuallyremoved before any application data is transmitted.¶

A sender and a receiver of a CommitMUST verify that the committed list ofproposals is valid as specified inSection 12.2. A list is invalid if, for example,it includes an Update and a Remove for the same member, or an Add when the sender does not havethe application-level permission to add new users.¶

The sender of a CommitSHOULD include all proposals that it has receivedduring the current epoch that are valid according to the rules for theirproposal types and according to application policy, as long as this results ina valid proposal list.¶

Due to the asynchronous nature of proposals, receivers of a CommitSHOULD NOT enforcethat all valid proposals sent within the current epoch are referenced by the nextCommit. In the event that a valid proposal is omitted from the next Commit, andthat proposal is still valid in the current epoch, the sender of the proposalMAY resend it after updating it to reflect the current epoch.¶

A member of the groupMAY send a Commit that references no proposals at all,which would thus have an emptyproposals vector. Sucha Commit resets the sender's leaf and the nodes along its direct path, andprovides forward secrecy and post-compromise security with regard to the senderof the Commit. An Update proposal can be regarded as a "lazy" version of thisoperation, where only the leaf changes and intermediate nodes are blanked out.¶

By default, thepath field of a CommitMUST be populated. Thepath fieldMAY be omitted if (a) it covers at least one proposal and (b) none of the proposalscovered by the Commit are of "path required" types. A proposal type requires apath if it cannot change the group membership in a way that requires the forwardsecrecy and post-compromise security guarantees that an UpdatePath provides.The only proposal types defined in this document that do not require a path are:¶

• add¶
• psk¶
• reinit¶

New proposal typesMUST state whether they require a path. If any instance of aproposal type requires a path, then the proposal type requires a path. Thisattribute of a proposal type is reflected in the "Path Required" field of the"MLS Proposal Types" registry defined inSection 17.4.¶

Update and Remove proposals are the clearest examples of proposals that requirea path. An UpdatePath is required to evict the removed member or the oldappearance of the updated member.¶

In pseudocode, the logic for validating thepath field of a Commit is asfollows:¶

pathRequiredTypes = [    update,    remove,    external_init,    group_context_extensions]pathRequired = falsefor proposal in commit.proposals:    pathRequired = pathRequired ||                   (proposal.msg_type in pathRequiredTypes)if len(commit.proposals) == 0 || pathRequired:    assert(commit.path != null)

To summarize, a Commit can have three different configurations, with differentuses:¶

1. An "empty" Commit that references no proposals, which updates the committer'scontribution to the group and provides PCS with regard to the committer.¶
2. A "partial" Commit that references proposals that do not require a path, andwhere the path is empty. Such a Commit doesn't provide PCS with regard to thecommitter.¶
3. A "full" Commit that references proposals of any type, which provides FS withregard to any removed members and PCS for the committer and any updatedmembers.¶

struct {    GroupContext group_context;    Extension extensions<V>;    MAC confirmation_tag;    uint32 signer;    /* SignWithLabel(., "GroupInfoTBS", GroupInfoTBS) */    opaque signature<V>;} GroupInfo;

struct {    GroupContext group_context;    Extension extensions<V>;    MAC confirmation_tag;    uint32 signer;} GroupInfoTBS;

struct {  opaque path_secret<V>;} PathSecret;struct {  opaque joiner_secret<V>;  optional<PathSecret> path_secret;  PreSharedKeyID psks<V>;} GroupSecrets;struct {  KeyPackageRef new_member;  HPKECiphertext encrypted_group_secrets;} EncryptedGroupSecrets;struct {  CipherSuite cipher_suite;  EncryptedGroupSecrets secrets<V>;  opaque encrypted_group_info<V>;} Welcome;

encrypted_group_secrets =  EncryptWithLabel(init_key, "Welcome",                   encrypted_group_info, group_secrets)group_secrets =  DecryptWithLabel(init_key_priv, "Welcome",                   encrypted_group_info, kem_output, ciphertext)

welcome_nonce = ExpandWithLabel(welcome_secret, "nonce", "", AEAD.Nn)welcome_key = ExpandWithLabel(welcome_secret, "key", "", AEAD.Nk)

struct {    HPKEPublicKey external_pub;} ExternalPub;

struct {    NodeType node_type;    select (Node.node_type) {        case leaf:   LeafNode leaf_node;        case parent: ParentNode parent_node;    };} Node;optional<Node> ratchet_tree<V>;

# Assuming a class Node that has left and right membersdef subtree_root(nodes):    # If there is only one node in the array, return it    if len(nodes) == 1:        return Node(nodes[0])    # Otherwise, the length of the array MUST be odd    if len(nodes) % 2 == 0:        raise Exception("Malformed node array {}", len(nodes))    # Identify the root of the subtree    d = 0    while (2**(d+1)) < len(nodes):       d += 1    R = 2**d - 1    root = Node(nodes[R])    root.left = subtree_root(nodes[:R])    root.right = subtree_root(nodes[(R+1):])    return root

13.1.Additional Cipher Suites

As discussed inSection 5.1, MLS allows the participants in a group tonegotiate the cryptographic algorithms used within the group. Thisextensibility is important for maintaining the security of the protocol overtime[RFC7696]. It also creates a risk of interoperability failure due toclients not supporting a common cipher suite.¶

The cipher suite registry defined inSection 17.1 attempts to strike abalance on this point. On the one hand, the base policy for the registry isSpecification Required, a fairly low bar designed to avoid the need forstandards work in cases where different ciphers are needed for nicheapplications. On the other hand, there is a higher bar (Standards Action) for ciphers to set theRecommended field in the registry. This higher bar is there in part to ensurethat the interoperability implications of new cipher suites are considered.¶

MLS cipher suites are defined independent of MLS versions, so that in principle,the same cipher suite can be used across versions. Standards work defining newversions of MLS should consider whether it is desirable for the new version tobe compatible with existing cipher suites, or whether the new version should ruleout some cipher suites. For example, a new version could follow the example ofHTTP/2, which restricted the set of allowed TLS ciphers (seeSection 9.2.2 of [RFC9113]).¶

13.2.Proposals

Commit messages do not have an extension field because the set of proposals isextensible. As discussed inSection 12.4, Proposals with a non-default proposaltypeMUST NOT be included in a commit unless the proposal type is supported byall the members of the group that will process the Commit.¶

13.3.Credential Extensibility

In order to ensure that MLS provides meaningful authentication, it is importantthat each member is able to authenticate some identity information for eachother member. Identity information is encoded in Credentials, so this propertyis provided by ensuring that members use compatible credential types.¶

The only types of credential that may be used in a group are those that allmembers of the group support, as specified by thecapabilities field of eachLeafNode in the ratchet tree. An application can introduce new credential typesby choosing an unallocated identifier from the registry inSection 17.5 and indicating support for the credential type inpublished LeafNodes, whether in Update proposals to existing groups orKeyPackages that are added to new groups. Once all members in a group indicatesupport for the credential type, members can start using LeafNodes with the newcredential. Application may enforce that certain credential types always remainsupported by adding arequired_capabilities extension to the group'sGroupContext, which would prevent any member from being added to the group thatdoesn't support them.¶

In future extensions to MLS, it may be useful to allow a member to present morethan one credential. For example, such credentials might present differentattributes attested by different authorities. To be consistent with the generalprinciple stated at the beginning of this section, such an extension would needto ensure that each member can authenticate some identity for each other member.For each pair of members (Alice, Bob), Alice would need to present at least onecredential of a type that Bob supports.¶

13.4.Extensions

This protocol includes a mechanism for negotiating extension parameters similarto the one in TLS[RFC8446]. In TLS, extension negotiation is one-to-one: Theclient offers extensions in its ClientHello message, and the server expressesits choices for the session with extensions in its ServerHello andEncryptedExtensions messages. In MLS, extensions appear in the followingplaces:¶

• In KeyPackages, to describe additional information related to the client¶
• In LeafNodes, to describe additional information about the client or itsparticipation in the group (once in the ratchet tree)¶
• In the GroupInfo, to tell new members of a group what parameters arebeing used by the group, and to provide any additional details required tojoin the group¶
• In the GroupContext object, to ensure that all members of the group have thesame view of the parameters in use¶

In other words, an application can use GroupContext extensions to ensure thatall members of the group agree on a set of parameters. Clients indicate theirsupport for parameters in thecapabilities field of their LeafNode. Newmembers of a group are informed of the group's GroupContext extensions via theextensions field in thegroup_context field of the GroupInfo object. Theextensions field in a GroupInfo object (outside of thegroup_context field)can be used to provide additional parameters to new joiners that are used tojoin the group.¶

This extension mechanism is designed to allow for the secure and forward-compatiblenegotiation of extensions. For this to work, implementationsMUST correctlyhandle extensible fields:¶

• A client that posts a KeyPackageMUST support all parameters advertised init. Otherwise, another client might fail to interoperate by selecting one ofthose parameters.¶
• A client processing a KeyPackage objectMUST ignore all unrecognized valuesin thecapabilities field of the LeafNode and all unknown extensions intheextensions andleaf_node.extensions fields. Otherwise, it could failto interoperate with newer clients.¶
• A client processing a GroupInfo objectMUST ignore all unrecognizedextensions in theextensions field.¶
• Any field containing a list of extensionsMUST NOT have more than oneextension of any given type.¶
• A client adding a new member to a groupMUST verify that the LeafNode for thenew member is compatible with the group's extensions. ThecapabilitiesfieldMUST indicate support for each extension in the GroupContext.¶
• A client joining a groupMUST verify that it supports every extension in theGroupContext for the group. Otherwise, itMUST treat the enclosingGroupInfo message as invalid and not join the group.¶

Note that the latter two requirements mean that all MLS GroupContext extensionsare mandatory, in the sense that an extension in use by the groupMUST besupported by all members of the group.¶

The parameters of a group may be changed by sending a GroupContextExtensionsproposal to enable additional extensions (Section 12.1.7), orby reinitializing the group (Section 11.2).¶

13.5.GREASE

As described inSection 13.4, clients are required to ignore unknown valuesfor certain parameters. To help ensure that other clients implement thisbehavior, a client can follow the "Generate Random Extensions And SustainExtensibility" or GREASE approach described in[RFC8701]. In the context ofMLS, this means that a client generating a KeyPackage, LeafNode, or GroupInfo object includesrandom values in certain fields which would be ignored by acorrectly implemented client processing the message. A client that incorrectlyrejects unknown code points will fail to process such a message, providing asignal to its implementer that the client needs to be fixed.¶

When generating the following fields, an MLS clientSHOULD include a randomselection of values chosen from these GREASE values:¶

• LeafNode.capabilities.cipher_suites¶
• LeafNode.capabilities.extensions¶
• LeafNode.capabilities.proposals¶
• LeafNode.capabilities.credentials¶
• LeafNode.extensions¶
• KeyPackage.extensions¶
• GroupInfo.extensions¶

For the KeyPackage and GroupInfo extensions, theextension_data for GREASEextensionsMAY have any contents selected by the sender, since they will beignored by a correctly implemented receiver. For example, a sender mightpopulate these extensions with a randomly sized amount of random data.¶

Note that any GREASE values added toLeafNode.extensions need to be reflectedinLeafNode.capabilities.extensions, since the LeafNode validation processdescribed inSection 7.3 requires that these two fields beconsistent.¶

GREASE valuesMUST NOT be sent in the following fields, because an unsupportedvalue in one these fields (including a GREASE value) will cause the enclosingmessage to be rejected:¶

• Proposal.proposal_type¶
• Credential.credential_type¶
• GroupContext.extensions¶
• GroupContextExtensions.extensions¶

Values reserved for GREASE have been registered in the variousregistries inSection 17. This prevents conflict between GREASEand real future values. The following values are reserved in each registry:0x0A0A,0x1A1A,0x2A2A,0x3A3A,0x4A4A,0x5A5A,0x6A6A,0x7A7A,0x8A8A,0x9A9A,0xAAAA,0xBABA,0xCACA,0xDADA, and0xEAEA. (Thevalue0xFAFA falls within the private use range.) These valuesMUST onlyappear in the fields listed above, and not, for example, in theproposal_typefield of a Proposal. ClientsMUST NOT implement any special processing rulesfor how to handle these values when receiving them, since this negates theirutility for detecting extensibility failures.¶

GREASE valuesMUST be handled using normal logic for processing unsupportedvalues. When comparing lists of capabilities to identify mutually supportedcapabilities, clientsMUST represent their own capabilities with a listcontaining only the capabilities actually supported, without any GREASE values.In other words, lists including GREASE values are only sent to other clients;representations of a client's own capabilitiesMUST NOT contain GREASE values.¶

15.1.Padding

Application messagesMAY be padded to provide some resistanceagainst traffic analysis techniques over encrypted traffic[CLINIC][HCJ16].While MLS might deliver the same payload less frequently acrossa lot of ciphertexts than traditional web servers, it might still providethe attacker enough information to mount an attack. If Alice asks Bob"When are we going to the movie?", then the answer "Wednesday" could be leakedto an adversary solely by the ciphertext length.¶

The length of thepadding field in PrivateMessageContent can bechosen by the sender at the time of message encryption. Senders may use paddingto reduce the ability of attackers outside the group to infer the size of theencrypted content. Note, however, that the transports used to carry MLSmessages may have maximum message sizes, so padding schemesSHOULD avoidincreasing message size beyond any such limits that exist in a givendeployment scenario.¶

15.2.Restrictions

During each epoch, sendersMUST NOT encrypt more data than permitted by thesecurity bounds of the AEAD scheme used[CFRG-AEAD-LIMITS].¶

Note that each change to the group through a handshake message will also set anewencryption_secret. Hence this changeMUST be applied before encryptingany new application message. This is required both to ensure that any usersremoved from the group can no longer receive messages and to (potentially)recover confidentiality and authenticity for future messages despite a paststate compromise.¶

15.3.Delayed and Reordered Application Messages

Since each application message contains the group identifier, the epoch, and ageneration counter, a client can receive messages out of order. When messagesare received out of order, the client moves the sender ratchet forward to matchthe received generation counter. Any unused nonce and key pairs from the ratchetare potentially stored so that they can be used to decrypt the messages thatwere delayed or reordered.¶

ApplicationsSHOULD define a policy on how long to keep unused nonce and keypairs for a sender, and the maximum number to keep. This is in addition toensuring that these secrets are deleted according to the deletion scheduledefined inSection 9.2. ApplicationsSHOULD also define a policylimiting the maximum number of steps that clients will move the ratchet forwardin response to a new message. Messages received with a generation counterthat is too much higher than the last message received would then be rejected.This avoids causing a denial-of-service attack by requiring the recipient toperform an excessive number of key derivations. For example, a malicious groupmember could send a message withgeneration = 0xffffffff at the beginning of anew epoch, forcing recipients to perform billions of key derivations unless theyapply limits of the type discussed above.¶

16.1.Transport Security

Because MLS messages are protected at the message level, theconfidentiality and integrity of the group state do not depend onthose messages being protected in transit. However, an attacker whocan observe those messages in transit will be able to learn about thegroup state, including potentially the group membership (seeSection 16.4.3 below). Such an attacker might also be able tomount denial-of-service attacks on the group or exclude new members byselectively removing messages in transit. In order to prevent thisform of attack, it isRECOMMENDED that all MLS messages be carriedover a secure transport such as TLS[RFC8446] or QUIC[RFC9000].¶

16.2.Confidentiality of Group Secrets

Group secrets are partly derived from the output of a ratchet tree. Ratchettrees work by assigning each member of the group to a leaf in the tree andmaintaining the following property: the private key of a node in the tree isknown only to members of the group that are assigned a leaf in the node'ssubtree. This is called thetree invariant, and it makes it possible toencrypt to all group members except one, with a number of ciphertexts that islogarithmic in the number of group members.¶

The ability to efficiently encrypt to all members except one allows members tobe securely removed from a group. It also allows a member to rotate theirkey pair such that the old private key can no longer be used to decrypt newmessages.¶

16.3.Confidentiality of Sender Data

The PrivateMessage framing encrypts "sender data" that identifies which groupmember sent an encrypted message, as described inSection 6.3.2.As with the QUIC header protection scheme[RFC9001],Section 5.4, this schemeis a variant of the HN1 construction analyzed in[NAN]. A sample of theciphertext is combined with asender_data_secret to derive a key and noncethat are used for AEAD encryption of the sender data.¶

(key, nonce) = PRF(sender_data_secret, sample)encrypted_sender_data =  AEAD.Seal(key, nonce, sender_data_aad, sender_data)

The only differences between this construction and HN1 as described in[NAN]are that it (1) uses authenticated encryption instead of unauthenticatedencryption and (2) protects information used to derive a nonce instead of thenonce itself.¶

Since thesender_data_secret is distinct from the content encryption key, itfollows that the sender data encryption scheme achieves AE2 security as definedin[NAN], and therefore guarantees the confidentiality of the sender data.¶

Use of the samesender_data_secret and ciphertext sample more than once riskscompromising sender data protection by reusing an AEAD (key, nonce) pair. Forexample, in many AEAD schemes, reusing a key and nonce reveals the exclusive ORof the two plaintexts. Assuming the ciphertext output of the AEAD algorithm isindistinguishable from random data (i.e., the AEAD is AE1-secure in the phrasingof[NAN]), the odds of two ciphertext samples being identical is roughly2^-L/2, i.e., the birthday bound.¶

The AEAD algorithms for cipher suites defined in this document all provide thisproperty. The size of the sample depends on the cipher suite's hash function, butin all cases, the probability of collision is no more than 2^-128.Any future cipher suiteMUST use an AE1-secure AEAD algorithm.¶

16.4.Confidentiality of Group Metadata

MLS does not provide confidentiality protection to some messages and fieldswithin messages:¶

• KeyPackage messages¶
• GroupInfo messages¶
• The unencrypted portion of a Welcome message¶
• Any Proposal or Commit messages sent as PublicMessage messages¶
• The unencrypted header fields in PrivateMessage messages¶
• The lengths of encrypted Welcome and PrivateMessage messages¶

The only mechanism MLS provides for confidentially distributing a group'sratchet tree to new members is to send it in a Welcome message as aratchet_tree extension. If an application distributes the tree in some otherway, its security will depend on that application mechanism.¶

A party observing these fields might be able to infer certain properties of thegroup:¶

• Group ID¶
• Current epoch and frequency of epoch changes¶
• Frequency of messages within an epoch¶
• Group extensions¶
• Group membership¶

The amount of metadata exposed to parties outside the group, and thus theability of these parties to infer the group's properties, depends on severalaspects of the DS design, such as:¶

• How KeyPackages are distributed¶
• How the ratchet tree is distributed¶
• How prospective external joiners get a GroupInfo object for the group¶
• Whether Proposal and Commit messages are sent as PublicMessage or PrivateMessage¶

In the remainder of this section, we note the ways that the above properties ofthe group are reflected in unprotected group messages, as a guide tounderstanding how they might be exposed or protected in a given application.¶

16.5.Authentication

The first form of authentication we provide is that group members can verify amessage originated from one of the members of the group. For encrypted messages,this is guaranteed because messages are encrypted with an AEAD under a keyderived from the group secrets. For plaintext messages, this is guaranteed bythe use of amembership_tag, which constitutes a MAC over the message, under akey derived from the group secrets.¶

The second form of authentication is that group members can verify a messageoriginated from a particular member of the group. This is guaranteed by adigital signature on each message from the sender's signature key.¶

The signature keys held by group members are critical to the security of MLSagainst active attacks. If a member's signature key is compromised, then anattacker can create LeafNodes and KeyPackages impersonating the member; depending on theapplication, this can then allow the attacker to join the group with thecompromised member's identity. For example, if a group has enabled externalparties to join via external commits, then an attacker that has compromised amember's signature key could use an external Commit to insert themselves intothe group -- even using a "resync"-style external Commit to replace thecompromised member in the group.¶

Applications can mitigate the risks of signature key compromise using pre-sharedkeys. If a group requires joiners to know a PSK in addition to authenticatingwith a credential, then in order to mount an impersonation attack, the attackerwould need to compromise the relevant PSK as well as the victim's signature key.The cost of this mitigation is that the application needs some externalarrangement that ensures that the legitimate members of the group have therequired PSKs.¶

16.6.Forward Secrecy and Post-Compromise Security

Forward secrecy and post-compromise security are important security notions forlong-lived MLS groups. Forward secrecy means that messages sent at a certainpoint in time are secure in the face of later compromise of a group member.Post-compromise security means that messages are secure even if a group memberwas compromised at some point in the past.¶

Post-compromise security is provided between epochs by membersregularly updating their leaf key in the ratchet tree. Updating theirleaf key prevents group secrets from continuing to be encrypted topublic keys whose private keys had previously been compromised. Notethat sending an Update proposal does not achieve PCS until anothermember includes it in a Commit. Members can achieve immediate PCS bysending their own Commit and populating thepath field, as describedinSection 12.4. To be clear, in all these cases, the PCS guaranteescome into effect when the members of the group process the relevantCommit, not when the sender creates it.¶

Forward secrecy between epochs is provided by deleting private keys from pastversions of the ratchet tree, as this prevents old group secrets from beingre-derived. Forward secrecywithin an epoch is provided by deleting messageencryption keys once they've been used to encrypt or decrypt a message.Note that group secrets and message encryption keys are shared by thegroup. There is thus a risk to forward secrecy as long as anymember has not deleted these keys. This is a particular risk if a memberis offline for a long period of time. ApplicationsSHOULD have mechanismsfor evicting group members that are offline for too long (i.e., havenot changed their key within some period).¶

New groups are also at risk of using previously compromised keys (as withpost-compromise security) if a member is added to a new group via an oldKeyPackage whose corresponding private key has been compromised. This risk canbe mitigated by having clients regularly generate new KeyPackages and uploadthem to the Delivery Service. This way, the key material used to add a memberto a new group is more likely to be fresh and less likely to be compromised.¶

16.7.Uniqueness of Ratchet Tree Key Pairs

The encryption and signature keys stored in theencryption_key andsignature_key fields of ratchet tree nodesMUST be distinct from one another.If two members' leaf nodes have the same signature key, for example, then thedata origin authentication properties afforded by signatures within the groupare degraded.¶

Uniqueness of keys in leaf nodes is assured by explicitly checking each leaf nodeas it is added to the tree, whether in an Add proposal, in an Update proposal, or in thepath field of aCommit. Details can be found in Sections7.3,12.2, and12.4.2. Uniqueness ofencryption keys in parent nodes is assured by checking that the keys in anUpdatePath are not found elsewhere in the tree (seeSection 12.4.2).¶

16.8.KeyPackage Reuse

KeyPackages are intended to be used only once. That is, once a KeyPackagehas been used to introduce the corresponding client to a group, itSHOULD bedeleted from the KeyPackage publication system. Reuse of KeyPackages can leadto replay attacks.¶

An applicationMAY allow for reuse of a "last resort" KeyPackage in order toprevent denial-of-service attacks. Since a KeyPackage is needed to add aclient to a new group, an attacker could prevent a client from being added to newgroups by exhausting all available KeyPackages. To prevent such a denial-of-serviceattack, the KeyPackage publication systemSHOULD rate-limit KeyPackagerequests, especially if not authenticated.¶

16.9.Delivery Service Compromise

MLS is designed to protect the confidentiality and integrity ofthe group data even in the face of a compromised DS. However, a compromisedDS can still mount some attacks. While it cannot forge messages,it can selectively delay or remove them. In some cases, this can beobserved by detecting gaps in the per-sender generation counter,though it may not always be possible to distinguish an attack from messageloss. In addition, the DS can permanently block messages to and froma group member. This will not always be detectable by other members.If an application uses the DS to resolve conflicts betweensimultaneous Commits (seeSection 14), it is also possible for theDS to influence which Commit is applied, even to the point ofpreventing a member from ever having its Commits applied.¶

When put together, these abilities potentially allow a DS to colludewith an attacker who has compromised a member's state to defeat PCS bysuppressing the valid Update and Commit messages from the member thatwould lock out the attacker and update the member's leaf to a new,uncompromised state. Aside from the SenderData.generation value, MLSleaves loss detection up to the application.¶

16.10.Authentication Service Compromise

Authentication Service compromise is much more serious than compromiseof the Delivery Service. A compromised AS can assert a binding for asignature key and identity pair of its choice, thus allowingimpersonation of a given user. This ability is sufficient to allow theAS to join new groups as if it were that user. Depending on theapplication architecture, it may also be sufficient to allow thecompromised AS to join the group as an existing user, for instance, asif it were a new device associated with the same user. Ifthe application uses a transparency mechanism such as CONIKS[CONIKS] or Key Transparency[KT], then it may be possible for endusers to detect this kind of misbehavior by the AS. It is also possible toconstruct schemes in which the various clients owned by a user vouchfor each other, e.g., by signing each others' keys.¶

16.11.Additional Policy Enforcement

The DS and AS may also apply additional policies to MLS operations to obtainadditional security properties. For example, MLS enables any participant to addor remove members of a group; a DS could enforce a policy that only certainmembers are allowed to perform these operations. MLS authenticates all membersof a group; a DS could help ensure that only clients with certain types ofcredentials are admitted. MLS provides no inherent protection against denial ofservice; a DS could also enforce rate limits in order to mitigatethese risks.¶

16.12.Group Fragmentation by Malicious Insiders

It is possible for a malicious member of a group to "fragment" the group bycrafting an invalid UpdatePath. Recall that an UpdatePath encrypts a sequenceof path secrets to different subtrees of the group's ratchet trees. These pathsecrets should be derived in a sequence as described inSection 7.4, but the UpdatePath syntax allows the sender toencrypt arbitrary, unrelated secrets. The syntax also does not guarantee thatthe encrypted path secret for a given node corresponds to the publickey provided for that node.¶

Both of these types of corruption will cause processing of a Commit to fail forsome members of the group. If the public key for a node does not match the pathsecret, then the members that decrypt that path secret will reject the Commitbased on this mismatch. If the path secret sequence is incorrect at some point,then members that can decrypt nodes before that point will compute a differentpublic key for the mismatched node than the one in the UpdatePath, which alsocauses the Commit to fail. ApplicationsSHOULD provide mechanisms for failedcommits to be reported, so that group members who were not able to recognize theerror themselves can reinitialize the group if necessary.¶

Even with such an error reporting mechanism in place, however, it is stillpossible for members to get locked out of the group by a malformed Commit.Since malformed Commits can only be recognized by certain members of the group,in an asynchronous application, it may be the case that all members that coulddetect a fault in a Commit are offline. In such a case, the Commit will beaccepted by the group, and the resulting state will possibly be used as the basis forfurther Commits. When the affected members come back online, they will rejectthe first Commit, and thus be unable to catch up with the group. These memberswill need to either add themselves back with an external Commit or reinitializethe group from scratch.¶

Applications can address this risk by requiring certain members of the group toacknowledge successful processing of a Commit before the group regards theCommit as accepted. The minimum set of acknowledgements necessary to verifythat a Commit is well-formed comprises an acknowledgement from one member pernode in the UpdatePath, that is, one member from each subtree rooted in thecopath node corresponding to the node in the UpdatePath. MLS does notprovide a built-in mechanism for such acknowledgements, but they canbe added at the application layer.¶

17.1.MLS Cipher Suites

A cipher suite is a combination of a protocol version and the set ofcryptographic algorithms that should be used.¶

Cipher suite names follow the naming convention:¶

CipherSuite MLS_LVL_KEM_AEAD_HASH_SIG = VALUE;

Where VALUE is represented as a 16-bit integer:¶

uint16 CipherSuite;

The columns in the registry are as follows:¶

• Value: The numeric value of the cipher suite¶
• Name: The name of the cipher suite¶

• Recommended: Whether support for this cipher suite is recommended by the IETF.Valid values are "Y", "N", and "D", as described below. The defaultvalue of the "Recommended" column is "N". Setting the Recommended item to "Y"or "D", or changing an item whose current value is "Y" or "D", requiresStandards Action[RFC8126].¶

  • Y: Indicates that the IETF has consensus that the item isRECOMMENDED. Thisonly means that the associated mechanism is fit for the purpose for which itwas defined. Careful reading of the documentation for the mechanism isnecessary to understand the applicability of that mechanism. The IETF couldrecommend mechanisms that have limited applicability, but it will provideapplicability statements that describe any limitations of the mechanism ornecessary constraints on its use.¶
  • N: Indicates that the item has not been evaluated by the IETF and that theIETF has made no statement about the suitability of the associatedmechanism. This does not necessarily mean that the mechanism is flawed, onlythat no consensus exists. The IETF might have consensus to leave an itemmarked as "N" on the basis of it having limited applicability or usageconstraints.¶
  • D: Indicates that the item is discouraged andSHOULD NOT orMUST NOT beused. This marking could be used to identify mechanisms that might result inproblems if they are used, such as a weak cryptographic algorithm or amechanism that might cause interoperability problems in deployment.¶
• Reference: The document where this cipher suite is defined¶

Initial contents:¶

All of the non-GREASE cipher suites use HMAC[RFC2104] as their MAC function, withdifferent hashes per cipher suite. The mapping of cipher suites to HPKEprimitives[RFC9180], HMAC hash functions, and TLS signature schemes[RFC8446] is as follows:¶

The hash used for the MLS transcript hash is the one referenced in thecipher suite name. In the cipher suites defined above, "SHA256", "SHA384", and"SHA512" refer, respectively, to the SHA-256, SHA-384, and SHA-512 functionsdefined in[SHS].¶

In addition to the general requirements ofSection 13.1, futurecipher suitesMUST meet the requirements ofSection 16.3.¶

It is advisable to keep the number of cipher suites low to increase the likelihoodthat clients can interoperate in a federated environment. The cipher suites thereforeinclude only modern, yet well-established algorithms. Depending on theirrequirements, clients can choose between two security levels (roughly 128-bitand 256-bit). Within the security levels, clients can choose between fasterX25519/X448 curves and curves compliant with FIPS 140-2 for Diffie-Hellman keynegotiations. Clients may also choose ChaCha20Poly1305 or AES-GCM, e.g., forperformance reasons. Since ChaCha20Poly1305 is not listed by FIPS 140-2, it isnot paired with curves compliant with FIPS 140-2. The security level of symmetricencryption algorithms and hash functions is paired with the security level ofthe curves.¶

The mandatory-to-implement cipher suite for MLS 1.0 isMLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519, which usesCurve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, andEd25519 for signatures. MLS clientsMUST implement this cipher suite.¶

17.2.MLS Wire Formats

The "MLS Wire Formats" registry lists identifiers for the types of messages that can be sent inMLS. The wire format field is two bytes wide, so the valid wire format valuesare in the range 0x0000 to 0xFFFF.¶

Template:¶

• Value: The numeric value of the wire format¶
• Name: The name of the wire format¶
• Recommended: Same as inSection 17.1¶
• Reference: The document where this wire format is defined¶

Initial contents:¶

17.3.MLS Extension Types

The "MLS Extension Types" registry lists identifiers for extensions to the MLS protocol. Theextension type field is two bytes wide, so valid extension type values are inthe range 0x0000 to 0xFFFF.¶

Template:¶

• Value: The numeric value of the extension type¶
• Name: The name of the extension type¶

• Message(s): The messages in which the extension may appear, drawn from the followinglist:¶

  • KP: KeyPackage objects¶
  • LN: LeafNode objects¶
  • GC: GroupContext objects¶
  • GI: GroupInfo objects¶
• Recommended: Same as inSection 17.1¶
• Reference: The document where this extension is defined¶

Initial contents:¶

17.4.MLS Proposal Types

The "MLS Proposal Types" registry lists identifiers for types of proposals that can be made forchanges to an MLS group. The extension type field is two bytes wide, so validextension type values are in the range 0x0000 to 0xFFFF.¶

Template:¶

• Value: The numeric value of the proposal type¶
• Name: The name of the proposal type¶
• Recommended: Same as inSection 17.1¶
• External: Whether a proposal of this type may be sent by anexternal sender(seeSection 12.1.8)¶
• Path Required: Whether a Commit covering a proposal of this type is requiredto have itspath field populated (seeSection 12.4)¶
• Reference: The document where this extension is defined¶

Initial contents:¶

17.5.MLS Credential Types

The "MLS Credential Types" registry lists identifiers for types of credentials that can be used forauthentication in the MLS protocol. The credential type field is two bytes wide,so valid credential type values are in the range 0x0000 to 0xFFFF.¶

Template:¶

• Value: The numeric value of the credential type¶
• Name: The name of the credential type¶
• Recommended: Same as inSection 17.1¶
• Reference: The document where this credential is defined¶

Initial contents:¶

17.6.MLS Signature Labels

TheSignWithLabel function defined inSection 5.1.2 avoids the risk ofconfusion between signatures in different contexts. Each context is assigned adistinct label that is incorporated into the signature. The "MLS Signature Labels" registry recordsthe labels defined in this document and allows additional labels to beregistered in case extensions add other types of signatures using the samesignature keys used elsewhere in MLS.¶

Template:¶

• Label: The string to be used as theLabel parameter toSignWithLabel¶
• Recommended: Same as inSection 17.1¶
• Reference: The document where this label is defined¶

Initial contents:¶

17.7.MLS Public Key Encryption Labels

TheEncryptWithLabel function defined inSection 5.1.3 avoids therisk of confusion between ciphertexts produced for different purposes indifferent contexts. Each context is assigned a distinct label that isincorporated into the signature. The "MLS Public Key Encryption Labels" registry records the labels defined inthis document and allows additional labels to be registered in case extensionsadd other types of public key encryption using the same HPKE keys used elsewherein MLS.¶

Template:¶

• Label: The string to be used as theLabel parameter toEncryptWithLabel¶
• Recommended: Same as inSection 17.1¶
• Reference: The document where this label is defined¶

Initial contents:¶

17.8.MLS Exporter Labels

The exporter function defined inSection 8.5 allows applications to derive keymaterial from the MLS key schedule. Like the TLS exporter[RFC8446], the MLSexporter uses a label to distinguish between different applications' use of theexporter. The "MLS Exporter Labels" registry allows applications to register their usage to avoidcollisions.¶

Template:¶

• Label: The string to be used as theLabel parameter toMLS-Exporter¶
• Recommended: Same as inSection 17.1¶
• Reference: The document where this label is defined¶

The registry has no initial contents, since it is intended to be used byapplications, not the core protocol. The table below is intended only to showthe column layout of the registry.¶

17.9.MLS Designated Expert Pool

Specification Required[RFC8126] registry requests are registeredafter a three-week review period on the MLS Designated Expert (DE) mailing list<mailto:mls-reg-review@ietf.org> on the advice of one or more of the MLS DEs. However,to allow for the allocation of values prior to publication, the MLSDEs may approve registration once they are satisfied that such aspecification will be published.¶

Registration requests sent to the MLS DEs' mailing list for reviewSHOULD use an appropriate subject (e.g., "Request to register valuein MLS Bar registry").¶

Within the review period, the MLS DEs will either approve or denythe registration request, communicating this decision to the MLS DEs'mailing list and IANA. DenialsSHOULD include an explanation and, ifapplicable, suggestions as to how to make the request successful.Registration requests that are undetermined for a period longer than21 days can be brought to the IESG's attention for resolution usingthe<mailto:iesg@ietf.org> mailing list.¶

Criteria thatSHOULD be applied by the MLS DEs includes determiningwhether the proposed registration duplicates existing functionality,whether it is likely to be of general applicability or useful onlyfor a single application, and whether the registration descriptionis clear. For example, for cipher suite registrations, the MLS DEs will apply theadvisory found inSection 17.1.¶

IANAMUST only accept registry updates from the MLS DEs andSHOULDdirect all requests for registration to the MLS DEs' mailing list.¶

It is suggested that multiple MLS DEs who are able torepresent the perspectives of different applications using thisspecification be appointed, in order to enable a broadly informed review ofregistration decisions. In cases where a registration decision couldbe perceived as creating a conflict of interest for a particularMLS DE, that MLS DESHOULD defer to the judgment of the other MLS DEs.¶

17.10.The "message/mls" Media Type

This document registers the "message/mls" media type in the "message" registry in order to allow otherprotocols (e.g., HTTP[RFC9113]) to convey MLS messages.¶

Type name:

message¶

Subtype name:

mls¶

Required parameters:

none¶

Optional parameters:

version

version:

The MLS protocol version expressed as a string<major>.<minor>. If omitted, the version is "1.0", which corresponds to MLS ProtocolVersion mls10. If for some reason the version number in the media type parameter differs from the ProtocolVersion embedded in the protocol, the protocol takes precedence.¶

Encoding considerations:

MLS messages are represented using the TLSpresentation language[RFC8446]. Therefore, MLS messages need to betreated as binary data.¶

Security considerations:

MLS is an encrypted messaging layer designedto be transmitted over arbitrary lower-layer protocols. Thesecurity considerations in this document (RFC 9420) also apply.¶

Interoperability considerations:

N/A¶

Published specification:

RFC 9420¶

Applications that use this media type:

MLS-based messaging applications¶

Fragment identifier considerations:

N/A¶

Additional information:

¶

Deprecated alias names for this type:

N/A¶

Magic number(s):

N/A¶

File extension(s):

N/A¶

Macintosh file type code(s):

N/A¶

Person & email address to contact for further information:

IETF MLS Working Group<mailto:mls@ietf.org>¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

IETF MLS Working Group¶

Change controller:

IETF¶