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

[Chelsea Komlo <[e-mail]>]

Hi Richard,

This approach of per-conversation non-attributable signing keys ensures
"conversation/participation unlinkability", which implies deniability.

This is certainly a viable option for implementations at a level above MLS,
with the caveat that it has sharp edges as nothing in MLS forces signing
keys to be used for exactly one group. Further, ensuring both async
conversations and single-use-keys may be tricky.

It would be great for future versions of MLS to think about how to move
deniability within the protocol itself, but most importantly I think it is
best to keep the core protocol simple to understand and implement. Allowing
deniability protections to be implemented at a layer above MLS seems like a
good compromise towards finalizing the first version of the protocol.

Best,
Chelsea

On Thu, Oct 22, 2020 at 11:50 AM Richard Barnes <[e-mail]> wrote:

> 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
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>