Network Working Group K. Kohbrok Internet-Draft R. Robert Intended status: Informational Phoenix R&D Expires: 24 March 2024 21 September 2023 MIMI Transport draft-kohbrok-mimi-transport-01 Abstract This document defines 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 24 March 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Kohbrok & Robert Expires 24 March 2024 [Page 1] Internet-Draft MT September 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Authentication . . . . . . . . . . . . . . . . . . . . . . . 2 3. Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Endpoint Discovery . . . . . . . . . . . . . . . . . . . . . 3 5. REST Endpoints . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Process Group Message . . . . . . . . . . . . . . . . . . 3 5.2. Welcome Information . . . . . . . . . . . . . . . . . . . 4 5.3. External Commit Information . . . . . . . . . . . . . . . 4 5.4. Verification Key . . . . . . . . . . . . . . . . . . . . 5 5.5. Deliver Connection Request . . . . . . . . . . . . . . . 5 5.6. Deliver Message . . . . . . . . . . . . . . . . . . . . . 5 5.7. Connection KeyPackage Retrieval . . . . . . . . . . . . . 6 5.8. Group KeyPackage Retrieval . . . . . . . . . . . . . . . 6 6. Rate-limiting . . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7.1. Transaction Types . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document describes an HTTP-based transport layer protocol for use with all MIMI sub-protocols. The MIMI transport protocol provides an envelope for for MIMI transaction types and takes care of message authentication. This document also describes the endpoints that are served by the individual MIMI functionalities. 2. Authentication The MIMI transport protocol uses the mutually authenticated mode of TLS to provide authentication for server-to-server communication. TODO: More information specific to how TLS should be used, i.e. mandate best practices that make sense in a mutually authenticated scenario that involves two WebPKI based certificates. Kohbrok & Robert Expires 24 March 2024 [Page 2] Internet-Draft MT September 2023 3. Framing The MIMI transport protocol uses a simple framing structure that includes the transaction payload, as well as a small header that signals the protocol version, as well as the transaction type contained in the envelope. enum { reserved(0), mimi10(1), (65535) } ProtocolVersion; // See the "MIMI Transaction Types" IANA registry for values // e.g. "mimi.delivery-service.add" opaque TransactionType; struct { ProtocolVersion version = mimi10; TransactionType transaction_type; opaque serialized_transaction; } TransactionEnvelope; 4. 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/.well- known/mimi/ds-domain. provider.com could for example answer by providing the domain ds.provider.com (assuming that this is where it responds to the REST endpoints defined below). 5. 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. 5.1. Process Group Message Kohbrok & Robert Expires 24 March 2024 [Page 3] Internet-Draft MT September 2023 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. 5.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. 5.3. External Commit Information GET /external_commit_information Content-type: application/octet-stream Body TLS serialized DSRequest Response TLS serialized DSResponse Kohbrok & Robert Expires 24 March 2024 [Page 4] Internet-Draft MT September 2023 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. 5.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. 5.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. 5.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. Kohbrok & Robert Expires 24 March 2024 [Page 5] Internet-Draft MT September 2023 5.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. 5.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. 6. 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). 7. IANA Considerations IANA has created the following registries: * Transaction Types 7.1. Transaction Types An transaction type denotes the nature of a given payload in the context of the MIMI protocol. The transaction type is a string that is composed of substrings separated by dots. Kohbrok & Robert Expires 24 March 2024 [Page 6] Internet-Draft MT September 2023 The first substring is "mimi", followed by the document that defines the corresponding transaction payload, which in turn is followed by the name of the transaction. The MIMI transaction specified in the MIMI DS document that signals the addition of a client would for example be denoted by the string ~~~ "mimi.delivery-service.add" ~~~ Authors' Addresses Konrad Kohbrok Phoenix R&D Email: konrad.kohbrok@datashrine.de Raphael Robert Phoenix R&D Email: ietf@raphaelrobert.com Kohbrok & Robert Expires 24 March 2024 [Page 7]