Messaging layer security: Secure and usable end-to-end encryption | Hacker News Reader

Messaging layer security: Secure and usable end-to-end encryption

ietf.org

115 pointswalterbell56 comments

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

Is that not what schnorr signatures solve?

... no?

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

[0] https://matrix.uhoreg.ca/mls/decentralised.html

Interoperability work on top of MLS is underway.

Edit: see https://news.ycombinator.com/item?id=35366250 for audio.

https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-... & https://news.ycombinator.com/item?id=33420112

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

https://mailarchive.ietf.org/arch/msg/mimi/CI3z3CUPE8rrC5p4_... & https://techcrunch.com/2022/12/30/inside-matrix-the-protocol...

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

https://dl.acm.org/doi/10.1145/3460120.3484542

the link was updated in 2021

And it's still true today. I was considering implementing MLS myself, but decided against it because of this.

https://github.com/mlswg/mls-architecture/blob/main/draft-ie...

Sad

DCGKA has O(n) complexity, so more like Signal groups than MLS.

Here's a version of MLS (By Alwen, Mularczyk, Tselekounis) which supports out order delivery of commits.

https://eprint.iacr.org/2023/394

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

it's already relevant at 1000 members, and why not use it when it is possible?

Also, switch messenger once you hit 1k?

Even it a leak may be possible, it still isn't guaranteed. Instead you guarantee server side access without e2ee

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.

per device? what about the computational costs involved (which may require wasm/js)?

Don't get me wrong, FR-CGKA looks cool. I hadn't seen it yet, and am still reading it.

Not sure why wasm/js is relevant to the discussion.

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 ;)

I thought the selling point of wasm was close to native speed. :-)

If something is important browsers can always add it to webcrypto anyway.

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.

125$ for 1 day access remote, are they serious?

https://registration.ietf.org/116/

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.

https://datatracker.ietf.org/doc/draft-ietf-shmoo-remote-fee...

Yep.

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.

If that's meant to be an RFC:

> Other apps, such as Wickr and Matrix, are planning to transition to MLS [...]

Matrix is a protocol, not an app, right? Maybe I'm being pedantic, but I tend to trust RFCs, so... cannot hurt to be precise, I think.

definitely protocol

https://spec.matrix.org/v1.6/

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.

Sure. My point is that if it is a protocol, then the RFC should not say that it is an app :-)

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.

I said "if that is meant to be an RFC". Of course if it is not meant to be an RFC, then it does not really matter...

English is not my mother tongue, so maybe I missed something here.

AFAICT this is not an RFC, it's just a blog post.

MLS is a month or two away from becoming an RFC.

I love standards so this is great. Someone smarter than me please explain the differences between this and the Signal Protocol.

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.

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.

> Other apps, such as Wickr and Matrix, are planning to transition to MLS

What exacty is the Matrix' plan wrt MLS? This announcement sounds almost like they will retire current Matrix 1.6 protocol. Is this accurate?

MSC3923: Bringing Matrix into the IETF process — https://github.com/matrix-org/matrix-spec-proposals/pull/392...

MSC3977: Matrix as a Messaging Framework — https://github.com/matrix-org/matrix-spec-proposals/pull/397...

MSC3919: Matrix Message Format — https://github.com/matrix-org/matrix-spec-proposals/pull/391...

MSC3918: Matrix Message Transport — https://github.com/matrix-org/matrix-spec-proposals/pull/391...

https://arewemlsyet.com. We won’t retire the current olm/megolm but complement it with MLS, and perhaps transition entirely if MLS works out.

Matrix is already really complicated! You'd really consider having it run two interacting ratcheting group messaging protocols?

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.

Congrats!! Very long time coming & very exciting! Will it get an rfc number soon?

I am a bit confused, I only find an abstract there. Is it supposed to link to a longer definition that would become an RFC?

> The IETF has approved publication of Messaging Layer Security (MLS)

Dated March 29th. Not quite final, but I believe this link is about the imminent release of the core spec.

These are the current drafts:

* https://datatracker.ietf.org/group/mls/documents/

You have to click on the "Document" tab.

Oh, somehow it was not so clear to me on smartphone. Thanks!

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.

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

Or am I missing something?

WhatsApp is used by billions, and uses (at least in theory) e2ee, so I don't think usability is a real problem for e2ee

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.

[1] https://faq.whatsapp.com/1524220618005378

[2] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

> WhatsApp doesn't even inform the user of changes to these numbers by default[1]

is this everything?

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

>If WhatsApp decides to MITM your chats, it can't do so retroactively due to the properties of the protocol.

Can't they just set you up as a new device? The user wouldn't know if they left the notification at the default setting.

Whatsapp would not MITM ever single user. They would carefully target particular individuals.

I think they could do literally anything, because it is closed source; including forging random keys or ignoring the notification setting, ...

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.

We absolutely do not solve messaging cryptography over and over; the field is littered with corpses, many of them quite fresh.

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.

Reply on news.ycombinator.com