Skip to main content


Messaging Layer Security (MLS) has been accepted by the IETF for publication as a standard. MLS is and #EndToEndEncryption method designed for group messaging. I've been working on integrating a variant of it with @Matrix.org (keep an eye out for demos coming soon). I've sat in on some of the IETF meetings, and the (not yet published) RFC may even contain some words that I've strung together. Congratulations to everyone who worked on it!

https://www.ietf.org/blog/mls-secure-and-usable-end-to-end-encryption/
How are you managing MLS' requirement to have strict ordering on commit messages in Matrix DAG message model?
Yes, good question. That's why I'm saying that I'm integrating a "variant of it" with Matrix. I've made some modifications (brief notes at https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentralised2/decentralised.org) to make it work in a decentralised system. There is more than one group working on approaches to decentralising MLS, and hopefully the next version of MLS will support a decentralised mode.
Given how long standardization of MLS took, do you believe there will be a new, IETF version of MLS within the next 5 years? If MIMI WG or EU DMA are going to make any recommendations for e2ee messaging, won't that be the current MLS version?

Do you think there could be reasonable ways to create a strict ordering of messages in the decentralized case so that no changes to MLS are necessary?
I don't know about the timelines, but there's already talk amongst people in the MLS WG about working on a new version of MLS.

I don't think it's possible to use an unmodified MLS in a decentralised case. Even if you could create a strict ordering, would have to end up completely discarding some updates, which is less than ideal.
While discarding updates is less than ideal, it is inevitable, as there never is instant state synchronization across all devices

I had a look at your proposal. It seems to introduce the notion of "application’s group membership" which I guess is referring to the matrix room membership. Is this proposal primarily meant for Matrix or do you envision to build something for the generic case that's compatible with every messenger (incl those that don't have room membership).
The proposal is intended to be fairly generic. You need some sort of notion of who's in the group, or else you don't know who to encrypt for.
Of course you need to know who to encrypt to, but MLS already takes care of that, no? That's why you Add/Remove keys/leafs.

On the application layer, a notion of group membership is not necessary and especially it doesn't need to be managed by servers (and if it's done by clients, than again, MLS already handles that, so clients "just" need to keep the MLS state and their application state in sync).
If you're using a system where you can just use MLS's notion of membership, then you can just use that and ignore that part of my proposal. But if you're in a decentralised situation where membership changes can come from anywhere and need to be merged together, then you may need something outside of MLS to manage that. (Consider: Alice bans Bob from the room in one branch, and Bob invites Carol in another branch. When the branches get merged, should Carol be in the room or not?) MLS doesn't include any way of resolving those types of conflicts.

Also, MLS isn't a complete membership system; for example, it doesn't define any permissions, and deliberately leaves that up to the application. For example, if Alice sends a commit that removes Bob from the tree, is that a valid operation? MLS leaves it up to the application to decide if that should be accepted.
In your example there is no reasonable way to automatically decide if Carol should be in the room or not. I don't know how Matrix handles that case, but in the end, you have to semantically apply one before the other (Add Carol before removing Bob or remove Bob first and reject Carol's addition), implying an ordering of the two, which then would be possible in MLS as well.
Yes, MLS does not have an internal model of permission levels, but for many chats that's not needed, as is shown merely by the fact that some popular messengers don't have them either.

If the application wants to handle permission levels, that's still perfectly compatible with MLS. But that also doesn't imply that the application's server(s) need to have full insights into group membership (e.g. they could be restricted to only know and share who is an admin of the group).
I don't think I ever said that the servers need to have any knowledge of the group membership. All I said was that "the application has a way to allow clients to determine the membership of the group in the face of concurrent changes to the group membership." Whether it's done client-side or server-side, it shouldn't matter.
In the end what I was hoping to reach with MLS, is that we have a single standard that covers all relevant usecases and can be used across messengers and bridges (thinking of MIMI and DMA here). If everyone just takes MLS and adjusts it to their wishes, this wouldn't work. Thus I'm proposing to try figure out if it's possible to use MLS with Matrix without further modifications of MLS. Maybe even introducing restrictions to Matrix for MLS encrypted chats should be considered.

vanitasvitae reshared this.

Yes, I agree. I would have liked to be able to use an unaltered MLS for Matrix, but haven't figured out a way to do it. Of course, just because I can't figure it out, doesn't mean it isn't possible, and if anyone has any brilliant ideas, I'd be happy to hear them.
⇧