10 ms·
The Messaging Layer Security (MLS) Protocol
- hwbehrens 3y agoI 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.
- richardwhiuk 3y agoOne of the authors works for Meta - J. Millican, Meta Platforms
- guerrilla 3y agoMeta 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.
- richardwhiuk 3y agoSure, but saying they aren't contributors isn't correct.
- Andrex 3y agoXMPP was either the wrong protocol for the right time, or the right protocol for the wrong time. I'm still not sure.
- cyberax 3y agoXMPP is a horrible protocol. It deserved to die. Who the hell thought that it's a good idea to use a never-ending stream of XML messages that required a custom parser?
- fabrice_d 3y agoNot 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.
- MattJ100 3y agoI'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.
- vilunov 3y agoProtocols 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. [1]: https://spec.matrix.org/latest/#namespacing https://spec.matrix.org/latest/#namespacing [2]: https://www.w3.org/TR/json-ld/#the-context https://www.w3.org/TR/json-ld/#the-context
- bdd 3y agoKatriel Cohn-Gordon is also a Meta employee.
- lukegb 3y agoMLS is currently being adopted by Google Messages for RCS (https://security.googleblog.com/2023/07/an-important-step-towards-secure-and.html https://security.googleblog.com/2023/07/an-important-step-to...) (I'm a Google employee, but don't work on this, not speaking for the company, etc etc etc)
- matricaria 3y agoMatrix is implementing this.
- dadrian 3y agoIt is already in use in WebEx.
- rpgbr 3y agoEU’s Digital Markets Act demands big tech to make their messaging apps talk to each other preserving e2ee.
- derhuerst 3y agoThis has been discussed recently [1] in another post. [1] https://news.ycombinator.com/item?id=36815705 https://news.ycombinator.com/item?id=36815705 (4 days ago, 202 points, 32 comments)
- pieter_mj 3y agoSometimes I'm overly relying on hn's ability catching dupes it seems.
- giaour 3y agoSecurity, Cryptography, Whatever did a good general overview of the spec a couple of months ago: https://securitycryptographywhatever.com/2023/04/22/mls/ https://securitycryptographywhatever.com/2023/04/22/mls/
- miketery 3y agoThis is a cool pod! Any other security / applied cryptography ones you or folks can recommend?
- ThePowerOfFuet 3y agoThis was incredibly painful to listen to because the host just wouldn't stop chuckling, giggling, and interrupting whoever was speaking.
- austin-cheney 3y agoThis 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.
- ementally 3y agoFrom https://simplex.chat/blog/20230722-simplex-chat-v5-2-message-delivery-receipts.html https://simplex.chat/blog/20230722-simplex-chat-v5-2-message... >Why not hosted groups with MLS? >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.
- ronsor 3y agoComplex 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.
- pkulak 3y agoEncrypted 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.
- mcdonje 3y agoI don't see how the existence of one attack vector makes addressing another irrelevant. To infiltrate an encrypted group chat like your scenario, the attacker needs to actually do social engineering work.
- anonymousiam 3y agoWhy are they using MLS to describe this? That acronym has already been widely used. https://en.wikipedia.org/wiki/Multilevel_security https://en.wikipedia.org/wiki/Multilevel_security https://csrc.nist.gov/glossary/term/multi_level_security https://csrc.nist.gov/glossary/term/multi_level_security https://gdmissionsystems.com/multilevel-security https://gdmissionsystems.com/multilevel-security https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/mls https://access.redhat.com/documentation/en-us/red_hat_enterp... https://www.ibm.com/docs/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0ze100/ch1.htm https://www.ibm.com/docs/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0ze1...
- lucideer 3y agoThis 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.
- anonymousiam 3y agoMLS 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. https://link.springer.com/content/pdf/10.1007/978-3-031-02333-0_8.pdf https://link.springer.com/content/pdf/10.1007/978-3-031-0233... https://csrc.nist.rip/nissc/2000/proceedings/papers/206.pdf https://csrc.nist.rip/nissc/2000/proceedings/papers/206.pdf
- walterbell 3y agohttps://www.ietf.org/blog/support-for-mls-2023/ https://www.ietf.org/blog/support-for-mls-2023/ [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.
- say_it_as_it_is 3y agoWhat is Moxie Marlinspike's take on this? I don't trust that an IETF task force is going to have the will to oppose government pressure for backdoors.
- retrocryptid 3y agoMinor 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.
- fabrice_d 3y agoThere's an open source implementation at https://openmls.tech/ https://openmls.tech/
- deeringc 3y agoThere's also https://github.com/cisco/mlspp https://github.com/cisco/mlspp
- txtsd 3y agoDoes this mean governments won't be able to make messaging services yield? Or will they mangle it anyway like they do TLS to block websites?
- dadrian 3y agoWhat do you think the government does to TLS?
- dhx 3y agoAnother win for djb for a fully rigid curve[1] required for the single mandatory cipher suite MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 [1] https://safecurves.cr.yp.to/rigid.html https://safecurves.cr.yp.to/rigid.html
- flangola7 3y agoWhy not AES256
- steelframe 3y agoBecause it's slower with no security benefit.
- flangola7 3y agoNot 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.
- upofadown 3y agoThe current thinking is that 128 bit AES is not really threatened by Grover's algorithm: * https://words.filippo.io/dispatches/post-quantum-age/#128-bits-are-enough https://words.filippo.io/dispatches/post-quantum-age/#128-bi... >CISA expects cryptographically relevant quantum computers to become a risk within 5 years... That seems incredibly unlikely right now...
- steelframe 3y agoFive 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.
- flangola7 3y ago