Re: [MLS] Include signature in the confirmed transcript hash?

[Natanael <[e-mail]>]

Den tors 17 sep. 2020 19:43Marta Mularczyk <[e-mail]> skrev:

> Hi all,
>
> Together with Joël Alwen and Daniel Jost, we noticed some unexpected (at
> least to us) effects of the way transcript hash is computed. What are your
> thoughts on this?
>
> Details: Say Alice and Bob each processes a commit packet and they end up
> with the same epoch secrets. Expected guarantee: agreement on the secrets
> implies being in sync -- agreement on the group state, and being able to
> continue progressing epochs.
>
> Problem: the latter is false if the packets processed by Alice and Bob
> only differ in the signature string (it's easy to come up with many
> equivalent ECDSA signatures, given only the signer's public key). Now Alice
> and Bob agree on the confirmed_transcript_hash, and hence on the current
> secrets, but not on the interim_transcript_hash, so they won't agree on the
> next epoch secrets. Result: they will never accept the same commit (due to
> not matching confirmation_tag) and so they'll never be in sync in the next
> epoch.
>
> This can be solved by including the signature in the
> confirmed_transcript_hash and not signing the confirmation_tag (the tag is
> also not part of the transcript_hash). We claim that this doesn't affect
> security. Assume Alice sends a commit and the adversary intercepts the
> packet. Consider these 3 cases:
>
I'd like to note that another option to changing what's hashed is to use an
algorithm designed to guarantee determinism with no malleability, like
Verifiable Random Functions (VRF).

There's currently an ongoing standardization process for VRF:s (one type
based on RSA, one based on ECC), see below;

https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vrf-07

>