I know some academics working on MLS and I spent some time last year trying to understand it, to decide if I wanted to work with them. I think this blog post doesn't mention the core problem that MLS is trying to solve, which is efficient and secure key management (including forward secrecy and post-compromise security, which the Signal Double Ratchet protocol does so elegantly) for group end-to-end encrypted messaging. You don't want to have a O(n^2) keys for n users to talk to each other, and you don't want to have a single shared session key that must be renegotiated among all participants every time one participant leaves or gets kicked out of the group. I think MLS can do this with O(lg n) keys and fewer key exchanges as participants come and go.
I've sort of mentally bucketed MLS into "secure end-to-end messaging for large group applications", like Slack or Telegram, where Signal's idea of a "group" is more akin to a bunch of people making plans to meet up for drinks or something.
(I don't know how accurate this really is, and MLS people would also probably argue that their abstractions work nicely for small groups too).
>I think MLS can do this with O(lg n) keys and fewer key exchanges as participants come and go.
Does this potentially help with the group end to end encrypted chat identity problem? The number of identities that need to be verified goes up O(n^2) with the number of participants. It is hard to make that usable.
I hope MLS will support a decentralized messaging system, which will be required for interoperable systems with no central authority like the Matrix network.
Originally it didn't[0], I hope this has changed or will. Otherwise, I'd guess it would be dead on arrival.
> The IETF had multiple prior lines of effort in this area during the development and widespread deployment of XMPP and SIP decades ago, but the nature of existing messaging implementations and the external environment have both changed significantly since then. Messaging applications now share more common content features and functionality, the MLS protocol has been developed to facilitate E2EE interoperable messaging, and regulatory pressure to interoperate has increased significantly (e.g., as a result of the EU Digital Markets Act).
> We sometimes found that the various components of Matrix came together in unexpected ways that created problems, even if they were fine in isolation. From our reading of the charter and current drafts, it is likely that MIMI will need to include new cryptographic protocols (or integrate existing ones). As such, an analysis that looks at how the pieces of the puzzle fit together would be valuable. Thus, we'd like to advocate for following the path of MLS and TLS 1.3 by engaging the security, privacy, cryptography and formal verification communities.
As your link discusses, MLS still requires centralization because of the requirements of total ordering of some messages by the delivery service. If you want a truly p2p encrypted group chat protocol then look at DCGKA by Matthew Weidner, Martin Kleppmann et al:
That's true, but not really relevant until you hit 1000s of chat members. MLS targets up to 50,000. But there isn't a plausible threat model for a secure chat that large (someone will leak or it will be infiltrated).
At 1000 members a DCGKA key update (when the group membership changes) is ~300kb. So, equivalent to someone sending a small image, which they probably do very frequently.
well, encryption needs computational resources; you have to expect higher overhead when you do encryption in the web compared to native code e.g. in Rust or C. It kind of is the upper bound of slowness ;)
The MIMI working group is meeting at IETF116 in Yokohama RIGHT NOW. I'm sitting in the meeting.
There's a live audio stream at https://datatracker.ietf.org/group/mimi/meetings/ or the video will be posted later after the meeting. You can also find links from that page to the charter, mailing list, etc, if you want to get involved.
Organizations cost quite a bit to run (mostly a mix of staff and marketing), and have different models for funding it. Some are more closed in participation, asking organizations and individuals to pay anywhere from $5k to $100k to participate, while some charge for the specs they produce.
IETF gets 40% of their revenue from meetings, but has managed to figure out how to fund open participation and open specs.
Yep, you can apply for a fee waiver if that's a significant challenge, but this org costs quite a lot to run (there's quite a big staff keeping the meeting running).
Having said that, the pricing for remote participants is currently a major topic of discussion.
Matrix is a protocol that is managed by "The Matrix.org Foundation" (https://matrix.org/foundation/). If the Matrix Foundation says they're transitioning to MLS, I suppose Matrix as a protocol is also shifting towards interoperability.
But by the same token, you're calling a blog post an rfc. If we're going to be fast and loose with words it should at least be allowed across the board.
The big difference between MLS and Signal Protocol is that MLS is tree structured (it began with a tree key derivation algorithm called ART, and now uses one called TreeKEM). An MLS group is structured as a binary tree with communicants at the leaves; pairs of communicants share an addressable key, as do pairs of pairs (forming subgroups) all the way on to the root, which computes a key that addresses the whole group.
Signal Protocol is entirely pairwise. A Signal group is a set of communicants who have established N^2 pairwise ratcheting relationships with each other.
See my other comment about this being a way to achieve all the nice properties of the Signal protocol in an efficient and scalable manner for group messaging instead of just 1:1 messaging.
They can peacefully coexist in a room by room choice of algorithm. Your other MIMI proposal, linear Matrix rooms, would weaken the integrity asumptions and completely change the trust model.
This is great an all but it doesn't really address the big problem with end to end encrypted messaging. That would be the usability issue. There is no point in constantly designing new protocols if very few people will ever be able to use the resulting systems. We make these things and then wait for someone to come along and make them usable. That never seems to happen.
I think we really have to turn things around the other way. First determine what a usable system would look like and then only after that is determined start thinking about the cryptography that would work for that system. After all, the cryptography aspect seems to be the relatively easy problem. We solve it over and over again.
Wire was a contributor to the MLS spec and their free app is usable without a phone number. For each person you are communicating with, there is a list of devices with a toggle button for "Verified". Once a conversation is taking place among verified devices, the addition of a new unverified device will block new messages and present the user with a warning to verify the device or override ("Send Anyway").
MLS E2EE is deployed in production today by Cisco WebEx.
So that was my question: is this supposed to be some kind of interoperable e2ee?
If yes, then that would be some equivalent of TLS but for e2ee, somehow. But then we need a protocol on top of that (for TLS that's HTTPS) to actually have interoperability at the application level, right?
But then it feels similar to saying "let's all agree to use the Signal Protocol and write interoperable clients, doesn't it? If I want a slightly different experience that requires a sightly different protocol, then suddenly I cannot interoperate anymore...
So what percentage of those billions are correctly using the ridiculously long numbers (60 decimal digits) used to represent identities (WhatsApp calls them "security codes") in that system to ensure they are actually communicating end to end? WhatsApp doesn't even inform the user of changes to these numbers by default[1] so my guess would be that practically no WhatsApp users are working end to end. WhatsApp can intercept messages at will.
I am not singling out WhatsApp here. In a usability study involving Signal[2], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection.
> what percentage of those billions are correctly using the ridiculously long numbers (60 decimal digits) used to represent identities (WhatsApp calls them "security codes") in that system to ensure they are actually communicating end to end?
Assuming one of those billions users is a motivated security enthusiast, WhatsApp is not able to perform MITM attacks at scale, as it would be trivial to prove. If WhatsApp decides to MITM your chats, it can't do so retroactively due to the properties of the protocol. If you're a high-profile target, you should verify your keys.
Well it's difficult for WhatsApp because it's closed source, so they can do whatever they want.
But let's assume the client app was open source, and WhatsApp decided to reset the key for some targeted users. Most users wouldn't realize, but if one did, then that would be very bad for WhatsApp. It would be all over the media. That's why it cannot be done at scale.
That's why it cannot be done at scale with Signal, too. Even if the users mostly ignore the "new key exchange" notification. If Signal MITM conversations and one person manages to prove it, then Signal is done. That's a pretty strong incentive for them not to do it.
