MIMI Delivery Service

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 9 May 2024.¶

Copyright Notice

Copyright (c) 2023 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

The MLS protocol document specifies a protocol between two or more clients. The MLS architecture document introduces an abstract concept of a "Delivery Service" (DS) that is specifically responsible for ordering handshake messages and more generally for delivering messages to the intended recipients.¶

This document describes a Delivery Service that performs the mandated ordering of handshake messages and uses MLS to implement a variety of other features:¶

• A protocol between clients and the Delivery Service that allows clients to interact with the Delivery Service, including the specific wire format of the messages. The protocol is specifically designed to be operated in a decentralized, federated architecture but can be used in single instances as well.¶

• Assistance for new joiners of a group: The Delivery Service can keep and update state such as the public ratchet tree, group extensions, etc.¶

• Message validation: The Delivery Service can inspect and validate handshake messages and reject malformed, invalid or malicious messages.¶

• Built-in authentication of group members and policy enforcement: The Delivery Service can authenticate group members and reject messages from non-members. Additionally, the Delivery Service can be linked to the Authentication Service to enforce more policies and validation rules.¶

• Scalability: The protocol makes no assumption about whether the Delivery Service runs as a single instance or as a cluster of instances.¶

• Network fluid: While the Delivery Service would typically run as a server-side component, the only requirement is that it is accessible by all clients.¶

• Transport agnostic: Messages between clients and the Delivery Service can be sent via an arbitrary transport protocol. Additionally, in the federated case, client messages to a guest Delivery Service can be forwarded by a client's local instance of this service.¶

TODO: Make use of MUST/SHOULD, etc. throughout.¶

2. Terminology

This document uses the terminology defined in [RFC9420] with the following additions:¶

• DS Domain: Fully qualified domain name as defined in [RFC2181] that represents the DS. This does not necessarily have to be the domain under which the DS is reachable on the network. Discovering that domain is the responsibility of the transport protocol over which the MIMI DS protocol runs. TODO: client identifiers definitions are preliminary.¶

• Client: An MLS client with a unique client identifier.¶

• Client identifier: An octet string that uniquely identifies the client and that maps to the DS domain of the client's DS.¶

3. Interfaces

The MIMI DS protocol inherits the proposal-commit logic from MLS. Any party that is either a group member, or that was added as an external sender can propose changes to the group such as the addition, removal, or update of clients. Group members can then change the group state in a commit operation. A commit MUST include all valid previously received proposals, as well as any valid proposals that the committing client wants to add to the commit.¶

The MIMI DS tracks the state of individual MLS groups on a hub by storing proposals and processing commits.¶

Any party (including group members and external senders) can send requests for the current group information (an MLS GroupInfo, required for clients to join the group without the help of a group member) or request key material (MLS KeyPackages, required by group members to add new group members) of the DS' clients.¶

Group members and external senders can send proposals to the group. The MIMI DS protocol supports any MLS proposal supported by the specific group in question. The proposals specified in [RFC9420] provide the baseline operations:¶

• Add proposals (to add new group members)¶

• Remove proposals (to remove existing group members)¶

• Update proposals (to update a group members's key material)¶

• PSK proposals (to inject additional key material into the group)¶

• Re-Init proposals (to re-initialize the group, e.g. with a new ciphersuite)¶

• Group Context Extensions (to modify data in GroupContext Extensions, e.g. to add/remove/update external senders)¶

TODO: We might want to allow non-group members to propose adding themselves (NewMemberProposal).¶

Additional proposals may be added via MLS' extension mechanism.¶

Group members can send commits (which can include any of the proposals listed above), as well as application messages.¶

Clients that are not group members can send an (external) commit to add themselves to a group.¶

Group members can send an external commit to re-join the group (e.g. if they have previously lost state, or their group state was corrupted).¶

The DS will verify all proposals, commits and application messages as described in [RFC9420] and fan them out to the rest of the group.¶

4. Architecture and protocol overview

The MIMI DS protocol allows interoperability between a hub which hosts a group conversation and one or more guest DSs which are home to one or more of the conversation's group members. Underlying each group conversation is an MLS group that facilitates end-to-end encryption and authentication between group members.¶

The main purpose of the MIMI DS protocol thus is to ensure that guest clients can participate in the group. With MLS as the underlying protocol, this means that the MIMI DS protocol is primarily concerned with the fan-out of MLS messages (both from and to guest clients), as well the assistance of guest clients in joining MLS groups.¶

The MIMI DS protocol requires clients to send MLS messages as PublicMessages (with the exception of messages with content type application). This allows the hub to track the MLS group state in the same way as a client would, enabling it to keep an up-to-date and fully authenticated list of members, as well as provide the full MLS group state to joining group members, even for those joining via external commit. In addition, the DS can verify messages and enforce access control policies on group operations.¶

struct {
  opaque token<V>;
} FanoutAuthToken

5. Security properties overview

The MIMI DS protocol provides a number of security guarantees.¶

6. Framing and processing overview

enum {
  ds_delete_group(0),
  ...
} DSRequestType;

struct {
  DSRequestType request_type;
  select (DSRequestBody.request_type) {
    case ds_delete_group:
      DeleteGroupRequest delete_group_request;
    ...
  }
} DSRequestBody;

struct {
  DSProtocolVersion version;
  DSRequestBody request_body;
  DSAuthData authentication_data;
} DSRequest;

enum {
  Unauthenticated,
  ClientSignature,
} DSAuthType;

struct {
  DSAuthType auth_type;
  select (DSAuthData.auth_type) {
    case Unauthenticated:
      struct {};
    case ClientSignature:
      uint32 sender_index;
      opaque signature<0..255>;
  }
} DSAuthData;

struct {
  DSProtocolVersion protocol_version;
  DSRequestBody request_body;
  u32 sender_index
} ClientSignatureTBS

struct {
  DSProtocolVersion protocol_version;
  DSResponseBody response_body;
} DSResponse

enum DSResponseType {
  Ok,
  Error,
  WelcomeInfo,
  ExternalCommitInfo
  KeyPackages,
}

struct DSResponseBody {
  DSResponseType response_type;
  select (DSResponseBody.response_type) {
    case Ok:
      struct {};
    case Error:
      DSError error;
    case WelcomeInfo:
      optional<Node> ratchet_tree<V>;
    case ExternalCommit:
      MLSMessage: group_info;
      optional<Node> ratchet_tree<V>;
    case KeyPackages:
      KeyPackage key_packages<V>;
  }
}

struct {
  TODO: Operation specific errors.
} DSError

struct {
  DSProtocolVersion protocol_version;
  opaque recipient_ids<V>;
  FanoutAuthToken fanout_auth_tokens<V>;
  MLSMessage mls_message;
} DSFanoutRequest

enum {
  Ok,
  Error,
} DSFanoutResponseType

struct {
  TODO: Fanout error types
} DSFanoutError

struct DSFanoutResponseBody {
  DSFanoutResponseType response_type;
  select (DSFanoutResponseBody.response_type) {
    case Ok:
      struct {};
    case Error:
      DSFanoutError error;
  }
}

struct {
  DSProtocolVersion protocol_version;
  DSResponseBody response_body;
} DSFanoutResponse

7. DS assisted joining

To verify and deliver messages, authenticate clients as members of a group and to assist clients that want to join a group, the DS keeps track of the state of each group for which it is the hub. More specifically, it keeps track of the group's ratchet tree, the group's GroupContext and other information required to produce a valid GroupInfo for the current group epoch. It does this by processing incoming MLS messages in the same way a member of that group would, except of course that the DS doesn't hold any private key material.¶

While MLS messages are sufficient to keep track of most of the group information, it is not quite enough to create a GroupInfo. To allow the DS to provide a valid GroupInfo to externally joining clients, it additionally requires clients to provide the remaining required information. Concretely, it requires clients to upload the Signature and the GroupInfo extensions. Clients need to send this information whenever they send an MLS message (i.e. an MLSMessage struct) that contains a commit.¶

struct {
  Extension group_info_extensions<V>;
  opaque Signature<V>;
} PartialGroupInfo

The combination of a commit and a partial group info is called an MLSGroupUpdate.¶

struct {
  MLSMessage commit;
  PartialGroupInfo partial_group_info;
} MLSGroupUpdate

Whenever the DS receives an MLSGroupUpdate, it must verify that the MLSMessage contains a PublicMessage with a commit and that commit and partial group info are valid relative to the existing group state according to the MLS specification.¶

TODO: For now there is no distinct endpoint to obtain authentication material that allows the DS to authenticate clients. This would be part of the AS design.¶

By tracking the group information in this way, the DS can help clients that join via external commit by providing them with a ratchet tree and a group into.¶

Similary, clients that wish to join a group via a regular invite (i.e. a Welcome message) have already received a GroupInfo and can obtain a ratchet tree from the DS.¶

In the time between a client being added to a group by a commit and the client wanting to join the group, the group state can have progressed by one or more epochs. As a consequence, the DS MUST keep track of epochs in which clients are added and store the corresponding group states until each client has successfully joined.¶

8. Proposals and DS-initiated operations

MLS relies on a proposal-commit logic, where the proposals encode the specific action the sending client intends to take and the commit then performs the actions of a set of commits.¶

The advantage of this approach is that the sender of the proposal does not have to be the committer, which allows, for example, the DS to propose the removal of a client, or a client to propose that it be removed from the group. Note that the latter example is the only way that a client can remove itself (i.e. leave) from a group.¶

Such proposals, where the original sender differs from the sender of the commit are called "proposal by reference", or "proposal by value" if the proposal is sent by the committer as part of the commit itself.¶

The following sections detail operations that can be performed by clients, so each operation that entails a change to the group state (with the exception of the self remove operation) require the sender to perform a commit, where the semantics of the operation are reflected as proposals by value. For example, the commit in the AddClientsRequest must only contain Add proposals.¶

If a client receives a valid standalone proposal, it MUST store it and verify that the next commit includes said proposal.¶

TODO: Be more specific about proposal validation. Also, we might want to allow the server to rescind a proposal.¶

Whenever a client sends a commit as part of an operation, it MUST include all stored proposals by reference, such as server-initiated Remove proposals, or proposals sent as part of a self-remove operation.¶

TODO: Proposals by reference pose a problem in the context of external commits, as, even if the external committer had access to all proposals in an epoch, it wouldn't be able to verify them, thus potentially leading to an invalid external commit. A solution could be introduced either as part of the MIMI DS protocol, or as an MLS extension. The latter would be preferable, as other users of MLS are likely going to encounter the same problem.¶

To allow the DS to send proposals, all groups MUST contain an external_senders extension as defined in Section 12.1.8.1. of [RFC9420] that includes the DS' credential and its signature public key.¶

TODO: We might also want to mandate that the group includes credentials of guest DSs involved in the group. However, for them to be able to send proposals, we'd need an additional operation/endpoint that the DS exposes.¶

TODO: Details of the DS credential, distribution, etc. A BasicCredential with the FQDN of the DS would probably be sufficient.¶

The DS can simply create such proposals itself based on the group information and distribute it to all group members via regular DSFanoutRequests.¶

9. Client-initiated operations

The DS supports a number of operations, each of which is represented by a variant of the DSRequestType enum and has its own request body.¶

enum {
  ds_delete_group,
  ds_proposals,
  ds_commits,
  ds_send_message,
  ds_key_packages,
  ds_group_info,
} DSRequestType;

struct {
  DSRequestType request_type;
  select (DSRequestBody.request_type) {
    case ds_delete_group:
      DeleteGroupRequest delete_group_request;
    case ds_proposals:
      ProposalRequest proposal_request;
    case ds_commits:
      CommitRequest commit_request;
    case ds_send_message:
      SendMessageRequest send_message_request;
    case ds_key_packages:
      KeyPackagesRequest key_packages_request;
    case ds_key_packages:
      GroupInfoRequest group_info_request;
  }
} DSRequestBody;

struct {
  MLSGroupUpdate group_update;
} DeleteGroupRequest;

struct {
  MLSMessage proposals<V>;
} AddClientsRequest;

struct {
  MLSGroupUpdate group_updates<V>;
  MLSMessage welcome_messages<V>;
} RemoveClientsRequest;

struct {
  MLSMessage application_message<V>;
} SendMessageRequest;

struct {
  ClientID client_identifiers<V>;
} KeyPackagesRequest;

struct {} GroupInfoRequest;

10. DSFanoutRequests

After the DS has processed an incoming MLSMessage, it prepares a DSFanoutRequest as described in Section 6.¶

For DS to DS communication, the MIMI DS protocol relies on the underlying transport protocol to provide mutual authentication.¶

11. Rate-limiting and spam prevention

All requests (with the exception of the VerificationKeyRequest) can be explicitly authenticated by the recipient through the verification of a signature. This means that recipients can follow a rate-limiting strategy of their choice based on the sender's identity.¶

For DSRequests, the DS can rate-limit on a per group-level, per-DS level (reducing the messages from all clients belonging to a single DS), or even based on individual clients.¶

For DSFanoutRequests, rate-limiting or blocking can happen based on the identity of the sending DS, or it can happen on a per-group basis, where the recipient only blocks messages from a particular group.¶

Such rate-limiting can happen by decision of the DS itself, or on the request of its local clients. For example, a client might wish to block connection requests from one specific other client without blocking connection requests from all other clients of that DS.¶

12. Security considerations

TODO: There is currently no consensus in the MIMI w.r.t. the security goals we want to reach.¶

The underlying MLS protocol provides end-to-end encryption and authentication for all MLSMessages, as well as group state agreement.¶

13. Normative References

[I-D.ietf-mls-protocol]

Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", Work in Progress, Internet-Draft, draft-ietf-mls-protocol-20, 27 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-20>.

[RFC2181]

Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/rfc/rfc2181>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

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

Authors' Addresses