Efficient Updates to Messaging Layer Security GroupContext Extension

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 April 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Messaging Layer Security (MLS) allows a group of clients to authenticate each other and establish shared secret state [RFC9420]. 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).¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terms from [RFC9420]. 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.¶

3. GroupContextDiff

This document defines a new GroupContextExtensionsDiff proposal. It is not a Safe Extension as defined in Section 2 of [I-D.ietf-mls-extensions], because it can modify any GroupContext extension, including those defined in [RFC9420]. The GroupContextExtensionsDiff proposal requires an UpdatePath, and may be sent by an authorized external sender.¶

enum {
    remove(0),
    add(1),
    replace(2),
    diff(3),
    (255)
} OperationType;

uint8 DiffType;

struct {
    /* MUST be a GroupContext extension */
    ExtensionType extension_type;
    OperationType operation;
    select (operation) {
        case remove:
            struct {};
        case add:
            opaque extension_data<V>;
        case replace:
            opaque extension_data<V>;
        case diff:
            opaque diff_data<V>;
    };
} ExtensionDiff;

struct {
    ExtensionDiff group_context_extension_diffs<V>;
} 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 Section 4 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 [RFC9420].¶

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

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

struct {
  opaque element<V>;
} OpaqueElement;

struct {
  opaque elementName<V>;
  opaque elementValue<V>;
} OpaqueMapElement;

struct {
      OpaqueElement removedKeys<V>;
      OpaqueMapElement newOrUpdatedElements<V>;
} MapDiff;

struct {
  uint32 index;
  opaque element<V>;
} ElementWithIndex;

struct {
  ElementWithIndex replacedElements<V>;
  uint32 removedIndices<V>;
  ElementWithIndex insertedElements<V>;
  OpaqueElement appendedEntries<V>;
} ListDiff;

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

6. IANA Considerations

7. Normative References

[I-D.ietf-mls-extensions]

Robert, R., "The Messaging Layer Security (MLS) Extensions", Work in Progress, Internet-Draft, draft-ietf-mls-extensions-05, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-mls-extensions-05>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9420]

Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

Acknowledgments

• TODO: Acknowledgements.¶

Authors' Addresses