Re: [MLS] hardening MLS against bad randomness

[Joel Alwen <[e-mail]>]

Roughly speaking, I'd say the goal is to protect honest group members from
members unintentionally using bad randomness (i.e. randomness with low entropy
for the adversary) but who otherwise follow the protocol. This includes the
sender using bad randomness and the receivers. Of course, there are limits to
what can be achieved but that's the ideal. In practical terms, this can well be
caused by poor configurations, overly deterministic boot processes or straight
up buggy logic rather than actual explicit attacks by an adversary.

So put differently, the idea is to reduce what an attacker with information (or
influence over) randomness can achieve in terms of breaking privacy,
authenticity and whatever other security goals we have for MLS.

>  However, if receiver would not notice if the sender took the correct steps,
then they do not have any guarantee

Yup, some solutions have that property (e.g. the "entropy pool" approach and
Konrad's proposal). Others are more tightly connected to correctness like the
"mixing in old keys" approach. (Personally I favor the latter. I like things
noticeably breaking when security precautions aren't being taken.)

> So is the goal to protect the sender from their own bad randomness, or to
protect an unaware receiver, in the event that the sender actually behaves
correctly? There can still be a gain from such a change, but it seems to be a
far weaker guarantee if there is no awareness at the receiver.

What do you mean by far weaker? From what I can tell whats lost when receivers
can (in fact, are forced to) verify that defenses are being applied is that it
becomes harder to implement the protocol poorly. Is that what you mean? Or is
there more?

> We also need to be careful in the differentiation of leaking state to the
adversary, which may well reveal the entire current state, and a bad random
generator.

I agree. Both are interesting and different attacks / failure modes. (In Sandro,
Yiannis and my work on security analysis of MLS we're treating these as two
different types of corruption modes available to the adversary.)

- Joël


On 22/04/2020 23:58, Hale, Britta (CIV) wrote:
> I am trying to understand the threat model we are working with on this. When trying to protect against bad randomness, the goal would seem to be to protect a receiver against potentially bad randomness from the sender. However, if receiver would not notice if the sender took the correct steps, then they do not have any guarantee - in fact, a sender could just incorrectly implement this without breaking functionality and no one would be the wiser that the bad-randomness protection has been lost (if I understand the proposal correctly).
> 
> So is the goal to protect the sender from their own bad randomness, or to protect an unaware receiver, in the event that the sender actually behaves correctly? There can still be a gain from such a change, but it seems to be a far weaker guarantee if there is no awareness at the receiver. 
> 
> We also need to be careful in the differentiation of leaking state to the adversary, which may well reveal the entire current state, and a bad random generator.
> 
> -- Britta
> 
> 
> On 4/22/20, 5:48 AM, "MLS on behalf of Joel Alwen" <[e-mail] on behalf of [e-mail]> wrote:
> 
>     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
>     
>     _______________________________________________
>     MLS mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/mls
>     
>