Beware that even though Matrix is supporting MLS, currently it's incompatible with the completely decentralized character of Matrix. MLS in its current shape relies on a centralized component – which is not a part of the Matrix protocol.
to be fair, i wasn't the one that was doing implementation, i was only reviewing it. it was done by in-house crypto team. so maybe something was lost between rfc to implementation to explanations to me about how it works/supposed to work. yet, mls function is secrecy and not enterprises.
MLS needs to support diverse, competing messaging systems, it's not a messaging system.
Related work, https://datatracker.ietf.org/group/mimi/about/
> Modern messaging services commonly support numerous features including plain and rich text, delivery notifications, read receipts, replies, reactions, presence, and many more. The working group will identify an extensible baseline set of messaging features and specify a content format to allow this feature set to be implemented interoperably. This format must be usable in the presence of E2EE.
Interoperability between different messaging system (is this what mimi is about ?) it's nice, but from perspective of enterprises it's not a must (for example ms lync or skype supported xmpp federation, but i never saw it enabled.). Because of security in various aspects. For example trust between servers of different organizations. Allowing accessing "some" external users "some" internal chats. Possibility of information leaking through those chats or in case that whatever access rules for external users were incorrectly defined.
So yes, MLS/MIMI could be nice for instant messaging, but it seems not too suitable for enterprise messaging.
.. you have a cryptographic guarantee that everybody sees the same list of admins, sees the same list of, of non-admins and general members and whatnot.
.. The server can absolutely not inject participants because the server is not a member. So, there is this add operation, that can only be performed by an existing member. However, there is also a way for a server, or let’s say generally an outside party to suggest, uh, other members.
But that requires the outside party, you know, to have a well-defined credential and to sign that request. And then that can be honored and everybody will see that that was a suggestion from the server. And that’s a controlled way, how you can add people to a group, but you can never do that, you know, steathily.How do you think otherwise "Wire offers a surveillance service for administrators to track and record messages for specific users " in order to "protect your organization from legal proceedings, such as litigation, government investigations, or Freedom of Information Act requests".
Raphael: .. the protocol itself is not enough to give you a completely private system because it’s really just one component, and to degree it is agnostic. Like, if you take double ratchet and X3DH, that’s when— you know it’s run inside of, of the Signal app, it’s super private. If you run that inside of WhatsApp, there’s two tons of metadata, but, it’s agnostic to the protocol as such. And the same is true for MLS.
Thomas: .. MLS does makes it possible to design secure group membership protocols that don’t depend on a server making sane decisions about who’s in the group.
Raphael: .. the list of members is hashed and then fed into the key schedule. So that’s how you have agreement on who’s in the group and who’s not .. when you receive a message, you also know who the sender thought they were sending it to.
Deirdre: .. that’s the thing you don’t get in Signal groups: you don’t know, everyone else that this person was trying to send to, because it’s all pairwise .. That’s pretty cool .. you can have your own [MLS] client that does whatever it wants, that can detect or reject or whatever it wants.It's still nice for security in personal instant messaging.