| Internet-Draft | MIMI Design Requirements | July 2023 |
| Mahy | Expires 11 January 2024 | [Page] |
This document describes design requirements on the More Instant Messaging Interoperability (MIMI) Working Group provider-to-provider message transport protocol. These requirements are based on the requirements of the group encryption using the Messaging Layer Security (MLS) protocol and requirements for high volume message transfer which would be needed with large messaging providers.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mimi-transport-design-reqs/.¶
Discussion of this document takes place on the MIMI Working Group mailing list (mailto:[email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at https://www.ietf.org/mailman/listinfo/mimi/.¶
Source for this draft and an issue tracker can be found at https://github.com/rohan-wire/mimi-groupchat/.¶
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 11 January 2024.¶
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.¶
As described in the Group Chat Framework for More Instant Messaging Interoperability (MIMI) [I-D.mahy-mimi-group-chat], the basic operations of users creating, joining, and leaving a chat, map to specific primitives in the Messaging Layer Security (MLS) protocol [I-D.ietf-mls-protocol]. Some of these primitives have implications on the design of the MIMI inter-provider message transport protocol.¶
This document describes constraints and requirements to be used during the design of that protocol.¶
The terms MLS client, MLS group, Proposal, Commit, External Commit, external join, group_id, epoch, Welcome, KeyPackage, GroupInfo, and GroupContext have the same meanings as in the MLS protocol [I-D.ietf-mls-protocol].¶
An MLS KeyPackage (KP) is used to establish initial keying material in a group, analogous to DoubleRatchet prekeys, except one KP is used for a client per group but each recipient does not require a separate one.¶
An MLS GroupInfo (GI) object is the information needed for a client to externally join an MLS group using an External Commit. The GroupInfo changes with each MLS epoch.¶
The terms in this document and [I-D.ralston-mimi-terminology] have not yet been aligned.¶
A room, also known as a chat room or group chat, is a virtual space users figuratively enter in order to participate in text-based conferencing. When used with MLS it typically has a 1:1 relationship with an MLS group.¶
A single human user or automated agent (ex: chat bot) with a distinct identifiable representation in a room.¶
An instant messaging agent instance associated with a specific user account on a specific device. For example, the mobile phone instance used by the user @[email protected].¶
For a given room, the owning provider is the provider which is authoritative for room policy and which determines which Commit to accept if more than one valid Commit arrives for the same epoch.¶
The rest of this document is separated into sections based on distinct handling requirements within the protocol.¶
Some primitives request use of an exclusive resource. These could be handled differently from other requests in a high availability environment.¶
Claiming single-use KeyPackages requires that the target's domain is online, that the requestor has consent to claim them, and there are sufficient KeyPackages uploaded by the client that are valid and have parameters that are compatible with the request.¶
One provider should be able to claim all the KeyPackages needed by the original requestor, for all users in a target provider in a single request. For example, say Alice at provider A wants KeyPackages for:¶
Provider A should be able to send a single request to provider B, for KeyPackages for all of Bobby, Betty, Bruce, and Bella's clients.¶
Below is the list of fields which should be provided when claiming KeyPackages:¶
If authorized, this should return a list of KeyPackages (which comply with the restrictions) for all clients of the requested users.¶
If the requestor is authorized to request KeyPackages from the target user, there should be either an error or a KeyPackage for each client of the target user.¶
For example, response from provider B:¶
Note: A similar API could be used between clients and their own provider. If so, if the client requests KeyPackages for their own user, presumably the client wants KeyPackages for all of their clients except the requesting client. This guidance is out-of-scope for MIMI, but is a sufficient gotcha to merit a note.¶
In the DoubleRatchet [DoubleRatchet] protocol, a client requests prekeys for every other client with which it communicates (one prekey for correspondant). If A, B, C, D, and E have never communicated and want to form a room, each client needs a prekey for the other 4 (20 prekeys total). However the prekeys are used for a session regardless of the number of rooms involved. If A, B, C, and X form a new room, only 6 new prekeys are needed.¶
In MLS, only one KeyPackage per member is needed per group, but a different KeyPackage is needed per group. If A, B, C, D and E join a group, only 5 KeyPackages are required. However when A, B, C, and X form a different group, 4 more KeyPackages are needed.¶
The implication is that it is harder to rate-limit the consumption of KeyPackages in MLS, but straightforward to associate KeyPackages with consent relationships and specific uses. KeyPackages are needed even when a client is temporarily offline, so KeyPackage exhaustion is an important DoS attack vector we want to prevent.¶
Sending a Commit requires exclusive access to the group's epoch on the owning provider, which needs to be online and available. By exclusive access, we mean that if multiple otherwise valid commits are received for the same epoch, only one of them can be accepted.¶
The most efficient way to send a Commit is as a Commit bundle.
A Commit bundle consists of a Commit, GroupInfo, an optional Welcome, and
enough information necessary so the responsible domain can provide the
ratchet_tree associated with the group.¶
| Number | Component |
|---|---|
| 1 | Commit |
| 0 or 1 | Welcome |
| 1 | GroupInfo |
| 1 | ratchet_tree container |
The Welcome is
the Welcome that the Committer would send if the Commit is accepted, and the
GroupInfo object is the new GroupInfo that would be valid in the new epoch if the
Commit is accepted. The GroupInfo needs to include an external_pub extension
so it can be used for external joins in the new epoch if the Commit is accepted.¶
If a Commit bundle is rejected because the epoch has already advanced, the Commit, and the tentative Welcome and GroupInfo need to be discarded by the requesting client. If the operation represented by the rejected Commit is still relevant, the requester can regenerate a new Commit bundle in the new epoch.¶
The GroupInfo logically contains the following fields, nested as shown:¶
GroupInfo¶
The size of a GroupInfo without a ratchet_tree extension is relatively modest
and need not vary with the number of clients in the group. Even if it includes
a somewhat complicated room_policy extension
(proposed in [I-D.mahy-mls-room-policy-ext]), the size of that extension typically
would not increase for each member of the group. By contrast, the ratchet_tree
extension grows linearly with the number of clients in the group. Depending on
the size of credentials used, it can easily grow to several megabytes for a large group.
Therefore, the MIMI transport protocol should require that the ratchet_tree is
conveyed outside of the GroupInfo.¶
Instead of sending the ratchet_tree directly, we can include a ratchet_tree container
object in the Commit bundle. This could have options for various ways to convey
a ratchet_tree: a complete ratchet tree, a compressed version, a delta from or patch to the
previous epoch's tree, or a reference to a separate service. This provides future
proofing. We will need to also come to consensus on a mandatory-to-implement option.
Including the entire tree is wasteful and likely to have real performance impacts for
large groups; requiring that the provider compute the ratchet tree itself is likely a
non-starter for providers with a high-volume of traffic.¶
Note: Sending a Proposal does NOT require exclusive access to the epoch. Assume a group contains clients A, B, and C. A proposal from A to remove B and a proposal from B to remove A are independently valid proposals, but together they would be incompatible and the combination would be invalid.¶
Requesting the GroupInfo from the owning provider requires the owning provider to be online, and requires that the requesting user has authorization to receive this (privacy sensitive) information. This request is expected to be followed immediately by a Commit bundle, except in cases like a sudden network loss or client crash.¶
The owning provider should make the GroupInfo available to a single requestor for a short amount of time (ex: from a handful of seconds to 30 seconds). The provider might put other restrictions in place to preventing abuse of this primitive, for example denying repeated GroupInfo requests in the absense of corresponding Commits.¶
The provider requesting the GroupInfo needs to be able to present a joining authorization passcode if one was included by the joining user. For more discussion of joining links and codes, see Section 7.3.¶
Ordinary messages and a handful of other events need to be sent provisionally from non-owning providers to the owning provider for any room, as the owning provider still has the ability to refuse these messages or events.¶
MLS application messages which are sent in the current epoch, could be sent by a client Alice to provider A, while simultaneously a Commit is arriving at owning provider B. Provider A should still deliver the messages to provider B, which should accept messages from authorized members, even if the message is from a slightly older epoch. However, if the Commit removed Alice from the group, Alice's message should be rejected. In practice, most provisional messages sent in good faith will be accepted. Therefore the protocol should send these messages efficiently (in bulk) between providers and communicate rejections asynchronously.¶
MLS Proposals should also be sent provisionally. If Alice sends a Proposal, Alice knows this Proposal was accepted or rejected only after receiving the Commit for the next epoch. The next Commit will either include the Proposal (indicating acceptance) or not (indicating rejection or incompatibility).¶
Messages and events which have been accepted by the owning provider then need to be fanned-out to the relevant providers, which in turn fan-out the messages and events to their relevant clients. Below are a list of events that would be fanned out:¶
room policy changes¶
In commercial messaging deployments, fanout messages among two providers could result in millions of messages per minute. Therefore it is crucial that fanout messages can be communicated and acknowledged in bulk.¶
At their discretion (according to their policies), providers might also choose to inform other providers when users are deleted. For example, two closely federated enterprise IM systems might do this for all user deletions where the deleted user is present on a room owned by the other provider. In another model, large consumer providers might inform each other when a user was deleted due to spam or abuse.¶
Regarding the ordering requirements of fanned-out messages:¶
Note: Clients might ask their own provider for MLS Commits, Proposals, Welcomes, and consent request/grant/reject information before other information, in order to display most recent messages without a long delay.¶
Delivering the most recent messages first seems desirable from a user interface perspective, however there are constraints; in order to decrypt messages, the entire sequence of Commits leading up to the current epoch must be processed in order. Clients typically only save the keying material for a small number of epochs (two to five). Keeping more epochs increases memory/storage consumption and reduces security, but allows clients to decrypt messages, while lots of joining and leaving is being processed.¶
Within each epoch, clients use a "generation" counter to calculate the key to decrypt a specific message within an epoch. Clients can run the generation counter forward and save keys for pending messages to decrypt a message whichs arrive ahead of turn, but clients can typically store from several hundred to a small number of thousands of these keys per group. Setting this to a very large number exposes clients to a very simple DoS attack where the client processes millions of forward ratchet operations to try to decrypt a malicious message.¶
Some primitives are requests that are neither sent to every member of a room, not do they necessarily result in a timely response. They are not a natural fit for HTTP REST calls for example.¶
For the consent primitive, the sender of a consent request should receive an acknowledgement that the request was received by the provider of the target user. For privacy reasons, the requestor should not know if the target user received or viewed the request. The original requestor will obviously find out about a consent accept, but a consent reject or block is typically not communicated to the rejected/blocked user (again for privacy reasons).¶
The consent primitive needs to include the following:¶
If the consent primitive does not specify a room, it implies consent for any room. This is a common model for systems that use connection requests. Once a user accepts a connection request, either party is consenting to add the other to any number of rooms. In other systems, consent for Alice to add Bob to a soccer fans room does not imply that Alice has permission to add Bob to a timeshare presentations room. Both models are common, so MIMI should be able to support both models.¶
Note that a user could reject consent for all rooms from a user even if there was a consent request for a specific room, or even no consent request.¶
A client sending a knock request expects to receive some indication that its knock was received. However the ultimate goal of the knock (to be added to a room) may take 2 seconds or 2 yearsm or may never result in a response.¶
Likewise, reporting spam or abuse needs to result in some acknowledgement of the report itself. However a delete or ban action for a spamming user may never happen, may happen immediately, or may happens after weeks or months.¶
For completeness, requests for permission to send messages (voice) and the corresponding grant voice and revoke voice primitives have a similar asynchronous form of operation. However, in a moderated room it is expected for each member to know if they have voice or not. Note that moderation is currently out-of-scope for MIMI.¶
This section assumes provider A is searching on provider B. It takes no position on how a user or providers figures out which provider or providers are queried.¶
Adding a user to a group, or obtaining consent to contact a user in MIMI requires discovery of the user ID of the target user. Whether a user can be discovered/ searched depends on the user's provider's policies and the user's configured preferences. Some users (for example a realtor or salesperson) may choose to be broadly searchable, while another user may allow only a search on a single specific field. The MIMI discovery protocol needs to provide a way to search for a user at a specific provider and should be able to indicate the specific field or fields that are being provided or searched:¶
In the case of an exact handle search it is likely that only a single user ID is returned (if at all). However when less specific information is requested, the search could yield multiple results, even a large number, which may need to be paginated and/or rate limited. The specific information provided in the response is also subject to the combination of user and provider policies.¶
Note that a provider could use a blanket consent rejection to prevent a user from being found via search.¶
Uploading a file to a room in a federated environment can use one of two models. Either each user uploads the file to their own provider, or every user uploads any files to the provider owning the room. Any member can download the files from the provider storing the file.¶
The MIMI message transport protocol could easily support both options.¶
Note that in many enterprise environments it may not be possible for clients to use a link directly to or from the provider storing the file. It may need to be proxied through the client's provider.¶
Many messaging systems have a way to generate a link (sometimes represented as a QR Code) that is used to identify a room, find a room, or authorize a user to join a room. There are many variations in the behavior of links when they are generated. For example, some links merely point to the target room but do not grant any additional authorization for a joiner. Typically they include both the address of the room and some authorization. Authorization could apply only to the first client to join using that code, or to any number of users. It could also be limited in time, or require an additional out-of-band password/passphrase or role-based authorization.¶
How a user generates or discovers such a link is out-of-scope of MIMI, however the way such a link is used to join a room across providers should be in scope, as it is a common mode of joining. To be useful in an interoperable way, a link needs to embed the room ID (probably as a URI) and a code. The MIMI message transfer protocol would then include the code in a request for GroupInfo for the room. Then the GroupInfo could be used in an external join.¶
A personal "introduction code" might also provide the user ID of a user, which could be used to request consent to communicate.¶
IM systems carry some types of information where only the most recent event may be needed. This could include (for example):¶
Note that presence is explicitly out-of-scope of MIMI. However the MIMI working group may discover that a message transfer primitive which only delivers the current status is useful and necessary.¶
Assumptions about authentication, privacy, and consent of individual users are discussed in the body of this document. The security considerations of MLS [I-D.ietf-mls-protocol] and the MLS group chat framework [I-D.mahy-mimi-group-chat] also apply.¶
TODO: Discussion of the end-to-middle problem.¶
This document has no IANA actions.¶