Network Working Group J. Alwen Internet-Draft AWS Intended status: Informational K. Kohbrok Expires: 18 December 2026 Phoenix R&D B. McMillion M. Mularczyk AWS R. Robert Phoenix R&D 16 June 2026 MLS Virtual Clients draft-ietf-mls-virtual-clients-latest Abstract This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. Status of This Memo 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 18 December 2026. Copyright Notice Copyright (c) 2026 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. Table of Contents 1. Introduction 2. Terminology 3. Requirements Language 4. Applications 4.1. Virtual clients for performance 4.1.1. Smaller trees 4.1.2. Fewer blanks 4.1.3. Emulation costs 4.2. Metadata hiding 5. Emulation group management 5.1. Adding an emulator client 5.1.1. Trade-offs 5.1.2. State transfer protocol 5.2. Joining externally 5.3. Removing emulator clients 6. Client emulation 6.1. Delivery Service 6.2. Generating Virtual Client Secrets 6.3. Creating LeafNodes and UpdatePaths 6.4. Virtual client actions 6.4.1. Creating and uploading KeyPackages 6.4.2. Externally joining groups with the virtual client 6.5. Sending PrivateMessages 6.5.1. Small-Space PRP 6.5.2. Reuse Guard 6.5.3. Coordinating ratchet generations with the DS 7. Security Considerations 7.1. Trust between emulator clients 7.2. Forward secrecy 7.3. Post-compromise security 7.4. Removing emulator clients 7.5. Handling of NewEmulatorClientState 7.6. Reuse guard 8. Privacy Considerations 9. IANA Considerations 9.1. virtual_clients 10. Normative References Authors' Addresses 1. Introduction The MLS protocol facilitates communication between clients, where in an MLS group, each client is represented by the leaf to which it holds the private key material. In this document, we propose the notion of a virtual client that is jointly emulated by a group of emulator clients, where each emulator client holds the key material necessary to act as the virtual client. The use of a virtual client allows multiple distinct clients to be represented by a single leaf in an MLS group. This pattern of shared group membership provides a new way for applications to structure groups, can improve performance and help hide group metadata. The effect of the use of virtual clients depends largely on how it is applied (see Section 4). We discuss technical challenges and propose a concrete scheme that allows a group of clients to emulate a virtual client that can participate in one or more MLS groups. 2. Terminology * Virtual Client: A client for which the secret key material is held by one or more emulator clients, each of which can act on behalf of the virtual client. * Emulator Client: A client that collaborates with other emulator clients in emulating a virtual client. * Emulation group: Group used by emulator clients to coordinate emulation of a virtual client. * Higher-level group: A group that is not an emulation group and that may contain one or more virtual clients. * Simple multi-client: A simple alternative to the concept of virtual clients, where entities that are represented by more than one client (e.g. a user with multiple devices) are implemented by including all of the entities' clients in all groups the entity is participating in. TODO: Terminology is up for debate. We’ve sometimes called this “user trees”, but since there are other use cases, we should choose a more neutral name. For now, it’s virtual client emulation. 3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here. 4. Applications Virtual clients generally allow multiple emulator clients to share membership in an MLS group, where the virtual client is represented as a single leaf. This is in contrast to the simple multi-client scenario as defined above. Depending on the application, the use of virtual clients can have different effects. However, in all cases, virtual client emulation introduces a small amount of overhead for the emulator clients and certain limitations when it comes to emulation group management (see Section 5). 4.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 6) allows emulator clients to carry the benefit of a single operation in the emulation group to all higher-level groups in which the virtual client is a member. 4.1.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. 4.1.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. 4.1.3. Emulation costs From a performance standpoint, using virtual clients only makes sense if the performance benefits from smaller trees and fewer blanks outweigh the performance overhead incurred by emulating the virtual client in the first place. 4.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 emulation 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. 5. Emulation group management Managing the emulation group is more elaborate than performing simple MLS operations within it. When adding a new emulator client, there are several pieces of cryptographic state that need to be synchronized before the new emulator client can start using the virtual client. The emulator client can either get this state from another emulator client, or if all other emulator clients are offline, the emulator client can use a series of external joins to onboard itself. 5.1. Adding an emulator client A joining emulator client is added to the emulation group by a provisioning emulator client via the usual MLS Add + Welcome. The GroupInfo in that Welcome carries the virtual_clients component (Section 9), whose component data is a NewEmulatorClientState struct that provides the state the joining emulator client needs to act as the virtual client going forward. The NewEmulatorClientState struct contains the complete secret state of the virtual client. Emulator clients MUST include it only in GroupInfo objects that are encrypted as part of a Welcome message for the emulation group. In particular, a GroupInfo object published to enable external commits into the emulation group MUST NOT contain a virtual_clients component. How the joining emulator client subsequently becomes an active participant in each higher-level group is application-defined. This document specifies two variants that the provisioning emulator client MAY use on a per-group basis: * *Variant A (provisioning state transfer).* The provisioning emulator client includes, for each higher-level group, the key- schedule outputs of the current epoch together with the HPKE private keys on the virtual client's direct path. The joining emulator obtains the RatchetTree and the GroupContext from an application-defined source. * *Variant B (external commit).* The provisioning emulator client only identifies which higher-level groups the virtual client is in. The joining emulator client acquires each group's current GroupInfo (from the DS or some other application-defined source) and performs an external commit into the group, evicting the virtual client's prior membership with a "resync" Remove proposal as described in Section 12.4.3.2 of [RFC9420]. Applications MAY mix the two variants across groups, for example using Variant A for groups where metadata hiding matters and Variant B elsewhere. Regardless of the variant chosen, a new emulator client MUST NOT send PrivateMessages in a higher-level group while the DerivationInfo of the active virtual-client LeafNode identifies an emulation-group epoch in which the new emulator client was not a member. The new emulator client has no leaf index at that epoch and therefore cannot compute the reuse_guard as described in Section 6.5.2. Before the new emulator client can send messages in such a higher-level group, the virtual-client LeafNode MUST be rotated (e.g., by a Commit with an update path or an Update proposal followed by a Commit) to a more recent emulation-group epoch in which the new emulator client is a member. Note that in higher-level groups where handshake messages are sent as PrivateMessages, the new emulator client cannot send this rotating Commit itself. In such groups, the rotation has to be performed by an existing emulator client, unless the application permits handshake messages framed as PublicMessages or external commits (Variant B), in which case the new emulator client can rotate the LeafNode itself. 5.1.1. Trade-offs * *Observability.* Variant A produces an ordinary Commit that looks like any other key rotation to the rest of the higher-level group. Variant B appears as the virtual client leaving and re-joining, which is visible to every member and may undermine metadata-hiding goals. * *Forward secrecy.* Variant A chains the new epoch from the previous epoch's init_secret. Variant B breaks the commit chain resulting in weaker forward secrecy at the point of onboarding. * *Policy.* Some applications may restrict external commits by policy leaving Variant A as the only option. * *State transfer cost.* Variant A requires O(log N) HPKE private keys and the current epoch's key-schedule state per higher-level group. Depending on group size and the group's ciphersuite, this may exceed the application's performance constraints. Variant B's overhead is constant per group. 5.1.2. State transfer protocol Applications MAY use the following structs to transfer group data to the newly added emulator client. opaque HPKEPrivateKey; struct { uint8 prefix_length; opaque prefix; opaque node_secret; } PPRFNode; struct { PPRFNode nodes; } PPRFState; enum { reserved(0), key_package(1), leaf_node(2), application(3), (255) } VirtualClientOperationType; struct { opaque epoch_id; VirtualClientOperationType operation_type; uint32 leaf_index; opaque random; opaque operation_secret; } RetainedOperationSecret; struct { uint32 node_index; opaque node_secret; } SecretTreeNodeState; enum { reserved(0), application(1), handshake(2), (255) } SecretTreeRatchetType; struct { uint32 leaf_index; SecretTreeRatchetType ratchet_type; uint32 generation; opaque next_secret; } SecretTreeRatchetState; struct { SecretTreeNodeState node_secrets; SecretTreeRatchetState ratchet_states; } SecretTreeState; struct { KeyPackageRef key_package_ref; opaque epoch_id; uint32 leaf_index; opaque random; } KeyPackageDerivationInfo; struct { opaque epoch_id; PPRFState epoch_base_secret; opaque epoch_encryption_key; opaque generation_id_secret; } EmulationEpochState; enum { reserved(0), state_transfer(1), external_commit(2), (255) } HigherLevelGroupStateType; struct { opaque group_id; HigherLevelGroupStateType state_type; select (HigherLevelGroupState.state_type) { case state_transfer: opaque init_secret; opaque sender_data_secret; opaque exporter_secret; opaque external_secret; opaque confirmation_key; opaque membership_key; opaque resumption_psk; opaque epoch_authenticator; SecretTreeState secret_tree; PPRFState safe_exporter_tree; HPKEPrivateKey direct_path_private_keys; case external_commit: struct{}; }; } HigherLevelGroupState; struct { opaque signing_key_material; KeyPackageDerivationInfo active_key_packages; RetainedOperationSecret retained_operation_secrets; EmulationEpochState past_emulation_epochs; HigherLevelGroupState higher_level_groups; } NewEmulatorClientState; * HPKEPrivateKey contains the serialized HPKE KEM private key for the ciphersuite used by the higher-level group. * PPRFState serializes a punctured binary-tree PRF as the set of retained subtree roots. The root of an unpunctured tree is represented by a PPRFNode with prefix_length 0 and a zero-length prefix. For other nodes, prefix contains the first prefix_length bits of the node's path, packed from most-significant bit to least-significant bit in each octet. Any unused low-order bits in the final octet MUST be zero. The entries in nodes MUST be prefix-free and sorted lexicographically by prefix. * RetainedOperationSecret carries an operation_secret whose PPRF input has been punctured, but whose derived key material is still live. Entries are identified by (epoch_id, operation_type, leaf_index, random). * SecretTreeState serializes the retained state of an RFC 9420 Secret Tree. Each SecretTreeNodeState contains an unexpanded tree node secret and its RFC 9420 tree node index. Each SecretTreeRatchetState contains the current state of a derived per-leaf hash ratchet; next_secret is the ratchet secret that will be used to derive the secret for generation. The serialized state MUST contain exactly the retained secrets needed to continue the Secret Tree deletion schedule from the sender's current state and MUST NOT contain secrets that have already been deleted. * signing_key_material is an application-defined blob that conveys whatever signing-key state the joining emulator client needs. For configurations where signing keys are derived from emulation-group secrets, it MAY be zero-length. See Section 6.2. * active_key_packages lists every KeyPackage the virtual client has outstanding. Each entry carries the KeyPackageRef together with the identifiers needed to find the corresponding retained key_package operation secret. When a Welcome arrives encrypted to one of these KeyPackages, the joining emulator client identifies the entry by KeyPackageRef, finds the RetainedOperationSecret matching (epoch_id, key_package, leaf_index, random), and uses its operation_secret to derive the corresponding init_key and KeyPackage LeafNode key material. * retained_operation_secrets contains every punctured operation_secret whose derived key material is still live. This includes operation secrets for outstanding KeyPackages, for the current LeafNode of each higher-level group, and for sent but uncommitted LeafNodes or UpdatePaths. * past_emulation_epochs carries, for every emulation-group epoch still referenced by an active LeafNode, KeyPackage, or retained operation secret and not equal to the current epoch, the punctured epoch_base_secret PPRF state, the epoch_encryption_key, and the generation_id_secret. State for the current emulation-group epoch is not included here because the joining emulator client derives it from the emulation group's Welcome. * higher_level_groups contains one entry per active higher-level group. Each entry carries the group_id and a state_type identifying which variant applies. For state_transfer entries, the provisioning emulator client transfers the current epoch's key-schedule outputs and the retained per-epoch state: * init_secret chains the joining emulator client's subsequent Commit into the next epoch (init_secret[n-1] combines with the new commit_secret to produce joiner_secret[n]). * sender_data_secret lets the joining emulator client decrypt sender data on incoming PrivateMessages. * exporter_secret lets the joining emulator client produce application-level exports from this epoch. * external_secret lets other parties perform further external commits from this epoch. * confirmation_key lets the joining emulator client verify the confirmation_tag on any incoming Commit. * membership_key lets the joining emulator client produce a valid membership_tag on its own Commit sent as PublicMessage. * resumption_psk lets the joining emulator client participate as an origin for resumption PSKs in this epoch, if the application uses them. * epoch_authenticator authenticates the current group state. * secret_tree is the current state of the group's Secret Tree, from which the joining emulator client derives per-member handshake- and application-ratchet keys needed to decrypt in-flight PrivateMessages. * safe_exporter_tree is the current punctured state of the Safe Exporter API's Exporter Tree if the higher-level group uses that API. If the group does not use the Safe Exporter API, nodes is zero-length. When used for a Safe Exporter Tree, PPRFState paths are 16-bit paths indexed by ComponentID. * direct_path_private_keys is the list of HPKE private keys for each non-blank node in the virtual client's filtered direct path. The first entry is the private key for the parent of the virtual client's leaf, if that node is non-blank. Subsequent entries correspond to the next non-blank nodes on the direct path toward the root, in order. The virtual client's leaf private key itself is derivable from the corresponding retained operation secret identified by the DerivationInfo on the current LeafNode and is therefore not transferred explicitly. For external_commit entries, no additional per-group fields are included. The joining emulator client external-commits into the group — fetching the current GroupInfo from the DS or another application-defined source — and includes a Remove proposal for the virtual client's prior leaf to evict the old membership. 5.2. Joining externally Without another online emulator client to bootstrap from, a new emulator can join the emulation group externally. A prerequisite for this external join is that the new client has the ability to learn which groups the virtual client is in and to externally join those groups. If those prerequisites are met, the new client needs to follow these steps: 1. Obtain a fresh credential that other emulation clients will accept. 2. Perform an external join to the emulation group. 3. Replace the virtual client's active key material by performing the following steps. Before each step, generate, derive or otherwise obtain the necessary credential and private signature key material. Ensure that other emulation clients can obtain the private key material. Details on credential and signature key generation and distribution are left to the application. The application MAY derive signature key material based on the new emulation group epoch as described in Section 6.2. 1. Replace all active KeyPackages with new KeyPackages, generated from the new emulation group epoch. 2. Perform an external join to all of the groups that the virtual client is a member of, using LeafNodes generated from the new emulation group epoch (see Section 6.2). Welcome messages which were unprocessed by the offline devices are discarded, and these groups are joined externally instead (potentially being queued for user approval first). 5.3. Removing emulator clients Since all emulator clients hold all key material of the virtual client, removing the emulator client entails its removal from the emulation group, as well as rotating or revoking any other virtual- client specific key material. To effectively remove an emulator client, the emulator client committing the proposal that removes the target client MUST take the following steps in order: 1. Effect the deletion of outstanding KeyPackages of the virtual client from the DS. The set of outstanding KeyPackages can be determined from the KeyPackageUpload messages previously sent to the emulation group (see Section 6.4.1). 2. Commit a Remove proposal for the emulation client to be removed in the emulation group, advancing it to a new epoch from which new virtual client secrets will be derived (see Section 6.2). Next, the application MUST provide new credentials and authentication key material for the virtual client that can be used to replace existing credentials and authentication key material in the next steps. The application MAY use the signature_key_secret derived from any of the operation_secrets during the next steps to derive group- specific key material. The application SHOULD take steps to revoke any valid long lived credentials associated with the virtual client that the removed emulator client had access to. Using the new emulation-group epoch, any combination of remaining emulator clients MUST do the following steps (in any order): * Effect an update of the key material in every higher-level group in which the virtual client is a member, using the new credential and authentication key material provided by the application. This MAY be done by creating a commit with an update path or sending an update proposal. * Upload a fresh set of KeyPackages derived from the new emulation- group epoch to replace those deleted in step 1. A corollary of this removal procedure is that in most scenarios another emulator client is required to be online and perform the necessary updates. The DS must also support deletion of previously uploaded KeyPackages. This is in contrast to the simple multi-client setup, where an external sender can effectively remove individual clients and there are no additional functional requirements for the DS. 6. Client emulation To ensure that all emulator clients can act through the virtual client, they have to coordinate some of its actions. Each emulation group MUST emulate exactly one virtual client. An emulation group MAY emulate that virtual client in multiple higher- level groups, but the virtual client MUST NOT be represented by more than one leaf in any given higher-level group. 6.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 higher-level group to which the message is sent, but also to all other clients in the emulation group. 6.2. Generating Virtual Client Secrets Generally, secrets for virtual client operations are derived from the emulation group. To that end, emulator clients derive an emulator_epoch_secret with every new epoch of that group using the Safe Exporter API defined in Section 4.4 of [I-D.ietf-mls-extensions], where virtual_clients_component_id is the component ID registered for the virtual_clients component in Section 9. emulator_epoch_secret = SafeExportSecret(virtual_clients_component_id) The emulator_epoch_secret is in turn used to derive four 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") generation_id_secret = DeriveSecret(emulator_epoch_secret, "Generation ID Secret") The epoch_base_secret keys a Virtual Client Secret Tree, a tree of secrets with the same structure as the Secret Tree defined in Section 9 of [RFC9420], with the following differences: * A Virtual Client Secret Tree always has 2^256 leaves, so that the output of the emulation group's ciphersuite hash function can be used directly as a leaf index. * The root of the tree is the epoch_base_secret rather than a secret derived from the encryption_secret of an MLS group epoch. TODO: Re-evaluate the tree size. A smaller tree (e.g., 2^128 leaves with the leaf index derived by truncating pprf_input) is probably sufficient. Secrets are derived from the Virtual Client Secret Tree as follows: VirtualClientSecret(Input) = tree_node_[LeafIndex(Input)]_secret Emulator clients MUST retain the (punctured) epoch_base_secret, the epoch_id, the epoch_encryption_key, the generation_id_secret, and the number of leaf nodes the emulation group's ratchet tree had at the corresponding epoch (including blank leaves, see Section 6.5.2) until no key material or generation IDs associated with that epoch are actively used anymore. For each retained epoch in which an emulator client was a member, it MUST also retain its own leaf index at that epoch. The epoch_base_secret, epoch_id, and epoch_encryption_key are used for deriving and processing virtual-client key material, including DerivationInfos and state transferred to new clients (Section 5.1); the generation_id_secret is used for computing generation IDs (Section 6.5.3); and the leaf count and leaf index are used for computing the reuse_guard (Section 6.5.2). When deriving a secret for a virtual client, e.g. for use in a KeyPackage or LeafNode update, the deriving client chooses a VirtualClientOperationType, 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. The operation_type is key_package when creating a KeyPackage, including the KeyPackage's init_key and LeafNode key material. The operation_type is leaf_node when creating a LeafNode for an Update proposal, a Commit with an update path, or an external commit. Applications MAY use the operation type application to derive application-specific key material. struct { uint32 leaf_index; VirtualClientOperationType operation_type; opaque random; } HashInput pprf_input = Hash(HashInput) The pprf_input is then used to derive an operation_secret. operation_secret = VirtualClientSecret(pprf_input) After deriving operation_secret, the emulator client MUST puncture pprf_input from the PPRF state for the corresponding epoch_base_secret. The emulator client MUST retain operation_secret as a RetainedOperationSecret until all key material derived from it is no longer active, and MUST delete operation_secret after that point. Given an epoch_id, operation_type, random, and the leaf_index of the emulator client performing the virtual client operation, other emulator clients can derive the operation_secret, puncture the same pprf_input, and use the operation_secret to perform the same operation. If the PPRF input has already been punctured, for example because the emulator client joined after the operation took place, the emulator client uses the corresponding RetainedOperationSecret transferred in NewEmulatorClientState. Depending on the operation, the acting emulator client will have to derive one or more secrets from the operation_secret. There are five 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 * reuse_guard_secret: Used to derive the PRP key for reuse_guard values when the virtual client sends a PrivateMessage (see Section 6.5.2) signature_key_secret = DeriveSecret(operation_secret, "Signature Key") encryption_key_secret = DeriveSecret(operation_secret, "Encryption Key") init_key_secret = DeriveSecret(operation_secret, "Init Key") path_generation_secret = DeriveSecret(operation_secret, "Path Generation") reuse_guard_secret = DeriveSecret(operation_secret, "Reuse Guard") The source of the virtual client's signature key is application- defined. An application MAY use signature_key_secret to derive a fresh signing key per operation, or MAY provide signing-key material through other means, for example a per-group or global signing key issued by the Authentication Service, or a signing key derived from an emulation-group epoch secret. Whatever the choice, the signing_key_material field of NewEmulatorClientState (see Section 5.1) carries the state a new emulator client needs; its contents are application-defined. 6.3. Creating LeafNodes and UpdatePaths When creating a LeafNode, either for a Commit with an update path, an Update proposal, an external commit, or a KeyPackage, the creating emulator client MUST derive the necessary secrets from the current epoch of the emulation group as described in Section Section 6.2. For a LeafNode in a KeyPackage, the creating emulator client MUST use the same key_package operation secret used to derive the KeyPackage's init_key_secret. For other LeafNodes, the creating emulator client MUST use a leaf_node operation secret. Similarly, if an emulator client generates a 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 a DerivationInfo struct as the virtual_clients component data in the LeafNode. struct { opaque epoch_id; opaque ciphertext; } DerivationInfo struct { uint32 leaf_index; opaque random; } DerivationInfoTBE The ciphertext is the serialized DerivationInfoTBE encrypted with the AEAD scheme of the emulation group's ciphersuite, with the epoch_id as AAD. The AEAD key and nonce are derived from the epoch's epoch_encryption_key, using the serialized encryption_key field of the LeafNode carrying the component as context: derivation_info_key = ExpandWithLabel(epoch_encryption_key, "key", encryption_key, AEAD.Nk) derivation_info_nonce = ExpandWithLabel(epoch_encryption_key, "nonce", encryption_key, AEAD.Nn) Since every virtual-client operation produces a LeafNode with a fresh encryption_key, each distinct DerivationInfoTBE is encrypted under a distinct key-nonce pair. Re-encrypting the same DerivationInfoTBE for the same LeafNode yields an identical ciphertext, which is benign. The operation type used to derive the LeafNode's operation_secret is determined by the LeafNode's leaf_node_source (Section 7.2 of [RFC9420]): key_package maps to key_package, while update and commit map to leaf_node. The leaf_index and random fields MUST be the values used with that operation type to derive the LeafNode's operation_secret. When other emulator clients receive a LeafNode for the virtual client, they use the epoch_id to determine the epoch of the emulation group from which to derive the secrets necessary to re-create the key material of the LeafNode and potential UpdatePath. They decrypt the DerivationInfo and use the operation type determined from the LeafNode's leaf_node_source, together with the leaf_index and random fields, as inputs to the operation secret derivation described in Section 6.2. The DerivationInfo on the active virtual-client LeafNode binds that virtual client's membership in the higher-level group to the emulation-group epoch identified by epoch_id. Protocol steps that require per-epoch emulation-group state for a higher-level group, such as computing the reuse_guard (Section 6.5.2) or a generation ID (Section 6.5.3), MUST use the emulation-group epoch identified by the active virtual-client LeafNode. 6.4. 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]. The SafeAAD component data of the virtual_clients component is a VirtualClientAction struct. 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; 6.4.1. Creating and uploading KeyPackages When creating a KeyPackage, the creating emulator client derives the init_key_secret, signature_key_secret, and encryption_key_secret from a key_package operation secret as described in Section 6.2. The KeyPackage's LeafNode MUST contain a DerivationInfo as described in Section 6.3 whose encrypted DerivationInfoTBE contains the same leaf_index and random values used for the KeyPackage operation. The random value MUST be the value reported for this KeyPackage in the corresponding KeyPackageUpload message. Before uploading one or more KeyPackages for a virtual client, the uploading emulator client MUST create a KeyPackageUpload message and send it to the emulation group as described in Section 6.4. The recipients can use the leaf_index of the sender, operation_type key_package, the random, and epoch_id to derive the operation_secret for each KeyPackageRef. They use that operation_secret to derive the KeyPackage's init_key and LeafNode key material. If the recipients receive a Welcome, they can then check which init_key to use based on the KeyPackageRef. struct { KeyPackageRef key_package_ref; opaque random; } KeyPackageInfo struct { opaque epoch_id; KeyPackageInfo key_package_info; } KeyPackageUpload After successfully sending the message, the sender MUST then upload the corresponding KeyPackages. The entries in key_package_info allow emulator clients to identify which KeyPackage to use and how to derive it when the virtual client receives a Welcome message. 6.4.2. Externally joining groups with the virtual client Before an emulator client uses an external commit to join a group with the virtual client, it MUST send an ExternalJoin message to the emulation group as described in Section 6.4. struct { opaque group_id; } ExternalJoin The sender MUST then use an external join to join the group with group ID group_id. When creating the Commit to join the group externally, it MUST generate the LeafNode and path as described in Section 6.3. 6.5. Sending PrivateMessages Given that MLS generates the encryption keys and nonces for PrivateMessages sequentially, but multiple emulator clients may send messages through the virtual client simultaneously, this can create a situation where encryption keys and nonces are reused inappropriately. Critically, if two emulator clients encrypt a message with both the same key and nonce simultaneously, this could compromise the message's confidentiality and integrity. Emulator clients MUST prevent this by computing the reuse_guard, as described below instead of sampling it randomly. 6.5.1. Small-Space PRP A small-space pseudorandom permutation (PRP) is a cryptographic algorithm that works similar to a block cipher, while also being able to adhere to format constraints. In particular, it is able to perform a pseudorandom permutation over an arbitrary input and output space. This document uses the FF1 mode from [NIST] instantiated with AES-128 as the underlying block cipher, with radix 2, numeral strings of length 32, and an empty tweak. A 32-bit unsigned integer is mapped to a numeral string by listing its bits from most significant to least significant; the output numeral string is mapped back to a 32-bit unsigned integer in the same way. output = SmallSpacePRP.Encrypt(key, input) input = SmallSpacePRP.Decrypt(key, output) key is a 16-byte AES-128 key; input and output are 32-bit unsigned integers. Where a 4-byte value such as the reuse_guard is required, the integer is encoded in network byte order (big-endian). 6.5.2. Reuse Guard MLS clients typically generate the bytes for the reuse_guard randomly. When sending a message with a virtual client, however, emulator clients choose a random value x such that x modulo N_e is equal to leaf_index_e, where: * e is the emulation-group epoch that produced the active virtual- client LeafNode in the higher-level group, identified by the epoch_id field of that LeafNode's DerivationInfo (see Section 6.3). * N_e is the number of leaf nodes in the emulation group's ratchet tree at epoch e, including blank leaves (see Section 7.7 of [RFC9420]). Since the ratchet tree is always full, N_e is a power of two, every member's leaf index is strictly less than N_e, and no two emulator clients share the same residue modulo N_e. * leaf_index_e is the encrypting emulator client's leaf index in the emulation group at epoch e. They then calculate: prp_key = ExpandWithLabel(reuse_guard_secret, "reuse guard", key_schedule_nonce, 16) reuse_guard = SmallSpacePRP.Encrypt(prp_key, x) ExpandWithLabel is computed with the emulation group's ciphersuite's algorithms. reuse_guard_secret is derived as described in Section 6.2 from the operation_secret of the operation that produced the virtual client's currently active LeafNode in the higher-level group. key_schedule_nonce is the nonce provided by the key schedule for encrypting this message. prp_key is computed in a way that it is unique to the key-nonce pair and computable by all emulator clients (but nobody else). reuse_guard is computed in a way that it appears random to outside observers (in particular, it does not leak which emulator client sent the message), but two emulator clients will never generate the same value. Recipient emulator clients can use the reuse_guard to recover the sender's leaf index in the emulation group. Since they share reuse_guard_secret and have access to key_schedule_nonce for the message, they can re-derive prp_key and invert the PRP to obtain x = SmallSpacePRP.Decrypt(prp_key, reuse_guard). The encrypting emulator client's leaf index in the emulation group at epoch e is then leaf_index_e = x mod N_e, where e and N_e are determined as described above. This allows recipients to attribute application messages to specific emulator clients without revealing the sender to outside observers. 6.5.3. Coordinating ratchet generations with the DS The method discussed above for computing reuse_guard prevents emulator clients from ever reusing the same key-nonce pair, as this would compromise the message. However, it does not prevent different emulator clients from attempting to encrypt messages with the same key but different nonces. While this doesn't create any security issues, it is a functionality issue due to the MLS deletion schedule. Other higher level group members (or indeed emulator clients) will delete the encryption key after using it to decrypt the first message they receive and will be unable to decrypt subsequent messages. The best solution depends on whether the Delivery Service is strongly or eventually consistent [RFC9750]. Emulator clients communicating with a strongly-consistent DS SHOULD prevent this issue by coordinating the use of individual ratchet generations for encryption through the DS. Emulator clients MAY send a generation ID to the DS whenever they fan out a private message. The generation ID is derived as follows. enum { reserved(0), application(1), handshake(2), (255) } RatchetType struct { opaque group_id; uint64 epoch; uint32 generation; RatchetType ratchet_type; } PrivateMessageContext generation_id = ExpandWithLabel(generation_id_secret, "generation id", PrivateMessageContext, Kdf.Nh) * group_id is the group_id of the higher-level group in which the PrivateMessage is sent * epoch is the epoch of that higher-level group at which the PrivateMessage is sent * generation is the generation of the ratchet used for encryption * ratchet_type is the type of ratchet used to encrypt the PrivateMessage * ExpandWithLabel as defined in [RFC9420] * generation_id_secret is derived as specified in Section 6.2 for the emulation-group epoch identified by the active virtual-client LeafNode in the higher-level group * Kdf.Nh is from the emulation group's ciphersuite Attaching the generation ID to the PrivateMessage allows the DS to detect collisions between generations per higher-level group, per higher-level group epoch and per ratchet type. Alternatively, devices communicating with an eventually-consistent DS may need to simply retain messages and encryption keys for a short period of time after sending, in case it becomes necessary to decrypt another device's message and re-encrypt and re-send their original message with another encryption key. 7. Security Considerations 7.1. Trust between emulator clients All emulator clients hold the complete secret state of the virtual client. Compromise of a single emulator client is therefore equivalent to compromise of the virtual client itself: the attacker learns the current epoch secrets of the emulation group and of every higher-level group the virtual client is a member of, and can impersonate the virtual client in all of them. Emulator clients have to trust each other fully; the emulation group does not provide any isolation between them. 7.2. Forward secrecy Forward secrecy for messages in higher-level groups depends on every emulator client deleting consumed key material according to the deletion schedule of Section 9.2 of [RFC9420]. Since every emulator client processes every message sent to a higher-level group, the effective forward secrecy of such a group is bounded by the emulator client that is slowest to advance its ratchets and delete its keys. The same applies to the retained state defined in this document: RetainedOperationSecrets and past emulation-epoch state (Section 5.1) extend the window during which a compromise reveals previously transmitted data, and emulator clients SHOULD delete them as soon as they are no longer needed. 7.3. Post-compromise security Some of the performance benefits of this scheme depend on the fact that one can update once in the emulation group and "re-use" the new randomness for updates in multiple higher-level groups. At that point, clients only really recover when they update the emulation group, i.e. re-using somewhat old randomness of the emulation group won't provide real PCS in higher-level groups. 7.4. Removing emulator clients The removal procedure in Section 5.3 is not atomic. Between the Commit that removes an emulator client from the emulation group and the completion of the key rotations in all higher-level groups, the removed client still holds valid key material for those groups and can read traffic in them and impersonate the virtual client. Applications SHOULD minimize this window and SHOULD revoke any long- lived credentials the removed client had access to, since a removed client that retains a valid virtual-client signing key and credential can otherwise re-join a higher-level group via an external commit. The procedure also depends on the DS actually deleting outstanding KeyPackages; a KeyPackage that escapes deletion allows the removed client to process Welcome messages addressed to the virtual client. 7.5. Handling of NewEmulatorClientState The NewEmulatorClientState struct contains the complete secret state of the virtual client and MUST only appear in GroupInfo objects encrypted within Welcome messages, as specified in Section 5.1. Publishing a GroupInfo containing the virtual_clients component, for example to enable external commits, discloses the secrets of all higher-level groups the virtual client is a member of. 7.6. Reuse guard The guarantee that no two emulator clients select colliding nonces (Section 6.5.2) relies on all emulator clients agreeing on N_e, on their leaf indices at epoch e, and on the exact PRP instantiation described in Section 6.5.1. The PRP key is 128 bits regardless of the ciphersuites in use; this bounds the sender-attribution and unlinkability properties of the reuse guard but does not affect the confidentiality of MLS messages. 8. Privacy Considerations Using a virtual client masks the emulation group's membership and activity from other members of higher-level groups: additions, removals, and updates of emulator clients appear in higher-level groups as ordinary LeafNode updates of the virtual client, and PrivateMessages sent by different emulator clients are indistinguishable to other higher-level group members. Whether the identity of the emulator clients is hidden additionally depends on the design of the Authentication Service and on the credentials the application provisions for the virtual client. The following residual metadata remains observable: * The presence of a DerivationInfo in a LeafNode reveals to anyone with access to the ratchet tree (including a DS that distributes GroupInfo or ratchet trees) that the leaf belongs to a virtual client. Applications that want to hide which leaves are virtual would need non-virtual clients to include indistinguishable components. * The epoch_id in a DerivationInfo is identical across all LeafNodes and KeyPackages that the virtual client produces from the same emulation-group epoch. Parties with access to the ratchet trees of multiple higher-level groups can use it to link the virtual client's leaves across those groups, and can observe how often the emulation group commits. * Generation IDs (Section 6.5.3) are only attached by virtual-client senders and therefore identify virtual-client traffic to the DS, in addition to revealing how many distinct ratchet generations are in use. * An external commit by a virtual client (Variant B of Section 5.1, or Section 5.2) is visible to all members of the higher-level group as the virtual client leaving and re-joining. 9. IANA Considerations This document requests the addition of a new value under the heading "Messaging Layer Security" in the "MLS Component Types" registry. 9.1. virtual_clients The component implementing the virtual client emulation defined in this document. The component data carried in each location is determined by the object in which the component appears: * In GroupInfo objects of the emulation group, the component data is a NewEmulatorClientState struct carrying the state a newly added emulator client needs to act as the virtual client (Section 5.1). * In LeafNode objects of a virtual client, the component data is a DerivationInfo struct communicating how to derive the LeafNode's key material (Section 6.3). * In SafeAAD objects of Commits in the emulation group, the component data is a VirtualClientAction struct communicating which virtual client action is taken in conjunction with the Commit (Section 6.4). * The component ID is additionally used with the Safe Exporter API to export the per-epoch emulator_epoch_secret from the emulation group (Section 6.2). The requested registration is: * Value: 0x0006 (suggested) * Name: virtual_clients * Where: GI, LN, AD, ES * Recommended: Y 10. Normative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-mls-extensions] Robert, R., "The Messaging Layer Security (MLS) Extensions", Work in Progress, Internet-Draft, draft-ietf- mls-extensions-09, 2 March 2026, . [NIST] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption", n.d., . [RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, . [RFC9750] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and A. Duric, "The Messaging Layer Security (MLS) Architecture", RFC 9750, DOI 10.17487/RFC9750, April 2025, . Authors' Addresses Joël Alwen AWS Email: alwenjo@amazon.com Konrad Kohbrok Phoenix R&D Email: konrad.kohbrok@datashrine.de Brendan McMillion Email: brendanmcmillion@gmail.com Marta Mularczyk AWS Email: mulmarta@amazon.ch Raphael Robert Phoenix R&D Email: ietf@raphaelrobert.com