Re: [MLS] Deniability without pairwise channels.

Hi Mathias,

For general context: Deniability is something that is being discussed right now and we should send some update to the list as soon as we have sorted things a bit better.

I hope I understood your correctly, you are essentially proposing a “sign & reveal” scheme. If not, I’m sorry, and please let me know.

What has become clearer in some of the discussion is that a “sign & reveal” scheme puts the burden of proof on the victim to some (large) extent. The attacker can publish a signature chain that starts with the public identity of the victim and ends with the signature of a specific message. This signature chain will most likely look valid to a third party at first sight. It then becomes the duty of the victim to prove that they indeed published secret keys and that therefore anyone could have signed the last part in the signature chain. For the victim, this is painful at best and impossible at worst. It would be much nicer if the attacker couldn’t publish such a signature chain in the first place.

There might be another problem, regarding synchronicity: since MLS is completely asynchronous no one should publish a secret key too early (i.e. before others have consumed the encrypted messages) otherwise we might not be able to trust the authentication any longer. 

But I fully agree that your proposal is obviously much more efficient than a 1:1 fanout.

Thanks

Raphael

> On 22 Jan 2020, at 15:34, Mathias Hall-Andersen <mathias@hall-andersen.dk> wrote:
> 
> Dear MLS group,
> 
> In MLS: since all group members share the same secret,
> the application of an AEAD does not provide authentication within the group,
> MLS mitigates this using sign-then-encrypt with a long-term signing key.
> 
>> [[ 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.]]
>> 
>> -- Section 12.2 Authentication
> 
> If deniability (without pairwise channels) is a desired feature in MLS,
> has the group discussed the feasibility of applying a "sign & reveal" type scheme?
> There are essentially two different options:
> 
> 1. Short-term credentials:
> 
> Clients would generate temporary "credentials" pk_{temp} for the group,
> by creating a certificate under their long term credential pk_{long term}:
> 
> S <- Sign(sk_{long term}, <Group Identifier, Expiry, pk_{temp}>)
> 
> Publish (S, pk_{temp}) to the group.
> 
> Then when sending messages apply sign-then-encrypt using the short-term credential:
> 
> S_{msg} <- Sign(sk_{term}, m)
> c <- Seal(k, .., .., <S_{msg}, m>)
> 
> Later, e.g. in lock-step with updates to the ratchet tree,
> the client publishes sk_{temp} to the group and generates a new short-term credential.
> 
> 
> 2. One-time credentials:
> 
> When sending messages apply sign-then-encrypt using a one-time credential:
> 
> S_{cert} <- Sign(sk_{long term}, <Group Identifier, Message Index, pk_{temp}>)
> S_{msg} <- Sign(sk_{term}, m)
> 
> Then encrypt:
> 
> c <- Seal(k, .., .., <S_{cert}, S_{msg}, sk_{old}, m>)
> 
> Where k is the group key and sk_{old} is the sk_{temp} from the previous message.
> 
> Best Regards,
> Mathias
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls