Internet DRAFT - draft-kohbrok-mimi-moh
draft-kohbrok-mimi-moh
Network Working Group K. Kohbrok
Internet-Draft R. Robert
Intended status: Informational Phoenix R&D
Expires: 18 November 2023 17 May 2023
MIMI over HTTPS
draft-kohbrok-mimi-moh-00
Abstract
This document an HTTPS based transport layer for use with 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 18 November 2023.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
Kohbrok & Robert Expires 18 November 2023 [Page 1]
Internet-Draft MoH May 2023
1.1. Transport Security and Authentication . . . . . . . . . . 2
1.2. Endpoint Discovery . . . . . . . . . . . . . . . . . . . 2
1.3. REST Endpoints . . . . . . . . . . . . . . . . . . . . . 2
1.3.1. Process Group Message . . . . . . . . . . . . . . . . 3
1.3.2. Welcome Information . . . . . . . . . . . . . . . . . 3
1.3.3. External Commit Information . . . . . . . . . . . . . 3
1.3.4. Verification Key . . . . . . . . . . . . . . . . . . 4
1.3.5. Deliver Connection Request . . . . . . . . . . . . . 4
1.3.6. Deliver Message . . . . . . . . . . . . . . . . . . . 4
1.3.7. Connection KeyPackage Retrieval . . . . . . . . . . . 5
1.3.8. Group KeyPackage Retrieval . . . . . . . . . . . . . 5
1.4. Rate-limiting . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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.
Kohbrok & Robert Expires 18 November 2023 [Page 2]
Internet-Draft MoH May 2023
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
Kohbrok & Robert Expires 18 November 2023 [Page 3]
Internet-Draft MoH May 2023
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
Kohbrok & Robert Expires 18 November 2023 [Page 4]
Internet-Draft MoH May 2023
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.
Kohbrok & Robert Expires 18 November 2023 [Page 5]
Internet-Draft MoH May 2023
1.4. Rate-limiting
The MoH 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
Email: konrad.kohbrok@datashrine.de
Raphael Robert
Phoenix R&D
Email: ietf@raphaelrobert.com
Kohbrok & Robert Expires 18 November 2023 [Page 6]
