Internet-Draft MT August 2023
Kohbrok & Robert Expires 10 February 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-kohbrok-mimi-transport-latest
Published:
Intended Status:
Informational
Expires:
Authors:
K. Kohbrok
Phoenix R&D
R. Robert
Phoenix R&D

MIMI Transport

Abstract

This document an HTTPS based transport layer for use with the MIMI Protocol.

Discussion Venues

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

Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/.

Source for this draft and an issue tracker can be found at https://github.com/kkohbrok/mimi-transport.

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

Table of Contents

1. Introduction

This document describes an HTTP-based transport layer protocol for use with the Delivery Service protocol specified in draft-robert-mimi-delivery-service, as well as other MIMI-relevant components such as contact discovery.

1.1. Transport Security and Authentication

All HTTP queries described in this document MUST use TLS with version 1.3 or higher to protect confidentiality and authenticity of the payloads. Delivery Service payloads are typically authenticated by the sender through the use of signatures and rely on HTTPS to authenticate the recipient. To prevent forwarding attacks, the payloads of the Delivery Service include both sender and recipient. The provider should thus always verify that the recipient corresponds to its own provider name.

1.2. Endpoint Discovery

A messaging provider that wants to query the endpoint of another messaging provider first has to discover the fully qualified domain name under which Delivery Service of that provider can be reached. It does so by performing a GET request to [provider.com](http://provider.com)/.well-known/mimi/ds-domain. provider.com could for example answer by providing the domain [ds.provider.com](http://ds.provider.com) (assuming that this is where it responds to the REST endpoints defined below).

1.3. REST Endpoints

The following REST endpoints can then be used to access the different functionalities of the Delivery Service.

As the Delivery Service relies on TLS encoded structs, all requests to endpoints described below should be marked as Content-type: application/octet-stream.

All structs and concepts referred to below are defined in draft-robert-mimi-delivery-service, where their underlying functionality is defined in more detail.

1.3.1. Process Group Message

POST /group_operation
Content-type: application/octet-stream

Body
TLS serialized DSRequest

Response
TLS serialized DSResponse

This REST endpoint provides access to all operations associated with an existing MLS group on the Delivery Service such as delivering application messages, adding group members, removing group members, updating key material, etc. The payloads for this endpoint are generally provided (and signed) by a member of the corresponding group rather than the service provider of that member. The exact operation, as well as the target group ID is determined by the payload itself rather than an HTTP header, the path or any other query parameter.

1.3.2. Welcome Information

GET /welcome_information
Content-type: application/octet-stream

Body
TLS serialized DSRequest

Response
TLS serialized DSResponse

Through this endpoint, a provider can obtain information required to join the group for clients that have already received a Welcome message. The DS responds with the group’s RatchetTree, as well as authentication information of existing group members.

1.3.3. External Commit Information

GET /external_commit_information
Content-type: application/octet-stream

Body
TLS serialized DSRequest

Response
TLS serialized DSResponse

Guest providers can use this endpoint to obtain information that allows a client to join a group without a Welcome message from an existing group member.

1.3.4. Verification Key

GET /verification_key
Content-type: application/octet-stream

Body
TLS serialized VerificationKeyRequest

Response
TLS serialized VerificationKeyResponse

This allows guest providers to obtain the verification key of this provider. This allows other providers to authenticate queries originating from this provider.

1.3.5. Deliver Connection Request

POST /connection_request
Content-type: application/octet-stream

Body
TLS serialized QueueingServiceRequest

Response
TLS serialized QueueingServiceResponse

This endpoint lets other providers deliver connection establishment request to clients of this provider.

1.3.6. Deliver Message

POST /deliver_message
Content-type: application/octet-stream

Body
TLS serialized QueueingServiceRequest

Response
TLS serialized QueueingServiceResponse

An owning provider can deliver messages from one of its owned groups to this endpoint, if one of the group’s clients is associated with this provider.

1.3.7. Connection KeyPackage Retrieval

POST /connection_key_packages
Content-type: application/octet-stream

Body
TLS serialized ConnectionKeyPackageRequest

Response
TLS serialized ConnectionKeyPackageResponse

Allows another provider to retrieve KeyPackages for use during the connection establishment process between two users.

1.3.8. Group KeyPackage Retrieval

POST /group_key_packages
Content-type: application/octet-stream

Body
TLS serialized GroupKeyPackageRequest

Response
TLS serialized GroupKeyPackageResponse

Allows another provider to retrieve KeyPackages that can be used to add another user or one of its clients to an existing group.

1.4. Rate-limiting

The MIMI transport protocol itself doesn’t include any rate-limiting measures. However, traditional rate-limiting (e.g. based on sender IP) can be applied, as well as rate-limiting based on information in the message body such as Group ID (e.g. in the case of the /welcome_information endpoint) or group member (in the case of the /group_operation endpoint). More fine-grained rate-limiting can be applied through the use of the emerging Privacy Pass protocol (draft-ietf-privacypass-auth-scheme).

Authors' Addresses

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