| Internet-Draft | MLS AppSync | July 2024 |
| Barnes & Mahy | Expires 8 January 2025 | [Page] |
One feature that the Messaging Layer Security (MLS) protocol provides is that it allows the members of a group to confirm that they agree on certain data. In this document, we define a mechanism 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. We define a GroupContext extension that captures the state of the application and an AppSync proposal that can be used to update the application state.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://bifurcation.github.io/mls-appsync/draft-barnes-mls-appsync.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-barnes-mls-appsync/.¶
Discussion of this document takes place on the Messaging Layer Security Working Group mailing list (mailto:[email protected]), 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/bifurcation/mls-appsync.¶
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 8 January 2025.¶
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.¶
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.¶
Here, we define two extensions to MLS to facilitate this application design:¶
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 defines a new AppSync proposal. AppSync is a Safe Extension as
defined in Section 2 of [I-D.ietf-mls-extensions], of type
extension_external_proposal.¶
The application_states extension allows the application to inject state
objects into the MLS key schedule. Changes to this state can be made out of
band, or using the AppSync proposal. Using the AppSync proposal ensures that
members of the MLS group have received the relevant state changes before they
are reflected in the group's application_states.¶
NOTE: This design exposes the high-level structure of the application state to MLS. An alternative design would be to have the application state be opaque to MLS. There is a trade-off between generality and the complexity of the API between the MLS implementation and the application. An opaque design would give the application more freedom, but require the MLS stack to call out to the application to get the updated state as part of Commit processing. This design allows the updates to happen within the MLS stack, so that no callback is needed, at the cost of forcing the application state to fit a certain structure. It also potentially can result in smaller state updates in large groups.¶
The state for Each applicationId in the application_states needs to conform
to one of four basic types: an ordered array, an unordered array, a map, or an
irreducible blob. This allows the AppSync proposal to efficiently modify a large
application state object.¶
The content of the application_states extension and the AppSync proposal are
structured as follows:¶
enum {
irreducible(0),
map(1),
unorderedList(2),
orderedArray(3),
(255)
} StateType;
struct {
opaque element<V>;
} OpaqueElement;
struct {
opaque elementName<V>;
opaque elementValue<V>;
} OpaqueMapElement;
struct {
uint32 applicationId;
StateType stateType;
select (stateType) {
case irreducible:
OpaqueElement state;
case map:
OpaqueMapElement mapEntries<V>;
case unorderedList:
OpaqueElement unorderedEntries<V>;
case orderedArray:
OpaqueElement orderedEntries<V>;
};
} ApplicationState;
struct {
ApplicationState applicationStates<V>;
} ApplicationStatesExtension;
struct {
uint32 index;
opaque element<V>;
} ElementWithIndex;
struct {
uint32 applicationId;
StateType stateType;
select (stateType) {
case irreducible:
OpaqueElement newState;
case map:
OpaqueElement removedKeys<V>;
OpaqueMapElement newOrUpdatedElements<V>;
case unorderedList:
uint32 removedIndices<V>;
OpaqueElement addedEntries<V>;
case orderedArray:
ElementWithIndex replacedElements<V>;
uint32 removedIndices<V>;
ElementWithIndex insertedElements<V>;
OpaqueElement appenededEntries<V>;
};
} AppSync;
The applicationId determines the structure and interpretation of the contents.
of an ApplicationState object. AppSync proposals
contain changes to this state, which the client uses to update the
representation of the state in application_states.¶
A client receiving an AppSync proposal applies it in the following way:¶
Identify an application_states GroupContext extension which contains the
same application_id state as the AppSync proposal¶
Apply the relevant operations (replace, remove, update, append, insert)
according to the stateType to the relevant parts of the ApplicationState
object in application_states extension.¶
An AppSync for an irreducible state replaces its state element with a new
(possibly empty) newState. An AppSync for a map-based ApplicationState first
removes all the keys in removedKeys and than replaces or adds the elements in
newOrUpdatedElements. An AppSync for an unorderedList ApplicationState first
removes all the indexes in removedIndices, then adds the elements in
addedEntries. Finally an AppSync for an orderedArray, replaces all the
elements (index-by-index) in replacedElements, 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.¶
Note that the application_states extension is updated directly by AppSync
proposals; a GroupContextExtensions proposal is not necessary. A proposal list
that contains both an AppSync proposal and a GroupContextExtensions proposal
is invalid.¶
Likewise a proposal list in a Commit MAY contain more than one AppSync proposal,
but no more than one AppSync proposal per applicationId. The proposals are
applied in the order that they are sent in the Commit.¶
AppSync proposals do not need to contain an UpdatePath. An AppSync proposal can be sent by an authorized external sender.¶
The mechanism defined in this document provides strong authenticity, integrity, and change control properties to the application state information it manages. Nobody outside the group can make changes to the application state, and the identity of the group member making each change is authenticated.¶
The application data synchronized via this mechanism may or may not be confidential to the group, depending on whether the AppSync 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.¶
TODO: Register new extension and proposal types.¶
TODO: IANA registry for application_id; register extension and proposal types
as safe extensions¶
TODO: Acknowledgements.¶