RFC 9420 a.k.a. Messaging Layer Security (opens in new tab)

Thanks. I would have give with the original link.

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.

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

Oh, the irony.

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

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.

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.

Same deal with Google Messages

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

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

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

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.

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