Have y’all seen the new MLS protocol standard published by the IETF the other day? Sounds like it’s a new method of encryption key exchange designed especially for group messaging with multiple people.
RFC 9420: The Messaging Layer Security (MLS) Protocol (rfc-editor.org)
IETF | New MLS protocol provides groups better and more efficient security at Internet scale
If I remember correctly, MLS as it is requires a central authority. However, Matrix says they’re working on “best practices for MLS that will work without modification in a decentralized environment”.
Also, email, and therefore DeltaChat, has long used (Open)PGP. I think the question here is, what would MLS do that OpenPGP can’t, and what can MLS do better?
I don’t think MLS requires a central authority. The two server roles are Delivery Service and Authentication Service, and the architecture document lays out possible implementations of the Authentication Service that don’t require any server software (e.g. a client UI that shows keys).
It would be very cool if Delta Chat could ASCII-armor the MLS protocol data the same way PGP does, and use MLS as the underlying cryptographic mechanism!
PGP doesn’t offer forward secrecy at all. This means that if an adversary compromises the key for one message, they can decrypt all future messages. MLS’s ratchet tree system prevents this kind of compromise, making “harvest and crack” style attacks much more difficult.
Also, I think MLS has better guarantees around group consistency, which Delta Chat currently has some issues with (especially in large groups).
Forward secrecy can be implemented with OpenPGP by rotating the encryption key, you don’t need double ratchet for it. See https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf
Group consistency problems are solved in the latest Delta Chat versions by managing the group as LWW-Element-Set CRDT.
Regarding MLS requiring centralization, see https://arewemlsyet.com/ for Matrix attempts to adapt MLS for Matrix (which is federated) that links to unfinished decentralised.org · decentralised2 · matrix-org / mls-ts · GitLab
The requirement for linear ordering is documented at RFC 9420: The Messaging Layer Security (MLS) Protocol
This essentially means you cannot have partition tolerance, I don’t see how this can work if you have a temporary netsplit.
Oh, interesting! That does seem to do the trick, yeah. Having the stronger guarantees of MLS would be nice, but so long as all the Delta Chat clients do the rotation properly, that would be an excellent improvement.
Ahhh, I recall adb mentioning something about that in the Delta Chat Community group. That’s good to hear!
It’s a shame that those haven’t been updated since mid-2023. I’ll have to go digging around the Matrix side of things to see if they’ve made more progress on integrating MLS and figuring out how to solve the decentralization challenges.
Thank you for all the links and the clarifications!
Also see slide 43 from https://fosdem.org/2025/events/attachments/fosdem-2025-6274-the-road-to-mainstream-matrix/slides/237411/2025-02-0_uVigysz.pdf
I did not watch the talk at FOSDEM 2025 - The Road to Mainstream Matrix but from the slides alone you see mentions of a “hub server” that is a center which hosts the chat, this seems to be unavoidable with MLS without large redesign.
Seems DMLS is not updated because Matrix gave up on decentralization and decided to introduce the hub server to make it work.
There is some work on decentralized group key agreement that specifically addresses the problem of centralization MLS has here:
Wire wants to deploy MLS end of April:
Would be interesting to see how it goes. Could be the first Secure Messenger to have Continuous Group Key Agreement deployed.