What's MLS, and why does it matter for workspace privacy?
MLS (Messaging Layer Security, RFC 9420) is the IETF protocol that gives groups of any size the same encryption properties Signal popularized for one-on-one chat. Here's what it is, what it solves, and why workspace tools should care.
Messaging Layer Security — MLS — is an IETF protocol, published as RFC 9420 in July 2023. It's the standardized cryptographic foundation for end-to-end encrypted group messaging, and it's what Koaich uses for every vault that involves more than two people.
If you're familiar with Signal: MLS is the group-messaging equivalent of Signal's Double Ratchet. It does for a 200-person room what Signal does for a 2-person conversation — same level of cryptographic strength, designed from scratch to scale.
The problem MLS solves
Encrypted messaging between two people is a well-understood problem. The math has been solid for over a decade. The hard problem is when there are more than two people in the conversation — and especially when the membership changes over time.
Naive approaches don't work. If you just take Signal's two-party protocol and apply it pairwise to every member of a group, the cryptographic cost grows as O(n²). For a 100-person team room, that's 10,000 pairwise key exchanges per message. Worse: when a member joins or leaves, you have to re-key with everyone, every time. Latency stacks; reliability tanks.
The other naive approach — a shared symmetric key for the whole group — is fast but doesn't have forward secrecy. The key persists across membership changes, so a member who leaves can still decrypt future messages if they retain the key.
MLS solves both at once: cryptographic cost grows as O(log n), forward secrecy is preserved on every membership change, and the key derivation is automatic and consensus-based.
How MLS works (at a high level)
MLS organizes group members into a binary tree. Each member is a leaf. Each internal node holds a derived key, computed from the keys of its two children. The root of the tree is the group key — what everyone uses to encrypt and decrypt messages.
When a member joins: a leaf is added, and the keys along the path from that leaf to the root are recomputed. Members of the group receive a 'Commit' message that lets them update their copy of the tree without needing to know the new member's private key.
When a member leaves: their leaf is blanked, and the keys along their old path are recomputed. The new member-less tree produces a new group key. The departed member's device has the old tree but not the new one, so any message encrypted after their removal is unreadable to them.
When a member's device is compromised: the compromised member generates a fresh key, the tree is updated, and the affected member resyncs. The group key rolls forward; the attacker who stole the old key is locked out of future messages.
Why workspace tools should care
Workspace groups have one property that consumer messaging usually doesn't: high member churn. A matter team gains and loses associates. A board room gains and loses directors. A contractor cycles through a project for two months. A startup hires, fires, and rotates investors. Every one of those is a membership change that needs to roll keys forward without the messaging breaking.
Without MLS — or something cryptographically equivalent — workspace tools have two options: keep a static group key (and accept that departed members can keep reading), or burn the room and rebuild on every change (and lose continuity). Most tools choose option three: don't encrypt the group key in the first place. The vendor holds it, manages it, rotates it administratively, and trusts itself to do that correctly.
MLS is what removes that trade-off. The cryptography handles membership churn; the vendor doesn't need to be involved in key management; forward secrecy stays intact.
Who's using it
MLS is still young as a deployed protocol. It's used by Wire, RingCentral, Cisco, Discord (for E2E voice/video via the DAVE protocol layered on MLS), and a growing list of others. The IETF working group includes Apple, Google, Cisco, Mozilla, and Wire among its active contributors.
Koaich uses MLS for every vault that gains a second member. The ciphersuite is MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 — the spec's default and the one that pairs cleanly with the X25519-style vault identities we use elsewhere in the stack.
The honest framing
MLS isn't magic. It's a well-engineered standard for one specific hard problem in cryptographic groups. It doesn't make a workspace tool secure by itself; it gives the workspace tool a foundation to build on without the painful trade-offs the prior generation of group-messaging designs forced.
When you see a workspace tool claiming 'end-to-end encrypted group rooms,' the right follow-up question is: how do you handle membership changes? If the answer is 'we rotate the key administratively,' the vendor's still in the trust loop. If the answer is 'we use MLS,' the cryptography is.