[walterbell]

What's a better alternative?

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.

[simplyaccont]

I didn't say that there is a better alternative. It's just... point of MLS is to build end-to-end secure messaging. Taking whatever party in the middle that deals with actual delivery out of "equation". For enterprise messaging it's very nice to have but must to have its history, searches and data exports ( for various legal needs, etc). MLS doesn't deal with this well. If at all. (unless it was recently changed)

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.

[walterbell]

Wire was one of the driving forces behind MLS and they have an enterprise messaging product (client and server) that is also open-source. Presumably they will be migrating their product to MLS, now that the protocol has reached 1.0.

[simplyaccont]

As I wrote above, you can torture protocol. Wire did it: "Additionally, Wire offers a surveillance service for administrators to track and record messages for specific users who require monitoring, helping you protect your organization from legal proceedings, such as litigation, government investigations, or Freedom of Information Act requests.". But it stops to be E2EE. It somewhat "okay" when it's self hosted. It's less okay when it's SaaS.

[walterbell]

From the MLS protocol discussion posted elsewhere in this thread, https://securitycryptographywhatever.com/2023/04/22/mls/

  .. 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.

[simplyaccont]

if i correctly understand what you are trying to say, then yes but no. None of the proper "enterprise" messaging systems will expose this kind of low level information. Moreover, enterprise messaging system will actively hide some of the information that is present in order to implement all the proper enterprise functionality.

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".

[walterbell]

In regulated industries, surveillance is known to the communicating parties, so there's no need to hide the presence of the mirroring member. From the interview above:

  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.

[ThePowerOfFuet]

This was incredibly painful to listen to because the host just wouldn't stop chuckling, giggling, and interrupting whoever was speaking.

[walterbell]

Thankfully there is a text transcript.