TL, DR. Internet Engineering Task Force (IETF) published a DMLS as the decentralized MLS. As IFT, we are also building a decentralized MLS called de-MLS. In this post, we compare the DMLS and de-MLS.
However, MLS provides great scalability and security in secure group messaging; it requires trusted delivery systems for ordering. It is crucial to keep scalability, every member in the group messaging needs to obtain the identical form of the tree, which is called the state. In other saying MLS RFC assumes the messages are well-ordered, which makes it possible to commit messages are delivered on time. This allows every member align on a unique state, which we called epoch tree state. Maybe you can ask yourself, what happens if some commits are wrongly delivered or are late? The answer is a fork. A fork means network partition, different subsets of members have different state and finally different group keys. This resulted with persistant fork, so they never converged into a single state. Still, we can make it possible by keeping all state info for all forks. If there is a need, we can change the fork, but it would affect the FS. Lastly, this forking situation implies that you cannot decrypt MLS messages since the encryption group key is different.
It is quite possible that this is a huge assumption and only possible for the federated (or centralized) structure. They also proposed a relaxed form of MLS called DMLS that allows a few forks as a draft RFC. The RFC has an assumption that these forks will be unified over time, which means all of them need to die except one. These forks are temporary, unlike the MLS forks. The members can store these forks with multiple commits. When there is unification, they conclude on a single one with a secure way, thanks to Puncturable pseudo random functions (PPRF) here. Unlike MLS, members cannot go back into the states by reading the old messages, which exatly the forward secure.
DMLS achieves this new functionality by introducing the PPRF primitive; unlike the traditional ones, the members cannot create the group secret for old epochs in forks. This allows DMLS to have a fork without compromising security. It means the epochs are not an integer in MLS anymore, so they are a cryptographic value for PPRF.
It sounds like DMLS is more suitable for network delays such as in P2P, but the RFC cannot provide other details as assumptions as follows:
- The number of forks should be limited: This means that the malicious members can create artificial forks. This makes the application inefficient. And the fork spam protection should be introduced by the application.
- The fork convergence: The application should handle the forks, and then the convergence is satisfied.
The no fork assumption in MLS is reduced to the fork limitation and convergence assumption in DMLS. So, where is the de-MLS according to this update:
The current de-MLS RFC is MLS backend which means we need to agree on a single state. For this purpose, we introduce binary (YES/NO voting-based) consensus and enable all members to have their voice. Since de-MLS allows multiple entities to create commits in P2P, naturally, we can have late commits. The late commits are getting canonical again with the help of the consensus. And deduplication of the commits is also specified in de-MLS RFC. Finally, here is a table that compares MLS, DMLS, and de-MLS.
| Property | MLS | DMLS | de-MLS |
|---|---|---|---|
| Ordering Model | Delivery Service total order | No global total order | External consensus |
| Fork Assumption | No Fork | temporary Forks (with unification later) | No Fork (with consensus) |
| Epoch Identification | integer | Cryptographic value for PPRF | integer |
| Forward Secrecy (FS) | Strong | PPRF mitigates | Strong |
| Consensus Assumption | Centralized DS | None | voting based binary consensus |
| Distributed Systems Model | Not suitable | Suitable (requires fork unification and limitation) | Suitable |
| Client Storage Complexity | Low | High (multi-branch state) | Medium (multi-proposals) |
| Security Philosophy | Fork-free strong ordering | Fork-tolerant + FS mitigation | Consensus-anchored MLS |
In the future, we can consider that the de-MLS can be DMLS backend to decrease voting rounds in the network. That means, the commit unification and handling the late commits problem will be reduced to the fork resolution rules. For anti-spam, we are going to use RLN, which already restricts the spam and limits forks.