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

Copyright Notice

Copyright (c) 2022 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 introduce 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:¶

• 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: The Delivery Service can authenticate group members, reject messages from non-members and enforce group administration policies. Additionally, the Delivery Service can be linked to the Authentication Service to enforce more policies and validation rules.¶
• Privacy-preserving message delivery: The Delivery Service can deliver messages to the intended recipients without learning the identity of group members, in particular the sender or the recipients of messages. This feature is optional and is compatible with most other features, such as assistance and validation.¶
• 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 accesible by all clients.¶
• Multi-device capable: The Delivery Service can be used by multiple devices of the same users and supports adding and removing devices of a user.¶
• A Queueing Service subcomponent that can be used to implement a queueing service for messages that are delivered asynchronously, particularly in federated environments, as well as the protocol between the Delivery Service and the Queueing Service.¶

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

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;

struct {
   opaque group_id<V>;
   uint32 timestamp;
   DSSenderID sender_id;
   // Signature over DSAuthTokenTBS
   opaque signature<0..255>;
} DSAuthToken;

struct {
   opaque group_id<V>;
   uint32 timestamp;
   DSSenderID sender_id;
} DSAuthTokenTBS;

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

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

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

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

4. Delivery Service state

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

• The public MLS ratchet tree of the group¶
• The GroupInfo of the current epoch¶
• Past group states (for members who join through a Welcome message)¶
• Client queue information (for message fanout via the Queueing Service)¶
• Proposal store that stores standalone proposals of the current epoch¶
• Extensions (TBD)¶

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

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

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

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

• Unlinking member credentials from credentials issued by the Authentication Service, providing pseudonimity at the Delivery Service level¶
• Encrypting the group state with a key that is only known to the group members, providing encryption at rest¶

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

• Example: Group administration extension¶
• TBD¶

Authors' Addresses