1.1.Change Log

RFC EDITOR PLEASE DELETE THIS SECTION.¶

draft-12¶

• Use the GroupContext to derive the joiner_secret (*)¶
• Make PreSharedKeys non optional in GroupSecrets (*)¶
• Update name for this particular key (*)¶
• Truncate tree size on removal (*)¶
• Use HPKE draft-08 (*)¶
• Clarify requirements around identity in MLS groups (*)¶
• Signal the intended wire format for MLS messages (*)¶
• Inject GroupContext as HPKE info instead of AAD (*)¶
• Clarify extension handling and make extension updatable (*)¶
• Improve extensibility of Proposals (*)¶
• Constrain proposal in External Commit (*)¶
• Remove the notion of a 'leaf index' (*)¶
• Add group_context_extensions proposal ID (*)¶
• Add RequiredCapabilities extension (*)¶
• Use cascaded KDF instead of concatenation to consolidate PSKs (*)¶
• Use key package hash to index clients in message structs (*)¶
• Don't require PublicGroupState for external init (*)¶
• Make ratchet tree section clearer.¶
• Handle non-member sender cases in MLSPlaintextTBS¶
• Clarify encoding of signatures with NIST curves¶
• Remove OPEN ISSUEs and TODOs¶
• Normalize the description of the zero vector¶

draft-11¶

• Include subtree keys in parent hash (*)¶
• Pin HPKE to draft-07 (*)¶
• Move joiner secret to the end of the first key schedule epoch (*)¶
• Add an AppAck proposal¶
• Make initializations of transcript hashes consistent¶

draft-10¶

• Allow new members to join via an external Commit (*)¶
• Enable proposals to be sent inline in a Commit (*)¶
• Re-enable constant-time Add (*)¶
• Change expiration extension to lifetime extension (*)¶
• Make the tree in the Welcome optional (*)¶
• PSK injection, re-init, sub-group branching (*)¶
• Require the initial init_secret to be a random value (*)¶
• Remove explicit sender data nonce (*)¶
• Do not encrypt to joiners in UpdatePath generation (*)¶
• Move MLSPlaintext signature under the confirmation tag (*)¶
• Explicitly authenticate group membership with MLSPLaintext (*)¶
• Clarify X509Credential structure (*)¶
• Remove uneeded interim transcript hash from GroupInfo (*)¶
• IANA considerations¶
• Derive an authentication secret¶
• Use Extract/Expand from HPKE KDF¶
• Clarify that application messages MUST be encrypted¶

draft-09¶

• Remove blanking of nodes on Add (*)¶
• Change epoch numbers to uint64 (*)¶
• Add PSK inputs (*)¶
• Add key schedule exporter (*)¶
• Sign the updated direct path on Commit, using "parent hashes" and onesignature per leaf (*)¶
• Use structured types for external senders (*)¶
• Redesign Welcome to include confirmation and use derived keys (*)¶
• Remove ignored proposals (*)¶
• Always include an Update with a Commit (*)¶
• Add per-message entropy to guard against nonce reuse (*)¶
• Use the same hash ratchet construct for both application and handshake keys (*)¶
• Add more ciphersuites¶
• Use HKDF to derive key pairs (*)¶
• Mandate expiration of ClientInitKeys (*)¶
• Add extensions to GroupContext and flesh out the extensibility story (*)¶
• Rename ClientInitKey to KeyPackage¶

draft-08¶

• Change ClientInitKeys so that they only refer to one ciphersuite (*)¶
• Decompose group operations into Proposals and Commits (*)¶
• Enable Add and Remove proposals from outside the group (*)¶
• Replace Init messages with multi-recipient Welcome message (*)¶
• Add extensions to ClientInitKeys for expiration and downgrade resistance (*)¶
• Allow multiple Proposals and a single Commit in one MLSPlaintext (*)¶

draft-07¶

• Initial version of the Tree based Application Key Schedule (*)¶
• Initial definition of the Init message for group creation (*)¶
• Fix issue with the transcript used for newcomers (*)¶
• Clarifications on message framing and HPKE contexts (*)¶

draft-06¶

• Reorder blanking and update in the Remove operation (*)¶
• Rename the GroupState structure to GroupContext (*)¶
• Rename UserInitKey to ClientInitKey¶
• Resolve the circular dependency that draft-05 introduced in theconfirmation MAC calculation (*)¶
• Cover the entire MLSPlaintext in the transcript hash (*)¶

draft-05¶

• Common framing for handshake and application messages (*)¶
• Handshake message encryption (*)¶
• Convert from literal state to a commitment via the "tree hash" (*)¶
• Add credentials to the tree and remove the "roster" concept (*)¶
• Remove the secret field from tree node values¶

draft-04¶

• Updating the language to be similar to the Architecture document¶
• ECIES is now renamed in favor of HPKE (*)¶
• Using a KDF instead of a Hash in TreeKEM (*)¶

draft-03¶

• Added ciphersuites and signature schemes (*)¶
• Re-ordered fields in UserInitKey to make parsing easier (*)¶
• Fixed inconsistencies between Welcome and GroupState (*)¶
• Added encryption of the Welcome message (*)¶

draft-02¶

• Removed ART (*)¶
• Allowed partial trees to avoid double-joins (*)¶
• Added explicit key confirmation (*)¶

draft-01¶

• Initial description of the Message Protection mechanism. (*)¶
• Initial specification proposal for the Application Key Scheduleusing the per-participant chaining of the Application Secret design. (*)¶
• Initial specification proposal for an encryption mechanism to protectApplication Messages using an AEAD scheme. (*)¶
• Initial specification proposal for an authentication mechanismof Application Messages using signatures. (*)¶
• Initial specification proposal for a padding mechanism to improvingprotection of Application Messages against traffic analysis. (*)¶
• Inversion of the Group Init Add and Application Secret derivationsin the Handshake Key Schedule to be ease chaining in case we switchdesign. (*)¶
• Removal of the UserAdd construct and split of GroupAdd into Addand Welcome messages (*)¶
• Initial proposal for authenticating handshake messages by signingover group state and including group state in the key schedule (*)¶
• Added an appendix with example code for tree math¶
• Changed the ECIES mechanism used by TreeKEM so that it uses noncesgenerated from the shared secret¶

draft-00¶

• Initial adoption of draft-barnes-mls-protocol-01 as a WG item.¶

5.1.Tree Computation Terminology

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

Asubtree of a tree is the tree given by the descendants of anynode, thehead of the subtree. 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 (respectivelyright subtree).¶

All trees used in this protocol are left-balanced binary trees. Abinary tree isfull (andbalanced) if its size is a power oftwo and for any parent node in the tree, its left and right subtreeshave the same size.¶

A binary tree isleft-balanced if for everyparent, either the parent is balanced, or the left subtree of thatparent is the largest full subtree that could be constructed fromthe leaves present in the parent's own subtree.Given a list ofn items, there is a unique left-balancedbinary tree structure with these elements as leaves.¶

(Note that left-balanced binary trees are the same structure that isused for the Merkle trees in the Certificate Transparency protocol[I-D.ietf-trans-rfc6962-bis].)¶

Thedirect path of a root is the empty list, and of any other nodeis the concatenation of that node's parent along with the parent's direct path.Thecopath of a node is the node's sibling concatenated with the list ofsiblings of all the nodes in its direct path, excluding the root.¶

For example, in the below tree:¶

• The direct path of C is (CD, ABCD, ABCDEFG)¶
• The copath of C is (D, AB, EFG)¶

              7 = root        ______|______       /             \      3              11    __|__           __|   /     \         /   \  1       5       9     | / \     / \     / \    |A   B   C   D   E   F   G                    1 1 10 1 2 3 4 5 6 7 8 9 0 1 2

Each node in the tree is assigned anindex, starting at zero andrunning from left to right. A node is a leaf node if and only if ithas an even index. The node indices for the nodes in the above treeare as follows:¶

• 0 = A¶
• 1 = AB¶
• 2 = B¶
• 3 = ABCD¶
• 4 = C¶
• 5 = CD¶
• 6 = D¶
• 7 = ABCDEFG¶
• 8 = E¶
• 9 = EF¶
• 10 = F¶
• 11 = EFG¶
• 12 = G¶

A tree withn leaves has2*n - 1 nodes. For example, the above tree has 7leaves (A, B, C, D, E, F, G) and 13 nodes. The root of a tree withn leavesis always the node with index2^k - 1, wherek is the largest number suchthat2^k < n.¶

5.2.Ratchet Tree Nodes

A particular instance of a ratchet tree is defined by the same parameters thatdefine an instance of HPKE, namely:¶

• A Key Encapsulation Mechanism (KEM), including aDeriveKeyPair function thatcreates a key pair for the KEM from a symmetric secret¶
• A Key Derivation Function (KDF), includingExtract andExpand functions¶
• An AEAD encryption scheme¶

Each node in a ratchet tree contains up to five values:¶

• A private key (only within the member's direct path, see below)¶
• A public key¶
• An ordered list of node indices for "unmerged" leaves (seeSection 5.3)¶
• A credential (only for leaf nodes)¶
• A hash of certain information about the node's parent, as of the last time thenode was changed (seeSection 7.5).¶

The conditions under which each of these values must or must not bepresent are laid out inSection 5.3.¶

A node in the tree may also beblank, indicating that no value ispresent at that node. Theresolution of a node is an ordered listof non-blank nodes that collectively cover all non-blank descendantsof the node.¶

• The resolution of a non-blank node comprises the node itself,followed by its list of unmerged leaves, if any¶
• The resolution of a blank leaf node is the empty list¶
• The resolution of a blank intermediate node is the result ofconcatenating the resolution of its left child with the resolutionof its right child, in that order¶

For example, consider the following tree, where the "_" characterrepresents a blank node and unmerged leaves are indicated in squarebrackets:¶

      _    __|__   /     \  _       5[C] / \     / \A   _   C   D0 1 2 3 4 5 6

In this tree, we can see all of the above rules in play:¶

• The resolution of node 5 is the list [CD, C]¶
• The resolution of node 2 is the empty list []¶
• The resolution of node 3 is the list [A, CD, C]¶

Every node, regardless of whether the node is blank or populated, hasa correspondinghash that summarizes the contents of the subtreebelow that node. The rules for computing these hashes are describedinSection 7.6.¶

5.3.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 ofthe group only if that member's leaf is a descendant ofthe node.

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 keys ofall the intermediate nodes they're below. Such a member has anunmerged leaf.Encrypting to an intermediate node requires encrypting to the node's public key,as well as the public keys of all the unmerged leaves below it. A leaf isunmerged when it is first added, because the process of adding the leaf does notgive it access to all of the nodes above it in the tree. Leaves are "merged" asthey receive the private keys for nodes, as described inSection 5.4.¶

5.4.Ratchet Tree Evolution

A member of an MLS group advances the key schedule to provide forward secrecyand post-compromise security by providing the group with fresh key material tobe added into the group's shared secret.To do so, one member of the group generates fresh keymaterial, applies it to their local tree state, and then sends this key materialto other members in the group via an UpdatePath message (seeSection 7.8) .All other group members then apply the key material in the UpdatePath to theirown local tree state to derive the group's now-updated shared secret.¶

To begin, the generator of the UpdatePath updates its leafKeyPackage and its direct path to the root with new secret values. TheHPKE leaf public key within the KeyPackage MUST be derived from a freshlygenerated HPKE secret key to provide post-compromise security.¶

The generator of the UpdatePath starts by sampling a fresh random value called"leaf_secret", and uses the leaf_secret to generate their leaf HPKE key pair(seeSection 7) and to seed a sequence of "path secrets", one for eachancestor of its leaf. In this setting,path_secret[0] refers to the node directly above the leaf,path_secret[1] for its parent, and so on. At each step, the pathsecret is used to derive a new secret value for the correspondingnode, from which the node's key pair is derived.¶

leaf_node_secret = DeriveSecret(leaf_secret, "node")path_secret[0] = DeriveSecret(leaf_secret, "path")path_secret[n] = DeriveSecret(path_secret[n-1], "path")node_secret[n] = DeriveSecret(path_secret[n], "node")leaf_priv, leaf_pub = KEM.DeriveKeyPair(leaf_node_secret)node_priv[n], node_pub[n] = KEM.DeriveKeyPair(node_secret[n])

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

      3    __|__   /     \  1       5[C] / \     / \A   B   C   D0 1 2 3 4 5 6

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

path_secret[1] --> node_secret[1] --> node_priv[1], node_pub[1]     ^     |path_secret[0] --> node_secret[0] --> node_priv[0], node_pub[0]     ^     |leaf_secret    --> leaf_node_secret --> leaf_priv, leaf_pub                                     ~> leaf_key_package

After applying the UpdatePath, the tree will have the following structure, wherelp andnp[i] represent the leaf_priv and node_priv values generated asdescribed above:¶

    np[1] -> 3           __|__          /     \np[0] -> 1       5[C]        / \     / \       A   B   C   D           ^           |           lp       0 1 2 3 4 5 6

After performing these operations, the generator of the UpdatePath MUSTdelete the leaf_secret.¶

5.5.Synchronizing Views of the Tree

After generating fresh key material and applying it to ratchet forward theirlocal tree state as described in the prior section, the generator must broadcastthis 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 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 direct path of thesender's leaf, including the root:¶

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

The path secret value for a given node is encrypted for the subtreecorresponding to the parent's non-updated child, that is, 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.¶

The recipient of an UpdatePath processes it with the following steps:¶

1. Compute the updated path secrets.¶

   • Identify a node in the direct path for which the local memberis in the subtree of the non-updated child.¶
   • Identify a node in the resolution of the copath node forwhich this node has a private key.¶
   • Decrypt the path secret for the parent of the copath node usingthe private key from the resolution node.¶
   • Derive path secrets for ancestors of that node using thealgorithm described above.¶
   • The recipient SHOULD verify that the received public keys agreewith the public keys derived from the new path_secret values.¶

2. Merge the updated path secrets into the tree.¶

   • For all updated nodes,¶

     • Replace the public key for each node with the received public key.¶
     • Set the list of unmerged leaves to the empty list.¶
     • Store the updated hash of the node's parent (represented as a ParentNodestruct), going from root to leaf, so that each hash incorporates all thenodes above it. The root node always has a zero-length hash for thisvalue.¶
   • For nodes where an updated path secret was computed in step 1,compute the corresponding node key pair and replace the valuesstored at the node with the computed values.¶

For example, in order to communicate the example update described inthe previous section, the sender would transmit the followingvalues:¶

In this table, the value pk(ns[X]) represents the public keyderived from the node secret X, whereas pk(X) represents the public leaf keyfor user X. The value E(K, S) representsthe public-key encryption of the path secret S to thepublic key K (using HPKE).¶

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

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

6.1.Ciphersuites

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

• HPKE parameters:¶

  • A Key Encapsulation Mechanism (KEM)¶
  • A Key Derivation Function (KDF)¶
  • An AEAD encryption algorithm¶
• A hash algorithm¶
• A signature algorithm¶

MLS uses draft-08 of HPKE[I-D.irtf-cfrg-hpke] for public-key encryption.TheDeriveKeyPair function associated to the KEM for the ciphersuite mapsoctet strings to HPKE key pairs.¶

Ciphersuites are represented with the CipherSuite type. HPKE public keysare opaque values in a format defined by the underlyingprotocol (see the Cryptographic Dependencies section of the HPKE specification for moreinformation).¶

opaque HPKEPublicKey<1..2^16-1>;

The signature algorithm specified in the ciphersuite is the mandatory algorithmto be used for signatures in MLSPlaintext and the tree signatures. It MUST bethe same as the signature algorithm specified in the credential field of theKeyPackage objects in the leaves of the tree (including the InitKeysused to add new members).¶

The ciphersuites are defined in sectionSection 16.1.¶

6.2.Credentials

A member of a group authenticates the identities of other participants by meansof credentials issued by some authentication system, like a PKI. Each type ofcredential MUST express the following data in the context of the group it isused with:¶

• The public key of a signature key pair matching the SignatureScheme specifiedby the CipherSuite of the group¶
• The identity of the holder of the private key¶

Credentials MAY also include information that allows a relying partyto verify the identity / signing key binding.¶

Additionally, Credentials SHOULD specify the signature scheme corresponding toeach contained public key.¶

// See RFC 8446 and the IANA TLS SignatureScheme registryuint16 SignatureScheme;// See IANA registry for registered valuesuint16 CredentialType;struct {    opaque identity<0..2^16-1>;    SignatureScheme signature_scheme;    opaque signature_key<0..2^16-1>;} BasicCredential;struct {    opaque cert_data<0..2^16-1>;} Certificate;struct {    CredentialType credential_type;    select (Credential.credential_type) {        case basic:            BasicCredential;        case x509:            Certificate chain<1..2^32-1>;    };} Credential;

A BasicCredential is a raw, unauthenticated assertion of an identity/keybinding. The format of the key in thepublic_key field is defined by therelevant ciphersuite: the group ciphersuite for a credential in a ratchet tree,the KeyPackage ciphersuite for a credential in a KeyPackage object.¶

For X509Credential, each entry in the chain represents a single DER-encodedX509 certificate. The chain is ordered such that the first entry (chain[0])is the end-entity certificate and each subsequent certificate in the chainMUST be the issuer of the previous certificate. The algorithm for thepublic_key in the end-entity certificate MUST match the relevantciphersuite.¶

For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is inthe format specified[RFC8032]. For ciphersuites using ECDSA with the NISTcurves P-256 or P-521, the public key is the output of the uncompressedElliptic-Curve-Point-to-Octet-String conversion according to[SECG].¶

The signatures used throughout this document are encoded as specified in[RFC8446]. In particular, ECDSA signatures are DER-encoded and EdDSA signaturesare defined as the concatenation ofr ands as specified in[RFC8032].¶

Note that each new credential that has not already been validatedby the application MUST be validated against the AuthenticationService.¶

7.1.Key Package IDs

When it is necessary to refer to a specific KeyPackage, protocol messagesincorporate a KeyPackageID:¶

struct { opaque key_package_hash<0..255>;} KeyPackageID¶

This value is the hash of the KeyPackage, using the hash indicated by thecipher_suite field. KeyPackage hashes are used in a Welcome message toindicate which KeyPackage is being used to include the new member. Since membersof a group are uniquely identified by their leaf KeyPackages, messages within agroup use the hash of this key package to refer to group members, e.g., tospecify the target of a Remove proposal or the signer of an MLSPlaintext.¶

7.2.Client Capabilities

Thecapabilities extension indicates what protocol versions, ciphersuites,protocol extensions, and non-default proposal types are supported by a client.Proposal types defined in this document are considered "default" and thus neednot be listed.¶

struct {    ProtocolVersion versions<0..255>;    CipherSuite ciphersuites<0..255>;    ExtensionType extensions<0..255>;    ProposalType proposals<0..255>;} Capabilities;

This extension MUST be always present in a KeyPackage. Extensions that appearin theextensions field of a KeyPackage MUST be included in theextensionsfield of thecapabilities extension.¶

7.3.Lifetime

Thelifetime extension represents the times between which clients willconsider a KeyPackage valid. This time is represented as an absolute time,measured in seconds since the Unix epoch (1970-01-01T00:00:00Z). A client MUSTNOT use the data in a KeyPackage for any processing before thenot_beforedate, or after thenot_after date.¶

uint64 not_before;uint64 not_after;

Applications MUST define a maximum total lifetime that is acceptable for aKeyPackage, and reject any KeyPackage where the total lifetime is longer thanthis duration.¶

This extension MUST always be present in a KeyPackage.¶

7.4.KeyPackage Identifiers

Within MLS, a KeyPackage is identified by its hash (see, e.g.,Section 11.2.2). Theexternal_key_id extension allows applications to addan explicit, application-defined identifier to a KeyPackage.¶

opaque external_key_id<0..2^16-1>;

7.5.Parent Hash

Theparent_hash extension carries information to authenticate the structure ofthe tree, as described below.¶

opaque parent_hash<0..255>;

Consider a ratchet tree with a parent node P and children V and S. The parent hashof P changes whenever anUpdatePath object is applied to the ratchet tree alonga path traversing node V (and hence also P). The new "Parent Hash of P (with Co-PathChild S)" is obtained by hashing P'sParentHashInput struct using the resolutionof S to populate theoriginal_child_resolution field. This way, P's Parent Hashfixes the new HPKE public keys of all nodes on the path from P to the root.Furthermore, for each such key PK the hash also binds the set of HPKE public keysto which PK's secret key was encrypted in the commit packet that anounced theUpdatePath object.¶

struct {    HPKEPublicKey public_key;    opaque parent_hash<0..255>;    HPKEPublicKey original_child_resolution<0..2^32-1>;} ParentHashInput;

The Parent Hash of P with Co-Path Child S is the hash of aParentHashInput objectpopulated as follows. The fieldpublic_key contains the HPKE public key of P. If Pis the root, thenparent_hash is set to a zero-length octet string.Otherwiseparent_hash is the Parent Hash of P's parent with P's sibling as theco-path child.¶

Finally,original_child_resolution is the array ofHPKEPublicKey values of thenodes in the resolution of S but with theunmerged_leaves of P omitted. Forexample, in the ratchet tree depicted inSection 5.2 theParentHashInput of node 5 with co-path child 4 would contain an emptyoriginal_child_resolution since 4's resolution includes only itself but 4 is alsoan unmerged leaf of 5. Meanwhile, theParentHashInput of node 5 with co-path child6 has an array with one element in it: the HPKE public key of 6.¶

7.6.Tree Hashes

To allow group members to verify that they agree on the public cryptographic stateof the group, this section defines a scheme for generating a hash value (calledthe "tree hash") that represents the contents of the group's ratchet tree and themembers' KeyPackages. The tree hash of a tree is the tree hash of its root node,which we define recursively, starting with the leaves.¶

As some nodes may be blank while others contain data we use the following structto include data if present.¶

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

The tree hash of a leaf node is the hash of leaf'sLeafNodeHashInput object whichmight include a Key Package depending on whether or not it is blank.¶

struct {    uint32 node_index;    optional<KeyPackage> key_package;} LeafNodeHashInput;

Now the tree hash of any non-leaf node is recursively defined to be the hash ofitsParentNodeTreeHashInput. This includes an optionalParentNodeobject depending on whether the node is blank or not.¶

struct {    HPKEPublicKey public_key;    opaque parent_hash<0..255>;    uint32 unmerged_leaves<0..2^32-1>;} ParentNode;struct {    uint32 node_index;    optional<ParentNode> parent_node;    opaque left_hash<0..255>;    opaque right_hash<0..255>;} ParentNodeTreeHashInput;

Theleft_hash andright_hash fields hold the tree hashes of the node'sleft and right children, respectively.¶

7.7.Group State

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

struct {    opaque group_id<0..255>;    uint64 epoch;    opaque tree_hash<0..255>;    opaque confirmed_transcript_hash<0..255>;    Extension extensions<0..2^32-1>;} GroupContext;

The fields in this state have the following semantics:¶

• Thegroup_id field is an application-defined identifier for thegroup.¶
• Theepoch field represents the current version of the group key.¶
• 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.6.¶
• Theconfirmed_transcript_hash field contains a running hash overthe messages that led to this state.¶

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 11.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 is updated with the data for anMLSPlaintext message encoding a Commit message in two parts:¶

struct {    WireFormat wire_format;    opaque group_id<0..255>;    uint64 epoch;    Sender sender;    opaque authenticated_data<0..2^32-1>;    ContentType content_type = commit;    Commit commit;    opaque signature<0..2^16-1>;} MLSPlaintextCommitContent;struct {    optional<MAC> confirmation_tag;} MLSPlaintextCommitAuthData;interim_transcript_hash_[0] = ""; // zero-length octet stringconfirmed_transcript_hash_[n] =    Hash(interim_transcript_hash_[n] ||        MLSPlaintextCommitContent_[n]);interim_transcript_hash_[n+1] =    Hash(confirmed_transcript_hash_[n] ||        MLSPlaintextCommitAuthData_[n]);

Thus theconfirmed_transcript_hash field in a GroupContext object represents atranscript over the whole history of MLSPlaintext Commit messages, up to theconfirmation tag field in the current MLSPlaintext message. The confirmationtag is then included in the transcript for the next epoch. The interimtranscript hash is computed by new members using the confirmation tag in theGroupInfo struct, and enables existing members to incorporate a Commit messageinto the transcript without having to store the whole MLSPlaintextCommitAuthDatastructure.¶

As shown above, when a new group is created, theinterim_transcript_hash fieldis set to the zero-length octet string.¶

7.8.Update Paths

As described inSection 11.2, each MLS Commit message may optionallytransmit a KeyPackage leaf and node values along its direct path.The path contains a public key and encrypted secret value for allintermediate nodes in the path above the leaf. The path is orderedfrom the closest node to the leaf to the root; each node MUST be theparent of its predecessor.¶

struct {    opaque kem_output<0..2^16-1>;    opaque ciphertext<0..2^16-1>;} HPKECiphertext;struct {    HPKEPublicKey public_key;    HPKECiphertext encrypted_path_secret<0..2^32-1>;} UpdatePathNode;struct {    KeyPackage leaf_key_package;    UpdatePathNode nodes<0..2^32-1>;} UpdatePath;

For eachUpdatePathNode, the resolution of the corresponding copath node MUSTbe filtered by removing all new leaf nodes added as part of this MLS Commitmessage. The number of ciphertexts in theencrypted_path_secret vector MUST beequal to the length of the filtered resolution, with each ciphertext being theencryption to the respective resolution node.¶

The HPKECiphertext values are computed as¶

kem_output, context = SetupBaseS(node_public_key, group_context)ciphertext = context.Seal("", path_secret)

wherenode_public_key is the public key of the node that the pathsecret is being encrypted for, group_context is the current GroupContext objectfor the group, and the functionsSetupBaseS andSeal are defined according to[I-D.irtf-cfrg-hpke].¶

Decryption is performed in the corresponding way, using the privatekey of the resolution node and the ephemeral public keytransmitted in the message.¶

8.1.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 an 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 PublicGroupState 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 andpreform 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)

In both cases, theinfo input to HPKE is set to the PublicGroupState for theprevious epoch, encoded using the TLS serialization.¶

8.2.Pre-Shared Keys

Groups which already have an out-of-band mechanism to generateshared group secrets can inject those into the MLS key schedule to seedthe MLS group secrets computations by this external entropy.¶

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 (FS) or Post-Compromise Security(PCS) guarantees as a Commit message. Unlike the key pairs populated in thetree by an Update or Commit, which 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 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 recovery and re-init PSKsare derived from the MLS key schedule and used in cases where it isnecessary to authenticate a member's participation in a prior group state.In particular, in addition to external PSK types, a PSK derived from within MLSmay be used in the following cases:¶

• Re-Initialization: If during the lifetime of a group, the group membersdecide to switch to a more secure ciphersuite or newer protocol version,a PSK can be used to carry entropy from the old group forward into a newgroup with the desired parameters.¶
• Branching: A PSK may be used to bootstrap a subset of current groupmembers into a new group. This applies if a subset of current groupmembers wish to branch based on the current group state.¶

The injection of one or more PSKs into the key schedule is signaled in two ways:1) as aPreSharedKey proposal, and 2) in theGroupSecrets object of aWelcome message sent to new members added in that epoch.¶

enum {  reserved(0),  external(1),  reinit(2),  branch(3)  (255)} PSKType;struct {  PSKType psktype;  select (PreSharedKeyID.psktype) {    case external:      opaque psk_id<0..255>;    case reinit:      opaque psk_group_id<0..255>;      uint64 psk_epoch;    case branch:      opaque psk_group_id<0..255>;      uint64 psk_epoch;  }  opaque psk_nonce<0..255>;} PreSharedKeyID;struct {    PreSharedKeyID psks<0..2^16-1>;} PreSharedKeys;

On receiving a Commit with aPreSharedKey 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_secret of the group andepoch specified in thePreSharedKeyID 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, as follows:¶

                0                                   0       = psk_secret_[0]                |                                   |                V                                   Vpsk_[0] --> KDF.Extract --> ExpandWithLabel --> KDF.Extract = psk_secret_[1]                                                    |                0                                   |                |                                   |                V                                   Vpsk_[1] --> KDF.Extract --> ExpandWithLabel --> KDF.Extract = psk_secret_[1]                                                    |                0                                  ...                |                                   |                V                                   Vpsk_[n] --> KDF.Extract --> ExpandWithLabel --> KDF.Extract = psk_secret_[n]

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

8.3.Secret Tree

For the generation of encryption keys and nonces, the key schedule begins withtheencryption_secret at the root and derives a tree of secrets with the samestructure as the group's ratchet tree. Each leaf in the Secret Tree isassociated with the same group member as the corresponding leaf in the ratchettree. Nodes are also assigned an index according to their position in the arrayrepresentation of the tree (described inAppendix A). If N is a node index inthe Secret Tree then left(N) and right(N) denote the children of N (if theyexist).¶

The secret of any other node in the tree is derived from its parent's secretusing a call to DeriveTreeSecret:¶

DeriveTreeSecret(Secret, Label, Node, Generation, Length) =    ExpandWithLabel(Secret, Label, TreeContext, Length)Where TreeContext is specified as:struct {    uint32 node = Node;    uint32 generation = Generation;} TreeContext;

If N is a node index in the Secret Tree then the secrets of the childrenof N are defined to be:¶

tree_node_[N]_secret        |        |        +--> DeriveTreeSecret(., "tree", left(N), 0, KDF.Nh)        |    = tree_node_[left(N)]_secret        |        +--> DeriveTreeSecret(., "tree", right(N), 0, KDF.Nh)             = tree_node_[right(N)]_secret

The secret in the leaf of the Secret Tree is used to initiate two symmetric hashratchets, from which a sequence of single-use keys and nonces are derived, asdescribed inSection 8.4. The root of each ratchet is computed as:¶

tree_node_[N]_secret        |        |        +--> DeriveTreeSecret(., "handshake", N, 0, KDF.Nh)        |    = handshake_ratchet_secret_[N]_[0]        |        +--> DeriveTreeSecret(., "application", N, 0, KDF.Nh)             = application_ratchet_secret_[N]_[0]

8.4.Encryption Keys

As described inSection 9, 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".¶

A sender ratchet starts from a per-sender base secret derived from a SecretTree, as described inSection 8.3. 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 pair MUST 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 indexof the sender's leaf in the ratchet tree and the current position inthe ratchet. In particular, the node index of the sender's leaf in theratchet tree is the same as the node index of the leaf in the Secret Treeused to initialize the sender's ratchet.¶

ratchet_secret_[N]_[j]      |      +--> DeriveTreeSecret(., "nonce", N, j, AEAD.Nn)      |    = ratchet_nonce_[N]_[j]      |      +--> DeriveTreeSecret(., "key", N, j, AEAD.Nk)      |    = ratchet_key_[N]_[j]      |      VDeriveTreeSecret(., "secret", N, j, KDF.Nh)= ratchet_secret_[N]_[j+1]

Here, AEAD.Nn and AEAD.Nk denote the lengthsin bytes of the nonce and key for the AEAD scheme defined bythe ciphersuite.¶

8.5.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 if¶
• 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,encryption_secret as well as any secret in a Secret Tree or one of theratchets.¶

As soon as a group member consumes a value they MUST immediately delete(all representations of) that value. This is crucial to ensuringforward secrecy for past messages. Members MAY 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 nodeindex N in some epoch n. Then, for that member, at least the followingvalues have been consumed and MUST be deleted:¶

• thecommit_secret,joiner_secret,epoch_secret,encryption_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 index N,¶
• the first j secrets in the application data ratchet of node index N and¶
• application_ratchet_nonce_[N]_[j] andapplication_ratchet_key_[N]_[j].¶

Concretely, suppose we have the following Secret Tree and ratchet forparticipant D:¶

       G     /   \    /     \   E       F  / \     / \ A   B   C   D            / \          HR0  AR0 -+- K0                |   |                |   +- N0                |               AR1 -+- K1                |   |                |   +- N1                |               AR2

Then if a client uses key K1 and nonce N1 during epoch n then it must consume(at least) values G, F, D, AR0, AR1, K1, N1 as well as the key schedule secretsused to derive G (theencryption_secret), namelyinit_secret of epoch n-1andcommit_secret,joiner_secret,epoch_secret of epoch n. The client MAYretain (not consume) the values K0 and N0 to allow for out-of-order delivery,and SHOULD retain AR2 for processing future messages.¶

8.6.Exporters

The main MLS key schedule provides anexporter_secret which canbe used by an application as the basis to derive new secrets calledexported_value outside the MLS layer.¶

MLS-Exporter(Label, Context, key_length) =       ExpandWithLabel(DeriveSecret(exporter_secret, Label),                         "exporter", Hash(Context), key_length)

Each application SHOULD provide a unique label toMLS-Exporter thatidentifies its use case. This is to prevent twoexported outputs from being generated with the same values and usedfor different functionalities.¶

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

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

8.7.Resumption Secret

The main MLS key schedule provides aresumption_secret which can provide extrasecurity in some cross-group operations.¶

The application SHOULD specify an upper limit on the number of pastepochs for which theresumption_secret may be stored.¶

There are two ways in which aresumption_secret can be used: to re-initializethe group with different parameters, or to create asub-group of an existing group as detailed inSection 8.2.¶

Resumption keys are distinguished from exporter keys in that they have specificuse inside the MLS protocol, whereas the use of exporter secrets may bedecided by an external application. They are thus derived separately to avoidkey material reuse.¶

8.8.State Authentication Keys

The main MLS key schedule provides a per-epochauthentication_secret.If one of the parties is being actively impersonated by an attacker, theirauthentication_secret will differ from that of the other group members.Thus, members of a group MAY use theirauthentication_secrets withinan out-of-band authentication protocol to ensure that theyshare the same view of the group.¶

9.1.Content Authentication

Thesignature field in an MLSPlaintext object is computed using the signingprivate key corresponding to the public key, which was authenticated by thecredential at the leaf of the tree indicated by the sender field. The signaturecovers the plaintext metadata and message content, which is all of MLSPlaintextexcept for thesignature, theconfirmation_tag andmembership_tag fields.If the sender is a member of the group, the signature also covers theGroupContext for the current epoch, so that signatures are specific to a givengroup and epoch.¶

struct {    select (MLSPlaintextTBS.sender.sender_type) {        case member:            GroupContext context;        case preconfigured:        case new_member:            struct{};    }    WireFormat wire_format;    opaque group_id<0..255>;    uint64 epoch;    Sender sender;    opaque authenticated_data<0..2^32-1>;    ContentType content_type;    select (MLSPlaintextTBS.content_type) {        case application:          opaque application_data<0..2^32-1>;        case proposal:          Proposal proposal;        case commit:          Commit commit;    }} MLSPlaintextTBS;

Themembership_tag field in the MLSPlaintext object authenticates the sender'smembership in the group. For an MLSPlaintext with a sender type other thanmember, this field MUST be omitted. For messages sent by members, it MUST bepresent and set to the following value:¶

struct {  MLSPlaintextTBS tbs;  opaque signature<0..2^16-1>;  optional<MAC> confirmation_tag;} MLSPlaintextTBM;membership_tag = MAC(membership_key, MLSPlaintextTBM);

Note that themembership_tag only needs to be computed for MLSPlaintextmessages that will be sent over the wire (wire_format == mls_plaintext). Itisn't needed for messages that will be encrypted and transmitted asMLSCiphertext messages (wire_format == mls_ciphertext).¶

9.2.Content Encryption

Theciphertext field of the MLSCiphertext object is produced by supplying theinputs described below to the AEAD function specified by the ciphersuite in use.The plaintext input contains the content and signature of the MLSPlaintext, plusoptional padding. These values are encoded in the following form:¶

struct {    select (MLSCiphertext.content_type) {        case application:          opaque application_data<0..2^32-1>;        case proposal:          Proposal proposal;        case commit:          Commit commit;    }    opaque signature<0..2^16-1>;    optional<MAC> confirmation_tag;    opaque padding<0..2^16-1>;} MLSCiphertextContent;

In the MLS key schedule, the sender creates two distinct key ratchets forhandshake and application messages for each member of the group. When encryptinga message, the sender looks at the ratchets it derived for its own member andchooses an unused generation from either the handshake or application ratchetdepending on the content type of the message. This generation of the ratchet isused to derive a provisional nonce and key.¶

Before use in the encryption operation, the nonce is XORed with a fresh randomvalue to guard against reuse. Because the key schedule generates noncesdeterministically, a client must keep persistent state as to where in the keyschedule it is; if this persistent state is lost or corrupted, a client mightreuse a generation that has already been used, causing reuse of a key/nonce pair.¶

To avoid this situation, the sender of a message MUST generate a fresh random4-byte "reuse guard" value and XOR it with the first four bytes of the noncefrom the key schedule before using the nonce for encryption. The sender MUSTinclude the reuse guard in thereuse_guard field of the sender data object, sothat the recipient of the message can use it to compute the nonce to be used fordecryption.¶

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

The Additional Authenticated Data (AAD) input to the encryptioncontains an object of the following form, with the values used toidentify the key and nonce:¶

struct {    opaque group_id<0..255>;    uint64 epoch;    ContentType content_type;    opaque authenticated_data<0..2^32-1>;} MLSCiphertextContentAAD;

9.3.Sender Data Encryption

The "sender data" used to look up the key for the content encryption isencrypted with the ciphersuite's AEAD with a key and nonce derived from both thesender_data_secret and a sample of the encrypted content. Before beingencrypted, the sender data is encoded as an object of the following form:¶

struct {    KeyPackageID sender;    uint32 generation;    opaque reuse_guard[4];} MLSSenderData;

MLSSenderData.sender is assumed to be amember sender type. When constructingan MLSSenderData from a Sender object, the sender MUST verify Sender.sender_typeismember and use Sender.sender for MLSSenderData.sender.¶

Thereuse_guard field contains a fresh random value used to avoid nonce reusein the case of state loss or corruption, as described inSection 9.2.¶

The key and nonce provided to the AEAD are computed as the KDF of the firstKDF.Nh bytes of the ciphertext generated in the previous section. If thelength of the ciphertext is less thanKDF.Nh, the whole ciphertext is usedwithout padding. In pseudocode, the key and nonce are derived as:¶

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)

The Additional Authenticated Data (AAD) for the SenderData ciphertext is all thefields of MLSCiphertext excludingencrypted_sender_data:¶

struct {    opaque group_id<0..255>;    uint64 epoch;    ContentType content_type;} MLSSenderDataAAD;

When parsing a SenderData struct as part of message decryption, the recipientMUST verify that the KeyPackageID indicated in thesender field identifies amember of the group.¶

10.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 ciphersuiteand protocol version in use. Additional requirements can be imposed byincluding arequired_capabilities extension in the GroupContext.¶

struct {    ExtensionType extensions<0..255>;    ProposalType proposals<0..255>;} RequiredCapabilities;

This extension lists the extensions and proposal types that must be supported byall members of the group. For new members, it is enforced by existing members during theapplication of Add commits. Existing members should of course be in compliancealready. In order to ensure this continues to be the case even as the group'sextensions can be updated, a GroupContextExtensions proposal is invalid if itcontains arequired_capabilities extension that requires capabililities notsupported by all current members.¶

10.2.Linking a New Group to an Existing Group

A new group may be tied to an already existing group for the purpose ofre-initializing the existing group, or to branch into a sub-group.Re-initializing an existing group may be used, for example, to restart the groupwith a different ciphersuite or protocol version. Branching may be used tobootstrap a new group consisting of a subset of current group members, based onthe current group state.¶

In both cases, thepsk_nonce included in thePreSharedKeyID object must be arandomly sampled nonce of lengthKDF.Nh to avoid key re-use.¶

11.1.Proposals

Proposals are included in an MLSPlaintext by way of a Proposal structure thatindicates their type:¶

// See IANA registry for registered valuesuint16 ProposalType;struct {    ProposalType msg_type;    select (Proposal.msg_type) {        case add:                      Add;        case update:                   Update;        case remove:                   Remove;        case psk:                      PreSharedKey;        case reinit:                   ReInit;        case external_init:            ExternalInit;        case app_ack:                  AppAck;        case group_context_extensions: GroupContextExtensions;    };} Proposal;

On receiving an MLSPlaintext containing a Proposal, a client MUST verify thesignature on the enclosing MLSPlaintext. If the signature verifiessuccessfully, then the Proposal should be cached in such a way that it can beretrieved by hash (as a ProposalOrRef object) in a later Commit message.¶

struct {    KeyPackage key_package;} Add;

struct {    KeyPackage key_package;} Update;

struct {    KeyPackageID removed;} Remove;

struct {    PreSharedKeyID psk;} PreSharedKey;

struct {    opaque group_id<0..255>;    ProtocolVersion version;    CipherSuite cipher_suite;    Extension extensions<0..2^32-1>;} ReInit;

struct {  opaque kem_output<0..2^16-1>;} ExternalInit;

struct {    KeyPackageID sender;    uint32 first_generation;    uint32 last_generation;} MessageRange;struct {    MessageRange received_ranges<0..2^32-1>;} AppAck;

11.2.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. Proposalssupplied by value are included directly in the Commit object. Proposalssupplied by reference are specified by including the hash of the MLSPlaintext inwhich the Proposal was sent, using the hash function from the group'sciphersuite. For proposals supplied by value, the sender of the proposal is thesame as the sender of the Commit. Conversely, proposals sent by people otherthan the committer MUST be included by reference.¶

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

A group member that has observed one or more proposals within an epoch MUST 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.¶

The sender of a Commit MUST include all valid proposals that it has receivedduring the current epoch. Invalid proposals include, for example, proposals withan invalid signature or proposals that are semantically invalid, such as an Addwhen the sender does not have the application-level permission to add new users.Proposals with a non-default proposal type MUST NOT be included in a commitunless the proposal type is supported by all the members of the group that willprocess the Commit (i.e., not including any members being added or removed bythe Commit).¶

If there are multiple proposals that apply to the same leaf, the committerchooses one and includes only that one in the Commit, considering the restinvalid. The committer MUST prefer any Remove received, or the most recentUpdate for the leaf if there are no Removes. If there are multiple Add proposalscontaining KeyPackages with the same tuple(credential.identity, endpoint_id)the committer again chooses one to include and considers the rest invalid. Addproposals that contain KeyPackages with an(credential.identity, endpoint_id)tuple that matches that of an existing KeyPackage in the group MUST beconsidered invalid. The comitter MUST consider invalid any Add or Updateproposal if the Credential in the contained KeyPackage shares the same signaturekey with a Credential in any leaf of the group, or indeed if the KeyPackageshares the samehpke_init_key with another KeyPackage in the group.¶

The Commit MUST NOT combine proposals sent within different epochs. In the eventthat a valid proposal is omitted from the next Commit, the sender of theproposal SHOULD retransmit it in the new epoch.¶

A member of the group MAY 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.¶

Thepath field of a Commit message MUST be populated if the Commit covers atleast one Update or Remove proposal. Thepath field MUST also be populatedif the Commit covers no proposals at all (i.e., if the proposals vectoris empty). Thepath field MAY be omitted if the Commit covers only Addproposals. In pseudocode, the logic for validating a Commit is as follows:¶

hasUpdates = falsehasRemoves = falsefor i, id in commit.proposals:    proposal = proposalCache[id]    assert(proposal != null)    hasUpdates = hasUpdates || proposal.msg_type == update    hasRemoves = hasRemoves || proposal.msg_type == removeif len(commit.proposals) == 0 || hasUpdates || hasRemoves:  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 Add, PreSharedKey, or ReInit proposals butwhere 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.¶

When creating or processing a Commit, three different ratchet trees andtheir associated GroupContexts are used:¶

1. "Old" refers to the ratchet tree and GroupContext for the epoch before thecommit. The old GroupContext is used when signing the MLSPlainText so thatexisting group members can verify the signature before processing thecommit.¶
2. "Provisional" refers to the ratchet tree and GroupContext constructed afterapplying the proposals that are referenced by the Commit. The provisionalGroupContext uses the epoch number for the new epoch, and the old confirmedtranscript hash. This is used when creating the UpdatePath, if theUpdatePath is needed.¶
3. "New" refers to the ratchet tree and GroupContext constructed after applyingthe proposals and the UpdatePath (if any). The new GroupContext uses theepoch number for the new epoch, and the new confirmed transcript hash. Thisis used when deriving the new epoch secrets, and is the only GroupContextthat newly-added members will have.¶

A member of the group creates a Commit message and the corresponding Welcomemessage at the same time, by taking the following steps:¶

• Construct an initial Commit object with theproposalsfield populated from Proposals received during the current epoch, and an emptypath field.¶

• Generate the provisional ratchet tree and GroupContext by applying the proposalsreferenced in the initial Commit object, as described inSection 11.1. Updateproposals are applied first, followed by Remove proposals, and then finallyAdd proposals. Add proposals are applied in the order listed in theproposals vector, and always to the leftmost unoccupied leaf in the tree, orthe right edge of the tree if all leaves are occupied.¶

  • Note that the order in which different types of proposals are applied shouldbe updated by the implementation to include any new proposals added bynegotiated group extensions.¶
  • PreSharedKey proposals are processed later when deriving thepsk_secret for the KeySchedule.¶
• Decide whether to populate thepath field: If thepath field is requiredbased on the proposals that are in the commit (see above), then it MUST bepopulated. Otherwise, the sender MAY omit thepath field at its discretion.¶

• If populating thepath field: Create an UpdatePath using the provisionalratchet tree and GroupContext. Any new member (from an add proposal) MUST beexluded from the resolution during the computation of the UpdatePath. Theleaf_key_package for this UpdatePath must have aparent_hash extension.Note that the KeyPackage in theUpdatePath effectively updates an existingKeyPackage in the group and thus MUST adhere to the same restrictions asKeyPackages used inUpdate proposals.¶

  • Assign this UpdatePath to thepath field in the Commit.¶
  • Apply the UpdatePath to the tree, as described inSection 5.5, creating the new ratchet tree. Definecommit_secret as the valuepath_secret[n+1] derived from thepath_secret[n] value assigned to the root node.¶
• If not populating thepath field: Set thepath field in the Commit to thenull optional. Definecommit_secret as the all-zero vector of lengthKDF.Nh (the same length as apath_secret value would be). In this case,the new ratchet tree is the same as the provisional ratchet tree.¶
• Derive thepsk_secret as specified inSection 8.2, where the orderof PSKs in the derivation corresponds to the order of PreSharedKey proposalsin theproposals vector.¶

• Construct an MLSPlaintext object containing the Commit object. Sign theMLSPlaintext using the old GroupContext as context.¶

  • Use the MLSPlaintext to update the confirmed transcript hash and generatethe new GroupContext.¶
  • Use theinit_secret from the previous epoch, thecommit_secret and thepsk_secret as defined in the previous steps, and the new GroupContext tocompute the newjoiner_secret,welcome_secret,epoch_secret, andderived secrets for the new epoch.¶
  • Use theconfirmation_key for the new epoch to compute theconfirmation_tag value, and themembership_key for the old epoch tocompute themembership_tag value in the MLSPlaintext.¶
  • Calculate the interim transcript hash using the new confirmed transcripthash and theconfirmation_tag from the MLSPlaintext.¶

• Construct a GroupInfo reflecting the new state:¶

  • Group ID, epoch, tree, confirmed transcript hash, interim transcripthash, and group context extensions from the new state¶
  • The confirmation_tag from the MLSPlaintext object¶
  • Other extensions as defined by the application¶
  • Sign the GroupInfo using the member's private signing key¶
  • Encrypt the GroupInfo using the key and nonce derived from thejoiner_secretfor the new epoch (seeSection 11.2.2)¶

• For each new member in the group:¶

  • Identify the lowest common ancestor in the tree of the new member'sleaf node and the member sending the Commit¶
  • If thepath field was populated above: Compute the path secretcorresponding to the common ancestor node¶
  • Compute an EncryptedGroupSecrets object that encapsulates theinit_secretfor the current epoch and the path secret (if present).¶
• Construct a Welcome message from the encrypted GroupInfo object, the encryptedkey packages, and any PSKs for which a proposal was included in the Commit. Theorder of thepsks MUST be the same as the order of PreSharedKey proposals in theproposals vector.¶
• If a ReInit proposal was part of the Commit, the committer MUST create a newgroup with the parameters specified in the ReInit proposal,and with the same members as the original group.The Welcome message MUST include aPreSharedKeyID withpsktypereinit and withpsk_group_id andpsk_epoch corresponding to the currentgroup and the epoch after the commit was processed.¶

A member of the group applies a Commit message by taking the following steps:¶

• Verify that theepoch field of the enclosing MLSPlaintext message is equalto theepoch field of the current GroupContext object¶
• Verify that the signature on the MLSPlaintext message verifies using thepublic key from the credential stored at the leaf in the tree indicated bythesender field.¶
• Verify that all PSKs specified in any PreSharedKey proposals in theproposals vectorare available.¶

• Generate the provisional ratchet tree and GroupContext by applying the proposalsreferenced in the initial Commit object, as described inSection 11.1. Updateproposals are applied first, followed by Remove proposals, and then finallyAdd proposals. Add proposals are applied in the order listed in theproposals vector, and always to the leftmost unoccupied leaf in the tree, orthe right edge of the tree if all leaves are occupied.¶

  • Note that the order in which different types of proposals are applied shouldbe updated by the implementation to include any new proposals added bynegotiated group extensions.¶
• Verify that thepath value is populated if theproposals vector containsany Update or Remove proposals, or if it's empty. Otherwise, thepath valueMAY be omitted.¶

• If thepath value is populated: Process thepath value using theprovisional ratchet tree and GroupContext, to generate the new ratchet treeand thecommit_secret:¶

  • Apply the UpdatePath to the tree, as described inSection 5.5, and storeleaf_key_package at theCommitter's leaf.¶
  • Verify that the KeyPackage has aparent_hash extension and that its valuematches the new parent of the sender's leaf node.¶
  • Definecommit_secret as the valuepath_secret[n+1] derived from thepath_secret[n] value assigned to the root node.¶
• If thepath value is not populated: Definecommit_secret as the all-zerovector of lengthKDF.Nh (the same length as apath_secret value would be).¶
• Update the confirmed and interim transcript hashes using the new Commit, andgenerate the new GroupContext.¶
• Derive thepsk_secret as specified inSection 8.2, where the orderof PSKs in the derivation corresponds to the order of PreSharedKey proposalsin theproposals vector.¶
• Use theinit_secret from the previous epoch, thecommit_secret and thepsk_secret as defined in the previous steps, and the new GroupContext tocompute the newjoiner_secret,welcome_secret,epoch_secret, andderived secrets for the new epoch.¶
• Use theconfirmation_key for the new epoch to compute the confirmation tagfor this message, as described below, and verify that it is the same as theconfirmation_tag field in the MLSPlaintext object.¶
• If the above checks are successful, consider the new GroupContext objectas the current state of the group.¶

• If the Commit included a ReInit proposal, the client MUST NOT use the group tosend messages anymore. Instead, it MUST wait for a Welcome message from the committerand check that¶

  • Theversion,cipher_suite andextensions fields of the new groupcorresponds to the ones in theReInit proposal, and that theversionis greater than or equal to that of the original group.¶
  • Thepsks field in the Welcome message includes aPreSharedKeyID withpsktype =reinit, andpsk_epoch andpsk_group_id equal to the epochand group ID of the original group after processing the Commit.¶

The confirmation tag value confirms that the members of the group have arrivedat the same state of the group:¶

MLSPlaintext.confirmation_tag =    MAC(confirmation_key, GroupContext.confirmed_transcript_hash)

struct {    CipherSuite cipher_suite;    opaque group_id<0..255>;    uint64 epoch;    opaque tree_hash<0..255>;    opaque interim_transcript_hash<0..255>;    Extension group_context_extensions<0..2^32-1>;    Extension other_extensions<0..2^32-1>;    HPKEPublicKey external_pub;    KeyPackageID signer;    opaque signature<0..2^16-1>;} PublicGroupState;

struct {    opaque group_id<0..255>;    uint64 epoch;    opaque tree_hash<0..255>;    opaque interim_transcript_hash<0..255>;    Extension group_context_extensions<0..2^32-1>;    Extension other_extensions<0..2^32-1>;    HPKEPublicKey external_pub;    KeyPackageID signer;} PublicGroupStateTBS;

struct {  opaque group_id<0..255>;  uint64 epoch;  opaque tree_hash<0..255>;  opaque confirmed_transcript_hash<0..255>;  Extension group_context_extensions<0..2^32-1>;  Extension other_extensions<0..2^32-1>;  MAC confirmation_tag;  KeyPackageID signer;  opaque signature<0..2^16-1>;} GroupInfo;struct {  opaque path_secret<1..255>;} PathSecret;struct {  opaque joiner_secret<1..255>;  optional<PathSecret> path_secret;  PreSharedKeys psks;} GroupSecrets;struct {  KeyPackageID new_member<1..255>;  HPKECiphertext encrypted_group_secrets;} EncryptedGroupSecrets;struct {  ProtocolVersion version = mls10;  CipherSuite cipher_suite;  EncryptedGroupSecrets secrets<0..2^32-1>;  opaque encrypted_group_info<1..2^32-1>;} Welcome;

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

11.3.Ratchet Tree Extension

By default, a GroupInfo message only provides the joiner with a commitmentto the group's ratchet tree. In order to process or generate handshakemessages, the joiner will need to get a copy of the ratchet tree from some othersource. (For example, the DS might provide a cached copy.) The inclusion ofthe tree hash in the GroupInfo message means that the source of the ratchettree need not be trusted to maintain the integrity of tree.¶

In cases where the application does not wish to provide such an external source,the whole public state of the ratchet tree can be provided in an extension oftyperatchet_tree, containing aratchet_tree object of the following form:¶

enum {    reserved(0),    leaf(1),    parent(2),    (255)} NodeType;struct {    NodeType node_type;    select (Node.node_type) {        case leaf:   KeyPackage key_package;        case parent: ParentNode node;    };} Node;optional<Node> ratchet_tree<1..2^32-1>;

The presence of aratchet_tree extension in a GroupInfo message does notresult in any changes to the GroupContext extensions for the group. The ratchettree provided is simply stored by the client and used for MLS operations.¶

If this extension is not provided in a Welcome message, then the client willneed to fetch the ratchet tree over some other channel before it can generate orprocess Commit messages. Applications should ensure that this out-of-bandchannel is provided with security protections equivalent to the protections thatare afforded to Proposal and Commit messages. For example, an application thatencrypts Proposal and Commit messages might distribute ratchet trees encryptedusing a key exchanged over the MLS channel.¶

13.1.Server-Enforced Ordering

With this approach, the Delivery Service ensures that incomingmessages are added to an ordered queue and outgoing messages aredispatched in the same order. The server is trusted to break tieswhen two members send a Commit message at the same time.¶

Messages should have a counter field sent in clear-text that canbe checked by the server and used for tie-breaking. The counterstarts at 0 and is incremented for every new incoming message.If two group members send a message with the same counter, thefirst message to arrive will be accepted by the server and thesecond one will be rejected. The rejected message needs to be sentagain with the correct counter number.¶

To prevent counter manipulation by the server, the counter'sintegrity can be ensured by including the counter in a signedmessage envelope.¶

This applies to all messages, not only state changing messages.¶

13.2.Client-Enforced Ordering

Order enforcement can be implemented on the client as well,one way to achieve it is to use a two step update protocol: thefirst client sends a proposal to update and the proposal isaccepted when it gets 50%+ approval from the rest of the group,then it sends the approved update. Clients which didn't gettheir proposal accepted, will wait for the winner to send theirupdate before retrying new proposals.¶

While this seems safer as it doesn't rely on the server, it ismore complex and harder to implement. It also could cause starvationfor some clients if they keep failing to get their proposal accepted.¶

14.1.Message Encryption and Decryption

The group members MUST use the AEAD algorithm associated withthe negotiated MLS ciphersuite to AEAD encrypt and decrypt theirApplication messages according to the Message Framing section.¶

The group identifier and epoch allow a recipient to know which group secretsshould be used and from which Epoch secret to start computing other secretsand keys. The sender identifier is used to identify the member'ssymmetric ratchet from the initial group Application secret. The applicationgeneration field is used to determine how far into the ratchet to iterate inorder to reproduce the required AEAD keys and nonce for performing decryption.¶

Application messages SHOULD 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 ?" the answer "Wednesday" might be leakedto an adversary by the ciphertext length. An attacker expecting Alice toanswer Bob with a day of the week might find out the plaintext bycorrelation between the question and the length.¶

Similarly to TLS 1.3, if padding is used, the MLS messages MUST bepadded with zero-valued bytes before AEAD encryption. Upon AEAD decryption,the length field of the plaintext is used to compute the number of bytesto be removed from the plaintext to get the correct data.As the padding mechanism is used to improve protection against trafficanalysis, removal of the padding SHOULD be implemented in a "constant-time"manner at the MLS layer and above layers to prevent timing side-channels thatwould provide attackers with information on the size of the plaintext.The padding length length_of_padding can be chosen at the time of the messageencryption by the sender. Recipients can calculate the padding size from knowingthe total size of the ApplicationPlaintext and the length of the content.¶

14.2.Restrictions

During each epoch senders MUST NOT encrypt more data than permitted by thesecurity bounds of the AEAD scheme used.¶

Note that each change to the Group through a Handshake message will also set anewencryption_secret. Hence this change MUST 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.¶

14.3.Delayed and Reordered Application messages

Since each Application message contains the group identifier, the epoch and amessage counter, a client can receive messages out of order.If they are able to retrieve or recompute the correct AEAD decryption keyfrom currently stored cryptographic material clients can decryptthese messages.¶

For usability, MLS clients might be required to keep the AEAD keyand nonce for a certain amount of time to retain the ability to decryptdelayed or out of order messages, possibly still in transit while adecryption is being done.¶

15.1.Confidentiality of the 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 theratchet tree invariant and it makes it possible toencrypt to all group members except one, with a number of ciphertexts that'slogarithmic 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 theirkeypair such that the old private key can no longer be used to decrypt newmessages.¶

15.2.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 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 to have therequired PSKs.¶

15.3.Forward Secrecy and Post-Compromise Security

Post-compromise security is provided between epochs by members regularlyupdating their leaf key in the ratchet tree. Updating their leaf key preventsgroup secrets from continuing to be encrypted to previously compromised publickeys.¶

Forward-secrecy between epochs is provided by deleting private keys from pastversion 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.¶

Post-compromise security is also provided for new groups by members regularlygenerating new InitKeys and uploading them to the Delivery Service, such thatcompromised key material won't be used when the member is added to a new group.¶

15.4.InitKey Reuse

InitKeys are intended to be used only once. That is, once an InitKey has beenused to introduce the corresponding client to a group, it SHOULD be deleted fromthe InitKey publication system. Reuse of InitKeys can lead to replay attacks.¶

An application MAY allow for reuse of a "last resort" InitKey in order toprevent denial of service attacks. Since an InitKey is needed to add a clientto a new group, an attacker could prevent a client being added to new groups byexhausting all available InitKeys.¶

15.5.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 5.4, but the UpdatePath syntax allows the sender toencrypt arbitrary, unrelated secrets. The syntax also does not guarantee thatthe encrypted path secret encrypted 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. Applications SHOULD provide mechanisms for failedcommits to be reported, so that group members who were not able to recognize theerror themselves can reject the commit and roll back to a previous state ifnecessary.¶

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

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

16.1.MLS Ciphersuites

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

Ciphersuite names follow the naming convention:¶

CipherSuite MLS_LVL_KEM_AEAD_HASH_SIG = VALUE;

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

uint16 CipherSuite;

The columns in the registry are as follows:¶

• Value: The numeric value of the ciphersuite¶
• Name: The name of the ciphersuite¶
• Recommended: Whether support for this ciphersuite is recommended by the IETF MLSWG. Valid values are "Y" and "N". The "Recommended" column is assigned avalue of "N" unless explicitly requested, and adding a value with a"Recommended" value of "Y" requires Standards Action[RFC8126]. IESG Approvalis REQUIRED for a Y->N transition.¶
• Reference: The document where this ciphersuite is defined¶

Initial contents:¶

All of these ciphersuites use HMAC[RFC2104] as their MAC function, withdifferent hashes per ciphersuite. The mapping of ciphersuites to HPKEprimitives, HMAC hash functions, and TLS signature schemes is as follows[I-D.irtf-cfrg-hpke][RFC8446]:¶

The hash used for the MLS transcript hash is the one referenced in theciphersuite name. In the ciphersuites defined above, "SHA256" and "SHA512"refer to the SHA-256 and SHA-512 functions defined in[SHS].¶

It is advisable to keep the number of ciphersuites low to increase the chancesclients can interoperate in a federated environment, therefore the ciphersuitesonly inlcude 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 FIPS 140-2 compliant curves for Diffie-Hellman keynegotiations. Additionally clients that run predominantly on mobile processorscan choose ChaCha20Poly1305 over AES-GCM for performance reasons. SinceChaCha20Poly1305 is not listed by FIPS 140-2 it is not paired with FIPS 140-2compliant curves. The security level of symmetric encryption algorithms and hashfunctions is paired with the security level of the curves.¶

The mandatory-to-implement ciphersuite for MLS 1.0 isMLS10_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 which usesCurve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, andEd25519 for signatures.¶

Values with the first byte 255 (decimal) are reserved for Private Use.¶

New ciphersuite values are assigned by IANA as described inSection 16.¶

16.2.MLS Extension Types

This 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 messages¶
  • GC: GroupContext objects (and thegroup_context_extensions field ofGroupInfo objects)¶
  • GI: Theother_extensions field of GroupInfo objects¶
• Recommended: Whether support for this extension is recommended by the IETF MLSWG. Valid values are "Y" and "N". The "Recommended" column is assigned avalue of "N" unless explicitly requested, and adding a value with a"Recommended" value of "Y" requires Standards Action[RFC8126]. IESG Approvalis REQUIRED for a Y->N transition.¶
• Reference: The document where this extension is defined¶

Initial contents:¶

16.3.MLS Proposal Types

This 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: Whether support for this extension is recommended by the IETF MLSWG. Valid values are "Y" and "N". The "Recommended" column is assigned avalue of "N" unless explicitly requested, and adding a value with a"Recommended" value of "Y" requires Standards Action[RFC8126]. IESG Approvalis REQUIRED for a Y->N transition.¶
• Reference: The document where this extension is defined¶

Initial contents:¶

16.4.MLS Credential Types

This 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: Whether support for this credential is recommended by the IETF MLSWG. Valid values are "Y" and "N". The "Recommended" column is assigned avalue of "N" unless explicitly requested, and adding a value with a"Recommended" value of "Y" requires Standards Action[RFC8126]. IESG Approvalis REQUIRED for a Y->N transition.¶
• Reference: The document where this credential is defined¶

Initial contents:¶

16.5.MLS Designated Expert Pool

Specification Required[RFC8126] registry requests are registeredafter a three-week review period on the MLS DEs' mailing list: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 DEsmailing list and IANA. Denials SHOULD 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 usingtheiesg@ietf.org mailing list.¶

Criteria that SHOULD 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, the MLS DEs will apply the ciphersuite-relatedadvisory found inSection 6.1.¶

IANA MUST only accept registry updates from the MLS DEs and SHOULDdirect all requests for registration to the MLS DEs' mailing list.¶

It is suggested that multiple MLS DEs be appointed who are able torepresent the perspectives of different applications using thisspecification, in order to enable 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 DE SHOULD defer to the judgment of the other MLS DEs.¶