]> Amazon

alwenjo@amazon.com

Amazon

mulmarta@amazon.com

sec mls This document describes an extension to the MLS protocol that improves its efficiency in terms of per-member download size. This comes at essentially no cost. In essence, this document defines a new message type called split commit which replaces regular MLS commits. Unlike regular commits, a split commit can be "split" by the Delivery Service (DS) into much smaller per-member commits, one for each receiving member. The size of a per-member commit is always logarithmic in the group size, while the size of a regular MLS commit can be linear. This extension works in settings with a DS that can do the splitting which can be demanding with encrypted MLS handshake messages. This is motivated by academic research , , .

Introduction

Protocol Overview Consider the example ratchet tree from :

In a group with a ratchet tree of this form, if member 0 were to commit, they would compute two updated path secrets X' and Y', and three encrypted versions of these path secrets: X' encrypted to B Y' encrypted to C Y' encrypted to D With a normal MLS Commit, all three of these encrypted values are sent to each other member -- even though each member can only decrypt one of the encrypted values. Since the number of encrypted values can grow linearly as the size of the group, in the worst case, this creates quadratic data to be transmitted. With split Commits, each member receives only what they decrypt. The committer can make individual messages for each member, or they can emit a single message with all encrypted values, which the DS can use to construct per-member messages. We call the per-member messages PerMemberCommits, and the message carrying all of the encrypted values a SplitCommit.

| | | | | | | | E(C; Y') | | | +-------------------->| | | | | | | E(D; Y') | | | +------------------------------->| | | | | ]]>

| | | | | | | | | | | E(B; X') | | | | +--------->| | | | | | | | | | E(C; Y') | | | | +-------------------->| | | | | | | | | E(D; Y') | | | | +------------------------------->| | | | | | ]]>

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

Split Commits A Split Commit uploaded to the DS consists of two parts. First, it contains a SplitUpdatePath object which is a regular UpdatePath defined in {!RFC9420}} but without the committer's LeafNode. Second, it contains a split_commit_message MlsMessage (PublicMessage or PrivateMessage) which includes an epoch identifier, the committed list of proposals and the committer's LeafNode. The split_commit_message is signed and encrypted, while SplitUpdatePath is not. The reason is that the DS includes in per-member commits only parts of the SplitUpdatePath and receivers can still verify authenticity and decrypt all that is needed. (The split_commit_message must be delivered in full but its size is worst-case logarithmic.) The lack of encryption for SplitUpdatePath is not a problem because it contains only HPKE public keys and ciphertexts. The proposals and LeafNode (the latter containing a credential) are encrypted. The purpose of the epoch identifier is to provide authenticity. In particular, with Split Commit, the committer does not sign the HPKE keys they chose for their updated path in the ratchet tree. However, we need authenticity for these keys (else the adversary can replace them by their own). Thus, the committer signs instead (as part of message framing) the epoch identifier that binds the tree hash of the new epoch. In particular, the epoch identifier is derived from the new epoch's key schedule.

; } SplitUpdatePath; struct { opaque epoch_identifier; ProposalOrRef proposals; optional leaf_node; } SplitCommit; struct { // PrivateMessage or PublicMessage MLSMessage split_commit_message; optional path; } SplitCommitMessage; struct { // PrivateMessage or PublicMessage // content_type = split_commit MLSMessage split_commit_message; optional encrypted_path_secret; } PerMemberCommit; ]]>

The SplitCommit object is a new content type and SplitCommitMessage is a new wire format. Other MLS objects account for this as specified below.

; select (FramedContent.content_type) { case commit: MAC confirmation_tag; case application: case proposal: case split_commit: struct{}; }; } FramedContentAuthData; struct { opaque group_id; uint64 epoch; Sender sender; opaque authenticated_data; ContentType content_type; select (FramedContent.content_type) { case application: opaque application_data; case proposal: Proposal proposal; case commit: Commit commit; case split_commit: SplitCommit split_commit; }; } FramedContent; struct { ProtocolVersion version = mls10; WireFormat wire_format; select (MLSMessage.wire_format) { case mls_public_message: PublicMessage public_message; case mls_private_message: PrivateMessage private_message; case mls_welcome: Welcome welcome; case mls_group_info: GroupInfo group_info; case mls_key_package: KeyPackage key_package; case mls_split_commit: SplitCommitMessage split_commit_message; }; } MLSMessage; ]]>

A committing group member generates a SplitCommitMessage using the following steps: 1. Perform a regular MLS commit, without message framing. 2. Export a secret epoch_identifier from the new epoch with the label "SplitCommit". 3. Generate a SplitCommit object split_commit with epoch_identifier from Step 2 and leaf_node from path in the commit generated in Step 1. 4. Generate MlsMessage split_commit_message by framing split_commit. 5. Output SplitCommitMesage with path including nodes from path in the commit in Step 1, epoch_identifier from Step 2 and split_commit_message from Step 4. If the DS knows the ratchet trees before and after the split commit, it generates a PerMemberCommit for a receiver group member from a SplitCommit member as follows by choosing from the SplitUpdatePath only the HPKECiphertext for the receiver. If the SplitCommit does not contain the SplitUpdatePath or the commit removes the receiver, the PerMemberCommit does not include the HPKECiphertext. Section 5 considers DS's that do not know the ratchet tree. A receiver group member processes a PerMemberCommit using the following steps: 1. Process the split_commit_message MLSMessage to recover split_commit. 2. Recover path_secret decrypting that HPKECiphertext. 3. Use path_secret, public keys from path and proposals to process the commit as specified in . 4. Verify that epoch_identifier in split_commit matches the secret exported from the new epoch with the label "SplitCommit" .

Transcript Hashes With split commits, the input to the confirmed transcript hash is the same as in . In particular, it contains the FramedContent with a SplitCommit object inside. Split commits contain no confirmation tags, so the interim transcript hash is simply equal to the confirmed transcript hash.

Delivering Split Commits without the Ratchet Tree If the DS does not know the ratchet tree, then it cannot determine which ciphertexts to deliver to which members. Dealing with this is outside the scope of this document. In general, there are several ways to deal with this. For example, the sender can annotate the ciphertexts in the split commit. Alternatively, the receiver can "pull" the split commit without path, identify the sender and indicate the index of the ciphertext it expects before pulling it. However, most DS's work in the push not pull model and are therefore incompatible with this solution.

Security Considerations

Transcript Hashes The transcript hash with split commits covers FramedContent with a SplitCommit that contains epoch_identifier, proposals and leaf_node. The transcript hash with regular commits covers FramedContent with a Commit that contains proposals, leaf_node and path, as well as the confirmation tag. Since epoch_identifier is derived from the key schedule and the tree hash of the new epoch is mixed into the key schedule, the transcript hash with split commits binds the public keys from path. There is no security-related reason to agree on ciphertexts, so there is no reason to include path in the transctipt hash. Note that group members do agree on content of the ciphertexts in path. That is, they agree on the commit secret hashed into the key schedule (and used to derive epoch_identifier), so they also agree on all path secrets that they can derive (assuming no hash collisions).

IANA Considerations This document has no IANA actions.

Gateway Algorithms and Data Structures Task Force Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Tokyo Institute of Technology & AIST, Tokyo, Japan AIST & PQShield Ltd., Tokyo, Japan PQShield SAS, Paris, France ACM Tokyo Institute of Technology & AIST, Tokyo, Japan AIST, Tokyo, Japan CWI, Amsterdam, Netherlands PQShield SAS, Paris, France Cloudflare, Amsterdam, Netherlands ACM AWS-Wickr, New York, NY, USA Ruhr-University Bochum, Bochum, Germany Ruhr-University Bochum, Bochum, Germany AWS-Wickr, New York, NY, USA ACM

Acknowledgments TODO acknowledge.