[AWS] Since the early days of MLS, AWS has been a core contributor by sharing our cryptographic expertise and engineering experience.
[Cisco] supported the Messaging Layer Security (MLS) effort since its inception — including by using a draft version of MLS for Webex Zero Trust meetings — and are delighted to welcome the publication of the MLS protocol standard.
[Cloudflare] With MLS, we see a future where large-scale, dynamic group communication can be private, secure, and efficient. We are eager to support and adopt this promising new standard.
[Google/Android] With seven years of development, MLS is mature and rigorously validated, making it the ideal choice to provide the security foundations of interoperable messaging."
[Matrix] With other interested parties, we’re continuing to develop decentralized best practices for MLS (so-called Decentralized MLS) that will work without modification in a decentralized environment such as Matrix or IETF’s MIMI
[Meta] conducted early research into Ratchet Trees alongside collaborators from Oxford University.
[Mozilla] Although end-to-end encryption is at the heart of this initiative, interoperability, scalability, and performance were significant goals met along the way. Mozilla is proud to support this new standard.
[Wire] Previously, technologies like Voice-over-IP and WebRTC played a significant role in democratizing global communication. Now, with MLS, we are building upon this success to again impact billions of people and achieve secure communication at an unprecedented scale.
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.
Yes, I’m aware. Yet I’m not entirely sure of the consequences: Does that mean, that dMLS and “regular” MLS could potentially still be interoperable (given they use the same Application layer protocol)?
company where i work implemented mls for very large groups (potentially tens of thousands of users) that can span across multiple servers in different geographies. won't recommend it.
it doesn't have things that are required for a proper "enterprise" messaging. so you need to hack around it. multi-device users were fun. chats with no active users that somebody joins to - more fun. state synchronization between multiple servers that host same chat - very exciting. during all those exercises you start to take little by little from mls. so even while it's preserved in the core, stuff that is added around, makes it "less".
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.
> 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.
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.
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.
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.
.. 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.
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".
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.
Yes. I know. And at this point for enterprise there is no reason to use MLS based solution for messaging. Or for software company to develop MLS based solution. Because it's just too complex for no obvious gain in security. Most of the enterprises/regulated industries/.govs simply do not need it. You can make much easier solutions.
It's still nice for security in personal instant messaging.
>Initially, we considered the design with the dedicated servers, potentially self-hosted, that host groups. This design would require adopting MLS (or similar) protocol for group-wide key agreement. Unfortunately, this design is not sufficiently resilient and easier to censor than decentralized design. Also, MLS protocol is very complex to implement, requires a centralized component, and reduces forward secrecy. So we decided against this approach.
Complex protocols are often the death of security. There's a good reason TLS 1.3 threw out 90% of the crap from older protocols: simplicity reduces chances for mistakes.
Not in the face of quantum computing. CISA expects cryptographically relevant quantum computers to become a risk within 5 years and is urging all security developers to transition to PQC ciphers as soon as possible.
Five years from now society will be in a full-blown panic about the uninhabitability of our planet. A quantum computer capable of breaking AES-128 will never be built.
> Five years from now society will be in a full-blown panic about the uninhabitability of our planet.
I don't disagree even 1%. Still, I don't think it hurts to plan for this. Broken encryption and hacked electrical grids is even more dangerous when there's a climate catastrophe ongoing.
>A quantum computer capable of breaking AES-128 will never be built.
My company has monthly meetings with the FBI and CISA. They are increasingly placing pressure to move to PQC. They're tight lipped, but they seem to know something we don't and I have the impression the danger is imminent.
Look up companies trying to hire quantum computer science researchers, it's nearly impossible because the federal government is writing blank checks and taking all of them.
> Taking these mitigating factors into account, it is quite likely that Grover’s algorithm will provide little or no advantage in attacking AES, and AES 128 will remain secure for decades to come.
I like the idea conceptually, but what is the likelihood of broader adoption? I notice that Meta, Apple, and Google are conspicuously absent from the contributors. Historically (see e.g. Matter) it seems like standards that aren't written to conform to existing de facto implementations tend to be superseded by later ones that are.
I'll admit to not having read the entirety of the RFC, but I'd also be curious about how the proposed approach maps to the current privacy/UX goals that the established players are pursuing, e.g. if WhatsApp wants to preserve cleartext moderation of E2E group chats, is that possible under this scheme, etc.
Meta preceeded Google in killing XMPP. I'm hopeful but cynical: companies have people on standard's committees for all kinds of other reasons, e.g. for prestige.
Protocols have many aspects, and the serialization format is often the least important among them, although it definitely attracts most attention, as it's the easiest to get acknowledged with deeply enough to be able discuss it.
XML back then (late 90s-early 00s) was quite an ubiquitous format, more popular than JSON. Websocket itself was drafted in 2010, so you wouldn't be able to come up with something better than a "never-ending stream of XML/JSON messages".
The single objectively positive aspect of XML is namespaces. It is very important for "extensibility" part of the protocol, as it allows you to introduce custom elements, which are namespaced by your org's domain name. Protocols such as Matrix [1] and ActivityPub [2] use JSON as the serialization format, but they too support extensibility, and therefore they have to implement namespacing. Which they do, but very differently.
I've created many XMPP implementations, and I've never created a custom XML parser for it (well, some toy ones for various fun things, but not one I'd use in production).
You're right that some XML parsers demand the entire document at once, and those are not suitable for XMPP (or any kind of incremental document parsing). Parsers with a SAX-based API for example don't have this limitation.
Xmpp is a good protocol. Zero of its problems were caused by XML. It has many really lousy and badly thought of and mutually inconsistent extensions, but an implementation can always ignore them.
All problems XMPP has are caused by the difficult problem which is decentralized messaging. Choose JSON or binary data format and eventually you'll encounter all the same problems again and again.
Not saying that XMPP overall is a great protocol, but you always could parse a XMPP stream with an event based XML parser (eg. a SAX parser). Yes you likely have to implement namespace resolution on top of the event stream, but it's not that hard.
Minor Nit: IEFT working groups don't implement code. Individual contributors do. But yes, looking at that list of companies, all of whom will be implementing code based on the spec, it's reasonable to have some concerns that they may yield to government pressure.
The flip side of this is that the spec is public so anyone can review it or take it to their local crypto expert and pay them to review it.
This past weekend I was trying to solve a similar problem also with shared public keys. I was having trouble getting it to work for my needs the way I wanted, so instead I am testing an approach of using large hash comparison based upon a preshared key. It’s a much higher grade of cryptographic reliability at a tiny fraction of the computational cost with many fewer parts to maintain.
Encrypted messages in large groups is such a hard problem, and, not to be crass, but is it worth solving? If I have 287 people on a group chat, how is that private, no matter the security? It seems like any adversary should be able to insert themselves into a situation like that unnoticed.
This is a spec. Multi-level security is a high-level concept - and not one that has much technical definition - the Wikipedia article (while problematic / vague) even includes some thoughts on semantic overload. As someone who works in security, it's not something that comes up - specific frameworks, applications & implementations are more relevant.
Avoiding every possible acronym clash in tech is not particularly viable today (and becomes less so daily).
---
Meanwhile, in the context of IETF's work, the acronym is natural and intuitive: Transport/Multiplexed-Transport -vs- Message makes immediate sense to anyone working with security in the context of network protocols.
MLS is quite a bit more than a "high-level concept" -- it has been implemented and has been in use throughout the US Government for nearly two decades.
