]> Cisco

rlb@ipv.sx

Rohan Mahy Consulting Services

rohan.ietf@gmail.com

Security Messaging Layer Security GroupContext GroupContextExtensions diffs efficient diffs The Messaging Layer Security (MLS) protocol allows the members of the group to agree on a set of GroupContext extensions. MLS includes a mechanism to do a wholesale replacements of all GroupContext extensions, but not to modify individual extensions. In this document, we define a mechanism that allows implementations to add, update, and remove each element of the GroupContext individually. This also makes it practical for applications using MLS to exploit this feature of MLS to ensure that the group members are in agreement on the state of the application in addition to MLS-related state. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Messaging Layer Security (MLS) allows a group of clients to authenticate each other and establish shared secret state . One of the primary security benefits of MLS is that the MLS key schedule confirms that the group agrees on certain metadata, such as the membership of the group. Members that disagree on the relevant metadata will arrive at different keys and be unable to communicate. Applications based on MLS can integrate their state into this metadata in order to confirm that the members of an MLS group agree on application state as well as MLS metadata. Unfortunately this state can only be modified using the GroupContextExtensions Proposal, which needs to include the entire GroupContext. This may include dozens of individual extensions and may be quite large. MLS clients should be able to modify orthogonal aspects of the GroupContext in separate Proposals and should not need to send large amounts of data for a small change. Here, we define a new MLS proposal type GroupContextExtensionsDiff. This proposal type allows modification on a per extension basis. It also allows GroupContext extensions to define simple diff formats (for example, to add, remove, and update elements in a list or items in a map).

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. This document uses terms from . Some are similar or may be confusing, so they are summarized here:

• GroupContext: The state of the group agreed on in a given epoch
• GroupContext extension: A (type, value) tuple included in the GroupContext
• ExtensionType: A two-byte identifier for the type of a GroupContext extension
• GroupContextExtensions proposal: A proposal to remove all of the extensions in the group's GroupContext and replace them with a new set of GroupContext extensions

Currently, the GroupContextExtensions proposal is the only mechanism defined for updating a group's GroupContext extensions.

GroupContextDiff This document defines a new GroupContextExtensionsDiff proposal. It is not a Safe Extension as defined in , because it can modify any GroupContext extension, including those defined in . The GroupContextExtensionsDiff proposal requires an UpdatePath, and may be sent by an authorized external sender. ; case replace: opaque extension_data; case diff: opaque diff_data; }; } ExtensionDiff; struct { ExtensionDiff group_context_extension_diffs; } GroupContextExtensionsDiff; ]]> The semantics of OperationType are as follows:

• remove means that the GroupContext extension was present, and will be completely absent from the GroupContext.
• add means that the GroupContext extension was absent, and will be present with the value provided in extension_data.
• replace means that the GroupContext extension was present and will be completely replaced with the new value in extension_data
• diff means that the GroupContext extension will be modified according to the diff format defined by that extension. (Two concrete diff formats are defined in which extension designers are free to use or not use.)

A single GroupContextExtensionsDiff proposal can contain changes to multiple extensions. Likewise a single Commit can include multiple GroupContextExtensionsDiff proposals, however a single Commit MUST NOT include multiple GroupContextExtensionsDiff proposals which refer to the same ExtensionType. A GroupContextExtensions proposal MUST NOT appear in a commit with any GroupContextExtensionsDiff proposal. The motivation for allowing multiple extensions in a single GroupContextExtensionsDiff proposal is to allow a client to modify multiple extensions in a single "transaction". A common example of this is to add a GroupContext extension while also adding that extension to the required_capabilities GroupContext extension. A proposal which removes a GroupContext extension that is present in the required_capabilities list is invalid. Adding a required capability that is not supported by all group members is already forbidden by . TODO: Fix the below

• There's nothing in MLS that says that there can only be one extension per ExtensionType in the GroupContext. If there were duplicates, this would be ambiguous. Could fix this with something dumb like (a) defining a noop OperationType and (b) saying that the n-th ExtensionDiff of a given type affects the n-th entry. That has the benefit of degrading to the normal thing in the sane case.

Diff Formats The following two subsections define two Diff Formats for very common data structures. Both of the Diff Formats defined below use the following struct for an opaque byte string. ; } OpaqueElement; ]]>

Map Diff Format This Diff Format logically represents a map or dictionary that is not allowed to have duplicate map keys. ; opaque elementValue; } OpaqueMapElement; struct { OpaqueElement removedKeys; OpaqueMapElement newOrUpdatedElements; } MapDiff; ]]> A diff using this format first removes all the keys in removedKeys and than replaces or adds the elements in newOrUpdatedElements. Removing a non-existant map key renders the diff and its proposal invalid.

List Diff Format This Diff Format logically represents changes to an ordered list. ; } ElementWithIndex; struct { ElementWithIndex replacedElements; uint32 removedIndices; ElementWithIndex insertedElements; OpaqueElement appendedEntries; } ListDiff; ]]> A diff using this format first replaces all the elements (index-by-index) in replacedElements, then the removes the elements in removedIndices according to the then order of the array, then inserts all the elements in insertedElements according to the then order of the array, then finally appends the appendedEntries (in order). All indices are zero-based. For the avoidance of doubt, two insertedElements with the same index will cause the second inserted element to be before the first inserted element. Attempting to insert or replace at a non-existing index renders the diff and its proposal invalid.

Security Considerations The mechanism defined in this document provides strong authenticity, integrity, and change control properties to the state information it manages. No unauthorized parties can make changes to the GroupContext, and the identity of the group member making each change is authenticated. The data synchronized via this mechanism may or may not be confidential to the group, depending on whether the GroupContextExtensionsDiff proposal is sent as an MLS PublicMessage or PrivateMessage. As with application data, applications should generally prefer the use of Private Message. There may be cases, however, where it is useful for intermediaries to inspect application state updates, e.g., to enforce policy.

IANA Considerations

GroupContextExtensionDiff Proposal The gce_diff MLS Proposal Type is used to update Group Context Extensions in a group more efficiently than using a group_context_extensions proposal type. The gce_diff type is updating rather than replacing the extensions.

• Value: 0x000d
• Name: gce_diff
• Recommended: Y
• External: Y
• Path Required: Y

Change to the MLS Extension Types registry This document adds a "Diff" column to the MLS Extension Types registry. In the registration template this will be referred to as "Diff Type". The value value can be "-" indicating no Diff Types are supported, or a value present in the GroupContext Diff Types registry.

GroupContext Diff Types registry The "MLS GroupContext Diff Types" registry lists identifiers for types of difference algorithms to be applied to GroupContext extension data. The diff type field is one byte wide, so valid values are in the range 0x00 to 0xFF. Template:

• Value: The numeric value of the diff type
• Name: The name of the diff type
• Recommended: Same as in Section 17.1 of
• Reference: The document where this extensions is defined

Initial contents:

Value	Name	R	Ref
0x00	reserved	-	RFC XXXX
0x01	list	Y	RFC XXXX
0x02	map	Y	RFC XXXX

Normative References 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. Phoenix R&D This document describes extensions to the Messaging Layer Security (MLS) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-extensions.

Acknowledgments

• TODO: Acknowledgements.