MLS Subgroups

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 21 September 2024.¶

Copyright Notice

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

Table of Contents

1. Introduction

MLS allows users to communicate in an end-to-end encrypted fashion but doesn't describe how to synchronize the operation of a user's devices. Instead, applications are generally expected to create distinct MLS clients for each device that a user has, and to ensure that all of the user's devices are added or removed from a group atomically. This creates some technical difficulties, as it can be hard for other members to ensure that the group truly stays in-sync with each user's set of authorized devices. It also creates a privacy issue because the members of a group can see which device a user sent a given message from, or when any user changes its set of authorized devices.¶

This document describes how to use an MLS group between all of a user's authorized devices to synchronize behavior, such that other users of the messaging service only see the user as a single MLS client. It does this in a way that preserves the Forward Secrecy and Post-Compromise Security guarantees of the groups that the user participates in, without requiring changes to the wire format of MLS.¶

2. Conventions and Definitions

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Device:

A user interface for messaging, performing encryption as needed.¶

User:

A (normally) human operator of a device. Users may have many devices, but a device only belongs to one user.¶

Subgroup:

An MLS group whose membership is exactly the set of authorized devices of a single user.¶

Virtual Client:

An MLS client that is controlled by one of many devices and synchronized by a subgroup.¶

Supergroup:

Refers to any MLS group which is not a subgroup.¶

3. Generation of Private Keys

When devices generate new asymmetric keypairs for a virtual client (such as a KeyPackage init_key or LeafNode encryption_key), they must do so in a way that the other devices participating in the subgroup can compute the private key as well. In the Subgroups protocol, a virtual client's private keys are derived deterministically from a secret exported from the most recent epoch in a subgroup. An extension is added to KeyPackages and LeafNodes generated this way to communicate to the other devices, which may not become aware of the keypair for several epochs, the epoch the private key was generated from.¶

Note that signature private keys are not generated this way. A virtual client's signature private key is generated once and shared directly with new devices.¶

subgroup_secret_tree_root
    = MLS-Exporter("Subgroup Secret Tree", "", KDF.Nh)

init_secret = DeriveSecret(tree_node_secret, "Subgroup KeyPackage")
init_priv, init_pub = KEM.DeriveKeyPair(init_secret)

leaf_secret = DeriveSecret(tree_node_secret, "Subgroup LeafNode")

leaf_node_secret = DeriveSecret(leaf_secret, "node")
leaf_priv, leaf_pub = KEM.DeriveKeyPair(leaf_node_secret)

path_secret[0] = DeriveSecret(leaf_secret, "path")

struct {
  uint64 epoch;
  uint32 leaf_index;
  uint32 random;
} PrivateKeyInfo;

opaque subgroup<V>;

nonce is sampled at random
subgroup = nonce || AEAD.Seal(key, nonce, "", PrivateKeyInfo)

4. Application Messages

Given that MLS generates the encryption keys and nonces for application and handshake messages sequentially, but a virtual client may send messages from several devices simultaneously, devices must take care to avoid reusing encryption keys and nonces.¶

If two devices encrypt a message with the same key simultaneously, they may have already deleted the relevant encryption key by the time they receive the other device's message, which will cause a decryption failure. This is a functional issue, and the best solution depends on whether the Delivery Service is strongly or eventually consistent [I-D.ietf-mls-architecture]. Devices communicating with a strongly consistent DS can prevent this issue by checking that they have processed all the messages sent to a group before sending their own message. Alternatively, devices communicating with an eventually consistent DS may simply need to retain encryption keys for a short period of time after use in case they are still necessary.¶

However, if two devices encrypt a message with both the same key and nonce simultaneously, this could compromise the message's confidentiality and integrity. Devices prevent this by ensuring two devices in a subgroup never choose the same reuse_guard.¶

output = SmallSpacePRP.Encrypt(key, input)
input = SmallSpacePRP.Decrypt(key, output)

prp_key = ExpandWithLabel(key_schedule_nonce, "reuse guard", leaf_secret, 16)
reuse_guard = SmallSpacePRP.Encrypt(prp_key, x)

5. Adding New Devices

When a user adds a new authorized device to their account, there are several pieces of cryptographic state that need to be synchronized before the device can start sending and receiving messages. The device can either get this state from another one of the user's devices, or if all of the user's other devices are offline, the device can use a series of external joins to prepare itself.¶

opaque MLSState<V>;

enum {
  reserved(0),
  empty(1),
  present(2),
} SecretTreeNodeType;

struct {
  SecretTreeNodeType node_type;
  select(SecretTreeNode.node_type) {
    case empty:
      SecretTreeNode left;
      SecretTreeNode right;
    case present:
      opaque value<V>;
  }
} SecretTreeNode;

struct {
  uint64 epoch;
  SecretTreeNode root;
} EpochSecretTree;

struct {
  KeyPackageRef ref;
  opaque init_secret<V>;
  opaque leaf_secret<V>;
} KeyPackageKey;

struct {
  opaque signature_private_key<V>;
  opaque subgroup_extension_key<V>;
  EpochSecretTree secret_trees<V>;
  KeyPackageKey key_package_keys<V>;
  MLSState group_states<V>;
} NewDeviceState;

struct {
  opaque signature_private_key<V>;
  opaque subgroup_extension_key<V>;
} ResyncMessage;

6. Aligning Security of Groups

Subgroups deprive supergroup members of visibility into whether key rotation is happening on a regular basis, and the extent to which compromised devices may have access to group secrets. As such, subgroups need to enforce policies that manage this concern.¶

A subgroup MUST have either the same or a stronger policy on how frequently devices must update their leaf node, than the groups that the virtual client is a member of.¶

Any time that a device is removed from a subgroup, an Update (or Commit with path populated) MUST be sent to all groups that the virtual client is a member of.¶

7. Security Considerations

TODO Security¶

8. IANA Considerations

This document defines two new MLS Extension Types, and a new MLS Exporter Label.¶

Acknowledgments

TODO acknowledge.¶

Author's Address