Part 2 – Server Architecture: TeamSpeak as an MLS Delivery Service
Summary
This is the server-side companion to the proposed MLS-based E2EE architecture for TeamSpeak 6.
(Companion thread for client architecture: [Feature Request] MLS (RFC 9420) Integration for TS6 E2EE – Part 1: Client Architecture)
The central idea is to use the TeamSpeak server as an MLS Delivery Service (DS).
The server would continue to perform the functions it already needs to perform for a TeamSpeak deployment:
-
user and client authentication,
-
channel permissions,
-
membership management,
-
message and media delivery,
-
connection management,
-
presence and server administration,
-
and enforcement of server-side policies.
However, the server would not need access to the plaintext of E2EE-protected communication or the corresponding group encryption secrets.
This would allow TeamSpeak to preserve its existing self-hosted server architecture while introducing a modern standardized group E2EE model.
1. The Proposed Architecture
At a high level:
TeamSpeak Server
┌────────────────────────┐
│ │
│ Authentication │
│ Permissions │
│ Channel Membership │
│ Routing / Delivery │
│ Presence │
│ MLS Delivery Service │
│ │
└───────────┬────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Client A Client B Client C
│ │ │
└─────────────────┼─────────────────┘
│
MLS Group State
│
End-to-End Encryption
The TeamSpeak server remains the central communication infrastructure.
The difference is that the cryptographic group state belongs to the participating clients rather than to the server.
2. Server as MLS Delivery Service
RFC 9420 separates the MLS protocol from the underlying delivery mechanism.
The Delivery Service is responsible for transporting MLS messages between members of a group and providing the infrastructure required for clients to exchange MLS protocol messages.
This maps naturally onto TeamSpeak’s existing server architecture.
For example:
Client A
│
│ MLS Commit
▼
TeamSpeak Server
│
├──────────────► Client B
│
└──────────────► Client C
The server does not need to decrypt or otherwise access the cryptographic contents of the MLS messages in order to deliver them to the appropriate group members.
The same general mechanism can be used for:
-
Commit messages,
-
Proposals,
-
Application messages,
-
Welcome messages,
-
and KeyPackage distribution.
The server therefore acts as the transport and coordination layer, while the clients maintain the cryptographic group state.
3. Separation of Responsibilities
A clean separation between the TeamSpeak server and the MLS cryptographic layer could look like this:
| Responsibility | TeamSpeak Server | MLS Client |
|---|---|---|
| User authentication | ✓ | |
| Server permissions | ✓ | |
| Channel membership | ✓ | |
| Connection management | ✓ | |
| Message/media routing | ✓ | |
| MLS group state | ✓ | |
| Group encryption secrets | ✓ | |
| Epoch state | ✓ | |
| TreeKEM state | ✓ | |
| Encryption / decryption | ✓ | |
| Forward secrecy | ✓ | |
| Post-compromise recovery | ✓ |
This separation is important because MLS should complement TeamSpeak’s permission system rather than replace it.
The server remains authoritative about who is authorized to participate in a channel.
MLS maintains the cryptographic state corresponding to that authorized group.
4. Existing Industry Example: MLS as a Delivery Layer
There is also a relevant real-world implementation of this architectural model.
Discord’s DAVE architecture uses MLS for group key management and integrates it with Discord’s existing real-time communication infrastructure.
The communication service participates in the delivery and coordination of MLS protocol messages without requiring access to the resulting media encryption keys.
This demonstrates that MLS can be integrated into a large-scale real-time communication system without requiring the delivery infrastructure itself to become the holder of the end-to-end encryption keys.
For TeamSpeak, the architectural principle could be similar:
TeamSpeak Server
│
Authentication / Permissions
│
MLS Delivery
│
┌────────────────┼────────────────┐
│ │ │
Client A Client B Client C
│ │ │
└────────────────┼────────────────┘
│
MLS Group
│
Group Key State
│
Media / Messaging
The important distinction is that TeamSpeak would not need to replicate Discord’s DAVE implementation.
Instead, TeamSpeak could independently evaluate MLS as the standardized group cryptographic foundation and integrate it with its existing server and media architecture.
This would allow TeamSpeak to retain its self-hosted server model while moving the cryptographic group state to the clients.
5. Channel Membership and MLS Membership
One of the most interesting architectural questions is how TeamSpeak channel membership maps onto MLS membership.
Conceptually:
TeamSpeak Permission Layer
│
▼
"Client may join"
│
▼
MLS Add / Commit
│
▼
Cryptographic
group membership
When a client is authorized to enter an E2EE-protected channel, the server can facilitate the corresponding MLS group operation.
The actual MLS state transition would be performed according to the MLS protocol by an authorized group member.
When a client leaves or loses authorization, the cryptographic group should transition accordingly.
This creates an important distinction:
TeamSpeak determines who is authorized. MLS determines who possesses the cryptographic state required to decrypt the protected communication.
A revoked client therefore should not simply remain a member of the cryptographic group after losing access to the TeamSpeak channel.
6. KeyPackage Distribution
MLS supports asynchronous group membership through KeyPackages.
A TeamSpeak server could provide the infrastructure necessary for clients to publish and retrieve their KeyPackages.
Conceptually:
Client A
│
publishes KeyPackage
│
▼
┌─────────────────┐
│ TeamSpeak Server│
│ │
│ KeyPackage Store│
└────────┬────────┘
│
requested by
│
▼
Client B
The server does not need to know the resulting group secret.
It provides the mechanism through which clients can obtain the cryptographic material required to establish MLS membership.
This also enables asynchronous onboarding:
A new client should not have to wait for another active client to come online merely because that client possesses the only currently available key material.
7. Removing a Client
Removal is particularly important for a communication platform with server-side permissions.
Suppose a client leaves a channel:
Before:
MLS Group
┌────┼────┬────┐
A B C D
B leaves
After:
MLS Group
┌────┼────┐
A C D
The TeamSpeak server can detect the membership change through its normal channel and session management.
The corresponding MLS membership transition can then establish a new cryptographic epoch.
The removed client should not receive the new group secrets.
This provides a much stronger relationship between access control and cryptographic membership than simply encrypting traffic while leaving old group keys valid.
8. Server Visibility
MLS does not make the TeamSpeak server completely unaware of communication metadata.
The server may still need to know information such as:
-
which clients are connected,
-
which channel they occupy,
-
which users have permission to access a channel,
-
where messages or media need to be delivered,
-
and potentially which clients belong to a particular MLS group.
That is expected.
The objective is not to make the server disappear from the architecture.
The objective is to ensure that:
The server can operate the communication infrastructure without possessing the cryptographic secrets required to decrypt protected content.
This distinction is important for a self-hosted communication platform.
9. Self-Hosted Servers
This model would preserve one of TeamSpeak’s most important characteristics:
The server remains fully under the control of the server operator.
A server administrator could continue to control:
-
server configuration,
-
channels,
-
permissions,
-
bans,
-
groups,
-
authentication,
-
logging policies,
-
and infrastructure.
At the same time, E2EE-protected content would remain encrypted between authorized clients.
This creates a useful separation between:
Server Administration
│
├── Who may connect?
├── Who may enter?
├── Where may they communicate?
└── How is traffic delivered?
≠
Cryptographic Confidentiality
│
├── Who possesses the group secrets?
├── Who can decrypt?
├── Which epoch is current?
└── Can previous state be recovered?
This is precisely the separation I would like to see explored for TeamSpeak 6.
10. Server Compromise
A particularly interesting property of this architecture is the effect of a compromised server.
If an attacker gains control over the TeamSpeak server, the attacker could potentially:
-
observe connection metadata,
-
manipulate or delay message delivery,
-
interfere with membership operations,
-
disconnect clients,
-
or attempt to disrupt the MLS group.
However, possession of the server alone should not provide the attacker with the MLS group secrets required to decrypt previously protected application data.
This is an important distinction:
Compromise of the delivery infrastructure should not automatically equal compromise of the communication content.
MLS does not eliminate the possibility of denial-of-service, traffic manipulation, or malicious delivery behavior. Its purpose is to provide cryptographic security for the group communication even though the delivery infrastructure does not possess the group’s encryption secrets.
11. Compatibility With Existing TeamSpeak Architecture
An MLS implementation should ideally be introduced as an additional cryptographic layer rather than requiring TeamSpeak to redesign its entire server architecture.
Conceptually:
Existing TeamSpeak
│
├── Authentication
├── Permissions
├── Channels
├── Sessions
└── Networking
│
▼
MLS Delivery Layer
│
▼
MLS Clients
This could allow MLS-protected communication to coexist with existing TeamSpeak functionality.
For example, the server could support different channel security policies:
Channel A
└── Standard TeamSpeak communication
Channel B
└── MLS-protected E2EE
Channel C
└── MLS-protected E2EE
+ restricted membership
This would also allow TeamSpeak to introduce MLS incrementally instead of requiring an immediate migration of every existing server and client.
12. Reliability and Persistence
A practical MLS implementation would also need to consider server persistence.
The server may need to retain certain MLS-related objects, such as:
-
KeyPackages,
-
delivery metadata,
-
queued MLS messages,
-
and information required for asynchronous clients.
However, these objects should not contain the actual group encryption secrets.
This distinction is particularly important for self-hosted deployments.
A server backup should therefore not automatically become a backup of the users’ E2EE group secrets.
13. Why This Architecture Fits TeamSpeak
The combination is interesting because the responsibilities align naturally:
TeamSpeak
│
┌─────────┴─────────┐
│ │
Server Layer Client Layer
│ │
│ │
Authentication Cryptography
Permissions MLS State
Channels Encryption
Delivery Decryption
Presence Key Management
│ │
└─────────┬─────────┘
│
Secure Group
Communication
TeamSpeak would therefore retain its traditional strengths as a self-hosted communication platform while gaining a standardized architecture for modern group E2EE.
Closing
The goal of this proposal is not to turn the TeamSpeak server into a cryptographic black box or to remove server administration capabilities.
The goal is to establish a clean architectural boundary:
The server controls access and delivers communication.
The clients control the cryptographic secrets.
MLS provides a standardized foundation for exploring this separation.
Combined with TeamSpeak’s existing channel, permission and self-hosted architecture, this could provide a strong foundation for scalable, asynchronous and privacy-preserving group communication.
I would very much like to see TeamSpeak investigate this architecture as a possible direction for future versions of TeamSpeak 6.
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