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.
RFC 9420 a.k.a. Messaging Layer Security
11–20 of 35 posts
Re: RFC 9420 a.k.a. Messaging Layer Security
#12Earlier 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.
Re: RFC 9420 a.k.a. Messaging Layer Security
#13What 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 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[1] https://datatracker.ietf.org/meeting/101/materials/minutes-1...
Re: RFC 9420 a.k.a. Messaging Layer Security
#15What 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…
Re: RFC 9420 a.k.a. Messaging Layer Security
#16Does 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…
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
#17Identity 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
#18Re: RFC 9420 a.k.a. Messaging Layer Security
#19At 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...
Re: RFC 9420 a.k.a. Messaging Layer Security
#20What 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?