[MLS] Deniability as external to the MLS protocol

[Richard Barnes <[e-mail]>]

Hey all,

Some recent and soon-to-be-proposed changes involving signatures over the
group's ratchet tree have raised concerns about the deniability of the
protocol.  I'd like to propose that we can safely punt deniability to a
different layer, and not worry about it in the core protocol.

The basic idea here is that signing keys only need to be denied to the
degree they are associated with an identity, so if the Authentication
Service is deniable, all artifacts generated by MLS are as well.

For example, supposed an application were set up in the following way:

* Signature keys are only used with a single group (thus so are KeyPackages)
* MLS credentials have no meaningful identity data (e.g., BasicCredential
with identity=H(public_key))
* Group members authenticate one another by exchanging signature public
keys over a 1:1 deniable channel (e.g., X3DH)

(Here we have instantiated a distributed, deniable Authentication Service
as a full mesh of 1:1 deniable channels.)  In this setup, as far as an
external observer knows, the whole group could have been generated by a
single participant, which seems like a not-bad definition of deniablity.
The MLS messages could be generated by anyone holding the relevant
signature private keys, and the deniable signature key distribution means
that anyone in the group could be the holder of those private keys.

This model is still compatible with things like pre-publishing KeyPackages
for asynchronous add.  You could obviously do an "add first, authenticate
when the joiner comes online" scheme.  You might also be able to do
something more proactive by pre-publishing some deniable data along with
the KeyPackage.

My goal here is to argue that there is at least one way of operating MLS in
a deniable mode, pretty much regardless of what the protocol itself does.
If this argument seems plausible to folks, it should then be safe to make
some changes that had been gated on deniability concerns:

* Updating #406 so that the GroupPublicState is signed by the member that
issues it
* Updating the path hash / parent hash scheme as recommended in Joël's
forthcoming proposal (and which I expect will look like what Benjamin and
Karthik suggested back in January)

I would also be open to adding something like the above discussion to the
architecture document, if people thought it would be useful for posterity.

Best,
--Richard