Re: [MLS] Short review of MLS drafts from the OTRv4 group

[Raphael Robert <[e-mail]>]

Hi Sofia,

Thanks for the review!
I’ll focus on your questions regarding deniability for now. 

> We are unsure if there is a will of including deniability in this. On some
> points it states:
> 
> """
> [[ OPEN ISSUE: Signatures under the identity keys, while simple, have
>   the side-effect of preclude deniability.  We may wish to allow other
>   options, such as (ii) a key chained off of the identity key, or (iii)
>   some other key obtained through a different manner, such as a
>   pairwise channel that provides deniability for the message
>   contents.]]
> """
> 
> """
> Non-Repudiation and Deniability
> As described in {{client-compromise}}, MLS provides data origin authentication
> within a group, such that one group member cannot send a message that appears to
> be from another group member. Additionally, some services require that a
> recipient be able to prove to the messaging service that a message was sent by
> a given Client, in order to report abuse. MLS supports both of these use cases.
> In some deployments, these services are provided by mechanisms which allow the
> receiver to prove a message's origin to a third party (this if often called
> "non-repudiation"), but it should also be possible to operate MLS in a "deniable"
> mode where such proof is not possible. [[OPEN ISSUE: Exactly how to supply this
> is still a protocol question.]]
> """
> 
> If this is something that wants to be included, we will be very happy to answer
> questions. Nevertheless, there is no way, currently, to achieve the same deniability
> properties OTRv4 has in a group setting.
> 
> We are also unsure of the difference between deniability and non-repudation.


The will is definitely there to allow deniability in MLS. However since that property is quite divisive, the current status quo is that it should be optional.
In practical terms, *some* deniability could be achieved by distributing the message signing keys through a deniable channel (similar to how the sender keys concept works). In a way this puts deniability “out of scope” in the sense that the distribution of signing keys is not in the charter. To my knowledge, there is no other substantial proposal on how deniability could be achieved, but it would be great to hear more from you on that subject!

Raphael