6 ms·

RFC 9420 a.k.a. Messaging Layer Security

205 points by jakobdabo 3y ago

goferito 3y ago
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?
- Zamicol 3y ago
  The section: How is MLS different from existing protocols? > Secure messaging protocols in use today were designed as one-to-one protocols [...] In contrast, MLS typically has costs of O(log n) for the same scenario, making it well-suited even for large groups.
- mananaysiempre 3y ago
  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/ https://matrix.org/blog/2023/07/a-giant-leap-with-mls/ [2] https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentralised2/decentralised.org https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentral...
  - Arathorn 3y ago
    Decentralisation-friendly MLS is working well already as a proof-of-concept in Matrix - check out the Implementation section of https://arewemlsyet.com https://arewemlsyet.com :)
  - wbl 3y ago
    You can have a global clock courtesy of the US space force.
    - mananaysiempre 3y ago
      The “clock” is in the distributed systems sense—a monotonically increasing integer on all participating machines, and the whole system is wrecked beyond repair if it ever decreases. Any resemblance to physical quantities is purely coincidental. (Equivalently, a supply of totally ordered gremlins with the ability to obtain a gremlin greater than any you’ve seen, and things blow up if any of them are ever actually incomparable.) It’s possible to build this atop a GNSS[1], but it’s quite expensive. [1] https://www.usenix.org/conference/osdi-06/chubby-lock-service-loosely-coupled-distributed-systems https://www.usenix.org/conference/osdi-06/chubby-lock-servic...
- woah 3y ago
  One big difference is that the authors of this protocol have probably spent a lot of time at IETF meetings
  - dopidopHN 3y ago
    You said that like it’s a bad thing?
    - eps 3y ago
      Depends on the group. For example, IKE was a protocol that passed by making everyone equally unhappy.
saurik 3y ago
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-architecture-10#name-non-repudiation-vs-deniabil 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-architecture-10#name-non-repudiation-vs-deniabil 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 https://github.com/mlswg/mls-architecture/issues/50
- jeroenhd 3y ago
  The last comment in the Github discussion you linked says: We decided to handle deniability in a separate document since it will be handled via an extension. I'm not sure what this extension looks like, but it looks like repudiation is not part of the MLS spec. I don't know how one is supposed to implement something like that through an extension, though; this sounds like it should either be a fundamental part of the protocol if it does get implemented.
  - lxgr 3y ago
    > this sounds like it should either be a fundamental part of the protocol if it does get implemented. You can do what the original OTR protocol did, i.e. "publish" previous authentication keys as soon as new ones superseding them are available. But that's conceptually less elegant than what e.g. Signal does (which is to never even have non-repudiable keys available through their triple DH handshake construction, if I understand it correctly): https://signal.org/blog/simplifying-otr-deniability/ https://signal.org/blog/simplifying-otr-deniability/
- 3y ago
jeroenhd 3y ago
Full standard: https://datatracker.ietf.org/doc/html/rfc9420 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/ https://datatracker.ietf.org/wg/mimi/about/) but this is a start.
- dopidopHN 3y ago
  Thanks. I would have give with the original link.
Klasiaster 3y ago
There are plans for using it in Matrix: https://arewemlsyet.com/ https://arewemlsyet.com/ (pointed out in https://news.ycombinator.com/item?id=36777573 https://news.ycombinator.com/item?id=36777573)
- mhoad 3y ago
  Same deal with Google Messages https://security.googleblog.com/2023/07/an-important-step-towards-secure-and.html https://security.googleblog.com/2023/07/an-important-step-to...
  - lxgr 3y ago
    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.
    - phh 3y ago
      Yeah no. Google Messages (almost) always go through Google services, not carriers. They are definitely their own platform.
      - inquirerGeneral 3y ago
        That's a vast oversimplification and is not really telling the whole story
    - cpach 3y ago
      Link in case anyone else is curious about RCS: https://en.wikipedia.org/wiki/Rich_Communication_Services https://en.wikipedia.org/wiki/Rich_Communication_Services
mananaysiempre 3y ago
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-101-mls-00 https://datatracker.ietf.org/meeting/101/materials/minutes-1...
- eps 3y ago
  Oh, the irony.
- wkrp 3y ago
  That's something ghost.org does by default. I unknowingly ran into the same issue for my blog.
  - dalanmiller 3y ago
    How does one turn this off?
    - cityroler 3y ago
      ghost Settings > Analytics > Outbound link tagging
- deleted 3y ago
  [deleted]
- raphaelrobert 3y ago
  Thank you for bringing this up! It appears ghost has this turned on by default, and I turned it off now. Sorry for any inconvenience. For context, we had an internal debate whether we should host the blog ourselves, but ultimately decided to use ghost. It ticked a few boxes, being open-source and run by a non-profit. The fact that it would do outbound link tagging by default really comes as a surprise, so thanks again for bringing it up.
upofadown 3y ago
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.
simonpure 3y ago
This proposal depends on a central server and there is an alternative decentralized proposal - https://eprint.iacr.org/2020/1281 https://eprint.iacr.org/2020/1281
dmw_ng 3y ago
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
- ezst 3y ago
  If Signal wanted to lead by example on the privacy front, they would have stuck with their initially federated design, wouldn't require phone numbers, and wouldn't (have to) hide behind obscure and unverifiable workarounds (SGX enclaves, sealed senders, ...)
  - palata 3y ago
    How is the sealed sender feature obscure and unverifiable?

205 points by jakobdabo 3y ago

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?

Zamicol 3y ago
The section: How is MLS different from existing protocols? > Secure messaging protocols in use today were designed as one-to-one protocols [...] In contrast, MLS typically has costs of O(log n) for the same scenario, making it well-suited even for large groups.
mananaysiempre 3y ago
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/ https://matrix.org/blog/2023/07/a-giant-leap-with-mls/ [2] https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentralised2/decentralised.org https://gitlab.matrix.org/matrix-org/mls-ts/-/blob/decentral...
- Arathorn 3y ago
  Decentralisation-friendly MLS is working well already as a proof-of-concept in Matrix - check out the Implementation section of https://arewemlsyet.com https://arewemlsyet.com :)
- wbl 3y ago
  You can have a global clock courtesy of the US space force.
  - mananaysiempre 3y ago
    The “clock” is in the distributed systems sense—a monotonically increasing integer on all participating machines, and the whole system is wrecked beyond repair if it ever decreases. Any resemblance to physical quantities is purely coincidental. (Equivalently, a supply of totally ordered gremlins with the ability to obtain a gremlin greater than any you’ve seen, and things blow up if any of them are ever actually incomparable.) It’s possible to build this atop a GNSS[1], but it’s quite expensive. [1] https://www.usenix.org/conference/osdi-06/chubby-lock-service-loosely-coupled-distributed-systems https://www.usenix.org/conference/osdi-06/chubby-lock-servic...
woah 3y ago
One big difference is that the authors of this protocol have probably spent a lot of time at IETF meetings
- dopidopHN 3y ago
  You said that like it’s a bad thing?
  - eps 3y ago
    Depends on the group. For example, IKE was a protocol that passed by making everyone equally unhappy.

saurik 3y ago

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-architecture-10#name-non-repudiation-vs-deniabil 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-architecture-10#name-non-repudiation-vs-deniabil 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 https://github.com/mlswg/mls-architecture/issues/50

jeroenhd 3y ago
The last comment in the Github discussion you linked says: We decided to handle deniability in a separate document since it will be handled via an extension. I'm not sure what this extension looks like, but it looks like repudiation is not part of the MLS spec. I don't know how one is supposed to implement something like that through an extension, though; this sounds like it should either be a fundamental part of the protocol if it does get implemented.
- lxgr 3y ago
  > this sounds like it should either be a fundamental part of the protocol if it does get implemented. You can do what the original OTR protocol did, i.e. "publish" previous authentication keys as soon as new ones superseding them are available. But that's conceptually less elegant than what e.g. Signal does (which is to never even have non-repudiable keys available through their triple DH handshake construction, if I understand it correctly): https://signal.org/blog/simplifying-otr-deniability/ https://signal.org/blog/simplifying-otr-deniability/
3y ago

jeroenhd 3y ago

Full standard: https://datatracker.ietf.org/doc/html/rfc9420 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/ https://datatracker.ietf.org/wg/mimi/about/) but this is a start.

dopidopHN 3y ago
Thanks. I would have give with the original link.

Klasiaster 3y ago

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

mhoad 3y ago
Same deal with Google Messages https://security.googleblog.com/2023/07/an-important-step-towards-secure-and.html https://security.googleblog.com/2023/07/an-important-step-to...
- lxgr 3y ago
  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.
  - phh 3y ago
    Yeah no. Google Messages (almost) always go through Google services, not carriers. They are definitely their own platform.
    - inquirerGeneral 3y ago
      That's a vast oversimplification and is not really telling the whole story
  - cpach 3y ago
    Link in case anyone else is curious about RCS: https://en.wikipedia.org/wiki/Rich_Communication_Services https://en.wikipedia.org/wiki/Rich_Communication_Services

mananaysiempre 3y ago

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-101-mls-00 https://datatracker.ietf.org/meeting/101/materials/minutes-1...

eps 3y ago
Oh, the irony.
wkrp 3y ago
That's something ghost.org does by default. I unknowingly ran into the same issue for my blog.
- dalanmiller 3y ago
  How does one turn this off?
  - cityroler 3y ago
    ghost Settings > Analytics > Outbound link tagging
deleted 3y ago
[deleted]
raphaelrobert 3y ago
Thank you for bringing this up! It appears ghost has this turned on by default, and I turned it off now. Sorry for any inconvenience. For context, we had an internal debate whether we should host the blog ourselves, but ultimately decided to use ghost. It ticked a few boxes, being open-source and run by a non-profit. The fact that it would do outbound link tagging by default really comes as a surprise, so thanks again for bringing it up.

upofadown 3y ago

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.

simonpure 3y ago

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

dmw_ng 3y ago

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

ezst 3y ago
If Signal wanted to lead by example on the privacy front, they would have stuck with their initially federated design, wouldn't require phone numbers, and wouldn't (have to) hide behind obscure and unverifiable workarounds (SGX enclaves, sealed senders, ...)
- palata 3y ago
  How is the sealed sender feature obscure and unverifiable?