MIMI Delivery Service

3.1. Client to server and server to server protocol

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 owning DS of one of their groups and a server-to-server protocol that allows an owning DS 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.¶

3.2. Transport for the MIMI DS protocol

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.¶

Both the client-to-server part, as well as the server-to-server part of the MIMI DS protocol provide sender authentication, leaving recipient authentication as provided, for example, by the HTTPS protocol to the transport layer.¶

TODO: If the transport layer provides mutual authentication, at least the server-to-server part of the MIMI DS protocol can be changed accordingly.¶

In the event that a guest DS proxies the client-server part of the MIMI DS protocol, the transport protocol can be used to facilitate additional functionality relevant to server-to-server communication, such as e.g. server-to-server authentication.¶

3.3. Flow

Figure 1 and Figure 2 show example protocol flows, where a client sends a request to the owning DS, followed by the owning DS fanning out a message to a guest DS. In Figure 2, the request sent by the client is proxied by the guest DS of that client.¶

For the remainder of this document, we assume that clients send requests directly to the owning DS. Proxying the requests over the client's own DS can always be done and does not change the functionality.¶

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.¶

3.4. Supported operations

The MIMI DS protocol allows guest clients to request a variety of operations for example to manage group membership, join groups, or send messages.¶

• Group creation/deletion¶
• Join a group from a Welcome message as a new member¶
• Join a group through an External Commit message as a new member or client of an existing member (e.g. Resync a client after state loss)¶
• Adding and removing users to/from a group¶
• Adding and removing clients to/from a member of the group¶
• Client updates (MLS leaf updates)¶
• Sending application messages¶
• Download of KeyPackages¶
• Enqueueing of a message fanned out from an owning DS¶
• Discovery of users and their clients¶
• Download of connection-specific KeyPackages¶

3.5. Client removals induced by the Delivery Service

Independent of client requests, the Delivery Service itself can remove clients from a group by issuing remove proposals in the following cases:¶

• A user has removed a client from its account¶
• A user has been deleted¶
• The client is removed from the group because it has been inactive for too long¶

3.6. Serialization format

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.¶

3.7. KeyPackages

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.¶

3.8. Clients and users

TODO: This section needs to be revisited once identifiers and client/user authentication in general have been decided on by the MIMI WG.¶

Secure messaging applications typically have a notion of users, where each user has one or more clients. As MLS does not have a native notion of users, it has to be provided by the MIMI DS protocol.¶

For the Full Metadata mode, the MIMI DS protocol only requires that the user identifier can be derived from the client identifier. Authentication of a client is then assumed to imply authentication of the user.¶

In the Reduced Metadata mode, the DS does not see real client or user identifiers, but instead has to work with pseudonyms. Here, the DS introduces its own notion of users. For more information see Section 11.¶

3.9. Version agility

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.¶

3.10. Group lifecycle

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.¶

3.11. Framing and processing overview

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;

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;

struct {
  DSProtocolVersion protocol_version;
  DSRequestBody request_body;
  u32 sender_index
} ClientSignatureTBS

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:
      AddPackage add_packages<V>;
    case ConnectionKeyPackages:
      AddPackage add_packages<V>;
  }
}

struct {
  TODO: Operation specific errors.
} DSError

enum {
  ClientIdentifier,
  ...
} DSFanoutRecipientType;

struct {
  DSRecipientType recipient_type;
  select (DSRecipient.recipient_type) {
    case ClientIdentifier:
      opaque client_id<0..255>;
    ...
  }
} DSFanoutRecipient;

struct {
  DSProtocolVersion protocol_version;
  FQDN sender;
  DSFanoutRecipient recipients<V>;
  MLSMessage mls_message;
  // Signature over the above fields
  opaque signature<0..255>;
} DSFanoutRequest

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

struct {
  KeyPackage key_package;
  optional<RMAddPackageData> rm_data;
} AddPackage

3.12. Connection establishment flow

A user can establish a connection to another user by creating a connection group, fetching connection AddPackage 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.¶

6.1. Request group id

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.¶

6.2. Create group

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;
  optional<RMCreateGroupData>
} 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:¶

• The group ID is not empty and is not already in use.¶
• The LeafNode is valid, according to [I-D.ietf-mls-protocol] 7.3. Leaf Node validation.¶
• The GroupInfo is valid, according to [I-D.ietf-mls-protocol] 12.4.3. Adding Members to the Group.¶

6.3. Delete group

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:¶

• The MLSGroupUpdate must contain a PublicMessage with a commit that contains remove proposals for every member of the group except the committer.¶

6.4. Add users to a group

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 AddPackages required to add the users' clients, the sender must first fetch the clients' AddPackages from their DS.¶

struct {
  MLSMessage welcome;
  optional<RMWelcomeData> rm_data;
} WelcomePackage

struct {
  MLSGroupUpdate group_update;
  WelcomePackage welcome_packages<V>;
  optional<RMAddClientsData> rm_data;
} AddUsersRequest;

Validation:¶

• The MLSGroupUpdate in the commit field must contain a PublicMessage with a commit that contains only Add proposals.¶
• The commit MUST NOT change the sender's client credential.¶
• Add proposals must not contain clients of existing group members.¶
• Add proposals must not contain connection AddPackages, except if the group is a connection group.¶
• If guest users are added as part of the request, there has to be a distinct Welcome message for each guest DS involved.¶

6.5. Remove users from a group

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:¶

• The MLSGroupUpdate must contain a PublicMessage with a commit that contains only remove proposals.¶
• The commit MUST NOT change the sender's client credential.¶
• The remove proposals in the commit MUST always remove all clients of one or more users.¶

6.6. Add clients to a group

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;
  WelcomePackage welcome_packages<V>;
  optional<RMAddClientsData> rm_data;
} AddClientsRequest;

Validation:¶

• The MLSGroupUpdate must contain a PublicMessage with a commit that contains only add proposals.¶
• The commit MUST NOT change the sender's client credential.¶
• All Add proposals must contain clients of the same user as an existing group member.¶

6.7. Remove clients from a group

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:¶

• The MLSGroupUpdate must contain a PublicMessage with a commit that contains only remove proposals.¶
• The commit MUST NOT change the sender's client credential.¶
• All remove proposals must target clients of the same user as the sending client.¶

6.8. Self remove a client from a group

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 5 for more details.¶

struct {
  MLSMessage proposal;
} SelfRemoveClientRequest;

Validation:¶

• The MLSMessage must contain a PublicMessage that contains a single remove proposal.¶
• The remove proposal must target the sending client.¶

6.9. Update a client in a group

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.¶

struct {
  MLSGroupUpdate group_update;
  optional<RMUpdateClientData> rm_data;
} UpdateClientRequest;

Validation:¶

• The MLSGroupUpdate must contain a PublicMessage that contains a commit with an UpdatePath, but without other proposals.¶
• If the leaf credential is changed by the update, the DS must validate the new credential.¶

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.¶

6.10. Join the group using an external commit

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;
  optional<RMExternalJoinData> rm_data;
} ExternalJoinRequest;

Validation:¶

• The MLSGroupUpdate must contain a PublicMessage that contains a commit with sender type NewMemberCommit.¶
• The sender of the ExternalJoinRequest must be a client that belongs to a user that is already in the group.¶

6.11. Send an application message to a group

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:¶

• The MLSMessage must contain a PrivateMessage with ContentType application.¶

6.12. Fetch the DS' signature public key

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 5), 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.¶

6.13. Fetch AddPackages of one or more clients

A request from a client to retrieve the AddPackage(s) of one or more clients of this DS. AddPackages are required to add other clients (and thus other users) to a group.¶

struct {
  ClientID client_identifiers<V>;
} AddPackagesRequest;

The DS responds with the AddPackages of all clients listed in the request.¶

Validation:¶

• All client identifiers must refer to clients native to this DS.¶
• The DS SHOULD verify that the sender of the request is authorized to retrieve the DSAddPackages of the clients in question. For example, it could check if the user of the sending client has a connection with the user of the target client(s).¶

6.14. Fetch connection AddPackages of one or more clients

A request from a client to retrieve the AddPackage(s) of all clients of a user of this DS. AddPackages obtained via this operation can only be used to add clients to a connection group.¶

Connection AddPackages are available separately from regular AddPackages, as they are meant to be accessed by clients of users with which the owning user has no connection.¶

struct {
  UserID user_identifier;
} ConnectionAddPackagesRequest;

The DS responds with connection AddPackages of all clients of the user corresponding to the identifier in the request.¶

Validation:¶

• All client identifiers must refer to clients native to this DS.¶
• All clients referred to by the identifiers must belong to the same user.¶

6.15. ReInitialize a group

A request from a client to re-initialize a group with different parameters as outlined in Section 3.10.¶

struct {
  MLSGroupUpdate commit;
} ReInitializeGroupRequest;

Validation:¶

• The MLSGroupUpdate must contain a PublicMessage that contains a commit with a re-init proposal.¶
• The GroupID in the re-init proposal must point to another group owned by the DS, which has a MIMI DS protocol version that is greater or equal than this group.¶

11.1. Connection key material

After the responder in a connection establishment process has joined the connection group created by the initiator, they MUST exchange their connection key material. This key material consists of keys that both users can use to hide metadata from the DS, or to authenticate themselves to the DS without revealing their identity when fetching KeyPackages for the other user.¶

struct {
  opaque connection_token<0..255>;
  opaque welcome_data_encryption_key<0..255>;
  opaque de_pseudonymization_key<0..255>;
} ConnectionKeyMaterial

The exact nature of the keys and what they are used for will become apparent in the following sections.¶

11.2. Group-level encryption keys

Some of the metadata in the context of a group has to be encrypted to prevent the DS from seeing it. Since the members of that group should still be able to process the data fully, the protocol needs key material that is known to group members, but not to the DS. In theory, such key material could be derived from the Exporter key of the MLS group. However, this key changes with each epoch, so all data encrypted in this way would have to be re-encrypted every epoch.¶

Instead, these group keys are randomly generated and distributed to new group members as part of the WelcomePackages. Instead of sending them in the clear, the sender of the Welcome encrypts them under the welcome data encryption key of each receiving user.¶

struct {
  opaque de_pseudonymization_key<0..255>;
  opaque credential_encryption_key<0..255>;
  opaque group_state_encryption_key<0..255>;
} GroupLevelKeys

struct {
  opaque encrypted_group_level_keys;
} RMWelcomeData

TODO: Lifecycle of these keys. Rotation of such key material is tricky, as any member who has not joined yet via a Welcome message, or who is going to try to join via external commit with the old key is going to fail. Then how to retrieve that key? Our preferred solution would be to introduce a maximum time that clients can be offline. Then it would be possible to have an overlapping rotation window that ensures that anyone that wants to join can join.¶

11.3. Pseudonymous client identifiers and authentication

As a general rule, clients MUST NOT use their real identifiers in credentials that they include in LeafNodes, be it in KeyPackages or as part of updates in their groups.¶

Instead, clients use per-group pseudonyms, where each pseudonym consists is a randomly generated UUID. Once a user is added to a group, the pseudonym remains the same throughout the lifetime of that group.¶

Despite this pseudonymization, clients must still be able to tie other group members to real client and user identities. To that end, clients sign their pseudonymized credentials with their client-level signature key material.¶

Since the signature would reveal which client has signed a pseudonymized credential, that signature MUST be encrypted symmetrically using a signature encryption key.¶

TODO: The authenticated encryption scheme used for the encryption should be determined by the MIMI DS protocol version.¶

Whenever the client uses a pseudonymized credential, it attaches the symmetric encryption key encrypted under another key that in turn known to everyone who is meant to be able to authenticate the client in that context.¶

There are two contexts in which a client needs to authenticate the credential of another client: In the context of a group and when a client fetches a KeyPackage from another client. (Note that there are no connection Key- or AddPackages in Reduced Metadata mode. See Section 11.9 for more details.)¶

struct {
  opaque encrypted_signature_encryption_key<0..255>;
} EncryptedSignatureEncryptionKey

struct {
  opaque encrypted_client_credential<0..255>;
} EncryptedClientCredential

struct {
  EncryptedSignatureEncryptionKey encrypted_signature_encryption_keys<V>;
  EncryptedClientCredential encrypted_client_credentials<V>;
} RMAddClientsData

11.4. Pseudonymous user identifiers and authentication

Pseudonymous per-group client identifiers mean that the DS can not determine which client belongs to which user. Instead, whenever a user is added, that user has to supply the DS with a public signature key called the user authentication key.¶

Since these user authentication keys are unique, per-group values, a user that was added to a group has to set them explicitly before it performs any other operation. User authentication keys are set using the regular update operation, which means that a newly added user MUST perform an update operation with one of its clients to set that key.¶

Client then use the user authentication key to authenticate operations that require user level authentication, specifically client addition and removal, as well as joining via external commit.¶

11.5. AddPackage retrieval

Since the DS can potentially observe which KeyPackage is added to which group, KeyPackages need to be published pseudonymously as well. This should be taken into account in the design of the DS' local client-to-server protocol.¶

Similarly, clients should be able to retrieve AddPackages of other users without revealing their identity. On the one hand, this means that they cannot authenticate using their client-level authentication key material. Instead, each user has a connection token that it distributes to all users that they have a connection with. They also upload it to the DS s.t. clients can show that they are authorized to fetch AddPackages by showing the connection token.¶

enum {
  Anonymous,
  ClientSignature,
  PseudonymousUserAuth,
  ConnectionToken,
} DSAuthType;

struct {
  DSAuthType auth_type;
  select (DSAuthData.auth_type) {
    case Anonymous:
      struct {};
    case ClientSignature:
      uint32 sender_index;
      opaque signature<0..255>;
    case PseudonymousUserAuth:
      opaque user_auth_hash<0..255>;
      opaque signature<0..255>;
    case ConnectionToken:
      opaque connection_token<0..255>
  }
} DSAuthData;

11.6. Pseudonymized fan-out

If DS cannot see the real identifiers of group members, it needs more information to determine where to fan messages out to. To this end, clients supply the DS with group-specific FanoutPseudonyms.¶

A FanoutPseudonym consists of the FQDN of the client's DS, as well as an octet string that allows the client's DS to further associate the message with the client. The local client-to-server protocol SHOULD ensure that that identifier is not tied to the client's real identifier.¶

struct {
  opaque ds_domain_name<0..255>;
  opaque destination_address<0..255>
} FanoutPseudonym

enum {
  ClientIdentifier,
  Pseudonym
} DSFanoutRecipientType;

struct {
  DSRecipientType recipient_type;
  select (DSRecipient.recipient_type) {
    case ClientIdentifier:
      opaque client_id<0..255>;
    case Pseudonym:
      FanoutPseudonym fanout_pseudonym
  }
} DSFanoutRecipient;

To allow for the delivery of messages immmediately after clients were added to a group, clients need to include a FanoutPseudonym extension in their KeyPackages.¶

Additionally, clients can update their FanoutPseudonym whenever they perform an update operation.¶

struct {
  optional<EncryptedSignatureEncryptionKey> encrypted_signature_encryption_key;
  optional<EncryptedClientCredential> encrypted_client_credential;
  optional<opaque> user_authentication_key;
  optional<FanoutPseudonym> fan_out_pseudonym
} RMUpdateClientData

TODO: This extension would have to be defined in the context of the MLS WG.¶

TODO: The intended way to use the destination address is for the client to have a queue pseudonymously registered to it on its own DS. The destination_address is then the identifier of the queue HPKE-encrypted to the client's DS, where for each group/KeyPackage, the client freshly encrypts the identifier to create unique ciphertexts.¶

11.7. Group state encryption at rest

To additionally protect persisted metadata on the DS, the DS MUST encrypt the group state before it stores it in persistent state. The key used for encryption and decryption is another group-level key that clients send to the DS with DSRequest.¶

struct {
  opaque group_state_ear_key<0..255>;
} RMGroupStateEARKey

Whenever a client sends a DSRequest that is concerned with a specific group, it includes the group state encryption key in the DSRequestBody. The DS then decrypts the group state, performs the operation and re-encrypts it.¶

11.8. External joins

For a client to perform an external join successfully, it needs all group-level keys. Since external join operations are only allowed for clients that belong to a user that is already in the group, those clients need to obtain the relevant key material from other clients of that user first.¶

11.9. Reduced metadata connection establishment

The only major change to the protocol that is required in the Metadata Reduced mode of operation is moving the connection establishment flow from a Welcome based one to one based on external commits. While this change prevents the initiator from immediately sending messages after creating the connection group, it is necessary, because the use of KeyPackages allows the DS to track which group is used as the connection group.¶

In this changed flow, the initiating client fetches a connection AddPackage, but instead of using it to add the clients of the responding user to the group, it encrypts a ConnectionEstablishmentInfo to the hpke_init_key in that KeyPackage.¶

struct {
  opaque initiator_client_credential<0..255>;
  opaque connection_group_id<0..255>;
  GroupLevelKeys group_level_keys;
  // Signature over the above fields using the signature key in the client
  // credential
  opaque signature<0..255>
} ConnectionEstablishmentInfo

struct {
  opaque recipient_identifier<0..255>;
  KeyPackageRef key_package_reference;
  opaque encrypted_connection_establishment_info<0..255>;
} ConnectionEstablishmentPackage

The recipient_identifier represents the real client identifier of the responding client.¶

TODO: "client_credential" is a place holder for whatever the key material would look like that binds an authentication key to the sender's identity.¶

The delivery of ConnectionEstablishmentPackages necessitates a new DS request type ds_fanout_cep, where the DSRequestBody contains a ConnectionEstablishmentPackage. The DS then stores and forwards the key_package_ref and the encrypted_connection_establishment_info to the client identified by the recipient_identifier.¶

The recipient can then determine the hpke_init_key of which KeyPackage to use and decrypt the ConnectionEstablishmentInfo. It can then perform an external join operation on the group indicated by the connection_group_id using the group_level_keys.¶

The users can then exchange information like the connection token via the connection group.¶

12.1. Transport Security

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.¶