| Internet-Draft | MIMI | September 2023 |
| Robert & Kohbrok | Expires 24 March 2024 | [Page] |
This document describes the MIMI Delivery Service.¶
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 (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.¶
The MLS protocol document specifies a protocol between two or more clients. The MLS architecture document introduces an abstract concept of a "Delivery Service" (DS) 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 and uses MLS to implement a variety of other features:¶
TODO: Make use of MUST/SHOULD, etc. throughout.¶
This document uses the terminology defined in [I-D.ietf-mls-protocol] with the following additions:¶
The MIMI DS protocol allows interoperability between a hub which hosts a group conversation and one or more guest DSs which are home to one or more of the conversation's group members. Underlying each group conversation is an MLS group that facilitates end-to-end encryption and authentication between group members.¶
The main purpose of the MIMI DS protocol thus is to ensure that guest clients can participate in the group. With MLS as the underlying protocol, this means that the MIMI DS protocol is primarily concerned with the fan-out of MLS messages (both from and to guest clients), as well the assistance of guest clients in joining MLS groups.¶
The MIMI DS protocol requires clients to send MLS messages as PublicMessages
(with the exception of messages with content type application). This allows
the hub to track the MLS group state in the same way as a client would,
enabling it to keep an up-to-date and fully authenticated list of members, as
well as provide the full MLS group state to joining group members, even for
those joining via external commit. In addition, the DS can verify messages and
enforce access control policies on group operations.¶
MLS being a protocol for end-to-end encryption, a subset of MIMI DS protocol messages have to originate from the clients rather than the interoperating delivery services.¶
The MIMI DS protocol consists of two parts: A client-to-server part that allows guest clients to interact with the hub of one of their groups and a server-to-server protocol that allows a hub to fan out messages to guest DSs, which can subsequently store and forward messages to their respective clients.¶
Note that the client-to-server part of the protocol can optionally be proxied via the guest DS of the sending client.¶
The MIMI DS protocol requires a transport protocol that provides confidentiality of messages and that allows the discovery of a DS based on the DS domain in a user identifier.¶
The client-to-server part of the MIMI DS protocol provide sender authentication. Recipient authentication, as well as mutual server-to-server authentication is left to the MIMI transport protocol.¶
Figure 1 shows an example protocol flow, where a client sends a request to its own guest DS, which in turn makes a request to the hub. The hub then fans out a message to another guest DS.¶
Both the message sending and the fanout parts of the protocol are designed in a request/response pattern. In the first protocol part, the client sends a DSRequest message to the Delivery Service and the Delivery Service responds with a DSResponse message. This pattern can easily be used over e.g. RESTful APIs.¶
For the second part of the protocol the Delivery Service sends a DSFanoutRequest to each guest DS. This happens whenever a message needs to be fanned out to all other members of a group as a result of an incoming DSRequest. The guest DS in turn responds with a DSFanoutResponse.¶
The MIMI DS protocol allows guest clients to request a variety of operations for example to manage group membership, join groups, or send messages.¶
Independent of client requests, the Delivery Service itself can remove clients from a group by issuing remove proposals in the following cases:¶
MLS messages use the presentation language and encoding format defined in [RFC8446] with the extensions defined in the MLS protocol specification. The MIMI DS protocol uses the same serialization format, as both clients and DS already have to support it to process MLS messages.¶
Octet strings resulting from serialization in this format are unambiguous and require no further canonicalization.¶
Clients have to upload KeyPackages such that others can add them to groups. In the context of interoperability, this means that clients have to be able to download KeyPackages of clients belonging to other DSs.¶
The MIMI DS protocol allows clients to download the KeyPackages of other clients. Uploading KeyPackages is outside of the scope of this protocol, as it is not relevant for interoperability.¶
TODO: KeyPackages of last resort should be marked. Ideally by using a KeyPackage extension.¶
In addition to regular KeyPackages, the MIMI DS protocol requires clients to provide connection KeyPackages for other clients to download. Connection KeyPackages are meant for use in the connection establishment process (explained in more detail in Section 6) and differ from regular KeyPackages only in that they include a LeafNode extension marking them as such.¶
TODO: Such an extension would have to be specified in the context of the MLS WG.¶
TODO: This section needs to be revisited once identifiers and client/user authentication in general have been decided on by the MIMI WG.¶
TODO: This topic is still under discussion, so this section only represents a suggestion for an MLS-based flow. Once we have more clarity on what participant data management looks like, we will update all other relevant sections of this document.¶
Each MIMI-DS managed group contains a MIMIParticipantExtension as part of its GroupContext. The MIMIParticipantExtension contains a participant list, i.e. all users that are associated with the group. Note that this includes inactive participants.¶
TODO: This extension can later be extended by also containing the roles of the participants to facilitate RBAC.¶
The participant list is changed via MIMIParticipant proposals, which can be issued by clients or servers and that can be the committed by clients as part of client-initiated operations as specified in Section 10. Each MIMIParticpipant proposal can add, remove or update a user's record in the MIMIParticipantExtension. The data in the extension MUST be consistent with the membership data of the MLS group.¶
MLS provides version, ciphersuite and extension agility. The versions, ciphersuites and extensions a client supports are advertised in its LeafNodes, both in all of the client's groups, as well as in its KeyPackages through the Capabilities field (Section 7.2 of [I-D.ietf-mls-protocol]).¶
MLS DS protocol clients MUST make use of a LeafNode extension to advertise the MIMI DS protocol versions they support.¶
TODO: Such an extension would have to be specified in the context of the MLS WG.¶
Upon creation MLS groups are parameterized by a GroupID, an MLS version number, as well as a ciphersuite. All three parameters are fixed and cannot be changed throughout the lifetime of a group.¶
Groups capable of interoperability with the MIMI DS protocol MUST use a GroupContext extension that indicates the MIMI DS protocol version with which it was created. This extension MUST NOT be changed throughout the lifetime of the group.¶
While all these parameters cannot be changed throughout a group's lifetime, the group can be re-initialized as described in Section 11.2. of [I-D.ietf-mls-protocol] to create a new group with a new set of parameters.¶
The MIMI DS protocol supports re-initializations of groups using the corresponding ReInitialization operation under the condition that all MLS parameters are compatible with the MIMI DS protocol version.¶
If a group is no longer used, it can be deleted either by a client or the DS itself.¶
TODO: Each MIMI DS protocol version should probably fix a set of ciphersuites, MLS protocol versions and maybe even extensions it supports. New ones can be added with protocol version upgrades.¶
The MIMI DS protocol provides a number of security guarantees.¶
The MLS protocol underlying the MIMI DS protocol provides a number of security guarantees that primarily affect end-to-end communication between clients such as authentication and confidentiality with forward- as well as post-compromise security (although the latter only holds for application messages). While the MIMI DS protocol acts as a layer around the MLS protocol it inherits some of MLSs security guarantees.¶
More concretely, the DS can verify client signatures on MLS messages and thus ensure that end-to-end authentication holds. Since the DS uses MLS messages to track the group state (including group membership), it is guaranteed to have the same view of that state as the group members.¶
Finally, the MIMI DS protocol also makes use of the authenticated channel provided by MLS to verify the authenticity of relevant extension data such as the FanoutAuth tokens used for queue authorization.¶
All client to server requests consist of a MIMI DS specific protocol wrapper called DSRequst. DSRequest contains the MIMI DS protocol version, a body with operation-specific data, as well as authentication information.¶
enum {
ds_request_group_id(0),
ds_create_group(1),
ds_delete_group(2),
...
} DSRequestType;
struct {
DSRequestType request_type;
select (DSRequestBody.request_type) {
case ds_delete_group:
DeleteGroupRequest delete_group_request;
...
}
} DSRequestBody;
struct {
DSProtocolVersion version;
DSRequestBody request_body;
DSAuthData authentication_data;
} DSRequest;
¶
A DS supports a variety of operations. For presentational reasons, we only
define DSRequestType and the corresponding case statement in DSRequestBody
partially here. The full definition with all operations relevant for the
normal DS operating mode can be found in Section 10.¶
The authentication_data field of a DSRequest depends on the request type and
contains the data necessary for the DS to authenticate the request.¶
enum {
Anonymous,
ClientSignature,
} DSAuthType;
struct {
DSAuthType auth_type;
select (DSAuthData.auth_type) {
case Anonymous:
struct {};
case ClientSignature:
uint32 sender_index;
opaque signature<0..255>;
}
} DSAuthData;
¶
Before the DS performs the requested operation, it performs an authentication operation depending on the DSAuthType.¶
sender_index to verify the signature over the
following struct:¶
struct {
DSProtocolVersion protocol_version;
DSRequestBody request_body;
u32 sender_index
} ClientSignatureTBS
¶
Note that all group operations additionally contain an MLSMessage the content of which mirrors the request type, e.g., an AddUsers request wraps an MLS commit that in turn contains the Add proposals for the users' clients. In that case, the DS uses the GroupID inside the MLSMessage to determine which group the request refers to and verifies the MLSMessage in the same way an MLS client would (including the signature).¶
Depending on the nature of the request, clients can also include data in the AAD field of the MLSMessage, where it can be read and authenticated by both DS and all other group members.¶
After performing the desired operation using the data in DSRequestBody the DS responds to the client (or the proxying guest DS) with a DSResponse.¶
struct {
DSProtocolVersion protocol_version;
DSResponseBody response_body;
} DSResponse
enum DSResponseType {
Ok,
Error,
GroupID,
WelcomeInfo,
ExternalCommitInfo
SignaturePublicKey,
KeyPackages,
ConnectionKeyPackages,
}
struct DSResponseBody {
DSResponseType response_type;
select (DSResponseBody.response_type) {
case Ok:
struct {};
case Error:
DSError error;
case GroupID:
opaque group_id<V>;
case WelcomeInfo:
optional<Node> ratchet_tree<V>;
case ExternalCommit:
MLSMessage: group_info;
optional<Node> ratchet_tree<V>;
case SignaturePublicKey:
SignaturePublicKey signature_public_key;
case KeyPackages:
KeyPackage key_packages<V>;
case ConnectionKeyPackages:
KeyPackage key_packages<V>;
}
}
struct {
TODO: Operation specific errors.
} DSError
¶
After sending the response, and depending on the operation the DS might fan out messages to one or more guest DSs.¶
To that end, it wraps the MLSMessage to be fanned out into a DSFanoutRequest. In addition to the MLSMessage, the DSFanoutRequest contains the protocol version, a list of client ids representing the clients for which the payload is meant, a FanoutAuthToken (see Section 3.8) for each of the clients, as well as the payload to be fanned out.¶
struct {
DSProtocolVersion protocol_version;
opaque recipient_ids<V>;
FanoutAuthToken fanout_auth_tokens<V>;
MLSMessage mls_message;
} DSFanoutRequest
¶
The receiving DS first verifies the signature using the sending DS' public signature key and then further validates the message by performing the following checks:¶
recipient_ids are all clients of this DS¶
fanout_auth_tokens are all valid tokens for the individual
recipients¶
The recieving DS can then store and forward the contained MLS message to the
clients indicated in the recipient_ids field and send a DSFanoutResponse.¶
enum {
Ok,
Error,
} DSFanoutResponseType
struct {
TODO: Fanout error types
} DSFanoutError
struct DSFanoutResponseBody {
DSFanoutResponseType response_type;
select (DSFanoutResponseBody.response_type) {
case Ok:
struct {};
case Error:
DSFanoutError error;
}
}
struct {
DSProtocolVersion protocol_version;
DSResponseBody response_body;
} DSFanoutResponse
¶
As noted in Section 3.7, clients must upload KeyPackages such that other clients can add them to groups.¶
A user can establish a connection to another user by creating a connection group, fetching a connection KeyPackage of the target user's clients from its DS and inviting that user to the connection group. The receiving user can process the Welcome and figure out from the group state who the sender is. Additional information can either be attached to the group via an extension, or via MLS application messages within that group.¶
TODO: This is a sketch for a simple connection establishment flow that allows the recipient to identify and authenticate the sender and that establishes an initial communication channel between the two users. More functionality can be added via additional messages or MLS extensions.¶
To verify and deliver messages, authenticate clients as members of a group and to assist clients that want to join a group, the DS keeps track of the state of each group for which it is the hub. More specifically, it keeps track of the group's ratchet tree, the group's GroupContext and other information required to produce a valid GroupInfo for the current group epoch. It does this by processing incoming MLS messages in the same way a member of that group would, except of course that the DS doesn't hold any private key material.¶
While MLS messages are sufficient to keep track of most of the group information, it is not quite enough to create a GroupInfo. To allow the DS to provide a valid GroupInfo to externally joining clients, it additionally requires clients to provide the remaining required information. Concretely, it requires clients to upload the Signature and the GroupInfo extensions. Clients need to send this information whenever they send an MLS message (i.e. an MLSMessage struct) that contains a commit.¶
struct {
Extension group_info_extensions<V>;
opaque Signature<V>;
} PartialGroupInfo
¶
The combination of a commit and a partial group info is called an MLSGroupUpdate.¶
struct {
MLSMessage commit;
PartialGroupInfo partial_group_info;
} MLSGroupUpdate
¶
Whenever the DS receives an MLSGroupUpdate, it must verify that the MLSMessage contains a PublicMessage with a commit and that commit and partial group info are valid relative to the existing group state according to the MLS specification.¶
TODO: For now there is no distinct endpoint to obtain authentication material that allows the DS to authenticate clients. This would be part of the AS design.¶
By tracking the group information in this way, the DS can help clients that join via external commit by providing them with a ratchet tree and a group into.¶
Similary, clients that wish to join a group via a regular invite (i.e. a Welcome message) have already received a GroupInfo and can obtain a ratchet tree from the DS.¶
In the time between a client being added to a group by a commit and the client wanting to join the group, the group state can have progressed by one or more epochs. As a consequence, the DS MUST keep track of epochs in which clients are added and store the corresponding group states until each client has successfully joined.¶
MLS relies on a proposal-commit logic, where the proposals encode the specific action the sending client intends to take and the commit then performs the actions of a set of commits.¶
The advantage of this approach is that the sender of the proposal does not have to be the committer, which allows, for example, the DS to propose the removal of a client, or a client to propose that it be removed from the group. Note that the latter example is the only way that a client can remove itself (i.e. leave) from a group.¶
Such proposals, where the original sender differs from the sender of the commit are called "proposal by reference", or "proposal by value" if the proposal is sent by the committer as part of the commit itself.¶
The following sections detail operations that can be performed by clients, so each operation that entails a change to the group state (with the exception of the self remove operation) require the sender to perform a commit, where the semantics of the operation are reflected as proposals by value. For example, the commit in the AddUsersRequest must only contain Add proposals.¶
If a client receives a valid standalone proposal, it MUST store it and verify that the next commit includes said proposal.¶
TODO: Be more specific about proposal validation. Also, we might want to allow the server to rescind a proposal.¶
Whenever a client sends a commit as part of an operation, it MUST include all stored proposals by reference, such as server-initiated Remove proposals, or proposals sent as part of a self-remove operation.¶
TODO: Proposals by reference pose a problem in the context of external commits, as, even if the external committer had access to all proposals in an epoch, it wouldn't be able to verify them, thus potentially leading to an invalid external commit. A solution could be introduced either as part of the MIMI DS protocol, or as an MLS extension. The latter would be preferable, as other users of MLS are likely going to encounter the same problem.¶
While the nature of MLS prevents the DS from performing changes to the group state itself, it can propose that clients perform certain actions and enforce the enactment of such proposals.¶
To allow the DS to send proposals, all groups MUST contain an external_senders
extension as defined in Section 12.1.8.1. of [I-D.ietf-mls-protocol] that
includes the DS' credential and its signature public key.¶
TODO: We might also want to mandate that the group includes credentials of guest DSs involved in the group. However, for them to be able to send proposals, we'd need an additional operation/endpoint that the DS exposes.¶
TODO: Details of the DS credential. A BasicCredential with the FQDN of the DS would probably be sufficient.¶
The DS can simply create such proposals itself based on the group information and distribute it to all group members via regular DSFanoutRequests.¶
The DS can propose that one or more clients be removed from a given group. To that end, it issues a remove proposal for each client it wants removed, where each remove proposal targets the leaf of one of the clients in question.¶
The DS can propose that one or more clients be added to the group. It does so by issueing an add proposal for each client, where each add proposal contains a KeyPackage of the respective client.¶
TODO: If the DS should be allowed to add clients that belong to another DS, we need an endpoint that allows DSs to fetch KeyPackages from one-another.¶
The DS supports a number of operations, each of which is represented by a variant of the DSRequestType enum and has its own request body.¶
enum {
ds_request_group_id(0),
ds_create_group(1),
ds_delete_group(2),
ds_add_users(3),
ds_remove_users(4),
ds_add_clients(5),
ds_remove_clients(6),
ds_self_remove_client(7),
ds_update_client(8),
ds_external_join(9),
ds_send_message(10),
ds_signature_public_key(11),
ds_key_packages(12),
ds_connection_key_packages(13),
ds_re_initialize_group(14),
} DSRequestType;
struct {
DSRequestType request_type;
select (DSRequestBody.request_type) {
case ds_request_group_id:
struct {};
case ds_create_group:
CreateGroupRequest create_group_request;
case ds_delete_group:
DeleteGroupRequest delete_group_request;
case ds_add_users:
AddUsersRequest add_users_request;
case ds_remove_users:
RemoveUsersRequest remove_users_request;
case ds_add_clients:
AddClientsRequest add_clients_request;
case ds_remove_clients:
RemoveClientsRequest remove_clients_request;
case ds_self_remove_clients:
SelfRemoveClientsRequest self_remove_clients_request;
case ds_update_client:
UpdateClientRequest update_client_request;
case ds_external_join:
ExternalJoinRequest external_join_request;
case ds_send_message:
SendMessageRequest send_message_request;
case ds_signature_public_key:
struct {};
case ds_key_packages:
KeyPackagesRequest key_packages_request;
case ds_connection_key_packages:
ConnectionKeyPackagesRequest connection_key_packages_request;
case ds_re_initialize_group:
ReInitializeGroupRequest re_initialize_group_request;
}
} DSRequestBody;
¶
Clients can use this operation to request a group id. This group ID can subsequently used to create a group on this DS.¶
After receiving this request, the DS generates a unique group id and responds with a DSResponse struct of type GroupID.¶
A request from the client to create a new group on the Delivery Service. This operation can be used both for the creation of regular groups and for the creation of connection groups.¶
The client sends the following CreateGroupRequest to the Delivery Service:¶
struct {
opaque group_id<V>;
LeafNode LeafNode;
MLSMessage group_info;
} CreateGroupRequest;
¶
The Delivery Service internally creates and stores the group based on the information in the request and responds with a CreateGroupResponse:¶
enum {
invalid_group_id(0),
invalid_leaf_node(1),
invalid_group_info(2),
} CreateGroupResponse;
¶
TODO: How to mark connection groups? Have the creator include a connection extension in the LeafNode?¶
Validation:¶
The Delivery Service validates the request as follows:¶
A request from the client to delete a group from the Delivery Service. This operation allows clients to delete a group from the DS. Clients can of course keep a copy of the group state locally for archival purposes.¶
struct {
MLSGroupUpdate group_update;
} DeleteGroupRequest;
¶
Validation:¶
The Delivery Service validates the request as follows:¶
A request from a client to add one or more users to a group. For each user, one or more of the user's clients are added to the group. The Welcome messages in the request are then fanned out to the user's DSs.¶
To obtain the KeyPackages required to add the users' clients, the sender must first fetch the clients' KeyPackages from their DS.¶
struct {
MLSGroupUpdate group_update;
MLSMessage welcome_messages<V>;
} AddUsersRequest;
¶
Validation:¶
commit field MUST contain a PublicMessage with a
commit that contains only Add proposals with the possible exception of Remove
proposals as detailed in Section 8.¶
A request from a client to remove one or more users from a group. The DS will still fan out the request to the users. The commit contained in the message will allow the users to recognize that they were removed.¶
struct {
MLSGroupUpdate group_update;
} RemoveUsersRequest;
¶
Validation:¶
A request from a client to add one or more clients of the same user. This operation allows users to add new clients to an existing group. Alternatively, new clients can add themselves by joining via external commit.¶
struct {
MLSGroupUpdate group_update;
MLSMessage welcome_messages<V>;
} AddClientsRequest;
¶
Validation:¶
A request from a client to remove one or more other clients of the same user from a group. This operation allows users to remove their own clients from a group. Note that this operation cannot be used by a client to remove itself from the group. For that purpose, the SelfRemoveClientRequest should be used instead.¶
struct {
MLSGroupUpdate group_update;
} RemoveClientsRequest;
¶
Validation:¶
A request from a client to remove itself from the group. If it's the last client of a user, this effectively removes the user from the group. Note that this request only contains a proposal, so the client is not effectively removed from the group until another group member commits that proposal. See Section 8 for more details.¶
struct {
MLSMessage proposal;
} SelfRemoveClientRequest;
¶
Validation:¶
A request from a client to update its own leaf in an MLS group. This operation can be used to update any information in the sender's leaf node. For example, the sender could use this operation to update its key material to achieve post-compromise security, update its Capabilities extension, or its leaf credential.¶
The sending client can also choose to send a FanoutAuthToken, which the DS uses to replace the client's existing token.¶
struct {
MLSGroupUpdate group_update;
optional<FanoutAuthToken> token;
} UpdateClientRequest;
¶
Validation:¶
TODO: The discussion around identity and credentials should yield a method to judge if a new credential is a valid update to an existing one.¶
A request from a client to join a group using an external commit, i.e. without the help of an existing group member. This operation can be used, for example, by new clients of a user that already has clients in the group, or by existing group members that have to recover from state loss.¶
To retrieve the information necessary to create the external commit, the joiner has to fetch the external commit information from the DS.¶
struct {
MLSGroupUpdate group_update;
} ExternalJoinRequest;
¶
Validation:¶
A request from a client to fan out an application message to a group. This operation is meant to send arbitrary data to the rest of the group. Since the application message is a PrivateMessage, the DS can not verify its content or authenticate its sender (even though it does authenticate the sender of the surrounding DSRequest).¶
struct {
MLSMessage application_message;
} SendMessageRequest;
¶
Validation:¶
A request from a remote DS to retrieve the signature public key of this DS. The
signature public key can be used by other DSs to verify DSFanoutRequests sent by
the DS. While the DS also uses its signature private key to sign proposals (see
Section 8), clients should use the signature key included in
the group's external_senders extension to validate those.¶
The DS responds with a DSResponse of type SignaturePublicKey that contains the signature public key of this DS.¶
A request from a client to retrieve the KeyPackage(s) of one or more clients of this DS. KeyPackages are required to add other clients (and thus other users) to a group.¶
struct {
ClientID client_identifiers<V>;
} KeyPackagesRequest;
¶
The DS responds with the KeyPackages of all clients listed in the request.¶
Validation:¶
A request from a client to retrieve the KeyPackage(s) of all clients of a user of this DS. KeyPackages obtained via this operation can only be used to add clients to a connection group.¶
Connection KeyPackages are available separately from regular KeyPackages, as they are meant to be accessed by clients of users with which the owning user has no connection.¶
struct {
UserID user_identifier;
} ConnectionKeyPackagesRequest;
¶
The DS responds with connection KeyPackages of all clients of the user corresponding to the identifier in the request.¶
Validation:¶
A request from a client to re-initialize a group with different parameters as outlined in Section 3.11.¶
struct {
MLSGroupUpdate commit;
} ReInitializeGroupRequest;
¶
Validation:¶
After the DS has processed an incoming MLSMessage, it prepares a DSFanoutRequest as described in Section 5.¶
To authenticate these messages, an additional layer of DS-to-DS authentication is required. As defined in Section 5, DSFanoutRequests are signed using signing key of the sending DS. The receiving DS can obtain the corresponding signature public key by sending a DSRequest to the sender indicated in the DSFanoutRequest.¶
The request for the signature public key MUST be sent via an HTTPS secured channel, or otherwise authenticated using a root of trust present on the DS.¶
TODO: If the transport provides server-to-server authentication this section and the signature on the DSFanoutRequest can be removed. TODO: Details on key management, caching etc. We can probably get away with using very small lifetimes for these keys, as they can be re-fetched cheaply and essentially at any time.¶
TODO: Access control is beyond the charter. However, to show how easily implementable it is with MLS, this is section sketches a possible MLS extension to handle access control in groups that is enforcible and verifiable by both clients and DS. It is just an example and details can be changed later.¶
As group operations are handled by MLS PublicMessages, the DS can enforce access control policies on groups. The privileges of clients in a group are determined by the group's RBAC GroupContext Extension.¶
struct {
uint32 admins<V>;
} RBACExtension
¶
The RBACExtension supports two roles: Members and Admins. Since all group members are Members by default, the extension only lists admins.¶
Any client the leaf node index of which is listed in the admins field of the
RBACExtension in a given group is considered as an Admin role and allowed to
perform the following operations in the context of this group.¶
The SetRole operation is an additional operation available to groups that have an RBACExtension.¶
struct {
MLSGroupUpdate group_update;
} SetRoleRequest
¶
The group_update needs to contain a commit which commits to a single
RBACProposal.¶
struct {
uint32 promoted_members;
uint32 demoted_members;
} SetRole
¶
The DS (and all clients) process this proposal by changing the role of the group
members with the leaf indices listed in the promoted_members and
demoted_members fields and change the admins field of the group's
RBACExtension accordingly. For example, if the leaf index admin is listed in the
changed_members field of the proposal, it is demoted to Member and removed
from the admins field. Similarly, if a Member is listed, it is promoted to
Admin and added to the admins field.¶
All requests (with the exception of the VerificationKeyRequest) can be explicitly authenticated by the recipient through the verification of a signature. This means that recipients can follow a rate-limiting strategy of their choice based on the sender's identity.¶
For DSRequests, the DS can rate-limit on a per group-level, per-DS level (reducing the messages from all clients or users belonging to a single DS), or even based on individual clients or users.¶
For DSFanoutRequests, rate-limiting or blocking can happen based on the identity of the sending DS, or it can happen on a per-group basis, where the recipient only blocks messages from a particular group.¶
Such rate-limiting can happen by decision of the DS itself, or on the request of its local users. For example, a user might wish to block connection requests from one specific other user without blocking connection requests from all other users of that DS.¶
As all application messages are encrypted, the DS has no way of analyzing their content for illegal or abusive content. It may make use of a message franking scheme to allow its users to report such content, although this is beyond the scope of this document.¶
Additionally, in the same way as a DS might allow its users to block certain messages from specific users in the context of spam prevention, it may do the same based on abusive or illegal content.¶
TODO: There is currently no consensus in the MIMI w.r.t. the security goals we want to reach.¶
The underlying MLS protocol provides end-to-end encryption and authentication for all MLSMessages, as well as group state agreement.¶
Transport of DSFanoutRequests, as well as their responses MUST use a recipient authenticated transport. This is to ensure that these messages are mutually authenticated.¶
To protect the metadata in all request-response flows, requests and responses SHOULD be secured using an encrypted transport channel.¶