Feature Request: MLS-based End-to-End Encryption for TeamSpeak 6
Summary
This proposal suggests evaluating the standardized Messaging Layer Security (MLS) protocol (RFC 9420) as a foundation for TeamSpeak 6’s future End-to-End Encryption architecture.
MLS was specifically designed for secure, dynamic group communication and could therefore be a particularly natural fit for TeamSpeak’s channel-based communication model.
(Companion thread for server architecture: [Feature Request] MLS (RFC 9420) Integration for TS6 E2EE – Part 2: Server Architecture)
The Problem with the Current Chat E2EE
The current E2EE approach can create several usability and scalability challenges, particularly for asynchronous and group communication:
-
Synchronous dependency: Users can encounter states such as “Currently unable to decrypt message – Waiting for keys” when required key material has not yet been exchanged between active clients.
-
Group scalability: Pairwise or individually managed key relationships become increasingly complex as group size and the number of devices increase.
-
Post-Compromise Security: A compromised endpoint requires an appropriate rekeying or update mechanism to restore security after the compromise.
-
Multi-device complexity: Maintaining cryptographic state consistently across multiple authorized devices becomes increasingly difficult as the number of participants and devices grows.
These are precisely the types of problems MLS was designed to address.
Why MLS (RFC 9420)?
MLS provides a standardized cryptographic framework for dynamic groups with changing membership.
Existing Industry Example: Discord DAVE
MLS is not merely a theoretical proposal for this use case.
Discord’s DAVE (Discord Audio & Video End-to-End Encryption) architecture uses MLS as its underlying group key-management mechanism for end-to-end encrypted audio and video communication.
The important distinction is that DAVE itself is Discord’s broader E2EE architecture, while MLS provides the standardized group cryptographic layer underneath it.
This is particularly relevant for TeamSpeak because the underlying problem is similar: participants dynamically join and leave communication groups while encrypted real-time communication needs to continue without requiring every participant to be simultaneously online.
TeamSpeak would not need to adopt DAVE itself.
Instead, the relevant architectural concept would be to evaluate MLS as the standardized cryptographic group layer, while retaining TeamSpeak’s own native voice, networking and server architecture.
This would allow TeamSpeak to build on an established standard rather than developing another proprietary group key-management mechanism from scratch.
1. Efficient Group Key Management
MLS uses a ratchet tree based on TreeKEM to manage group cryptographic state.
Membership changes such as adding, removing, or updating members can be processed by updating the relevant path through the tree rather than performing independent key exchanges with every participant.
This makes the approach suitable for large and frequently changing groups.
2. Forward Secrecy and Post-Compromise Security
MLS provides mechanisms for both Forward Secrecy (FS) and Post-Compromise Security (PCS).
Group state advances through epochs. Once an epoch has been superseded and the corresponding secrets have been securely erased, previous cryptographic state cannot simply be recovered from the current state.
Following a successful update or commit after a compromise, fresh key material can be established, allowing the group to recover its security properties without requiring every participant to manually exchange keys.
3. Asynchronous Group Membership
MLS supports asynchronous group membership through KeyPackages.
A client can publish the cryptographic information required for a future addition in advance. A new participant therefore does not necessarily need another participant to be online at the exact moment the group membership is established.
This could significantly reduce situations in which cryptographic state depends on another participant being simultaneously online.
4. Natural Fit for TeamSpeak Channels
TeamSpeak already models communication around dynamically changing groups:
TeamSpeak Server
│
Channel A
│
┌────────────┼────────────┐
│ │ │
Client A Client B Client C
│ │ │
└────────────┼────────────┘
│
MLS Group
│
Current Epoch / Keys
A TeamSpeak channel could therefore map naturally to an MLS group.
Joining, leaving, or changing membership would trigger the corresponding MLS group-state transition.
Proposed Client Architecture
The cryptographic layer could be integrated below the TeamSpeak 6 user interface.
┌──────────────────────────────────────┐
│ TeamSpeak 6 UI │
│ CEF │
└──────────────────┬───────────────────┘
│
▼
┌──────────────────────────────────────┐
│ TeamSpeak Native Client Core │
│ │
│ Channel / Identity / Session Logic │
│ │ │
│ ▼ │
│ MLS Integration │
│ │
│ ┌──────────────────────────────┐ │
│ │ MLS State Machine │ │
│ │ │ │
│ │ • Group State │ │
│ │ • Epoch Management │ │
│ │ • KeyPackages │ │
│ │ • TreeKEM │ │
│ │ • Commit / Update Handling │ │
│ └──────────────────────────────┘ │
└──────────────────┬───────────────────┘
│
▼
Network Layer
│
▼
TeamSpeak Server
The CEF frontend would remain responsible for presentation and user interaction, while cryptographic state and MLS operations would remain isolated within the native client core.
This would also reduce the amount of cryptographic logic exposed to the UI layer.
OpenMLS as a Possible Implementation Basis
Rather than implementing a new group ratchet and key-management protocol internally, TeamSpeak could evaluate an established MLS implementation such as OpenMLS.
OpenMLS is implemented in Rust and aims to implement RFC 9420.
A possible integration architecture could use a small, well-defined native interface between the TeamSpeak client core and the MLS implementation:
TeamSpeak C++ Core
│
│ C / FFI boundary
▼
OpenMLS
│
▼
MLS cryptographic state
The exact implementation language or library should, however, remain an implementation decision for the TeamSpeak development team.
The important architectural proposal is the adoption of MLS itself, rather than a dependency on one particular library.
Multi-Device Support
MLS could also provide a cleaner foundation for multi-device scenarios.
Instead of treating a person as a single cryptographic endpoint, each authorized client/device could maintain its own MLS leaf.
For example:
MLS Group
│
┌───────────┼───────────┐
│ │ │
User A User B User A
Desktop Desktop Mobile
│ │
Leaf Leaf
This makes device-level membership and revocation explicit within the cryptographic group.
A device leaving or being revoked can therefore result in an appropriate MLS membership transition without requiring the entire group to be reconstructed manually.
Privacy and Trust Model
An MLS-based architecture could allow the TeamSpeak server to continue acting primarily as a trusted transport, authentication and delivery component, while keeping protected message and media content confidential between authorized clients.
The server would not need access to the plaintext content or the current group encryption secrets.
The server would, however, still need to handle operational information required by the TeamSpeak architecture, such as authentication, authorization, channel membership and message/media delivery.
This could provide a strong combination of:
-
self-hosted infrastructure,
-
familiar TeamSpeak server administration,
-
modern standardized cryptography,
-
scalable group key management,
-
Forward Secrecy,
-
Post-Compromise Security,
-
and asynchronous group membership.
MLS would not, by itself, hide all metadata such as channel membership, connection information or traffic patterns. Those aspects would need to be addressed separately.
Why This Would Be Valuable for TeamSpeak
TeamSpeak has a particularly interesting architectural characteristic compared with many modern communication platforms: self-hosted servers remain a central part of the product.
Combining this model with modern standardized group E2EE could provide a strong privacy architecture:
TeamSpeak Server
│
Authentication / Delivery
│
encrypted data
│
┌───────────┼───────────┐
│ │ │
Client Client Client
│ │ │
└───────────┼───────────┘
│
MLS Group
│
E2E encryption
The goal would not simply be to add another encryption mechanism, but to establish a cryptographic architecture designed from the beginning around dynamic, asynchronous group communication.
For TeamSpeak’s channel-based architecture, MLS appears to be a particularly promising standard worth evaluating.
Closing
I would very much like to see TeamSpeak investigate MLS as a possible foundation for future E2EE.
The combination of TeamSpeak’s self-hosted architecture with a modern, standardized group E2EE protocol such as MLS would represent a significant architectural opportunity for a communication platform where privacy is built into the underlying design.
As a privacy-focused TeamSpeak user, this is the direction I would personally love to see TeamSpeak explore.
I would also greatly appreciate the eventual publication of the cryptographic architecture and independent security audit results, and until then, I will be following the further development of the project with great interest.
Thank you for taking the time to consider this proposal.
Best regards,
Kosmoe a longterm TS user
