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

From: Sofía Celi <[email-masked]>
Date: Fri, 13 Nov 2020 15:01:38 +0000

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

---

From: Raphael Robert <[email-masked]>
Date: Fri, 13 Nov 2020 16:26:05 +0100

Thanks Sofia!

I think this is exactly what we need to achieve optional deniability for message authorship without touching the authentication guarantees of the the core protocol.

Raphael

> On 13 Nov 2020, at 16:01, Sofía Celi <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Benjamin Beurdouche <[email-masked]>
Date: Fri, 13 Nov 2020 16:41:00 +0100

I am supportive of that change as well.
B.

> On Nov 13, 2020, at 4:27 PM, Raphael Robert <raphael=[email-masked]> wrote:
> 
> Thanks Sofia!
>

---

From: Natanael <[email-masked]>
Date: Fri, 13 Nov 2020 17:27:33 +0100

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.