[saurik]

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

[raphaelrobert]

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

[Arathorn]

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.

[jeroenhd]

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]

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