Internet-Draft | MIMI | July 2024 |
Kohbrok & Robert | Expires 4 January 2025 | [Page] |
This document describes MIMI Portability mechanisms.¶
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 4 January 2025.¶
Copyright (c) 2024 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.¶
draft-robert-mimi-delivery-service and others describe a transport and delivery mechanism for messages in a federated environment that relies on the concept of a fixed Delivery Service that is in charge of orchestrating the communication for a given MLS group. All clients of a given MLS group agree on what Delivery Service to use and rely on it to solve the problem of Commit message ordering.¶
While having a fixed Delivery Service solves a class of synchronization problems, it can sometimes be a limiting factor, especially because it introduces reliance on a specific operator. There are legitimate scenarios where the operator of a Delivery Service no longer wants to operate it, or where the users of a group want to switch to a different Delivery Service.¶
This document describes mechanisms that allow users to switch an MLS group to a different Delivery Service.¶
draft-01¶
Version bump to prevent expiration¶
We consider two distinct Delivery Services, the Source Delivery Service and the Target Delivery Service. The Source Delivery Service is where the MLS group currently resides, and the Target Delivery Service is where the MLS group should be moved to. The Source Delivery Service and the Target Delivery Service have distinct domain names.¶
The Source Delivery Service is responsible for exporting the MLS group state and sending it to the Target Delivery Service. The Target Delivery Service is responsible for importing the MLS group state and making it available to the members of the MLS group.¶
Once the MLS group state has been imported into the Target Delivery Service, the Source Delivery Service no longer has any responsibility for the MLS group. The Source Delivery Service can delete the MLS group state and all associated metadata.¶
TODO: The MLS group ID is fixed for the lifetime of a group and cannot be changed. This requires group IDs to be globally unique across all relevant Delivery Services. Even though this could be solved using a UUID, groups should also be tied to a specific owning delivery service.¶
TODO: Describe what keys are used for the signatures.¶
TODO: Describe that the crypto primitives should be aligned with the ciphersuite of the MLS group.¶
The migration process is initiated by a client of the MLS group. The client requests a MigrationResponse from the Target Delivery Service. The Target Delivery Service returns a MigrationResponse that can be used by the Source Delivery Service to transfer the MLS group state to the Target Delivery Service.¶
The client sends the following MigrationRequest message to the Target Delivery Service:¶
struct { opaque source_domain_name<V>; opaque target_domain_name<V>; opaque group_id<V>; uint64 epoch; } MigrationRequest;¶
The Target Delivery Service responds with a MigrationResponse message:¶
struct { MigrationRequest migration_request; uint8[32] nonce; opaque signature<V>; } MigrationResponse;¶
The client sends the following MigrationInit message to the Source Delivery Service:¶
struct { MigrationResponse migration_response; opaque signature<V>; } MigrationInit; struct { opaque target_ds_domain<V>; } MigrationCommitAAD¶
The client also sends a Commit message to the group, where the AAD consists of a serialized MigrationCommitAAD struct.¶
The Source Delivery Service sends a MigrationContent message to the Target Delivery Service:¶
struct { MigrationResponse migration_response; opaque group_state<V>; opaque signature<V>; } MigrationContent;¶
The Target Delivery Service responds with a TargetMigrationComplete message:¶
struct { opaque migration_content_hash<V>; opaque signature<V>; } TargetMigrationComplete;¶
The Source Delivery Service proceeds to fan out the client's Commit message that includes the MigrationCommmitAAD to the group.¶
Finally, the Source Delivery Service responds to the client with a MigrationConfirmation message:¶
struct { opaque domain_name<V>; uint8[32] nonce; opaque group_id<V>; opaque signature<V>; } MigrationConfirmation;¶
The Source Delivery Service can now delete the MLS group state and all associated metadata.¶
Clients can now send messages to the group using the Target Delivery Service.¶