Re: [MLS] Deniability as external to the MLS protocol

For deniable signatures I'd like to suggest taking a look at KeyForge (not
sure if it's ideal for MLS, see caveats below).

http://www.mit.edu/~specter/blog/2020/dkim/

KeyForge was designed to make DKIM email header signatures deniable. It
uses a long term root key (good for usability and key management), and
derives a sequence of subkeys to be used for a certain period of time
(using signature context / tags) and then disclosed after use without
compromising the root key. Quote;

> At any given time, KeyForge can remain succinct because it generates a
neat tree of public/private keypairs where exposing a node’s private key
also results in also exposing that node’s children’s keys, but not it’s
parents. If you then tag each layer of the tree as a
Master/Year/Month/Day/15-minute “chunk”, you get something like this:
> KeyForge is a tree of keys, where revealing a node's private key will
also reveal all of it's childrens' private keys, but not its parents' keys.

> So, for this KeyForge layout, one can reveal the private key for, say,
December 2020, and it’ll result in all signatures generated from that
entire month being forgable.

Note that the simple way of doing this, adding in the MLS group context as
a tag, will make message contents deniable but leave proof of
participation. This has a security model very similar to the original OTR's
key disclosure mechanism.

Another way of doing this is by using the user's long term keypair with the
purely time based scheme to sign a group context specific message signing
keypair. This only proves the sender's identity to those who receives the
signature before the key is disclosed, so users who return after having
been offline for a while will need to request re-signing by those users
whose signatures they did not see in time.

Also keep in mind that for all variants of this which use time based tags,
your signature can be proven to be valid to non-participants within its
validity period.

If you want to guarantee that deniable context based signatures are always
fully deniable to non-participants, thus making both message contents and
participation deniable, then you need a method to derive a
per-user-and-group context for the signature where the signature context
tag itself can only be validated by participants but not by
non-participants.

Perhaps this can be done by using some kind of secure coin flip scheme
among participants and mixing it with the MLS group context. But I'm not
completely sure if this can be done securely, further research is likely
needed.

Den fre 13 nov. 2020 16:02Sofía Celi <cherenkov@riseup.net> skrev:

> Dear all,
>
> As you know, we had many discussions on deniability and solving this
> problem is not an easy task, as evidence of this thread. To make sure we
> can work on this optional feature in the future, without modifying the
> core protocol, we believe that there are no changes needed to be added
> to the core protocol. Some minor relaxing of the phrasing in the
> document might be useful, though, and might help for future features as
> well, so I have submitted PR #437
> (https://github.com/mlswg/mls-protocol/pull/437). This rephrasing should
> allow deniability of application messages by allowing the usage of
> deniable signature keys. Please, let us know of any comments regarding it.
>
> Thank you,
>
>
> --
> Sofía Celi
> @claucece
> http://claucece.github.io/
> Cryptographic research and implementation at many places, but mainly at
> Cloudflare
> FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>