[MLS] Improving entropy in MLS

Konrad Kohbrok <konrad.kohbrok@datashrine.de> Tue, 30 March 2021 07:27 UTC

Return-Path: <konrad.kohbrok@datashrine.de>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1103A14CF for <mls@ietfa.amsl.com>; Tue, 30 Mar 2021 00:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqCHOxZMkM_o for <mls@ietfa.amsl.com>; Tue, 30 Mar 2021 00:27:45 -0700 (PDT)
Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6447E3A1417 for <mls@ietf.org>; Tue, 30 Mar 2021 00:27:44 -0700 (PDT)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4F8gyK6HhlzQjmc for <mls@ietf.org>; Tue, 30 Mar 2021 09:27:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id BWzticxgs5rH for <mls@ietf.org>; Tue, 30 Mar 2021 09:27:31 +0200 (CEST)
Date: Tue, 30 Mar 2021 09:27:31 +0200 (CEST)
From: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
To: "mls@ietf.org" <mls@ietf.org>
Message-ID: <1529628012.30519.1617089251424@office.mailbox.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Normal
X-MBO-SPAM-Probability:
X-Rspamd-Score: -0.65 / 15.00 / 15.00
X-Rspamd-Queue-Id: 97AFE1846
X-Rspamd-UID: 2a2fc3
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/WedE9-3Oak4PCMke3kqxNdAn98o>
Subject: [MLS] Improving entropy in MLS
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 07:27:50 -0000

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