[HN Gopher] The Messaging Layer Security (MLS) Protocol
___________________________________________________________________
The Messaging Layer Security (MLS) Protocol
Author : pieter_mj
Score : 99 points
Date : 2023-07-25 15:38 UTC (7 hours ago)
(HTM) web link (datatracker.ietf.org)
(TXT) w3m dump (datatracker.ietf.org)
| derhuerst wrote:
| This has been discussed recently [1] in another post.
|
| [1] https://news.ycombinator.com/item?id=36815705 (4 days ago,
| 202 points, 32 comments)
| pieter_mj wrote:
| Sometimes I'm overly relying on hn's ability catching dupes it
| seems.
| anonymousiam wrote:
| Why are they using MLS to describe this? That acronym has already
| been widely used.
|
| https://en.wikipedia.org/wiki/Multilevel_security
|
| https://csrc.nist.gov/glossary/term/multi_level_security
|
| https://gdmissionsystems.com/multilevel-security
|
| https://access.redhat.com/documentation/en-us/red_hat_enterp...
|
| https://www.ibm.com/docs/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0ze1...
| lucideer wrote:
| 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.
| anonymousiam wrote:
| 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.
|
| https://link.springer.com/content/pdf/10.1007/978-3-031-0233.
| ..
|
| https://csrc.nist.rip/nissc/2000/proceedings/papers/206.pdf
| ementally wrote:
| From 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.
| giaour wrote:
| Security, Cryptography, Whatever did a good general overview of
| the spec a couple of months ago:
| https://securitycryptographywhatever.com/2023/04/22/mls/
| miketery wrote:
| This is a cool pod! Any other security / applied cryptography
| ones you or folks can recommend?
| pkulak wrote:
| 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.
| mcdonje wrote:
| I 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.
| dhx wrote:
| Another 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
| walterbell wrote:
| 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.
| xen2xen1 wrote:
| Apple.. Umm, how does this get us lock in again? No statement
| from MS is much more interesting.
| preya2k wrote:
| 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.
| pmontra wrote:
| Microsoft and Apple are missing.
| codethief wrote:
| And Signal. Does anyone know what their stance on the matter
| is?
| txtsd wrote:
| Does 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?
| say_it_as_it_is wrote:
| What 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 wrote:
| 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.
| fabrice_d wrote:
| There's an open source implementation at https://openmls.tech/
| deeringc wrote:
| There's also https://github.com/cisco/mlspp
| austin-cheney wrote:
| 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.
| hwbehrens wrote:
| 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.
| dadrian wrote:
| It is already in use in WebEx.
| matricaria wrote:
| Matrix is implementing this.
| lukegb wrote:
| MLS is currently being adopted by Google Messages for RCS
| (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)
| richardwhiuk wrote:
| One of the authors works for Meta - J. Millican, Meta Platforms
| guerrilla wrote:
| 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.
| Andrex wrote:
| XMPP was either the wrong protocol for the right time, or
| the right protocol for the wrong time. I'm still not sure.
| richardwhiuk wrote:
| Sure, but saying they aren't contributors isn't correct.
| cyberax wrote:
| XMPP 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?
| vilunov wrote:
| 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.
|
| [1]: https://spec.matrix.org/latest/#namespacing
|
| [2]: https://www.w3.org/TR/json-ld/#the-context
| fabrice_d wrote:
| 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.
| MattJ100 wrote:
| Many SAX parsers support namespaces natively. Expat is a
| popular choice.
| fabrice_d wrote:
| I mostly used the one from libxml2 but it's been a while
| and I could not remember if the SAX parser did namespace
| resolution :)
| MattJ100 wrote:
| 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.
| Andrew_nenakhov wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-25 23:01 UTC)