MLS Virtual Clients

3.1. Virtual clients for performance

If a group of emulator clients emulate a virtual client in more than one group, the overhead caused by the emulation process can be outweighed by two performance benefits.¶

On the one hand, the use of virtual clients makes the higher-level groups (in which the virtual client is a member) smaller. Instead of one leaf for each emulator client, it only has a single leaf for the virtual client. As the complexity of most MLS operations depends on the number of group members, this increases performance for all members of that group.¶

At the same time, the virtual client emulation process (see Section 5) allows emulator clients to carry the benefit of a single operation in the emulation group to all virtual clients emulated in that group.¶

3.2. Metadata hiding

Virtual clients can be used to hide the emulator clients from other members of higher-level groups. For example, removing group members of the emulator group will only be visible in the higher-level group as a regular group update. Similarly, when an emulator client wants to send a message in a higher-level group, recipients will see the virtual client as the sender and won't be able to discern which emulator client sent the message, or indeed the fact that the sender is a virtual client at all.¶

Hiding emulator clients behind their virtual client(s) can, for example, hide the number of devices a human user has, or which device the user is sending messages from.¶

As hiding of emulator clients by design obfuscates the membership in higher-level groups, it also means that other higher-level group members can't identify the actual senders and recipients of messages. From the point of view of other group members, the "end" of the end-to-end encryption and authentication provided by MLS ends with the virtual client. The relevance of this fact largely depends on the security goals of the application and the design of the authentication service.¶

If the virtual client is used to hide the emulator clients, the delivery service and other higher-level group members also lose the ability to enforce policies to evict stale clients. For example, an emulator client could become stale (i.e. inactive), while another keeps sending updates. From the point of view of the higher-level group, the virtual client would remain active.¶

4.1. External remove proposals

In some cases, it is desirable for an external sender (e.g. the messaging provider of a user) to be able to propose the removal of an individual (non-virtual) client from a group without requiring another client of the same user to be online. Doing so would allow another client to commit to said remove proposal and thus remove the client in question from the group.¶

This is not possible when using virtual clients. Here, the non-virtual client would be the emulator client of a virtual client in a higher-level group. While the server could propose the removal of the client from the emulation group, this would not effectively remove the client's access to the higher-level groups through the virtual client.¶

For such a removal to take place, another emulator client would have to be online to update the key material of the virtual client (in addition to the removal in the emulation group).¶

Another possibility would be for emulator clients to provision KeyPackages for which only a subset of emulator clients have access to. The external sender could then propose the removal of the virtual client, coupled with the immediate addition of a new one using one of the KeyPackages.¶

4.2. External joins

In a simple multi-client scenario, new (emulator) clients are able to join via external commit without influencing the operation of any other emulator client and without requiring another emulator client to be online.¶

When using virtual clients and a client wishes to externally join the emulator group, it will not have immediate access to the secrets of the virtual clients associated with that group.¶

This can be remedied via one of the following options:¶

• Another emulator client could provide it with the necessary secrets¶

• The new emulator client could have the virtual client rejoin all higher-level groups¶

While the first option has the benefit of not requiring an external commit in any higher-level groups (thus reducing overhead), it either requires another emulator client to be online to share the necessary secrets directly, or a way for the new emulator client to retrieve the necessary without the help of another client. The latter can be achieved, for example, by encrypting the relevant secrets such that the new client can retrieve and decrypt them.¶

The second option on the other hand additionally requires the new emulator client to re-upload all KeyPackages of the virtual client, thus further increasing the difficulty of coordinating actions between emulation group and higher-level groups.¶

5.1. Delivery Service

Client emulation requires that any message sent by an emulator client on behalf of a virtual client be delivered not just to the rest of the supergroup to which the the message is sent, but also to all other clients in the emulator group.¶

5.2. Generating Virtual Client Secrets

Generally, secrets for virtual client operations are derived from the emulation group. To that end, emulator clients derive an epoch_base_secret with every new epoch of that group.¶

emulator_epoch_secret = SafeExportSecret(XXX)

TODO: Replace XXX with the component ID.¶

The emulator_epoch_secret is in turn used to derive two further secrets, after which it is deleted.¶

epoch_id =
  DeriveSecret(emulator_epoch_secret, "Epoch ID")
epoch_base_secret =
  DeriveSecret(emulator_epoch_secret, "Base Secret")
epoch_encryption_key =
  DeriveSecret(emulator_epoch_secret, "Encryption Key")

The epoch_base_secret is then used to key an instance of the PPRF defined in [I-D.ietf-mls-extensions] using a tree with 2^32 leaves.¶

Secrets are derived from the PPRF as follows:¶

VirtualClientSecret(Input) = tree_node_[LeafNode(Input)]_secret

Emulator client MUST store both the (punctured) epoch_base_secret and the epoch_id until no key material derived from it is actively used anymore. This is required for the addition of new clients to the emulator group as described in Section Section 5.4.¶

When deriving a secret for a virtual client, e.g. for use in a KeyPackage or LeafNode update, the deriving client samples a random octet string random and hashes it with its leaf index in the emulation group using the hash function of the emulation group's ciphersuite.¶

struct {
  u32 leaf_index;
  opaque random<V>;
} HashInput

pprf_input = Hash(HashInput)

TODO: We could also hash in the specific operation to further separate domains.¶

The pprf_input is then used to derive an operation_secret.¶

operation_secret = VirtualClientSecret(pprf_input)

Given an epoch_id, random and the leaf_index of the emulator client performing the virtual client operation, other emulator clients can derive the operation_secret and use it to perform the same operation.¶

Depending on the operation, the acting emulator client will have to derive one or more secrets from the operation_secret.¶

There are four types of MLS-related secrets that can be derived from an operation_secret.¶

• signature_key_secret: Used to derive the signature key in a virtual client's leaf¶

• init_key_secret: Used to derive the init_key HPKE key in a KeyPackage¶

• encryption_key_secret: Used to derive the encryption_key HPKE key in the LeafNode of a virtual client¶

• path_generation_secret: Used to generate path_secrets for the UpdatePath of a virtual client¶

signature_key_secret =
  DeriveSecret(epoch_base_secret, "Signature Key")

encryption_key_secret =
  DeriveSecret(epoch_base_secret, "Encryption Key")

init_key_secret =
  DeriveSecret(epoch_base_secret, "Init Key")

path_generation_secret =
  DeriveSecret(epoch_base_secret, "Path Generation")

From these secrets, the deriving client can generate the corresponding keypair by using the secret as the randomness required in the key generation process.¶

5.3. Creating LeafNodes and UpdatePaths

When creating a LeafNode, either for a Commit with path, an Update proposal or a KeyPackage, the creating emulator client MUST derive the necessary secrets from the current epoch of the emulator group as described in Section Section 5.2.¶

Similarly, if an emulator client generates an Commit with an update path, it MUST use path_generation_secret as the path_secret for the first parent_node instead of generating it randomly.¶

To signal to other emulator clients which epoch to use to derive the necessary secrets to recreate the key material, the emulator client includes an DerivationInfoExtension in the LeafNode.¶

struct {
  opaque epoch_id<V>;
  opaque ciphertext<V>;
} DerivationInfoExtension

struct {
  uint32 leaf_index;
  opaque random<V>;
} EpochInfoTBE

The ciphertext is the serialized EpochInfoTBE encrypted under the epoch's epoch_encryption_key with the epoch_id as AAD using the AEAD scheme of the emulation group's ciphersuite.¶

When other emulator clients receive an Update (i.e. either an Update proposal or a Commit with an UpdatePath) in group that the virtual client is a member in it uses the epoch_id to determine the epoch of the emulator group from which to derive the secrets necessary to re-create the key material of the LeafNode and a potential UpdatePath.¶

5.4. Adding emulator clients

There are two ways of adding new clients to the emulation group. Either new clients get sent the secret key material of all groups that the virtual client is currently in, or it joins into all of the virtual client's groups, either via a regular or an external commit.¶

TODO: Specify protocol¶

5.5. Virtual client actions

There are two occasions where emulator clients need to communicate directly to operate the virtual client. In both cases, the acting emulator client sends a Commit to the emulation group before taking an action with the virtual client.¶

The commit serves two purposes: First, the agreement on message ordering facilitated by the DS prevents concurrent conflicting actions by two or more emulator clients. Second, the acting emulator client can attach additional information to the commit using the SafeAAD mechanism described in Section 4.9 of [I-D.ietf-mls-extensions].¶

enum {
  reserved(0),
  key_package_upload(1),
  external_join(2),
  255,
} ActionType;

struct {
  ActionType action_type;
  select (VirtualClientAction.action_type) {
    case key_package_upload:
      KeyPackageUpload key_package_upload;
    case external_join:
      ExternalJoin external_join;
  };
} VirtualClientAction;

struct {
  KeyPackageRef key_package_ref<V>;
  opaque random<V>;
} KeyPackageInfo

struct {
  opaque epoch_id<V>;
  KeyPackageInfo key_package_info<V>;
} KeyPackageUpload

struct {
  opaque group_id<V>;
} ExternalJoin

5.6. Sending application messages

There are two issues when emulator clients send application messages through a virtual client: Nonce-reuse and key-reuse. Both issues ares solved as specified in Section 4.4 of [I-D.draft-mcmillion-mls-subgroups].¶

8.1. Smaller Trees

As a general rule, groups where one or more sets of clients are replaced by virtual clients have fewer members, which leads to cheaper MLS operations where the cost depends on the group size, e.g., commits with a path, the download size of the group state for new members, etc. This increase in performance can offset performance penalties, for example, when using a PQ-secure cipher suite, or if the application requires high update frequencies (deniability).¶

8.2. Fewer blanks

Blanks are typically created in the process of client removals. With virtual clients, the removal of an emulator client will not cause the leaf of the virtual client (or indeed any node in the virtual client’s direct path) to be blanked, except if it is the last remaining emulator client. As a result, fluctuation in emulator clients does not necessarily lead to blanks in the group of the corresponding virtual clients, resulting in fewer overall blanks and better performance for all group members.¶