from Hacker News

RFC 9420 a.k.a. Messaging Layer Security

by jakobdabo on 7/21/23, 4:19 PM with 33 comments

• by jeroenhd on 7/21/23, 5:41 PM

  Full standard: https://datatracker.ietf.org/doc/html/rfc9420

  With the EU's DMA requirements coming up, this is a major candidate for a standard protocol for messenger interoperability. There's no legal requirement to support it, but implementing an existing standard that supports end-to-end encryption seems like a much cheaper and safer method than building your own.

  Of course actual interoperability will depend on MIMI (https://datatracker.ietf.org/wg/mimi/about/) but this is a start.

• by mananaysiempre on 7/21/23, 7:31 PM

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

• by saurik on 7/21/23, 5:40 PM

  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 arguments with Ian Goldberg, the developer of Off-the-Record messaging.

  https://datatracker.ietf.org/doc/html/draft-ietf-mls-archite...

  The arguments on the bug tracker about power imbalances were maybe a bit better, but I still personally believe this to be an important property (and one which clients need to fully embrace, allowing the ability to edit any part of the message history so easily anyone could figure out how to do it).

  https://github.com/mlswg/mls-architecture/issues/50

• by Klasiaster on 7/21/23, 5:41 PM

  There are plans for using it in Matrix: https://arewemlsyet.com/ (pointed out in https://news.ycombinator.com/item?id=36777573)

• by dmw_ng on 7/22/23, 9:57 AM

  I was recently shocked to discover media attachments sent on Signal are uploaded to either Google Cloud Storage or some other service sitting behind CloudFlare. The recipient device(s) fetch the uploaded keys to access the images. The net effect is that there is almost certainly a log file somewhere that correlates the IP addresses/user agents of conversation participants for a very large subset of all Signal users

  The point is mostly there are plenty of security issues with existing systems that probably aren't easily fixed with another layer of crypto woowoo, and it makes me uncomfortable that crypto is used to justify marketing these systems as secure. How do you explain to a user that the JPEG compression implementation on their particular phone with their particular photograph has a unique on-the-wire transfer size that may already be enough to correlate them with their recipient? etc

• by upofadown on 7/21/23, 8:37 PM

  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.

• by simonpure on 7/21/23, 8:45 PM

  This proposal depends on a central server and there is an alternative decentralized proposal - https://eprint.iacr.org/2020/1281

• by goferito on 7/21/23, 6:39 PM

  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?