Messaging Layer Security                                       R. Barnes
Internet-Draft                                                     Cisco
Intended status: Informational                                   R. Mahy
Expires: 24 April 2025                    Rohan Mahy Consulting Services
                                                         21 October 2024


  Efficient Updates to Messaging Layer Security GroupContext Extension
                       draft-mahy-mls-gce-diff-00

Abstract

   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

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://rohanmahy.github.io/mls-gce-diff/draft-mahy-mls-gce-
   diff.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-mahy-mls-gce-diff/.

   Discussion of this document takes place on the Messaging Layer
   Security Working Group mailing list (mailto:mls@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/mls/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/mls/.

   Source for this draft and an issue tracker can be found at
   https://github.com/rohanmahy/mls-gce-diff.

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



Barnes & Mahy             Expires 24 April 2025                 [Page 1]

Internet-Draft           MLS GroupContext diffs             October 2024


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  GroupContextDiff  . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Diff Formats  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Map Diff Format . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  List Diff Format  . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  GroupContextExtensionDiff Proposal  . . . . . . . . . . .   7
     6.2.  Change to the MLS Extension Types registry  . . . . . . .   7
     6.3.  GroupContext Diff Types registry  . . . . . . . . . . . .   8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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



Barnes & Mahy             Expires 24 April 2025                 [Page 2]

Internet-Draft           MLS GroupContext diffs             October 2024


   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.











Barnes & Mahy             Expires 24 April 2025                 [Page 3]

Internet-Draft           MLS GroupContext diffs             October 2024


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.





Barnes & Mahy             Expires 24 April 2025                 [Page 4]

Internet-Draft           MLS GroupContext diffs             October 2024


   *  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;




Barnes & Mahy             Expires 24 April 2025                 [Page 5]

Internet-Draft           MLS GroupContext diffs             October 2024


4.1.  Map Diff Format

   This Diff Format logically represents a map or dictionary that is not
   allowed to have duplicate map keys.

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

   struct {
         OpaqueElement removedKeys<V>;
         OpaqueMapElement newOrUpdatedElements<V>;
   } 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.

4.2.  List Diff Format

   This Diff Format logically represents changes to an ordered list.

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

   struct {
     ElementWithIndex replacedElements<V>;
     uint32 removedIndices<V>;
     ElementWithIndex insertedElements<V>;
     OpaqueElement appendedEntries<V>;
   } 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.




Barnes & Mahy             Expires 24 April 2025                 [Page 6]

Internet-Draft           MLS GroupContext diffs             October 2024


   Attempting to insert or replace at a non-existing index renders the
   diff and its proposal invalid.

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

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

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






Barnes & Mahy             Expires 24 April 2025                 [Page 7]

Internet-Draft           MLS GroupContext diffs             October 2024


6.3.  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 [RFC9420]

   *  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 |
                    +-------+----------+---+----------+

                                  Table 1

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



Barnes & Mahy             Expires 24 April 2025                 [Page 8]

Internet-Draft           MLS GroupContext diffs             October 2024


   [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

   Richard Barnes
   Cisco
   Email: rlb@ipv.sx


   Rohan Mahy
   Rohan Mahy Consulting Services
   Email: rohan.ietf@gmail.com
































Barnes & Mahy             Expires 24 April 2025                 [Page 9]