From nobody Sun Apr 4 01:11:41 2021 Return-Path: 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 6655C3A1C51 for ; Sun, 4 Apr 2021 01:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.216 X-Spam-Level: * X-Spam-Status: No, score=1.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=npAVvt0s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RluQzWPd 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 JaGABetnpVdI for ; Sun, 4 Apr 2021 01:11:29 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82E13A1C4E for ; Sun, 4 Apr 2021 01:11:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 877045C005A for ; Sun, 4 Apr 2021 03:43:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 04 Apr 2021 03:43:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=ESjf0bW7UknXQtuNCHydLlem3XlvAA6f+eqxN+fVIF4=; b=npAVvt0s 9EceCFU0oOzxsfRacq4Oug9/1ALlNK5Dcwuw2I534BHPdGC9oTYHVSCDX7Htvd5s 03wIZ1w5b5VolQkLiGpLzOioFLVGNywZm8JXdHMJS2IIO3CYY0450C4q8080KWY6 062WJfnHiFqjov1wrse06Co6BS1d+g+aKHQmFmJd2boBeVuHno/o+FHmqJgI0HFf CfllZHAN9AdaY0VHwKKF16mVN197YKWqwtv9bwrjWg9rR+K/E7QgbONfhJkEdH/u ppC+CekrXH0B43WrY/ExRNGYDFCYw9G15Uoi1Hg3uhRg/Sz3osc3t6bkeCt4Nkli t9GIlJBjcizvGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ESjf0bW7UknXQtuNCHydLlem3XlvA A6f+eqxN+fVIF4=; b=RluQzWPdcy9p84HbJUt3bfeXGeZ/rd41P66/hYt/M582m JcNGFCPa8oTc7Mrgol/qRu5z/nCpNO1Xh5NBZqUlYlofR+J4XkJLpQZ2mvKHx7JL Lrzwwsnz54jE835oFEPUehH9E8bGlOdE1nLNsHrWZypxc3/RZlPUCeZxEAmDD+1M YjOcSkzMSrKMhsPHt74/tnRXog1iaRzkZvH7Cy3cryPe5axNgGgMdeh5UL9jdisl sG1O53DE9yW9ZipnHqjZJkaM/PrH8zFbt4J988h7uSRTJVp3c7f6RI8yywUSBBrW nPolUiloQcL0W4XVQI/G8TOTcl+aktzQv+urSZujw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeiledguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvvdehrd efvdenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az213-537.internal.cloudapp.net (unknown [40.65.225.32]) by mail.messagingengine.com (Postfix) with ESMTPA id 60911240054 for ; Sun, 4 Apr 2021 03:43:22 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2934055139343300043==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210404074322.60911240054@mailuser.nyi.internal> Date: Sun, 4 Apr 2021 03:43:22 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 08:11:35 -0000 --===============2934055139343300043== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - An entropy pool design for MLS (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/467=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============2934055139343300043== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday April 04, 2021

Pull requests

mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============2934055139343300043==-- From nobody Mon Apr 5 01:45:47 2021 Return-Path: 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 DB72C3A0489 for ; Mon, 5 Apr 2021 01:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.20150623.gappssmtp.com 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 xkKz-Tocfyc3 for ; Mon, 5 Apr 2021 01:45:41 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD1A3A047D for ; Mon, 5 Apr 2021 01:45:40 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id mh7so5888580ejb.12 for ; Mon, 05 Apr 2021 01:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=uX3+RzjSY5gcvEnZtqSo8DVYHJoe3c+bLL5s9LkxkLs=; b=O1BzArFBslFh0fTdyHA2XpIFdvGVHgu6FYLV+JGuk7vmdxhrQmlBQlNs45rih+wRCa ViRSFavTNmHwJZt0BIB5JnacZk+WXy8jM7in1TTPnLJUBg/FuTBJbcPrCLVVRrAqbgs6 XzDib69o1FvlMPzLozN2/v4W9/T6RH7Ad0gOaAwNScUVyoo9VYHF2n/s4MWnrop9PvbU sqLyg4AFUZT5JrFgT3BVl2Y5272Ak9Wx/bXFp6iFpSo7ylZnmcdvRKewoswRWTPMmRzp 4ZurseS7TwN2ag7YKoxoXZw+M1IujGS6//sFdIDKqKYETbl5wa3uIpFnsXARIVwryycK d2BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uX3+RzjSY5gcvEnZtqSo8DVYHJoe3c+bLL5s9LkxkLs=; b=Zb8SzIj9sgwUUI1cb+U1sF/UcyuuXTi08+GwqWt5ZEICU2t8I6Taeyt6XHS8dSngdq VUB2Okdd58C9SGIguSGzbm9yRoVtZa0vmjDdRe1zZUmIMBtlN8y+XEOz5j+dkQ3Zy9FH nORGkQgyl51Alq61AD+ltfkz2ZL0I5GFeTCxQa+tz9BCE8AtIF34AyA2vSZltHsPPh2D wf/D8knxHZvDh0SgZOZAzaScHJh2IoA8lKE1SUzumlNydj0UCPvcRkFs+1MnA9LONEX/ LNNSTtguaOIztjablmWlaNe1Q1W3FM1CHQn92cTdCW2HWvOty+ymoNyqqFxiJLteKZdX Iwpg== X-Gm-Message-State: AOAM5333qDZhnKUWN+pfcE4fRL97I32UcojmeO/hafOwMsm+1M7UHE0z uXZKdR+uxhQPkOyEp9Fw42jJeZDLut0D2g== X-Google-Smtp-Source: ABdhPJz9lWBKPu19A5IHjsXWGVJ08hb0dGXv+jYbwkt7K5n1cLaxH/Hma+4sQnMlW+p9wnRcOr16wg== X-Received: by 2002:a17:907:a059:: with SMTP id gz25mr14817779ejc.211.1617612336504; Mon, 05 Apr 2021 01:45:36 -0700 (PDT) Received: from [192.168.1.137] (213-47-79-147.cable.dynamic.surfer.at. [213.47.79.147]) by smtp.gmail.com with ESMTPSA id e12sm840682edv.11.2021.04.05.01.45.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Apr 2021 01:45:35 -0700 (PDT) To: mls@ietf.org References: <1529628012.30519.1617089251424@office.mailbox.org> <965197897.32483.1617096310176@office.mailbox.org> <535299944.41006.1617176490395@office.mailbox.org> From: Joel Alwen Message-ID: <2c4da106-ef54-575b-1e4f-b94c02b00f7c@wickr.com> Date: Mon, 5 Apr 2021 10:45:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Improving entropy in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 08:45:46 -0000 Hey People, In principle modularity is definitely worth going for. The counter points though are "defense in depth" and "minimize your assumptions". Yes, the OS/cryptolib *should* provide good entropy. But we can still design protocols to minimize their dependce on that service. Other's have faced this issue in the past. Compare the ECDSA's strong dependency on external entropy when signing to that of the newer sig scheme EdDSA which requires none. It is precisely this *unnecessary* vuln in ECDSA that was exploited to break the PS3's security. Lessons we're learnt and thats how we ended up with EdDSA. The goal of this PR is to not make the same mistake with MLS. But modularity aside, its also not totally clear to me how the PR's mechanism would work as an external solution because it also feeds in entropy from ongoing MLs sessions. Here the solution benefits from ensuring that both A) entropy derived off the MLS session is never used for any other prupose and B) entropy is absorbed once for each epoch. (More often would be fine too but less efficient with no security improvement. Less would offer weaker security.) To simulate the same security benefits with an external entropy pool (e.g. in the OS or cryptolib) you'd want to reproduce both A) and B) since they both help with security. A) is possible but potentially rather non-trivial if you want to use exporter keys (and i'm not sure there's any other way to do it). Meanwhile the PR, being an internal solution, has lower-level access to the key schedule so it can trivially insure A) by defining a unique prefix to the HKDF for this purpose e.g. automatically seperating the output away from all exported keys. Ensuring B) doesn't look completely straightforward to me either. A "polling" based solution seems pretty imperfect & less-efficient to me. An alternative would be to have clients notify external services whenever a new commit has just been processed but is that really what we want? Even commits containing only update (or even no) proposals? (Not to mention is that even really an "external" solution...) Any way, I'm not saying I think there is no *possible* external solution. Just that the mechanisms in the PR seem more aligned with an internal one built into the MLS implementation rather than bolted on after the fact, especially in some code that doesn't even "know" about MLS at all. - Joël On 31/03/2021 09:55, Franziskus Kiefer wrote: > Hi Konrad, all > > I agree with Benjamin and Brendan that the protocol is not the right place for > something like this. > Since you already mention [1], don't you think it would be better to recommend > that implementations use RFC 8937 [2] and give an example of how to instantiate > G'(n)? > > Best, > Franziskus > > [1] https://eprint.iacr.org/2018/1057 > [2] https://www.rfc-editor.org/rfc/rfc8937.html > > > On Wed, 31 Mar 2021 at 09:41, Konrad Kohbrok > wrote: > > Hi Brendan, > > Thanks for your feedback! You make two good arguments here, that I want to > address independently. > > The first is the maintenance of layers of abstraction. Yes, ultimately, we'd > like to be able to rely on the OS's (CSP)RNG, but events in the past (see > the introduction of [1] for a few examples) have shown that they are not > always too reliable. As a consequence, protocols should be designed to be > robust against bad sources of randomness. In particular, our design allows > the inclusion of "remote" sources of randomness, which is something the OS's > RNG can't provide. In addition, I'd like to mention that we're not intending > to replace the OS's RNG, but rather complement it. Note, that the design > ensures that no secret can be extracted from the pool without retrieving > fresh randomness from the OS's RNG. > > This brings me to the second point, where I agree that we should keep MLS > free from unnecessary complexity that makes it more prone to bugs and you're > right in that the source of randomness is a particularly fundamental and > thus vulnerable part of MLS. However, the design is conceivably simple and > uses the same, tried, tested and provably secure mechanism that is used in > the key schedule of TLS and MLS: a simple extract-expand cycle. See [2] for > a security proof of the MLS key schedule, which can easily be adapted to the > design of the entropy pool. > > To summarize, we're not proposing to replace the OS's RNG, but rather extend > it such that additional sources of entropy can be included. The mechanism is > simple and, in my opinion, reasonably easy to review, implement and prove > secure without additional assumptions. > > Cheers, > Konrad > > [1] https://eprint.iacr.org/2018/1057 > [2] https://eprint.iacr.org/2021/137 > > > > Brendan McMillion > > hat am 30.03.2021 23:01 geschrieben: > > > > > > Hey Konrad > > > > Thanks for writing this up. However, I feel pretty strongly opposed to > this idea, just as a matter of maintaining proper layers of abstraction. MLS > implementations aren't remotely the only things on a user's system that > require strong randomness, which is why every OS has its own CSPRNG. Those > CSPRNGs are going to be much more robust, better designed, and thoroughly > audited than anything we'd implement. Instead, it's more likely we'd have > MLS implementations do this incorrectly and introduce more > randomness-related vulnerabilities than we prevented. > > > > > > > > On Tue, Mar 30, 2021 at 2:25 AM Konrad Kohbrok > > wrote: > > > Great questions. I really should have included our thoughts on the > threat model. > > > > > > We don't assume the entropy pool to be more protected than any other > secret in MLS. > > > > > > Functionally, we want the pool to allow the following: > > > - a party should be able to accrue entropy over time using the OS's RNG > > > - a party should be able to inject entropy from other sources (in > particular secrets derived from the epoch_secret of any of the party's > groups whenever a fresh commit comes in) > > > > > > Assuming the OS's RNG is really bad (e.g. it spits out only zeroes), > then a party can still have decent entropy once it receives commits from > groups that it is in. Any party that wants to predict the entropy in the > pool would have to know every secret that is injected into the pool. That > means that an adversary would have to compromise all of the party's groups > to predict secrets extracted from the entropy pool. > > > > > > Of course, the pool will take some time to accrue entropy from various > sources, so it doesn't help if the adversary is present from the start, but > it will help if the adversary compromises a party later on. If that happens, > then the compromised party can recover if the adversary misses (i.e. doesn't > intercept and decrypt) any commit from another party after the compromise. > > > > > > Now we have to make sure that the design doesn't give us any > disadvantages over just sampling from the OS's RNG every time we need fresh > randomness. > > > > > > Let's assume full state compromise. Then > > > 1) the adversary can't obtain entropy extracted from the pool in the > past (because it's essentially a KDF-chain, just as the key schedule) > > > 2) the adversary can't predict what entropy the client will extract in > the future if one of the following is true: > > > - the OS's RNG is good > > > - a commit from a group arrives, where the group itself is not compromised > > > - any other external entropy gets injected that the adversary doesn't > have access to (e.g. a signature from a secret key that is kept secure in an > HSM) > > > > > > To summarize: It's no silver bullet against bad entropy in general, but > it's cheap, no worse than just relying on the OS's RNG and provides a > framework to accrue randomness over time from various sources even if the > OS's RNG is bad/compromised and it allows parties to recover from compromise > in that case. > > > > > > Hope that shed some light on things. > > > > > > Cheers, > > > Konrad > > > > > > > > > > > > > Benjamin Beurdouche > hat am 30.03.2021 09:53 geschrieben: > > > > > > > > > > > > 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 > > 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 > > > > > > > _______________________________________________ > > > MLS mailing list > > > MLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/mls > > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > On 31/03/2021 09:55, Franziskus Kiefer wrote: > Hi Konrad, all > > I agree with Benjamin and Brendan that the protocol is not the right place for > something like this. > Since you already mention [1], don't you think it would be better to recommend > that implementations use RFC 8937 [2] and give an example of how to instantiate > G'(n)? > > Best, > Franziskus > > [1] https://eprint.iacr.org/2018/1057 > [2] https://www.rfc-editor.org/rfc/rfc8937.html > > > On Wed, 31 Mar 2021 at 09:41, Konrad Kohbrok > wrote: > > Hi Brendan, > > Thanks for your feedback! You make two good arguments here, that I want to > address independently. > > The first is the maintenance of layers of abstraction. Yes, ultimately, we'd > like to be able to rely on the OS's (CSP)RNG, but events in the past (see > the introduction of [1] for a few examples) have shown that they are not > always too reliable. As a consequence, protocols should be designed to be > robust against bad sources of randomness. In particular, our design allows > the inclusion of "remote" sources of randomness, which is something the OS's > RNG can't provide. In addition, I'd like to mention that we're not intending > to replace the OS's RNG, but rather complement it. Note, that the design > ensures that no secret can be extracted from the pool without retrieving > fresh randomness from the OS's RNG. > > This brings me to the second point, where I agree that we should keep MLS > free from unnecessary complexity that makes it more prone to bugs and you're > right in that the source of randomness is a particularly fundamental and > thus vulnerable part of MLS. However, the design is conceivably simple and > uses the same, tried, tested and provably secure mechanism that is used in > the key schedule of TLS and MLS: a simple extract-expand cycle. See [2] for > a security proof of the MLS key schedule, which can easily be adapted to the > design of the entropy pool. > > To summarize, we're not proposing to replace the OS's RNG, but rather extend > it such that additional sources of entropy can be included. The mechanism is > simple and, in my opinion, reasonably easy to review, implement and prove > secure without additional assumptions. > > Cheers, > Konrad > > [1] https://eprint.iacr.org/2018/1057 > [2] https://eprint.iacr.org/2021/137 > > > > Brendan McMillion > > hat am 30.03.2021 23:01 geschrieben: > > > > > > Hey Konrad > > > > Thanks for writing this up. However, I feel pretty strongly opposed to > this idea, just as a matter of maintaining proper layers of abstraction. MLS > implementations aren't remotely the only things on a user's system that > require strong randomness, which is why every OS has its own CSPRNG. Those > CSPRNGs are going to be much more robust, better designed, and thoroughly > audited than anything we'd implement. Instead, it's more likely we'd have > MLS implementations do this incorrectly and introduce more > randomness-related vulnerabilities than we prevented. > > > > > > > > On Tue, Mar 30, 2021 at 2:25 AM Konrad Kohbrok > > wrote: > > > Great questions. I really should have included our thoughts on the > threat model. > > >  > > >  We don't assume the entropy pool to be more protected than any other > secret in MLS. > > >  > > >  Functionally, we want the pool to allow the following: > > >  - a party should be able to accrue entropy over time using the OS's RNG > > >  - a party should be able to inject entropy from other sources (in > particular secrets derived from the epoch_secret of any of the party's > groups whenever a fresh commit comes in) > > >  > > >  Assuming the OS's RNG is really bad (e.g. it spits out only zeroes), > then a party can still have decent entropy once it receives commits from > groups that it is in. Any party that wants to predict the entropy in the > pool would have to know every secret that is injected into the pool. That > means that an adversary would have to compromise all of the party's groups > to predict secrets extracted from the entropy pool. > > >  > > >  Of course, the pool will take some time to accrue entropy from various > sources, so it doesn't help if the adversary is present from the start, but > it will help if the adversary compromises a party later on. If that happens, > then the compromised party can recover if the adversary misses (i.e. doesn't > intercept and decrypt) any commit from another party after the compromise. > > >  > > >  Now we have to make sure that the design doesn't give us any > disadvantages over just sampling from the OS's RNG every time we need fresh > randomness. > > >  > > >  Let's assume full state compromise. Then > > >  1) the adversary can't obtain entropy extracted from the pool in the > past (because it's essentially a KDF-chain, just as the key schedule) > > >  2) the adversary can't predict what entropy the client will extract in > the future if one of the following is true: > > >  - the OS's RNG is good > > >  - a commit from a group arrives, where the group itself is not compromised > > >  - any other external entropy gets injected that the adversary doesn't > have access to (e.g. a signature from a secret key that is kept secure in an > HSM) > > >  > > >  To summarize: It's no silver bullet against bad entropy in general, but > it's cheap, no worse than just relying on the OS's RNG and provides a > framework to accrue randomness over time from various sources even if the > OS's RNG is bad/compromised and it allows parties to recover from compromise > in that case. > > >  > > >  Hope that shed some light on things. > > >  > > >  Cheers, > > >  Konrad > > >  > > >  > > >  > > >  > Benjamin Beurdouche > hat am 30.03.2021 09:53 geschrieben: > > >  > > > >  > > > >  > 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 > > 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 > > > >  > > >  _______________________________________________ > > >  MLS mailing list > > >  MLS@ietf.org > > >  https://www.ietf.org/mailman/listinfo/mls > > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Sun Apr 18 00:51:12 2021 Return-Path: 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 89C693A0E94 for ; Sun, 18 Apr 2021 00:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=D9H6q9Vk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=slWKr1iu 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 qlO_Wa3G8AGj for ; Sun, 18 Apr 2021 00:51:02 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F366B3A0E95 for ; Sun, 18 Apr 2021 00:51:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 609CF5C053A for ; Sun, 18 Apr 2021 03:41:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 18 Apr 2021 03:41:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=S5piCJ9bydqs58GuM3rXw3C7s9ErUuEB1DrOCraM0kk=; b=D9H6q9Vk GvMcsr792HiyuOCXYy5iGw/+ETFJSpkOR9B2BOXV65En6MouZByBgtKHvufyz9Zb kyPmuLQkY1BtBBN08FC1G08dNfHehyKPpkUt16aZ1EPFxdPpCwTY8dPVmh1LH0b6 JsriojysospRMHaLcTiVDuy2bg6OWhTLjJMmlnRO1jUVoyo1NEF7avDYktnAnoha urptP6MTaCKFmZY+vt73TdGGSxLTpIFjOAHdODDAwcusqzvW8/AIdhV3bg9bRg60 OJ5aaCphkw4XZSd/YIlGyRbFWDGyvDzwp/8G6knMh4YCll6OycjuM6NfIQUwmcrv JVOFh/rkkYOMUA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=S5piCJ9bydqs58GuM3rXw3C7s9ErU uEB1DrOCraM0kk=; b=slWKr1iu+vxAXMN1GeMV/5ynxx/xL2j/bFJBd1SthUzwL Kg6APAoiwT6WnQiAlX2tJ7FbRtYxeoQ7ewsTe6l+620uwazq1KoMmm/TYtkZAwir KS4b9658oZjdRB9qIsCSie48xJ6s2rmoIWXUEswGX0oDQ2MQFWMzpol5UJwKHOkh gXIl+18AmEnE/OG/e2kNdGcn0phqwFb3XYF7X+TT+yQ6zsQ+ADnwt0sj8Y+bTe8b crRvGELUnUEIGzgzsQYunp2ck5/bBSVVT6GYTk69k6rK//zTxrl7e1b64Y+9OVTd NT9g8n5sqsMZxgBx+Ml5uOGQVLUbDWIgJXmKbqJNQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudelkedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddufeekrdekhedrle dvnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az207-445.internal.cloudapp.net (unknown [52.138.85.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D5011080069 for ; Sun, 18 Apr 2021 03:41:40 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2329201628641161657==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210418074140.4D5011080069@mailuser.nyi.internal> Date: Sun, 18 Apr 2021 03:41:40 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 07:51:07 -0000 --===============2329201628641161657== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #432 Remove the concept of leaf indices (1 by franziskuskiefer) https://github.com/mlswg/mls-protocol/issues/432=20 Pull requests ------------- * mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - Move definitions of security properties to security considerations sect= ion (by kkohbrok) https://github.com/mlswg/mls-architecture/pull/77=20 1 pull requests received 1 new comments: - #77 Move definitions of security properties to security considerations = section (1 by beurdouche) https://github.com/mlswg/mls-architecture/pull/77=20 1 pull requests merged: - Move definitions of security properties to security considerations sect= ion https://github.com/mlswg/mls-architecture/pull/77=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============2329201628641161657== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday April 18, 2021

Issues

mlswg/mls-protocol (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Pull requests

mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============2329201628641161657==-- From nobody Mon Apr 19 07:10:57 2021 Return-Path: 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 1BCE93A3364 for ; Mon, 19 Apr 2021 07:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, 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 hf7ZBhlFQHCl for ; Mon, 19 Apr 2021 07:10:45 -0700 (PDT) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD953A3376 for ; Mon, 19 Apr 2021 07:10:26 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2: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-201.mailbox.org (Postfix) with ESMTPS id 4FP7xq3k2PzQjbY; Mon, 19 Apr 2021 16:10:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id s7KgyuQ_WEJO; Mon, 19 Apr 2021 16:10:18 +0200 (CEST) Date: Mon, 19 Apr 2021 16:10:18 +0200 (CEST) From: Konrad Kohbrok To: Joel Alwen , mls@ietf.org Message-ID: <1932244246.88280.1618841418318@office.mailbox.org> In-Reply-To: <2c4da106-ef54-575b-1e4f-b94c02b00f7c@wickr.com> References: <1529628012.30519.1617089251424@office.mailbox.org> <965197897.32483.1617096310176@office.mailbox.org> <535299944.41006.1617176490395@office.mailbox.org> <2c4da106-ef54-575b-1e4f-b94c02b00f7c@wickr.com> 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: -7.55 / 15.00 / 15.00 X-Rspamd-Queue-Id: 3E7511817 X-Rspamd-UID: 88d0cd Archived-At: Subject: Re: [MLS] Improving entropy in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 14:10:56 -0000 Hi everyone, I'm not sure what the authors and the chairs had in mind in terms of how we= deal with the PRs and issue that are currently open (there are a couple of= others beside the PR discussed in this thread), but I think it would be us= eful to have (virtual) interims again to make progress. I know we are in a freeze, but I seem to remember that there is meant to be= a "last call" soon and I feel that some of the issues are definitely worth= discussing before that happens. Cheers, Konrad > Joel Alwen hat am 05.04.2021 10:45 geschrieben: >=20 > =20 > Hey People, >=20 > In principle modularity is definitely worth going for. The counter points= though > are "defense in depth" and "minimize your assumptions". Yes, the OS/crypt= olib > *should* provide good entropy. But we can still design protocols to minim= ize > their dependce on that service. >=20 > Other's have faced this issue in the past. Compare the ECDSA's strong dep= endency > on external entropy when signing to that of the newer sig scheme EdDSA wh= ich > requires none. It is precisely this *unnecessary* vuln in ECDSA that was > exploited to break the PS3's security. Lessons we're learnt and thats how= we > ended up with EdDSA. The goal of this PR is to not make the same mistake = with MLS. >=20 >=20 >=20 > But modularity aside, its also not totally clear to me how the PR's mecha= nism > would work as an external solution because it also feeds in entropy from = ongoing > MLs sessions. Here the solution benefits from ensuring that both A) entro= py > derived off the MLS session is never used for any other prupose and B) en= tropy > is absorbed once for each epoch. (More often would be fine too but less > efficient with no security improvement. Less would offer weaker security.= ) >=20 > To simulate the same security benefits with an external entropy pool (e.g= . in > the OS or cryptolib) you'd want to reproduce both A) and B) since they bo= th help > with security. A) is possible but potentially rather non-trivial if you w= ant to > use exporter keys (and i'm not sure there's any other way to do it). Mean= while > the PR, being an internal solution, has lower-level access to the key sch= edule > so it can trivially insure A) by defining a unique prefix to the HKDF for= this > purpose e.g. automatically seperating the output away from all exported k= eys. > Ensuring B) doesn't look completely straightforward to me either. A "poll= ing" > based solution seems pretty imperfect & less-efficient to me. An alternat= ive > would be to have clients notify external services whenever a new commit h= as just > been processed but is that really what we want? Even commits containing o= nly > update (or even no) proposals? (Not to mention is that even really an "ex= ternal" > solution...) >=20 >=20 > Any way, I'm not saying I think there is no *possible* external solution.= Just > that the mechanisms in the PR seem more aligned with an internal one buil= t into > the MLS implementation rather than bolted on after the fact, especially i= n some > code that doesn't even "know" about MLS at all. >=20 > - Jo=C3=ABl >=20 >=20 > On 31/03/2021 09:55, Franziskus Kiefer wrote: > > Hi Konrad, all > > > > I agree with Benjamin and Brendan that the protocol is not the right pl= ace for > > something like this. > > Since you already mention [1], don't you think it would be better to re= commend > > that implementations use RFC 8937 [2] and give an example of how to ins= tantiate > > G'(n)? > > > > Best, > > Franziskus > > > > [1] https://eprint.iacr.org/2018/1057 > > [2] https://www.rfc-editor.org/rfc/rfc8937.html > > > > > > On Wed, 31 Mar 2021 at 09:41, Konrad Kohbrok > > wrote: > > > > Hi Brendan, > > > > Thanks for your feedback! You make two good arguments here, that I = want to > > address independently. > > > > The first is the maintenance of layers of abstraction. Yes, ultimat= ely, we'd > > like to be able to rely on the OS's (CSP)RNG, but events in the pas= t (see > > the introduction of [1] for a few examples) have shown that they ar= e not > > always too reliable. As a consequence, protocols should be designed= to be > > robust against bad sources of randomness. In particular, our design= allows > > the inclusion of "remote" sources of randomness, which is something= the OS's > > RNG can't provide. In addition, I'd like to mention that we're not = intending > > to replace the OS's RNG, but rather complement it. Note, that the d= esign > > ensures that no secret can be extracted from the pool without retri= eving > > fresh randomness from the OS's RNG. > > > > This brings me to the second point, where I agree that we should ke= ep MLS > > free from unnecessary complexity that makes it more prone to bugs a= nd you're > > right in that the source of randomness is a particularly fundamenta= l and > > thus vulnerable part of MLS. However, the design is conceivably sim= ple and > > uses the same, tried, tested and provably secure mechanism that is = used in > > the key schedule of TLS and MLS: a simple extract-expand cycle. See= [2] for > > a security proof of the MLS key schedule, which can easily be adapt= ed to the > > design of the entropy pool. > > > > To summarize, we're not proposing to replace the OS's RNG, but rath= er extend > > it such that additional sources of entropy can be included. The mec= hanism is > > simple and, in my opinion, reasonably easy to review, implement and= prove > > secure without additional assumptions. > > > > Cheers, > > Konrad > > > > [1] https://eprint.iacr.org/2018/1057 > > [2] https://eprint.iacr.org/2021/137 > > > > > > > Brendan McMillion > > > hat am 30.03.2021 23:01 geschrieben: > > > > > > > > > Hey Konrad > > > > > > Thanks for writing this up. However, I feel pretty strongly oppos= ed to > > this idea, just as a matter of maintaining proper layers of abstrac= tion. MLS > > implementations aren't remotely the only things on a user's system = that > > require strong randomness, which is why every OS has its own CSPRNG= . Those > > CSPRNGs are going to be much more robust, better designed, and thor= oughly > > audited than anything we'd implement. Instead, it's more likely we'= d have > > MLS implementations do this incorrectly and introduce more > > randomness-related vulnerabilities than we prevented. > > > > > > > > > > > > On Tue, Mar 30, 2021 at 2:25 AM Konrad Kohbrok > > = > wrote: > > > > Great questions. I really should have included our thoughts on = the > > threat model. > > > > > > > > We don't assume the entropy pool to be more protected than any= other > > secret in MLS. > > > > > > > > Functionally, we want the pool to allow the following: > > > > - a party should be able to accrue entropy over time using the= OS's RNG > > > > - a party should be able to inject entropy from other sources = (in > > particular secrets derived from the epoch_secret of any of the part= y's > > groups whenever a fresh commit comes in) > > > > > > > > Assuming the OS's RNG is really bad (e.g. it spits out only ze= roes), > > then a party can still have decent entropy once it receives commits= from > > groups that it is in. Any party that wants to predict the entropy i= n the > > pool would have to know every secret that is injected into the pool= . That > > means that an adversary would have to compromise all of the party's= groups > > to predict secrets extracted from the entropy pool. > > > > > > > > Of course, the pool will take some time to accrue entropy from= various > > sources, so it doesn't help if the adversary is present from the st= art, but > > it will help if the adversary compromises a party later on. If that= happens, > > then the compromised party can recover if the adversary misses (i.e= . doesn't > > intercept and decrypt) any commit from another party after the comp= romise. > > > > > > > > Now we have to make sure that the design doesn't give us any > > disadvantages over just sampling from the OS's RNG every time we ne= ed fresh > > randomness. > > > > > > > > Let's assume full state compromise. Then > > > > 1) the adversary can't obtain entropy extracted from the pool = in the > > past (because it's essentially a KDF-chain, just as the key schedul= e) > > > > 2) the adversary can't predict what entropy the client will ex= tract in > > the future if one of the following is true: > > > > - the OS's RNG is good > > > > - a commit from a group arrives, where the group itself is not > compromised > > > > - any other external entropy gets injected that the adversary = doesn't > > have access to (e.g. a signature from a secret key that is kept sec= ure in an > > HSM) > > > > > > > > To summarize: It's no silver bullet against bad entropy in gen= eral, but > > it's cheap, no worse than just relying on the OS's RNG and provides= a > > framework to accrue randomness over time from various sources even = if the > > OS's RNG is bad/compromised and it allows parties to recover from c= ompromise > > in that case. > > > > > > > > Hope that shed some light on things. > > > > > > > > Cheers, > > > > Konrad > > > > > > > > > > > > > > > > > Benjamin Beurdouche > > hat am 30.03.2021 09:53 gesc= hrieben: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I like this idea. I am not fully clear about the threat mode= l, though. > > > > > > > > > > From reading this, it looks like we assume that the adversar= y that > > compromised a > > > > > principal doesn=E2=80=99t 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 additio= nal > > 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 prov= ide 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 > > = > wrote: > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > MLS is a protocol that is very vulnerable to individual pa= rties > > with bad randomness. For example, when a party joins a group, the s= ecrecy 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 compl= etely > > replaced by that of the joining member. > > > > > > > > > > > > There are multiple ways to mitigate this threat and Jo=C3= =ABl and Sandro > > proposed a few of them in the following mail to the list: > > https://mailarchive.ietf.org/arch/msg/mls/ZR84smU5xeLrziNTk5W1P1Z1n= QI/ > > > > > > > > > > > > > > Concretely, there were two approaches: one that would be b= aked into > > the protocol (essentially using a secret derived from old path secr= ets to > > inject into new ones in addition to the current approach) and one t= hat would > > mandate the use of an entropy pool. > > > > > > > > > > > > The ideas were discussed a bit at the time, but nothing ha= s > > happened since then. Jo=C3=ABl, Sandro and I have just opened a PR = with a > > concrete design for an entropy pool that is modeled after the key s= chedule > > (https://github.com/mlswg/mls-protocol/pull/467 > > ). Concretely, it a= llows > > gathering entropy over time and for parties with a bad entropy sour= ce to > > profit from parties with a good one without compromising security. > > > > > > > > > > > > While for future iterations of MLS, we might want to consi= der a > > solution that is more integral to the protocol, we are aware that t= he > > authors want to avoid breaking changes at this point. With the entr= opy 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 > > > > > > > > > > _______________________________________________ > > > > MLS mailing list > > > > MLS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mls > > > > > > > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > > > > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > >=20 >=20 > On 31/03/2021 09:55, Franziskus Kiefer wrote: > > Hi Konrad, all > >=20 > > I agree with Benjamin and Brendan that the protocol is not the right pl= ace for > > something like this. > > Since you already mention [1], don't you think it would be better to re= commend > > that implementations use RFC 8937 [2] and give an example of how to ins= tantiate > > G'(n)? > >=20 > > Best, > > Franziskus > >=20 > > [1] https://eprint.iacr.org/2018/1057 > > [2] https://www.rfc-editor.org/rfc/rfc8937.html > > > >=20 > > On Wed, 31 Mar 2021 at 09:41, Konrad Kohbrok > > wrote: > >=20 > > Hi Brendan, > >=20 > > Thanks for your feedback! You make two good arguments here, that I = want to > > address independently. > >=20 > > The first is the maintenance of layers of abstraction. Yes, ultimat= ely, we'd > > like to be able to rely on the OS's (CSP)RNG, but events in the pas= t (see > > the introduction of [1] for a few examples) have shown that they ar= e not > > always too reliable. As a consequence, protocols should be designed= to be > > robust against bad sources of randomness. In particular, our design= allows > > the inclusion of "remote" sources of randomness, which is something= the OS's > > RNG can't provide. In addition, I'd like to mention that we're not = intending > > to replace the OS's RNG, but rather complement it. Note, that the d= esign > > ensures that no secret can be extracted from the pool without retri= eving > > fresh randomness from the OS's RNG. > >=20 > > This brings me to the second point, where I agree that we should ke= ep MLS > > free from unnecessary complexity that makes it more prone to bugs a= nd you're > > right in that the source of randomness is a particularly fundamenta= l and > > thus vulnerable part of MLS. However, the design is conceivably sim= ple and > > uses the same, tried, tested and provably secure mechanism that is = used in > > the key schedule of TLS and MLS: a simple extract-expand cycle. See= [2] for > > a security proof of the MLS key schedule, which can easily be adapt= ed to the > > design of the entropy pool. > >=20 > > To summarize, we're not proposing to replace the OS's RNG, but rath= er extend > > it such that additional sources of entropy can be included. The mec= hanism is > > simple and, in my opinion, reasonably easy to review, implement and= prove > > secure without additional assumptions. > >=20 > > Cheers, > > Konrad > >=20 > > [1] https://eprint.iacr.org/2018/1057 > > [2] https://eprint.iacr.org/2021/137 > >=20 > >=20 > > > Brendan McMillion > > > hat am 30.03.2021 23:01 geschrieben: > > > > > > > > > Hey Konrad > > > > > > Thanks for writing this up. However, I feel pretty strongly oppos= ed to > > this idea, just as a matter of maintaining proper layers of abstrac= tion. MLS > > implementations aren't remotely the only things on a user's system = that > > require strong randomness, which is why every OS has its own CSPRNG= . Those > > CSPRNGs are going to be much more robust, better designed, and thor= oughly > > audited than anything we'd implement. Instead, it's more likely we'= d have > > MLS implementations do this incorrectly and introduce more > > randomness-related vulnerabilities than we prevented. > > > > > > > > > > > > On Tue, Mar 30, 2021 at 2:25 AM Konrad Kohbrok > > = > wrote: > > > > Great questions. I really should have included our thoughts on = the > > threat model. > > > >=C2=A0 > > > >=C2=A0 We don't assume the entropy pool to be more protected tha= n any other > > secret in MLS. > > > >=C2=A0 > > > >=C2=A0 Functionally, we want the pool to allow the following: > > > >=C2=A0 - a party should be able to accrue entropy over time usin= g the OS's RNG > > > >=C2=A0 - a party should be able to inject entropy from other sou= rces (in > > particular secrets derived from the epoch_secret of any of the part= y's > > groups whenever a fresh commit comes in) > > > >=C2=A0 > > > >=C2=A0 Assuming the OS's RNG is really bad (e.g. it spits out on= ly zeroes), > > then a party can still have decent entropy once it receives commits= from > > groups that it is in. Any party that wants to predict the entropy i= n the > > pool would have to know every secret that is injected into the pool= . That > > means that an adversary would have to compromise all of the party's= groups > > to predict secrets extracted from the entropy pool. > > > >=C2=A0 > > > >=C2=A0 Of course, the pool will take some time to accrue entropy= from various > > sources, so it doesn't help if the adversary is present from the st= art, but > > it will help if the adversary compromises a party later on. If that= happens, > > then the compromised party can recover if the adversary misses (i.e= . doesn't > > intercept and decrypt) any commit from another party after the comp= romise. > > > >=C2=A0 > > > >=C2=A0 Now we have to make sure that the design doesn't give us = any > > disadvantages over just sampling from the OS's RNG every time we ne= ed fresh > > randomness. > > > >=C2=A0 > > > >=C2=A0 Let's assume full state compromise. Then > > > >=C2=A0 1) the adversary can't obtain entropy extracted from the = pool in the > > past (because it's essentially a KDF-chain, just as the key schedul= e) > > > >=C2=A0 2) the adversary can't predict what entropy the client wi= ll extract in > > the future if one of the following is true: > > > >=C2=A0 - the OS's RNG is good > > > >=C2=A0 - a commit from a group arrives, where the group itself i= s not compromised > > > >=C2=A0 - any other external entropy gets injected that the adver= sary doesn't > > have access to (e.g. a signature from a secret key that is kept sec= ure in an > > HSM) > > > >=C2=A0 > > > >=C2=A0 To summarize: It's no silver bullet against bad entropy i= n general, but > > it's cheap, no worse than just relying on the OS's RNG and provides= a > > framework to accrue randomness over time from various sources even = if the > > OS's RNG is bad/compromised and it allows parties to recover from c= ompromise > > in that case. > > > >=C2=A0 > > > >=C2=A0 Hope that shed some light on things. > > > >=C2=A0 > > > >=C2=A0 Cheers, > > > >=C2=A0 Konrad > > > >=C2=A0 > > > >=C2=A0 > > > >=C2=A0 > > > >=C2=A0 > Benjamin Beurdouche > > hat am 30.03.2021 09:53 gesc= hrieben: > > > >=C2=A0 > > > > >=C2=A0 > > > > >=C2=A0 > Hi all, > > > >=C2=A0 > > > > >=C2=A0 > I like this idea. I am not fully clear about the threat= model, though. > > > >=C2=A0 > > > > >=C2=A0 > From reading this, it looks like we assume that the adv= ersary that > > compromised a > > > >=C2=A0 > principal doesn=E2=80=99t have complete control the ent= ropy pool. > > > >=C2=A0 > > > > >=C2=A0 > This is in contrast over what we assume of the AEAD key= s or even the > > KEM keys > > > >=C2=A0 > where a full state compromise will gain access to the v= alues. > > > >=C2=A0 > > > > >=C2=A0 > However it looks very close to the assumptions about ad= ditional > > protections for signing keys. > > > >=C2=A0 > E.g., not directly accessible, and behind an interface = that an > > adversary can query for certain operations > > > >=C2=A0 > through an API (e.g. when is stored in an HSM, co-proce= ssor or a > > functional secure enclave). > > > >=C2=A0 > > > > >=C2=A0 > Am I reading this properly? > > > >=C2=A0 > If yes, I can understand the value in this threat model= , but we > > should make it clear that the > > > >=C2=A0 > entropy pool has to get these additional protections to= provide these > > good properties. > > > >=C2=A0 > > > > >=C2=A0 > Seems to me like a good improvement in all cases anyway= , so I think > > we should consider it. > > > >=C2=A0 > > > > >=C2=A0 > Thanks! > > > >=C2=A0 > Ben > > > >=C2=A0 > > > > >=C2=A0 > > On 30 Mar 2021, at 09:27, Konrad Kohbrok > > = > wrote: > > > >=C2=A0 > > > > > >=C2=A0 > > Hi everyone, > > > >=C2=A0 > > > > > >=C2=A0 > > MLS is a protocol that is very vulnerable to individu= al parties > > with bad randomness. For example, when a party joins a group, the s= ecrecy 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 compl= etely > > replaced by that of the joining member. > > > >=C2=A0 > > > > > >=C2=A0 > > There are multiple ways to mitigate this threat and J= o=C3=ABl and Sandro > > proposed a few of them in the following mail to the list: > > https://mailarchive.ietf.org/arch/msg/mls/ZR84smU5xeLrziNTk5W1P1Z1n= QI/ > > > > > >=C2=A0 > > > > > >=C2=A0 > > Concretely, there were two approaches: one that would= be baked into > > the protocol (essentially using a secret derived from old path secr= ets to > > inject into new ones in addition to the current approach) and one t= hat would > > mandate the use of an entropy pool. > > > >=C2=A0 > > > > > >=C2=A0 > > The ideas were discussed a bit at the time, but nothi= ng has > > happened since then. Jo=C3=ABl, Sandro and I have just opened a PR = with a > > concrete design for an entropy pool that is modeled after the key s= chedule > > (https://github.com/mlswg/mls-protocol/pull/467 > > ). Concretely, it a= llows > > gathering entropy over time and for parties with a bad entropy sour= ce to > > profit from parties with a good one without compromising security. > > > >=C2=A0 > > > > > >=C2=A0 > > While for future iterations of MLS, we might want to = consider a > > solution that is more integral to the protocol, we are aware that t= he > > authors want to avoid breaking changes at this point. With the entr= opy pool, > > we thus propose a solution that does not affect the protocol flow, = but that > > still offers significant advantages over no mitigations at all. > > > >=C2=A0 > > > > > >=C2=A0 > > Cheers, > > > >=C2=A0 > > Konrad > > > >=C2=A0 > > > > > >=C2=A0 > > _______________________________________________ > > > >=C2=A0 > > MLS mailing list > > > >=C2=A0 > > MLS@ietf.org > > > >=C2=A0 > > https://www.ietf.org/mailman/listinfo/mls > > > > > >=C2=A0 > > > >=C2=A0 _______________________________________________ > > > >=C2=A0 MLS mailing list > > > >=C2=A0 MLS@ietf.org > > > >=C2=A0 https://www.ietf.org/mailman/listinfo/mls > > > > > > > >=20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > > >=20 > >=20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Thu Apr 22 04:49:24 2021 Return-Path: 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 138793A147B for ; Thu, 22 Apr 2021 04:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 oOK9O80QKtDW for ; Thu, 22 Apr 2021 04:49:20 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BDF3A147A for ; Thu, 22 Apr 2021 04:49:19 -0700 (PDT) IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AOb5WrK1WUOAde8j1yXgXRgqjBHokLtp033Aq?= =?us-ascii?q?2lEZdDV+dMuEm8ey2MkKzBOcskdzZFgMkc2NUZPwJE/02oVy5eAqU4uKeCnDlC?= =?us-ascii?q?+WIJp57Y3kqgeBJwTb+vRG3altN4hyYeeAb2RStsrx7AmmH9tI+rDum8qVrNzT?= =?us-ascii?q?1nJ8CTxtApsA0y5CFg2ZHkdqLTMrObMFEvOni/Zvln6FcXQTYt/TPBY4Y9Q=3D?= X-IronPort-AV: E=Sophos;i="5.82,242,1613430000"; d="scan'208";a="504493928" Received: from unknown (HELO [192.168.42.138]) ([37.171.157.154]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 22 Apr 2021 13:49:15 +0200 To: mls@ietf.org From: =?UTF-8?Q?Th=c3=a9ophile_Wallez?= Message-ID: <894d5000-fa72-ad62-d5d4-e5e7ad01a3f7@inria.fr> Date: Thu, 22 Apr 2021 13:49:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [MLS] Purpose of path_secret in the Welcome message? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 11:49:22 -0000 Hello, I am a PhD student currently writing a formalization of MLS, and I was wondering about the use of the `path_secret` field in `GroupSecrets`. To communicate with the group during the current epoch, it is sufficient to know `joiner_secret`. Also, thanks to the concept of unmerged leaves, a newly added leaf don't need to know any path secret to handle an UpdatePath: knowing a path secret early would simply result in the fact that the leaf could decrypt two different `encrypted_path_secret` in `UpdatePathNode`, which does not seem useful. Can someone give me some intuition for when and why this optional `path_secret` is used? Best, Théophile. From nobody Thu Apr 22 05:30:04 2021 Return-Path: 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 E447E3A1720 for ; Thu, 22 Apr 2021 05:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 qnwOxDRxljJo for ; Thu, 22 Apr 2021 05:29:58 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995F43A1725 for ; Thu, 22 Apr 2021 05:29:58 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id y12so33606127qtx.11 for ; Thu, 22 Apr 2021 05:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=purgFZGP3jpbrbxSjZxMSn0Un0U7akonOufscTTmhCE=; b=mR8N8hsTgSi7I85Gz0RJx4m6Yla3hwBbRQTMBii7v5dWQ42AzKoMO376sj5spQuWac wqBGM6JjQzMjI1VnQ0ym1T8OJyTyqbzoWReqtE76F/Q0XENDYj5AD+W1VyXn6psM5WHJ dqCCprkFoh7grC0zKLTzenxcSDvsGD3seLbiWzgtBhCh/jJTiFPB3bioPZKY8sc9VHZC uU5q6cXCXcpk/SWI3sGojEf+IEsuvh1dPXinfHJWNp071mx0wtoVtuMumyHzK+LroS9m 3kuu4s7aCMlBdTxE4YwfK7VKnSkzZCbfNHYlRXtU+XUhtqtTOlRVu1v7vsBMgDnNzsQf VM0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=purgFZGP3jpbrbxSjZxMSn0Un0U7akonOufscTTmhCE=; b=t9+JkqL+9FBfu7d5POctCYykkb3Dy18nWoy3m5sUgb3XCAEjbWxrEQ2XU999D1pkPU DVUKMq1iKNuHuTDdGrsMWNDi3ulC6qkB0nFWrRuZj15YUE5TRk/4vCJzvDzGgFnOx+fh 9FYRWWZfXRj86KxOl1hxDbY8gwWv2+lnDp5dNP5FFhFoJ/6pBVl7u6VKpRED54BSdu6a 87JF/o5tlWKZeR95xdNIqWBYU1WR1mzOj8yQc5JqQOlwTUkuL/dYhSKwGplMsTTlxdes Y4IF43qmtRm/8luQZoDZRIpHVMiqvw1TdtZ8nreOeKU1QfXIyD2B3n5B52kmXOKBmYpz FG8Q== X-Gm-Message-State: AOAM5327ASZFnrWYYUalMVXT2rwemMuHM2B/DaxyYEXae+KKlFioj4XV ch4xlh7CIH6ZcaVIbGM01kpauyIQUblkUK6vXDyfEAZ+vx09wA== X-Google-Smtp-Source: ABdhPJxaAfuEA1P/yiMNnEcYn4sEfaPFzCj2DvE2ynq7BQlilUkFrbPM5L7Xy2a9PpIbEyDY0hSqY5mmRHekRJT7MVQ= X-Received: by 2002:a05:622a:148f:: with SMTP id t15mr2959359qtx.191.1619094595870; Thu, 22 Apr 2021 05:29:55 -0700 (PDT) MIME-Version: 1.0 References: <894d5000-fa72-ad62-d5d4-e5e7ad01a3f7@inria.fr> In-Reply-To: <894d5000-fa72-ad62-d5d4-e5e7ad01a3f7@inria.fr> From: Richard Barnes Date: Thu, 22 Apr 2021 08:29:37 -0400 Message-ID: To: =?UTF-8?Q?Th=C3=A9ophile_Wallez?= Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000003eb8fe05c08ed636" Archived-At: Subject: Re: [MLS] Purpose of path_secret in the Welcome message? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 12:30:03 -0000 --0000000000003eb8fe05c08ed636 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Th=C3=A9ophile, You're correct that the `path_secret` isn't used in the process of joining the group (decrypting the Welcome message and initializing group state). It is used the next time there's a group operation and an UpdatePath is sent. It's optional because the sender of an all-Add Commit message doesn't have to send an Update Path. In that case, the path above a joiner's leaf will be all-blank; there's no path secret to communicate. Hope that helps, --Richard On Thu, Apr 22, 2021 at 7:49 AM Th=C3=A9ophile Wallez wrote: > Hello, > > I am a PhD student currently writing a formalization of MLS, and I was > wondering about the use of the `path_secret` field in `GroupSecrets`. > To communicate with the group during the current epoch, it is sufficient > to know `joiner_secret`. > Also, thanks to the concept of unmerged leaves, a newly added leaf don't > need to know any path secret to handle an UpdatePath: knowing a path > secret early would simply result in the fact that the leaf could decrypt > two different `encrypted_path_secret` in `UpdatePathNode`, which does > not seem useful. > > Can someone give me some intuition for when and why this optional > `path_secret` is used? > > > Best, > Th=C3=A9ophile. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000003eb8fe05c08ed636 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Th=C3=A9ophile,

You'r= e correct that the `path_secret` isn't used in the process of joining t= he group (decrypting the Welcome message and initializing group state).=C2= =A0 It is used the next time there's a group operation and an UpdatePat= h is sent.=C2=A0 It's optional because the sender of an all-Add Commit = message doesn't have to send an Update Path.=C2=A0 In that case, the pa= th above a joiner's leaf will be all-blank; there's no path secret = to communicate.

Hope that helps,
--Richard

On Thu, Apr 22, 2021 at 7:49 AM Th=C3=A9ophile Wallez <<= a href=3D"mailto:theophile.wallez@inria.fr">theophile.wallez@inria.fr&g= t; wrote:
Hello,=

I am a PhD student currently writing a formalization of MLS, and I was
wondering about the use of the `path_secret` field in `GroupSecrets`.
To communicate with the group during the current epoch, it is sufficient to know `joiner_secret`.
Also, thanks to the concept of unmerged leaves, a newly added leaf don'= t
need to know any path secret to handle an UpdatePath: knowing a path
secret early would simply result in the fact that the leaf could decrypt two different `encrypted_path_secret` in `UpdatePathNode`, which does
not seem useful.

Can someone give me some intuition for when and why this optional
`path_secret` is used?


Best,
Th=C3=A9ophile.

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000003eb8fe05c08ed636-- From nobody Thu Apr 22 08:38:20 2021 Return-Path: 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 D06FD3A16E7 for ; Thu, 22 Apr 2021 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 1Wa6m5H-gPa1 for ; Thu, 22 Apr 2021 08:38:08 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8693A1642 for ; Thu, 22 Apr 2021 08:37:45 -0700 (PDT) IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AjpDoEKpdceHGuRGkgaqhN6YaV5uvLNV00zAX?= =?us-ascii?q?/kB9WHVpW+SCncGvg/gXkTfo4QxhAk0IscycOaWGXHPX/YN0545UBru5QAz6og?= =?us-ascii?q?KTRr1Kx43k3jHmBmni5vdQvJ0QLpRWJf/RKRxUjcPm7BLQKadH/PCr0oCNwd3f?= =?us-ascii?q?wXBkUB1wZ8hbnn5EIyuSD0Eefng2ObMVGJ+d+cZdqzflRHJ/VKuGL1UfRO7ZvZ?= =?us-ascii?q?n3kvvdEFA7LjE97g3mt0LT1JfeEwKEmj8EWTJO3rtKyxmfryXd5r+/99C2zwa0?= =?us-ascii?q?7R6W071ymMH9jvtPbfb8z/Q9DzX3l0KPeoNsQNS5zWgIicSu8ktvqd/Xvn4bTp?= =?us-ascii?q?1OwlbQZHzwmwfnwQP60D0jgkWSjmOwpHv4vIjEQygnANBKnoJTfnLimgwdlfVx?= =?us-ascii?q?yrhC0W7cl5c/N2K9oA3Y59zFEy5njVC1p31Kq59vs1VnSocVZLJcqoYSlXklUe?= =?us-ascii?q?ZBIAvA5IoqEPZjAajnjZ48HD36DwG7zwsfp+CEZXg9EgyLRUIPoKWuokdrtUt0?= =?us-ascii?q?1k4JgPEY901wua4VcZVC6ujeW54Y141mdNMcbq52GY46MIGKI1HKKCi8Tl66EB?= =?us-ascii?q?DNFLIOPHzEwqSHq4kd1aWFY5AZyZsphf36ISBlnF93XkTpEKS1rdF22yGIZG28?= =?us-ascii?q?WDj3o/sul6RRi/nZTLrvKzCZThQQm9Chq/4bDtezYYfASedrKs6mC3DvF4ZP1w?= =?us-ascii?q?i7YZ9PMnMTFO0t0+xLL26mk4bsMY3ltuvSdbLvItPWfQoMayfFDnwKQTTpYP9N?= =?us-ascii?q?9V+mQVjxhBS5YQKkRmXPual9F6DG8/NW8pEEMqdFrhIY4G7Jr/2jGHl4vqs/YU?= =?us-ascii?q?dkZIn/mqeAr2+s8Q/znhNUEysYNUpT6KjtSDdxvAcPCV79bLprgaTpRUlimEGK?= =?us-ascii?q?PgNySMnbeTQv6GhfyOaJL4eN32QZAdqhNW6W5kFjwAPwc74s3pKC/tv+PqkkBo?= =?us-ascii?q?s7QsVKZGC7byBdqEJsriNKcwUERlDSfwmey5mYsA=3D=3D?= X-IronPort-AV: E=Sophos;i="5.82,242,1613430000"; d="scan'208";a="504547152" Received: from apoitiers-658-1-144-74.w90-16.abo.wanadoo.fr (HELO [192.168.42.138]) ([90.16.71.74]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 22 Apr 2021 17:37:16 +0200 To: Messaging Layer Security WG References: <894d5000-fa72-ad62-d5d4-e5e7ad01a3f7@inria.fr> From: =?UTF-8?Q?Th=c3=a9ophile_Wallez?= Message-ID: <13d9cf9c-7a1d-164f-e739-07b8da6a291e@inria.fr> Date: Thu, 22 Apr 2021 17:37:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MLS] Purpose of path_secret in the Welcome message? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 15:38:19 -0000 Hi Richard, On 22/04/2021 14:29, Richard Barnes wrote: > It is used the next time there's a group operation and an UpdatePath > is sent. I don't get why this is true? From my understanding, a new leaf will be in the `unmerged_leaves` list of all the non-blank nodes above it [0]. Given this fact, the new leaf will be in the resolution of all the nodes above it, therefore the new leaf will be able to decipher the path secrets for the following UpdatePath without using the `path_secret` of the Welcome message. Also, in the worst case the `path_secret` might correspond to the path secret of the root node (since it is the path secret of the lowest common ancestor of the leaf sending the Welcome message and the leaf receiving the Welcome message [1]), which would not be useful to process an UpdatePath message. [0] https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html#section-11.1.1-5.2 [1] https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html#section-11.2.2-9.4.2.2 Thanks, Théophile. From nobody Thu Apr 22 18:24:31 2021 Return-Path: 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 CC0033A1E7C for ; Thu, 22 Apr 2021 18:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 2aXWdnYawfUo for ; Thu, 22 Apr 2021 18:24:25 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3852A3A1E7A for ; Thu, 22 Apr 2021 18:24:24 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id v7so20242388qkj.13 for ; Thu, 22 Apr 2021 18:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8Q8k0hE10EkGcJiToUYeXAdTWykhZSv8irjS9bIsyg=; b=1uL2/ot0zJQebwQG/8e+R20Zej/CAmouQ2EsAF0HOsis1i1rZXmLVPOr9OnOiskmek r5F4Bh6Nj3I2x8v5o6dLdEiEU9kNdyCm6WNmXfzbwK1Xyc2WgTVPVhSyCJ+ZbqoWpwBu 8ah7TYafp2U53QqKtxiVy021G10ly2lxDUBrjuJo1LEuQ4GTG3KXR93s8zSeegBL41+2 y4jfEYK9cpQH2VJgUig1xFSxoPbE7O1pZEpX1Km5aZ2rN+mREx27yXGdhPoEr9+IUM8z 5Rzw9QPU/DnQLfvcsG9tCW4X1bKnWwEON/cZcui4gVgJ6RppKJMOnb2DcnHdTE2ugTYp RPsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t8Q8k0hE10EkGcJiToUYeXAdTWykhZSv8irjS9bIsyg=; b=s6JZPSwRBPEBW3kq7k48uLJDmhI5PvThyF5HdrGL0k40tgEXJIx/fZgVOcJ3ZAR/Op rgdqQaEBU7K1ExPR6bYuoWZaGI6J8BaBUlFpyWISW9JczkG8v/kvfqJRXfHsSukcvfBd 7Wtkv5jRQkpsoci6EZvvpKhN9xw9HeYKBfk1hUs83kMQ/8/R3XDtLaiVaAbzk5A9GG3I I6UjcnxhgMXQH4osvIjymQpgIgH2gHMWwY5n01T5TX3ARIG9/LZ+12VDjG3WoVdisdWe 3UDz1oR0tmr31HPWrtwdEV3/nm/rulAqe0+h0MeDqHikWsNZjASEHiArlXMgysR5YPj0 suuw== X-Gm-Message-State: AOAM533Yl5gswQrEpEMlM33AHJShYLQkm3r1uml5EnWhMG1dAJZwPc8/ UeVFikqCAJMmNdcY6uEflnmsqEH8ch6iGOVaKTdGzA== X-Google-Smtp-Source: ABdhPJzFKWVvkq/Wme16yC3aZrWMMZQhpbBnSLa3WP19/JtYqchRdaldhZOJSegEYznW7xKJiVoxiraYAWhBlKaKqM4= X-Received: by 2002:a37:a887:: with SMTP id r129mr1552471qke.371.1619141061671; Thu, 22 Apr 2021 18:24:21 -0700 (PDT) MIME-Version: 1.0 References: <894d5000-fa72-ad62-d5d4-e5e7ad01a3f7@inria.fr> <13d9cf9c-7a1d-164f-e739-07b8da6a291e@inria.fr> In-Reply-To: <13d9cf9c-7a1d-164f-e739-07b8da6a291e@inria.fr> From: Richard Barnes Date: Thu, 22 Apr 2021 21:24:03 -0400 Message-ID: To: =?UTF-8?Q?Th=C3=A9ophile_Wallez?= Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d2873705c099a75f" Archived-At: Subject: Re: [MLS] Purpose of path_secret in the Welcome message? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 01:24:30 -0000 --000000000000d2873705c099a75f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2021 at 11:39 AM Th=C3=A9ophile Wallez wrote: > Hi Richard, > > On 22/04/2021 14:29, Richard Barnes wrote: > > > It is used the next time there's a group operation and an UpdatePath > > is sent. > > I don't get why this is true? > From my understanding, a new leaf will be in the `unmerged_leaves` list > of all the non-blank nodes above it [0]. Ah, this might not be obvious from the spec, but the order of operations for the committer and their tree is as follows: 1. Apply proposals - including adding joiners to unmerged_leaves 2. Generate and apply an UpdatePath In that stage 2, the nodes on the committer's direct path are overwritten -- including clearing unmerged_leaves, because the corresponding secret is sent to all the leaves underneath that node. Continuing members get the path secret from the UpdatePath struct; new members get it from GroupSecrets.path_secret. As usual, happy to clarify the spec if it can be clearer on this point. --RLB > Given this fact, the new leaf > will be in the resolution of all the nodes above it, therefore the new > leaf will be able to decipher the path secrets for the following > UpdatePath without using the `path_secret` of the Welcome message. > Also, in the worst case the `path_secret` might correspond to the path > secret of the root node (since it is the path secret of the lowest > common ancestor of the leaf sending the Welcome message and the leaf > receiving the Welcome message [1]), which would not be useful to process > an UpdatePath message. > > > [0] > > https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol= .html#section-11.1.1-5.2 > [1] > > https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol= .html#section-11.2.2-9.4.2.2 > > Thanks, > Th=C3=A9ophile. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d2873705c099a75f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 22, 2021 at 11:39 AM Th=C3=A9= ophile Wallez <theophile.wa= llez@inria.fr> wrote:
Hi Richard,

On 22/04/2021 14:29, Richard Barnes wrote:

> It is used the next time there's a group operation and an UpdatePa= th
> is sent.

I don't get why this is true?
=C2=A0From my understanding, a new leaf will be in the `unmerged_leaves` li= st
of all the non-blank nodes above it [0].

A= h, this might not be obvious from the spec, but the order of operations for= the committer and their tree is as follows:

1. Apply pro= posals - including adding joiners to unmerged_leaves
2. Gener= ate and apply an UpdatePath

In that stage 2, t= he nodes on the committer's direct path are overwritten -- including cl= earing unmerged_leaves, because the corresponding secret is sent to all the= leaves underneath that node.=C2=A0 Continuing members get the path secret = from the UpdatePath struct; new members get it from GroupSecrets.path_secre= t.

As usual, happy to clarify the spec if it can be clearer on this poi= nt.

--RLB
=C2=A0
Given this fact, the new leaf
will be in the resolution of all the nodes above it, therefore the new
leaf will be able to decipher the path secrets for the following
UpdatePath without using the `path_secret` of the Welcome message.
Also, in the worst case the `path_secret` might correspond to the path
secret of the root node (since it is the path secret of the lowest
common ancestor of the leaf sending the Welcome message and the leaf
receiving the Welcome message [1]), which would not be useful to process an UpdatePath message.


[0]
htt= ps://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html= #section-11.1.1-5.2
[1]
https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.= html#section-11.2.2-9.4.2.2

Thanks,
Th=C3=A9ophile.

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d2873705c099a75f-- From nobody Fri Apr 23 11:18:00 2021 Return-Path: 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 A64B33A1920 for ; Fri, 23 Apr 2021 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 l3d6WrSuI6tg for ; Fri, 23 Apr 2021 11:17:57 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87D93A191E for ; Fri, 23 Apr 2021 11:17:56 -0700 (PDT) IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A8iUX9ao0VCMs9ur3w0PPa7saV5sQLdV00zAX?= =?us-ascii?q?/kB9WHVpW+SCncGvg/gXkTfo4QxhAk0Is9aGJaWGXDfw9YRt55MQILelW2DdyR?= =?us-ascii?q?eVBatl6pbvxCClPiX4+PJU26sISdkCNPTbC19mgcHmpDSiG9E7z9WdtIyuj+HS?= =?us-ascii?q?z3BiJDsaEZ1IxQF/FwqdDwlKVBBLbKBJb6a0y+hmg36beXoRZtmmHXVtZYX+jv?= =?us-ascii?q?DCiZ6OW29hOzcK8xKJlint1biSKWnX4j4wSDVKqI1SklTttgzi++GKqPu7ygDR?= =?us-ascii?q?vlWjtKh+vdv6159jCMmU4/JlbgnErwazecBAVtS5zXUIicSu8ktvtsfKrwxIBb?= =?us-ascii?q?Uq11r1fnup5SLqwRSI6kd211bGyUWExUH+qtbyXzIwB6N69MVkWz7Y8VdlgNZn?= =?us-ascii?q?zKlQ1XmYvJY/N2KHoA3Yx/zlEy5njVC1p31Kq59qs1V6XZEFYLFc6awzlXkld6?= =?us-ascii?q?soJTn34owrHO5lAKjnlbcmMW+yVHzSsmlxzNHEZB1adX3rLSZi2vC96DROmWA8?= =?us-ascii?q?8k1w/r1Tol47+JUxR4Is3ZWGDo1TiLpMQsUKBJgNTtspfM3fMB2ufTvxKm6IZX?= =?us-ascii?q?zoGKYbUki90qLf0fEc/+uqeIMFiKconf36ITZlnF93UEL8AcqB1PRwg1jwaVT4?= =?us-ascii?q?eDLq06hlltREk4y5YqHqPy2FQFVrvu+JmN9aOcHQXe2/UagmXsPLHC/JAoZG3w?= =?us-ascii?q?r3Xt1pL2UEWsFQmu9TYSP6nuv7brbnseTHfO2WHrb3Djo+fWv6DhI4LXHODfQF?= =?us-ascii?q?1UytUmL1m1zqQnvoUETi554YKtmtw8EjjLMAMYVQvhNQs02w4vuALyZP25ZGC3?= =?us-ascii?q?dWEffdnqSyuGWsuVzQ52FSJxJBAi9ukcHdekIPnwMTL0/ye7prgaTRRUlimEGf?= =?us-ascii?q?Lhs6dd7fDRJEzm4Hi56fHtit6AVnL9qmN1iRh3wVqGnideZspoSzofvJX9cdBp?= =?us-ascii?q?YiYqZ4EgLGDFhbggBvwV0zGzMsdwviOxarra2kiaYfDObZe8I5oCrDG78rlVvv?= =?us-ascii?q?8XmwgIUKTnsfZTSnVsmamkIPQDVTnVl47q8Yh9O76EmSAFp6vMkcdHlFaGGsCr?= =?us-ascii?q?pACwifIL9MkrTAeQ17Tw6x9EynoiB2RnHunn9i4lDJHGmqcfTKD1JBunZelq37?= =?us-ascii?q?mWkEPVm1TgZ2bDRzqod9FXvL00wDk9O2Wg=3D=3D?= X-IronPort-AV: E=Sophos;i="5.82,246,1613430000"; d="scan'208,217";a="504748385" Received: from lfbn-idf1-1-1495-94.w90-90.abo.wanadoo.fr (HELO [192.168.1.25]) ([90.90.176.94]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 23 Apr 2021 20:17:29 +0200 To: Richard Barnes Cc: Messaging Layer Security WG References: <894d5000-fa72-ad62-d5d4-e5e7ad01a3f7@inria.fr> <13d9cf9c-7a1d-164f-e739-07b8da6a291e@inria.fr> From: =?UTF-8?Q?Th=c3=a9ophile_Wallez?= Message-ID: <2e031088-4ba7-bd3a-efc9-8cbea85e9d53@inria.fr> Date: Fri, 23 Apr 2021 20:17:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------018A77782F93BF7751C20678" Content-Language: en-US-large Archived-At: Subject: Re: [MLS] Purpose of path_secret in the Welcome message? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 18:17:59 -0000 This is a multi-part message in MIME format. --------------018A77782F93BF7751C20678 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 23/04/2021 03:24, Richard Barnes wrote: > Ah, this might not be obvious from the spec, but the order of > operations for the committer and their tree is as follows: > > 1. Apply proposals - including adding joiners to unmerged_leaves > 2. Generate and apply an UpdatePath > > In that stage 2, the nodes on the committer's direct path are > overwritten -- including clearing unmerged_leaves, because the > corresponding secret is sent to all the leaves underneath that node.  > Continuing members get the path secret from the UpdatePath struct; new > members get it from GroupSecrets.path_secret. > > As usual, happy to clarify the spec if it can be clearer on this point. Thank you, this clarifies the use of `path_secret`! Indeed, I thought it was done in the reverse order (generate and apply an UpdatePath, then apply proposals). Théophile. --------------018A77782F93BF7751C20678 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 23/04/2021 03:24, Richard Barnes wrote:
Ah, this might not be obvious from the spec, but the order of operations for the committer and their tree is as follows:

1. Apply proposals - including adding joiners to unmerged_leaves
2. Generate and apply an UpdatePath

In that stage 2, the nodes on the committer's direct path are overwritten -- including clearing unmerged_leaves, because the corresponding secret is sent to all the leaves underneath that node.  Continuing members get the path secret from the UpdatePath struct; new members get it from GroupSecrets.path_secret.

As usual, happy to clarify the spec if it can be clearer on this point.

Thank you, this clarifies the use of `path_secret`!

Indeed, I thought it was done in the reverse order (generate and apply an UpdatePath, then apply proposals).

Théophile.

--------------018A77782F93BF7751C20678--