Re: [MLS] hardening MLS against bad randomness

[Joel Alwen <[e-mail]>]

Hey Konrad!

On 22/04/2020 21:24, Konrad Kohbrok wrote:
> One way to keep it transparent for the receiver (if that is indeed what we want)
> would be for the updating party to include the previous epoch's path_secret[0]
> when creating a fresh path_secret[0] and then KDF'ing up the tree as before. In
> other words, follow your MLS specific suggestion, but only for the leaf secrets.
> Since that is (I think?) the only place new randomness comes into the tree
> anyway, it would have about the same effect, wouldn't it? Also, it would be a
> minor change to the protocol and the receiver wouldn't even notice if the sender
> did it (for better or worse).

I like that this is less invasive in terms of changes. (Though IMO its actually
a Pro not a Con that functionality breaks when you don't implement any given
defense correctly, including those against bad randomness.)

One nit: better to derive something off of the old path_secret[0] and use that
rather than use path_secret[0] directly. Don't want to keep path_secret[0]
around after a commit (bad for FS of TreeKEM / PCFS of MLS).

I do think that using only path_secret[0] defends a bit less though. E.g. say
Alice & Bob are siblings (and everything is delivered & process immediately).
Here's an execution.

1) Alice commits.
2) Leak Alice's state to adversary.
3) Bob commits.
4) Alice commits with bad randomness.

Mixing in only something from path_secret[0] means all keys in commit (4) are
now bad. But mixing in something from old path_secret[n] for new pub/priv key n
means all but her leaf are now good keys.

- Joël