Internet-Draft MIMI May 2023
Robert & Kohbrok Expires 10 November 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-robert-mimi-delivery-service-01
Published:
Intended Status:
Informational
Expires:
Authors:
R. Robert
Phoenix R&D
K. Kohbrok
Phoenix R&D

MIMI Delivery Service

Abstract

This document describes the 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 10 November 2023.

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" 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 but also offers the basic functionality that is common to several messaging services. In particular, it offers the following features:

2. Protocol overview

The Delivery Service is designed around an MLS group as a basic entity. The Delivery Service can be used with multiple groups but does not require a link between the groups. All operations of the Delivery Service are relative to a specific group.

2.1. High level functions of the Delivery Service

  • Authentication of group members
  • Validation of handshake messages
  • Ordering of handshake messages
  • Delivery of messages to the Queueing Service
  • Assistance for clients who (re)join a group

2.1.1. Flow

The protocol is designed in a request/response pattern, whereby the client sends a DSRequest message to the Delivery Service and the Delivery Service responds with a DSResponse message. This pattern can easily be used over e.g. RESTful APIs.

Client Delivery Service DSRequest DSResponse
Figure 1: Delivery Service Request/Response scheme

Depending on the client's request, the Delivery Service sends a message to the Queueing Service. This happens whenever a message needs to be fanned out to all other members of a group.

Client Delivery Service Queueing Service DSRequest DSResponse Fanout
Figure 2: Client/Delivery Service communication with fanout

In the federated case, messages to a guest Delivery Service can be proxied via the sender's own Delivery Service.

2.2. High level overview of the operations

  • Group creation/deletion
  • Updating client queue information
  • Assistance to join a group from a Welcome message as a new member
  • Assistance to join a group through an External Commit message as a new member or client of an existing member
  • Adding and removing users to/from a group
  • Adding and removing clients to/from a member of the group
  • Client updates (MLS leaf updates)
  • Assistance to resync a client with a group in case of state loss
  • Sending application messages

2.3. Client removals induced by the Delivery Service

The Delivery Service can remove clients from a group by issuing remove proposals in the following cases:

  • A user has removed a client from its account
  • A user has been deleted
  • The client is removed from the group because it has been inactive for too long

2.4. Authentication

Clients authenticate to the Delivery Service using the signature key from their respective leaf node in the group and a client-specific identifier.

Depending on the operation, one or more kind of client identifier can be used:

  • A leaf index: The client identifier is the leaf index of the client in the group.
  • KeyPackageRef: The client identifier is the KeyPackageRef of the client's KeyPackage.
  • User key hash: The client identifier is the hash of the user's public key.

The identifier is encoded as follows:

enum  {
  leaf_index(0),
  key_package_ref(1),
  user_key_hash(2),
} DSSenderType;

struct {
  DSSenderType sender_type;
  select (DSSenderID.sender_type) {
    case leaf_index
      uint32 leaf_index;
    case key_package_ref
      opaque key_package_ref<V>;
    case user_key_hash
      opaque user_key_hash<V>;
  }
} DSSenderID;

To authenticate, the client signs the corresponding request. The key used to sign/verify a given request depends on the sender_id.

struct {
   DSSenderID sender_id;
   DSRequest request;
   // Signature over DSMessageTBS
   opaque signature<0..255>;
} DSMessage;

struct {
   DSSenderID sender_id;
   DSRequest request;
} DSMessageTBS;

2.5. Request/Response scheme

The various request types, each corresponding to an operation, are combined as follows:

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

The request type is encoded in the DSRequest message as follows:

struct {
  DSRequestType request_type;
  select (DSRequest.request_type) {
    case ds_create_group:
      CreateGroupRequest create_group_request;
    case ds_delete_group:
      DeleteGroupRequest delete_group_request;
    ...
  }
} DSRequest;

3. Operations

3.1. Create group

A request from the client to create a new group on the Delivery Service.

The client sends the following CreateGroupRequest to the Delivery Service:

struct {
  opaque group_id<V>;
  KeyPackage key_package;
  ClientQueueConfig client_queue_config;
  GroupInfo group_info;
} CreateGroupRequest;

The Delivery Service responds with a CreateGroupResponse:

enum {
  invalid_group_id(0),
  invalid_key_package(1),
  invalid_group_info(2),
} CreateGroupResponse;

3.1.1. Validation

The Delivery Service validates the request as follows:

  • The group ID is not empty and is not already in use.
  • The KeyPackage is valid, according to (I-D.ietf-mls-protocol) 13.4.3.2. Joining via External Commits.
  • The GroupInfo is valid, according to (I-D.ietf-mls-protocol) 11.1. KeyPackage validation.

3.2. Delete group

A request from the client to delete a group from the Delivery Service.

3.3. Update queue information

A request from the client to update the queue information for a group. Clients can provision a queue information object to indicate to the Delivery Service how to transmit messages to the client during fanout.

3.4. Further operations

The following operations follow the same pattern as the create group operation but are not fully specified in this version of the document:

  • Add user to group
  • Remove user from group
  • Add client to group
  • Remove client from group
  • Update client
  • Resync client
  • Update client queue information
  • Join from a Welcome message
  • Join from an External Commit message
  • Send message

4. Delivery Service state

For each group hostend on a particular Delivery Service instance, the Delivery Service keeps the following state:

5. Queueing Service

The Queueing Service is a service that is used by the Delivery Service to fan out messages to clients. Each client has a queue that is used to store messages for later retrieval by the client. The group state on the Delivery Service contains client queue information for each client of a group. This information is forwarded to the Queueing Service along with the message during message fanout. The information is opaque to the Delivery Service and is only used by the Queueing Service to deliver the message to the client.

Note that this document uses the term "client queue" to refer to an abstract mechanism to forward messages to clients and does not necessarily imply that an actual queueing mechanism is used.

This document only specifies the interface between the Delivery Service and the Queueing Service. Other aspects of the Queueing Service are not specified in this document.

5.1. Queueing Service protocol

The Queueing Service protocol is a simple request/response protocol used between the Delivery Service and the Queueing Service.

Delivery Service Queueing Service QueueingServiceRequest QueueingServiceResponse
Figure 3: Queueing Service Request/Response scheme

Whenever the Delivery Service has validated an incoming message from a client and starts to fan out the message, it sends the following request to the Queueing Service for every client in the group:

struct {
  opaque client_queue_information<V>;
  MLSMessage message;
} QueueingServiceRequest;

The Queueing Service responds with a QueueingServiceResponse:

enum {
  ok(0),
  invalid_client_queue_information(1),
} QueueingServiceResponse;

In case the Queueing Service considers the client queue information to be in invalid (e.g. because the corresponding user/client has been deleted), it responds with invalid_client_queue_information. Otherwise, it responds with ok.

The Delivery Service can use rejected messages to subsequentially issue remove proposals to remove the client from the group. The Delivery Service rejects Commit messages and application messages until a client has sent a Commit that covers the proposals.

5.2. Queueing service in federated environments

In federated environments, the Queueing Service does not necessarily have to be part of the same domain as the Delivery Service. In this case, the Delivery Service sends requests over an inter-domain transport protocol to the Queueing Service.

6. Privacy preserving message delivery

If the desired mode of operation is for the Delivery Service to learn as little as possible about the groups it serves and their members, the protocol can be extended to protect the group state on the Delivery Service. This can happen through two complementary mechanisms:

In practice, the requests from clients to the Delivery Server are extended with additional parameters, such as decryption keys for the group state and additional pseudonymous user-level authentication.

7. Extensions

The Delivery Service can make use of the following MLS extensions:

Authors' Addresses

Raphael Robert
Phoenix R&D
Konrad Kohbrok
Phoenix R&D