Post-quantum protection for group messaging is not a simple exchange between two endpoints. On October 26, a new experimental Internet-Draft proposed a hybrid classical and post-quantum key-encapsulation mechanism for Messaging Layer Security. The design places classical and post-quantum public keys in the MLS ratchet tree and combines their contributions when group state changes.
This is an individual Internet-Draft with experimental status, not an IETF standard or deployment recommendation. It may change, expire, or be replaced. Its operational value is immediate: it shows that cryptographic migration in a dynamic group is inseparable from state, membership, commit sequencing, bandwidth, recovery, and implementation behavior.
The protected asset is an evolving group state
MLS organizes members in a ratchet tree so group key updates scale efficiently. A membership addition, removal, reinitialization, or other commit changes the epoch and affects what each participant must know. In the proposal, each relevant tree node carries classical and post-quantum material, and the combiner binds shared secrets, ciphertexts, public keys, algorithm identifiers, group context, epoch, transcript hash, and node position.
A migration-ready inventory should therefore connect:
- the messaging service, tenant, group type, client population, owner, and data sensitivity;
- MLS version, ciphersuite, classical and post-quantum KEMs, libraries, and implementations;
- KeyPackages, credentials, devices, key stores, and member lifecycle;
- group identifiers, epochs, tree state, commit paths, and transcript handling;
- rotation policy, membership-change triggers, and post-compromise recovery window;
- message, ciphertext, storage, bandwidth, latency, and battery constraints;
- zeroization, caching, persistence, backup, recovery, and crash behavior;
- unsupported-version, decapsulation-failure, and downgrade handling; and
- test evidence, source maturity, confidence, exception, and accountable owner.
A checkbox saying “ML-KEM supported” answers almost none of those questions.
Membership changes are cryptographic events
In group messaging, removing a member is not merely an access-control database update. A removed participant possesses prior state, so the group must evolve secrets correctly to restore confidentiality. The draft treats additions, removals, reinitializations, and external commits as rotation events in its optional asynchronous mode.
Organizations need to know how real clients behave during offline periods, delayed delivery, device replacement, failed commits, and partial upgrades. A group can include desktop, mobile, embedded, and partner implementations moving at different release speeds. Migration readiness depends on the least capable required member and on policy for incompatible clients.
Bandwidth savings create a recovery tradeoff
The proposal explores an asynchronous mode that performs fresh post-quantum encapsulation only on designated rotation commits, while advancing a one-way ratchet on other epochs. This reduces post-quantum bandwidth but introduces a bounded delay in post-quantum post-compromise recovery. The draft makes the rotation interval part of the ciphersuite rather than a negotiable message field.
That tradeoff must be visible in governance records. A count of commits is not elapsed time: a busy collaboration group and a dormant control channel can take radically different amounts of time to traverse the same rotation window. Teams should measure actual commit rates and document the worst-case recovery delay relevant to each use case.
Failure behavior determines whether hybrid remains hybrid
The draft requires a failed decapsulation to abort the commit and forbids substituting zero, constant, fallback, or partial inputs. It also rejects unsupported algorithms or versions rather than silently falling back to non-hybrid operation. Those rules reflect a broader principle: both halves of a hybrid must remain present and context-bound in the running system.
Testing should deliberately corrupt each ciphertext and public key, modify context, replay commits, skip required rotations, present unsupported identifiers, and simulate state loss. Teams should confirm that failures do not advance the epoch, that old secrets are zeroized, and that logs expose useful operational evidence without leaking sensitive material.
Two architectures can create different inventories
The draft distinguishes its integrated tree-KEM approach from another proposal that runs classical and post-quantum MLS sessions in parallel and injects an exported secret. These alternatives have different state, traffic, implementation, and recovery dependencies.
Inventory records should name the architecture, not merely “hybrid MLS.” Otherwise tests, supplier claims, and risk decisions may appear comparable when they refer to different constructions. Architecture choice also determines which clients must change, how group state is duplicated or combined, and where operational evidence can be collected.
What organizations should do next
First, discover MLS and group-messaging use cases, including client populations, libraries, devices, credentials, and key storage. Map data lifetime and group membership patterns.
Second, separate algorithm capability from protocol integration. Track ciphersuite support, state handling, interoperability, rotation, recovery, and approved policy as distinct states.
Third, benchmark complete commits and group operations across representative sizes, devices, networks, and membership changes. Include bandwidth, latency, memory, energy, and recovery behavior.
Finally, treat this proposal as experimental. Monitor review and revisions, and do not present a prototype as standards-complete protection.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect cryptographic findings to applications, devices, hosts, locations, data, owners, suppliers, evidence, exceptions, and migration work.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The construction is new and has not completed standards review. Security analysis, registry allocations, parameters, performance, interoperability, and the rotation tradeoff may evolve. The prudent action is to inventory group-messaging dependencies and state behavior now, while keeping production claims tied to mature, validated specifications.
Source
- A Hybrid Post-Quantum KEM for the Messaging Layer Security Protocol, revision 00, IETF Datatracker / Adyta authors, October 26, 2026.