Re: [MLS] Improving entropy in MLS

*ouch, sorry about all the spelling mistakes… :D

> On 30 Mar 2021, at 09:53, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
> 
> Hi all,
> 
> I like this idea. I am not fully clear about the threat model, though.
> 
> From reading this, it looks like we assume that the adversary that compromised a 
> principal doesn’t have complete control the entropy pool.
> 
> This is in contrast over what we assume of the AEAD keys or even the KEM keys
> where a full state compromise will gain access to the values.
> 
> However it looks very close to the assumptions about additional protections for signing keys.
> E.g., not directly accessible, and behind an interface that an adversary can query for certain operations
> through an API (e.g. when is stored in an HSM, co-processor or a functional secure enclave).
> 
> Am I reading this properly?
> If yes, I can understand the value in this threat model, but we should make it clear that the
> entropy pool has to get these additional protections to provide these good properties.
> 
> Seems to me like a good improvement in all cases anyway, so I think we should consider it.
> 
> Thanks!
> Ben
> 
>> On 30 Mar 2021, at 09:27, Konrad Kohbrok <konrad.kohbrok@datashrine.de> wrote:
>> 
>> Hi everyone,
>> 
>> MLS is a protocol that is very vulnerable to individual parties with bad randomness. For example, when a party joins a group, the secrecy of the group's key material relies on the quality of that party's key material. Similarly, when doing an external join, the groups entropy is completely replaced by that of the joining member.
>> 
>> There are multiple ways to mitigate this threat and Joël and Sandro proposed a few of them in the following mail to the list: https://mailarchive.ietf.org/arch/msg/mls/ZR84smU5xeLrziNTk5W1P1Z1nQI/
>> 
>> Concretely, there were two approaches: one that would be baked into the protocol (essentially using a secret derived from old path secrets to inject into new ones in addition to the current approach) and one that would mandate the use of an entropy pool.
>> 
>> The ideas were discussed a bit at the time, but nothing has happened since then. Joël, Sandro and I have just opened a PR with a concrete design for an entropy pool that is modeled after the key schedule (https://github.com/mlswg/mls-protocol/pull/467). Concretely, it allows gathering entropy over time and for parties with a bad entropy source to profit from parties with a good one without compromising security.
>> 
>> While for future iterations of MLS, we might want to consider a solution that is more integral to the protocol, we are aware that the authors want to avoid breaking changes at this point. With the entropy pool, we thus propose a solution that does not affect the protocol flow, but that still offers significant advantages over no mitigations at all.
>> 
>> Cheers,
>> Konrad
>> 
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>