Comment by jeroenhd
2 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.
> 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/