Live data from Hacker News

RFC 9420 a.k.a. Messaging Layer Security

blog.phnx.im

11–20 of 35 posts

Re: RFC 9420 a.k.a. Messaging Layer Security

#11
post #8
post #6

Earlier quoted context omitted.

Same deal with Google Messages https://security.googleblog.com/2023/07/an-important-step-to...

I wonder how Google would actually implement that, given that "Google Messages", as far as I can tell, isn't really a "platform" (as stated in the linked article) but rather a client for RCS, which needs mobile operator support to work on Android, and to my knowledge does not work at all on iOS.

Link in case anyone else is curious about RCS: https://en.wikipedia.org/wiki/Rich_Communication_Services

Re: RFC 9420 a.k.a. Messaging Layer Security

#12
post #8
post #6

Earlier quoted context omitted.

Same deal with Google Messages https://security.googleblog.com/2023/07/an-important-step-to...

I wonder how Google would actually implement that, given that "Google Messages", as far as I can tell, isn't really a "platform" (as stated in the linked article) but rather a client for RCS, which needs mobile operator support to work on Android, and to my knowledge does not work at all on iOS.

Yeah no. Google Messages (almost) always go through Google services, not carriers. They are definitely their own platform.

Re: RFC 9420 a.k.a. Messaging Layer Security

#13
post #9

What is the difference with the Matrix protocol? Matrix is already open-source, there are libraries publicly available that implement it, both for clients and serves, in different languages. Why not just adopting it?

The Matrix spec defines everything about how communication should happen—port discovery, federation, transport, wire formats, encodings, schemas, addresses for people, group membership, reconciliation of parallel histories, ..., and, yes, end-to-end cryptography. MLS is just the end-to-end cryptography part, how to turn it into bits, and a general idea of where the underlying network should deliver those bits. Nothing about how the delivery is accomplished or how to format the user data that’s protected by the cryptography.

The corresponding part of Matrix is called Olm (for two-party conversations) and Megolm (for groups). Why (a Matrix mapping of) MLS and not those then? The Matrix people, who did have a hand in MLS, say[1] it performs better than Megolm, and IIRC Megolm is indeed something of a hack on top of plain Olm, because E2EE on Matrix has been built up gradually starting from the simpler two-party case. Unfortunately, it looks like MLS as specified is insufficient for Matrix, because it relies on a global clock—which you can’t get in a partition-tolerant federation—but they think that should eventually be solvable[2].

[1] https://matrix.org/blog/2023/07/a-giant-leap-with-mls/

[2] https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentral...

Re: RFC 9420 a.k.a. Messaging Layer Security

#14
At the risk of falling afoul of the site guidelines, can I complain about an uncommon annoyance? Apparently this blog pulls a Facebook, or more precisely a fbclid, and adds ref=blog.phnx.im as a query parameter to every link. This seems less than fitting for a post on a privacy technology, and actually breaks the link to the IETF BoF minutes[1].

[1] https://datatracker.ietf.org/meeting/101/materials/minutes-1...

Re: RFC 9420 a.k.a. Messaging Layer Security

#15
post #9

What is the difference with the Matrix protocol? Matrix is already open-source, there are libraries publicly available that implement it, both for clients and serves, in different languages. Why not just adopting it?

The Matrix spec defines everything about how communication should happen—port discovery, federation, transport, wire formats, encodings, schemas, addresses for people, group membership, reconciliation of parallel histories, ..., and, yes, end-to-end cryptography. MLS is just the end-to-end cryptography part, how to turn it into bits, and a general idea of where the underlying network should deliver those bits. Nothin…

Decentralisation-friendly MLS is working well already as a proof-of-concept in Matrix - check out the Implementation section of https://arewemlsyet.com :)

Re: RFC 9420 a.k.a. Messaging Layer Security

#16
post #2

Does anyone know the status with respect to support for deniability / repudiation? I can't tell where they landed, and they seem to have deleted the paragraph from prior drafts that mostly left me more confused. https://datatracker.ietf.org/doc/html/draft-ietf-mls-archite... Previously, their designs had explicitly lacked this feature, and they said they actively didn't want it, citing "terrorism", resulting in argum…

afaik MLS doesn't currently support deniability. This means you can have attack where a member of the group conversation can prove in retrospect that an encrypted message was sent by a given sender. This is a big deal if you want to be able to talk freely without being blackmailed - for instance, I might want to say something to a given user intended only for their eyes, and if they then take that info and show it to other people (e.g. to blackmail me), I want to be able to claim that they faked the screenshot or otherwise fabricated the message. I certainly don't want some sort of signature on the message undeniably tying it back to me.

Now, Double Ratchet (and Olm and Megolm in Matrix) provide cryptographic deniability by using MACs rather than signatures for integrity, meaning that any given message could have been faked by the other participant in the conversation (given they know the secret that would allow them to encrypt that message themselves).

However, it's worth noting that practically speaking, a malicious server admin could turn up with some snapshots of their DB or some server logs with the ciphertext in them and say "i can prove that that screenshot's not faked, because my server saw that encrypted message sent from that user". And so if the admin was trusted (i.e. not colluding with the blackmailer), that could be seen as sufficient evidence to break deniability, albeit not at a cryptographic level.

So, basically: deniability is subtle - it's not obvious that cryptographic deniability is always a big win, given one can often find non-cryptographic ways to sufficiently prove that a user sent a message. That said, if you don't have cryptographic deniability, then you can be sure that a malicious conversation participant equipped with a suitable client which has forensics mode enabled will be able to produce evidence that cryptographically proves that you indeed said a given sensitive statement, whether you like it or not.

Re: RFC 9420 a.k.a. Messaging Layer Security

#17
The killer feature here is efficient handling of very large groups. That's great but that isn't the main issue with this sort of thing.

Identity in end to end encrypted group messaging is hard to do. This seems to leave the difficult identity issue to future work. How do we know that we are due to have a breakthrough in the near future?

Even if they do come up with something usable in a technical sense, there is no way you are going to know who all the participants are in a large group. The problem is to some extent inherently unsolvable.

Interoperable 1 to 1 end to end encryption might be a better first try.

Re: RFC 9420 a.k.a. Messaging Layer Security

#19

At the risk of falling afoul of the site guidelines, can I complain about an un common annoyance? Apparently this blog pulls a Facebook, or more precisely a fbclid, and adds ref=blog.phnx.im as a query parameter to every link. This seems less than fitting for a post on a privacy technology, and actually breaks the link to the IETF BoF minutes[1]. [1] https://datatracker.ietf.org/meeting/101/materials/minutes-1...

Oh, the irony.

Re: RFC 9420 a.k.a. Messaging Layer Security

#20
post #9

What is the difference with the Matrix protocol? Matrix is already open-source, there are libraries publicly available that implement it, both for clients and serves, in different languages. Why not just adopting it?

One big difference is that the authors of this protocol have probably spent a lot of time at IETF meetings
Post reply on HN