RFC 9420 a.k.a. Messaging Layer Security

https://blog.phnx.im/rfc-9420-mls/

by jakobdabo • 3 years ago

205 33 3 years ago

blog.phnx.im

saurik• 3 years 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-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

jeroenhd2• 3 years 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.

lxgr2• 3 years 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/

Arathorn2• 3 years ago

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.

raphaelrobert2• 3 years ago

MLS and blog author here. I've been a proponent of deniability within the MLS WG and there have been quite a few online and offline discussion about it. Personal opinions aside, deniability remains a divisive property. Some people think it is important, many people do not care about it, and a few even think it is harmful. That sets it apart from properties like say confidentiality that is far more appealing to most people. It also remains largely theoretical, in that the lack of deniability hasn't had tangible negative consequences so far (the DKIM case aside, but that doesn't translate 1:1 to messaging). Deniability is also used as a colloquial term, when there is much more nuance to it (what exactly is deniable? what capabilities does the attacker have? etc.). Finally, deniability in protocols like Signal clearly have limitations and can be circumvented with moderate effort as explained in [1]. So the reason why deniability didn't make it into core MLS is rather banal: there was not enough traction.

That being said, there has been a low key effort to come up with an extension to MLS to introduce some notion of deniability. It is not published yet, but I will probably talk more about it at the upcoming MLS session at IETF117.

[1] https://asokan.org/asokan/research/deniability.pdf

Klasiaster• 3 years ago

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

mhoad• 3 years ago

Same deal with Google Messages

https://security.googleblog.com/2023/07/an-important-step-to...

lxgr2• 3 years 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.

jeroenhd2• 3 years ago

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.

dopidopHN2• 3 years ago

Thanks. I would have give with the original link.

goferito• 3 years 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• 3 years 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.

mananaysiempre3• 3 years 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/

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

Arathorn2• 3 years ago

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

wbl• 3 years ago

You can have a global clock courtesy of the US space force.

woah• 3 years ago

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

dopidopHN2• 3 years ago

You said that like it’s a bad thing?

mananaysiempre3• 3 years 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-1...

eps2• 3 years ago

Oh, the irony.

wkrp• 3 years ago

That's something ghost.org does by default. I unknowingly ran into the same issue for my blog.

dalanmiller• 3 years ago

How does one turn this off?

raphaelrobert2• 3 years 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• 3 years 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• 3 years ago

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

dmw_ng• 3 years 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• 3 years 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• 3 years ago

How is the sealed sender feature obscure and unverifiable?

RFC 9420 a.k.a. Messaging Layer Security

Related Stories