GROUP KEY AGREEMENT
How MLS turns membership changes into cryptographic state transitions.
Protecting a conversation between two endpoints is already a stateful protocol. A group adds members who join at different times, use several devices, miss messages and leave while the remaining participants continue.
Messaging Layer Security organizes that change into cryptographic epochs. Each committed membership update produces a new group state and new key schedule. Members derive the same secrets without sending a separate encrypted key to every participant.
Removing a member is effective only when the group completes the transition and every remaining client agrees on the new epoch.
A ratchet tree scales the key agreement
MLS represents group key material in a tree. Each member occupies a leaf and knows private secrets along its direct path. Public values allow updates to be distributed efficiently.
An update path replaces secrets from one leaf toward the root. Other members use the public information and their own private path secret to derive the new root.
The work grows logarithmically with group size for common operations rather than requiring one independent pairwise exchange with every member.
The epoch is the shared view
Each epoch commits to the group identifier, ciphersuite, tree, transcript and extensions. Application messages are protected under keys derived for that epoch.
A client receiving a message from another epoch must apply or retrieve the missing commits before interpreting it. Accepting content under an ambiguous epoch can attach it to the wrong membership state.
The epoch number is not merely a counter. It names a cryptographic view of who belongs to the group and which parameters they share.
Proposals do not change the group
Add, update and remove proposals describe intended changes. A Commit selects proposals, advances the key schedule and creates the next epoch.
A displayed administrative action may create a proposal before the group has processed its commit. Until then, the target member may still possess current epoch keys.
User interfaces and authorization systems should distinguish requested removal, committed removal and confirmation that relevant clients have advanced.
Removal protects the future
A properly removed member should not derive keys for later epochs. It can still retain every message and secret it legitimately obtained earlier.
Cryptographic removal cannot erase history from a compromised device. Nor can it prevent another remaining member from forwarding future plaintext.
The guarantee is forward exclusion from new group secrets, bounded by the honesty and update state of remaining clients.
Forward secrecy and post-compromise security need updates
Deleting old epoch secrets protects past messages after a current compromise. Fresh update paths can restore security for future epochs after an attacker loses access to the compromised client.
Healing is not automatic with the passage of time. It depends on an uncompromised member contributing fresh secret material and affected clients processing the update.
Backups that preserve every historical secret can defeat forward secrecy. Multi-device synchronization can extend compromise if it copies current state to a device that has not been cleaned.
KeyPackages are prepublished entry points
A client publishes a KeyPackage containing an initialization key, signature key, credential and supported capabilities. Another member can use it to add the client while that client is offline.
Initialization keys are intended for controlled use. Reusing a KeyPackage or its private key across additions can weaken security and link group memberships.
The directory distributing KeyPackages needs authentication, inventory and consumption semantics. An obsolete package can add the wrong device even when the MLS cryptography verifies.
The authentication service defines identity
MLS authenticates credentials and signatures according to the selected ciphersuite and application profile. It does not define what a user account is or which device may represent it.
An Authentication Service maps credentials to application identities and policies. Account recovery, device enrollment and enterprise membership remain outside the base protocol.
If the service can silently substitute a credential, key transparency can make that change visible and auditable.
The Delivery Service controls availability and order
MLS can operate over an untrusted Delivery Service. Encryption prevents it from reading application content or forging valid member messages.
The service can still delay, reorder or withhold commits and messages. It can give different clients incomplete histories and observe group-level metadata.
Clients need rules for buffering, fetching missing state and detecting that their local view has stopped advancing.
Concurrent commits create branches
Two members may create commits from the same epoch before learning of each other. Both cannot simply become the next group state.
The application needs an ordering and retry strategy. A losing commit may need to be reproposed against the accepted epoch with fresh update material.
Consensus over one linear group history is partly provided by the delivery environment, not by the tree alone.
Metadata remains a group property
Servers can commonly observe group identifiers, traffic timing, message sizes, membership operations and which devices fetch updates. Encryption protects message content, not all group structure.
Padding, batching and private delivery can reduce exposure, but large dynamic groups create distinctive patterns. The architecture should state which metadata the service is permitted to learn.
State backup is a security decision
A client that loses its current epoch state may be unable to decrypt new messages. Backing up state improves recoverability but creates another copy of current and possibly historical secrets.
A safe design can back up identity credentials separately, re-add a recovered device with a new KeyPackage and avoid restoring old epoch secrets. That choice may sacrifice access to old ciphertext unless messages are backed up under another key.
Recovery behaviour defines the practical boundary of forward secrecy.
Membership is the cryptographic state
MLS does more than encrypt messages to a list. It makes the list part of a shared authenticated state and evolves that state through proposals, commits and epochs.
Security depends on credential distribution, delivery ordering, key deletion and recovery practices outside the core protocol.
Removing a member creates a new epoch because membership is not metadata around the keys. It determines the keys.
