From nobody Fri Jan 1 06:48:36 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 5AFB33A07F5 for ; Fri, 1 Jan 2021 06:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 xw1LjpuZRNxT for ; Fri, 1 Jan 2021 06:48:31 -0800 (PST) Received: from mailg210.ethz.ch (mailg210.ethz.ch [IPv6:2001:67c:10ec:5606::21]) (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 6AB293A07EA for ; Fri, 1 Jan 2021 06:48:30 -0800 (PST) Received: from mailm217.d.ethz.ch (2001:67c:10ec:5603::31) by mailg210.ethz.ch (2001:67c:10ec:5606::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 1 Jan 2021 15:48:09 +0100 Received: from mailm213.d.ethz.ch (2001:67c:10ec:5603::27) by mailm217.d.ethz.ch (2001:67c:10ec:5603::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 1 Jan 2021 15:48:25 +0100 Received: from mailm213.d.ethz.ch ([fe80::48e5:b9c:79eb:9d16]) by mailm213.d.ethz.ch ([fe80::48e5:b9c:79eb:9d16%4]) with mapi id 15.01.2106.006; Fri, 1 Jan 2021 15:48:25 +0100 From: "Mularczyk Marta" To: "mls@ietf.org" CC: Raphael Robert , 'Joel Alwen' Thread-Topic: [MLS] New Parent Hash Thread-Index: AQHWuTjfZw1SmrLREUKS4j4Eh1hSAKoRUjgAgABQ3ICAAYQpGA== Date: Fri, 1 Jan 2021 14:48:25 +0000 Message-ID: <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com>, In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.4.196.130] x-tm-snts-smtp: 80D60426418710D866A70DC07484FF954B5FE49E3D8FD0D66A301BE88B2109CE2000:8 Content-Type: multipart/alternative; boundary="_000_32c5c409abbc4cf79ecf74c9e2a2befainfethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [MLS] New Parent Hash 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, 01 Jan 2021 14:48:34 -0000 --_000_32c5c409abbc4cf79ecf74c9e2a2befainfethzch_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Raphael, Thanks for explaining! Using "descendants" is definitely better for securit= y, but also, as Hubert mentioned, less efficient. Also we did understand =93resolution=94 the same way as you when we propose= d the strong parent hash (sorry for the confusion). But we obviously really want to understand if/why using resolution is insec= ure. Ultimately, the security property we care about is that privacy and au= thenticity of application messages holds. The Parent Hash mechanism helps u= s ensure this holds also for epochs in adversarially generated groups, as l= ong as the adversary does not control any leaves in this epoch (i.e. does n= ot know the signing key of the leaf). So to really see if your examples bre= ak security, it would be good to see if they let us violate this security g= oal. To see why we believe the new parent hash notion (i.e. with resolutions) ac= hieves this, let us first clarify what technical property about (even adver= sarially produced) ratchet trees we want from verifying parent hashes. It= =92s not that the adversary can=92t produce manipulated trees at all. It=92= s that the only manipulations she is able to do will not let her produce a = tree that violates the tree invariant. That=92s because (in our model) when= the tree invariant holds then we can show that the epoch is secure. So some manipulations *are* possible. They are just =93benign=94. For examp= le, suppose adversary A controls a leaf L with HPKE key pk in tree T (i.e. = she knows the signing key of L=92s owner). Then A can construct a new tree = T=92 identical to T but where leaf L has pk=92 !=3D pk (say, by performing = a commit at leaf L to obtain T=92). But for this, in T=92 leaf L must still= be controlled by A. We call this manipulation =93benign=94 because even th= ough A might now break privacy of application messages in epoch with tree T= =92 it doesnt violate our security goal because privacy is conditioned on A= *not* controlling any leaves. Conversely, one thing A can *not* do is the following. Say T=92 has a node = V with HPKE public key pk0 such that A knows corresponding sk0. Then for T= =92 to pass verification, it must contain a leaf controlled by A. This hold= s since for T=92 to pass verification there must be a leaf in V=92s subtree= with a signature covering a hash that includes pk0. I.e. some leaf must = =93attest=94 to having inserted pk0 into T=92. (Recall that in our model th= e adversary can=92t just leak sk0 alone. They must leak a full state of som= e client which also means leaking the client's signing key.) So our question to you is the following. (Does this make sense? And) we=92r= e not exactly sure what you have in mind when you say =93swapping out two l= eaf nodes=94. But we think it would only be a problem if it is not benign. = Is this true for your attack? Could you expand a bit on what tree manipulat= ion you have in mind? Best, Jo=EBl & Marta ________________________________ From: MLS on behalf of Hubert Chathi Sent: Thursday, December 31, 2020 5:36:53 PM To: mls@ietf.org Subject: Re: [MLS] New Parent Hash I think that if you use "descendants" as you define it, then calculating th= e parent_hash will become O(n) all the time, rather than O(log n) in the be= st-case, since the size of the descendants list will be O(n). I'm not sure= if there's a good way to maintain O(log n) and still provide the desired s= ecurity. On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: > Hi Jo=EBl, Daniel and Marta, > > I just implemented the stronger parent hash scheme you proposed in the > way it is described in the spec now. > The good news is that it is implementable, the bad news is that is does > not solve the problem you initially describe. Specifically, swapping > out two leaf nodes still goes undetected. > > I think it is due to a terminology conflict, but it would be great if > you could validate that assumption. > In 7.4 you introduce the notion of =93original child resolution=94 as " t= he > array of HPKEPublicKey values of the nodes in the resolution of S=94. The > term =93resolution=94 is defined in 5.2. It is essentially a way of deali= ng > with blank nodes by substituting them with the first non-blank > descendants you find when descending the subtree of a node. > Here is my assumption: You probably thought the resolution would cover > all non-blank descendants of a node, not just the first non-blank > descendant. In that case we would need another function that does that > (let=92s call it =93descendants=94). > > If we look at the example of 5.2: > > =16=16 - The resolution of node 3 is the list [A, CD, C] > - The descendants of node 3 is the list [A, CD, C, D] > > =16=16 - The resolution of node 5 is the list [CD] > - The descendants of node 5 is the list [CD, C, D] (we just need to > additionally filter out C, because it is an unmerged leaf of node 5) > > Here is a code snippet of what the =93descendants=94 function would look > like (sorry that it=92s Rust, not Python): > > fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { > if level(x) =3D=3D 0 { > vec![x] > } else { > let left_child =3D left(x); > let right_child =3D right(x, size); > [ > descendants(left_child, size), > vec![x], > descendants(right_child, size), > ] > .concat() > } > } > > There=92s a more efficient implementation of course, this is just to illu= strate. > > In other words, the new =93original child resolution=94 of S would be the > subtree under S, but with filtered-out blank nodes and unmerged leaves > of S. > > If my assumption is correct, I=92ll follow up quickly with a PR since > this is currently a blocker for interop based on draft-11. > > Thanks > > Raphael > > > > > On 12. Nov 2020, at 22:14, Joel Alwen wrote: > > > > Hey people, > > > > Just a quick heads up that Daniel, Marta and I put in a PR with a new v= ersion of > > strong parent hash to prevent the attacks from the earlier thread. We t= ried to > > make it as minimal as we could to help with deniability while still pre= venting > > the attacks permitted by weak parent hashes. > > > > In a nutshell, when computing parent_hash at node v with parent p and s= ibling w > > we include > > - p's HPKE pubkey > > - p's parent_hash value and > > - HPKE pub keys in the resolution of w except for those belonging to le= aves > > unmerged at p. > > > > As a sanity check, notice that as long as p's keys remain the same one = can > > always recompute the same parent_hash value at v as was initially compu= ted by > > the member that set p's keys. (In other words, new members can verify t= hat the > > stored parent_hash values match whats in the tree.) In particular, that= 's coz as > > long as p's keys are unchanged so is the resolution of w. The only exce= ption are > > leaves being added as unmerged at w. But those leaves are also added as= unmerged > > at p so they are left out of the hash. > > > > As for deniability, at least parent_hash only binds HPKE keys and nothi= ng else > > (like, say, credentials or signatures). Its the best we were able to co= me up > > with for now... > > > > - jo=EBl > > > > _______________________________________________ > > 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 --_000_32c5c409abbc4cf79ecf74c9e2a2befainfethzch_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Raphael,


Thanks for explaining! Using "descendants" is definitely better for sec= urity, but also, as Hubert mentioned, less efficient.


Also we did understand =93resolution=94 the same way as you when we proposed th= e strong parent hash (sorry for the confusion). 


But we obviously really want to understand if/why using resolution is insecure= . Ultimately, the security property we care about is that privacy and authe= nticity of application messages holds. The Parent Hash mechanism helps us e= nsure this holds also for epochs in adversarially generated groups, as long as the adversary does not contr= ol any leaves in this epoch (i.e. does not know the signing key of the leaf= ). So to really see if your examples break security, it would be good to se= e if they let us violate this security goal.


To see why we believe the new parent hash notion (i.e. with resolutions) achi= eves this, let us first clarify what technical property about (even adversa= rially produced) ratchet trees we want from verifying parent hashes. It=92s= not that the adversary can=92t produce manipulated trees at all. It=92s that the only manipulations she is able t= o do will not let her produce a tree that violates the tree invariant. That= =92s because (in our model) when the tree invariant holds then we can show = that the epoch is secure.


So some manipulations *are* possible. They are just =93benign=94. For example= , suppose adversary A controls a leaf L with HPKE key pk in tree T (i.e. sh= e knows the signing key of L=92s owner). Then A can construct a new tree T= =92 identical to T but where leaf L has pk=92 !=3D pk (say, by performing a commit at leaf L to obtain T=92). But for th= is, in T=92 leaf L must still be controlled by A. We call this manipulation= =93benign=94 because even though A might now break privacy of application = messages in epoch with tree T=92 it doesnt violate our security goal because privacy is conditioned on A *not* controlling an= y leaves.


Conversely, one thing A can *not* do is the following. Say T=92 has a node V with HPKE= public key pk0 such that A knows corresponding sk0. Then for T=92 to pass = verification, it must contain a leaf controlled by A. This holds since for = T=92 to pass verification there must be a leaf in V=92s subtree with a signature covering a hash that includes pk0= . I.e. some leaf must =93attest=94 to having inserted pk0 into T=92. (Recal= l that in our model the adversary can=92t just leak sk0 alone. They must le= ak a full state of some client which also means leaking the client's signing key.)


So our question to you is the following. (Does this make sense? And) we=92re = not exactly sure what you have in mind when you say =93swapping out two lea= f nodes=94. But we think it would only be a problem if it is not benign. Is= this true for your attack? Could you expand a bit on what tree manipulation you have in mind?


Best,

Jo=EBl & Marta

From: MLS <mls-bounces= @ietf.org> on behalf of Hubert Chathi <hubertc@matrix.org>
Sent: Thursday, December 31, 2020 5:36:53 PM
To: mls@ietf.org
Subject: Re: [MLS] New Parent Hash
 
I think that if you use "descendants" as= you define it, then calculating the parent_hash will become O(n) all the t= ime, rather than O(log n) in the best-case, since the size of the descendan= ts list will be O(n).  I'm not sure if there's a good way to maintain O(log n) and still provide the desired security.
On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote:
> Hi Jo=EBl, Daniel and Marta,
>
> I just implemented the stronger parent hash scheme you proposed in the=
> way it is described in the spec now.
> The good news is that it is implementable, the bad news is that is doe= s
> not solve the problem you initially describe. Specifically, swapping <= br> > out two leaf nodes still goes undetected.
>
> I think it is due to a terminology conflict, but it would be great if =
> you could validate that assumption.
> In 7.4 you introduce the notion of =93original child resolution=94 as = " the
> array of HPKEPublicKey values of the nodes in the resolution of S=94. = The
> term =93resolution=94 is defined in 5.2. It is essentially a way of de= aling
> with blank nodes by substituting them with the first non-blank
> descendants you find when descending the subtree of a node.
> Here is my assumption: You probably thought the resolution would cover=
> all non-blank descendants of a node, not just the first non-blank
> descendant. In that case we would need another function that does that=
> (let=92s call it =93descendants=94).
>
> If we look at the example of 5.2:
>
>  - The resolution of node 3 is the list [A, CD, C]
>  - The descendants of node 3 is the list [A, CD, C, D]
>
>  - The resolution of node 5 is the list [CD]
>  - The descendants of node 5 is the list [CD, C, D] (we just need= to
> additionally filter out C, because it is an unmerged leaf of node 5) >
> Here is a code snippet of what the =93descendants=94 function would lo= ok
> like (sorry that it=92s Rust, not Python):
>
> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec<NodeIndex&g= t; {
>     if level(x) =3D=3D 0 {
>         vec![x]
>     } else {
>         let left_child =3D lef= t(x);
>         let right_child =3D ri= ght(x, size);
>         [
>            = ; descendants(left_child, size),
>            = ; vec![x],
>            = ; descendants(right_child, size),
>         ]
>         .concat()
>     }
> }
>
> There=92s a more efficient implementation of course, this is just to i= llustrate.
>
> In other words, the new =93original child resolution=94 of S would be = the
> subtree under S, but with filtered-out blank nodes and unmerged leaves=
> of S.
>
> If my assumption is correct, I=92ll follow up quickly with a PR since =
> this is currently a blocker for interop based on draft-11.
>
> Thanks
>
> Raphael
>
>
>
> > On 12. Nov 2020, at 22:14, Joel Alwen <jalwen@wickr.com> wr= ote:
> >
> > Hey people,
> >
> > Just a quick heads up that Daniel, Marta and I put in a PR with a= new version of
> > strong parent hash to prevent the attacks from the earlier thread= . We tried to
> > make it as minimal as we could to help with deniability while sti= ll preventing
> > the attacks permitted by weak parent hashes.
> >
> > In a nutshell, when computing parent_hash at node v with parent p= and sibling w
> > we include
> > - p's HPKE pubkey
> > - p's parent_hash value and
> > - HPKE pub keys in the resolution of w except for those belonging= to leaves
> > unmerged at p.
> >
> > As a sanity check, notice that as long as p's keys remain the sam= e one can
> > always recompute the same parent_hash value at v as was initially= computed by
> > the member that set p's keys. (In other words, new members can ve= rify that the
> > stored parent_hash values match whats in the tree.) In particular= , that's coz as
> > long as p's keys are unchanged so is the resolution of w. The onl= y exception are
> > leaves being added as unmerged at w. But those leaves are also ad= ded as unmerged
> > at p so they are left out of the hash.
> >
> > As for deniability, at least parent_hash only binds HPKE keys and= nothing else
> > (like, say, credentials or signatures). Its the best we were able= to come up
> > with for now...
> >
> > - jo=EBl
> >
> > _______________________________________________
> > 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
 --_000_32c5c409abbc4cf79ecf74c9e2a2befainfethzch_-- From nobody Fri Jan 1 08:30: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 539E33A00C9 for ; Fri, 1 Jan 2021 08:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-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 t6uxk51xz5IA for ; Fri, 1 Jan 2021 08:30:07 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 B24083A00C4 for ; Fri, 1 Jan 2021 08:30:06 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id b2so20553547edm.3 for ; Fri, 01 Jan 2021 08:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=N9lWimKbGL6Ge0++0JNitjq/p4klzffILe16FmV9wzo=; b=O1TCVghVj7CQk1ulwwf8AtdgYOMtaQngrQ0kIfzL91omqfaSY2gPbZNMcJ2gw7sSb4 vr2b2QODgkHRlLkZjCBeRNiv5NLf4RpSgI+zqspImIZGL+BLnb4wmpy/wqvvj6AIAsb0 ojbGKeHW7jbcOXrFTIrCaUo9Rg4PXr24UflMfpyxC5dljKs71fNS2UgRj42tt06/qy/J DJdvpNBl3gSaeM9hL84UQ89H/0PrDnSuvdvavruFaONfWe9CBje8WkoxN/5bM0+T9iKR 9feuZKrT64ziMWRETQeMHGRHlkxi3xBalguoXb1iAMHAJb1huclAHrSTRxwAuV+ABVxL n58w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N9lWimKbGL6Ge0++0JNitjq/p4klzffILe16FmV9wzo=; b=VeGH5HxDuh1GaZAOqwOfiZV5vHVJfcxmduaAYOqRqWMrFXZc3SSL6ePRvzdYcNxwm/ uniDzNeRO57j0uDZycjVxhlrl28/3qI0S2X0E4tXCBlNr9G2NOhDZdG2Q6tOhN18DeoX 8AvfFhQbvpsE2CaXkQ+pQcQVFLYNmU/X2XFx680GXPf8sRATCCGFpKdB0aYzIKFOY7H9 gJDdbseIYcjX03esRLEgfuS0TvKpmxQpUZjDIEkuoGvR+nohTdkBLSpmkaDrwL4tiEHb skhd555PZIRBCPqMgHmxTTJZe32ZKnx6Vw3kbQfQ4GwxyAPojS3kUU4ufo1WpqiEjE0z 6vjQ== X-Gm-Message-State: AOAM532H0+Hh3HjxWYFFfbOMotLsQxIOwsgj7iNKwNzZp2odUcHBwAlN k88oK9UxkBej5ClVEEEeGWQ5JQ== X-Google-Smtp-Source: ABdhPJzjUBG6i0Ern+haDvf9FiQG8+0xeDDdkPKjNpoi1Y/V2zX6OJ8lKs288VHouemiSK2adGmQ7g== X-Received: by 2002:a50:9dc9:: with SMTP id l9mr59715958edk.377.1609518604661; Fri, 01 Jan 2021 08:30:04 -0800 (PST) Received: from rmbp.fritz.box ([37.209.98.242]) by smtp.gmail.com with ESMTPSA id n13sm20963183ejr.93.2021.01.01.08.30.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2021 08:30:03 -0800 (PST) From: Raphael Robert Message-Id: <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_34649948-4F69-4AA3-99F4-09270D5D4E66" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Fri, 1 Jan 2021 17:30:02 +0100 In-Reply-To: <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> Cc: "mls@ietf.org" , Joel Alwen To: Mularczyk Marta References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [MLS] New Parent Hash 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, 01 Jan 2021 16:30:10 -0000 --Apple-Mail=_34649948-4F69-4AA3-99F4-09270D5D4E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the lengthy explanation! I=E2=80=99m glad we are on the same page regarding the definition of the = resolution. I think I understand where the misunderstanding is coming = from. Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D solution on the = ML (on Oct 23 2020) that was the following: "strong parent_hash" : Define parent_hash to include tree_hash (and = tree_hash to *not* include parent_hash). The tree_hash of a node covers all values in = the subtree rooted at that node (except the parent_hashes and signatures). = So basically something like this: - leaf.tree_hash :=3D H(leaf.data) - node.tree_hash :=3D H(node.data, node.lchild.tree_hash, = node.rchild.tree_hash) - root.parent_hash :=3D 0 - node.parent_hash :=3D H(node.parent.tree_hash, = node.parent.parent_hash). This definition did include the whole subtree and therefore I was = assuming that this would also end up in the spec change. As far as I now = understand, you went for a more lightweight approach where you say that = just using the resolution is enough, because pinning all nodes in the = subtree is not necessary and would only prevent =E2=80=9Cbenign=E2=80=9D = attacks. I guess I missed the part where you switched from one concept = to the other. What I discovered during implementation is that when you only use the = resolution approach and the tree has no blanks, you are not always able = to detect if the attacker has swapped two leaves. This might indeed just = be a benign attack in the sense that the tree invariant is not violated.=20= At this point I don=E2=80=99t have strong arguments for or against using = the resolution approach, I would have to think about it some more. Just = as a reminder for context, the original concept by Benjamin and Karthik = was =E2=80=9Cparent hash covers the tree hash=E2=80=9D. That=E2=80=99s = pretty much what you initially proposed, except that it also covered the = KeyPackage at the leaf level, not just the HPKE public key. My question right now would be: What is the benefit of the lightweight = resolution-based approach? If it=E2=80=99s just efficiency, we should = look at whether there=E2=80=99s really that much to gain. On efficiency: The parent hashes are verified in two instances: a) when a new member = joins the group and validates the public tree it received and b) when a = member receives a full Commit from another member. Re a): The spec now says "Moreover, when joining a group, new members = MUST authenticate each non-blank parent node P. A parent node P is = authenticated=E2=80=9D. This means the effort is linear to start with. = Depending on how you define the operation, it is even worse than linear. = Say the tree has n leaves and therefore 2n-1 nodes. For every node, we = need to iterate over at least a part of the subtree and collect public = keys that we then concatenate. We end up only hashing once per node, but = with a variable size payload. I think the cost of navigating the subtree = and collecting the keys is O(log n) for the =E2=80=9Cresolution approach = and O(n) for the =E2=80=9Cdescendants" approach and the cost of hashing = is linearly proportional to the size of the payload. If we assume that = hashing is the most expensive operation, the total cost would be O(n * = log n) for =E2=80=9Cresolution=E2=80=9D and O(n ^ 2) for = =E2=80=9Cdescendants".=20 Re b): It is very similar to a), except that we only have to iterate = over log n nodes of the direct path, not the whole tree. That means that = the total effort is O(log n * log n) for =E2=80=9Cresolution=E2=80=9D = and O(n * log n) for =E2=80=9Cdescendants=E2=80=9D. There=E2=80=99s clearly a difference in terms of efficiency between the = two approaches. That being said, we should keep in mind that for small = payloads, hashing is a lot faster than other cryptographic operations = like e.g. producing and verifying signatures. Since a new joiner needs = to also verify n signatures when joining a group, it could well be that = the effort of verifying the parent hashes is negligible compared to the = cost of verifying all signatures. In summary: I still don=E2=80=99t have strong arguments against the = =E2=80=9Cresolution=E2=80=9D approach, but I also have a feeling that = the efficiency differences are not dramatic either. Happy New Year and thanks! Raphael > On 1. Jan 2021, at 15:48, Mularczyk Marta = wrote: >=20 > Hi Raphael, >=20 > Thanks > for explaining! Using "descendants" is definitely better for = security, but also, as Hubert mentioned, less efficient. >=20 > Also > we did understand =E2=80=9Cresolution=E2=80=9D the same way as you = when we proposed the strong parent hash (sorry for the confusion).=20 >=20 > But > we obviously really want to understand if/why using resolution is = insecure. Ultimately, the security property we care about is that = privacy and authenticity of application messages holds. The Parent Hash = mechanism helps us ensure this holds also for epochs > in adversarially generated groups, as long as the adversary does not = control any leaves in this epoch (i.e. does not know the signing key of = the leaf). So to really see if your examples break security, it would be = good to see if they let us violate this security > goal. >=20 > To > see why we believe the new parent hash notion (i.e. with resolutions) = achieves this, let us first clarify what technical property about (even = adversarially produced) ratchet trees we want from verifying parent = hashes. It=E2=80=99s not that the adversary can=E2=80=99t produce > manipulated trees at all. It=E2=80=99s that the only manipulations = she is able to do will not let her produce a tree that violates the tree = invariant. That=E2=80=99s because (in our model) when the tree invariant = holds then we can show that the epoch is secure. >=20 > So > some manipulations *are* possible. They are just =E2=80=9Cbenign=E2=80=9D= . For example, suppose adversary A controls a leaf L with HPKE key pk in = tree T (i.e. she knows the signing key of L=E2=80=99s owner). Then A can = construct a new tree T=E2=80=99 identical to T but where leaf L has = pk=E2=80=99 > !=3D pk (say, by performing a commit at leaf L to obtain T=E2=80=99). = But for this, in T=E2=80=99 leaf L must still be controlled by A. We = call this manipulation =E2=80=9Cbenign=E2=80=9D because even though A = might now break privacy of application messages in epoch with tree T=E2=80= =99 it doesnt violate > our security goal because privacy is conditioned on A *not* = controlling any leaves. >=20 > Conversely, > one thing A can *not* do is the following. Say T=E2=80=99 has a node = V with HPKE public key pk0 such that A knows corresponding sk0. Then for = T=E2=80=99 to pass verification, it must contain a leaf controlled by A. = This holds since for T=E2=80=99 to pass verification there must be > a leaf in V=E2=80=99s subtree with a signature covering a hash that = includes pk0. I.e. some leaf must =E2=80=9Cattest=E2=80=9D to having = inserted pk0 into T=E2=80=99. (Recall that in our model the adversary = can=E2=80=99t just leak sk0 alone. They must leak a full state of some = client which also > means leaking the client's signing key.) >=20 > So > our question to you is the following. (Does this make sense? And) = we=E2=80=99re not exactly sure what you have in mind when you say = =E2=80=9Cswapping out two leaf nodes=E2=80=9D. But we think it would = only be a problem if it is not benign. Is this true for your attack? = Could you > expand a bit on what tree manipulation you have in mind? >=20 > Best, > Jo=C3=ABl > & Marta > From: MLS on behalf of Hubert Chathi = > Sent: Thursday, December 31, 2020 5:36:53 PM > To: mls@ietf.org > Subject: Re: [MLS] New Parent Hash > =20 > I think that if you use "descendants" as you define it, then = calculating the parent_hash will become O(n) all the time, rather than = O(log n) in the best-case, since the size of the descendants list will = be O(n). I'm not sure if there's a good way to maintain O(log n) and = still provide the desired security. >=20 > On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: > > Hi Jo=C3=ABl, Daniel and Marta, > >=20 > > I just implemented the stronger parent hash scheme you proposed in = the=20 > > way it is described in the spec now. > > The good news is that it is implementable, the bad news is that is = does=20 > > not solve the problem you initially describe. Specifically, swapping=20= > > out two leaf nodes still goes undetected. > >=20 > > I think it is due to a terminology conflict, but it would be great = if=20 > > you could validate that assumption. > > In 7.4 you introduce the notion of =E2=80=9Coriginal child = resolution=E2=80=9D as " the=20 > > array of HPKEPublicKey values of the nodes in the resolution of = S=E2=80=9D. The=20 > > term =E2=80=9Cresolution=E2=80=9D is defined in 5.2. It is = essentially a way of dealing=20 > > with blank nodes by substituting them with the first non-blank=20 > > descendants you find when descending the subtree of a node.=20 > > Here is my assumption: You probably thought the resolution would = cover=20 > > all non-blank descendants of a node, not just the first non-blank=20 > > descendant. In that case we would need another function that does = that=20 > > (let=E2=80=99s call it =E2=80=9Cdescendants=E2=80=9D). > >=20 > > If we look at the example of 5.2: > >=20 > > =16=16 - The resolution of node 3 is the list [A, CD, C] > > - The descendants of node 3 is the list [A, CD, C, D] > >=20 > > =16=16 - The resolution of node 5 is the list [CD] > > - The descendants of node 5 is the list [CD, C, D] (we just need to=20= > > additionally filter out C, because it is an unmerged leaf of node 5) > >=20 > > Here is a code snippet of what the =E2=80=9Cdescendants=E2=80=9D = function would look=20 > > like (sorry that it=E2=80=99s Rust, not Python): > >=20 > > fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { > > if level(x) =3D=3D 0 { > > vec![x] > > } else { > > let left_child =3D left(x); > > let right_child =3D right(x, size); > > [ > > descendants(left_child, size), > > vec![x], > > descendants(right_child, size), > > ] > > .concat() > > } > > } > >=20 > > There=E2=80=99s a more efficient implementation of course, this is = just to illustrate. > >=20 > > In other words, the new =E2=80=9Coriginal child resolution=E2=80=9D = of S would be the=20 > > subtree under S, but with filtered-out blank nodes and unmerged = leaves=20 > > of S. > >=20 > > If my assumption is correct, I=E2=80=99ll follow up quickly with a = PR since=20 > > this is currently a blocker for interop based on draft-11. > >=20 > > Thanks > >=20 > > Raphael > >=20 > >=20 > >=20 > > > On 12. Nov 2020, at 22:14, Joel Alwen wrote: > > >=20 > > > Hey people, > > >=20 > > > Just a quick heads up that Daniel, Marta and I put in a PR with a = new version of > > > strong parent hash to prevent the attacks from the earlier thread. = We tried to > > > make it as minimal as we could to help with deniability while = still preventing > > > the attacks permitted by weak parent hashes. > > >=20 > > > In a nutshell, when computing parent_hash at node v with parent p = and sibling w > > > we include > > > - p's HPKE pubkey > > > - p's parent_hash value and > > > - HPKE pub keys in the resolution of w except for those belonging = to leaves > > > unmerged at p. > > >=20 > > > As a sanity check, notice that as long as p's keys remain the same = one can > > > always recompute the same parent_hash value at v as was initially = computed by > > > the member that set p's keys. (In other words, new members can = verify that the > > > stored parent_hash values match whats in the tree.) In particular, = that's coz as > > > long as p's keys are unchanged so is the resolution of w. The only = exception are > > > leaves being added as unmerged at w. But those leaves are also = added as unmerged > > > at p so they are left out of the hash. > > >=20 > > > As for deniability, at least parent_hash only binds HPKE keys and = nothing else > > > (like, say, credentials or signatures). Its the best we were able = to come up > > > with for now... > > >=20 > > > - jo=C3=ABl > > >=20 > > > _______________________________________________ > > > MLS mailing list > > > MLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/mls = > >=20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls = > > >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_34649948-4F69-4AA3-99F4-09270D5D4E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the lengthy explanation!

I=E2=80=99m glad we are on the same = page regarding the definition of the resolution. I think I understand = where the misunderstanding is coming from.

Initially you proposed a =E2=80=9Cstrong = hash=E2=80=9D solution on the ML (on Oct 23 2020) that was the = following:

"strong parent_hash" : Define parent_hash to include = tree_hash (and tree_hash to
*not* include = parent_hash). The tree_hash of a node covers all values in the
subtree rooted at that node  (except the parent_hashes = and signatures). So
basically something like = this:
- leaf.tree_hash :=3D = H(leaf.data)
- node.tree_hash :=3D = H(node.data, node.lchild.tree_hash, node.rchild.tree_hash)
= - root.parent_hash :=3D 0
- = node.parent_hash :=3D H(node.parent.tree_hash, = node.parent.parent_hash).

This definition did = include the whole subtree and therefore I was assuming that this would = also end up in the spec change. As far as I now understand, you went for = a more lightweight approach where you say that just using the resolution = is enough, because pinning all nodes in the subtree is not necessary and = would only prevent =E2=80=9Cbenign=E2=80=9D attacks. I guess I missed = the part where you switched from one concept to the other.

What I discovered during = implementation is that when you only use the resolution approach and the = tree has no blanks, you are not always able to detect if the attacker = has swapped two leaves. This might indeed just be a benign attack in the = sense that the tree invariant is not violated. 

At this point I don=E2=80=99= t have strong arguments for or against using the resolution approach, I = would have to think about it some more. Just as a reminder for context, = the original concept by Benjamin and Karthik was =E2=80=9Cparent hash = covers the tree hash=E2=80=9D. That=E2=80=99s pretty much what you = initially proposed, except that it also covered the KeyPackage at the = leaf level, not just the HPKE public key.

My question right now would be: What is = the benefit of the lightweight resolution-based approach? If it=E2=80=99s = just efficiency, we should look at whether there=E2=80=99s really that = much to gain.

On= efficiency:
The parent hashes are verified in two = instances: a) when a new member joins the group and validates the public = tree it received and b) when a member receives a full Commit from = another member.

Re a): The spec now says "Moreover, when joining a group, new = members MUST authenticate each non-blank parent node P. A parent node P = is authenticated=E2=80=9D. This means the effort is linear to start = with. Depending on how you define the operation, it is even worse than = linear. Say the tree has n leaves and therefore 2n-1 nodes. For every = node, we need to iterate over at least a part of the subtree and collect = public keys that we then concatenate. We end up only hashing once per = node, but with a variable size payload. I think the cost of navigating = the subtree and collecting the keys is O(log n) for the =E2=80=9Cresolutio= n approach and O(n) for the =E2=80=9Cdescendants" approach and the cost = of hashing is linearly proportional to the size of the payload. If we = assume that hashing is the most expensive operation, the total cost = would be O(n * log n) for =E2=80=9Cresolution=E2=80=9D and O(n ^ 2) for = =E2=80=9Cdescendants". 

Re b): It is very similar to a), except = that we only have to iterate over log n nodes of the direct path, not = the whole tree. That means that the total effort is O(log n * log n) for = =E2=80=9Cresolution=E2=80=9D and O(n * log n) for = =E2=80=9Cdescendants=E2=80=9D.

There=E2=80=99s clearly a difference in = terms of efficiency between the two approaches. That being said, we = should keep in mind that for small payloads, hashing is a lot faster = than other cryptographic operations like e.g. producing and verifying = signatures. Since a new joiner needs to also verify n signatures when = joining a group, it could well be that the effort of verifying the = parent hashes is negligible compared to the cost of verifying all = signatures.

In = summary: I still don=E2=80=99t have strong arguments against the = =E2=80=9Cresolution=E2=80=9D approach, but I also have a feeling that = the efficiency differences are not dramatic either.

Happy New Year and = thanks!

Raphael

On 1. Jan 2021, at 15:48, = Mularczyk Marta <marta.mularczyk@inf.ethz.ch> wrote:

Hi Raphael,

Thanks for explaining! Using "descendants" is definitely better for security, = but also, as Hubert mentioned, less efficient.

Also we did understand =E2=80=9Cresolution=E2=80=9D the same way as you when = we proposed the strong parent hash (sorry for the = confusion). 

But we obviously really want to understand if/why using resolution is = insecure. Ultimately, the security property we care about is that = privacy and authenticity of application messages holds. The Parent Hash = mechanism helps us ensure this holds also for epochs in adversarially generated groups, as long as the adversary does not = control any leaves in this epoch (i.e. does not know the signing key of = the leaf). So to really see if your examples break security, it would be = good to see if they let us violate this security goal.

To see why we believe the new parent hash notion (i.e. with resolutions) = achieves this, let us first clarify what technical property about (even = adversarially produced) ratchet trees we want from verifying parent = hashes. It=E2=80=99s not that the adversary can=E2=80=99t produce manipulated trees at all. It=E2=80=99s that the only manipulations she = is able to do will not let her produce a tree that violates the tree = invariant. That=E2=80=99s because (in our model) when the tree invariant = holds then we can show that the epoch is secure.

So some manipulations *are* possible. They are just =E2=80=9Cbenign=E2=80=9D= . For example, suppose adversary A controls a leaf L with HPKE key pk in = tree T (i.e. she knows the signing key of L=E2=80=99s owner). Then A can = construct a new tree T=E2=80=99 identical to T but where leaf L has = pk=E2=80=99 !=3D pk (say, by performing a commit at leaf L to obtain T=E2=80=99). = But for this, in T=E2=80=99 leaf L must still be controlled by A. We = call this manipulation =E2=80=9Cbenign=E2=80=9D because even though A = might now break privacy of application messages in epoch with tree T=E2=80= =99 it doesnt violate our security goal because privacy is conditioned on A *not* controlling = any leaves.

Conversely, one thing A can *not* do is the following. Say T=E2=80=99 has a node V = with HPKE public key pk0 such that A knows corresponding sk0. Then for = T=E2=80=99 to pass verification, it must contain a leaf controlled by A. = This holds since for T=E2=80=99 to pass verification there must be a leaf in V=E2=80=99s subtree with a signature covering a hash that = includes pk0. I.e. some leaf must =E2=80=9Cattest=E2=80=9D to having = inserted pk0 into T=E2=80=99. (Recall that in our model the adversary = can=E2=80=99t just leak sk0 alone. They must leak a full state of some = client which also means leaking the client's signing key.)

So our question to you is the following. (Does this make sense? And) = we=E2=80=99re not exactly sure what you have in mind when you say = =E2=80=9Cswapping out two leaf nodes=E2=80=9D. But we think it would = only be a problem if it is not benign. Is this true for your attack? = Could you expand a bit on what tree manipulation you have in = mind?

Best,
Jo=C3=ABl & Marta

From: MLS= <mls-bounces@ietf.org> on behalf of Hubert Chathi = <hubertc@matrix.org>
Sent: Thursday, December 31, 2020 = 5:36:53 PM
To: mls@ietf.org
Subject: Re: [MLS] New Parent = Hash
 
I think that if you use = "descendants" as you define it, then calculating the parent_hash will = become O(n) all the time, rather than O(log n) in the best-case, since = the size of the descendants list will be O(n).  I'm not sure if = there's a good way to maintain O(log n) and still provide the desired = security.

On Thu, 31 Dec 2020, at 06:47, = Raphael Robert wrote:
> Hi Jo=C3=ABl, Daniel and = Marta,
> 
> I just = implemented the stronger parent hash scheme you proposed in the 
> way it = is described in the spec now.
> The good news is that = it is implementable, the bad news is that is does 
> not = solve the problem you initially describe. Specifically, swapping 
> out two = leaf nodes still goes undetected.
> 
> I think = it is due to a terminology conflict, but it would be great if 
> you = could validate that assumption.
> In 7.4 you introduce = the notion of =E2=80=9Coriginal child resolution=E2=80=9D as " the 
> array = of HPKEPublicKey values of the nodes in the resolution of S=E2=80=9D. = The 
> = term =E2=80=9Cresolution=E2=80=9D is defined in 5.2. It is essentially a = way of dealing 
> with blank nodes by substituting them with the first = non-blank 
> descendants you find when descending the subtree of a = node. 
> Here is my assumption: You probably thought the = resolution would cover 
> all = non-blank descendants of a node, not just the first non-blank 
> = descendant. In that case we would need another function that does = that 
>= (let=E2=80=99s call it =E2=80=9Cdescendants=E2=80=9D).
> 
> If we look at the example of 5.2:
> 
> =16=16 = - The resolution of node 3 is the list [A, CD, C]
> = - The descendants of node 3 is the list [A, CD, C, D]
> 
> =16=16 - The resolution of node 5 is the list [CD]
>  - The descendants of node 5 is the list [CD, C, D] = (we just need to 
> additionally filter out C, because it is an unmerged = leaf of node 5)
> 
> Here is = a code snippet of what the =E2=80=9Cdescendants=E2=80=9D function would = look 
>= like (sorry that it=E2=80=99s Rust, not Python):
> 
> fn = descendants(x: NodeIndex, size: LeafIndex) -> Vec<NodeIndex> = {
>     if level(x) =3D=3D 0 {
>         = vec![x]
>     } else {
>         let = left_child =3D left(x);
>         let = right_child =3D right(x, size);
>         [
>          = ;   descendants(left_child, size),
>          = ;   vec![x],
>          = ;   descendants(right_child, size),
>         ]
>         = .concat()
>     }
> = }
> > There=E2=80=99s a more efficient implementation of = course, this is just to illustrate.
> 
> In = other words, the new =E2=80=9Coriginal child resolution=E2=80=9D of S = would be the 
> subtree under S, but with filtered-out blank nodes and = unmerged leaves 
> of S.
> 
> If my = assumption is correct, I=E2=80=99ll follow up quickly with a PR = since 
> this is currently a blocker for interop based on = draft-11.
> 
> = Thanks
> 
> = Raphael
> 
> 
> 
> > On = 12. Nov 2020, at 22:14, Joel Alwen <jalwen@wickr.com> wrote:
> > 
> > = Hey people,
> > 
> > = Just a quick heads up that Daniel, Marta and I put in a PR with a new = version of
> > strong parent hash to prevent the = attacks from the earlier thread. We tried to
> > = make it as minimal as we could to help with deniability while still = preventing
> > the attacks permitted by weak parent = hashes.
> > 
> > In = a nutshell, when computing parent_hash at node v with parent p and = sibling w
> > we include
> > - = p's HPKE pubkey
> > - p's parent_hash value and
> > - HPKE pub keys in the resolution of w except for = those belonging to leaves
> > unmerged at p.
> > > > As a sanity check, notice that as long as p's keys = remain the same one can
> > always recompute the = same parent_hash value at v as was initially computed by
> > the member that set p's keys. (In other words, new = members can verify that the
> > stored parent_hash = values match whats in the tree.) In particular, that's coz as
> > long as p's keys are unchanged so is the resolution = of w. The only exception are
> > leaves being added = as unmerged at w. But those leaves are also added as unmerged
> > at p so they are left out of the hash.
> > > > As for deniability, at least parent_hash only = binds HPKE keys and nothing else
> > (like, say, = credentials or signatures). Its the best we were able to come up
> > with for now...
> > 
> > - = jo=C3=ABl
> > 
> > = _______________________________________________
> > = 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

= --Apple-Mail=_34649948-4F69-4AA3-99F4-09270D5D4E66-- From nobody Fri Jan 1 14:10: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 0338A3A0D3F for ; Fri, 1 Jan 2021 14:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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 xz2ZMpa55qt0 for ; Fri, 1 Jan 2021 14:10:07 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 DEEB83A0D3D for ; Fri, 1 Jan 2021 14:10:06 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id b73so21058547edf.13 for ; Fri, 01 Jan 2021 14:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TxdDzJJRfY0hek/f6dDc4buAAKITrcfG0w7bb/89C2o=; b=R9XI1u4fBqE0TgGjs6fJEew/07QOepyFLX6+5R9PFAiSt2h+cjC74d0mwsCrCZd0B4 tYe5JkWFxi1h7GLyvelmIapIayDCsP+d5Za4pdC3vF3AGKtSv12lfl2WdAE/m7EQ9XvA DlhX2MocrxJr1+MwgCAteHsguE+FsUEJ2pcm1uZKqVgUrYAvgYgpRdIIN4X7csf2Fut1 RJdl95PWXepU0HXFIcV7JVVg2SpNOAqiaULkwIAQhqSsGlrRe45dfV/XsgbU5V/6soya cOtV15NO4Pup461d2UEQGYFqUtXdSkdEES5z3uG7y8wZUtOg0EIDl/e16n/ADbKWI5Ql MkUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TxdDzJJRfY0hek/f6dDc4buAAKITrcfG0w7bb/89C2o=; b=Giao4zXwgyWo0hlhaL1oI04Z30faC8lg3annhLPYdUVDh6guHV0wVYuVHa2B4Hlib1 1ad+10TOwnNVwNE8RO6d3lzXvEFeRHBW/mVfujCf7LYw2YCukGrpt605WVqJX4QsRGVl fyeavRxFlskLmFt8By7vp2Rvbw1hDmF3GkN+mvPSW2HqWfe9hIFGRJKqLwXhb3MGaegL DWEEK8aQklsGkvpHF9e1ux6gi/NITyH+buwTbdyT7iCWmRgEdEeS+8Sa3e6do1PX7oFF Cq37dgEpfVXrUcx+AKa1994oNB3XJihuE/+PcZcJ2DWM8RB1b+/zFbuDKMxh6MS0oIMx 9tcA== X-Gm-Message-State: AOAM530qg/5GbQw/wZ+KHRcE0rWPz7CTQbdFMEWWZQ3Hafk5nsjpKgrQ VS+MipjlNz1I3SLy4Jr5Se5R0wiJKx8BVA== X-Google-Smtp-Source: ABdhPJxTosU2Eupfu57kTg58BxmVW90eNxV8yYZzxmBMgvKu1UD1K9DfgeO0HwfczQZgDvfJa5ZrgA== X-Received: by 2002:a05:6402:c83:: with SMTP id cm3mr60749334edb.189.1609539004542; Fri, 01 Jan 2021 14:10:04 -0800 (PST) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id h16sm21106142eji.110.2021.01.01.14.10.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jan 2021 14:10:03 -0800 (PST) To: Raphael Robert , Mularczyk Marta Cc: "mls@ietf.org" References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> From: Joel Alwen Message-ID: <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> Date: Fri, 1 Jan 2021 23:10:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] New Parent Hash 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, 01 Jan 2021 22:10:10 -0000 Servus Raphael, > Happy New Year Same to you! Here's hoping the new one will be a tad happier than the last. ;-) As for why "resolutions": The impetus to look for a new approach after our initial proposal came from a comment in your email on the Fri, 23 October 2020 18:23 UTC in the thread "Weak vs. Strong Tree Authentication". There you wrote: > Going for fully hashing the tree nodes as described locks down the whole > tree structure, making any reshuffling impossible. Maybe there is a more > lightweight approach that would yield the same result without “provid[ing] > irrefutable evidence that the signing key's owner was in a group with (at > least some) of the other members in the group”, but I can’t think of > anything right now. That was an intriguing challenge and got us thinking. The result is the current Parent Hash definition using resolutions. We realized that to buy wiggle room in not locking down as much of the tree (especially, not locking down other members identities into the hash) we could pay a "price" that actually doesn't harm the security we've been aiming for. Namely, we can allow the adversary some more tree manipulation but still only benign ones that dont actually allow her to break the security property we've been aiming for. In retrospect, a second reason to use resolutions is efficiency (though to fair, that was really a coincidence rather than an explicit goal of the redesign). Initially, we had been thinking of simply having parent hash include tree hash as in the Benjamin-Karthik (BK) proposal of days yore. But we realized that since then MLS had introduced Unmerged Leaves which meant that the tree hash of some nodes can change between when they are assigned their HPKE key and later when a new member wants to verify the parent hash of the node. In other words the BK approach was broken by unmerged leaves. So, to make the "include the whole subtree in parent hash" approach work, it seems new members would, for each node being verified, traverse the nodes full sub-tree so as to weed out those nodes that were added after the to-be-verified node got its HPKE key. (I believe this is the O(n) time that Hubert is referring too?) In contrast, the new version of parent hash (using resolutions) has the potential to be much faster; it requires hashing less data but also visiting less of the tree. E.g. when verifying near the root the difference can be as much as visiting order n nodes vs. visiting 1 node in the new construction. The more blanks & unmerged leaves in the tree the more the new construction collapses to the old one. But only in the most extreme case do they actually reach parity and the new approach is never slower than the old. Needless to say, we didn't implement this stuff though, let alone benchmark the 2 approaches so any hard data elucidating what the actual difference is would be very welcome. Still, the new approach can only be as fast or faster (but never slower) than the new one. Nor do I think it's any more complicated to define or implement. And from a security perspective they both let MLS meet our security definition. So regardless of how small the speed up is (and ignoring the locking in the tree discussion above) it's still not clear to me why we'd want to switch back. A meaningful attack that only works on the new but not old construction would be one very quick way of changing my mind though! :-) But, I believe such an attack would require either new adversarial capabilities and/or break a new security property we didn't consider. (For the adversaries & security we considered, there is no security loss with the new approach compared to the old one.) - Joël On 01/01/2021 17:30, Raphael Robert wrote: > Thanks for the lengthy explanation! > > I’m glad we are on the same page regarding the definition of the resolution. > I think I understand where the misunderstanding is coming from. > > Initially you proposed a “strong hash” solution on the ML (on Oct 23 2020) > that was the following: > > "strong parent_hash" : Define parent_hash to include tree_hash (and > tree_hash to *not* include parent_hash). The tree_hash of a node covers all > values in the subtree rooted at that node (except the parent_hashes and > signatures). So basically something like this: - leaf.tree_hash := > H(leaf.data) - node.tree_hash := H(node.data, node.lchild.tree_hash, > node.rchild.tree_hash) - root.parent_hash := 0 - node.parent_hash := > H(node.parent.tree_hash, node.parent.parent_hash). > > This definition did include the whole subtree and therefore I was assuming > that this would also end up in the spec change. As far as I now understand, > you went for a more lightweight approach where you say that just using the > resolution is enough, because pinning all nodes in the subtree is not > necessary and would only prevent “benign” attacks. I guess I missed the part > where you switched from one concept to the other. > > What I discovered during implementation is that when you only use the > resolution approach and the tree has no blanks, you are not always able to > detect if the attacker has swapped two leaves. This might indeed just be a > benign attack in the sense that the tree invariant is not violated. > > At this point I don’t have strong arguments for or against using the > resolution approach, I would have to think about it some more. Just as a > reminder for context, the original concept by Benjamin and Karthik was > “parent hash covers the tree hash”. That’s pretty much what you initially > proposed, except that it also covered the KeyPackage at the leaf level, not > just the HPKE public key. > > My question right now would be: What is the benefit of the lightweight > resolution-based approach? If it’s just efficiency, we should look at whether > there’s really that much to gain. > > On efficiency: The parent hashes are verified in two instances: a) when a > new member joins the group and validates the public tree it received and b) > when a member receives a full Commit from another member. > > Re a): The spec now says "Moreover, when joining a group, new members MUST > authenticate each non-blank parent node P. A parent node P is authenticated”. > This means the effort is linear to start with. Depending on how you define > the operation, it is even worse than linear. Say the tree has n leaves and > therefore 2n-1 nodes. For every node, we need to iterate over at least a part > of the subtree and collect public keys that we then concatenate. We end up > only hashing once per node, but with a variable size payload. I think the > cost of navigating the subtree and collecting the keys is O(log n) for the > “resolution approach and O(n) for the “descendants" approach and the cost of > hashing is linearly proportional to the size of the payload. If we assume > that hashing is the most expensive operation, the total cost would be O(n * > log n) for “resolution” and O(n ^ 2) for “descendants". > > Re b): It is very similar to a), except that we only have to iterate over > log n nodes of the direct path, not the whole tree. That means that the > total effort is O(log n * log n) for “resolution” and O(n * log n) for > “descendants”. > > There’s clearly a difference in terms of efficiency between the two > approaches. That being said, we should keep in mind that for small payloads, > hashing is a lot faster than other cryptographic operations like e.g. > producing and verifying signatures. Since a new joiner needs to also verify > n signatures when joining a group, it could well be that the effort of > verifying the parent hashes is negligible compared to the cost of verifying > all signatures. > > In summary: I still don’t have strong arguments against the “resolution” > approach, but I also have a feeling that the efficiency differences are not > dramatic either. > > Happy New Year and thanks! > > Raphael > >> On 1. Jan 2021, at 15:48, Mularczyk Marta > > wrote: >> >> Hi Raphael, >> >> Thanks for explaining! Using "descendants" is definitely better for >> security, but also, as Hubert mentioned, less efficient. >> >> Also we did understand “resolution” the same way as you when we proposed >> the strong parent hash (sorry for the confusion). >> >> But we obviously really want to understand if/why using resolution is >> insecure. Ultimately, the security property we care about is that privacy >> and authenticity of application messages holds. The Parent Hash mechanism >> helps us ensure this holds also for epochs in adversarially generated >> groups, as long as the adversary does not control any leaves in this epoch >> (i.e. does not know the signing key of the leaf). So to really see if your >> examples break security, it would be good to see if they let us violate >> this security goal. >> >> To see why we believe the new parent hash notion (i.e. with resolutions) >> achieves this, let us first clarify what technical property about (even >> adversarially produced) ratchet trees we want from verifying parent hashes. >> It’s not that the adversary can’t produce manipulated trees at all. It’s >> that the only manipulations she is able to do will not let her produce a >> tree that violates the tree invariant. That’s because (in our model) when >> the tree invariant holds then we can show that the epoch is secure. >> >> So some manipulations *are* possible. They are just “benign”. For example, >> suppose adversary A controls a leaf L with HPKE key pk in tree T (i.e. she >> knows the signing key of L’s owner). Then A can construct a new tree T’ >> identical to T but where leaf L has pk’ != pk (say, by performing a commit >> at leaf L to obtain T’). But for this, in T’ leaf L must still be >> controlled by A. We call this manipulation “benign” because even though A >> might now break privacy of application messages in epoch with tree T’ it >> doesnt violate our security goal because privacy is conditioned on A *not* >> controlling any leaves. >> >> Conversely, one thing A can *not* do is the following. Say T’ has a node V >> with HPKE public key pk0 such that A knows corresponding sk0. Then for T’ >> to pass verification, it must contain a leaf controlled by A. This holds >> since for T’ to pass verification there must be a leaf in V’s subtree with >> a signature covering a hash that includes pk0. I.e. some leaf must >> “attest” to having inserted pk0 into T’. (Recall that in our model the >> adversary can’t just leak sk0 alone. They must leak a full state of some >> client which also means leaking the client's signing key.) >> >> So our question to you is the following. (Does this make sense? And) we’re >> not exactly sure what you have in mind when you say “swapping out two leaf >> nodes”. But we think it would only be a problem if it is not benign. Is >> this true for your attack? Could you expand a bit on what tree >> manipulation you have in mind? >> >> Best, Joël& Marta >> >> -------------------------------------------------------------------------------- >> >> >> *From:* MLS > on behalf of >> Hubert Chathi > *Sent:* >> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org >> *Subject:* Re: [MLS] New Parent Hash >> >> I think that if you use "descendants" as you define it, then calculating >> the parent_hash will become O(n) all the time, rather than O(log n) in the >> best-case, since the size of the descendants list will be O(n). I'm not >> sure if there's a good way to maintain O(log n) and still provide the >> desired security. >> >> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: >>> Hi Joël, Daniel and Marta, >>> >>> I just implemented the stronger parent hash scheme you proposed in the >>> way it is described in the spec now. The good news is that it is >>> implementable, the bad news is that is does not solve the problem you >>> initially describe. Specifically, swapping out two leaf nodes still goes >>> undetected. >>> >>> I think it is due to a terminology conflict, but it would be great if >>> you could validate that assumption. In 7.4 you introduce the notion of >>> “original child resolution” as " the array of HPKEPublicKey values of >>> the nodes in the resolution of S”. The term “resolution” is defined in >>> 5.2. It is essentially a way of dealing with blank nodes by substituting >>> them with the first non-blank descendants you find when descending the >>> subtree of a node. Here is my assumption: You probably thought the >>> resolution would cover all non-blank descendants of a node, not just the >>> first non-blank descendant. In that case we would need another function >>> that does that (let’s call it “descendants”). >>> >>> If we look at the example of 5.2: >>> >>>  - The resolution of node 3 is the list [A, CD, C] - The descendants >>> of node 3 is the list [A, CD, C, D] >>> >>>  - The resolution of node 5 is the list [CD] - The descendants of node >>> 5 is the list [CD, C, D] (we just need to additionally filter out C, >>> because it is an unmerged leaf of node 5) >>> >>> Here is a code snippet of what the “descendants” function would look >>> like (sorry that it’s Rust, not Python): >>> >>> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { if >>> level(x) == 0 { vec![x] } else { let left_child = left(x); let >>> right_child = right(x, size); [ descendants(left_child, size), vec![x], >>> descendants(right_child, size), ] .concat() } } >>> >>> There’s a more efficient implementation of course, this is just to >>> illustrate. >>> >>> In other words, the new “original child resolution” of S would be the >>> subtree under S, but with filtered-out blank nodes and unmerged leaves >>> of S. >>> >>> If my assumption is correct, I’ll follow up quickly with a PR since this >>> is currently a blocker for interop based on draft-11. >>> >>> Thanks >>> >>> Raphael >>> >>> >>> >>>> On 12. Nov 2020, at 22:14, Joel Alwen >>> > wrote: >>>> >>>> Hey people, >>>> >>>> Just a quick heads up that Daniel, Marta and I put in a PR with a new >>>> version of strong parent hash to prevent the attacks from the earlier >>>> thread. We tried to make it as minimal as we could to help with >>>> deniability while still preventing the attacks permitted by weak >>>> parent hashes. >>>> >>>> In a nutshell, when computing parent_hash at node v with parent p and >>>> sibling w we include - p's HPKE pubkey - p's parent_hash value and - >>>> HPKE pub keys in the resolution of w except for those belonging to >>>> leaves unmerged at p. >>>> >>>> As a sanity check, notice that as long as p's keys remain the same one >>>> can always recompute the same parent_hash value at v as was initially >>>> computed by the member that set p's keys. (In other words, new members >>>> can verify that the stored parent_hash values match whats in the >>>> tree.) In particular, that's coz as long as p's keys are unchanged so >>>> is the resolution of w. The only exception are leaves being added as >>>> unmerged at w. But those leaves are also added as unmerged at p so they >>>> are left out of the hash. >>>> >>>> As for deniability, at least parent_hash only binds HPKE keys and >>>> nothing else (like, say, credentials or signatures). Its the best we >>>> were able to come up with for now... >>>> >>>> - joël >>>> >>>> _______________________________________________ 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 Sat Jan 2 09:03:28 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 78C803A0C4F for ; Sat, 2 Jan 2021 09:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_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=wire-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 XsDRLZiYsHFV for ; Sat, 2 Jan 2021 09:03:22 -0800 (PST) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 518B83A0C49 for ; Sat, 2 Jan 2021 09:03:21 -0800 (PST) Received: by mail-ej1-x62b.google.com with SMTP id d17so30836418ejy.9 for ; Sat, 02 Jan 2021 09:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lPgbQGqPPQw+VVFZslO3+BAg9UmnfxDZKHdBxE23NvA=; b=AIHGYyzaNtevsiCgvtGnzP37qq+ugjLNgpm69Qb3D9/6AaK7H7fjWpbKWN2jwRQoUo J98sMiIxgLPkEjKeGTFWUlstXrV/UvuTYQfPT1ECs37HqOLqBixti3565HpXFG/uAdVy PgRr+aCjXaCdnYygOodopxPBqHYBG9OIlTprG24chbWiKmAqfGVPd7iJzLVk5dP6Vvu1 +5OzzNt6RjsXYTnNxsbnpCtjYibAIiD90uvB4VTg8HhJ+/Mv5XfeOyzGBECe8z+zDm0K eGHGP2iqwbWS6k/SyHQfiomN1zMjximQFzaccOTnO13vqXooDmNJ62VZbejcNQODwLwA H1EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lPgbQGqPPQw+VVFZslO3+BAg9UmnfxDZKHdBxE23NvA=; b=OjEhY8T0yqVTuVGgyDZAff1Js5PgMMTHqT9c6hTbVgMo1zAuw384roccruvZsG01ex 7OwdjVqJj27IBCmgJoDyL6KQePq4mD1WWONj+E47WHp2tsRQeYe2r0pAnuIDHCFFN8qB p+Q/Y+7vemJ2OxwJCyJUJp1IB1fFjUXFXv2RqMIJBpsFfu1J59Dn0B/MAPyQ88WIzNx8 atVzH4NxI3z8S484P6mEBozuo1uTA3RWBONE9djlBgv9kNDgIm8Hl6PFgqbhtA2IArC0 g3V9GmElZmFGWD5ZTJb1Rc0D6q2mXYCo/f2ihSU0C7iTZNVmcZF2gmz8Gfp2isGb/5iA zF5g== X-Gm-Message-State: AOAM53362atszK3+9LKaun57V3W0+IUJydpMEaHgWZJXAbP4U+ikbGtS m/afMY4B9enrdobZZeLDh8wYMg== X-Google-Smtp-Source: ABdhPJzqOgV2fZIqSaa1aJt1OKY9mUDY+75etb2MQ96CIEXgba6mNbr2LcdM6fOYtLHEettoOUOZkQ== X-Received: by 2002:a17:906:710b:: with SMTP id x11mr63594494ejj.433.1609606999350; Sat, 02 Jan 2021 09:03:19 -0800 (PST) Received: from [192.168.178.21] ([37.209.98.242]) by smtp.gmail.com with ESMTPSA id ck27sm41683038edb.13.2021.01.02.09.03.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Jan 2021 09:03:18 -0800 (PST) From: Raphael Robert Message-Id: <4135BB5E-4C35-4EFF-91B6-1615C3560F1E@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F6418678-4B60-4861-9A61-36A84FB4689F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Sat, 2 Jan 2021 18:02:45 +0100 In-Reply-To: <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> Cc: Mularczyk Marta , "mls@ietf.org" To: Joel Alwen References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [MLS] New Parent Hash 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: Sat, 02 Jan 2021 17:03:26 -0000 --Apple-Mail=_F6418678-4B60-4861-9A61-36A84FB4689F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Marta and Jo=C3=ABl for the explanation! That was the delta that = was missing for my understanding and it=E2=80=99s definitely good to = have that on list. > On 1. Jan 2021, at 23:10, Joel Alwen wrote: >=20 > Servus Raphael, >=20 >> Happy New Year >=20 > Same to you! Here's hoping the new one will be a tad happier than the = last. ;-) >=20 > As for why "resolutions": The impetus to look for a new approach after = our > initial proposal came from a comment in your email on the Fri, 23 = October 2020 > 18:23 UTC in the thread "Weak vs. Strong Tree Authentication". There = you wrote: >=20 >> Going for fully hashing the tree nodes as described locks down the = whole >> tree structure, making any reshuffling impossible. Maybe there is a = more=20 >> lightweight approach that would yield the same result without = =E2=80=9Cprovid[ing]=20 >> irrefutable evidence that the signing key's owner was in a group with = (at=20 >> least some) of the other members in the group=E2=80=9D, but I can=E2=80= =99t think of >> anything right now. >=20 > That was an intriguing challenge and got us thinking. The result is = the current > Parent Hash definition using resolutions. We realized that to buy = wiggle room in > not locking down as much of the tree (especially, not locking down = other members > identities into the hash) we could pay a "price" that actually doesn't = harm the > security we've been aiming for. Namely, we can allow the adversary = some more > tree manipulation but still only benign ones that dont actually allow = her to > break the security property we've been aiming for. Just for context, what I had in mind was something that was not as = detrimental to the membership deniability. I think in that respect both = the =E2=80=9Cresolution=E2=80=9D and the =E2=80=9Cdescendants=E2=80=9D = approach are equivalent. That being said, this looks quite elegant! > In retrospect, a second reason to use resolutions is efficiency = (though to fair, > that was really a coincidence rather than an explicit goal of the = redesign). > Initially, we had been thinking of simply having parent hash include = tree hash > as in the Benjamin-Karthik (BK) proposal of days yore. But we realized = that > since then MLS had introduced Unmerged Leaves which meant that the = tree hash of > some nodes can change between when they are assigned their HPKE key = and later > when a new member wants to verify the parent hash of the node. In = other words > the BK approach was broken by unmerged leaves. So, to make the = "include the > whole subtree in parent hash" approach work, it seems new members = would, for > each node being verified, traverse the nodes full sub-tree so as to = weed out > those nodes that were added after the to-be-verified node got its HPKE = key. (I > believe this is the O(n) time that Hubert is referring too?) In = contrast, the > new version of parent hash (using resolutions) has the potential to be = much > faster; it requires hashing less data but also visiting less of the = tree. E.g. > when verifying near the root the difference can be as much as visiting = order n > nodes vs. visiting 1 node in the new construction. >=20 > The more blanks & unmerged leaves in the tree the more the new = construction > collapses to the old one. But only in the most extreme case do they = actually > reach parity and the new approach is never slower than the old. >=20 > Needless to say, we didn't implement this stuff though, let alone = benchmark the > 2 approaches so any hard data elucidating what the actual difference = is would be > very welcome. Still, the new approach can only be as fast or faster = (but never > slower) than the new one. Nor do I think it's any more complicated to = define or > implement. And from a security perspective they both let MLS meet our = security > definition. So regardless of how small the speed up is (and ignoring = the locking > in the tree discussion above) it's still not clear to me why we'd want = to switch > back. >=20 > A meaningful attack that only works on the new but not old = construction would be > one very quick way of changing my mind though! :-) But, I believe such = an attack > would require either new adversarial capabilities and/or break a new = security > property we didn't consider. (For the adversaries & security we = considered, > there is no security loss with the new approach compared to the old = one.) I think we are now fully aligned on the definitions and the performance = implications and now that we have better documentation we can continue = with the interim effort. I=E2=80=99d however like to leave it as an open question whether we = shouldn=E2=80=99t reconsider locking down entire subtrees as a = security-in-depth measure if we can convince ourselves the performance = toll is not too high.=20 For example, I=E2=80=99m wondering if there isn=E2=80=99t a clever way = to combine the tree hash and the parent hash. The tree hash has to be = calculated for every epoch change anyway and it=E2=80=99s always in = O(n). Thanks Raphael >=20 > - Jo=C3=ABl >=20 > On 01/01/2021 17:30, Raphael Robert wrote: >> Thanks for the lengthy explanation! >>=20 >> I=E2=80=99m glad we are on the same page regarding the definition of = the resolution.=20 >> I think I understand where the misunderstanding is coming from. >>=20 >> Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D solution on = the ML (on Oct 23 2020)=20 >> that was the following: >>=20 >> "strong parent_hash" : Define parent_hash to include tree_hash (and >> tree_hash to *not* include parent_hash). The tree_hash of a node = covers all >> values in the subtree rooted at that node (except the parent_hashes = and >> signatures). So basically something like this: - leaf.tree_hash :=3D >> H(leaf.data) - node.tree_hash :=3D H(node.data, = node.lchild.tree_hash, >> node.rchild.tree_hash) - root.parent_hash :=3D 0 - node.parent_hash = :=3D >> H(node.parent.tree_hash, node.parent.parent_hash). >>=20 >> This definition did include the whole subtree and therefore I was = assuming=20 >> that this would also end up in the spec change. As far as I now = understand,=20 >> you went for a more lightweight approach where you say that just = using the=20 >> resolution is enough, because pinning all nodes in the subtree is not=20= >> necessary and would only prevent =E2=80=9Cbenign=E2=80=9D attacks. I = guess I missed the part=20 >> where you switched from one concept to the other. >>=20 >> What I discovered during implementation is that when you only use the=20= >> resolution approach and the tree has no blanks, you are not always = able to=20 >> detect if the attacker has swapped two leaves. This might indeed just = be a=20 >> benign attack in the sense that the tree invariant is not violated. >>=20 >> At this point I don=E2=80=99t have strong arguments for or against = using the=20 >> resolution approach, I would have to think about it some more. Just = as a=20 >> reminder for context, the original concept by Benjamin and Karthik = was=20 >> =E2=80=9Cparent hash covers the tree hash=E2=80=9D. That=E2=80=99s = pretty much what you initially=20 >> proposed, except that it also covered the KeyPackage at the leaf = level, not=20 >> just the HPKE public key. >>=20 >> My question right now would be: What is the benefit of the = lightweight=20 >> resolution-based approach? If it=E2=80=99s just efficiency, we should = look at whether >> there=E2=80=99s really that much to gain. >>=20 >> On efficiency: The parent hashes are verified in two instances: a) = when a >> new member joins the group and validates the public tree it received = and b) >> when a member receives a full Commit from another member. >>=20 >> Re a): The spec now says "Moreover, when joining a group, new members = MUST=20 >> authenticate each non-blank parent node P. A parent node P is = authenticated=E2=80=9D. >> This means the effort is linear to start with. Depending on how you = define >> the operation, it is even worse than linear. Say the tree has n = leaves and >> therefore 2n-1 nodes. For every node, we need to iterate over at = least a part >> of the subtree and collect public keys that we then concatenate. We = end up >> only hashing once per node, but with a variable size payload. I think = the >> cost of navigating the subtree and collecting the keys is O(log n) = for the >> =E2=80=9Cresolution approach and O(n) for the =E2=80=9Cdescendants" = approach and the cost of >> hashing is linearly proportional to the size of the payload. If we = assume >> that hashing is the most expensive operation, the total cost would be = O(n * >> log n) for =E2=80=9Cresolution=E2=80=9D and O(n ^ 2) for = =E2=80=9Cdescendants". >>=20 >> Re b): It is very similar to a), except that we only have to iterate = over >> log n nodes of the direct path, not the whole tree. That means that = the >> total effort is O(log n * log n) for =E2=80=9Cresolution=E2=80=9D and = O(n * log n) for=20 >> =E2=80=9Cdescendants=E2=80=9D. >>=20 >> There=E2=80=99s clearly a difference in terms of efficiency between = the two=20 >> approaches. That being said, we should keep in mind that for small = payloads,=20 >> hashing is a lot faster than other cryptographic operations like e.g.=20= >> producing and verifying signatures. Since a new joiner needs to also = verify >> n signatures when joining a group, it could well be that the effort = of=20 >> verifying the parent hashes is negligible compared to the cost of = verifying=20 >> all signatures. >>=20 >> In summary: I still don=E2=80=99t have strong arguments against the = =E2=80=9Cresolution=E2=80=9D=20 >> approach, but I also have a feeling that the efficiency differences = are not=20 >> dramatic either. >>=20 >> Happy New Year and thanks! >>=20 >> Raphael >>=20 >>> On 1. Jan 2021, at 15:48, Mularczyk Marta = >> >> wrote: >>>=20 >>> Hi Raphael, >>>=20 >>> Thanks for explaining! Using "descendants" is definitely better for=20= >>> security, but also, as Hubert mentioned, less efficient. >>>=20 >>> Also we did understand =E2=80=9Cresolution=E2=80=9D the same way as = you when we proposed=20 >>> the strong parent hash (sorry for the confusion). >>>=20 >>> But we obviously really want to understand if/why using resolution = is=20 >>> insecure. Ultimately, the security property we care about is that = privacy=20 >>> and authenticity of application messages holds. The Parent Hash = mechanism=20 >>> helps us ensure this holds also for epochs in adversarially = generated=20 >>> groups, as long as the adversary does not control any leaves in this = epoch=20 >>> (i.e. does not know the signing key of the leaf). So to really see = if your=20 >>> examples break security, it would be good to see if they let us = violate=20 >>> this security goal. >>>=20 >>> To see why we believe the new parent hash notion (i.e. with = resolutions)=20 >>> achieves this, let us first clarify what technical property about = (even=20 >>> adversarially produced) ratchet trees we want from verifying parent = hashes. >>> It=E2=80=99s not that the adversary can=E2=80=99t produce = manipulated trees at all. It=E2=80=99s >>> that the only manipulations she is able to do will not let her = produce a >>> tree that violates the tree invariant. That=E2=80=99s because (in = our model) when=20 >>> the tree invariant holds then we can show that the epoch is secure. >>>=20 >>> So some manipulations *are* possible. They are just =E2=80=9Cbenign=E2= =80=9D. For example, >>> suppose adversary A controls a leaf L with HPKE key pk in tree T = (i.e. she >>> knows the signing key of L=E2=80=99s owner). Then A can construct a = new tree T=E2=80=99=20 >>> identical to T but where leaf L has pk=E2=80=99 !=3D pk (say, by = performing a commit=20 >>> at leaf L to obtain T=E2=80=99). But for this, in T=E2=80=99 leaf L = must still be=20 >>> controlled by A. We call this manipulation =E2=80=9Cbenign=E2=80=9D = because even though A=20 >>> might now break privacy of application messages in epoch with tree = T=E2=80=99 it=20 >>> doesnt violate our security goal because privacy is conditioned on A = *not*=20 >>> controlling any leaves. >>>=20 >>> Conversely, one thing A can *not* do is the following. Say T=E2=80=99 = has a node V >>> with HPKE public key pk0 such that A knows corresponding sk0. Then = for T=E2=80=99=20 >>> to pass verification, it must contain a leaf controlled by A. This = holds=20 >>> since for T=E2=80=99 to pass verification there must be a leaf in = V=E2=80=99s subtree with=20 >>> a signature covering a hash that includes pk0. I.e. some leaf must >>> =E2=80=9Cattest=E2=80=9D to having inserted pk0 into T=E2=80=99. = (Recall that in our model the >>> adversary can=E2=80=99t just leak sk0 alone. They must leak a full = state of some >>> client which also means leaking the client's signing key.) >>>=20 >>> So our question to you is the following. (Does this make sense? And) = we=E2=80=99re=20 >>> not exactly sure what you have in mind when you say =E2=80=9Cswapping = out two leaf=20 >>> nodes=E2=80=9D. But we think it would only be a problem if it is not = benign. Is=20 >>> this true for your attack? Could you expand a bit on what tree >>> manipulation you have in mind? >>>=20 >>> Best, Jo=C3=ABl& Marta >>>=20 >>> = --------------------------------------------------------------------------= ------ >>>=20 >>>=20 >>>=20 > *From:* MLS = >> on behalf = of >>> Hubert Chathi = >> *Sent:*=20 >>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org = =20 >>> > *Subject:* Re: [MLS] New = Parent Hash >>>=20 >>> I think that if you use "descendants" as you define it, then = calculating=20 >>> the parent_hash will become O(n) all the time, rather than O(log n) = in the >>> best-case, since the size of the descendants list will be O(n). I'm = not=20 >>> sure if there's a good way to maintain O(log n) and still provide = the=20 >>> desired security. >>>=20 >>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: >>>> Hi Jo=C3=ABl, Daniel and Marta, >>>>=20 >>>> I just implemented the stronger parent hash scheme you proposed in = the=20 >>>> way it is described in the spec now. The good news is that it is=20 >>>> implementable, the bad news is that is does not solve the problem = you=20 >>>> initially describe. Specifically, swapping out two leaf nodes still = goes=20 >>>> undetected. >>>>=20 >>>> I think it is due to a terminology conflict, but it would be great = if >>>> you could validate that assumption. In 7.4 you introduce the notion = of=20 >>>> =E2=80=9Coriginal child resolution=E2=80=9D as " the array of = HPKEPublicKey values of >>>> the nodes in the resolution of S=E2=80=9D. The term = =E2=80=9Cresolution=E2=80=9D is defined in >>>> 5.2. It is essentially a way of dealing with blank nodes by = substituting >>>> them with the first non-blank descendants you find when descending = the >>>> subtree of a node. Here is my assumption: You probably thought the >>>> resolution would cover all non-blank descendants of a node, not = just the >>>> first non-blank descendant. In that case we would need another = function >>>> that does that (let=E2=80=99s call it =E2=80=9Cdescendants=E2=80=9D).= >>>>=20 >>>> If we look at the example of 5.2: >>>>=20 >>>> =16=16 - The resolution of node 3 is the list [A, CD, C] - The = descendants >>>> of node 3 is the list [A, CD, C, D] >>>>=20 >>>> =16=16 - The resolution of node 5 is the list [CD] - The = descendants of node=20 >>>> 5 is the list [CD, C, D] (we just need to additionally filter out = C,=20 >>>> because it is an unmerged leaf of node 5) >>>>=20 >>>> Here is a code snippet of what the =E2=80=9Cdescendants=E2=80=9D = function would look >>>> like (sorry that it=E2=80=99s Rust, not Python): >>>>=20 >>>> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { = if=20 >>>> level(x) =3D=3D 0 { vec![x] } else { let left_child =3D left(x); = let=20 >>>> right_child =3D right(x, size); [ descendants(left_child, size), = vec![x],=20 >>>> descendants(right_child, size), ] .concat() } } >>>>=20 >>>> There=E2=80=99s a more efficient implementation of course, this is = just to=20 >>>> illustrate. >>>>=20 >>>> In other words, the new =E2=80=9Coriginal child resolution=E2=80=9D = of S would be the=20 >>>> subtree under S, but with filtered-out blank nodes and unmerged = leaves >>>> of S. >>>>=20 >>>> If my assumption is correct, I=E2=80=99ll follow up quickly with a = PR since this=20 >>>> is currently a blocker for interop based on draft-11. >>>>=20 >>>> Thanks >>>>=20 >>>> Raphael >>>>=20 >>>>=20 >>>>=20 >>>>> On 12. Nov 2020, at 22:14, Joel Alwen =20 >>>>> >> wrote: >>>>>=20 >>>>> Hey people, >>>>>=20 >>>>> Just a quick heads up that Daniel, Marta and I put in a PR with a = new=20 >>>>> version of strong parent hash to prevent the attacks from the = earlier=20 >>>>> thread. We tried to make it as minimal as we could to help with=20 >>>>> deniability while still preventing the attacks permitted by weak >>>>> parent hashes. >>>>>=20 >>>>> In a nutshell, when computing parent_hash at node v with parent p = and=20 >>>>> sibling w we include - p's HPKE pubkey - p's parent_hash value and = -=20 >>>>> HPKE pub keys in the resolution of w except for those belonging to=20= >>>>> leaves unmerged at p. >>>>>=20 >>>>> As a sanity check, notice that as long as p's keys remain the same = one=20 >>>>> can always recompute the same parent_hash value at v as was = initially=20 >>>>> computed by the member that set p's keys. (In other words, new = members=20 >>>>> can verify that the stored parent_hash values match whats in the >>>>> tree.) In particular, that's coz as long as p's keys are unchanged = so >>>>> is the resolution of w. The only exception are leaves being added = as >>>>> unmerged at w. But those leaves are also added as unmerged at p so = they >>>>> are left out of the hash. >>>>>=20 >>>>> As for deniability, at least parent_hash only binds HPKE keys and=20= >>>>> nothing else (like, say, credentials or signatures). Its the best = we=20 >>>>> were able to come up with for now... >>>>>=20 >>>>> - jo=C3=ABl >>>>>=20 >>>>> _______________________________________________ MLS mailing list=20= >>>>> MLS@ietf.org >=20 >>>>> https://www.ietf.org/mailman/listinfo/mls = >>> > >>>>=20 >>>> _______________________________________________ MLS mailing list=20 >>>> MLS@ietf.org >=20 >>>> https://www.ietf.org/mailman/listinfo/mls = >>> > >>>>=20 >>>=20 >>> _______________________________________________ MLS mailing list=20 >>> MLS@ietf.org >=20 >>> https://www.ietf.org/mailman/listinfo/mls = =20 >>> > --Apple-Mail=_F6418678-4B60-4861-9A61-36A84FB4689F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Marta and Jo=C3=ABl for the explanation! That was the = delta that was missing for my understanding and it=E2=80=99s definitely = good to have that on list.

On 1. Jan 2021, at 23:10, Joel = Alwen <jalwen@wickr.com> wrote:

Servus Raphael,

Happy New Year

Same to you! Here's hoping the new one will be a tad happier = than the last. ;-)

As for why "resolutions": The impetus to look for a new = approach after our
initial proposal came from a comment in your email on the = Fri, 23 October 2020
18:23 UTC in the thread "Weak vs. Strong Tree = Authentication". There you wrote:

Going for fully hashing the tree = nodes as described locks down the whole
tree structure, = making any reshuffling impossible. Maybe there is a more 
lightweight = approach that would yield the same result without =E2=80=9Cprovid[ing] 
irrefutable = evidence that the signing key's owner was in a group with (at 
least some) = of the other members in the group=E2=80=9D, but I can=E2=80=99t think = of
anything right now.

That was an intriguing challenge = and got us thinking. The result is the current
Parent Hash definition using = resolutions. We realized that to buy wiggle room in
not locking down as much of the = tree (especially, not locking down other members
identities into the hash) we = could pay a "price" that actually doesn't harm the
security we've been aiming for. = Namely, we can allow the adversary some more
tree manipulation but still only = benign ones that dont actually allow her to
break the security property = we've been aiming for.

Just for context, what I had in mind was something that = was not as detrimental to the membership deniability. I think in that = respect both the =E2=80=9Cresolution=E2=80=9D and the =E2=80=9Cdescendants= =E2=80=9D approach are equivalent.
That being said, this looks = quite elegant!

In retrospect, a second reason to use resolutions is = efficiency (though to fair,
that was really a coincidence rather than an explicit goal of = the redesign).
Initially, we had been thinking of simply having parent hash = include tree hash
as in the Benjamin-Karthik (BK) proposal of days yore. But we = realized that
since then = MLS had introduced Unmerged Leaves which meant that the tree hash = of
some nodes = can change between when they are assigned their HPKE key and = later
when a new = member wants to verify the parent hash of the node. In other = words
the BK = approach was broken by unmerged leaves. So, to make the "include = the
whole subtree = in parent hash" approach work, it seems new members would, for
each node being verified, = traverse the nodes full sub-tree so as to weed out
those nodes that were added = after the to-be-verified node got its HPKE key. (I
believe this is the O(n) time = that Hubert is referring too?) In contrast, the
new version of parent hash = (using resolutions) has the potential to be much
faster; it requires hashing less = data but also visiting less of the tree. E.g.
when verifying near the root the = difference can be as much as visiting order n
nodes vs. visiting 1 node in the = new construction.

The more blanks & unmerged leaves in the tree the more = the new construction
collapses to the old one. But only in the most extreme case = do they actually
reach parity and the new approach is never slower than the = old.

Needless to = say, we didn't implement this stuff though, let alone benchmark = the
2 approaches = so any hard data elucidating what the actual difference is would = be
very welcome. = Still, the new approach can only be as fast or faster (but = never
slower) than = the new one. Nor do I think it's any more complicated to define = or
implement. = And from a security perspective they both let MLS meet our = security
definition. = So regardless of how small the speed up is (and ignoring the = locking
in the tree = discussion above) it's still not clear to me why we'd want to = switch
back.

A meaningful attack that only works on the new but not old = construction would be
one very quick way of changing my mind though! :-) But, I = believe such an attack
would require either new adversarial capabilities and/or = break a new security
property we didn't consider. (For the adversaries & = security we considered,
there is no security loss with the new approach compared to = the old one.)

I = think we are now fully aligned on the definitions and the performance = implications and now that we have better documentation we can continue = with the interim effort.

I=E2=80=99d = however like to leave it as an open question whether we shouldn=E2=80=99t = reconsider locking down entire subtrees as a security-in-depth measure = if we can convince ourselves the performance toll is not too = high. 
For example, I=E2=80=99m wondering if there = isn=E2=80=99t a clever way to combine the tree hash and the parent hash. = The tree hash has to be calculated for every epoch change anyway and = it=E2=80=99s always in O(n).

Thanks

Raphael


- Jo=C3=ABl

On 01/01/2021 17:30, Raphael Robert wrote:
Thanks = for the lengthy explanation!

I=E2=80=99m = glad we are on the same page regarding the definition of the = resolution. 
I think I understand where the misunderstanding is coming = from.

Initially you proposed a =E2=80=9Cstron= g hash=E2=80=9D solution on the ML (on Oct 23 2020) 
that was the = following:

"strong parent_hash" : Define = parent_hash to include tree_hash (and
tree_hash to *not* = include parent_hash). The tree_hash of a node covers all
values in the subtree rooted at that node  (except the = parent_hashes and
signatures). So basically something like = this: - leaf.tree_hash :=3D
H(leaf.data) - node.tree_hash = :=3D H(node.data, node.lchild.tree_hash,
node.rchild.tree_hash) - root.parent_hash :=3D 0 - = node.parent_hash :=3D
H(node.parent.tree_hash, = node.parent.parent_hash).

This definition = did include the whole subtree and therefore I was assuming 
that this = would also end up in the spec change. As far as I now understand, 
you went for = a more lightweight approach where you say that just using the 
resolution = is enough, because pinning all nodes in the subtree is not 
necessary = and would only prevent =E2=80=9Cbenign=E2=80=9D attacks. I guess I = missed the part 
where you switched from one concept to the other.

What I discovered during implementation is = that when you only use the 
resolution = approach and the tree has no blanks, you are not always able to 
detect if = the attacker has swapped two leaves. This might indeed just be a 
benign = attack in the sense that the tree invariant is not violated.

At this point I don=E2=80=99t have strong = arguments for or against using the 
resolution = approach, I would have to think about it some more. Just as a 
reminder for = context, the original concept by Benjamin and Karthik was 
=E2=80=9Cparen= t hash covers the tree hash=E2=80=9D. That=E2=80=99s pretty much what = you initially 
proposed, except that it also covered the KeyPackage at the = leaf level, not 
just the HPKE public key.

My = question right now would be: What is the benefit of the lightweight 
resolution-based approach? If it=E2=80=99s just efficiency, = we should look at whether
there=E2=80=99s really that much = to gain.

On efficiency: The parent hashes = are verified in two instances: a) when a
new member joins = the group and validates the public tree it received and b)
when a member receives a full Commit from another member.

Re a): The spec now says "Moreover, when = joining a group, new members MUST 
authenticate = each non-blank parent node P. A parent node P is authenticated=E2=80=9D.This means the effort is linear to start with. Depending on = how you define
the operation, it is even worse than = linear. Say the tree has n leaves and
therefore 2n-1 = nodes. For every node, we need to iterate over at least a part
of the subtree and collect public keys that we then = concatenate. We end up
only hashing once per node, but = with a variable size payload. I think the
cost of = navigating the subtree and collecting the keys is O(log n) for the
=E2=80=9Cresolution approach and O(n) for the =E2=80=9Cdescenda= nts" approach and the cost of
hashing is linearly = proportional to the size of the payload. If we assume
that = hashing is the most expensive operation, the total cost would be O(n = *
log n) for =E2=80=9Cresolution=E2=80=9D and O(n ^ 2) for = =E2=80=9Cdescendants".

Re b): It is very = similar to a), except that we only have to iterate over
log = n nodes of the direct path, not the whole tree. That means that the
total effort is O(log n * log n) for =E2=80=9Cresolution=E2=80=9D= and O(n * log n) for 
=E2=80=9Cdescendants=E2=80=9D.

There=E2=80=99s clearly a difference in terms of efficiency = between the two 
approaches. That being said, we should keep in mind that for = small payloads, 
hashing is a lot faster than other cryptographic operations = like e.g. 
producing and verifying signatures. Since a new joiner needs = to also verify
n signatures when joining a group, it could = well be that the effort of 
verifying = the parent hashes is negligible compared to the cost of verifying 
all = signatures.

In summary: I still don=E2=80=99t= have strong arguments against the =E2=80=9Cresolution=E2=80=9D 
approach, = but I also have a feeling that the efficiency differences are not 
dramatic = either.

Happy New Year and thanks!

Raphael

On 1. Jan 2021, at 15:48, Mularczyk Marta = <marta.mularczyk@inf.ethz.ch 
<mailto:marta.mularczyk@inf.ethz.ch>> wrote:

Hi Raphael,

Thanks = for explaining! Using "descendants" is definitely better for 
security, = but also, as Hubert mentioned, less efficient.

Also we did understand =E2=80=9Cresolution=E2=80=9D the same = way as you when we proposed 
the strong = parent hash (sorry for the confusion).

But = we obviously really want to understand if/why using resolution is 
insecure. = Ultimately, the security property we care about is that privacy 
and = authenticity of application messages holds. The Parent Hash = mechanism 
helps us ensure this holds also for epochs in adversarially = generated 
groups, as long as the adversary does not control any leaves = in this epoch 
(i.e. does not know the signing key of the leaf). So to = really see if your 
examples break security, it would be good to see if they let = us violate 
this security goal.

To see why = we believe the new parent hash notion (i.e. with resolutions) 
achieves = this, let us first clarify what technical property about (even 
adversarially = produced) ratchet trees we want from verifying parent hashes.
It=E2=80=99s not that the adversary can=E2=80=99t produce = manipulated trees at all. It=E2=80=99s
that the only = manipulations she is able to do will not let her produce a
tree that violates the tree invariant. That=E2=80=99s because = (in our model) when 
the tree invariant holds then we can show that the epoch is = secure.

So some manipulations *are* = possible. They are just =E2=80=9Cbenign=E2=80=9D. For example,
suppose adversary A controls a leaf L with HPKE key pk in = tree T (i.e. she
knows the signing key of L=E2=80=99s = owner). Then A can construct a new tree T=E2=80=99 
identical to = T but where leaf L has pk=E2=80=99 !=3D pk (say, by performing a = commit 
at= leaf L to obtain T=E2=80=99). But for this, in T=E2=80=99 leaf L must = still be 
controlled by A. We call this manipulation =E2=80=9Cbenign=E2=80= =9D because even though A 
might now = break privacy of application messages in epoch with tree T=E2=80=99 = it 
doesnt= violate our security goal because privacy is conditioned on A = *not* 
controlling any leaves.

Conversely, one thing A can *not* do is the following. Say = T=E2=80=99 has a node V
with HPKE public key pk0 such that = A knows corresponding sk0. Then for T=E2=80=99 
to pass = verification, it must contain a leaf controlled by A. This holds 
since for = T=E2=80=99 to pass verification there must be a leaf in V=E2=80=99s = subtree with 
a signature covering a hash that includes pk0. I.e. some leaf = must
=E2=80=9Cattest=E2=80=9D to having inserted pk0 into = T=E2=80=99. (Recall that in our model the
adversary = can=E2=80=99t just leak sk0 alone. They must leak a full state of = some
client which also means leaking the client's signing = key.)

So our question to you is the = following. (Does this make sense? And) we=E2=80=99re 
not exactly = sure what you have in mind when you say =E2=80=9Cswapping out two = leaf 
nodes=E2=80=9D. But we think it would only be a problem if it = is not benign. Is 
this true for your attack? Could you expand a bit on what = tree
manipulation you have in mind?

Best, Jo=C3=ABl& Marta

---------------------------------------------------------------= -----------------



*From:* MLS <mls-bounces@ietf.org <mailto:mls-bounces@ietf.org>> on behalf of
Hubert Chathi <hubertc@matrix.org <mailto:hubertc@matrix.org>> *Sent:* 
Thursday, = December 31, 2020 5:36:53 PM *To:* mls@ietf.org 
<mailto:mls@ietf.org> = *Subject:* Re: [MLS] New Parent Hash

I = think that if you use "descendants" as you define it, then = calculating 
the parent_hash will become O(n) all the time, rather than = O(log n) in the
best-case, since the size of the = descendants list will be O(n).  I'm not 
sure if = there's a good way to maintain O(log n) and still provide the 
desired = security.

On Thu, 31 Dec 2020, at 06:47, = Raphael Robert wrote:
Hi Jo=C3=ABl, Daniel and Marta,

I = just implemented the stronger parent hash scheme you proposed in = the 
way = it is described in the spec now. The good news is that it is 
implementable,= the bad news is that is does not solve the problem you 
initially = describe. Specifically, swapping out two leaf nodes still goes 
undetected.
I think it is due to a terminology conflict, = but it would be great if
you could validate that = assumption. In 7.4 you introduce the notion of 
=E2=80=9Corigi= nal child resolution=E2=80=9D as " the array of HPKEPublicKey values = of
the nodes in the resolution of S=E2=80=9D. The term = =E2=80=9Cresolution=E2=80=9D is defined in
5.2. It is = essentially a way of dealing with blank nodes by substituting
them with the first non-blank descendants you find when = descending the
subtree of a node. Here is my assumption: = You probably thought the
resolution would cover all = non-blank descendants of a node, not just the
first = non-blank descendant. In that case we would need another function
that does that (let=E2=80=99s call it =E2=80=9Cdescendants=E2=80= =9D).

If we look at the example of 5.2:

=16=16 - The resolution of node 3 is the list = [A, CD, C] - The descendants
of node 3 is the list [A, CD, = C, D]

=16=16 - The resolution of node 5 is = the list [CD] - The descendants of node 
5 is the = list [CD, C, D] (we just need to additionally filter out C, 
because it = is an unmerged leaf of node 5)

Here is a = code snippet of what the =E2=80=9Cdescendants=E2=80=9D function would = look
like (sorry that it=E2=80=99s Rust, not Python):

fn descendants(x: NodeIndex, size: LeafIndex) = -> Vec<NodeIndex> { if 
level(x) =3D=3D= 0 { vec![x] } else { let left_child =3D left(x); let 
right_child = =3D right(x, size); [ descendants(left_child, size), vec![x], 
descendants(right_child, size), ] .concat() } }

There=E2=80=99s a more efficient = implementation of course, this is just to 
illustrate.
In other words, the new =E2=80=9Coriginal = child resolution=E2=80=9D of S would be the 
subtree = under S, but with filtered-out blank nodes and unmerged leaves
of S.

If my assumption is = correct, I=E2=80=99ll follow up quickly with a PR since this 
is currently = a blocker for interop based on draft-11.

Thanks

Raphael



On 12. Nov 2020, at 22:14, Joel Alwen <jalwen@wickr.com 
<mailto:jalwen@wickr.com>> wrote:

Hey people,

Just a quick heads = up that Daniel, Marta and I put in a PR with a new 
version of = strong parent hash to prevent the attacks from the earlier 
thread. We = tried to make it as minimal as we could to help with 
deniability = while still preventing the attacks permitted by weak
parent = hashes.

In a nutshell, when computing = parent_hash at node v with parent p and 
sibling w we = include - p's HPKE pubkey - p's parent_hash value and - 
HPKE pub = keys in the resolution of w except for those belonging to 
leaves = unmerged at p.

As a sanity check, notice = that as long as p's keys remain the same one 
can always = recompute the same parent_hash value at v as was initially 
computed by = the member that set p's keys. (In other words, new members 
can verify = that the stored parent_hash values match whats in the
tree.)= In particular, that's coz as long as p's keys are unchanged so
is the resolution of w. The only exception are leaves being = added as
unmerged at w. But those leaves are also added as = unmerged at p so they
are left out of the hash.

As for deniability, at least parent_hash only = binds HPKE keys and 
nothing else (like, say, credentials or signatures). Its the = best we 
were able to come up with for now...

- jo=C3=ABl

_______________________________________________ MLS mailing = list 
MLS@ietf.org <mailto:MLS@ietf.org> 
https://www.ietf.org/mailman/listinfo/mls
<https://www.ietf.org/mailman/listinfo/mls>

_______________________________________________ MLS mailing = list 
MLS@ietf.org <mailto:MLS@ietf.org> 
https://www.ietf.org/mailman/listinfo/mls
<https://www.ietf.org/mailman/listinfo/mls>


_______________________________________________ MLS mailing = list 
MLS@ietf.org <mailto:MLS@ietf.org> 
https://www.ietf.org/mailman/listinfo/mls 
<https://www.ietf.org/mailman/listinfo/mls>
<= /blockquote>

= --Apple-Mail=_F6418678-4B60-4861-9A61-36A84FB4689F-- From nobody Sun Jan 3 00:06:05 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 165183A0AF7 for ; Sun, 3 Jan 2021 00:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[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, 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=fpFy07a2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dKXTosnp 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 7GP3FfSnVMy4 for ; Sun, 3 Jan 2021 00:05:58 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541823A0AF8 for ; Sun, 3 Jan 2021 00:05:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 11A355EB for ; Sun, 3 Jan 2021 02:56:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 03 Jan 2021 02:56:25 -0500 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= fm1; bh=HJJawOZ5GdT7yW3Ti1T93J7OLrZCJ3MWKQZdifNMBCk=; b=fpFy07a2 moUpYUPksQes1393KMJ7Lyo1KiLwrj8597uWOpYLcfLLr4lQ+gCeLB//5GhuVaur 2zUevzaYEx0oo2UY+14kW3z9bc5YnsGEYVqx+SrIIfutsx3IVwhfByl04yGhyjT2 2wDcRp2S0nLENwRIDQUo/0vnANQMf7zP4E2K+1a6bRatbEbFNQmPYuv9eVuDpCvW 7ZHGYj6guHuodLM+vI8FJZF4DiFttYh10/tr1YlQfL6VnL5KjF0pP2i9sDSzXmPN FCGzmHri9h15LKJhB/7OQhIBSSdnXieW2AfkUo43KuytC5ZCGi5X1aqWJ3NQmMec px+A0OpC7+8ghw== 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=fm1; bh=HJJawOZ5GdT7yW3Ti1T93J7OLrZCJ 3MWKQZdifNMBCk=; b=dKXTosnpJ+p9T+PzfJHd3IkwzG+EK9iSf4k6KYt9G/VgL iPYinGDHepAKVF4zrC8BadOR5mHob2NDeTnm0MfemCU7cJxB7vWc0qkrmbxVZ9xU P02idhuumyLPL9FvjybGVjKcVvctpzY5Rz3R33sIGAaMxttlXWbRPGrpEua4DDn1 EXfpuoDNsLNj1RNYwb5NT6bymhuDZzjlGEsDwaSr3lWgV3t7LkBI7RkWeoD3ZQkR uo1zsuY9TnIXbC+7zQjbKjBQ5CpsxbBOYKCCcKnJjjsyYBXWceK8SNXkAUV8aIsd URhQbSDlDYuVrvaFM6iwus8yiuJlan+A6sYFrU+6g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeftddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvdehgedrkeegrd ejfeenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az50-739.internal.cloudapp.net (unknown [52.254.84.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 852311080057 for ; Sun, 3 Jan 2021 02:56:24 -0500 (EST) Content-Type: multipart/alternative; boundary="===============5408482157168970159==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210103075624.852311080057@mailuser.nyi.internal> Date: Sun, 3 Jan 2021 02:56:24 -0500 (EST) 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, 03 Jan 2021 08:06:00 -0000 --===============5408482157168970159== 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: - Use the GroupContext to derive the joiner_secret (by ericcornelissen) https://github.com/mlswg/mls-protocol/pull/453=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============5408482157168970159== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 03, 2021

Pull requests

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

1 pull requests submitted:

Repositories tracked by this digest:

--===============5408482157168970159==-- From nobody Mon Jan 4 05:33:36 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 0B7BD3A0D14 for ; Mon, 4 Jan 2021 05:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.262, 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 AITvY1fnv7R4 for ; Mon, 4 Jan 2021 05:33:32 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 0EAAB3A0D13 for ; Mon, 4 Jan 2021 05:33:32 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id lt17so36794918ejb.3 for ; Mon, 04 Jan 2021 05:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SyHXCV+LQMf+ZHwkuLlRdSLrEC3GEmw0vuspeTPsYF8=; b=gWVcle3xCUvQ8ZMo5wI98/tdTxlq0r4Ye/mvR/QcUNGLi2rAZBkUzDiutI6HYQ/eKU SjxzxBymJCssKfcYoY3O1AbYWojd2ZB5IkUGoB8Vy4FCibN1U5XA+uus73E4koTuTUyb u8Og19PYMwbn+COYGkQfgGJ3ZUogWUXoW4yx68AiOsbDx9EGvej51MkHHqMWdozTlGoK +7rDwkvX+jXgm6Hm8f/pRfzRSZK+PmYlG3IybQvlIzpkQ3zrLcK78VpWQmYtX+cSTRyQ MP/NHtcS6SEXryZBtpFxQQ8Qfg/6I9w5jJ2ToQQr3243R1g/Nd92Me9tq0pqhCLB558i mYQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SyHXCV+LQMf+ZHwkuLlRdSLrEC3GEmw0vuspeTPsYF8=; b=NaiJYZ8pHd7nqR1eVj5RT78Y/2EmDJ5ZIr/0qQE/P0doInjS8yTm1iL5mA3ekxBkWz 8Ulm6OSNA6lD4fJhRpXcmKw2QDJ0ElB4mC8Wya0oUsOudM6vvX2xulbLLrNLzl6pTO7L IuBAyXtdtpd0yGcZzpxiPlbQuViSwI5GcZ9BxphZ8muZUcMfFVhHqocKoHGOfvXpE6+0 wwLzAaydFw3nEXzeZ37Y8GYz3nU8fgMr1NGREEEivjrTptcdZcXGyFQ2JyRnOPYYJ5Mn M+GeWa7zUddvhHGkmECXebcb6IjFEt8olJYWoaUot3fzeAGNDIkhKHMEPTUrqQGwi2iM dxPg== X-Gm-Message-State: AOAM531xXfqW+Jh12CzDJwjEDbtgsr08NQrOL9/jAxTaRWa7+zgCc4Pf KskYfjphzejX0R/zO5zQ/N3Ckg/GBYU5gQ== X-Google-Smtp-Source: ABdhPJwKueN8PGw3jMiFgri/BXiWfY+KRwZcgwE3E9y6yTvIpC0AZeMY+Em0iwZGXxzXWq2bt34Ufw== X-Received: by 2002:a17:906:a00a:: with SMTP id p10mr67633357ejy.312.1609767209716; Mon, 04 Jan 2021 05:33:29 -0800 (PST) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id n2sm23601215ejj.24.2021.01.04.05.33.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jan 2021 05:33:29 -0800 (PST) To: Raphael Robert Cc: Mularczyk Marta , "mls@ietf.org" References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> <4135BB5E-4C35-4EFF-91B6-1615C3560F1E@wire.com> From: Joel Alwen Message-ID: <54f2ca71-89e1-1ca3-b783-2ad774564127@wickr.com> Date: Mon, 4 Jan 2021 14:33:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <4135BB5E-4C35-4EFF-91B6-1615C3560F1E@wire.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] New Parent Hash 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, 04 Jan 2021 13:33:35 -0000 On 02/01/2021 18:02, Raphael Robert wrote: > Thanks Marta and Joël for the explanation! That was the delta that was missing > for my understanding and it’s definitely good to have that on list. Yes, good call. FYI there's a MUCH more complete discussion of the security properties of MLS we've analyzed, the adversarial and communication models we used and the actual security proof in eprint/2020/1327. (We'll be updating it soon to include our security analysis of the new parent hash scheme.) > Just for context, what I had in mind was something that was not as detrimental > to the membership deniability. I think in that respect both the “resolution” > and the “descendants” approach are equivalent. I agree that the resolution method is hardly deniable in any formal sense I know of. Switching from signing (hashes of) the entire list of certs of everyone in a subtree to "only" signing HPKE pubkeys in the resolution does feel like a pretty superficial improvement for deniability. :-/ To me, the advantage of using resolutions is the simplicity & efficiency compared to using descendants. TBH, for deniability I think there's a whole family of impossibilities waiting to be formalized here (like the one in Thm. 1 of eprint/2019/1153). Asynchronous + authenticated + (strongly?!) deniable + no global trusted setup + communication complexity sub-linear in the group size? Seems very hard to me (in my non-expert opinion). My guess is that real compromises in the model / design goals need to be made to get (even just weak) deniability. > I’d however like to leave it as an open question whether we shouldn’t reconsider locking down entire subtrees as a security-in-depth measure if we can convince ourselves the performance toll is not too high. If we can do it, without paying too much of an efficiency price, then by all means why not? I'm still curious what we'd be getting though. E.g. what needs to happen so that hashing in descendants is secure but using only the resolution isn't? > The tree hash has to be calculated for every epoch change anyway and it’s always in O(n). For my own edification: I would have thought computing the new tree hash at the root after a commit to p proposals requires at most ~ O(p*log(n)) actual hash calls + as many memory lookups no? Let L_p be the leaves modified by the proposals. The root of any subtree with no leaf in L_p has the same tree hash as before the commit. So by storing tree hashes as we compute them we can replace computing unchanged subtree tree hashes with a lookup. What am I missing here? - Joël >> On 1. Jan 2021, at 23:10, Joel Alwen > > wrote: >> >> Servus Raphael, >> >>> Happy New Year >> >> Same to you! Here's hoping the new one will be a tad happier than the last. ;-) >> >> As for why "resolutions": The impetus to look for a new approach after our >> initial proposal came from a comment in your email on the Fri, 23 October 2020 >> 18:23 UTC in the thread "Weak vs. Strong Tree Authentication". There you wrote: >> >>> Going for fully hashing the tree nodes as described locks down the whole >>> tree structure, making any reshuffling impossible. Maybe there is a more  >>> lightweight approach that would yield the same result without “provid[ing]  >>> irrefutable evidence that the signing key's owner was in a group with (at  >>> least some) of the other members in the group”, but I can’t think of >>> anything right now. >> >> That was an intriguing challenge and got us thinking. The result is the current >> Parent Hash definition using resolutions. We realized that to buy wiggle room in >> not locking down as much of the tree (especially, not locking down other members >> identities into the hash) we could pay a "price" that actually doesn't harm the >> security we've been aiming for. Namely, we can allow the adversary some more >> tree manipulation but still only benign ones that dont actually allow her to >> break the security property we've been aiming for. > > Just for context, what I had in mind was something that was not as detrimental > to the membership deniability. I think in that respect both the “resolution” and > the “descendants” approach are equivalent. > That being said, this looks quite elegant! > >> In retrospect, a second reason to use resolutions is efficiency (though to fair, >> that was really a coincidence rather than an explicit goal of the redesign). >> Initially, we had been thinking of simply having parent hash include tree hash >> as in the Benjamin-Karthik (BK) proposal of days yore. But we realized that >> since then MLS had introduced Unmerged Leaves which meant that the tree hash of >> some nodes can change between when they are assigned their HPKE key and later >> when a new member wants to verify the parent hash of the node. In other words >> the BK approach was broken by unmerged leaves. So, to make the "include the >> whole subtree in parent hash" approach work, it seems new members would, for >> each node being verified, traverse the nodes full sub-tree so as to weed out >> those nodes that were added after the to-be-verified node got its HPKE key. (I >> believe this is the O(n) time that Hubert is referring too?) In contrast, the >> new version of parent hash (using resolutions) has the potential to be much >> faster; it requires hashing less data but also visiting less of the tree. E.g. >> when verifying near the root the difference can be as much as visiting order n >> nodes vs. visiting 1 node in the new construction. >> >> The more blanks & unmerged leaves in the tree the more the new construction >> collapses to the old one. But only in the most extreme case do they actually >> reach parity and the new approach is never slower than the old. >> >> Needless to say, we didn't implement this stuff though, let alone benchmark the >> 2 approaches so any hard data elucidating what the actual difference is would be >> very welcome. Still, the new approach can only be as fast or faster (but never >> slower) than the new one. Nor do I think it's any more complicated to define or >> implement. And from a security perspective they both let MLS meet our security >> definition. So regardless of how small the speed up is (and ignoring the locking >> in the tree discussion above) it's still not clear to me why we'd want to switch >> back. >> >> A meaningful attack that only works on the new but not old construction would be >> one very quick way of changing my mind though! :-) But, I believe such an attack >> would require either new adversarial capabilities and/or break a new security >> property we didn't consider. (For the adversaries & security we considered, >> there is no security loss with the new approach compared to the old one.) > > I think we are now fully aligned on the definitions and the performance > implications and now that we have better documentation we can continue with the > interim effort. > > I’d however like to leave it as an open question whether we shouldn’t reconsider > locking down entire subtrees as a security-in-depth measure if we can convince > ourselves the performance toll is not too high.  > For example, I’m wondering if there isn’t a clever way to combine the tree hash > and the parent hash. The tree hash has to be calculated for every epoch change > anyway and it’s always in O(n). > > Thanks > > Raphael > >> >> - Joël >> >> On 01/01/2021 17:30, Raphael Robert wrote: >>> Thanks for the lengthy explanation! >>> >>> I’m glad we are on the same page regarding the definition of the resolution.  >>> I think I understand where the misunderstanding is coming from. >>> >>> Initially you proposed a “strong hash” solution on the ML (on Oct 23 2020)  >>> that was the following: >>> >>> "strong parent_hash" : Define parent_hash to include tree_hash (and >>> tree_hash to *not* include parent_hash). The tree_hash of a node covers all >>> values in the subtree rooted at that node  (except the parent_hashes and >>> signatures). So basically something like this: - leaf.tree_hash := >>> H(leaf.data) - node.tree_hash := H(node.data, node.lchild.tree_hash, >>> node.rchild.tree_hash) - root.parent_hash := 0 - node.parent_hash := >>> H(node.parent.tree_hash, node.parent.parent_hash). >>> >>> This definition did include the whole subtree and therefore I was assuming  >>> that this would also end up in the spec change. As far as I now understand,  >>> you went for a more lightweight approach where you say that just using the  >>> resolution is enough, because pinning all nodes in the subtree is not  >>> necessary and would only prevent “benign” attacks. I guess I missed the part  >>> where you switched from one concept to the other. >>> >>> What I discovered during implementation is that when you only use the  >>> resolution approach and the tree has no blanks, you are not always able to  >>> detect if the attacker has swapped two leaves. This might indeed just be a  >>> benign attack in the sense that the tree invariant is not violated. >>> >>> At this point I don’t have strong arguments for or against using the  >>> resolution approach, I would have to think about it some more. Just as a  >>> reminder for context, the original concept by Benjamin and Karthik was  >>> “parent hash covers the tree hash”. That’s pretty much what you initially  >>> proposed, except that it also covered the KeyPackage at the leaf level, not  >>> just the HPKE public key. >>> >>> My question right now would be: What is the benefit of the lightweight  >>> resolution-based approach? If it’s just efficiency, we should look at whether >>> there’s really that much to gain. >>> >>> On efficiency: The parent hashes are verified in two instances: a) when a >>> new member joins the group and validates the public tree it received and b) >>> when a member receives a full Commit from another member. >>> >>> Re a): The spec now says "Moreover, when joining a group, new members MUST  >>> authenticate each non-blank parent node P. A parent node P is authenticated”. >>> This means the effort is linear to start with. Depending on how you define >>> the operation, it is even worse than linear. Say the tree has n leaves and >>> therefore 2n-1 nodes. For every node, we need to iterate over at least a part >>> of the subtree and collect public keys that we then concatenate. We end up >>> only hashing once per node, but with a variable size payload. I think the >>> cost of navigating the subtree and collecting the keys is O(log n) for the >>> “resolution approach and O(n) for the “descendants" approach and the cost of >>> hashing is linearly proportional to the size of the payload. If we assume >>> that hashing is the most expensive operation, the total cost would be O(n * >>> log n) for “resolution” and O(n ^ 2) for “descendants". >>> >>> Re b): It is very similar to a), except that we only have to iterate over >>> log n nodes of the direct path, not the whole tree. That means that the >>> total effort is O(log n * log n) for “resolution” and O(n * log n) for  >>> “descendants”. >>> >>> There’s clearly a difference in terms of efficiency between the two  >>> approaches. That being said, we should keep in mind that for small payloads,  >>> hashing is a lot faster than other cryptographic operations like e.g.  >>> producing and verifying signatures. Since a new joiner needs to also verify >>> n signatures when joining a group, it could well be that the effort of  >>> verifying the parent hashes is negligible compared to the cost of verifying  >>> all signatures. >>> >>> In summary: I still don’t have strong arguments against the “resolution”  >>> approach, but I also have a feeling that the efficiency differences are not  >>> dramatic either. >>> >>> Happy New Year and thanks! >>> >>> Raphael >>> >>>> On 1. Jan 2021, at 15:48, Mularczyk Marta >>>   >>>> >> >>>> wrote: >>>> >>>> Hi Raphael, >>>> >>>> Thanks for explaining! Using "descendants" is definitely better for  >>>> security, but also, as Hubert mentioned, less efficient. >>>> >>>> Also we did understand “resolution” the same way as you when we proposed  >>>> the strong parent hash (sorry for the confusion). >>>> >>>> But we obviously really want to understand if/why using resolution is  >>>> insecure. Ultimately, the security property we care about is that privacy  >>>> and authenticity of application messages holds. The Parent Hash mechanism  >>>> helps us ensure this holds also for epochs in adversarially generated  >>>> groups, as long as the adversary does not control any leaves in this epoch  >>>> (i.e. does not know the signing key of the leaf). So to really see if your  >>>> examples break security, it would be good to see if they let us violate  >>>> this security goal. >>>> >>>> To see why we believe the new parent hash notion (i.e. with resolutions)  >>>> achieves this, let us first clarify what technical property about (even  >>>> adversarially produced) ratchet trees we want from verifying parent hashes. >>>> It’s not that the adversary can’t produce manipulated trees at all. It’s >>>> that the only manipulations she is able to do will not let her produce a >>>> tree that violates the tree invariant. That’s because (in our model) when  >>>> the tree invariant holds then we can show that the epoch is secure. >>>> >>>> So some manipulations *are* possible. They are just “benign”. For example, >>>> suppose adversary A controls a leaf L with HPKE key pk in tree T (i.e. she >>>> knows the signing key of L’s owner). Then A can construct a new tree T’  >>>> identical to T but where leaf L has pk’ != pk (say, by performing a commit  >>>> at leaf L to obtain T’). But for this, in T’ leaf L must still be  >>>> controlled by A. We call this manipulation “benign” because even though A  >>>> might now break privacy of application messages in epoch with tree T’ it  >>>> doesnt violate our security goal because privacy is conditioned on A *not*  >>>> controlling any leaves. >>>> >>>> Conversely, one thing A can *not* do is the following. Say T’ has a node V >>>> with HPKE public key pk0 such that A knows corresponding sk0. Then for T’  >>>> to pass verification, it must contain a leaf controlled by A. This holds  >>>> since for T’ to pass verification there must be a leaf in V’s subtree with  >>>> a signature covering a hash that includes pk0. I.e. some leaf must >>>> “attest” to having inserted pk0 into T’. (Recall that in our model the >>>> adversary can’t just leak sk0 alone. They must leak a full state of some >>>> client which also means leaking the client's signing key.) >>>> >>>> So our question to you is the following. (Does this make sense? And) we’re  >>>> not exactly sure what you have in mind when you say “swapping out two leaf  >>>> nodes”. But we think it would only be a problem if it is not benign. Is  >>>> this true for your attack? Could you expand a bit on what tree >>>> manipulation you have in mind? >>>> >>>> Best, Joël& Marta >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> >>>> >> *From:* MLS >  > >> on behalf of >>>> Hubert Chathi >>>  >>> >> *Sent:*  >>>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org   >>>> > *Subject:* Re: [MLS] New Parent Hash >>>> >>>> I think that if you use "descendants" as you define it, then calculating  >>>> the parent_hash will become O(n) all the time, rather than O(log n) in the >>>> best-case, since the size of the descendants list will be O(n).  I'm not  >>>> sure if there's a good way to maintain O(log n) and still provide the  >>>> desired security. >>>> >>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: >>>>> Hi Joël, Daniel and Marta, >>>>> >>>>> I just implemented the stronger parent hash scheme you proposed in the  >>>>> way it is described in the spec now. The good news is that it is  >>>>> implementable, the bad news is that is does not solve the problem you  >>>>> initially describe. Specifically, swapping out two leaf nodes still goes  >>>>> undetected. >>>>> >>>>> I think it is due to a terminology conflict, but it would be great if >>>>> you could validate that assumption. In 7.4 you introduce the notion of  >>>>> “original child resolution” as " the array of HPKEPublicKey values of >>>>> the nodes in the resolution of S”. The term “resolution” is defined in >>>>> 5.2. It is essentially a way of dealing with blank nodes by substituting >>>>> them with the first non-blank descendants you find when descending the >>>>> subtree of a node. Here is my assumption: You probably thought the >>>>> resolution would cover all non-blank descendants of a node, not just the >>>>> first non-blank descendant. In that case we would need another function >>>>> that does that (let’s call it “descendants”). >>>>> >>>>> If we look at the example of 5.2: >>>>> >>>>>  - The resolution of node 3 is the list [A, CD, C] - The descendants >>>>> of node 3 is the list [A, CD, C, D] >>>>> >>>>>  - The resolution of node 5 is the list [CD] - The descendants of node  >>>>> 5 is the list [CD, C, D] (we just need to additionally filter out C,  >>>>> because it is an unmerged leaf of node 5) >>>>> >>>>> Here is a code snippet of what the “descendants” function would look >>>>> like (sorry that it’s Rust, not Python): >>>>> >>>>> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { if  >>>>> level(x) == 0 { vec![x] } else { let left_child = left(x); let  >>>>> right_child = right(x, size); [ descendants(left_child, size), vec![x],  >>>>> descendants(right_child, size), ] .concat() } } >>>>> >>>>> There’s a more efficient implementation of course, this is just to  >>>>> illustrate. >>>>> >>>>> In other words, the new “original child resolution” of S would be the  >>>>> subtree under S, but with filtered-out blank nodes and unmerged leaves >>>>> of S. >>>>> >>>>> If my assumption is correct, I’ll follow up quickly with a PR since this  >>>>> is currently a blocker for interop based on draft-11. >>>>> >>>>> Thanks >>>>> >>>>> Raphael >>>>> >>>>> >>>>> >>>>>> On 12. Nov 2020, at 22:14, Joel Alwen >>>>>   >>>>>> >> wrote: >>>>>> >>>>>> Hey people, >>>>>> >>>>>> Just a quick heads up that Daniel, Marta and I put in a PR with a new  >>>>>> version of strong parent hash to prevent the attacks from the earlier  >>>>>> thread. We tried to make it as minimal as we could to help with  >>>>>> deniability while still preventing the attacks permitted by weak >>>>>> parent hashes. >>>>>> >>>>>> In a nutshell, when computing parent_hash at node v with parent p and  >>>>>> sibling w we include - p's HPKE pubkey - p's parent_hash value and -  >>>>>> HPKE pub keys in the resolution of w except for those belonging to  >>>>>> leaves unmerged at p. >>>>>> >>>>>> As a sanity check, notice that as long as p's keys remain the same one  >>>>>> can always recompute the same parent_hash value at v as was initially  >>>>>> computed by the member that set p's keys. (In other words, new members  >>>>>> can verify that the stored parent_hash values match whats in the >>>>>> tree.) In particular, that's coz as long as p's keys are unchanged so >>>>>> is the resolution of w. The only exception are leaves being added as >>>>>> unmerged at w. But those leaves are also added as unmerged at p so they >>>>>> are left out of the hash. >>>>>> >>>>>> As for deniability, at least parent_hash only binds HPKE keys and  >>>>>> nothing else (like, say, credentials or signatures). Its the best we  >>>>>> were able to come up with for now... >>>>>> >>>>>> - joël >>>>>> >>>>>> _______________________________________________ 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 Mon Jan 4 10:19:55 2021 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23A3A0EED; Mon, 4 Jan 2021 10:19:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, mls-chairs@ietf.org, mls@ietf.org, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160978439359.10347.5395916064561884373@ietfa.amsl.com> Date: Mon, 04 Jan 2021 10:19:54 -0800 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 110 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 18:19:54 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack privacypass masque Key Participant Conflict: acme artarea dispatch perc secdispatch People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: if wish comes to pass that needs to be a conflict for the chairs. --------------------------------------------------------- From nobody Tue Jan 5 06:49:07 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 400FA3A0EF9 for ; Tue, 5 Jan 2021 06:49:05 -0800 (PST) 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 e1zE3t4OsMYw for ; Tue, 5 Jan 2021 06:49:00 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 DFBC33A101A for ; Tue, 5 Jan 2021 06:48:59 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id c14so20985122qtn.0 for ; Tue, 05 Jan 2021 06:48:59 -0800 (PST) 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=BDKtIJiLxggbuHi/39JJ9zGJtFgYQ9pBUr00R7GBOAI=; b=jWXxNEaREt+t7TgRvDcDxbzIG2ZC/ikwxiROscRa0rkxuhXSiBUyru1dR6qzvY4yo/ 8ArgQ7NiLGazSb/CEgBGFsRbv/K6DyNpk9wjeUZ2vlWvngtPUrfTsK/PlCf8a0dcdItU CmBS/Tb0Loe8HXHfXyU3n93Mtndy9Kf1QsT1BJjKhyKkuALggk+P9ceYYWKmVxV6fSVS uGZCM8q4OV0keINfgFtDir5atV89nvoaOzhQjpy375cI4AnKSci9ExFqVWZlZCcUAQEo XCC9hHvwFlwZLkq99Qw9ZNYwrqE7zsdhZ6pnPmgJzjcuknMLuU8Sw0J6PJL/csusYK17 eR4Q== 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=BDKtIJiLxggbuHi/39JJ9zGJtFgYQ9pBUr00R7GBOAI=; b=Ig9yCqrSWMTQL/YEq6a3YGOwo6CHv+xfCXgUtKZ4hX5FaqYU1WVMTE8nXNotcSzduf qfylRQnwGgS1H/0xYYp3zReklsAGy7ZabFngSQxEM13+7/+Aic25vJyZbEG0aRHI02jF ZhPGodMGQ+MIn4e1QBu3wzGuEAoSevVIaHSN4QJFoXHJjSkoAc5GUVZPHKKazVItXbMe Thi5B1AGPneCJRNP4vYI0xuHWFsvHZZSu4Wp4+R1OIx4cV1HODU0k0OpDKAFSGXThfvU bLKp2bwsKPHCL2F4o+aX/b0K6zLlh/Omx4/We/oZKotpbcbFRxsJVKWwUYdZ6bxN6SpO XrPw== X-Gm-Message-State: AOAM53203ad9Czld3AlT/e8ieidfMzE9FVTLDn96blrTFOtf9pyg9vKe cPmXzaC/weIqHYcVgHLwhG5alv2VZk8/OVsYyoqmDQ== X-Google-Smtp-Source: ABdhPJwHdhboBo2XDE6W1uaLUSq8K0dbLsqv5B7iJ8PCKwQEK9rMkqbvC1jMJqH8eND7rrZy+WIT/liY3NpgFhBxcVw= X-Received: by 2002:ac8:598d:: with SMTP id e13mr77078395qte.313.1609858138470; Tue, 05 Jan 2021 06:48:58 -0800 (PST) MIME-Version: 1.0 References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> <4135BB5E-4C35-4EFF-91B6-1615C3560F1E@wire.com> <54f2ca71-89e1-1ca3-b783-2ad774564127@wickr.com> In-Reply-To: <54f2ca71-89e1-1ca3-b783-2ad774564127@wickr.com> From: Richard Barnes Date: Tue, 5 Jan 2021 09:48:27 -0500 Message-ID: To: Joel Alwen Cc: Raphael Robert , "mls@ietf.org" , Mularczyk Marta Content-Type: multipart/alternative; boundary="0000000000007b92c605b8284e3f" Archived-At: Subject: Re: [MLS] New Parent Hash 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: Tue, 05 Jan 2021 14:49:05 -0000 --0000000000007b92c605b8284e3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Marta, Raphael, and Joel for sorting this out :) I agree with Jo=C3=ABl's assessment that the "descendants" approach is actu= ally log-scale as well. You only have to do the full O(n) hashing when you join the group and first get the tree. After that, you just update the hashes that have changed. Same as with the tree hash. (Note: I am assuming that the "descendant hash" would be tree-structured like the parent hash; it just would cover only the HPKE public keys instead of the whole nodes.) So it seems like we have two log-scale alternatives here: - The "resolution" approach (in draft-11), which incorporates the minimum information necessary to assure the tree invariant - The "descendants" approach, which binds in the entire structure of the tree (in units of HPKE keys) >From an implementation point of view, there's not a ton of difference between these two, but the "descendants" approach seems a bit nicer to me. In the "resolution" case, you can re-use resolution logic; in the "descendants" case, you can re-use the "update the changed nodes" logic that the tree hash requires. If anything, the "descendants" approach is a little more "static", in that you can store the descendant hashes on the nodes, then at parent-hash time, you can just grab the descendant-hash from the appropriate child. A tree-structured hash also seems easier to get right than making sure the resolution is in the right order, and it's compatible with the idea that you mainly need to know about the copath of an UpdatePath in order to process it. >From a security POV, it seems like either is acceptable, since they both enforce the tree invariant. The extra structure enforcement doesn't seem like it adds much in terms of security, but it does seem a little easier to think about, since you don't have to keep in mind the caveat that the structure can change below the resolution points. So net/net, I have a slight preference for the "descendants" approach, if people are OK with the extra rigidity. --Richard --Richard On Mon, Jan 4, 2021 at 8:33 AM Joel Alwen wrote: > > On 02/01/2021 18:02, Raphael Robert wrote: > > Thanks Marta and Jo=C3=ABl for the explanation! That was the delta that= was > missing > > for my understanding and it=E2=80=99s definitely good to have that on l= ist. > > Yes, good call. FYI there's a MUCH more complete discussion of the securi= ty > properties of MLS we've analyzed, the adversarial and communication model= s > we > used and the actual security proof in eprint/2020/1327. (We'll be updatin= g > it > soon to include our security analysis of the new parent hash scheme.) > > > Just for context, what I had in mind was something that was not as > detrimental > > to the membership deniability. I think in that respect both the > =E2=80=9Cresolution=E2=80=9D > > and the =E2=80=9Cdescendants=E2=80=9D approach are equivalent. > > I agree that the resolution method is hardly deniable in any formal sense > I know > of. Switching from signing (hashes of) the entire list of certs of > everyone in a > subtree to "only" signing HPKE pubkeys in the resolution does feel like a > pretty > superficial improvement for deniability. :-/ To me, the advantage of usin= g > resolutions is the simplicity & efficiency compared to using descendants. > > TBH, for deniability I think there's a whole family of impossibilities > waiting > to be formalized here (like the one in Thm. 1 of eprint/2019/1153). > Asynchronous > + authenticated + (strongly?!) deniable + no global trusted setup + > communication complexity sub-linear in the group size? Seems very hard to > me (in > my non-expert opinion). My guess is that real compromises in the model / > design > goals need to be made to get (even just weak) deniability. > > I=E2=80=99d however like to leave it as an open question whether we sho= uldn=E2=80=99t > reconsider locking down entire subtrees as a security-in-depth measure if > we can convince ourselves the performance toll is not too high. > > If we can do it, without paying too much of an efficiency price, then by > all > means why not? I'm still curious what we'd be getting though. E.g. what > needs to > happen so that hashing in descendants is secure but using only the > resolution isn't? > > > The tree hash has to be calculated for every epoch change anyway and > it=E2=80=99s always in O(n). > > For my own edification: I would have thought computing the new tree hash > at the > root after a commit to p proposals requires at most ~ O(p*log(n)) actual > hash > calls + as many memory lookups no? Let L_p be the leaves modified by the > proposals. The root of any subtree with no leaf in L_p has the same tree > hash as > before the commit. So by storing tree hashes as we compute them we can > replace > computing unchanged subtree tree hashes with a lookup. What am I missing > here? > > - Jo=C3=ABl > > > >> On 1. Jan 2021, at 23:10, Joel Alwen >> > wrote: > >> > >> Servus Raphael, > >> > >>> Happy New Year > >> > >> Same to you! Here's hoping the new one will be a tad happier than the > last. ;-) > >> > >> As for why "resolutions": The impetus to look for a new approach after > our > >> initial proposal came from a comment in your email on the Fri, 23 > October 2020 > >> 18:23 UTC in the thread "Weak vs. Strong Tree Authentication". There > you wrote: > >> > >>> Going for fully hashing the tree nodes as described locks down the > whole > >>> tree structure, making any reshuffling impossible. Maybe there is a > more > >>> lightweight approach that would yield the same result without > =E2=80=9Cprovid[ing] > >>> irrefutable evidence that the signing key's owner was in a group with > (at > >>> least some) of the other members in the group=E2=80=9D, but I can=E2= =80=99t think of > >>> anything right now. > >> > >> That was an intriguing challenge and got us thinking. The result is th= e > current > >> Parent Hash definition using resolutions. We realized that to buy > wiggle room in > >> not locking down as much of the tree (especially, not locking down > other members > >> identities into the hash) we could pay a "price" that actually doesn't > harm the > >> security we've been aiming for. Namely, we can allow the adversary som= e > more > >> tree manipulation but still only benign ones that dont actually allow > her to > >> break the security property we've been aiming for. > > > > Just for context, what I had in mind was something that was not as > detrimental > > to the membership deniability. I think in that respect both the > =E2=80=9Cresolution=E2=80=9D and > > the =E2=80=9Cdescendants=E2=80=9D approach are equivalent. > > That being said, this looks quite elegant! > > > >> In retrospect, a second reason to use resolutions is efficiency (thoug= h > to fair, > >> that was really a coincidence rather than an explicit goal of the > redesign). > >> Initially, we had been thinking of simply having parent hash include > tree hash > >> as in the Benjamin-Karthik (BK) proposal of days yore. But we realized > that > >> since then MLS had introduced Unmerged Leaves which meant that the tre= e > hash of > >> some nodes can change between when they are assigned their HPKE key an= d > later > >> when a new member wants to verify the parent hash of the node. In othe= r > words > >> the BK approach was broken by unmerged leaves. So, to make the "includ= e > the > >> whole subtree in parent hash" approach work, it seems new members > would, for > >> each node being verified, traverse the nodes full sub-tree so as to > weed out > >> those nodes that were added after the to-be-verified node got its HPKE > key. (I > >> believe this is the O(n) time that Hubert is referring too?) In > contrast, the > >> new version of parent hash (using resolutions) has the potential to be > much > >> faster; it requires hashing less data but also visiting less of the > tree. E.g. > >> when verifying near the root the difference can be as much as visiting > order n > >> nodes vs. visiting 1 node in the new construction. > >> > >> The more blanks & unmerged leaves in the tree the more the new > construction > >> collapses to the old one. But only in the most extreme case do they > actually > >> reach parity and the new approach is never slower than the old. > >> > >> Needless to say, we didn't implement this stuff though, let alone > benchmark the > >> 2 approaches so any hard data elucidating what the actual difference i= s > would be > >> very welcome. Still, the new approach can only be as fast or faster > (but never > >> slower) than the new one. Nor do I think it's any more complicated to > define or > >> implement. And from a security perspective they both let MLS meet our > security > >> definition. So regardless of how small the speed up is (and ignoring > the locking > >> in the tree discussion above) it's still not clear to me why we'd want > to switch > >> back. > >> > >> A meaningful attack that only works on the new but not old constructio= n > would be > >> one very quick way of changing my mind though! :-) But, I believe such > an attack > >> would require either new adversarial capabilities and/or break a new > security > >> property we didn't consider. (For the adversaries & security we > considered, > >> there is no security loss with the new approach compared to the old > one.) > > > > I think we are now fully aligned on the definitions and the performance > > implications and now that we have better documentation we can continue > with the > > interim effort. > > > > I=E2=80=99d however like to leave it as an open question whether we sho= uldn=E2=80=99t > reconsider > > locking down entire subtrees as a security-in-depth measure if we can > convince > > ourselves the performance toll is not too high. > > For example, I=E2=80=99m wondering if there isn=E2=80=99t a clever way = to combine the > tree hash > > and the parent hash. The tree hash has to be calculated for every epoch > change > > anyway and it=E2=80=99s always in O(n). > > > > Thanks > > > > Raphael > > > >> > >> - Jo=C3=ABl > >> > >> On 01/01/2021 17:30, Raphael Robert wrote: > >>> Thanks for the lengthy explanation! > >>> > >>> I=E2=80=99m glad we are on the same page regarding the definition of = the > resolution. > >>> I think I understand where the misunderstanding is coming from. > >>> > >>> Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D solution on th= e ML (on Oct 23 > 2020) > >>> that was the following: > >>> > >>> "strong parent_hash" : Define parent_hash to include tree_hash (and > >>> tree_hash to *not* include parent_hash). The tree_hash of a node > covers all > >>> values in the subtree rooted at that node (except the parent_hashes > and > >>> signatures). So basically something like this: - leaf.tree_hash :=3D > >>> H(leaf.data) - node.tree_hash :=3D H(node.data, node.lchild.tree_hash= , > >>> node.rchild.tree_hash) - root.parent_hash :=3D 0 - node.parent_hash := =3D > >>> H(node.parent.tree_hash, node.parent.parent_hash). > >>> > >>> This definition did include the whole subtree and therefore I was > assuming > >>> that this would also end up in the spec change. As far as I now > understand, > >>> you went for a more lightweight approach where you say that just usin= g > the > >>> resolution is enough, because pinning all nodes in the subtree is not > >>> necessary and would only prevent =E2=80=9Cbenign=E2=80=9D attacks. I = guess I missed > the part > >>> where you switched from one concept to the other. > >>> > >>> What I discovered during implementation is that when you only use the > >>> resolution approach and the tree has no blanks, you are not always > able to > >>> detect if the attacker has swapped two leaves. This might indeed just > be a > >>> benign attack in the sense that the tree invariant is not violated. > >>> > >>> At this point I don=E2=80=99t have strong arguments for or against us= ing the > >>> resolution approach, I would have to think about it some more. Just a= s > a > >>> reminder for context, the original concept by Benjamin and Karthik wa= s > >>> =E2=80=9Cparent hash covers the tree hash=E2=80=9D. That=E2=80=99s pr= etty much what you > initially > >>> proposed, except that it also covered the KeyPackage at the leaf > level, not > >>> just the HPKE public key. > >>> > >>> My question right now would be: What is the benefit of the lightweigh= t > >>> resolution-based approach? If it=E2=80=99s just efficiency, we should= look at > whether > >>> there=E2=80=99s really that much to gain. > >>> > >>> On efficiency: The parent hashes are verified in two instances: a) > when a > >>> new member joins the group and validates the public tree it received > and b) > >>> when a member receives a full Commit from another member. > >>> > >>> Re a): The spec now says "Moreover, when joining a group, new members > MUST > >>> authenticate each non-blank parent node P. A parent node P is > authenticated=E2=80=9D. > >>> This means the effort is linear to start with. Depending on how you > define > >>> the operation, it is even worse than linear. Say the tree has n leave= s > and > >>> therefore 2n-1 nodes. For every node, we need to iterate over at leas= t > a part > >>> of the subtree and collect public keys that we then concatenate. We > end up > >>> only hashing once per node, but with a variable size payload. I think > the > >>> cost of navigating the subtree and collecting the keys is O(log n) fo= r > the > >>> =E2=80=9Cresolution approach and O(n) for the =E2=80=9Cdescendants" a= pproach and the > cost of > >>> hashing is linearly proportional to the size of the payload. If we > assume > >>> that hashing is the most expensive operation, the total cost would be > O(n * > >>> log n) for =E2=80=9Cresolution=E2=80=9D and O(n ^ 2) for =E2=80=9Cdes= cendants". > >>> > >>> Re b): It is very similar to a), except that we only have to iterate > over > >>> log n nodes of the direct path, not the whole tree. That means that t= he > >>> total effort is O(log n * log n) for =E2=80=9Cresolution=E2=80=9D and= O(n * log n) for > >>> =E2=80=9Cdescendants=E2=80=9D. > >>> > >>> There=E2=80=99s clearly a difference in terms of efficiency between t= he two > >>> approaches. That being said, we should keep in mind that for small > payloads, > >>> hashing is a lot faster than other cryptographic operations like e.g. > >>> producing and verifying signatures. Since a new joiner needs to also > verify > >>> n signatures when joining a group, it could well be that the effort o= f > >>> verifying the parent hashes is negligible compared to the cost of > verifying > >>> all signatures. > >>> > >>> In summary: I still don=E2=80=99t have strong arguments against the > =E2=80=9Cresolution=E2=80=9D > >>> approach, but I also have a feeling that the efficiency differences > are not > >>> dramatic either. > >>> > >>> Happy New Year and thanks! > >>> > >>> Raphael > >>> > >>>> On 1. Jan 2021, at 15:48, Mularczyk Marta < > marta.mularczyk@inf.ethz.ch > >>>> > >>>> marta.mularczyk@inf.ethz.ch>>> > >>>> wrote: > >>>> > >>>> Hi Raphael, > >>>> > >>>> Thanks for explaining! Using "descendants" is definitely better for > >>>> security, but also, as Hubert mentioned, less efficient. > >>>> > >>>> Also we did understand =E2=80=9Cresolution=E2=80=9D the same way as = you when we > proposed > >>>> the strong parent hash (sorry for the confusion). > >>>> > >>>> But we obviously really want to understand if/why using resolution i= s > >>>> insecure. Ultimately, the security property we care about is that > privacy > >>>> and authenticity of application messages holds. The Parent Hash > mechanism > >>>> helps us ensure this holds also for epochs in adversarially generate= d > >>>> groups, as long as the adversary does not control any leaves in this > epoch > >>>> (i.e. does not know the signing key of the leaf). So to really see i= f > your > >>>> examples break security, it would be good to see if they let us > violate > >>>> this security goal. > >>>> > >>>> To see why we believe the new parent hash notion (i.e. with > resolutions) > >>>> achieves this, let us first clarify what technical property about > (even > >>>> adversarially produced) ratchet trees we want from verifying parent > hashes. > >>>> It=E2=80=99s not that the adversary can=E2=80=99t produce manipulate= d trees at all. > It=E2=80=99s > >>>> that the only manipulations she is able to do will not let her > produce a > >>>> tree that violates the tree invariant. That=E2=80=99s because (in ou= r model) > when > >>>> the tree invariant holds then we can show that the epoch is secure. > >>>> > >>>> So some manipulations *are* possible. They are just =E2=80=9Cbenign= =E2=80=9D. For > example, > >>>> suppose adversary A controls a leaf L with HPKE key pk in tree T > (i.e. she > >>>> knows the signing key of L=E2=80=99s owner). Then A can construct a = new tree > T=E2=80=99 > >>>> identical to T but where leaf L has pk=E2=80=99 !=3D pk (say, by per= forming a > commit > >>>> at leaf L to obtain T=E2=80=99). But for this, in T=E2=80=99 leaf L = must still be > >>>> controlled by A. We call this manipulation =E2=80=9Cbenign=E2=80=9D = because even > though A > >>>> might now break privacy of application messages in epoch with tree T= =E2=80=99 > it > >>>> doesnt violate our security goal because privacy is conditioned on A > *not* > >>>> controlling any leaves. > >>>> > >>>> Conversely, one thing A can *not* do is the following. Say T=E2=80= =99 has a > node V > >>>> with HPKE public key pk0 such that A knows corresponding sk0. Then > for T=E2=80=99 > >>>> to pass verification, it must contain a leaf controlled by A. This > holds > >>>> since for T=E2=80=99 to pass verification there must be a leaf in V= =E2=80=99s subtree > with > >>>> a signature covering a hash that includes pk0. I.e. some leaf must > >>>> =E2=80=9Cattest=E2=80=9D to having inserted pk0 into T=E2=80=99. (Re= call that in our model the > >>>> adversary can=E2=80=99t just leak sk0 alone. They must leak a full s= tate of > some > >>>> client which also means leaking the client's signing key.) > >>>> > >>>> So our question to you is the following. (Does this make sense? And) > we=E2=80=99re > >>>> not exactly sure what you have in mind when you say =E2=80=9Cswappin= g out two > leaf > >>>> nodes=E2=80=9D. But we think it would only be a problem if it is not= benign. > Is > >>>> this true for your attack? Could you expand a bit on what tree > >>>> manipulation you have in mind? > >>>> > >>>> Best, Jo=C3=ABl& Marta > >>>> > >>>> > -------------------------------------------------------------------------= ------- > >>>> > >>>> > >>>> > >> *From:* MLS >> >> >> on behalf of > >>>> Hubert Chathi >>>> >>>> >> *Sent:* > >>>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org mls@ietf.org> > >>>> > *Subject:* Re: [MLS] New > Parent Hash > >>>> > >>>> I think that if you use "descendants" as you define it, then > calculating > >>>> the parent_hash will become O(n) all the time, rather than O(log n) > in the > >>>> best-case, since the size of the descendants list will be O(n). I'm > not > >>>> sure if there's a good way to maintain O(log n) and still provide th= e > >>>> desired security. > >>>> > >>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: > >>>>> Hi Jo=C3=ABl, Daniel and Marta, > >>>>> > >>>>> I just implemented the stronger parent hash scheme you proposed in > the > >>>>> way it is described in the spec now. The good news is that it is > >>>>> implementable, the bad news is that is does not solve the problem > you > >>>>> initially describe. Specifically, swapping out two leaf nodes still > goes > >>>>> undetected. > >>>>> > >>>>> I think it is due to a terminology conflict, but it would be great = if > >>>>> you could validate that assumption. In 7.4 you introduce the notion > of > >>>>> =E2=80=9Coriginal child resolution=E2=80=9D as " the array of HPKEP= ublicKey values of > >>>>> the nodes in the resolution of S=E2=80=9D. The term =E2=80=9Cresolu= tion=E2=80=9D is defined > in > >>>>> 5.2. It is essentially a way of dealing with blank nodes by > substituting > >>>>> them with the first non-blank descendants you find when descending > the > >>>>> subtree of a node. Here is my assumption: You probably thought the > >>>>> resolution would cover all non-blank descendants of a node, not jus= t > the > >>>>> first non-blank descendant. In that case we would need another > function > >>>>> that does that (let=E2=80=99s call it =E2=80=9Cdescendants=E2=80=9D= ). > >>>>> > >>>>> If we look at the example of 5.2: > >>>>> > >>>>> - The resolution of node 3 is the list [A, CD, C] - The > descendants > >>>>> of node 3 is the list [A, CD, C, D] > >>>>> > >>>>> - The resolution of node 5 is the list [CD] - The descendants of > node > >>>>> 5 is the list [CD, C, D] (we just need to additionally filter out C= , > >>>>> because it is an unmerged leaf of node 5) > >>>>> > >>>>> Here is a code snippet of what the =E2=80=9Cdescendants=E2=80=9D fu= nction would look > >>>>> like (sorry that it=E2=80=99s Rust, not Python): > >>>>> > >>>>> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { i= f > >>>>> level(x) =3D=3D 0 { vec![x] } else { let left_child =3D left(x); le= t > >>>>> right_child =3D right(x, size); [ descendants(left_child, size), > vec![x], > >>>>> descendants(right_child, size), ] .concat() } } > >>>>> > >>>>> There=E2=80=99s a more efficient implementation of course, this is = just to > >>>>> illustrate. > >>>>> > >>>>> In other words, the new =E2=80=9Coriginal child resolution=E2=80=9D= of S would be > the > >>>>> subtree under S, but with filtered-out blank nodes and unmerged > leaves > >>>>> of S. > >>>>> > >>>>> If my assumption is correct, I=E2=80=99ll follow up quickly with a = PR since > this > >>>>> is currently a blocker for interop based on draft-11. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Raphael > >>>>> > >>>>> > >>>>> > >>>>>> On 12. Nov 2020, at 22:14, Joel Alwen >>>>>> > >>>>>> >> wrote: > >>>>>> > >>>>>> Hey people, > >>>>>> > >>>>>> Just a quick heads up that Daniel, Marta and I put in a PR with a > new > >>>>>> version of strong parent hash to prevent the attacks from the > earlier > >>>>>> thread. We tried to make it as minimal as we could to help with > >>>>>> deniability while still preventing the attacks permitted by weak > >>>>>> parent hashes. > >>>>>> > >>>>>> In a nutshell, when computing parent_hash at node v with parent p > and > >>>>>> sibling w we include - p's HPKE pubkey - p's parent_hash value and > - > >>>>>> HPKE pub keys in the resolution of w except for those belonging to > >>>>>> leaves unmerged at p. > >>>>>> > >>>>>> As a sanity check, notice that as long as p's keys remain the same > one > >>>>>> can always recompute the same parent_hash value at v as was > initially > >>>>>> computed by the member that set p's keys. (In other words, new > members > >>>>>> can verify that the stored parent_hash values match whats in the > >>>>>> tree.) In particular, that's coz as long as p's keys are unchanged > so > >>>>>> is the resolution of w. The only exception are leaves being added = as > >>>>>> unmerged at w. But those leaves are also added as unmerged at p so > they > >>>>>> are left out of the hash. > >>>>>> > >>>>>> As for deniability, at least parent_hash only binds HPKE keys and > >>>>>> nothing else (like, say, credentials or signatures). Its the best > we > >>>>>> were able to come up with for now... > >>>>>> > >>>>>> - jo=C3=ABl > >>>>>> > >>>>>> _______________________________________________ MLS mailing list > >>>>>> MLS@ietf.org >>>>>> > > >>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>> > >>>> >>>> > > >>>>> > >>>>> _______________________________________________ MLS mailing list > >>>>> MLS@ietf.org MLS@ietf.org>> > >>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>> > >>>> >>>> > > >>>>> > >>>> > >>>> _______________________________________________ MLS mailing list > >>>> MLS@ietf.org MLS@ietf.org>> > >>>> https://www.ietf.org/mailman/listinfo/mls > >>>> > >>>> >>>> > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000007b92c605b8284e3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Marta, Raphael, and Joel for sorting this out = :)

I agree with Jo=C3=ABl's assessment that th= e "descendants" approach is actually log-scale as well.=C2=A0 You= only have to do the full O(n) hashing when you join the group and first ge= t the tree.=C2=A0 After that, you just update the hashes that have changed.= =C2=A0 Same as with the tree hash.=C2=A0 (Note: I am assuming that the &quo= t;descendant hash" would be tree-structured like the parent hash; it j= ust would cover only the HPKE public keys instead of the whole nodes.)
<= /div>

So it seems like we have two log-scale alternative= s here:

- The "resolution" approach (in = draft-11), which incorporates the minimum information necessary to assure t= he tree invariant
- The "descendants" approach, which b= inds in the entire structure of the tree (in units of HPKE keys)

<= div>From an implementation point of view, there's not a ton of differen= ce between these two, but the "descendants" approach seems a bit = nicer to me.=C2=A0 In the "resolution" case, you can re-use resol= ution logic; in the "descendants" case, you can re-use the "= update the changed nodes" logic that the tree hash requires.=C2=A0 If = anything, the "descendants" approach is a little more "stati= c", in that you can store the descendant hashes on the nodes, then at = parent-hash time, you can just grab the descendant-hash from the appropriat= e child.=C2=A0 A tree-structured hash also seems easier to get right than m= aking sure the resolution is in the right order, and it's compatible wi= th the idea that you mainly need to know about the copath of an UpdatePath = in order to process it.

From a security POV, i= t seems like either is acceptable, since they both enforce the tree invaria= nt.=C2=A0 The extra structure enforcement doesn't seem like it adds muc= h in terms of security, but it does seem a little easier to think about, si= nce you don't have to keep in mind the caveat that the structure can ch= ange below the resolution points.

So net/net, = I have a slight preference for the "descendants" approach, if peo= ple are OK with the extra rigidity.

--Richard
<= /div>

--Richard

On Mon, Jan 4, 2021 at 8:33 AM = Joel Alwen <jalwen@wickr.com>= wrote:

On 02/01/2021 18:02, Raphael Robert wrote:
> Thanks Marta and Jo=C3=ABl for the explanation! That was the delta tha= t was missing
> for my understanding and it=E2=80=99s definitely good to have that on = list.

Yes, good call. FYI there's a MUCH more complete discussion of the secu= rity
properties of MLS we've analyzed, the adversarial and communication mod= els we
used and the actual security proof in eprint/2020/1327. (We'll be updat= ing it
soon to include our security analysis of the new parent hash scheme.)

> Just for context, what I had in mind was something that was not as det= rimental
> to the membership deniability. I think in that respect both the =E2=80= =9Cresolution=E2=80=9D
> and the =E2=80=9Cdescendants=E2=80=9D approach are equivalent.

I agree that the resolution method is hardly deniable in any formal sense I= know
of. Switching from signing (hashes of) the entire list of certs of everyone= in a
subtree to "only" signing HPKE pubkeys in the resolution does fee= l like a pretty
superficial improvement for deniability. :-/ To me, the advantage of using<= br> resolutions is the simplicity & efficiency compared to using descendant= s.

TBH, for deniability I think there's a whole family of impossibilities = waiting
to be formalized here (like the one in Thm. 1 of eprint/2019/1153). Asynchr= onous
+ authenticated + (strongly?!) deniable + no global trusted setup +
communication complexity sub-linear in the group size? Seems very hard to m= e (in
my non-expert opinion). My guess is that real compromises in the model / de= sign
goals need to be made to get (even just weak) deniability.
> I=E2=80=99d however like to leave it as an open question whether we sh= ouldn=E2=80=99t reconsider locking down entire subtrees as a security-in-de= pth measure if we can convince ourselves the performance toll is not too hi= gh.

If we can do it, without paying too much of an efficiency price, then by al= l
means why not? I'm still curious what we'd be getting though. E.g. = what needs to
happen so that hashing in descendants is secure but using only the resoluti= on isn't?

> The tree hash has to be calculated for every epoch change anyway and i= t=E2=80=99s always in O(n).

For my own edification: I would have thought computing the new tree hash at= the
root after a commit to p proposals requires at most ~ O(p*log(n)) actual ha= sh
calls + as many memory lookups no? Let L_p be the leaves modified by the proposals. The root of any subtree with no leaf in L_p has the same tree ha= sh as
before the commit. So by storing tree hashes as we compute them we can repl= ace
computing unchanged subtree tree hashes with a lookup. What am I missing he= re?

- Jo=C3=ABl


>> On 1. Jan 2021, at 23:10, Joel Alwen <jalwen@wickr.com
>> <mailto:j= alwen@wickr.com>> wrote:
>>
>> Servus Raphael,
>>
>>> Happy New Year
>>
>> Same to you! Here's hoping the new one will be a tad happier t= han the last. ;-)
>>
>> As for why "resolutions": The impetus to look for a new = approach after our
>> initial proposal came from a comment in your email on the Fri, 23 = October 2020
>> 18:23 UTC in the thread "Weak vs. Strong Tree Authentication&= quot;. There you wrote:
>>
>>> Going for fully hashing the tree nodes as described locks down= the whole
>>> tree structure, making any reshuffling impossible. Maybe there= is a more=C2=A0
>>> lightweight approach that would yield the same result without = =E2=80=9Cprovid[ing]=C2=A0
>>> irrefutable evidence that the signing key's owner was in a= group with (at=C2=A0
>>> least some) of the other members in the group=E2=80=9D, but I = can=E2=80=99t think of
>>> anything right now.
>>
>> That was an intriguing challenge and got us thinking. The result i= s the current
>> Parent Hash definition using resolutions. We realized that to buy = wiggle room in
>> not locking down as much of the tree (especially, not locking down= other members
>> identities into the hash) we could pay a "price" that ac= tually doesn't harm the
>> security we've been aiming for. Namely, we can allow the adver= sary some more
>> tree manipulation but still only benign ones that dont actually al= low her to
>> break the security property we've been aiming for.
>
> Just for context, what I had in mind was something that was not as det= rimental
> to the membership deniability. I think in that respect both the =E2=80= =9Cresolution=E2=80=9D and
> the =E2=80=9Cdescendants=E2=80=9D approach are equivalent.
> That being said, this looks quite elegant!
>
>> In retrospect, a second reason to use resolutions is efficiency (t= hough to fair,
>> that was really a coincidence rather than an explicit goal of the = redesign).
>> Initially, we had been thinking of simply having parent hash inclu= de tree hash
>> as in the Benjamin-Karthik (BK) proposal of days yore. But we real= ized that
>> since then MLS had introduced Unmerged Leaves which meant that the= tree hash of
>> some nodes can change between when they are assigned their HPKE ke= y and later
>> when a new member wants to verify the parent hash of the node. In = other words
>> the BK approach was broken by unmerged leaves. So, to make the &qu= ot;include the
>> whole subtree in parent hash" approach work, it seems new mem= bers would, for
>> each node being verified, traverse the nodes full sub-tree so as t= o weed out
>> those nodes that were added after the to-be-verified node got its = HPKE key. (I
>> believe this is the O(n) time that Hubert is referring too?) In co= ntrast, the
>> new version of parent hash (using resolutions) has the potential t= o be much
>> faster; it requires hashing less data but also visiting less of th= e tree. E.g.
>> when verifying near the root the difference can be as much as visi= ting order n
>> nodes vs. visiting 1 node in the new construction.
>>
>> The more blanks & unmerged leaves in the tree the more the new= construction
>> collapses to the old one. But only in the most extreme case do the= y actually
>> reach parity and the new approach is never slower than the old. >>
>> Needless to say, we didn't implement this stuff though, let al= one benchmark the
>> 2 approaches so any hard data elucidating what the actual differen= ce is would be
>> very welcome. Still, the new approach can only be as fast or faste= r (but never
>> slower) than the new one. Nor do I think it's any more complic= ated to define or
>> implement. And from a security perspective they both let MLS meet = our security
>> definition. So regardless of how small the speed up is (and ignori= ng the locking
>> in the tree discussion above) it's still not clear to me why w= e'd want to switch
>> back.
>>
>> A meaningful attack that only works on the new but not old constru= ction would be
>> one very quick way of changing my mind though! :-) But, I believe = such an attack
>> would require either new adversarial capabilities and/or break a n= ew security
>> property we didn't consider. (For the adversaries & securi= ty we considered,
>> there is no security loss with the new approach compared to the ol= d one.)
>
> I think we are now fully aligned on the definitions and the performanc= e
> implications and now that we have better documentation we can continue= with the
> interim effort.
>
> I=E2=80=99d however like to leave it as an open question whether we sh= ouldn=E2=80=99t reconsider
> locking down entire subtrees as a security-in-depth measure if we can = convince
> ourselves the performance toll is not too high.=C2=A0
> For example, I=E2=80=99m wondering if there isn=E2=80=99t a clever way= to combine the tree hash
> and the parent hash. The tree hash has to be calculated for every epoc= h change
> anyway and it=E2=80=99s always in O(n).
>
> Thanks
>
> Raphael
>
>>
>> - Jo=C3=ABl
>>
>> On 01/01/2021 17:30, Raphael Robert wrote:
>>> Thanks for the lengthy explanation!
>>>
>>> I=E2=80=99m glad we are on the same page regarding the definit= ion of the resolution.=C2=A0
>>> I think I understand where the misunderstanding is coming from= .
>>>
>>> Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D solutio= n on the ML (on Oct 23 2020)=C2=A0
>>> that was the following:
>>>
>>> "strong parent_hash" : Define parent_hash to include= tree_hash (and
>>> tree_hash to *not* include parent_hash). The tree_hash of a no= de covers all
>>> values in the subtree rooted at that node =C2=A0(except the pa= rent_hashes and
>>> signatures). So basically something like this: - leaf.tree_has= h :=3D
>>> H(leaf.data) - node.tree_hash :=3D H(node.data, node.lchild.tr= ee_hash,
>>> node.rchild.tree_hash) - root.parent_hash :=3D 0 - node.parent= _hash :=3D
>>> H(node.parent.tree_hash, node.parent.parent_hash).
>>>
>>> This definition did include the whole subtree and therefore I = was assuming=C2=A0
>>> that this would also end up in the spec change. As far as I no= w understand,=C2=A0
>>> you went for a more lightweight approach where you say that ju= st using the=C2=A0
>>> resolution is enough, because pinning all nodes in the subtree= is not=C2=A0
>>> necessary and would only prevent =E2=80=9Cbenign=E2=80=9D atta= cks. I guess I missed the part=C2=A0
>>> where you switched from one concept to the other.
>>>
>>> What I discovered during implementation is that when you only = use the=C2=A0
>>> resolution approach and the tree has no blanks, you are not al= ways able to=C2=A0
>>> detect if the attacker has swapped two leaves. This might inde= ed just be a=C2=A0
>>> benign attack in the sense that the tree invariant is not viol= ated.
>>>
>>> At this point I don=E2=80=99t have strong arguments for or aga= inst using the=C2=A0
>>> resolution approach, I would have to think about it some more.= Just as a=C2=A0
>>> reminder for context, the original concept by Benjamin and Kar= thik was=C2=A0
>>> =E2=80=9Cparent hash covers the tree hash=E2=80=9D. That=E2=80= =99s pretty much what you initially=C2=A0
>>> proposed, except that it also covered the KeyPackage at the le= af level, not=C2=A0
>>> just the HPKE public key.
>>>
>>> My question right now would be: What is the benefit of the lig= htweight=C2=A0
>>> resolution-based approach? If it=E2=80=99s just efficiency, we= should look at whether
>>> there=E2=80=99s really that much to gain.
>>>
>>> On efficiency: The parent hashes are verified in two instances= : a) when a
>>> new member joins the group and validates the public tree it re= ceived and b)
>>> when a member receives a full Commit from another member.
>>>
>>> Re a): The spec now says "Moreover, when joining a group,= new members MUST=C2=A0
>>> authenticate each non-blank parent node P. A parent node P is = authenticated=E2=80=9D.
>>> This means the effort is linear to start with. Depending on ho= w you define
>>> the operation, it is even worse than linear. Say the tree has = n leaves and
>>> therefore 2n-1 nodes. For every node, we need to iterate over = at least a part
>>> of the subtree and collect public keys that we then concatenat= e. We end up
>>> only hashing once per node, but with a variable size payload. = I think the
>>> cost of navigating the subtree and collecting the keys is O(lo= g n) for the
>>> =E2=80=9Cresolution approach and O(n) for the =E2=80=9Cdescend= ants" approach and the cost of
>>> hashing is linearly proportional to the size of the payload. I= f we assume
>>> that hashing is the most expensive operation, the total cost w= ould be O(n *
>>> log n) for =E2=80=9Cresolution=E2=80=9D and O(n ^ 2) for =E2= =80=9Cdescendants".
>>>
>>> Re b): It is very similar to a), except that we only have to i= terate over
>>> log n nodes of the direct path, not the whole tree. That means= that the
>>> total effort is O(log n * log n) for =E2=80=9Cresolution=E2=80= =9D and O(n * log n) for=C2=A0
>>> =E2=80=9Cdescendants=E2=80=9D.
>>>
>>> There=E2=80=99s clearly a difference in terms of efficiency be= tween the two=C2=A0
>>> approaches. That being said, we should keep in mind that for s= mall payloads,=C2=A0
>>> hashing is a lot faster than other cryptographic operations li= ke e.g.=C2=A0
>>> producing and verifying signatures. Since a new joiner needs t= o also verify
>>> n signatures when joining a group, it could well be that the e= ffort of=C2=A0
>>> verifying the parent hashes is negligible compared to the cost= of verifying=C2=A0
>>> all signatures.
>>>
>>> In summary: I still don=E2=80=99t have strong arguments agains= t the =E2=80=9Cresolution=E2=80=9D=C2=A0
>>> approach, but I also have a feeling that the efficiency differ= ences are not=C2=A0
>>> dramatic either.
>>>
>>> Happy New Year and thanks!
>>>
>>> Raphael
>>>
>>>> On 1. Jan 2021, at 15:48, Mularczyk Marta <marta.mularczyk@inf.et= hz.ch
>>>> <mailto:marta.mularczyk@inf.ethz.ch>=C2=A0
>>>> <mailto:marta.mularczyk@inf.ethz.ch <mailto:marta.mularczyk@inf.ethz= .ch>>>
>>>> wrote:
>>>>
>>>> Hi Raphael,
>>>>
>>>> Thanks for explaining! Using "descendants" is de= finitely better for=C2=A0
>>>> security, but also, as Hubert mentioned, less efficient. >>>>
>>>> Also we did understand =E2=80=9Cresolution=E2=80=9D the sa= me way as you when we proposed=C2=A0
>>>> the strong parent hash (sorry for the confusion).
>>>>
>>>> But we obviously really want to understand if/why using re= solution is=C2=A0
>>>> insecure. Ultimately, the security property we care about = is that privacy=C2=A0
>>>> and authenticity of application messages holds. The Parent= Hash mechanism=C2=A0
>>>> helps us ensure this holds also for epochs in adversariall= y generated=C2=A0
>>>> groups, as long as the adversary does not control any leav= es in this epoch=C2=A0
>>>> (i.e. does not know the signing key of the leaf). So to re= ally see if your=C2=A0
>>>> examples break security, it would be good to see if they l= et us violate=C2=A0
>>>> this security goal.
>>>>
>>>> To see why we believe the new parent hash notion (i.e. wit= h resolutions)=C2=A0
>>>> achieves this, let us first clarify what technical propert= y about (even=C2=A0
>>>> adversarially produced) ratchet trees we want from verifyi= ng parent hashes.
>>>> It=E2=80=99s not that the adversary can=E2=80=99t produce = manipulated trees at all. It=E2=80=99s
>>>> that the only manipulations she is able to do will not let= her produce a
>>>> tree that violates the tree invariant. That=E2=80=99s beca= use (in our model) when=C2=A0
>>>> the tree invariant holds then we can show that the epoch i= s secure.
>>>>
>>>> So some manipulations *are* possible. They are just =E2=80= =9Cbenign=E2=80=9D. For example,
>>>> suppose adversary A controls a leaf L with HPKE key pk in = tree T (i.e. she
>>>> knows the signing key of L=E2=80=99s owner). Then A can co= nstruct a new tree T=E2=80=99=C2=A0
>>>> identical to T but where leaf L has pk=E2=80=99 !=3D pk (s= ay, by performing a commit=C2=A0
>>>> at leaf L to obtain T=E2=80=99). But for this, in T=E2=80= =99 leaf L must still be=C2=A0
>>>> controlled by A. We call this manipulation =E2=80=9Cbenign= =E2=80=9D because even though A=C2=A0
>>>> might now break privacy of application messages in epoch w= ith tree T=E2=80=99 it=C2=A0
>>>> doesnt violate our security goal because privacy is condit= ioned on A *not*=C2=A0
>>>> controlling any leaves.
>>>>
>>>> Conversely, one thing A can *not* do is the following. Say= T=E2=80=99 has a node V
>>>> with HPKE public key pk0 such that A knows corresponding s= k0. Then for T=E2=80=99=C2=A0
>>>> to pass verification, it must contain a leaf controlled by= A. This holds=C2=A0
>>>> since for T=E2=80=99 to pass verification there must be a = leaf in V=E2=80=99s subtree with=C2=A0
>>>> a signature covering a hash that includes pk0. I.e. some l= eaf must
>>>> =E2=80=9Cattest=E2=80=9D to having inserted pk0 into T=E2= =80=99. (Recall that in our model the
>>>> adversary can=E2=80=99t just leak sk0 alone. They must lea= k a full state of some
>>>> client which also means leaking the client's signing k= ey.)
>>>>
>>>> So our question to you is the following. (Does this make s= ense? And) we=E2=80=99re=C2=A0
>>>> not exactly sure what you have in mind when you say =E2=80= =9Cswapping out two leaf=C2=A0
>>>> nodes=E2=80=9D. But we think it would only be a problem if= it is not benign. Is=C2=A0
>>>> this true for your attack? Could you expand a bit on what = tree
>>>> manipulation you have in mind?
>>>>
>>>> Best, Jo=C3=ABl& Marta
>>>>
>>>> ----------------------------------------------------------= ----------------------
>>>>
>>>>
>>>>
>> *From:* MLS <mls-bounces@ietf.org
>> <mailto:mls-bounces@ietf.org>=C2=A0<mailto:mls-bounces@ietf.org
>> <mailto:mls-bounces@ietf.org>>> on behalf of
>>>> Hubert Chathi <hubertc@matrix.org
>>>> <mailto:hubertc@matrix.org>=C2=A0<mailto:hubertc@matrix.org
>>>> <mailto:hubertc@matrix.org>>> *Sent:*=C2=A0
>>>> Thursday, December 31, 2020 5:36:53 PM *To:*=C2=A0mls@ietf.org <mailto:mls@ietf.org>=C2=A0 >>>> <mailto:mls@ietf.org <mailto:mls@ietf.org>> *Subject:* Re: [MLS] New Parent Hash
>>>>
>>>> I think that if you use "descendants" as you def= ine it, then calculating=C2=A0
>>>> the parent_hash will become O(n) all the time, rather than= O(log n) in the
>>>> best-case, since the size of the descendants list will be = O(n).=C2=A0 I'm not=C2=A0
>>>> sure if there's a good way to maintain O(log n) and st= ill provide the=C2=A0
>>>> desired security.
>>>>
>>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote:
>>>>> Hi Jo=C3=ABl, Daniel and Marta,
>>>>>
>>>>> I just implemented the stronger parent hash scheme you= proposed in the=C2=A0
>>>>> way it is described in the spec now. The good news is = that it is=C2=A0
>>>>> implementable, the bad news is that is does not solve = the problem you=C2=A0
>>>>> initially describe. Specifically, swapping out two lea= f nodes still goes=C2=A0
>>>>> undetected.
>>>>>
>>>>> I think it is due to a terminology conflict, but it wo= uld be great if
>>>>> you could validate that assumption. In 7.4 you introdu= ce the notion of=C2=A0
>>>>> =E2=80=9Coriginal child resolution=E2=80=9D as " = the array of HPKEPublicKey values of
>>>>> the nodes in the resolution of S=E2=80=9D. The term = =E2=80=9Cresolution=E2=80=9D is defined in
>>>>> 5.2. It is essentially a way of dealing with blank nod= es by substituting
>>>>> them with the first non-blank descendants you find whe= n descending the
>>>>> subtree of a node. Here is my assumption: You probably= thought the
>>>>> resolution would cover all non-blank descendants of a = node, not just the
>>>>> first non-blank descendant. In that case we would need= another function
>>>>> that does that (let=E2=80=99s call it =E2=80=9Cdescend= ants=E2=80=9D).
>>>>>
>>>>> If we look at the example of 5.2:
>>>>>
>>>>>=C2=A0 =C2=A0 - The resolution of node 3 is the list [A= , CD, C] - The descendants
>>>>> of node 3 is the list [A, CD, C, D]
>>>>>
>>>>>=C2=A0 =C2=A0 - The resolution of node 5 is the list [C= D] - The descendants of node=C2=A0
>>>>> 5 is the list [CD, C, D] (we just need to additionally= filter out C,=C2=A0
>>>>> because it is an unmerged leaf of node 5)
>>>>>
>>>>> Here is a code snippet of what the =E2=80=9Cdescendant= s=E2=80=9D function would look
>>>>> like (sorry that it=E2=80=99s Rust, not Python):
>>>>>
>>>>> fn descendants(x: NodeIndex, size: LeafIndex) -> Ve= c<NodeIndex> { if=C2=A0
>>>>> level(x) =3D=3D 0 { vec![x] } else { let left_child = =3D left(x); let=C2=A0
>>>>> right_child =3D right(x, size); [ descendants(left_chi= ld, size), vec![x],=C2=A0
>>>>> descendants(right_child, size), ] .concat() } }
>>>>>
>>>>> There=E2=80=99s a more efficient implementation of cou= rse, this is just to=C2=A0
>>>>> illustrate.
>>>>>
>>>>> In other words, the new =E2=80=9Coriginal child resolu= tion=E2=80=9D of S would be the=C2=A0
>>>>> subtree under S, but with filtered-out blank nodes and= unmerged leaves
>>>>> of S.
>>>>>
>>>>> If my assumption is correct, I=E2=80=99ll follow up qu= ickly with a PR since this=C2=A0
>>>>> is currently a blocker for interop based on draft-11.<= br> >>>>>
>>>>> Thanks
>>>>>
>>>>> Raphael
>>>>>
>>>>>
>>>>>
>>>>>> On 12. Nov 2020, at 22:14, Joel Alwen <jalwen@wickr.com
>>>>>> <mailto:jalwen@wickr.com>=C2=A0
>>>>>> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>>> wrote:
>>>>>>
>>>>>> Hey people,
>>>>>>
>>>>>> Just a quick heads up that Daniel, Marta and I put= in a PR with a new=C2=A0
>>>>>> version of strong parent hash to prevent the attac= ks from the earlier=C2=A0
>>>>>> thread. We tried to make it as minimal as we could= to help with=C2=A0
>>>>>> deniability while still preventing the attacks per= mitted by weak
>>>>>> parent hashes.
>>>>>>
>>>>>> In a nutshell, when computing parent_hash at node = v with parent p and=C2=A0
>>>>>> sibling w we include - p's HPKE pubkey - p'= ;s parent_hash value and -=C2=A0
>>>>>> HPKE pub keys in the resolution of w except for th= ose belonging to=C2=A0
>>>>>> leaves unmerged at p.
>>>>>>
>>>>>> As a sanity check, notice that as long as p's = keys remain the same one=C2=A0
>>>>>> can always recompute the same parent_hash value at= v as was initially=C2=A0
>>>>>> computed by the member that set p's keys. (In = other words, new members=C2=A0
>>>>>> can verify that the stored parent_hash values matc= h whats in the
>>>>>> tree.) In particular, that's coz as long as p&= #39;s keys are unchanged so
>>>>>> is the resolution of w. The only exception are lea= ves being added as
>>>>>> unmerged at w. But those leaves are also added as = unmerged at p so they
>>>>>> are left out of the hash.
>>>>>>
>>>>>> As for deniability, at least parent_hash only bind= s HPKE keys and=C2=A0
>>>>>> nothing else (like, say, credentials or signatures= ). Its the best we=C2=A0
>>>>>> were able to come up with for now...
>>>>>>
>>>>>> - jo=C3=ABl
>>>>>>
>>>>>> _______________________________________________ ML= S mailing list=C2=A0
>>>>>> = MLS@ietf.org <mailto:MLS@ietf.org>=C2=A0<mailto:MLS@ietf.org
>>>>>> <mailto:MLS@ietf.org>>=C2=A0
>>>>>> https://www.ietf.org/mailman/listi= nfo/mls
>>>>>> <https://www.ietf.org/mailman/l= istinfo/mls>
>>>> <https://www.ietf.org/mailman/listinfo/= mls
>>>> <https://www.ietf.org/mailman/listinfo/= mls>>
>>>>>
>>>>> _______________________________________________ MLS ma= iling list=C2=A0
>>>>> MLS@= ietf.org <mailto:M= LS@ietf.org>=C2=A0<mailto:MLS@ietf.org <mailto:MLS@ietf.org>>=C2=A0
>>>>> https://www.ietf.org/mailman/listinfo/= mls
>>>>> <https://www.ietf.org/mailman/listi= nfo/mls>
>>>> <https://www.ietf.org/mailman/listinfo/= mls
>>>> <https://www.ietf.org/mailman/listinfo/= mls>>
>>>>>
>>>>
>>>> _______________________________________________ MLS mailin= g list=C2=A0
>>>> MLS@ietf= .org <mailto:MLS@i= etf.org>=C2=A0<mailto:MLS@ietf.org <mailto:MLS@ietf.org>>=C2=A0
>>>> https://www.ietf.org/mailman/listinfo/mls=
>>>> <https://www.ietf.org/mailman/listinfo/= mls>=C2=A0
>>>> <https://www.ietf.org/mailman/listinfo/= mls
>>>> <https://www.ietf.org/mailman/listinfo/= mls>>
>

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000007b92c605b8284e3f-- From nobody Wed Jan 6 06:31:59 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 EDED43A0D05 for ; Wed, 6 Jan 2021 06:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.262, 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 baEtVJUYOeq3 for ; Wed, 6 Jan 2021 06:31:55 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 C3D323A0D04 for ; Wed, 6 Jan 2021 06:31:54 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id g20so5370742ejb.1 for ; Wed, 06 Jan 2021 06:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=41tTnfwvYiDoX25L+y2ACVnPW4HqGhvWd5Gy2/r0jCo=; b=jcd66hN0lqMPDoWA6YeViveN2uTCMFH5NMRvmMcP27GPK58FrmwaGmSuc59fqpe51x S03KARvRJCsrd/h7hhZYkxVn7tul2XqFD+NdBMnlL1zOX6j/l1xd4NjGfGBZW6Aw6YVl coWkH+gKS3eaNO5LoNocTDXJoEg3fJwjAGPIm6xrLrmeTdOtwSb9Hj2fEQbfoL3WSCR/ dzuT2AtFOKCICBvVq/rj1gRwkdAGzh+Vh2AM7PbOCJY9ZAhc/OT1qGrlAus+1KuCxLnP AKjxc26/cHBPf1zgukdxczd+MMo2m91qMXwGDPMOjhhhldkHtIJHh07NQt5YaYDzHEwW af6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=41tTnfwvYiDoX25L+y2ACVnPW4HqGhvWd5Gy2/r0jCo=; b=W4lGtUDeYl+mmTg0vPSz6qSepegIXbwCxC9Z/DwYcZee4Z0Qgdxn4W+l+wsZA8SK2B 4BQM2UC8SWw/M1Wug04a5crIdDc21V8EfHRz9t+DXr8ckiXyD8PlWHzzik5phh4s52oG 9M7WJoPahvrSPvANAy6nj/KONVnwaTpRTt0ERgwvWu3hVJZrwPqGul7Kc1ThOExQdNBm mt3R6MBgmcatS0KjLGEXXOoszSCFyXZ7GANdPH+l2kCvaIj8jsGn8J4wZEPJD35gEQOJ 0iSJ5ONK0AiwKYrNdDbTsmRUSw0f1D3jLQUgHLW7yzmEA/xYYi3ebTWeX9nH8Ol8FMGq LMFQ== X-Gm-Message-State: AOAM530E0AGdQcphdyvUrVPpGpxg31maWU7UWj0U0O6SS+5kueb5SQ7R KYEDxjaKxLn+zYk18Rzvj/bpZGmpVeiDtg== X-Google-Smtp-Source: ABdhPJw/WUmo+qDU3WLz3blR+M7xr/Qsfv9HHE1LCcCGqv2R4rF29dzlDI+g9Cdgvcaw9rzAEYAQ5Q== X-Received: by 2002:a17:907:2506:: with SMTP id y6mr3067423ejl.53.1609943512998; Wed, 06 Jan 2021 06:31:52 -0800 (PST) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id cf17sm1513391edb.16.2021.01.06.06.31.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Jan 2021 06:31:52 -0800 (PST) To: Richard Barnes Cc: Raphael Robert , "mls@ietf.org" , Mularczyk Marta References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> <4135BB5E-4C35-4EFF-91B6-1615C3560F1E@wire.com> <54f2ca71-89e1-1ca3-b783-2ad774564127@wickr.com> From: Joel Alwen Message-ID: <9bfee582-1227-754a-c70f-d59012e6ea82@wickr.com> Date: Wed, 6 Jan 2021 15:31:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] New Parent Hash 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: Wed, 06 Jan 2021 14:31:58 -0000 Responding inline... On 05/01/2021 15:48, Richard Barnes wrote: > Note: I am assuming that the "descendant hash" would be tree-structured like > the parent hash; it just would cover only the HPKE public keys instead of the > whole nodes. This would be a departure from the original Benjamin-Karthik approach as they included the Tree Hash of the co-path child when computing the Parent Hash of a node. Tree Hash covers more than the HPKE pks (e.g. the whole key package at a leaf and (in recent drafts) also the list of unmerged leaves at each node). So including only the HPKE leaves in a subtree introduces a 3rd hash for a node which would have to be computed and maintained by all members... I'm not sure that's worth it. I'm also not 100% clear yet on what the verification algorithm is when joining a group. Here's what I'm missing: For tree T and node V in T with child node W let PH(T,V,W) be the parent hash of V in T using co-path child W. Say, at time (epoch) t1 node V in ratchet tree T1 was just assigned a new HPKE key pair with direct path child U and co-path child W. Later, you join the group (and V still has the same PK as in T1). You get the current tree T2 and want check PH(T1,V,W) is stored at U. Can anyone with a clearer picture than me (e.g. Richard?) sketch the algo to recompute PH(T1,V,W) given tree T2? Pseudocode, text whatever. (Or if that's not efficient on its own maybe sketch how to recompute PH(T,X,Y) you'd want to compute as part of verification. Amortization could help here since, done right, you may be able to reuse work from pasts PH computations in the subequent ones.) > From an implementation point of view, there's not a ton of difference between > these two I dunno... My guess is such tree verification would be more complicated (if not even asymptotically worse) than the resolution version from in Draft 11... E.g. one issue is that, because of unmerged leaves, sometimes we have to do compute hashes of multiple subsets of PKs from a nodes subtree. Here's an example. Extend the above example as follows: - Unmerged leaf Z was added to W's subtree at time t3 : t1 < t3 < t2. - Parent P of V gets an HPKE key with co-path child V at time t4 : t3 < t4 < t2. - Let W be not blank in T2. To verify tree T2 we must compute both PH(T1,V,W) and PH(T4,P,V). For the resolution approach its pretty simple. For PH(T1,V,W) get W's resolution in T2 and remove Z (as Z is also be unmerged at V). For PH(T4,P,V) get P's resolution and remove any leaves that are unmerged at P. But for the descendants approach I think you need a fair bit more work. For PH(T1,V,W) you need the hash of W's descendent *excluding Z*. But for PH(T4,P,V) you need the hash of W's descendents *including Z*. I think that means having to re-visit every node from Z to W when computing PH(T4,P,V) despite having already visited all but P while computing PH(T1,V,W). In any case, I without some clearer idea of the verification algorithm I can't say I'd be in favor of switching to a descendant based Parent Hash. - Joël > - The "resolution" approach (in draft-11), which incorporates the minimum > information necessary to assure the tree invariant - The "descendants" > approach, which binds in the entire structure of the tree (in units of HPKE > keys) > > From an implementation point of view, there's not a ton of difference > between these two, but the "descendants" approach seems a bit nicer to me. > In the "resolution" case, you can re-use resolution logic; in the > "descendants" case, you can re-use the "update the changed nodes" logic that > the tree hash requires. If anything, the "descendants" approach is a little > more "static", in that you can store the descendant hashes on the nodes, then > at parent-hash time, you can just grab the descendant-hash from the > appropriate child. A tree-structured hash also seems easier to get right > than making sure the resolution is in the right order, and it's compatible > with the idea that you mainly need to know about the copath of an UpdatePath > in order to process it. > > From a security POV, it seems like either is acceptable, since they both > enforce the tree invariant. The extra structure enforcement doesn't seem > like it adds much in terms of security, but it does seem a little easier to > think about, since you don't have to keep in mind the caveat that the > structure can change below the resolution points. > > So net/net, I have a slight preference for the "descendants" approach, if > people are OK with the extra rigidity. > > --Richard > > --Richard > > On Mon, Jan 4, 2021 at 8:33 AM Joel Alwen > wrote: > > > On 02/01/2021 18:02, Raphael Robert wrote: >> Thanks Marta and Joël for the explanation! That was the delta that was >> missing for my understanding and it’s definitely good to have that on >> list. > > Yes, good call. FYI there's a MUCH more complete discussion of the security > properties of MLS we've analyzed, the adversarial and communication models > we used and the actual security proof in eprint/2020/1327. (We'll be updating > it soon to include our security analysis of the new parent hash scheme.) > >> Just for context, what I had in mind was something that was not as >> detrimental to the membership deniability. I think in that respect both the >> “resolution” and the “descendants” approach are equivalent. > > I agree that the resolution method is hardly deniable in any formal sense I > know of. Switching from signing (hashes of) the entire list of certs of > everyone in a subtree to "only" signing HPKE pubkeys in the resolution does > feel like a pretty superficial improvement for deniability. :-/ To me, the > advantage of using resolutions is the simplicity & efficiency compared to > using descendants. > > TBH, for deniability I think there's a whole family of impossibilities > waiting to be formalized here (like the one in Thm. 1 of eprint/2019/1153). > Asynchronous + authenticated + (strongly?!) deniable + no global trusted > setup + communication complexity sub-linear in the group size? Seems very > hard to me (in my non-expert opinion). My guess is that real compromises in > the model / design goals need to be made to get (even just weak) > deniability. >> I’d however like to leave it as an open question whether we shouldn’t > reconsider locking down entire subtrees as a security-in-depth measure if we > can convince ourselves the performance toll is not too high. > > If we can do it, without paying too much of an efficiency price, then by all > means why not? I'm still curious what we'd be getting though. E.g. what needs > to happen so that hashing in descendants is secure but using only the > resolution isn't? > >> The tree hash has to be calculated for every epoch change anyway and it’s > always in O(n). > > For my own edification: I would have thought computing the new tree hash at > the root after a commit to p proposals requires at most ~ O(p*log(n)) actual > hash calls + as many memory lookups no? Let L_p be the leaves modified by > the proposals. The root of any subtree with no leaf in L_p has the same tree > hash as before the commit. So by storing tree hashes as we compute them we > can replace computing unchanged subtree tree hashes with a lookup. What am I > missing here? > > - Joël > > >>> On 1. Jan 2021, at 23:10, Joel Alwen >>> >> wrote: >>> >>> Servus Raphael, >>> >>>> Happy New Year >>> >>> Same to you! Here's hoping the new one will be a tad happier than the > last. ;-) >>> >>> As for why "resolutions": The impetus to look for a new approach after >>> our initial proposal came from a comment in your email on the Fri, 23 >>> October > 2020 >>> 18:23 UTC in the thread "Weak vs. Strong Tree Authentication". There you > wrote: >>> >>>> Going for fully hashing the tree nodes as described locks down the >>>> whole tree structure, making any reshuffling impossible. Maybe there is >>>> a more lightweight approach that would yield the same result without >>>> “provid[ing] irrefutable evidence that the signing key's owner was in a >>>> group with (at least some) of the other members in the group”, but I >>>> can’t think of anything right now. >>> >>> That was an intriguing challenge and got us thinking. The result is the > current >>> Parent Hash definition using resolutions. We realized that to buy wiggle > room in >>> not locking down as much of the tree (especially, not locking down other > members >>> identities into the hash) we could pay a "price" that actually doesn't > harm the >>> security we've been aiming for. Namely, we can allow the adversary some >>> more tree manipulation but still only benign ones that dont actually >>> allow her to break the security property we've been aiming for. >> >> Just for context, what I had in mind was something that was not as >> detrimental to the membership deniability. I think in that respect both >> the > “resolution” and >> the “descendants” approach are equivalent. That being said, this looks >> quite elegant! >> >>> In retrospect, a second reason to use resolutions is efficiency (though > to fair, >>> that was really a coincidence rather than an explicit goal of the >>> redesign). Initially, we had been thinking of simply having parent hash >>> include tree > hash >>> as in the Benjamin-Karthik (BK) proposal of days yore. But we realized >>> that since then MLS had introduced Unmerged Leaves which meant that the >>> tree > hash of >>> some nodes can change between when they are assigned their HPKE key and >>> later when a new member wants to verify the parent hash of the node. In >>> other words the BK approach was broken by unmerged leaves. So, to make >>> the "include the whole subtree in parent hash" approach work, it seems >>> new members would, for each node being verified, traverse the nodes full >>> sub-tree so as to weed out those nodes that were added after the >>> to-be-verified node got its HPKE > key. (I >>> believe this is the O(n) time that Hubert is referring too?) In contrast, >>> the new version of parent hash (using resolutions) has the potential to >>> be much faster; it requires hashing less data but also visiting less of >>> the tree. > E.g. >>> when verifying near the root the difference can be as much as visiting > order n >>> nodes vs. visiting 1 node in the new construction. >>> >>> The more blanks & unmerged leaves in the tree the more the new >>> construction collapses to the old one. But only in the most extreme case >>> do they actually reach parity and the new approach is never slower than >>> the old. >>> >>> Needless to say, we didn't implement this stuff though, let alone > benchmark the >>> 2 approaches so any hard data elucidating what the actual difference is > would be >>> very welcome. Still, the new approach can only be as fast or faster (but > never >>> slower) than the new one. Nor do I think it's any more complicated to > define or >>> implement. And from a security perspective they both let MLS meet our > security >>> definition. So regardless of how small the speed up is (and ignoring the > locking >>> in the tree discussion above) it's still not clear to me why we'd want >>> to > switch >>> back. >>> >>> A meaningful attack that only works on the new but not old construction > would be >>> one very quick way of changing my mind though! :-) But, I believe such >>> an > attack >>> would require either new adversarial capabilities and/or break a new >>> security property we didn't consider. (For the adversaries & security we >>> considered, there is no security loss with the new approach compared to >>> the old one.) >> >> I think we are now fully aligned on the definitions and the performance >> implications and now that we have better documentation we can continue > with the >> interim effort. >> >> I’d however like to leave it as an open question whether we shouldn’t > reconsider >> locking down entire subtrees as a security-in-depth measure if we can >> convince ourselves the performance toll is not too high. For example, I’m >> wondering if there isn’t a clever way to combine the tree > hash >> and the parent hash. The tree hash has to be calculated for every epoch >> change anyway and it’s always in O(n). >> >> Thanks >> >> Raphael >> >>> >>> - Joël >>> >>> On 01/01/2021 17:30, Raphael Robert wrote: >>>> Thanks for the lengthy explanation! >>>> >>>> I’m glad we are on the same page regarding the definition of the > resolution. >>>> I think I understand where the misunderstanding is coming from. >>>> >>>> Initially you proposed a “strong hash” solution on the ML (on Oct 23 >>>> 2020) that was the following: >>>> >>>> "strong parent_hash" : Define parent_hash to include tree_hash (and >>>> tree_hash to *not* include parent_hash). The tree_hash of a node covers >>>> all values in the subtree rooted at that node (except the >>>> parent_hashes and signatures). So basically something like this: - >>>> leaf.tree_hash := H(leaf.data) - node.tree_hash := H(node.data, >>>> node.lchild.tree_hash, node.rchild.tree_hash) - root.parent_hash := 0 - >>>> node.parent_hash := H(node.parent.tree_hash, node.parent.parent_hash). >>>> >>>> This definition did include the whole subtree and therefore I was >>>> assuming that this would also end up in the spec change. As far as I >>>> now understand, you went for a more lightweight approach where you say >>>> that just using the resolution is enough, because pinning all nodes in >>>> the subtree is not necessary and would only prevent “benign” attacks. I >>>> guess I missed the > part >>>> where you switched from one concept to the other. >>>> >>>> What I discovered during implementation is that when you only use the >>>> resolution approach and the tree has no blanks, you are not always able >>>> to detect if the attacker has swapped two leaves. This might indeed >>>> just be a benign attack in the sense that the tree invariant is not >>>> violated. >>>> >>>> At this point I don’t have strong arguments for or against using the >>>> resolution approach, I would have to think about it some more. Just as >>>> a reminder for context, the original concept by Benjamin and Karthik >>>> was “parent hash covers the tree hash”. That’s pretty much what you >>>> initially proposed, except that it also covered the KeyPackage at the >>>> leaf level, not just the HPKE public key. >>>> >>>> My question right now would be: What is the benefit of the lightweight >>>> resolution-based approach? If it’s just efficiency, we should look at > whether >>>> there’s really that much to gain. >>>> >>>> On efficiency: The parent hashes are verified in two instances: a) when >>>> a new member joins the group and validates the public tree it received >>>> and b) when a member receives a full Commit from another member. >>>> >>>> Re a): The spec now says "Moreover, when joining a group, new members >>>> MUST authenticate each non-blank parent node P. A parent node P is > authenticated”. >>>> This means the effort is linear to start with. Depending on how you >>>> define the operation, it is even worse than linear. Say the tree has n >>>> leaves and therefore 2n-1 nodes. For every node, we need to iterate >>>> over at least a > part >>>> of the subtree and collect public keys that we then concatenate. We end >>>> up only hashing once per node, but with a variable size payload. I >>>> think the cost of navigating the subtree and collecting the keys is >>>> O(log n) for the “resolution approach and O(n) for the “descendants" >>>> approach and the cost of hashing is linearly proportional to the size >>>> of the payload. If we assume that hashing is the most expensive >>>> operation, the total cost would be O(n * log n) for “resolution” and >>>> O(n ^ 2) for “descendants". >>>> >>>> Re b): It is very similar to a), except that we only have to iterate >>>> over log n nodes of the direct path, not the whole tree. That means >>>> that the total effort is O(log n * log n) for “resolution” and O(n * >>>> log n) for “descendants”. >>>> >>>> There’s clearly a difference in terms of efficiency between the two >>>> approaches. That being said, we should keep in mind that for small > payloads, >>>> hashing is a lot faster than other cryptographic operations like e.g. >>>> producing and verifying signatures. Since a new joiner needs to also >>>> verify n signatures when joining a group, it could well be that the >>>> effort of verifying the parent hashes is negligible compared to the >>>> cost of verifying all signatures. >>>> >>>> In summary: I still don’t have strong arguments against the >>>> “resolution” approach, but I also have a feeling that the efficiency >>>> differences are not dramatic either. >>>> >>>> Happy New Year and thanks! >>>> >>>> Raphael >>>> >>>>> On 1. Jan 2021, at 15:48, Mularczyk Marta >>>>> >>>>> >>>> > >>>>> >>> >>>>> wrote: >>>>> >>>>> Hi Raphael, >>>>> >>>>> Thanks for explaining! Using "descendants" is definitely better for >>>>> security, but also, as Hubert mentioned, less efficient. >>>>> >>>>> Also we did understand “resolution” the same way as you when we >>>>> proposed the strong parent hash (sorry for the confusion). >>>>> >>>>> But we obviously really want to understand if/why using resolution is >>>>> insecure. Ultimately, the security property we care about is that >>>>> privacy and authenticity of application messages holds. The Parent >>>>> Hash mechanism helps us ensure this holds also for epochs in >>>>> adversarially generated groups, as long as the adversary does not >>>>> control any leaves in this epoch (i.e. does not know the signing key >>>>> of the leaf). So to really see if your examples break security, it >>>>> would be good to see if they let us violate this security goal. >>>>> >>>>> To see why we believe the new parent hash notion (i.e. with >>>>> resolutions) achieves this, let us first clarify what technical >>>>> property about (even adversarially produced) ratchet trees we want >>>>> from verifying parent hashes. It’s not that the adversary can’t >>>>> produce manipulated trees at all. It’s that the only manipulations >>>>> she is able to do will not let her produce a tree that violates the >>>>> tree invariant. That’s because (in our model) when the tree invariant >>>>> holds then we can show that the epoch is secure. >>>>> >>>>> So some manipulations *are* possible. They are just “benign”. For >>>>> example, suppose adversary A controls a leaf L with HPKE key pk in >>>>> tree T (i.e. she knows the signing key of L’s owner). Then A can >>>>> construct a new tree T’ identical to T but where leaf L has pk’ != pk >>>>> (say, by performing a commit at leaf L to obtain T’). But for this, >>>>> in T’ leaf L must still be controlled by A. We call this manipulation >>>>> “benign” because even though A might now break privacy of application >>>>> messages in epoch with tree T’ it doesnt violate our security goal >>>>> because privacy is conditioned on A *not* controlling any leaves. >>>>> >>>>> Conversely, one thing A can *not* do is the following. Say T’ has a >>>>> node V with HPKE public key pk0 such that A knows corresponding sk0. >>>>> Then for T’ to pass verification, it must contain a leaf controlled >>>>> by A. This holds since for T’ to pass verification there must be a >>>>> leaf in V’s subtree with a signature covering a hash that includes >>>>> pk0. I.e. some leaf must “attest” to having inserted pk0 into T’. >>>>> (Recall that in our model the adversary can’t just leak sk0 alone. >>>>> They must leak a full state of some client which also means leaking >>>>> the client's signing key.) >>>>> >>>>> So our question to you is the following. (Does this make sense? And) >>>>> we’re not exactly sure what you have in mind when you say “swapping >>>>> out two leaf nodes”. But we think it would only be a problem if it is >>>>> not benign. Is this true for your attack? Could you expand a bit on >>>>> what tree manipulation you have in mind? >>>>> >>>>> Best, Joël& Marta >>>>> >>>>> > -------------------------------------------------------------------------------- > > >>>> >>>>> >>>>> >>> *From:* MLS >>> > >>> >>> on behalf >>> of >>>>> Hubert Chathi >>>>> > >>>>> >>> *Sent:* >>>>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org > > >>>>> >> *Subject:* Re: [MLS] New Parent Hash >>>>> >>>>> I think that if you use "descendants" as you define it, then >>>>> calculating the parent_hash will become O(n) all the time, rather >>>>> than O(log n) in the best-case, since the size of the descendants >>>>> list will be O(n). I'm not sure if there's a good way to maintain >>>>> O(log n) and still provide the desired security. >>>>> >>>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: >>>>>> Hi Joël, Daniel and Marta, >>>>>> >>>>>> I just implemented the stronger parent hash scheme you proposed in >>>>>> the way it is described in the spec now. The good news is that it >>>>>> is implementable, the bad news is that is does not solve the >>>>>> problem you initially describe. Specifically, swapping out two leaf >>>>>> nodes still goes undetected. >>>>>> >>>>>> I think it is due to a terminology conflict, but it would be great >>>>>> if you could validate that assumption. In 7.4 you introduce the >>>>>> notion of “original child resolution” as " the array of >>>>>> HPKEPublicKey values of the nodes in the resolution of S”. The term >>>>>> “resolution” is defined in 5.2. It is essentially a way of dealing >>>>>> with blank nodes by substituting them with the first non-blank >>>>>> descendants you find when descending the subtree of a node. Here is >>>>>> my assumption: You probably thought the resolution would cover all >>>>>> non-blank descendants of a node, not just the first non-blank >>>>>> descendant. In that case we would need another function that does >>>>>> that (let’s call it “descendants”). >>>>>> >>>>>> If we look at the example of 5.2: >>>>>> >>>>>> - The resolution of node 3 is the list [A, CD, C] - The >>>>>> descendants of node 3 is the list [A, CD, C, D] >>>>>> >>>>>> - The resolution of node 5 is the list [CD] - The descendants of >>>>>> node 5 is the list [CD, C, D] (we just need to additionally filter >>>>>> out C, because it is an unmerged leaf of node 5) >>>>>> >>>>>> Here is a code snippet of what the “descendants” function would >>>>>> look like (sorry that it’s Rust, not Python): >>>>>> >>>>>> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { >>>>>> if level(x) == 0 { vec![x] } else { let left_child = left(x); let >>>>>> right_child = right(x, size); [ descendants(left_child, size), >>>>>> vec![x], descendants(right_child, size), ] .concat() } } >>>>>> >>>>>> There’s a more efficient implementation of course, this is just to >>>>>> illustrate. >>>>>> >>>>>> In other words, the new “original child resolution” of S would be >>>>>> the subtree under S, but with filtered-out blank nodes and unmerged >>>>>> leaves of S. >>>>>> >>>>>> If my assumption is correct, I’ll follow up quickly with a PR since >>>>>> this is currently a blocker for interop based on draft-11. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Raphael >>>>>> >>>>>> >>>>>> >>>>>>> On 12. Nov 2020, at 22:14, Joel Alwen >>>>>>> > >>>>>>> > >>> wrote: >>>>>>> >>>>>>> Hey people, >>>>>>> >>>>>>> Just a quick heads up that Daniel, Marta and I put in a PR with a >>>>>>> new version of strong parent hash to prevent the attacks from the >>>>>>> earlier thread. We tried to make it as minimal as we could to >>>>>>> help with deniability while still preventing the attacks >>>>>>> permitted by weak parent hashes. >>>>>>> >>>>>>> In a nutshell, when computing parent_hash at node v with parent p >>>>>>> and sibling w we include - p's HPKE pubkey - p's parent_hash >>>>>>> value and - HPKE pub keys in the resolution of w except for those >>>>>>> belonging to leaves unmerged at p. >>>>>>> >>>>>>> As a sanity check, notice that as long as p's keys remain the >>>>>>> same one can always recompute the same parent_hash value at v as >>>>>>> was initially computed by the member that set p's keys. (In other >>>>>>> words, new members can verify that the stored parent_hash values >>>>>>> match whats in the tree.) In particular, that's coz as long as >>>>>>> p's keys are unchanged so is the resolution of w. The only >>>>>>> exception are leaves being added as unmerged at w. But those >>>>>>> leaves are also added as unmerged at p so they are left out of >>>>>>> the hash. >>>>>>> >>>>>>> As for deniability, at least parent_hash only binds HPKE keys and >>>>>>> nothing else (like, say, credentials or signatures). Its the >>>>>>> best we were able to come up with for now... >>>>>>> >>>>>>> - joël >>>>>>> >>>>>>> _______________________________________________ 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 Fri Jan 8 08:40:21 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 6A9E43A1124 for ; Fri, 8 Jan 2021 08:40:19 -0800 (PST) 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, 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 (1024-bit key) header.d=sn3rd.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 kmRcVQag8Igb for ; Fri, 8 Jan 2021 08:40:18 -0800 (PST) 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 1B82C3A1123 for ; Fri, 8 Jan 2021 08:40:18 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id 19so8917057qkm.8 for ; Fri, 08 Jan 2021 08:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=RUGdb37NA23H/h1G8BHi0YYcbLCYy5OXN7G74ilUi6E=; b=OJffTa87s4DhQ/5VmJK8SMleM7ToEtVO5f4CKvDG5oba/I1cfbB5UX+Ik2BWPKBICK RLYUErea4KdW8mjtnd8XBRaPI2bfkfw5hKVBm+eLBp+vfY8FOjuobkP16r9lKMdl9lwK ir4YSkbY73n7hT0SuV1sA9sMHYVL/Eg9KMduI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=RUGdb37NA23H/h1G8BHi0YYcbLCYy5OXN7G74ilUi6E=; b=ZLtGgiVSnq5VTPRokXZoXU9/9jopsJ36+cd7jiKc596f7ENLJdx/WUtl7x4o4dHVhQ 4t9JLKpcKhLJsHls6WaX29Q9iqTWDXFOL0r46lLMGeqF8KITTDtT82kmJ9ndowZ+vBC+ 1rxdwYqnXccOf1oNJKTDNqGlotJTPYdKfWDLF4/YU/Qrr8LktlJEQppNQ7godlsb4YSL 9QhTi36QVHbQCrxNy+FKXABj2rvm47w32jsEHViiHbbYXlIhPZEs67ELWLOrSp4Ods2i FUq8K9r90seD2EUPj4UjH1AL7mc0RxpK8GOOJW/FjRUQKRJHjtC+Q+ILyRW8y4pVUuoe Obfw== X-Gm-Message-State: AOAM532Kwi2MZx+zYMftmJh8Hyx/IPXfxoNvVgU1ro9e2P1C6k1rMUT4 Y9N7bDR01VUD+cQRitGeg45y52od+iRIEA== X-Google-Smtp-Source: ABdhPJyE5CtbNz1trylROVubPHRuJsUltOJn91J3P9t47ouPrtj5+bU8RpsZmBvnr1JmHcXy8J+Srg== X-Received: by 2002:a37:6382:: with SMTP id x124mr4632786qkb.398.1610124016821; Fri, 08 Jan 2021 08:40:16 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id 127sm5065248qkj.51.2021.01.08.08.40.15 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jan 2021 08:40:16 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <043DD707-8699-464D-8EE1-ED299B5AB741@sn3rd.com> Date: Fri, 8 Jan 2021 11:40:15 -0500 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [MLS] MLS@IETF109 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, 08 Jan 2021 16:40:19 -0000 The MLS WG will met at IETF 109. We requested a 1-hour slot [1] and = would like to solicit input from the WG for agenda requests. Please send = your agenda topics and an estimate for how much time you will need to = mls-chairs@ietf.org. Please note that we will prioritize security = reviews of the protocol, but we expect the majority of the the time be = spent discussing existing WG items. Nick and Sean [1] = https://mailarchive.ietf.org/arch/msg/mls/PRG11KlkAbSPyYSRUFsZl8-k92s/= From nobody Sat Jan 9 09:59:29 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 EA3243A13E8 for ; Sat, 9 Jan 2021 09:59:26 -0800 (PST) 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, 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 (1024-bit key) header.d=sn3rd.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 kQazg7RxPJvd for ; Sat, 9 Jan 2021 09:59:25 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 A123C3A114D for ; Sat, 9 Jan 2021 09:59:25 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id 75so13773745ilv.13 for ; Sat, 09 Jan 2021 09:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=b7wvGHJfzF/nawUU7yLwyI+b3h0j+DgIjmtQ6tR9lWA=; b=h4Mb6vztY0W7e4ufjdb442EbrD0ysH+Myv/Z5aPwgqFyHulhjYKhM/Y1NY8I9VnjzK ZgsmQCAj/X2Zor+yMikFEuVqShJhINZ7kRzjz+QB00ex7gcnurxfXHpGhqpCsgi7nK19 alN9SdOKl2GipqIHk/OSHGl/3CAkkr0QwPXvw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=b7wvGHJfzF/nawUU7yLwyI+b3h0j+DgIjmtQ6tR9lWA=; b=Kz+JTichVFcE6wN9L9iJNxvhmXFKxS3eMQVrZx4e2XA7GhI3Stg+/lUrheFlZniwTb 6pOSrYoK4kdvxx0MNdEOf/919m1aDGrEwlsLaONZvd7lLEKLKXWffLh7oZE89z5Ua7rU WXPuGqkaUcT9269NggZegqZQ83XnhUzrG1hO/McMCXAqN6JQq2tkce7ep85Tq/qfOLm0 auup13DR8LAZlB9PGWiiUTspKJrzDdC6ytcmy0jqz8MfAo4cak75dWps7OoLepxCK8GE R7R0ZBQjJ9flKJO9pa0rKbqA2s0+bCFn9Gq+kGBXnOAyWFUQIdjGlrnZAA2FRpnRFyxN B/jQ== X-Gm-Message-State: AOAM532G4QbvVo0GosgIXWspAKAmSuFPP24/r4G72D2gxTyZlkSL8b4x 5lLFTgW0B+NVcfKGuudTq7THZm50MrAMbQ== X-Google-Smtp-Source: ABdhPJwNPzi21TwbjMvi2ehMTrAu9+svLzIaOESXbLFy1mky3UVB2bXVhqYhIy/XofvdQQhPmjGjdg== X-Received: by 2002:a05:6e02:1a8f:: with SMTP id k15mr3367315ilv.37.1610215164486; Sat, 09 Jan 2021 09:59:24 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id r19sm3249779ila.70.2021.01.09.09.59.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jan 2021 09:59:23 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <25336761-DA4F-4D91-ACF7-51C03CAB68CE@sn3rd.com> Date: Sat, 9 Jan 2021 12:59:22 -0500 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [MLS] MLS@IETF100 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: Sat, 09 Jan 2021 17:59:27 -0000 The MLS WG will met at IETF 110. We requested a 1-hour slot [1] and = would like to solicit input from the WG for agenda requests. Please send = your agenda topics and an estimate for how much time you will need to = mls-chairs@ietf.org. Please note that we will prioritize security = reviews of the protocol, but we expect the majority of the the time be = spent discussing existing WG items. Nick and Sean [1] = https://mailarchive.ietf.org/arch/msg/mls/PRG11KlkAbSPyYSRUFsZl8-k92s/= From nobody Tue Jan 12 07:52:21 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 2876C3A09E8 for ; Tue, 12 Jan 2021 07:52:19 -0800 (PST) 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 UJDojTGG7wPz for ; Tue, 12 Jan 2021 07:52:12 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 568383A09E1 for ; Tue, 12 Jan 2021 07:52:12 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id c7so2232713qke.1 for ; Tue, 12 Jan 2021 07:52:12 -0800 (PST) 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=ffOmpD7A51p4LX7/WtjhJIQK1IOzO/EwuKJlRXPNbb0=; b=pEXodi8jlW7oF7cyxYvN8ALT+vB2WnTlvKcMOSkZyRCcXWnx0sKYyE32Xg7htPfPKR HAGgU52vJt512f65i/csPRC1P7H5UUlaI4K5/ITFIv7Td9HTzOTKPkmuWtX5aCKuyRpu h9lRZRfXmlX3TSCTY3od8+JFT+sctditPJk/jPc3LvO0Gsi+KZqtwBh73bh94/fpLw/J sFItnvTWCZx9Zp08F4gFPVPK5Bx9JMSDX5+CwxGwY4hyOnkBM57myS64aQEgnFHhgr2k c5fJC65P5aC97m/e6F1NbPnlltjyY2hIoXswFGqI4sxQGHn9YPksSvFAPOTwCrualL8i oIBA== 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=ffOmpD7A51p4LX7/WtjhJIQK1IOzO/EwuKJlRXPNbb0=; b=t4lp/gh+ZztRwn/cJfioYnXGCE33qs4X/rvEue+TKIqfnbWaz7B1L1YOkmOicIOgjY yCbSzS4Yzoxv1zpP5UPpl4L9U3rtAd1yRxIqbkm2FCfOutKNL78OeRQHQ4VrPqtHlJWK KQW+YnJykrexhmv0lGuvzE+1RNX+p17pXu0/BUbHTTOQIBKuvKkKeqJvTtc1L2NLEU9Z g47BUZQa5pYr0YJsZEX7k+4W99cSmcLowUB4UY/3DEjvej+NrGwUVc/pBhG0FSAmUNSM utUXi67b68CogaVllBdius0F57PN7VYVGl5ekDRoMlwsrVU0uFXRTKeEY3UaCWL4eTbn zKRQ== X-Gm-Message-State: AOAM530vW0HrOxjr9VfO3PHKbgOxPuj7tyk4FRsDYC1SwZvI5aNyDR7+ JZQoJmjhaHcW32jbpsTAMQf4EwHgCCGxWyoFTND2mnurh6Y= X-Google-Smtp-Source: ABdhPJxnZIYqoGqbHN87j4iG0x3ztsw0gBCKy2JTTsyNk+lQLe3syv3r1ZzH8qh8vgyG1P8aiZuwRxJxodgIMU5beLM= X-Received: by 2002:a05:620a:2009:: with SMTP id c9mr5232036qka.159.1610466730992; Tue, 12 Jan 2021 07:52:10 -0800 (PST) MIME-Version: 1.0 References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> <4135BB5E-4C35-4EFF-91B6-1615C3560F1E@wire.com> <54f2ca71-89e1-1ca3-b783-2ad774564127@wickr.com> <9bfee582-1227-754a-c70f-d59012e6ea82@wickr.com> In-Reply-To: <9bfee582-1227-754a-c70f-d59012e6ea82@wickr.com> From: Richard Barnes Date: Tue, 12 Jan 2021 10:51:53 -0500 Message-ID: To: Joel Alwen Cc: Raphael Robert , "mls@ietf.org" , Mularczyk Marta Content-Type: multipart/alternative; boundary="0000000000006c88a305b8b60139" Archived-At: Subject: Re: [MLS] New Parent Hash 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: Tue, 12 Jan 2021 15:52:19 -0000 --0000000000006c88a305b8b60139 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Jo=C3=ABl, Sorry for a bit of delay, took me a minute to get my thoughts in order. But the answer seems pretty clear to me now. tl;dr: On further thought, the =E2=80=9Cdescendants=E2=80=9D approach is O(= N^2) for new joiners. So I=E2=80=99m inclined keep the resolution approach. The parent hash for a parent node P incorporates some input from a copath child C. If I understand the security requirement correctly, you want the copath child=E2=80=99s input to describe the subtree as it was the last tim= e the parent node was updated. In at least enough detail to tell which private keys received the private key for P, possibly in more detail. This input needs to remain constant as long as the public key in P remains the same, so that validation is possible. That raises the question of what details of the subtree under C can change without the public key in P also being changed. The only operations we have that change the tree are Add, Update, Remove, and Commit. Update and Remove within the subtree result in the path from the leaf being blanked, so the parent node will also be blanked. A Commit within the subtree will also replace P. Only Add changes the subtree without changing the parent, and the only change it makes is to (1) set the key package at the affected leaf, and (2) add an unmerged leaf to the leaf node=E2=80=99s ancestors. This implies that you can =E2=80=9Crewind=E2=80=9D the state of the tree to= the state it was in when the parent node was set by (1) resetting the leaves in P.unmerged_leaves to blanks and (2) removing P.unmerged_leaves from all unmerged_leaves lists in the subtree. This =E2=80=9Crewound=E2=80=9D tree = is constant over the lifetime over P.public_key, so any summary of it is suitable as an input to the parent hash, for example: * The resolution of the subtree root C [Alwen, Jost, Mularczyk] * The tree hash of the subtree [Bhargavan, Beurdouche] * A hash over the public keys [Robert, Barnes] =E2=80=94 though this is not sufficient to tell which nodes received P=E2=80=99s private key, and thus d= oes not meet the security goals The necessity of this =E2=80=9Crewind=E2=80=9D, though, means that the impl= ementation of the copath child input basically needs to be =E2=80=9Cdynamic=E2=80=9D. To= capture the resolution, the copath child input needs to capture the =E2=80=9Crewound=E2= =80=9D unmerged leaf state, which means that the copath child input depends on the parent as well as the copath child. I had been thinking that there was a =E2=80= =9Cstatic=E2=80=9D solution here, where you compute one thing per node, and update it when something below the node changed, like with the tree hash. Here, though, a node=E2=80=99s contribution to a parent hash depends on the parent, you wou= ld need to store several values per node, which removes any efficiency advantage. Returning to the =E2=80=9Cresolution=E2=80=9D vs. =E2=80=9Cdescendants=E2= =80=9D decision=E2=80=A6 The =E2=80=9Cdescendants=E2=80=9D option in this framing would entail computing either the tree hash or a =E2=80=9Ctree hash lite=E2=80=9D on the copath child=E2=80=99s subtree, whe= re the =E2=80=9Clite=E2=80=9D variant would omit some things from the leaves (e.g., only covering HPKE public keys). Because it has to be dynamic, that requires O(n) hash operations for a full Update Path, with each step in the tree doing ~2^khashes, with k increasing as you go up the tree. In other words, we have the following trade-off: * Resolution: Assures tree invariant only, costs ~log(N) ~ N hashes per update path node / parent hash * Descendants: Assures full tree structure, costs n hashes per update path node / parent hash These costs are borne by the sender and the receiver of an UpdatePath. A new joiner verifying a tree will have to verify ~N parent hashes, so the number of hash invocations will be O(N^2) in the worst case. (Side note: the verifier might actually have to do *double* that work, since it needs to test both of its children. We might want to add a =E2=80=9Clast updated= child=E2=80=9D bit next to the =E2=80=9Cparent hash=E2=80=9D field, so that the verifier c= an tell which one was more recently updated, and thus should be correct.) That latter cost factor of N makes the efficiency of the resolution approach seem even more important. While the extra rigidity from the descendant approach seems appealing, it doesn=E2=80=99t seem essential. Ne= t of all that, I=E2=80=99m inclined to keep the resolution approach. =E2=80=94Richard On Wed, Jan 6, 2021 at 9:31 AM Joel Alwen wrote: > Responding inline... > > On 05/01/2021 15:48, Richard Barnes wrote: > > Note: I am assuming that the "descendant hash" would be tree-structured > like > > the parent hash; it just would cover only the HPKE public keys instead > of the > > whole nodes. > > This would be a departure from the original Benjamin-Karthik approach as > they > included the Tree Hash of the co-path child when computing the Parent Has= h > of a > node. Tree Hash covers more than the HPKE pks (e.g. the whole key package > at a > leaf and (in recent drafts) also the list of unmerged leaves at each > node). So > including only the HPKE leaves in a subtree introduces a 3rd hash for a > node > which would have to be computed and maintained by all members... I'm not > sure > that's worth it. > > I'm also not 100% clear yet on what the verification algorithm is when > joining a > group. Here's what I'm missing: > > For tree T and node V in T with child node W let PH(T,V,W) be the parent > hash of > V in T using co-path child W. Say, at time (epoch) t1 node V in ratchet > tree T1 > was just assigned a new HPKE key pair with direct path child U and co-pat= h > child > W. Later, you join the group (and V still has the same PK as in T1). You > get the > current tree T2 and want check PH(T1,V,W) is stored at U. Can anyone with= a > clearer picture than me (e.g. Richard?) sketch the algo to recompute > PH(T1,V,W) > given tree T2? Pseudocode, text whatever. (Or if that's not efficient on > its own > maybe sketch how to recompute PH(T,X,Y) you'd want to compute as part of > verification. Amortization could help here since, done right, you may be > able to > reuse work from pasts PH computations in the subequent ones.) > > > From an implementation point of view, there's not a ton of difference > between > > these two > > I dunno... My guess is such tree verification would be more complicated > (if not > even asymptotically worse) than the resolution version from in Draft 11..= . > > E.g. one issue is that, because of unmerged leaves, sometimes we have to = do > compute hashes of multiple subsets of PKs from a nodes subtree. Here's an > example. Extend the above example as follows: > - Unmerged leaf Z was added to W's subtree at time t3 : t1 < t3 < t2. > - Parent P of V gets an HPKE key with co-path child V at time t4 : t3 < > t4 < t2. > - Let W be not blank in T2. > To verify tree T2 we must compute both PH(T1,V,W) and PH(T4,P,V). > > For the resolution approach its pretty simple. For PH(T1,V,W) get W's > resolution > in T2 and remove Z (as Z is also be unmerged at V). For PH(T4,P,V) get P'= s > resolution and remove any leaves that are unmerged at P. > > But for the descendants approach I think you need a fair bit more work. F= or > PH(T1,V,W) you need the hash of W's descendent *excluding Z*. But for > PH(T4,P,V) > you need the hash of W's descendents *including Z*. I think that means > having to > re-visit every node from Z to W when computing PH(T4,P,V) despite having > already > visited all but P while computing PH(T1,V,W). > > In any case, I without some clearer idea of the verification algorithm I > can't > say I'd be in favor of switching to a descendant based Parent Hash. > > - Jo=C3=ABl > > > > - The "resolution" approach (in draft-11), which incorporates the > minimum > > information necessary to assure the tree invariant - The "descendants" > > approach, which binds in the entire structure of the tree (in units of > HPKE > > keys) > > > > From an implementation point of view, there's not a ton of difference > > between these two, but the "descendants" approach seems a bit nicer to > me. > > In the "resolution" case, you can re-use resolution logic; in the > > "descendants" case, you can re-use the "update the changed nodes" logic > that > > the tree hash requires. If anything, the "descendants" approach is a > little > > more "static", in that you can store the descendant hashes on the nodes= , > then > > at parent-hash time, you can just grab the descendant-hash from the > > appropriate child. A tree-structured hash also seems easier to get rig= ht > > than making sure the resolution is in the right order, and it's > compatible > > with the idea that you mainly need to know about the copath of an > UpdatePath > > in order to process it. > > > > From a security POV, it seems like either is acceptable, since they bot= h > > enforce the tree invariant. The extra structure enforcement doesn't se= em > > like it adds much in terms of security, but it does seem a little easie= r > to > > think about, since you don't have to keep in mind the caveat that the > > structure can change below the resolution points. > > > > So net/net, I have a slight preference for the "descendants" approach, = if > > people are OK with the extra rigidity. > > > > --Richard > > > > --Richard > > > > On Mon, Jan 4, 2021 at 8:33 AM Joel Alwen > > wrote: > > > > > > On 02/01/2021 18:02, Raphael Robert wrote: > >> Thanks Marta and Jo=C3=ABl for the explanation! That was the delta tha= t was > >> missing for my understanding and it=E2=80=99s definitely good to have = that on > >> list. > > > > Yes, good call. FYI there's a MUCH more complete discussion of the > security > > properties of MLS we've analyzed, the adversarial and communication > models > > we used and the actual security proof in eprint/2020/1327. (We'll be > updating > > it soon to include our security analysis of the new parent hash scheme.= ) > > > >> Just for context, what I had in mind was something that was not as > >> detrimental to the membership deniability. I think in that respect bot= h > the > >> =E2=80=9Cresolution=E2=80=9D and the =E2=80=9Cdescendants=E2=80=9D app= roach are equivalent. > > > > I agree that the resolution method is hardly deniable in any formal > sense I > > know of. Switching from signing (hashes of) the entire list of certs of > > everyone in a subtree to "only" signing HPKE pubkeys in the resolution > does > > feel like a pretty superficial improvement for deniability. :-/ To me, > the > > advantage of using resolutions is the simplicity & efficiency compared = to > > using descendants. > > > > TBH, for deniability I think there's a whole family of impossibilities > > waiting to be formalized here (like the one in Thm. 1 of > eprint/2019/1153). > > Asynchronous + authenticated + (strongly?!) deniable + no global truste= d > > setup + communication complexity sub-linear in the group size? Seems ve= ry > > hard to me (in my non-expert opinion). My guess is that real compromise= s > in > > the model / design goals need to be made to get (even just weak) > > deniability. > >> I=E2=80=99d however like to leave it as an open question whether we sh= ouldn=E2=80=99t > > reconsider locking down entire subtrees as a security-in-depth measure > if we > > can convince ourselves the performance toll is not too high. > > > > If we can do it, without paying too much of an efficiency price, then b= y > all > > means why not? I'm still curious what we'd be getting though. E.g. what > needs > > to happen so that hashing in descendants is secure but using only the > > resolution isn't? > > > >> The tree hash has to be calculated for every epoch change anyway and > it=E2=80=99s > > always in O(n). > > > > For my own edification: I would have thought computing the new tree has= h > at > > the root after a commit to p proposals requires at most ~ O(p*log(n)) > actual > > hash calls + as many memory lookups no? Let L_p be the leaves modified = by > > the proposals. The root of any subtree with no leaf in L_p has the same > tree > > hash as before the commit. So by storing tree hashes as we compute them > we > > can replace computing unchanged subtree tree hashes with a lookup. What > am I > > missing here? > > > > - Jo=C3=ABl > > > > > >>> On 1. Jan 2021, at 23:10, Joel Alwen > > >>> >> wrote: > >>> > >>> Servus Raphael, > >>> > >>>> Happy New Year > >>> > >>> Same to you! Here's hoping the new one will be a tad happier than the > > last. ;-) > >>> > >>> As for why "resolutions": The impetus to look for a new approach afte= r > >>> our initial proposal came from a comment in your email on the Fri, 23 > >>> October > > 2020 > >>> 18:23 UTC in the thread "Weak vs. Strong Tree Authentication". There > you > > wrote: > >>> > >>>> Going for fully hashing the tree nodes as described locks down the > >>>> whole tree structure, making any reshuffling impossible. Maybe there > is > >>>> a more lightweight approach that would yield the same result without > >>>> =E2=80=9Cprovid[ing] irrefutable evidence that the signing key's own= er was in > a > >>>> group with (at least some) of the other members in the group=E2=80= =9D, but I > >>>> can=E2=80=99t think of anything right now. > >>> > >>> That was an intriguing challenge and got us thinking. The result is t= he > > current > >>> Parent Hash definition using resolutions. We realized that to buy > wiggle > > room in > >>> not locking down as much of the tree (especially, not locking down > other > > members > >>> identities into the hash) we could pay a "price" that actually doesn'= t > > harm the > >>> security we've been aiming for. Namely, we can allow the adversary so= me > >>> more tree manipulation but still only benign ones that dont actually > >>> allow her to break the security property we've been aiming for. > >> > >> Just for context, what I had in mind was something that was not as > >> detrimental to the membership deniability. I think in that respect bot= h > >> the > > =E2=80=9Cresolution=E2=80=9D and > >> the =E2=80=9Cdescendants=E2=80=9D approach are equivalent. That being = said, this looks > >> quite elegant! > >> > >>> In retrospect, a second reason to use resolutions is efficiency (thou= gh > > to fair, > >>> that was really a coincidence rather than an explicit goal of the > >>> redesign). Initially, we had been thinking of simply having parent ha= sh > >>> include tree > > hash > >>> as in the Benjamin-Karthik (BK) proposal of days yore. But we realize= d > >>> that since then MLS had introduced Unmerged Leaves which meant that t= he > >>> tree > > hash of > >>> some nodes can change between when they are assigned their HPKE key a= nd > >>> later when a new member wants to verify the parent hash of the node. = In > >>> other words the BK approach was broken by unmerged leaves. So, to mak= e > >>> the "include the whole subtree in parent hash" approach work, it seem= s > >>> new members would, for each node being verified, traverse the nodes > full > >>> sub-tree so as to weed out those nodes that were added after the > >>> to-be-verified node got its HPKE > > key. (I > >>> believe this is the O(n) time that Hubert is referring too?) In > contrast, > >>> the new version of parent hash (using resolutions) has the potential = to > >>> be much faster; it requires hashing less data but also visiting less = of > >>> the tree. > > E.g. > >>> when verifying near the root the difference can be as much as visitin= g > > order n > >>> nodes vs. visiting 1 node in the new construction. > >>> > >>> The more blanks & unmerged leaves in the tree the more the new > >>> construction collapses to the old one. But only in the most extreme > case > >>> do they actually reach parity and the new approach is never slower th= an > >>> the old. > >>> > >>> Needless to say, we didn't implement this stuff though, let alone > > benchmark the > >>> 2 approaches so any hard data elucidating what the actual difference = is > > would be > >>> very welcome. Still, the new approach can only be as fast or faster > (but > > never > >>> slower) than the new one. Nor do I think it's any more complicated to > > define or > >>> implement. And from a security perspective they both let MLS meet our > > security > >>> definition. So regardless of how small the speed up is (and ignoring > the > > locking > >>> in the tree discussion above) it's still not clear to me why we'd wan= t > >>> to > > switch > >>> back. > >>> > >>> A meaningful attack that only works on the new but not old constructi= on > > would be > >>> one very quick way of changing my mind though! :-) But, I believe suc= h > >>> an > > attack > >>> would require either new adversarial capabilities and/or break a new > >>> security property we didn't consider. (For the adversaries & security > we > >>> considered, there is no security loss with the new approach compared = to > >>> the old one.) > >> > >> I think we are now fully aligned on the definitions and the performanc= e > >> implications and now that we have better documentation we can continue > > with the > >> interim effort. > >> > >> I=E2=80=99d however like to leave it as an open question whether we sh= ouldn=E2=80=99t > > reconsider > >> locking down entire subtrees as a security-in-depth measure if we can > >> convince ourselves the performance toll is not too high. For example, > I=E2=80=99m > >> wondering if there isn=E2=80=99t a clever way to combine the tree > > hash > >> and the parent hash. The tree hash has to be calculated for every epoc= h > >> change anyway and it=E2=80=99s always in O(n). > >> > >> Thanks > >> > >> Raphael > >> > >>> > >>> - Jo=C3=ABl > >>> > >>> On 01/01/2021 17:30, Raphael Robert wrote: > >>>> Thanks for the lengthy explanation! > >>>> > >>>> I=E2=80=99m glad we are on the same page regarding the definition of= the > > resolution. > >>>> I think I understand where the misunderstanding is coming from. > >>>> > >>>> Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D solution on t= he ML (on Oct 23 > >>>> 2020) that was the following: > >>>> > >>>> "strong parent_hash" : Define parent_hash to include tree_hash (and > >>>> tree_hash to *not* include parent_hash). The tree_hash of a node > covers > >>>> all values in the subtree rooted at that node (except the > >>>> parent_hashes and signatures). So basically something like this: - > >>>> leaf.tree_hash :=3D H(leaf.data) - node.tree_hash :=3D H(node.data, > >>>> node.lchild.tree_hash, node.rchild.tree_hash) - root.parent_hash := =3D 0 > - > >>>> node.parent_hash :=3D H(node.parent.tree_hash, node.parent.parent_ha= sh). > >>>> > >>>> This definition did include the whole subtree and therefore I was > >>>> assuming that this would also end up in the spec change. As far as I > >>>> now understand, you went for a more lightweight approach where you s= ay > >>>> that just using the resolution is enough, because pinning all nodes = in > >>>> the subtree is not necessary and would only prevent =E2=80=9Cbenign= =E2=80=9D attacks. > I > >>>> guess I missed the > > part > >>>> where you switched from one concept to the other. > >>>> > >>>> What I discovered during implementation is that when you only use th= e > >>>> resolution approach and the tree has no blanks, you are not always > able > >>>> to detect if the attacker has swapped two leaves. This might indeed > >>>> just be a benign attack in the sense that the tree invariant is not > >>>> violated. > >>>> > >>>> At this point I don=E2=80=99t have strong arguments for or against u= sing the > >>>> resolution approach, I would have to think about it some more. Just = as > >>>> a reminder for context, the original concept by Benjamin and Karthik > >>>> was =E2=80=9Cparent hash covers the tree hash=E2=80=9D. That=E2=80= =99s pretty much what you > >>>> initially proposed, except that it also covered the KeyPackage at th= e > >>>> leaf level, not just the HPKE public key. > >>>> > >>>> My question right now would be: What is the benefit of the lightweig= ht > >>>> resolution-based approach? If it=E2=80=99s just efficiency, we shou= ld look at > > whether > >>>> there=E2=80=99s really that much to gain. > >>>> > >>>> On efficiency: The parent hashes are verified in two instances: a) > when > >>>> a new member joins the group and validates the public tree it receiv= ed > >>>> and b) when a member receives a full Commit from another member. > >>>> > >>>> Re a): The spec now says "Moreover, when joining a group, new member= s > >>>> MUST authenticate each non-blank parent node P. A parent node P is > > authenticated=E2=80=9D. > >>>> This means the effort is linear to start with. Depending on how you > >>>> define the operation, it is even worse than linear. Say the tree has= n > >>>> leaves and therefore 2n-1 nodes. For every node, we need to iterate > >>>> over at least a > > part > >>>> of the subtree and collect public keys that we then concatenate. We > end > >>>> up only hashing once per node, but with a variable size payload. I > >>>> think the cost of navigating the subtree and collecting the keys is > >>>> O(log n) for the =E2=80=9Cresolution approach and O(n) for the =E2= =80=9Cdescendants" > >>>> approach and the cost of hashing is linearly proportional to the siz= e > >>>> of the payload. If we assume that hashing is the most expensive > >>>> operation, the total cost would be O(n * log n) for =E2=80=9Cresolut= ion=E2=80=9D and > >>>> O(n ^ 2) for =E2=80=9Cdescendants". > >>>> > >>>> Re b): It is very similar to a), except that we only have to iterate > >>>> over log n nodes of the direct path, not the whole tree. That means > >>>> that the total effort is O(log n * log n) for =E2=80=9Cresolution=E2= =80=9D and O(n * > >>>> log n) for =E2=80=9Cdescendants=E2=80=9D. > >>>> > >>>> There=E2=80=99s clearly a difference in terms of efficiency between = the two > >>>> approaches. That being said, we should keep in mind that for small > > payloads, > >>>> hashing is a lot faster than other cryptographic operations like e.g= . > >>>> producing and verifying signatures. Since a new joiner needs to also > >>>> verify n signatures when joining a group, it could well be that the > >>>> effort of verifying the parent hashes is negligible compared to the > >>>> cost of verifying all signatures. > >>>> > >>>> In summary: I still don=E2=80=99t have strong arguments against the > >>>> =E2=80=9Cresolution=E2=80=9D approach, but I also have a feeling tha= t the efficiency > >>>> differences are not dramatic either. > >>>> > >>>> Happy New Year and thanks! > >>>> > >>>> Raphael > >>>> > >>>>> On 1. Jan 2021, at 15:48, Mularczyk Marta > >>>>> > > >>>>> >>>>> > > >>>>> > > >>> > >>>>> wrote: > >>>>> > >>>>> Hi Raphael, > >>>>> > >>>>> Thanks for explaining! Using "descendants" is definitely better for > >>>>> security, but also, as Hubert mentioned, less efficient. > >>>>> > >>>>> Also we did understand =E2=80=9Cresolution=E2=80=9D the same way as= you when we > >>>>> proposed the strong parent hash (sorry for the confusion). > >>>>> > >>>>> But we obviously really want to understand if/why using resolution = is > >>>>> insecure. Ultimately, the security property we care about is that > >>>>> privacy and authenticity of application messages holds. The Parent > >>>>> Hash mechanism helps us ensure this holds also for epochs in > >>>>> adversarially generated groups, as long as the adversary does not > >>>>> control any leaves in this epoch (i.e. does not know the signing ke= y > >>>>> of the leaf). So to really see if your examples break security, it > >>>>> would be good to see if they let us violate this security goal. > >>>>> > >>>>> To see why we believe the new parent hash notion (i.e. with > >>>>> resolutions) achieves this, let us first clarify what technical > >>>>> property about (even adversarially produced) ratchet trees we want > >>>>> from verifying parent hashes. It=E2=80=99s not that the adversary c= an=E2=80=99t > >>>>> produce manipulated trees at all. It=E2=80=99s that the only manipu= lations > >>>>> she is able to do will not let her produce a tree that violates the > >>>>> tree invariant. That=E2=80=99s because (in our model) when the tree= invariant > >>>>> holds then we can show that the epoch is secure. > >>>>> > >>>>> So some manipulations *are* possible. They are just =E2=80=9Cbenign= =E2=80=9D. For > >>>>> example, suppose adversary A controls a leaf L with HPKE key pk in > >>>>> tree T (i.e. she knows the signing key of L=E2=80=99s owner). Then = A can > >>>>> construct a new tree T=E2=80=99 identical to T but where leaf L has= pk=E2=80=99 !=3D pk > >>>>> (say, by performing a commit at leaf L to obtain T=E2=80=99). But f= or this, > >>>>> in T=E2=80=99 leaf L must still be controlled by A. We call this ma= nipulation > >>>>> =E2=80=9Cbenign=E2=80=9D because even though A might now break priv= acy of application > >>>>> messages in epoch with tree T=E2=80=99 it doesnt violate our securi= ty goal > >>>>> because privacy is conditioned on A *not* controlling any leaves. > >>>>> > >>>>> Conversely, one thing A can *not* do is the following. Say T=E2=80= =99 has a > >>>>> node V with HPKE public key pk0 such that A knows corresponding sk0= . > >>>>> Then for T=E2=80=99 to pass verification, it must contain a leaf co= ntrolled > >>>>> by A. This holds since for T=E2=80=99 to pass verification there mu= st be a > >>>>> leaf in V=E2=80=99s subtree with a signature covering a hash that i= ncludes > >>>>> pk0. I.e. some leaf must =E2=80=9Cattest=E2=80=9D to having inserte= d pk0 into T=E2=80=99. > >>>>> (Recall that in our model the adversary can=E2=80=99t just leak sk0= alone. > >>>>> They must leak a full state of some client which also means leaking > >>>>> the client's signing key.) > >>>>> > >>>>> So our question to you is the following. (Does this make sense? And= ) > >>>>> we=E2=80=99re not exactly sure what you have in mind when you say = =E2=80=9Cswapping > >>>>> out two leaf nodes=E2=80=9D. But we think it would only be a proble= m if it is > >>>>> not benign. Is this true for your attack? Could you expand a bit on > >>>>> what tree manipulation you have in mind? > >>>>> > >>>>> Best, Jo=C3=ABl& Marta > >>>>> > >>>>> > > > -------------------------------------------------------------------------= ------- > > > > > >>>> > >>>>> > >>>>> > >>> *From:* MLS > >>> > > > > >>> >>> on > behalf > >>> of > >>>>> Hubert Chathi > >>>>> > > > > >>>>> >>> *Sent:* > >>>>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org > > > > >>>>> > >> *Subject:* Re: [MLS] New Parent Hash > >>>>> > >>>>> I think that if you use "descendants" as you define it, then > >>>>> calculating the parent_hash will become O(n) all the time, rather > >>>>> than O(log n) in the best-case, since the size of the descendants > >>>>> list will be O(n). I'm not sure if there's a good way to maintain > >>>>> O(log n) and still provide the desired security. > >>>>> > >>>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: > >>>>>> Hi Jo=C3=ABl, Daniel and Marta, > >>>>>> > >>>>>> I just implemented the stronger parent hash scheme you proposed in > >>>>>> the way it is described in the spec now. The good news is that it > >>>>>> is implementable, the bad news is that is does not solve the > >>>>>> problem you initially describe. Specifically, swapping out two lea= f > >>>>>> nodes still goes undetected. > >>>>>> > >>>>>> I think it is due to a terminology conflict, but it would be great > >>>>>> if you could validate that assumption. In 7.4 you introduce the > >>>>>> notion of =E2=80=9Coriginal child resolution=E2=80=9D as " the arr= ay of > >>>>>> HPKEPublicKey values of the nodes in the resolution of S=E2=80=9D.= The term > >>>>>> =E2=80=9Cresolution=E2=80=9D is defined in 5.2. It is essentially = a way of dealing > >>>>>> with blank nodes by substituting them with the first non-blank > >>>>>> descendants you find when descending the subtree of a node. Here i= s > >>>>>> my assumption: You probably thought the resolution would cover all > >>>>>> non-blank descendants of a node, not just the first non-blank > >>>>>> descendant. In that case we would need another function that does > >>>>>> that (let=E2=80=99s call it =E2=80=9Cdescendants=E2=80=9D). > >>>>>> > >>>>>> If we look at the example of 5.2: > >>>>>> > >>>>>> - The resolution of node 3 is the list [A, CD, C] - The > >>>>>> descendants of node 3 is the list [A, CD, C, D] > >>>>>> > >>>>>> - The resolution of node 5 is the list [CD] - The descendants of > >>>>>> node 5 is the list [CD, C, D] (we just need to additionally filter > >>>>>> out C, because it is an unmerged leaf of node 5) > >>>>>> > >>>>>> Here is a code snippet of what the =E2=80=9Cdescendants=E2=80=9D f= unction would > >>>>>> look like (sorry that it=E2=80=99s Rust, not Python): > >>>>>> > >>>>>> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec { > >>>>>> if level(x) =3D=3D 0 { vec![x] } else { let left_child =3D left(x)= ; let > >>>>>> right_child =3D right(x, size); [ descendants(left_child, size), > >>>>>> vec![x], descendants(right_child, size), ] .concat() } } > >>>>>> > >>>>>> There=E2=80=99s a more efficient implementation of course, this is= just to > >>>>>> illustrate. > >>>>>> > >>>>>> In other words, the new =E2=80=9Coriginal child resolution=E2=80= =9D of S would be > >>>>>> the subtree under S, but with filtered-out blank nodes and unmerge= d > >>>>>> leaves of S. > >>>>>> > >>>>>> If my assumption is correct, I=E2=80=99ll follow up quickly with a= PR since > >>>>>> this is currently a blocker for interop based on draft-11. > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Raphael > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On 12. Nov 2020, at 22:14, Joel Alwen > > >>>>>>> > > >>>>>>> > > >>> wrote: > >>>>>>> > >>>>>>> Hey people, > >>>>>>> > >>>>>>> Just a quick heads up that Daniel, Marta and I put in a PR with a > >>>>>>> new version of strong parent hash to prevent the attacks from the > >>>>>>> earlier thread. We tried to make it as minimal as we could to > >>>>>>> help with deniability while still preventing the attacks > >>>>>>> permitted by weak parent hashes. > >>>>>>> > >>>>>>> In a nutshell, when computing parent_hash at node v with parent p > >>>>>>> and sibling w we include - p's HPKE pubkey - p's parent_hash > >>>>>>> value and - HPKE pub keys in the resolution of w except for those > >>>>>>> belonging to leaves unmerged at p. > >>>>>>> > >>>>>>> As a sanity check, notice that as long as p's keys remain the > >>>>>>> same one can always recompute the same parent_hash value at v as > >>>>>>> was initially computed by the member that set p's keys. (In other > >>>>>>> words, new members can verify that the stored parent_hash values > >>>>>>> match whats in the tree.) In particular, that's coz as long as > >>>>>>> p's keys are unchanged so is the resolution of w. The only > >>>>>>> exception are leaves being added as unmerged at w. But those > >>>>>>> leaves are also added as unmerged at p so they are left out of > >>>>>>> the hash. > >>>>>>> > >>>>>>> As for deniability, at least parent_hash only binds HPKE keys and > >>>>>>> nothing else (like, say, credentials or signatures). Its the > >>>>>>> best we were able to come up with for now... > >>>>>>> > >>>>>>> - jo=C3=ABl > >>>>>>> > >>>>>>> _______________________________________________ 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 > > > > > --0000000000006c88a305b8b60139 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Jo=C3=ABl,

Sorry for a bit of delay, took me a = minute to get my thoughts in order.=C2=A0 But the answer seems pretty clear= to me now.

tl;dr: On further thought, the =E2=80=9Cdescendants=E2= =80=9D approach is O(N^2) for new joiners.=C2=A0 So I=E2=80=99m inclined ke= ep the resolution approach.

The parent hash for a parent node P inco= rporates some input from a copath child C.=C2=A0 If I understand the securi= ty requirement correctly, you want the copath child=E2=80=99s input to desc= ribe the subtree as it was the last time the parent node was updated.=C2=A0= In at least enough detail to tell which private keys received the private = key for P, possibly in more detail.=C2=A0 This input needs to remain consta= nt as long as the public key in P remains the same, so that validation is p= ossible.

That raises the question of what details of the subtree und= er C can change without the public key in P also being changed. =C2=A0 The = only operations we have that change the tree are Add, Update, Remove, and C= ommit.=C2=A0 Update and Remove within the subtree result in the path from t= he leaf being blanked, so the parent node will also be blanked.=C2=A0 A Com= mit within the subtree will also replace P.=C2=A0 Only Add changes the subt= ree without changing the parent, and the only change it makes is to (1) set= the key package at the affected leaf, and (2) add an unmerged leaf to the = leaf node=E2=80=99s ancestors.

This implies that you can =E2=80=9Cre= wind=E2=80=9D the state of the tree to the state it was in when the parent = node was set by (1) resetting =C2=A0the leaves in P.unmerged_leaves to blan= ks and (2) removing P.unmerged_leaves from all unmerged_leaves lists in the= subtree.=C2=A0 This =E2=80=9Crewound=E2=80=9D tree is constant over the li= fetime over P.public_key, so any summary of it is suitable as an input to t= he parent hash, for example:

* The resolution of the subtree root C = [Alwen, Jost, Mularczyk]
* The tree hash of the subtree [Bhargavan, Beur= douche]
* A hash over the public keys [Robert, Barnes] =E2=80=94 though = this is not sufficient to tell which nodes received P=E2=80=99s private key= , and thus does not meet the security goals

The necessity of this = =E2=80=9Crewind=E2=80=9D, though, means that the implementation of the copa= th child input basically needs to be =E2=80=9Cdynamic=E2=80=9D.=C2=A0 To ca= pture the resolution, the copath child input needs to capture the =E2=80=9C= rewound=E2=80=9D unmerged leaf state, which means that the copath child inp= ut depends on the parent as well as the copath child.=C2=A0 I had been thin= king that there was a =E2=80=9Cstatic=E2=80=9D solution here, where you com= pute one thing per node, and update it when something below the node change= d, like with the tree hash.=C2=A0 Here, though, a node=E2=80=99s contributi= on to a parent hash depends on the parent, you would need to store several = values per node, which removes any efficiency advantage.

Returning t= o the =E2=80=9Cresolution=E2=80=9D vs. =E2=80=9Cdescendants=E2=80=9D decisi= on=E2=80=A6 The =E2=80=9Cdescendants=E2=80=9D option in this framing would = entail computing either the tree hash or a =E2=80=9Ctree hash lite=E2=80=9D= on the copath child=E2=80=99s subtree, where the =E2=80=9Clite=E2=80=9D va= riant would omit some things from the leaves (e.g., only covering HPKE publ= ic keys).=C2=A0 Because it has to be dynamic, that requires O(n) hash opera= tions for a full Update Path, with each step in the tree doing ~2^khashes, = with k increasing as you go up the tree.

In other words, we have the= following trade-off:

* Resolution: Assures tree invariant only, cos= ts ~log(N) ~ N hashes per update path node =C2=A0/ parent hash
* Descend= ants: Assures full tree structure, costs n hashes per update path node / pa= rent hash

These costs are borne by the sender and the receiver of an= UpdatePath.=C2=A0 A new joiner verifying a tree will have to verify ~N par= ent hashes, so the number of hash invocations will be O(N^2) in the worst c= ase. =C2=A0(Side note: the verifier might actually have to do *double* that= work, since it needs to test both of its children.=C2=A0 We might want to = add a =E2=80=9Clast updated child=E2=80=9D bit next to the =E2=80=9Cparent = hash=E2=80=9D field, so that the verifier can tell which one was more recen= tly updated, and thus should be correct.)

That latter cost factor of= N makes the efficiency of the resolution approach seem even more important= .=C2=A0 While the extra rigidity from the descendant approach seems appeali= ng, it doesn=E2=80=99t seem essential.=C2=A0 Net of all that, I=E2=80=99m i= nclined to keep the resolution approach.

=E2=80=94Richard
<= br>
On Wed,= Jan 6, 2021 at 9:31 AM Joel Alwen <jalwen@wickr.com> wrote:
Responding inline...

On 05/01/2021 15:48, Richard Barnes wrote:
> Note: I am assuming that the "descendant hash" would be tree= -structured like
> the parent hash; it just would cover only the HPKE public keys instead= of the
> whole nodes.

This would be a departure from the original Benjamin-Karthik approach as th= ey
included the Tree Hash of the co-path child when computing the Parent Hash = of a
node. Tree Hash covers more than the HPKE pks (e.g. the whole key package a= t a
leaf and (in recent drafts) also the list of unmerged leaves at each node).= So
including only the HPKE leaves in a subtree introduces a 3rd hash for a nod= e
which would have to be computed and maintained by all members... I'm no= t sure
that's worth it.

I'm also not 100% clear yet on what the verification algorithm is when = joining a
group. Here's what I'm missing:

For tree T and node V in T with child node W let PH(T,V,W) be the parent ha= sh of
V in T using co-path child W. Say, at time (epoch) t1 node V in ratchet tre= e T1
was just assigned a new HPKE key pair with direct path child U and co-path = child
W. Later, you join the group (and V still has the same PK as in T1). You ge= t the
current tree T2 and want check PH(T1,V,W) is stored at U. Can anyone with a=
clearer picture than me (e.g. Richard?) sketch the algo to recompute PH(T1,= V,W)
given tree T2? Pseudocode, text whatever. (Or if that's not efficient o= n its own
maybe sketch how to recompute PH(T,X,Y) you'd want to compute as part o= f
verification. Amortization could help here since, done right, you may be ab= le to
reuse work from pasts PH computations in the subequent ones.)

> From an implementation point of view, there's not a ton of differe= nce between
> these two

I dunno... My guess is such tree verification would be more complicated (if= not
even asymptotically worse) than the resolution version from in Draft 11...<= br>
E.g. one issue is that, because of unmerged leaves, sometimes we have to do=
compute hashes of multiple subsets of PKs from a nodes subtree. Here's = an
example. Extend the above example as follows:
=C2=A0- Unmerged leaf Z was added to W's subtree at time t3 : t1 < t= 3 < t2.
=C2=A0- Parent P of V gets an HPKE key with co-path child V at time t4 : t3= < t4 < t2.
=C2=A0- Let W be not blank in T2.
To verify tree T2 we must compute both PH(T1,V,W) and PH(T4,P,V).

For the resolution approach its pretty simple. For PH(T1,V,W) get W's r= esolution
in T2 and remove Z (as Z is also be unmerged at V). For PH(T4,P,V) get P= 9;s
resolution and remove any leaves that are unmerged at P.

But for the descendants approach I think you need a fair bit more work. For=
PH(T1,V,W) you need the hash of W's descendent *excluding Z*. But for P= H(T4,P,V)
you need the hash of W's descendents *including Z*. I think that means = having to
re-visit every node from Z to W when computing PH(T4,P,V) despite having al= ready
visited all but P while computing PH(T1,V,W).

In any case, I without some clearer idea of the verification algorithm I ca= n't
say I'd be in favor of switching to a descendant based Parent Hash.

- Jo=C3=ABl


> - The "resolution" approach (in draft-11), which incorporate= s the minimum
> information necessary to assure the tree invariant - The "descend= ants"
> approach, which binds in the entire structure of the tree (in units of= HPKE
> keys)
>
> From an implementation point of view, there's not a ton of differe= nce
> between these two, but the "descendants" approach seems a bi= t nicer to me.
> In the "resolution" case, you can re-use resolution logic; i= n the
> "descendants" case, you can re-use the "update the chan= ged nodes" logic that
> the tree hash requires.=C2=A0 If anything, the "descendants"= approach is a little
> more "static", in that you can store the descendant hashes o= n the nodes, then
> at parent-hash time, you can just grab the descendant-hash from the > appropriate child.=C2=A0 A tree-structured hash also seems easier to g= et right
> than making sure the resolution is in the right order, and it's co= mpatible
> with the idea that you mainly need to know about the copath of an Upda= tePath
> in order to process it.
>
> From a security POV, it seems like either is acceptable, since they bo= th
> enforce the tree invariant.=C2=A0 The extra structure enforcement does= n't seem
> like it adds much in terms of security, but it does seem a little easi= er to
> think about, since you don't have to keep in mind the caveat that = the
> structure can change below the resolution points.
>
> So net/net, I have a slight preference for the "descendants"= approach, if
> people are OK with the extra rigidity.
>
> --Richard
>
> --Richard
>
> On Mon, Jan 4, 2021 at 8:33 AM Joel Alwen <jalwen@wickr.com
> <mailto:jalwe= n@wickr.com>> wrote:
>
>
> On 02/01/2021 18:02, Raphael Robert wrote:
>> Thanks Marta and Jo=C3=ABl for the explanation! That was the delta= that was
>> missing for my understanding and it=E2=80=99s definitely good to h= ave that on
>> list.
>
> Yes, good call. FYI there's a MUCH more complete discussion of the= security
> properties of MLS we've analyzed, the adversarial and communicatio= n models
> we used and the actual security proof in eprint/2020/1327. (We'll = be updating
> it soon to include our security analysis of the new parent hash scheme= .)
>
>> Just for context, what I had in mind was something that was not as=
>> detrimental to the membership deniability. I think in that respect= both the
>> =E2=80=9Cresolution=E2=80=9D and the =E2=80=9Cdescendants=E2=80=9D= approach are equivalent.
>
> I agree that the resolution method is hardly deniable in any formal se= nse I
> know of. Switching from signing (hashes of) the entire list of certs o= f
> everyone in a subtree to "only" signing HPKE pubkeys in the = resolution does
> feel like a pretty superficial improvement for deniability. :-/ To me,= the
> advantage of using resolutions is the simplicity & efficiency comp= ared to
> using descendants.
>
> TBH, for deniability I think there's a whole family of impossibili= ties
> waiting to be formalized here (like the one in Thm. 1 of eprint/2019/1= 153).
> Asynchronous + authenticated + (strongly?!) deniable + no global trust= ed
> setup + communication complexity sub-linear in the group size? Seems v= ery
> hard to me (in my non-expert opinion). My guess is that real compromis= es in
> the model / design goals need to be made to get (even just weak)
> deniability.
>> I=E2=80=99d however like to leave it as an open question whether w= e shouldn=E2=80=99t
> reconsider locking down entire subtrees as a security-in-depth measure= if we
> can convince ourselves the performance toll is not too high.
>
> If we can do it, without paying too much of an efficiency price, then = by all
> means why not? I'm still curious what we'd be getting though. = E.g. what needs
> to happen so that hashing in descendants is secure but using only the =
> resolution isn't?
>
>> The tree hash has to be calculated for every epoch change anyway a= nd it=E2=80=99s
> always in O(n).
>
> For my own edification: I would have thought computing the new tree ha= sh at
> the root after a commit to p proposals requires at most ~ O(p*log(n)) = actual
> hash calls + as many memory lookups no? Let L_p be the leaves modified= by
> the proposals. The root of any subtree with no leaf in L_p has the sam= e tree
> hash as before the commit. So by storing tree hashes as we compute the= m we
> can replace computing unchanged subtree tree hashes with a lookup. Wha= t am I
> missing here?
>
> - Jo=C3=ABl
>
>
>>> On 1. Jan 2021, at 23:10, Joel Alwen <jalwen@wickr.com
> <mailto:jalwe= n@wickr.com>
>>> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>>> wrote:
>>>
>>> Servus Raphael,
>>>
>>>> Happy New Year
>>>
>>> Same to you! Here's hoping the new one will be a tad happi= er than the
> last. ;-)
>>>
>>> As for why "resolutions": The impetus to look for a = new approach after
>>> our initial proposal came from a comment in your email on the = Fri, 23
>>> October
> 2020
>>> 18:23 UTC in the thread "Weak vs. Strong Tree Authenticat= ion". There you
> wrote:
>>>
>>>> Going for fully hashing the tree nodes as described locks = down the
>>>> whole tree structure, making any reshuffling impossible. M= aybe there is
>>>> a more lightweight approach that would yield the same resu= lt without
>>>> =E2=80=9Cprovid[ing] irrefutable evidence that the signing= key's owner was in a
>>>> group with (at least some) of the other members in the gro= up=E2=80=9D, but I
>>>> can=E2=80=99t think of anything right now.
>>>
>>> That was an intriguing challenge and got us thinking. The resu= lt is the
> current
>>> Parent Hash definition using resolutions. We realized that to = buy wiggle
> room in
>>> not locking down as much of the tree (especially, not locking = down other
> members
>>> identities into the hash) we could pay a "price" tha= t actually doesn't
> harm the
>>> security we've been aiming for. Namely, we can allow the a= dversary some
>>> more tree manipulation but still only benign ones that dont ac= tually
>>> allow her to break the security property we've been aiming= for.
>>
>> Just for context, what I had in mind was something that was not as=
>> detrimental to the membership deniability. I think in that respect= both
>> the
> =E2=80=9Cresolution=E2=80=9D and
>> the =E2=80=9Cdescendants=E2=80=9D approach are equivalent. That be= ing said, this looks
>> quite elegant!
>>
>>> In retrospect, a second reason to use resolutions is efficienc= y (though
> to fair,
>>> that was really a coincidence rather than an explicit goal of = the
>>> redesign). Initially, we had been thinking of simply having pa= rent hash
>>> include tree
> hash
>>> as in the Benjamin-Karthik (BK) proposal of days yore. But we = realized
>>> that since then MLS had introduced Unmerged Leaves which meant= that the
>>> tree
> hash of
>>> some nodes can change between when they are assigned their HPK= E key and
>>> later when a new member wants to verify the parent hash of the= node. In
>>> other words the BK approach was broken by unmerged leaves. So,= to make
>>> the "include the whole subtree in parent hash" appro= ach work, it seems
>>> new members would, for each node being verified, traverse the = nodes full
>>> sub-tree so as to weed out those nodes that were added after t= he
>>> to-be-verified node got its HPKE
> key. (I
>>> believe this is the O(n) time that Hubert is referring too?) I= n contrast,
>>> the new version of parent hash (using resolutions) has the pot= ential to
>>> be much faster; it requires hashing less data but also visitin= g less of
>>> the tree.
> E.g.
>>> when verifying near the root the difference can be as much as = visiting
> order n
>>> nodes vs. visiting 1 node in the new construction.
>>>
>>> The more blanks & unmerged leaves in the tree the more the= new
>>> construction collapses to the old one. But only in the most ex= treme case
>>> do they actually reach parity and the new approach is never sl= ower than
>>> the old.
>>>
>>> Needless to say, we didn't implement this stuff though, le= t alone
> benchmark the
>>> 2 approaches so any hard data elucidating what the actual diff= erence is
> would be
>>> very welcome. Still, the new approach can only be as fast or f= aster (but
> never
>>> slower) than the new one. Nor do I think it's any more com= plicated to
> define or
>>> implement. And from a security perspective they both let MLS m= eet our
> security
>>> definition. So regardless of how small the speed up is (and ig= noring the
> locking
>>> in the tree discussion above) it's still not clear to me w= hy we'd want
>>> to
> switch
>>> back.
>>>
>>> A meaningful attack that only works on the new but not old con= struction
> would be
>>> one very quick way of changing my mind though! :-) But, I beli= eve such
>>> an
> attack
>>> would require either new adversarial capabilities and/or break= a new
>>> security property we didn't consider. (For the adversaries= & security we
>>> considered, there is no security loss with the new approach co= mpared to
>>> the old one.)
>>
>> I think we are now fully aligned on the definitions and the perfor= mance
>> implications and now that we have better documentation we can cont= inue
> with the
>> interim effort.
>>
>> I=E2=80=99d however like to leave it as an open question whether w= e shouldn=E2=80=99t
> reconsider
>> locking down entire subtrees as a security-in-depth measure if we = can
>> convince ourselves the performance toll is not too high. For examp= le, I=E2=80=99m
>> wondering if there isn=E2=80=99t a clever way to combine the tree<= br> > hash
>> and the parent hash. The tree hash has to be calculated for every = epoch
>> change anyway and it=E2=80=99s always in O(n).
>>
>> Thanks
>>
>> Raphael
>>
>>>
>>> - Jo=C3=ABl
>>>
>>> On 01/01/2021 17:30, Raphael Robert wrote:
>>>> Thanks for the lengthy explanation!
>>>>
>>>> I=E2=80=99m glad we are on the same page regarding the def= inition of the
> resolution.
>>>> I think I understand where the misunderstanding is coming = from.
>>>>
>>>> Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D sol= ution on the ML (on Oct 23
>>>> 2020) that was the following:
>>>>
>>>> "strong parent_hash" : Define parent_hash to inc= lude tree_hash (and
>>>> tree_hash to *not* include parent_hash). The tree_hash of = a node covers
>>>> all values in the subtree rooted at that node=C2=A0 (excep= t the
>>>> parent_hashes and signatures). So basically something like= this: -
>>>> leaf.tree_hash :=3D H(leaf.data) - node.tree_hash :=3D H(n= ode.data,
>>>> node.lchild.tree_hash, node.rchild.tree_hash) - root.paren= t_hash :=3D 0 -
>>>> node.parent_hash :=3D H(node.parent.tree_hash, node.parent= .parent_hash).
>>>>
>>>> This definition did include the whole subtree and therefor= e I was
>>>> assuming that this would also end up in the spec change. A= s far as I
>>>> now understand, you went for a more lightweight approach w= here you say
>>>> that just using the resolution is enough, because pinning = all nodes in
>>>> the subtree is not necessary and would only prevent =E2=80= =9Cbenign=E2=80=9D attacks. I
>>>> guess I missed the
> part
>>>> where you switched from one concept to the other.
>>>>
>>>> What I discovered during implementation is that when you o= nly use the
>>>> resolution approach and the tree has no blanks, you are no= t always able
>>>> to detect if the attacker has swapped two leaves. This mig= ht indeed
>>>> just be a benign attack in the sense that the tree invaria= nt is not
>>>> violated.
>>>>
>>>> At this point I don=E2=80=99t have strong arguments for or= against using the
>>>> resolution approach, I would have to think about it some m= ore. Just as
>>>> a reminder for context, the original concept by Benjamin a= nd Karthik
>>>> was =E2=80=9Cparent hash covers the tree hash=E2=80=9D. Th= at=E2=80=99s pretty much what you
>>>> initially proposed, except that it also covered the KeyPac= kage at the
>>>> leaf level, not just the HPKE public key.
>>>>
>>>> My question right now would be: What is the benefit of the= lightweight
>>>>=C2=A0 resolution-based approach? If it=E2=80=99s just effi= ciency, we should look at
> whether
>>>> there=E2=80=99s really that much to gain.
>>>>
>>>> On efficiency: The parent hashes are verified in two insta= nces: a) when
>>>> a new member joins the group and validates the public tree= it received
>>>> and b) when a member receives a full Commit from another m= ember.
>>>>
>>>> Re a): The spec now says "Moreover, when joining a gr= oup, new members
>>>> MUST authenticate each non-blank parent node P. A parent n= ode P is
> authenticated=E2=80=9D.
>>>> This means the effort is linear to start with. Depending o= n how you
>>>> define the operation, it is even worse than linear. Say th= e tree has n
>>>> leaves and therefore 2n-1 nodes. For every node, we need t= o iterate
>>>> over at least a
> part
>>>> of the subtree and collect public keys that we then concat= enate. We end
>>>> up only hashing once per node, but with a variable size pa= yload. I
>>>> think the cost of navigating the subtree and collecting th= e keys is
>>>> O(log n) for the =E2=80=9Cresolution approach and O(n) for= the =E2=80=9Cdescendants"
>>>> approach and the cost of hashing is linearly proportional = to the size
>>>> of the payload. If we assume that hashing is the most expe= nsive
>>>> operation, the total cost would be O(n * log n) for =E2=80= =9Cresolution=E2=80=9D and
>>>> O(n ^ 2) for =E2=80=9Cdescendants".
>>>>
>>>> Re b): It is very similar to a), except that we only have = to iterate
>>>> over log n nodes of the direct path, not the whole tree. T= hat means
>>>> that the total effort is O(log n * log n) for =E2=80=9Cres= olution=E2=80=9D and O(n *
>>>> log n) for =E2=80=9Cdescendants=E2=80=9D.
>>>>
>>>> There=E2=80=99s clearly a difference in terms of efficienc= y between the two
>>>> approaches. That being said, we should keep in mind that f= or small
> payloads,
>>>> hashing is a lot faster than other cryptographic operation= s like e.g.
>>>> producing and verifying signatures. Since a new joiner nee= ds to also
>>>> verify n signatures when joining a group, it could well be= that the
>>>> effort of verifying the parent hashes is negligible compar= ed to the
>>>> cost of verifying all signatures.
>>>>
>>>> In summary: I still don=E2=80=99t have strong arguments ag= ainst the
>>>> =E2=80=9Cresolution=E2=80=9D approach, but I also have a f= eeling that the efficiency
>>>> differences are not dramatic either.
>>>>
>>>> Happy New Year and thanks!
>>>>
>>>> Raphael
>>>>
>>>>> On 1. Jan 2021, at 15:48, Mularczyk Marta
>>>>> <marta.mularczyk@inf.ethz.ch
> <mailto:marta.mularczyk@inf.ethz.ch>
>>>>> <mailto:marta.mularczyk@inf.ethz.ch
>>>>> <mailto:marta.mularczyk@inf.ethz.ch>>
>>>>> <mailto:marta.mularczyk@inf.ethz.ch
> <mailto:marta.mularczyk@inf.ethz.ch> <mailto:marta.mularczyk@inf.ethz.ch =
> <mailto:marta.mularczyk@inf.ethz.ch>>>>
>>>>> wrote:
>>>>>
>>>>> Hi Raphael,
>>>>>
>>>>> Thanks for explaining! Using "descendants" i= s definitely better for
>>>>> security, but also, as Hubert mentioned, less efficien= t.
>>>>>
>>>>> Also we did understand =E2=80=9Cresolution=E2=80=9D th= e same way as you when we
>>>>> proposed the strong parent hash (sorry for the confusi= on).
>>>>>
>>>>> But we obviously really want to understand if/why usin= g resolution is
>>>>>=C2=A0 insecure. Ultimately, the security property we c= are about is that
>>>>> privacy and authenticity of application messages holds= . The Parent
>>>>> Hash mechanism helps us ensure this holds also for epo= chs in
>>>>> adversarially generated groups, as long as the adversa= ry does not
>>>>> control any leaves in this epoch (i.e. does not know t= he signing key
>>>>> of the leaf). So to really see if your examples break = security, it
>>>>> would be good to see if they let us violate this secur= ity goal.
>>>>>
>>>>> To see why we believe the new parent hash notion (i.e.= with
>>>>> resolutions) achieves this, let us first clarify what = technical
>>>>> property about (even adversarially produced) ratchet t= rees we want
>>>>> from verifying parent hashes. It=E2=80=99s not that th= e adversary can=E2=80=99t
>>>>> produce manipulated trees at all. It=E2=80=99s that th= e only manipulations
>>>>> she is able to do will not let her produce a tree that= violates the
>>>>> tree invariant. That=E2=80=99s because (in our model) = when the tree invariant
>>>>> holds then we can show that the epoch is secure.
>>>>>
>>>>> So some manipulations *are* possible. They are just = =E2=80=9Cbenign=E2=80=9D. For
>>>>> example, suppose adversary A controls a leaf L with HP= KE key pk in
>>>>> tree T (i.e. she knows the signing key of L=E2=80=99s = owner). Then A can
>>>>> construct a new tree T=E2=80=99 identical to T but whe= re leaf L has pk=E2=80=99 !=3D pk
>>>>> (say, by performing a commit at leaf L to obtain T=E2= =80=99). But for this,
>>>>> in T=E2=80=99 leaf L must still be controlled by A. We= call this manipulation
>>>>> =E2=80=9Cbenign=E2=80=9D because even though A might n= ow break privacy of application
>>>>> messages in epoch with tree T=E2=80=99 it doesnt viola= te our security goal
>>>>> because privacy is conditioned on A *not* controlling = any leaves.
>>>>>
>>>>> Conversely, one thing A can *not* do is the following.= Say T=E2=80=99 has a
>>>>> node V with HPKE public key pk0 such that A knows corr= esponding sk0.
>>>>> Then for T=E2=80=99 to pass verification, it must cont= ain a leaf controlled
>>>>> by A. This holds since for T=E2=80=99 to pass verifica= tion there must be a
>>>>> leaf in V=E2=80=99s subtree with a signature covering = a hash that includes
>>>>> pk0. I.e. some leaf must =E2=80=9Cattest=E2=80=9D to h= aving inserted pk0 into T=E2=80=99.
>>>>> (Recall that in our model the adversary can=E2=80=99t = just leak sk0 alone.
>>>>> They must leak a full state of some client which also = means leaking
>>>>> the client's signing key.)
>>>>>
>>>>> So our question to you is the following. (Does this ma= ke sense? And)
>>>>> we=E2=80=99re not exactly sure what you have in mind w= hen you say =E2=80=9Cswapping
>>>>> out two leaf nodes=E2=80=9D. But we think it would onl= y be a problem if it is
>>>>> not benign. Is this true for your attack? Could you ex= pand a bit on
>>>>> what tree manipulation you have in mind?
>>>>>
>>>>> Best, Jo=C3=ABl& Marta
>>>>>
>>>>>
> ----------------------------------------------------------------------= ----------
>
>
>>>>
>>>>>
>>>>>
>>> *From:* MLS <mls-bounces@ietf.org <mailto:mls-bounces@ietf.org>
>>> <mailto:mls-bounces@ietf.org
> <mailto:m= ls-bounces@ietf.org>> <mailto:mls-bounces@ietf.org
> <mailto:m= ls-bounces@ietf.org>
>>> <mailto:mls-bounces@ietf.org <mailto:mls-bounces@ietf.org>>>> on behal= f
>>> of
>>>>> Hubert Chathi <hubertc@matrix.org <mailto:hubertc@matrix.org>
>>>>> <mailto:hubertc@matrix.org
> <mailto:hub= ertc@matrix.org>> <mailto:hubertc@matrix.org
> <mailto:hub= ertc@matrix.org>
>>>>> <mailto:hubertc@matrix.org <mailto:hubertc@matrix.org>>>> *Sent:* =
>>>>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org
> <mailto:mls@ietf.= org> <mailto:ml= s@ietf.org <mailto:mls@ietf.org>>
>>>>> <mailto:mls@ietf.org <mailto:mls@ietf.org> <mailto:mls@ietf.org
> <mailto:mls@ietf.= org>>> *Subject:* Re: [MLS] New Parent Hash
>>>>>
>>>>> I think that if you use "descendants" as you= define it, then
>>>>> calculating the parent_hash will become O(n) all the t= ime, rather
>>>>> than O(log n) in the best-case, since the size of the = descendants
>>>>> list will be O(n).=C2=A0 I'm not sure if there'= ;s a good way to maintain
>>>>> O(log n) and still provide the desired security.
>>>>>
>>>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: >>>>>> Hi Jo=C3=ABl, Daniel and Marta,
>>>>>>
>>>>>> I just implemented the stronger parent hash scheme= you proposed in
>>>>>> the way it is described in the spec now. The good = news is that it
>>>>>> is implementable, the bad news is that is does not= solve the
>>>>>> problem you initially describe. Specifically, swap= ping out two leaf
>>>>>> nodes still goes undetected.
>>>>>>
>>>>>> I think it is due to a terminology conflict, but i= t would be great
>>>>>> if you could validate that assumption. In 7.4 you = introduce the
>>>>>> notion of =E2=80=9Coriginal child resolution=E2=80= =9D as " the array of
>>>>>> HPKEPublicKey values of the nodes in the resolutio= n of S=E2=80=9D. The term
>>>>>> =E2=80=9Cresolution=E2=80=9D is defined in 5.2. It= is essentially a way of dealing
>>>>>> with blank nodes by substituting them with the fir= st non-blank
>>>>>> descendants you find when descending the subtree o= f a node. Here is
>>>>>> my assumption: You probably thought the resolution= would cover all
>>>>>> non-blank descendants of a node, not just the firs= t non-blank
>>>>>> descendant. In that case we would need another fun= ction that does
>>>>>> that (let=E2=80=99s call it =E2=80=9Cdescendants= =E2=80=9D).
>>>>>>
>>>>>> If we look at the example of 5.2:
>>>>>>
>>>>>> - The resolution of node 3 is the list [A, CD, C] = - The
>>>>>> descendants of node 3 is the list [A, CD, C, D] >>>>>>
>>>>>> - The resolution of node 5 is the list [CD] - The = descendants of
>>>>>> node 5 is the list [CD, C, D] (we just need to add= itionally filter
>>>>>> out C, because it is an unmerged leaf of node 5) >>>>>>
>>>>>> Here is a code snippet of what the =E2=80=9Cdescen= dants=E2=80=9D function would
>>>>>> look like (sorry that it=E2=80=99s Rust, not Pytho= n):
>>>>>>
>>>>>> fn descendants(x: NodeIndex, size: LeafIndex) ->= ; Vec<NodeIndex> {
>>>>>> if level(x) =3D=3D 0 { vec![x] } else { let left_c= hild =3D left(x); let
>>>>>> right_child =3D right(x, size); [ descendants(left= _child, size),
>>>>>> vec![x], descendants(right_child, size), ] .concat= () } }
>>>>>>
>>>>>> There=E2=80=99s a more efficient implementation of= course, this is just to
>>>>>>=C2=A0 illustrate.
>>>>>>
>>>>>> In other words, the new =E2=80=9Coriginal child re= solution=E2=80=9D of S would be
>>>>>> the subtree under S, but with filtered-out blank n= odes and unmerged
>>>>>> leaves of S.
>>>>>>
>>>>>> If my assumption is correct, I=E2=80=99ll follow u= p quickly with a PR since
>>>>>> this is currently a blocker for interop based on d= raft-11.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Raphael
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 12. Nov 2020, at 22:14, Joel Alwen <jalwen@wickr.com
> <mailto:jalwe= n@wickr.com>
>>>>>>> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>>
>>>>>>> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>
> <mailto:jalwe= n@wickr.com <mailto:jalwen@wickr.com>>>> wrote:
>>>>>>>
>>>>>>> Hey people,
>>>>>>>
>>>>>>> Just a quick heads up that Daniel, Marta and I= put in a PR with a
>>>>>>> new version of strong parent hash to prevent t= he attacks from the
>>>>>>> earlier thread. We tried to make it as minimal= as we could to
>>>>>>> help with deniability while still preventing t= he attacks
>>>>>>> permitted by weak parent hashes.
>>>>>>>
>>>>>>> In a nutshell, when computing parent_hash at n= ode v with parent p
>>>>>>> and sibling w we include - p's HPKE pubkey= - p's parent_hash
>>>>>>> value and - HPKE pub keys in the resolution of= w except for those
>>>>>>> belonging to leaves unmerged at p.
>>>>>>>
>>>>>>> As a sanity check, notice that as long as p= 9;s keys remain the
>>>>>>> same one can always recompute the same parent_= hash value at v as
>>>>>>> was initially computed by the member that set = p's keys. (In other
>>>>>>> words, new members can verify that the stored = parent_hash values
>>>>>>> match whats in the tree.) In particular, that&= #39;s coz as long as
>>>>>>> p's keys are unchanged so is the resolutio= n of w. The only
>>>>>>> exception are leaves being added as unmerged a= t w. But those
>>>>>>> leaves are also added as unmerged at p so they= are left out of
>>>>>>> the hash.
>>>>>>>
>>>>>>> As for deniability, at least parent_hash only = binds HPKE keys and
>>>>>>>=C2=A0 nothing else (like, say, credentials or = signatures). Its the
>>>>>>> best we were able to come up with for now... >>>>>>>
>>>>>>> - jo=C3=ABl
>>>>>>>
>>>>>>> ______________________________________________= _ MLS mailing list
>>>>>>>=C2=A0 MLS@ietf.org <mailto:MLS@ietf.org> <mailto:MLS@ietf.org
> <mailto:MLS@ietf.= org>> <mailto:MLS@ietf.org <mailto:MLS@ietf.org>
>>>>>>> <mailto:MLS@ietf.org <mailto:MLS@ietf.org>>>
>>>>>>> https://www.ietf.org/mailman/l= istinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls><= br> >>>>>>> <https://www.ietf.org/mailm= an/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>&= gt;
>>>>> <https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls><= br> >>>>> <https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>&= gt;>
>>>>>>
>>>>>> _______________________________________________ ML= S mailing list
>>>>>> = MLS@ietf.org <mailto:MLS@ietf.org> <mailto:MLS@ietf.org
> <mailto:MLS@ietf.= org>> <mailto:MLS@ietf.org <mailto:MLS@ietf.org>
> <mailto:MLS@ietf.= org <mailto:MLS@ie= tf.org>>>
>>>>>> https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls><= br> >>>>>> <https://www.ietf.org/mailman/l= istinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>&= gt;
>>>>> <https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls><= br> >>>>> <https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>&= gt;>
>>>>>>
>>>>>
>>>>> _______________________________________________ MLS ma= iling list
>>>>> MLS@= ietf.org <mailto:M= LS@ietf.org> <mailto:MLS@ietf.org
> <mailto:MLS@ietf.= org>> <mailto:MLS@ietf.org <mailto:MLS@ietf.org>
> <mailto:MLS@ietf.= org <mailto:MLS@ie= tf.org>>>
>>>>> https://www.ietf.org/mailman/listinfo/= mls
> <https://www.ietf.org/mailman/listinfo/mls><= br> >>>>> <https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>&= gt;
>>>>> <https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls><= br> >>>>> <https://www.ietf.org/mailman/listi= nfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>&= gt;>
>>
>
> _______________________________________________ MLS mailing list MLS@ietf.org
> <mailto:MLS@ietf.= org> https://www.ietf.org/mailman/listinfo/mls <= br> > <https://www.ietf.org/mailman/listinfo/mls><= br> >
--0000000000006c88a305b8b60139-- From nobody Tue Jan 12 08:38:58 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 B37773A0B5B for ; Tue, 12 Jan 2021 08:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_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=wire-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 FhB1j2Nxp5yu for ; Tue, 12 Jan 2021 08:38:50 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 971323A0B58 for ; Tue, 12 Jan 2021 08:38:49 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id g24so3010512edw.9 for ; Tue, 12 Jan 2021 08:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0lRHzfosZ59wJ8Hu6XonzKcFgozbpQdJZUVfJsYeOic=; b=ZU8IWRpi9lADUCz3Dx1IcTvcyV9QCJXxDb96nvNfejibJZS7jiJvSL/+oPXDTmYrgR NM+rEsKuSRIrmZNLIfwHSYBkCxq0ZmHPfhmcwNkrTh7jRFnm4b3XmWJQryJ8zxV3FpWb 7ZytlGmeVIDRW8YKiU2k5SsnsSrLmMlbW8VllbWYDeqbqmUCS10nC4gRFTlTV+Rqi0wI rBZzYbVGRkUKdfxBclx//y+nXDA7dDJz6O8SIM2id1qIHBrD10gO5f9gUA4oT6y2pCAx REOo2je8eIYPplIJiUDYNxHvLnssoz7gSIphN+65/8oCOPSFojyd4UKaPY/AH1qX7gY4 c4Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0lRHzfosZ59wJ8Hu6XonzKcFgozbpQdJZUVfJsYeOic=; b=MXGBwWmirAZFZFFxX8uGk/QGSbTIyVcW4/V+tdfGm291eQODY8KSUA7FRwJjkg31yM 5VEzR10Pl/4qEiKMfxVLKgz9QTcAs10WR0RrN12Qs5RFT8KmSGtKNn4RpbPRhbj0Ipm+ ToZyICWmh2A1rywhPQbJ9RbNwVL/u3t/abKvfxMP7ymLrydsqrD9YLAkf7MdPAQ/VusP TdswrSl8FD3rHlBln02fe66VWyYBBJaigEp7LcA2Pcm2WVtNKV4Q6oPvGjWjanptT8Lc 54f2ygwX7nRCWNCbH24Mhtq+Wtmjx4pJEqNWvDvS39z/7ZTE2X/yvstYOh6u5eQLtmEA PUxQ== X-Gm-Message-State: AOAM5320NkC0KE4a7p8ND/+ODwDWKGu041m1IUAr6c/Ok+pGnW0O40Te IhzIYu7Y9qXdG37PWWsd0dXBIg== X-Google-Smtp-Source: ABdhPJwGycjhyP9lfXbqE+7f6GcFl7t1SbP2ia6GmhPon5+dgXspgv5cLGo3z2BqZJpRhreSR7ySOQ== X-Received: by 2002:a50:c3c5:: with SMTP id i5mr27574edf.166.1610469527817; Tue, 12 Jan 2021 08:38:47 -0800 (PST) Received: from [192.168.178.21] ([37.209.98.242]) by smtp.gmail.com with ESMTPSA id d13sm1727309edx.27.2021.01.12.08.38.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 08:38:46 -0800 (PST) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6B027BAA-AB23-4F23-91E4-4807CD31414B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Tue, 12 Jan 2021 17:38:11 +0100 In-Reply-To: Cc: Joel Alwen , "mls@ietf.org" , Mularczyk Marta To: Richard Barnes References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> <32c5c409abbc4cf79ecf74c9e2a2befa@inf.ethz.ch> <8C2A0364-90BA-4789-9163-E31D8C5B5CB1@wire.com> <1b6230e4-e634-18aa-cfe2-8c35f1b645c2@wickr.com> <4135BB5E-4C35-4EFF-91B6-1615C3560F1E@wire.com> <54f2ca71-89e1-1ca3-b783-2ad774564127@wickr.com> <9bfee582-1227-754a-c70f-d59012e6ea82@wickr.com> X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [MLS] New Parent Hash 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: Tue, 12 Jan 2021 16:38:57 -0000 --Apple-Mail=_6B027BAA-AB23-4F23-91E4-4807CD31414B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey all, It looks like we are generally aligned on the matter then and we keep = things as-is.=20 Performance: As Jo=C3=ABl pointed out, you can do clever things for the = 'descendants' approach, so I think we should close the performance = aspect of the debate. It's irrelevant to the decision taking. Security: 'resolution' seems to do the job and we should not move to = 'descendants' just now. I propose the following criteria for changes: - the proofs for 'resolution' turn out to be wrong - new attacks are found that are worth addressing - strong reasons to have 'security-in-depth' by using =E2=80=98descendants= =E2=80=99 instead (should be stated on list and get some consensus) Thanks Raphael > On 12. Jan 2021, at 16:51, Richard Barnes wrote: >=20 > Hey Jo=C3=ABl, >=20 > Sorry for a bit of delay, took me a minute to get my thoughts in = order. But the answer seems pretty clear to me now. >=20 > tl;dr: On further thought, the =E2=80=9Cdescendants=E2=80=9D approach = is O(N^2) for new joiners. So I=E2=80=99m inclined keep the resolution = approach. >=20 > The parent hash for a parent node P incorporates some input from a = copath child C. If I understand the security requirement correctly, you = want the copath child=E2=80=99s input to describe the subtree as it was = the last time the parent node was updated. In at least enough detail to = tell which private keys received the private key for P, possibly in more = detail. This input needs to remain constant as long as the public key = in P remains the same, so that validation is possible. >=20 > That raises the question of what details of the subtree under C can = change without the public key in P also being changed. The only = operations we have that change the tree are Add, Update, Remove, and = Commit. Update and Remove within the subtree result in the path from = the leaf being blanked, so the parent node will also be blanked. A = Commit within the subtree will also replace P. Only Add changes the = subtree without changing the parent, and the only change it makes is to = (1) set the key package at the affected leaf, and (2) add an unmerged = leaf to the leaf node=E2=80=99s ancestors. >=20 > This implies that you can =E2=80=9Crewind=E2=80=9D the state of the = tree to the state it was in when the parent node was set by (1) = resetting the leaves in P.unmerged_leaves to blanks and (2) removing = P.unmerged_leaves from all unmerged_leaves lists in the subtree. This = =E2=80=9Crewound=E2=80=9D tree is constant over the lifetime over = P.public_key, so any summary of it is suitable as an input to the parent = hash, for example: >=20 > * The resolution of the subtree root C [Alwen, Jost, Mularczyk] > * The tree hash of the subtree [Bhargavan, Beurdouche] > * A hash over the public keys [Robert, Barnes] =E2=80=94 though this = is not sufficient to tell which nodes received P=E2=80=99s private key, = and thus does not meet the security goals >=20 > The necessity of this =E2=80=9Crewind=E2=80=9D, though, means that the = implementation of the copath child input basically needs to be = =E2=80=9Cdynamic=E2=80=9D. To capture the resolution, the copath child = input needs to capture the =E2=80=9Crewound=E2=80=9D unmerged leaf = state, which means that the copath child input depends on the parent as = well as the copath child. I had been thinking that there was a = =E2=80=9Cstatic=E2=80=9D solution here, where you compute one thing per = node, and update it when something below the node changed, like with the = tree hash. Here, though, a node=E2=80=99s contribution to a parent hash = depends on the parent, you would need to store several values per node, = which removes any efficiency advantage. >=20 > Returning to the =E2=80=9Cresolution=E2=80=9D vs. =E2=80=9Cdescendants=E2= =80=9D decision=E2=80=A6 The =E2=80=9Cdescendants=E2=80=9D option in = this framing would entail computing either the tree hash or a =E2=80=9Ctre= e hash lite=E2=80=9D on the copath child=E2=80=99s subtree, where the = =E2=80=9Clite=E2=80=9D variant would omit some things from the leaves = (e.g., only covering HPKE public keys). Because it has to be dynamic, = that requires O(n) hash operations for a full Update Path, with each = step in the tree doing ~2^khashes, with k increasing as you go up the = tree. >=20 > In other words, we have the following trade-off: >=20 > * Resolution: Assures tree invariant only, costs ~log(N) ~ N hashes = per update path node / parent hash > * Descendants: Assures full tree structure, costs n hashes per update = path node / parent hash >=20 > These costs are borne by the sender and the receiver of an UpdatePath. = A new joiner verifying a tree will have to verify ~N parent hashes, so = the number of hash invocations will be O(N^2) in the worst case. (Side = note: the verifier might actually have to do *double* that work, since = it needs to test both of its children. We might want to add a =E2=80=9Cla= st updated child=E2=80=9D bit next to the =E2=80=9Cparent hash=E2=80=9D = field, so that the verifier can tell which one was more recently = updated, and thus should be correct.) >=20 > That latter cost factor of N makes the efficiency of the resolution = approach seem even more important. While the extra rigidity from the = descendant approach seems appealing, it doesn=E2=80=99t seem essential. = Net of all that, I=E2=80=99m inclined to keep the resolution approach. >=20 > =E2=80=94Richard >=20 > On Wed, Jan 6, 2021 at 9:31 AM Joel Alwen > wrote: > Responding inline... >=20 > On 05/01/2021 15:48, Richard Barnes wrote: > > Note: I am assuming that the "descendant hash" would be = tree-structured like > > the parent hash; it just would cover only the HPKE public keys = instead of the > > whole nodes. >=20 > This would be a departure from the original Benjamin-Karthik approach = as they > included the Tree Hash of the co-path child when computing the Parent = Hash of a > node. Tree Hash covers more than the HPKE pks (e.g. the whole key = package at a > leaf and (in recent drafts) also the list of unmerged leaves at each = node). So > including only the HPKE leaves in a subtree introduces a 3rd hash for = a node > which would have to be computed and maintained by all members... I'm = not sure > that's worth it. >=20 > I'm also not 100% clear yet on what the verification algorithm is when = joining a > group. Here's what I'm missing: >=20 > For tree T and node V in T with child node W let PH(T,V,W) be the = parent hash of > V in T using co-path child W. Say, at time (epoch) t1 node V in = ratchet tree T1 > was just assigned a new HPKE key pair with direct path child U and = co-path child > W. Later, you join the group (and V still has the same PK as in T1). = You get the > current tree T2 and want check PH(T1,V,W) is stored at U. Can anyone = with a > clearer picture than me (e.g. Richard?) sketch the algo to recompute = PH(T1,V,W) > given tree T2? Pseudocode, text whatever. (Or if that's not efficient = on its own > maybe sketch how to recompute PH(T,X,Y) you'd want to compute as part = of > verification. Amortization could help here since, done right, you may = be able to > reuse work from pasts PH computations in the subequent ones.) >=20 > > =46rom an implementation point of view, there's not a ton of = difference between > > these two >=20 > I dunno... My guess is such tree verification would be more = complicated (if not > even asymptotically worse) than the resolution version from in Draft = 11... >=20 > E.g. one issue is that, because of unmerged leaves, sometimes we have = to do > compute hashes of multiple subsets of PKs from a nodes subtree. Here's = an > example. Extend the above example as follows: > - Unmerged leaf Z was added to W's subtree at time t3 : t1 < t3 < t2. > - Parent P of V gets an HPKE key with co-path child V at time t4 : t3 = < t4 < t2. > - Let W be not blank in T2. > To verify tree T2 we must compute both PH(T1,V,W) and PH(T4,P,V). >=20 > For the resolution approach its pretty simple. For PH(T1,V,W) get W's = resolution > in T2 and remove Z (as Z is also be unmerged at V). For PH(T4,P,V) get = P's > resolution and remove any leaves that are unmerged at P. >=20 > But for the descendants approach I think you need a fair bit more = work. For > PH(T1,V,W) you need the hash of W's descendent *excluding Z*. But for = PH(T4,P,V) > you need the hash of W's descendents *including Z*. I think that means = having to > re-visit every node from Z to W when computing PH(T4,P,V) despite = having already > visited all but P while computing PH(T1,V,W). >=20 > In any case, I without some clearer idea of the verification algorithm = I can't > say I'd be in favor of switching to a descendant based Parent Hash. >=20 > - Jo=C3=ABl >=20 >=20 > > - The "resolution" approach (in draft-11), which incorporates the = minimum=20 > > information necessary to assure the tree invariant - The = "descendants" > > approach, which binds in the entire structure of the tree (in units = of HPKE > > keys) > >=20 > > =46rom an implementation point of view, there's not a ton of = difference > > between these two, but the "descendants" approach seems a bit nicer = to me. > > In the "resolution" case, you can re-use resolution logic; in the > > "descendants" case, you can re-use the "update the changed nodes" = logic that > > the tree hash requires. If anything, the "descendants" approach is = a little > > more "static", in that you can store the descendant hashes on the = nodes, then > > at parent-hash time, you can just grab the descendant-hash from the > > appropriate child. A tree-structured hash also seems easier to get = right > > than making sure the resolution is in the right order, and it's = compatible > > with the idea that you mainly need to know about the copath of an = UpdatePath > > in order to process it. > >=20 > > =46rom a security POV, it seems like either is acceptable, since = they both > > enforce the tree invariant. The extra structure enforcement doesn't = seem > > like it adds much in terms of security, but it does seem a little = easier to > > think about, since you don't have to keep in mind the caveat that = the > > structure can change below the resolution points. > >=20 > > So net/net, I have a slight preference for the "descendants" = approach, if > > people are OK with the extra rigidity. > >=20 > > --Richard > >=20 > > --Richard > >=20 > > On Mon, Jan 4, 2021 at 8:33 AM Joel Alwen =20 > > >> wrote: > >=20 > >=20 > > On 02/01/2021 18:02, Raphael Robert wrote: > >> Thanks Marta and Jo=C3=ABl for the explanation! That was the delta = that was > >> missing for my understanding and it=E2=80=99s definitely good to = have that on > >> list. > >=20 > > Yes, good call. FYI there's a MUCH more complete discussion of the = security=20 > > properties of MLS we've analyzed, the adversarial and communication = models > > we used and the actual security proof in eprint/2020/1327. (We'll be = updating > > it soon to include our security analysis of the new parent hash = scheme.) > >=20 > >> Just for context, what I had in mind was something that was not as > >> detrimental to the membership deniability. I think in that respect = both the > >> =E2=80=9Cresolution=E2=80=9D and the =E2=80=9Cdescendants=E2=80=9D = approach are equivalent. > >=20 > > I agree that the resolution method is hardly deniable in any formal = sense I > > know of. Switching from signing (hashes of) the entire list of certs = of > > everyone in a subtree to "only" signing HPKE pubkeys in the = resolution does > > feel like a pretty superficial improvement for deniability. :-/ To = me, the > > advantage of using resolutions is the simplicity & efficiency = compared to > > using descendants. > >=20 > > TBH, for deniability I think there's a whole family of = impossibilities > > waiting to be formalized here (like the one in Thm. 1 of = eprint/2019/1153). > > Asynchronous + authenticated + (strongly?!) deniable + no global = trusted > > setup + communication complexity sub-linear in the group size? Seems = very > > hard to me (in my non-expert opinion). My guess is that real = compromises in > > the model / design goals need to be made to get (even just weak) > > deniability. > >> I=E2=80=99d however like to leave it as an open question whether we = shouldn=E2=80=99t > > reconsider locking down entire subtrees as a security-in-depth = measure if we=20 > > can convince ourselves the performance toll is not too high. > >=20 > > If we can do it, without paying too much of an efficiency price, = then by all=20 > > means why not? I'm still curious what we'd be getting though. E.g. = what needs > > to happen so that hashing in descendants is secure but using only = the=20 > > resolution isn't? > >=20 > >> The tree hash has to be calculated for every epoch change anyway = and it=E2=80=99s > > always in O(n). > >=20 > > For my own edification: I would have thought computing the new tree = hash at > > the root after a commit to p proposals requires at most ~ = O(p*log(n)) actual > > hash calls + as many memory lookups no? Let L_p be the leaves = modified by > > the proposals. The root of any subtree with no leaf in L_p has the = same tree > > hash as before the commit. So by storing tree hashes as we compute = them we > > can replace computing unchanged subtree tree hashes with a lookup. = What am I > > missing here? > >=20 > > - Jo=C3=ABl > >=20 > >=20 > >>> On 1. Jan 2021, at 23:10, Joel Alwen > > > > >>> = >>> wrote: > >>>=20 > >>> Servus Raphael, > >>>=20 > >>>> Happy New Year > >>>=20 > >>> Same to you! Here's hoping the new one will be a tad happier than = the > > last. ;-) > >>>=20 > >>> As for why "resolutions": The impetus to look for a new approach = after > >>> our initial proposal came from a comment in your email on the Fri, = 23 > >>> October > > 2020 > >>> 18:23 UTC in the thread "Weak vs. Strong Tree Authentication". = There you > > wrote: > >>>=20 > >>>> Going for fully hashing the tree nodes as described locks down = the > >>>> whole tree structure, making any reshuffling impossible. Maybe = there is > >>>> a more lightweight approach that would yield the same result = without > >>>> =E2=80=9Cprovid[ing] irrefutable evidence that the signing key's = owner was in a > >>>> group with (at least some) of the other members in the group=E2=80=9D= , but I > >>>> can=E2=80=99t think of anything right now. > >>>=20 > >>> That was an intriguing challenge and got us thinking. The result = is the > > current > >>> Parent Hash definition using resolutions. We realized that to buy = wiggle > > room in > >>> not locking down as much of the tree (especially, not locking down = other > > members > >>> identities into the hash) we could pay a "price" that actually = doesn't > > harm the > >>> security we've been aiming for. Namely, we can allow the adversary = some > >>> more tree manipulation but still only benign ones that dont = actually > >>> allow her to break the security property we've been aiming for. > >>=20 > >> Just for context, what I had in mind was something that was not as > >> detrimental to the membership deniability. I think in that respect = both > >> the > > =E2=80=9Cresolution=E2=80=9D and > >> the =E2=80=9Cdescendants=E2=80=9D approach are equivalent. That = being said, this looks > >> quite elegant! > >>=20 > >>> In retrospect, a second reason to use resolutions is efficiency = (though > > to fair, > >>> that was really a coincidence rather than an explicit goal of the > >>> redesign). Initially, we had been thinking of simply having parent = hash > >>> include tree > > hash > >>> as in the Benjamin-Karthik (BK) proposal of days yore. But we = realized > >>> that since then MLS had introduced Unmerged Leaves which meant = that the > >>> tree > > hash of > >>> some nodes can change between when they are assigned their HPKE = key and > >>> later when a new member wants to verify the parent hash of the = node. In > >>> other words the BK approach was broken by unmerged leaves. So, to = make > >>> the "include the whole subtree in parent hash" approach work, it = seems > >>> new members would, for each node being verified, traverse the = nodes full > >>> sub-tree so as to weed out those nodes that were added after the > >>> to-be-verified node got its HPKE > > key. (I > >>> believe this is the O(n) time that Hubert is referring too?) In = contrast, > >>> the new version of parent hash (using resolutions) has the = potential to > >>> be much faster; it requires hashing less data but also visiting = less of > >>> the tree. > > E.g. > >>> when verifying near the root the difference can be as much as = visiting > > order n > >>> nodes vs. visiting 1 node in the new construction. > >>>=20 > >>> The more blanks & unmerged leaves in the tree the more the new > >>> construction collapses to the old one. But only in the most = extreme case > >>> do they actually reach parity and the new approach is never slower = than > >>> the old. > >>>=20 > >>> Needless to say, we didn't implement this stuff though, let alone > > benchmark the > >>> 2 approaches so any hard data elucidating what the actual = difference is > > would be > >>> very welcome. Still, the new approach can only be as fast or = faster (but > > never > >>> slower) than the new one. Nor do I think it's any more complicated = to > > define or > >>> implement. And from a security perspective they both let MLS meet = our > > security > >>> definition. So regardless of how small the speed up is (and = ignoring the > > locking > >>> in the tree discussion above) it's still not clear to me why we'd = want > >>> to > > switch > >>> back. > >>>=20 > >>> A meaningful attack that only works on the new but not old = construction > > would be > >>> one very quick way of changing my mind though! :-) But, I believe = such > >>> an > > attack > >>> would require either new adversarial capabilities and/or break a = new > >>> security property we didn't consider. (For the adversaries & = security we > >>> considered, there is no security loss with the new approach = compared to > >>> the old one.) > >>=20 > >> I think we are now fully aligned on the definitions and the = performance=20 > >> implications and now that we have better documentation we can = continue > > with the > >> interim effort. > >>=20 > >> I=E2=80=99d however like to leave it as an open question whether we = shouldn=E2=80=99t > > reconsider > >> locking down entire subtrees as a security-in-depth measure if we = can > >> convince ourselves the performance toll is not too high. For = example, I=E2=80=99m > >> wondering if there isn=E2=80=99t a clever way to combine the tree > > hash > >> and the parent hash. The tree hash has to be calculated for every = epoch > >> change anyway and it=E2=80=99s always in O(n). > >>=20 > >> Thanks > >>=20 > >> Raphael > >>=20 > >>>=20 > >>> - Jo=C3=ABl > >>>=20 > >>> On 01/01/2021 17:30, Raphael Robert wrote: > >>>> Thanks for the lengthy explanation! > >>>>=20 > >>>> I=E2=80=99m glad we are on the same page regarding the definition = of the > > resolution. > >>>> I think I understand where the misunderstanding is coming from. > >>>>=20 > >>>> Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D solution = on the ML (on Oct 23 > >>>> 2020) that was the following: > >>>>=20 > >>>> "strong parent_hash" : Define parent_hash to include tree_hash = (and=20 > >>>> tree_hash to *not* include parent_hash). The tree_hash of a node = covers > >>>> all values in the subtree rooted at that node (except the > >>>> parent_hashes and signatures). So basically something like this: = - > >>>> leaf.tree_hash :=3D H(leaf.data) - node.tree_hash :=3D = H(node.data, > >>>> node.lchild.tree_hash, node.rchild.tree_hash) - root.parent_hash = :=3D 0 - > >>>> node.parent_hash :=3D H(node.parent.tree_hash, = node.parent.parent_hash). > >>>>=20 > >>>> This definition did include the whole subtree and therefore I was > >>>> assuming that this would also end up in the spec change. As far = as I > >>>> now understand, you went for a more lightweight approach where = you say > >>>> that just using the resolution is enough, because pinning all = nodes in > >>>> the subtree is not necessary and would only prevent =E2=80=9Cbenign= =E2=80=9D attacks. I > >>>> guess I missed the > > part > >>>> where you switched from one concept to the other. > >>>>=20 > >>>> What I discovered during implementation is that when you only use = the=20 > >>>> resolution approach and the tree has no blanks, you are not = always able > >>>> to detect if the attacker has swapped two leaves. This might = indeed > >>>> just be a benign attack in the sense that the tree invariant is = not > >>>> violated. > >>>>=20 > >>>> At this point I don=E2=80=99t have strong arguments for or = against using the=20 > >>>> resolution approach, I would have to think about it some more. = Just as > >>>> a reminder for context, the original concept by Benjamin and = Karthik > >>>> was =E2=80=9Cparent hash covers the tree hash=E2=80=9D. That=E2=80=99= s pretty much what you > >>>> initially proposed, except that it also covered the KeyPackage at = the > >>>> leaf level, not just the HPKE public key. > >>>>=20 > >>>> My question right now would be: What is the benefit of the = lightweight > >>>> resolution-based approach? If it=E2=80=99s just efficiency, we = should look at > > whether > >>>> there=E2=80=99s really that much to gain. > >>>>=20 > >>>> On efficiency: The parent hashes are verified in two instances: = a) when > >>>> a new member joins the group and validates the public tree it = received > >>>> and b) when a member receives a full Commit from another member. > >>>>=20 > >>>> Re a): The spec now says "Moreover, when joining a group, new = members > >>>> MUST authenticate each non-blank parent node P. A parent node P = is > > authenticated=E2=80=9D. > >>>> This means the effort is linear to start with. Depending on how = you > >>>> define the operation, it is even worse than linear. Say the tree = has n > >>>> leaves and therefore 2n-1 nodes. For every node, we need to = iterate > >>>> over at least a > > part > >>>> of the subtree and collect public keys that we then concatenate. = We end > >>>> up only hashing once per node, but with a variable size payload. = I > >>>> think the cost of navigating the subtree and collecting the keys = is > >>>> O(log n) for the =E2=80=9Cresolution approach and O(n) for the = =E2=80=9Cdescendants" > >>>> approach and the cost of hashing is linearly proportional to the = size > >>>> of the payload. If we assume that hashing is the most expensive > >>>> operation, the total cost would be O(n * log n) for = =E2=80=9Cresolution=E2=80=9D and > >>>> O(n ^ 2) for =E2=80=9Cdescendants". > >>>>=20 > >>>> Re b): It is very similar to a), except that we only have to = iterate > >>>> over log n nodes of the direct path, not the whole tree. That = means > >>>> that the total effort is O(log n * log n) for =E2=80=9Cresolution=E2= =80=9D and O(n * > >>>> log n) for =E2=80=9Cdescendants=E2=80=9D. > >>>>=20 > >>>> There=E2=80=99s clearly a difference in terms of efficiency = between the two=20 > >>>> approaches. That being said, we should keep in mind that for = small > > payloads, > >>>> hashing is a lot faster than other cryptographic operations like = e.g.=20 > >>>> producing and verifying signatures. Since a new joiner needs to = also > >>>> verify n signatures when joining a group, it could well be that = the > >>>> effort of verifying the parent hashes is negligible compared to = the > >>>> cost of verifying all signatures. > >>>>=20 > >>>> In summary: I still don=E2=80=99t have strong arguments against = the > >>>> =E2=80=9Cresolution=E2=80=9D approach, but I also have a feeling = that the efficiency > >>>> differences are not dramatic either. > >>>>=20 > >>>> Happy New Year and thanks! > >>>>=20 > >>>> Raphael > >>>>=20 > >>>>> On 1. Jan 2021, at 15:48, Mularczyk Marta > >>>>> > > > > >>>>> > >>>>> >>=20 > >>>>> > > > = =20= > > >>>> > >>>>> wrote: > >>>>>=20 > >>>>> Hi Raphael, > >>>>>=20 > >>>>> Thanks for explaining! Using "descendants" is definitely better = for=20 > >>>>> security, but also, as Hubert mentioned, less efficient. > >>>>>=20 > >>>>> Also we did understand =E2=80=9Cresolution=E2=80=9D the same way = as you when we > >>>>> proposed the strong parent hash (sorry for the confusion). > >>>>>=20 > >>>>> But we obviously really want to understand if/why using = resolution is > >>>>> insecure. Ultimately, the security property we care about is = that > >>>>> privacy and authenticity of application messages holds. The = Parent > >>>>> Hash mechanism helps us ensure this holds also for epochs in > >>>>> adversarially generated groups, as long as the adversary does = not > >>>>> control any leaves in this epoch (i.e. does not know the signing = key > >>>>> of the leaf). So to really see if your examples break security, = it > >>>>> would be good to see if they let us violate this security goal. > >>>>>=20 > >>>>> To see why we believe the new parent hash notion (i.e. with > >>>>> resolutions) achieves this, let us first clarify what technical > >>>>> property about (even adversarially produced) ratchet trees we = want > >>>>> from verifying parent hashes. It=E2=80=99s not that the = adversary can=E2=80=99t > >>>>> produce manipulated trees at all. It=E2=80=99s that the only = manipulations > >>>>> she is able to do will not let her produce a tree that violates = the > >>>>> tree invariant. That=E2=80=99s because (in our model) when the = tree invariant > >>>>> holds then we can show that the epoch is secure. > >>>>>=20 > >>>>> So some manipulations *are* possible. They are just = =E2=80=9Cbenign=E2=80=9D. For > >>>>> example, suppose adversary A controls a leaf L with HPKE key pk = in > >>>>> tree T (i.e. she knows the signing key of L=E2=80=99s owner). = Then A can > >>>>> construct a new tree T=E2=80=99 identical to T but where leaf L = has pk=E2=80=99 !=3D pk > >>>>> (say, by performing a commit at leaf L to obtain T=E2=80=99). = But for this, > >>>>> in T=E2=80=99 leaf L must still be controlled by A. We call this = manipulation > >>>>> =E2=80=9Cbenign=E2=80=9D because even though A might now break = privacy of application > >>>>> messages in epoch with tree T=E2=80=99 it doesnt violate our = security goal > >>>>> because privacy is conditioned on A *not* controlling any = leaves. > >>>>>=20 > >>>>> Conversely, one thing A can *not* do is the following. Say T=E2=80= =99 has a > >>>>> node V with HPKE public key pk0 such that A knows corresponding = sk0. > >>>>> Then for T=E2=80=99 to pass verification, it must contain a leaf = controlled > >>>>> by A. This holds since for T=E2=80=99 to pass verification there = must be a > >>>>> leaf in V=E2=80=99s subtree with a signature covering a hash = that includes > >>>>> pk0. I.e. some leaf must =E2=80=9Cattest=E2=80=9D to having = inserted pk0 into T=E2=80=99. > >>>>> (Recall that in our model the adversary can=E2=80=99t just leak = sk0 alone. > >>>>> They must leak a full state of some client which also means = leaking > >>>>> the client's signing key.) > >>>>>=20 > >>>>> So our question to you is the following. (Does this make sense? = And) > >>>>> we=E2=80=99re not exactly sure what you have in mind when you = say =E2=80=9Cswapping > >>>>> out two leaf nodes=E2=80=9D. But we think it would only be a = problem if it is > >>>>> not benign. Is this true for your attack? Could you expand a bit = on > >>>>> what tree manipulation you have in mind? > >>>>>=20 > >>>>> Best, Jo=C3=ABl& Marta > >>>>>=20 > >>>>>=20 > > = --------------------------------------------------------------------------= ------ > > > >=20 > >>>>=20 > >>>>>=20 > >>>>>=20 > >>> *From:* MLS = >=20 > >>> > > >> = =20 > > > > >>> = >>>> on behalf > >>> of > >>>>> Hubert Chathi = >=20 > >>>>> > > >> = =20 > > > > >>>>> = >>>> *Sent:*=20 > >>>>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org = > > > >> > >>>>> > > > >>> *Subject:* Re: [MLS] = New Parent Hash > >>>>>=20 > >>>>> I think that if you use "descendants" as you define it, then > >>>>> calculating the parent_hash will become O(n) all the time, = rather > >>>>> than O(log n) in the best-case, since the size of the = descendants > >>>>> list will be O(n). I'm not sure if there's a good way to = maintain > >>>>> O(log n) and still provide the desired security. > >>>>>=20 > >>>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert wrote: > >>>>>> Hi Jo=C3=ABl, Daniel and Marta, > >>>>>>=20 > >>>>>> I just implemented the stronger parent hash scheme you proposed = in > >>>>>> the way it is described in the spec now. The good news is that = it > >>>>>> is implementable, the bad news is that is does not solve the > >>>>>> problem you initially describe. Specifically, swapping out two = leaf > >>>>>> nodes still goes undetected. > >>>>>>=20 > >>>>>> I think it is due to a terminology conflict, but it would be = great > >>>>>> if you could validate that assumption. In 7.4 you introduce the > >>>>>> notion of =E2=80=9Coriginal child resolution=E2=80=9D as " the = array of > >>>>>> HPKEPublicKey values of the nodes in the resolution of S=E2=80=9D= . The term > >>>>>> =E2=80=9Cresolution=E2=80=9D is defined in 5.2. It is = essentially a way of dealing > >>>>>> with blank nodes by substituting them with the first non-blank > >>>>>> descendants you find when descending the subtree of a node. = Here is > >>>>>> my assumption: You probably thought the resolution would cover = all > >>>>>> non-blank descendants of a node, not just the first non-blank > >>>>>> descendant. In that case we would need another function that = does > >>>>>> that (let=E2=80=99s call it =E2=80=9Cdescendants=E2=80=9D). > >>>>>>=20 > >>>>>> If we look at the example of 5.2: > >>>>>>=20 > >>>>>> - The resolution of node 3 is the list [A, CD, C] - The > >>>>>> descendants of node 3 is the list [A, CD, C, D] > >>>>>>=20 > >>>>>> - The resolution of node 5 is the list [CD] - The descendants = of > >>>>>> node 5 is the list [CD, C, D] (we just need to additionally = filter > >>>>>> out C, because it is an unmerged leaf of node 5) > >>>>>>=20 > >>>>>> Here is a code snippet of what the =E2=80=9Cdescendants=E2=80=9D = function would > >>>>>> look like (sorry that it=E2=80=99s Rust, not Python): > >>>>>>=20 > >>>>>> fn descendants(x: NodeIndex, size: LeafIndex) -> Vec = { > >>>>>> if level(x) =3D=3D 0 { vec![x] } else { let left_child =3D = left(x); let=20 > >>>>>> right_child =3D right(x, size); [ descendants(left_child, = size), > >>>>>> vec![x], descendants(right_child, size), ] .concat() } } > >>>>>>=20 > >>>>>> There=E2=80=99s a more efficient implementation of course, this = is just to > >>>>>> illustrate. > >>>>>>=20 > >>>>>> In other words, the new =E2=80=9Coriginal child resolution=E2=80=9D= of S would be > >>>>>> the subtree under S, but with filtered-out blank nodes and = unmerged > >>>>>> leaves of S. > >>>>>>=20 > >>>>>> If my assumption is correct, I=E2=80=99ll follow up quickly = with a PR since > >>>>>> this is currently a blocker for interop based on draft-11. > >>>>>>=20 > >>>>>> Thanks > >>>>>>=20 > >>>>>> Raphael > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>>> On 12. Nov 2020, at 22:14, Joel Alwen > > > > >>>>>>> = >>=20 > >>>>>>> = > > > = >>>> wrote: > >>>>>>>=20 > >>>>>>> Hey people, > >>>>>>>=20 > >>>>>>> Just a quick heads up that Daniel, Marta and I put in a PR = with a > >>>>>>> new version of strong parent hash to prevent the attacks from = the > >>>>>>> earlier thread. We tried to make it as minimal as we could to > >>>>>>> help with deniability while still preventing the attacks > >>>>>>> permitted by weak parent hashes. > >>>>>>>=20 > >>>>>>> In a nutshell, when computing parent_hash at node v with = parent p > >>>>>>> and sibling w we include - p's HPKE pubkey - p's parent_hash > >>>>>>> value and - HPKE pub keys in the resolution of w except for = those > >>>>>>> belonging to leaves unmerged at p. > >>>>>>>=20 > >>>>>>> As a sanity check, notice that as long as p's keys remain the > >>>>>>> same one can always recompute the same parent_hash value at v = as > >>>>>>> was initially computed by the member that set p's keys. (In = other > >>>>>>> words, new members can verify that the stored parent_hash = values > >>>>>>> match whats in the tree.) In particular, that's coz as long as > >>>>>>> p's keys are unchanged so is the resolution of w. The only > >>>>>>> exception are leaves being added as unmerged at w. But those > >>>>>>> leaves are also added as unmerged at p so they are left out of > >>>>>>> the hash. > >>>>>>>=20 > >>>>>>> As for deniability, at least parent_hash only binds HPKE keys = and > >>>>>>> nothing else (like, say, credentials or signatures). Its the > >>>>>>> best we were able to come up with for now... > >>>>>>>=20 > >>>>>>> - jo=C3=ABl > >>>>>>>=20 > >>>>>>> _______________________________________________ MLS mailing = list > >>>>>>> MLS@ietf.org > > > >> > > >>>>>>> = >>>=20 > >>>>>>> https://www.ietf.org/mailman/listinfo/mls = > > > > >>>>>>> > > >> > >>>>> > > > > >>>>> > > >>> > >>>>>>=20 > >>>>>> _______________________________________________ MLS mailing = list=20 > >>>>>> MLS@ietf.org > > > >> >=20 > > >>> > >>>>>> https://www.ietf.org/mailman/listinfo/mls = > > > > >>>>>> > > >> > >>>>> > > > > >>>>> > > >>> > >>>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ MLS mailing list=20= > >>>>> MLS@ietf.org > > > >> >=20 > > >>> > >>>>> https://www.ietf.org/mailman/listinfo/mls = > > > > >>>>> > > >> > >>>>> > > > > >>>>> > > >>> > >>=20 > >=20 > > _______________________________________________ MLS mailing list = MLS@ietf.org > > > = https://www.ietf.org/mailman/listinfo/mls = =20 > > > > >=20 --Apple-Mail=_6B027BAA-AB23-4F23-91E4-4807CD31414B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hey = all,

It looks like = we are generally aligned on the matter then and we keep things = as-is. 

Performance: As Jo=C3=ABl pointed out, you can do clever = things for the 'descendants' approach, so I think we should close the = performance aspect of the debate. It's irrelevant to the decision = taking.

Security: 'resolution' seems to do = the job and we should not move to 'descendants' just now.

I propose the following criteria for = changes:

- the proofs for = 'resolution' turn out to be wrong
- new attacks are found = that are worth addressing
- strong reasons to have = 'security-in-depth' by using =E2=80=98descendants=E2=80=99 instead = (should be stated on list and get some consensus)
Thanks

Raphael

On 12. = Jan 2021, at 16:51, Richard Barnes <rlb@ipv.sx> wrote:

Hey Jo=C3=ABl,

Sorry for a bit = of delay, took me a minute to get my thoughts in order.  But the = answer seems pretty clear to me now.

tl;dr: = On further thought, the =E2=80=9Cdescendants=E2=80=9D approach is O(N^2) = for new joiners.  So I=E2=80=99m inclined keep the resolution = approach.

The parent hash for a parent node = P incorporates some input from a copath child C.  If I understand = the security requirement correctly, you want the copath child=E2=80=99s = input to describe the subtree as it was the last time the parent node = was updated.  In at least enough detail to tell which private keys = received the private key for P, possibly in more detail.  This = input needs to remain constant as long as the public key in P remains = the same, so that validation is possible.

That raises the question of what details of the subtree under = C can change without the public key in P also being changed.   The = only operations we have that change the tree are Add, Update, Remove, = and Commit.  Update and Remove within the subtree result in the = path from the leaf being blanked, so the parent node will also be = blanked.  A Commit within the subtree will also replace P.  = Only Add changes the subtree without changing the parent, and the only = change it makes is to (1) set the key package at the affected leaf, and = (2) add an unmerged leaf to the leaf node=E2=80=99s ancestors.

This implies that you can =E2=80=9Crewind=E2=80=9D= the state of the tree to the state it was in when the parent node was = set by (1) resetting  the leaves in P.unmerged_leaves to blanks and = (2) removing P.unmerged_leaves from all unmerged_leaves lists in the = subtree.  This =E2=80=9Crewound=E2=80=9D tree is constant over the = lifetime over P.public_key, so any summary of it is suitable as an input = to the parent hash, for example:

* The = resolution of the subtree root C [Alwen, Jost, Mularczyk]
* = The tree hash of the subtree [Bhargavan, Beurdouche]
* A = hash over the public keys [Robert, Barnes] =E2=80=94 though this is not = sufficient to tell which nodes received P=E2=80=99s private key, and = thus does not meet the security goals

The = necessity of this =E2=80=9Crewind=E2=80=9D, though, means that the = implementation of the copath child input basically needs to be = =E2=80=9Cdynamic=E2=80=9D.  To capture the resolution, the copath = child input needs to capture the =E2=80=9Crewound=E2=80=9D unmerged leaf = state, which means that the copath child input depends on the parent as = well as the copath child.  I had been thinking that there was a = =E2=80=9Cstatic=E2=80=9D solution here, where you compute one thing per = node, and update it when something below the node changed, like with the = tree hash.  Here, though, a node=E2=80=99s contribution to a parent = hash depends on the parent, you would need to store several values per = node, which removes any efficiency advantage.

Returning to the =E2=80=9Cresolution=E2=80=9D vs. = =E2=80=9Cdescendants=E2=80=9D decision=E2=80=A6 The =E2=80=9Cdescendants=E2= =80=9D option in this framing would entail computing either the tree = hash or a =E2=80=9Ctree hash lite=E2=80=9D on the copath child=E2=80=99s = subtree, where the =E2=80=9Clite=E2=80=9D variant would omit some things = from the leaves (e.g., only covering HPKE public keys).  Because it = has to be dynamic, that requires O(n) hash operations for a full Update = Path, with each step in the tree doing ~2^khashes, with k increasing as = you go up the tree.

In other words, we have = the following trade-off:

* Resolution: = Assures tree invariant only, costs ~log(N) ~ N hashes per update path = node  / parent hash
* Descendants: Assures full tree = structure, costs n hashes per update path node / parent hash

These costs are borne by the sender and the = receiver of an UpdatePath.  A new joiner verifying a tree will have = to verify ~N parent hashes, so the number of hash invocations will be = O(N^2) in the worst case.  (Side note: the verifier might actually = have to do *double* that work, since it needs to test both of its = children.  We might want to add a =E2=80=9Clast updated child=E2=80=9D= bit next to the =E2=80=9Cparent hash=E2=80=9D field, so that the = verifier can tell which one was more recently updated, and thus should = be correct.)

That latter cost factor of N = makes the efficiency of the resolution approach seem even more = important.  While the extra rigidity from the descendant approach = seems appealing, it doesn=E2=80=99t seem essential.  Net of all = that, I=E2=80=99m inclined to keep the resolution approach.

=E2=80=94Richard

On Wed, Jan 6, 2021 at 9:31 AM Joel Alwen <jalwen@wickr.com> wrote:
Responding inline...

On 05/01/2021 15:48, Richard Barnes wrote:
> Note: I am assuming that the "descendant hash" would be = tree-structured like
> the parent hash; it just would cover only the HPKE public keys = instead of the
> whole nodes.

This would be a departure from the original Benjamin-Karthik approach as = they
included the Tree Hash of the co-path child when computing the Parent = Hash of a
node. Tree Hash covers more than the HPKE pks (e.g. the whole key = package at a
leaf and (in recent drafts) also the list of unmerged leaves at each = node). So
including only the HPKE leaves in a subtree introduces a 3rd hash for a = node
which would have to be computed and maintained by all members... I'm not = sure
that's worth it.

I'm also not 100% clear yet on what the verification algorithm is when = joining a
group. Here's what I'm missing:

For tree T and node V in T with child node W let PH(T,V,W) be the parent = hash of
V in T using co-path child W. Say, at time (epoch) t1 node V in ratchet = tree T1
was just assigned a new HPKE key pair with direct path child U and = co-path child
W. Later, you join the group (and V still has the same PK as in T1). You = get the
current tree T2 and want check PH(T1,V,W) is stored at U. Can anyone = with a
clearer picture than me (e.g. Richard?) sketch the algo to recompute = PH(T1,V,W)
given tree T2? Pseudocode, text whatever. (Or if that's not efficient on = its own
maybe sketch how to recompute PH(T,X,Y) you'd want to compute as part = of
verification. Amortization could help here since, done right, you may be = able to
reuse work from pasts PH computations in the subequent ones.)

> =46rom an implementation point of view, there's not a ton of = difference between
> these two

I dunno... My guess is such tree verification would be more complicated = (if not
even asymptotically worse) than the resolution version from in Draft = 11...

E.g. one issue is that, because of unmerged leaves, sometimes we have to = do
compute hashes of multiple subsets of PKs from a nodes subtree. Here's = an
example. Extend the above example as follows:
 - Unmerged leaf Z was added to W's subtree at time t3 : t1 < t3 = < t2.
 - Parent P of V gets an HPKE key with co-path child V at time t4 : = t3 < t4 < t2.
 - Let W be not blank in T2.
To verify tree T2 we must compute both PH(T1,V,W) and PH(T4,P,V).

For the resolution approach its pretty simple. For PH(T1,V,W) get W's = resolution
in T2 and remove Z (as Z is also be unmerged at V). For PH(T4,P,V) get = P's
resolution and remove any leaves that are unmerged at P.

But for the descendants approach I think you need a fair bit more work. = For
PH(T1,V,W) you need the hash of W's descendent *excluding Z*. But for = PH(T4,P,V)
you need the hash of W's descendents *including Z*. I think that means = having to
re-visit every node from Z to W when computing PH(T4,P,V) despite having = already
visited all but P while computing PH(T1,V,W).

In any case, I without some clearer idea of the verification algorithm I = can't
say I'd be in favor of switching to a descendant based Parent Hash.

- Jo=C3=ABl


> - The "resolution" approach (in draft-11), which incorporates the = minimum
> information necessary to assure the tree invariant - The = "descendants"
> approach, which binds in the entire structure of the tree (in units = of HPKE
> keys)
>
> =46rom an implementation point of view, there's not a ton of = difference
> between these two, but the "descendants" approach seems a bit nicer = to me.
> In the "resolution" case, you can re-use resolution logic; in = the
> "descendants" case, you can re-use the "update the changed nodes" = logic that
> the tree hash requires.  If anything, the "descendants" = approach is a little
> more "static", in that you can store the descendant hashes on the = nodes, then
> at parent-hash time, you can just grab the descendant-hash from = the
> appropriate child.  A tree-structured hash also seems easier = to get right
> than making sure the resolution is in the right order, and it's = compatible
> with the idea that you mainly need to know about the copath of an = UpdatePath
> in order to process it.
>
> =46rom a security POV, it seems like either is acceptable, since = they both
> enforce the tree invariant.  The extra structure enforcement = doesn't seem
> like it adds much in terms of security, but it does seem a little = easier to
> think about, since you don't have to keep in mind the caveat that = the
> structure can change below the resolution points.
>
> So net/net, I have a slight preference for the "descendants" = approach, if
> people are OK with the extra rigidity.
>
> --Richard
>
> --Richard
>
> On Mon, Jan 4, 2021 at 8:33 AM Joel Alwen <jalwen@wickr.com
> <mailto:jalwen@wickr.com>> wrote:
>
>
> On 02/01/2021 18:02, Raphael Robert wrote:
>> Thanks Marta and Jo=C3=ABl for the explanation! That was the = delta that was
>> missing for my understanding and it=E2=80=99s definitely good = to have that on
>> list.
>
> Yes, good call. FYI there's a MUCH more complete discussion of the = security
> properties of MLS we've analyzed, the adversarial and communication = models
> we used and the actual security proof in eprint/2020/1327. (We'll = be updating
> it soon to include our security analysis of the new parent hash = scheme.)
>
>> Just for context, what I had in mind was something that was not = as
>> detrimental to the membership deniability. I think in that = respect both the
>> =E2=80=9Cresolution=E2=80=9D and the =E2=80=9Cdescendants=E2=80=9D= approach are equivalent.
>
> I agree that the resolution method is hardly deniable in any formal = sense I
> know of. Switching from signing (hashes of) the entire list of = certs of
> everyone in a subtree to "only" signing HPKE pubkeys in the = resolution does
> feel like a pretty superficial improvement for deniability. :-/ To = me, the
> advantage of using resolutions is the simplicity & efficiency = compared to
> using descendants.
>
> TBH, for deniability I think there's a whole family of = impossibilities
> waiting to be formalized here (like the one in Thm. 1 of = eprint/2019/1153).
> Asynchronous + authenticated + (strongly?!) deniable + no global = trusted
> setup + communication complexity sub-linear in the group size? = Seems very
> hard to me (in my non-expert opinion). My guess is that real = compromises in
> the model / design goals need to be made to get (even just weak)
> deniability.
>> I=E2=80=99d however like to leave it as an open question = whether we shouldn=E2=80=99t
> reconsider locking down entire subtrees as a security-in-depth = measure if we
> can convince ourselves the performance toll is not too high.
>
> If we can do it, without paying too much of an efficiency price, = then by all
> means why not? I'm still curious what we'd be getting though. E.g. = what needs
> to happen so that hashing in descendants is secure but using only = the
> resolution isn't?
>
>> The tree hash has to be calculated for every epoch change = anyway and it=E2=80=99s
> always in O(n).
>
> For my own edification: I would have thought computing the new tree = hash at
> the root after a commit to p proposals requires at most ~ = O(p*log(n)) actual
> hash calls + as many memory lookups no? Let L_p be the leaves = modified by
> the proposals. The root of any subtree with no leaf in L_p has the = same tree
> hash as before the commit. So by storing tree hashes as we compute = them we
> can replace computing unchanged subtree tree hashes with a lookup. = What am I
> missing here?
>
> - Jo=C3=ABl
>
>
>>> On 1. Jan 2021, at 23:10, Joel Alwen <jalwen@wickr.com
> <mailto:jalwen@wickr.com>
>>> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>>> wrote:
>>>
>>> Servus Raphael,
>>>
>>>> Happy New Year
>>>
>>> Same to you! Here's hoping the new one will be a tad = happier than the
> last. ;-)
>>>
>>> As for why "resolutions": The impetus to look for a new = approach after
>>> our initial proposal came from a comment in your email on = the Fri, 23
>>> October
> 2020
>>> 18:23 UTC in the thread "Weak vs. Strong Tree = Authentication". There you
> wrote:
>>>
>>>> Going for fully hashing the tree nodes as described = locks down the
>>>> whole tree structure, making any reshuffling = impossible. Maybe there is
>>>> a more lightweight approach that would yield the same = result without
>>>> =E2=80=9Cprovid[ing] irrefutable evidence that the = signing key's owner was in a
>>>> group with (at least some) of the other members in the = group=E2=80=9D, but I
>>>> can=E2=80=99t think of anything right now.
= >>>
>>> That was an intriguing challenge and got us thinking. The = result is the
> current
>>> Parent Hash definition using resolutions. We realized that = to buy wiggle
> room in
>>> not locking down as much of the tree (especially, not = locking down other
> members
>>> identities into the hash) we could pay a "price" that = actually doesn't
> harm the
>>> security we've been aiming for. Namely, we can allow the = adversary some
>>> more tree manipulation but still only benign ones that dont = actually
>>> allow her to break the security property we've been aiming = for.
>>
>> Just for context, what I had in mind was something that was not = as
>> detrimental to the membership deniability. I think in that = respect both
>> the
> =E2=80=9Cresolution=E2=80=9D and
>> the =E2=80=9Cdescendants=E2=80=9D approach are equivalent. That = being said, this looks
>> quite elegant!
>>
>>> In retrospect, a second reason to use resolutions is = efficiency (though
> to fair,
>>> that was really a coincidence rather than an explicit goal = of the
>>> redesign). Initially, we had been thinking of simply having = parent hash
>>> include tree
> hash
>>> as in the Benjamin-Karthik (BK) proposal of days yore. But = we realized
>>> that since then MLS had introduced Unmerged Leaves which = meant that the
>>> tree
> hash of
>>> some nodes can change between when they are assigned their = HPKE key and
>>> later when a new member wants to verify the parent hash of = the node. In
>>> other words the BK approach was broken by unmerged leaves. = So, to make
>>> the "include the whole subtree in parent hash" approach = work, it seems
>>> new members would, for each node being verified, traverse = the nodes full
>>> sub-tree so as to weed out those nodes that were added = after the
>>> to-be-verified node got its HPKE
> key. (I
>>> believe this is the O(n) time that Hubert is referring = too?) In contrast,
>>> the new version of parent hash (using resolutions) has the = potential to
>>> be much faster; it requires hashing less data but also = visiting less of
>>> the tree.
> E.g.
>>> when verifying near the root the difference can be as much = as visiting
> order n
>>> nodes vs. visiting 1 node in the new construction.
>>>
>>> The more blanks & unmerged leaves in the tree the more = the new
>>> construction collapses to the old one. But only in the most = extreme case
>>> do they actually reach parity and the new approach is never = slower than
>>> the old.
>>>
>>> Needless to say, we didn't implement this stuff though, let = alone
> benchmark the
>>> 2 approaches so any hard data elucidating what the actual = difference is
> would be
>>> very welcome. Still, the new approach can only be as fast = or faster (but
> never
>>> slower) than the new one. Nor do I think it's any more = complicated to
> define or
>>> implement. And from a security perspective they both let = MLS meet our
> security
>>> definition. So regardless of how small the speed up is (and = ignoring the
> locking
>>> in the tree discussion above) it's still not clear to me = why we'd want
>>> to
> switch
>>> back.
>>>
>>> A meaningful attack that only works on the new but not old = construction
> would be
>>> one very quick way of changing my mind though! :-) But, I = believe such
>>> an
> attack
>>> would require either new adversarial capabilities and/or = break a new
>>> security property we didn't consider. (For the adversaries = & security we
>>> considered, there is no security loss with the new approach = compared to
>>> the old one.)
>>
>> I think we are now fully aligned on the definitions and the = performance
>> implications and now that we have better documentation we can = continue
> with the
>> interim effort.
>>
>> I=E2=80=99d however like to leave it as an open question = whether we shouldn=E2=80=99t
> reconsider
>> locking down entire subtrees as a security-in-depth measure if = we can
>> convince ourselves the performance toll is not too high. For = example, I=E2=80=99m
>> wondering if there isn=E2=80=99t a clever way to combine the = tree
> hash
>> and the parent hash. The tree hash has to be calculated for = every epoch
>> change anyway and it=E2=80=99s always in O(n).
>>
>> Thanks
>>
>> Raphael
>>
>>>
>>> - Jo=C3=ABl
>>>
>>> On 01/01/2021 17:30, Raphael Robert wrote:
>>>> Thanks for the lengthy explanation!
>>>>
>>>> I=E2=80=99m glad we are on the same page regarding the = definition of the
> resolution.
>>>> I think I understand where the misunderstanding is = coming from.
>>>>
>>>> Initially you proposed a =E2=80=9Cstrong hash=E2=80=9D = solution on the ML (on Oct 23
>>>> 2020) that was the following:
>>>>
>>>> "strong parent_hash" : Define parent_hash to include = tree_hash (and
>>>> tree_hash to *not* include parent_hash). The tree_hash = of a node covers
>>>> all values in the subtree rooted at that node  = (except the
>>>> parent_hashes and signatures). So basically something = like this: -
>>>> leaf.tree_hash :=3D H(leaf.data) - node.tree_hash :=3D = H(node.data,
>>>> node.lchild.tree_hash, node.rchild.tree_hash) - = root.parent_hash :=3D 0 -
>>>> node.parent_hash :=3D H(node.parent.tree_hash, = node.parent.parent_hash).
>>>>
>>>> This definition did include the whole subtree and = therefore I was
>>>> assuming that this would also end up in the spec = change. As far as I
>>>> now understand, you went for a more lightweight = approach where you say
>>>> that just using the resolution is enough, because = pinning all nodes in
>>>> the subtree is not necessary and would only prevent = =E2=80=9Cbenign=E2=80=9D attacks. I
>>>> guess I missed the
> part
>>>> where you switched from one concept to the other.
>>>>
>>>> What I discovered during implementation is that when = you only use the
>>>> resolution approach and the tree has no blanks, you are = not always able
>>>> to detect if the attacker has swapped two leaves. This = might indeed
>>>> just be a benign attack in the sense that the tree = invariant is not
>>>> violated.
>>>>
>>>> At this point I don=E2=80=99t have strong arguments for = or against using the
>>>> resolution approach, I would have to think about it = some more. Just as
>>>> a reminder for context, the original concept by = Benjamin and Karthik
>>>> was =E2=80=9Cparent hash covers the tree hash=E2=80=9D. = That=E2=80=99s pretty much what you
>>>> initially proposed, except that it also covered the = KeyPackage at the
>>>> leaf level, not just the HPKE public key.
>>>>
>>>> My question right now would be: What is the benefit of = the lightweight
>>>>  resolution-based approach? If it=E2=80=99s just = efficiency, we should look at
> whether
>>>> there=E2=80=99s really that much to gain.
>>>>
>>>> On efficiency: The parent hashes are verified in two = instances: a) when
>>>> a new member joins the group and validates the public = tree it received
>>>> and b) when a member receives a full Commit from = another member.
>>>>
>>>> Re a): The spec now says "Moreover, when joining a = group, new members
>>>> MUST authenticate each non-blank parent node P. A = parent node P is
> authenticated=E2=80=9D.
>>>> This means the effort is linear to start with. = Depending on how you
>>>> define the operation, it is even worse than linear. Say = the tree has n
>>>> leaves and therefore 2n-1 nodes. For every node, we = need to iterate
>>>> over at least a
> part
>>>> of the subtree and collect public keys that we then = concatenate. We end
>>>> up only hashing once per node, but with a variable size = payload. I
>>>> think the cost of navigating the subtree and collecting = the keys is
>>>> O(log n) for the =E2=80=9Cresolution approach and O(n) = for the =E2=80=9Cdescendants"
>>>> approach and the cost of hashing is linearly = proportional to the size
>>>> of the payload. If we assume that hashing is the most = expensive
>>>> operation, the total cost would be O(n * log n) for = =E2=80=9Cresolution=E2=80=9D and
>>>> O(n ^ 2) for =E2=80=9Cdescendants".
>>>>
>>>> Re b): It is very similar to a), except that we only = have to iterate
>>>> over log n nodes of the direct path, not the whole = tree. That means
>>>> that the total effort is O(log n * log n) for = =E2=80=9Cresolution=E2=80=9D and O(n *
>>>> log n) for =E2=80=9Cdescendants=E2=80=9D.
>>>>
>>>> There=E2=80=99s clearly a difference in terms of = efficiency between the two
>>>> approaches. That being said, we should keep in mind = that for small
> payloads,
>>>> hashing is a lot faster than other cryptographic = operations like e.g.
>>>> producing and verifying signatures. Since a new joiner = needs to also
>>>> verify n signatures when joining a group, it could well = be that the
>>>> effort of verifying the parent hashes is negligible = compared to the
>>>> cost of verifying all signatures.
>>>>
>>>> In summary: I still don=E2=80=99t have strong arguments = against the
>>>> =E2=80=9Cresolution=E2=80=9D approach, but I also have = a feeling that the efficiency
>>>> differences are not dramatic either.
>>>>
>>>> Happy New Year and thanks!
>>>>
>>>> Raphael
>>>>
>>>>> On 1. Jan 2021, at 15:48, Mularczyk Marta
>>>>> <marta.mularczyk@inf.ethz.ch
> <mailto:marta.mularczyk@inf.ethz.ch>
>>>>> <mailto:marta.mularczyk@inf.ethz.ch
>>>>> <mailto:marta.mularczyk@inf.ethz.ch>>
>>>>> <mailto:marta.mularczyk@inf.ethz.ch
> <mailto:marta.mularczyk@inf.ethz.ch> = <mailto:marta.mularczyk@inf.ethz.ch
> <mailto:marta.mularczyk@inf.ethz.ch>>>>
>>>>> wrote:
>>>>>
>>>>> Hi Raphael,
>>>>>
>>>>> Thanks for explaining! Using "descendants" is = definitely better for
>>>>> security, but also, as Hubert mentioned, less = efficient.
>>>>>
>>>>> Also we did understand =E2=80=9Cresolution=E2=80=9D = the same way as you when we
>>>>> proposed the strong parent hash (sorry for the = confusion).
>>>>>
>>>>> But we obviously really want to understand if/why = using resolution is
>>>>>  insecure. Ultimately, the security property = we care about is that
>>>>> privacy and authenticity of application messages = holds. The Parent
>>>>> Hash mechanism helps us ensure this holds also for = epochs in
>>>>> adversarially generated groups, as long as the = adversary does not
>>>>> control any leaves in this epoch (i.e. does not = know the signing key
>>>>> of the leaf). So to really see if your examples = break security, it
>>>>> would be good to see if they let us violate this = security goal.
>>>>>
>>>>> To see why we believe the new parent hash notion = (i.e. with
>>>>> resolutions) achieves this, let us first clarify = what technical
>>>>> property about (even adversarially produced) = ratchet trees we want
>>>>> from verifying parent hashes. It=E2=80=99s not that = the adversary can=E2=80=99t
>>>>> produce manipulated trees at all. It=E2=80=99s that = the only manipulations
>>>>> she is able to do will not let her produce a tree = that violates the
>>>>> tree invariant. That=E2=80=99s because (in our = model) when the tree invariant
>>>>> holds then we can show that the epoch is secure.
>>>>>
>>>>> So some manipulations *are* possible. They are just = =E2=80=9Cbenign=E2=80=9D. For
>>>>> example, suppose adversary A controls a leaf L with = HPKE key pk in
>>>>> tree T (i.e. she knows the signing key of L=E2=80=99s= owner). Then A can
>>>>> construct a new tree T=E2=80=99 identical to T but = where leaf L has pk=E2=80=99 !=3D pk
>>>>> (say, by performing a commit at leaf L to obtain = T=E2=80=99). But for this,
>>>>> in T=E2=80=99 leaf L must still be controlled by A. = We call this manipulation
>>>>> =E2=80=9Cbenign=E2=80=9D because even though A = might now break privacy of application
>>>>> messages in epoch with tree T=E2=80=99 it doesnt = violate our security goal
>>>>> because privacy is conditioned on A *not* = controlling any leaves.
>>>>>
>>>>> Conversely, one thing A can *not* do is the = following. Say T=E2=80=99 has a
>>>>> node V with HPKE public key pk0 such that A knows = corresponding sk0.
>>>>> Then for T=E2=80=99 to pass verification, it must = contain a leaf controlled
>>>>> by A. This holds since for T=E2=80=99 to pass = verification there must be a
>>>>> leaf in V=E2=80=99s subtree with a signature = covering a hash that includes
>>>>> pk0. I.e. some leaf must =E2=80=9Cattest=E2=80=9D = to having inserted pk0 into T=E2=80=99.
>>>>> (Recall that in our model the adversary can=E2=80=99t= just leak sk0 alone.
>>>>> They must leak a full state of some client which = also means leaking
>>>>> the client's signing key.)
>>>>>
>>>>> So our question to you is the following. (Does this = make sense? And)
>>>>> we=E2=80=99re not exactly sure what you have in = mind when you say =E2=80=9Cswapping
>>>>> out two leaf nodes=E2=80=9D. But we think it would = only be a problem if it is
>>>>> not benign. Is this true for your attack? Could you = expand a bit on
>>>>> what tree manipulation you have in mind?
>>>>>
>>>>> Best, Jo=C3=ABl& Marta
>>>>>
>>>>>
> = --------------------------------------------------------------------------= ------
>
>
>>>>
>>>>>
>>>>>
>>> *From:* MLS <mls-bounces@ietf.org <mailto:mls-bounces@ietf.org>
>>> <mailto:mls-bounces@ietf.org
> <mailto:mls-bounces@ietf.org>> <mailto:mls-bounces@ietf.org
> <mailto:mls-bounces@ietf.org>
>>> <mailto:mls-bounces@ietf.org <mailto:mls-bounces@ietf.org>>>> on behalf
>>> of
>>>>> Hubert Chathi <hubertc@matrix.org <mailto:hubertc@matrix.org>
>>>>> <mailto:hubertc@matrix.org
> <mailto:hubertc@matrix.org>> <mailto:hubertc@matrix.org
> <mailto:hubertc@matrix.org>
>>>>> <mailto:hubertc@matrix.org <mailto:hubertc@matrix.org>>>> *Sent:*
>>>>> Thursday, December 31, 2020 5:36:53 PM *To:* mls@ietf.org
> <mailto:mls@ietf.org> <mailto:mls@ietf.org <mailto:mls@ietf.org>>
>>>>> <mailto:mls@ietf.org <mailto:mls@ietf.org> <mailto:mls@ietf.org
> <mailto:mls@ietf.org>>> *Subject:* Re: [MLS] New Parent = Hash
>>>>>
>>>>> I think that if you use "descendants" as you define = it, then
>>>>> calculating the parent_hash will become O(n) all = the time, rather
>>>>> than O(log n) in the best-case, since the size of = the descendants
>>>>> list will be O(n).  I'm not sure if there's a = good way to maintain
>>>>> O(log n) and still provide the desired security.
>>>>>
>>>>> On Thu, 31 Dec 2020, at 06:47, Raphael Robert = wrote:
>>>>>> Hi Jo=C3=ABl, Daniel and Marta,
>>>>>>
>>>>>> I just implemented the stronger parent hash = scheme you proposed in
>>>>>> the way it is described in the spec now. The = good news is that it
>>>>>> is implementable, the bad news is that is does = not solve the
>>>>>> problem you initially describe. Specifically, = swapping out two leaf
>>>>>> nodes still goes undetected.
>>>>>>
>>>>>> I think it is due to a terminology conflict, = but it would be great
>>>>>> if you could validate that assumption. In 7.4 = you introduce the
>>>>>> notion of =E2=80=9Coriginal child resolution=E2=80= =9D as " the array of
>>>>>> HPKEPublicKey values of the nodes in the = resolution of S=E2=80=9D. The term
>>>>>> =E2=80=9Cresolution=E2=80=9D is defined in 5.2. = It is essentially a way of dealing
>>>>>> with blank nodes by substituting them with the = first non-blank
>>>>>> descendants you find when descending the = subtree of a node. Here is
>>>>>> my assumption: You probably thought the = resolution would cover all
>>>>>> non-blank descendants of a node, not just the = first non-blank
>>>>>> descendant. In that case we would need another = function that does
>>>>>> that (let=E2=80=99s call it = =E2=80=9Cdescendants=E2=80=9D).
>>>>>>
>>>>>> If we look at the example of 5.2:
>>>>>>
>>>>>> - The resolution of node 3 is the list [A, CD, = C] - The
>>>>>> descendants of node 3 is the list [A, CD, C, = D]
>>>>>>
>>>>>> - The resolution of node 5 is the list [CD] - = The descendants of
>>>>>> node 5 is the list [CD, C, D] (we just need to = additionally filter
>>>>>> out C, because it is an unmerged leaf of node = 5)
>>>>>>
>>>>>> Here is a code snippet of what the = =E2=80=9Cdescendants=E2=80=9D function would
>>>>>> look like (sorry that it=E2=80=99s Rust, not = Python):
>>>>>>
>>>>>> fn descendants(x: NodeIndex, size: LeafIndex) = -> Vec<NodeIndex> {
>>>>>> if level(x) =3D=3D 0 { vec![x] } else { let = left_child =3D left(x); let
>>>>>> right_child =3D right(x, size); [ = descendants(left_child, size),
>>>>>> vec![x], descendants(right_child, size), ] = .concat() } }
>>>>>>
>>>>>> There=E2=80=99s a more efficient implementation = of course, this is just to
>>>>>>  illustrate.
>>>>>>
>>>>>> In other words, the new =E2=80=9Coriginal child = resolution=E2=80=9D of S would be
>>>>>> the subtree under S, but with filtered-out = blank nodes and unmerged
>>>>>> leaves of S.
>>>>>>
>>>>>> If my assumption is correct, I=E2=80=99ll = follow up quickly with a PR since
>>>>>> this is currently a blocker for interop based = on draft-11.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Raphael
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 12. Nov 2020, at 22:14, Joel Alwen = <jalwen@wickr.com
> <mailto:jalwen@wickr.com>
>>>>>>> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>>
>>>>>>> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>
> <mailto:jalwen@wickr.com <mailto:jalwen@wickr.com>>>> wrote:
>>>>>>>
>>>>>>> Hey people,
>>>>>>>
>>>>>>> Just a quick heads up that Daniel, Marta = and I put in a PR with a
>>>>>>> new version of strong parent hash to = prevent the attacks from the
>>>>>>> earlier thread. We tried to make it as = minimal as we could to
>>>>>>> help with deniability while still = preventing the attacks
>>>>>>> permitted by weak parent hashes.
>>>>>>>
>>>>>>> In a nutshell, when computing parent_hash = at node v with parent p
>>>>>>> and sibling w we include - p's HPKE pubkey = - p's parent_hash
>>>>>>> value and - HPKE pub keys in the resolution = of w except for those
>>>>>>> belonging to leaves unmerged at p.
>>>>>>>
>>>>>>> As a sanity check, notice that as long as = p's keys remain the
>>>>>>> same one can always recompute the same = parent_hash value at v as
>>>>>>> was initially computed by the member that = set p's keys. (In other
>>>>>>> words, new members can verify that the = stored parent_hash values
>>>>>>> match whats in the tree.) In particular, = that's coz as long as
>>>>>>> p's keys are unchanged so is the resolution = of w. The only
>>>>>>> exception are leaves being added as = unmerged at w. But those
>>>>>>> leaves are also added as unmerged at p so = they are left out of
>>>>>>> the hash.
>>>>>>>
>>>>>>> As for deniability, at least parent_hash = only binds HPKE keys and
>>>>>>>  nothing else (like, say, credentials = or signatures). Its the
>>>>>>> best we were able to come up with for = now...
>>>>>>>
>>>>>>> - jo=C3=ABl
>>>>>>>
>>>>>>> = _______________________________________________ MLS mailing list
>>>>>>>  MLS@ietf.org <mailto:MLS@ietf.org> <mailto:MLS@ietf.org
> <mailto:MLS@ietf.org>> <mailto:MLS@ietf.org= <mailto:MLS@ietf.org>
>>>>>>> <mailto:MLS@ietf.org <mailto:MLS@ietf.org>>>
>>>>>>> https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>>>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>>
>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>>>
>>>>>>
>>>>>> _______________________________________________ = MLS mailing list
>>>>>> MLS@ietf.org <mailto:MLS@ietf.org> <mailto:MLS@ietf.org
> <mailto:MLS@ietf.org>> <mailto:MLS@ietf.org= <mailto:MLS@ietf.org>
> <mailto:MLS@ietf.org <mailto:MLS@ietf.org>>>
>>>>>> https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>>
>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>>>
>>>>>>
>>>>>
>>>>> _______________________________________________ MLS = mailing list
>>>>> MLS@ietf.org <mailto:MLS@ietf.org> <mailto:MLS@ietf.org
> <mailto:MLS@ietf.org>> <mailto:MLS@ietf.org= <mailto:MLS@ietf.org>
> <mailto:MLS@ietf.org <mailto:MLS@ietf.org>>>
>>>>> https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>>
>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>
>>>>> <https://www.ietf.org/mailman/listinfo/mls
> <https://www.ietf.org/mailman/listinfo/mls>>>
>>
>
> _______________________________________________ MLS mailing list MLS@ietf.org
> <mailto:MLS@ietf.org> https://www.ietf.org/mailman/listinfo/mls=
> <https://www.ietf.org/mailman/listinfo/mls>
>

= --Apple-Mail=_6B027BAA-AB23-4F23-91E4-4807CD31414B-- From nobody Sun Jan 17 00:31:06 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 976353A0C88 for ; Sun, 17 Jan 2021 00:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=YqUXsIan; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j5UCaHSC 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 zkrl3ygWjdPS for ; Sun, 17 Jan 2021 00:31:02 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76363A0C86 for ; Sun, 17 Jan 2021 00:31:01 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C61E55C005D for ; Sun, 17 Jan 2021 03:13:16 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 17 Jan 2021 03:13:16 -0500 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= fm1; bh=PK64kgieblOCiJ31LZT2JIcXwksMybgwurk+R3ZPZpA=; b=YqUXsIan 8oRDgDC9mdxWIIQ821ZuEFz6TX4WlZzuHeqLaesJV1pYkvDfRwUECPzAwvWkB2Ju ff9X/NA4DrY7fBHzFao3d3ezkmZzK4x/MWaLr09jNAZUgX4HFNGxGOXTz/SSWHAk rFc7kh/GkQJASqcJDxatAvumYOyUlQVAfZfr0S75Rl1EWBlYHQOkaH4FFvLpbzZ0 1y1oHiLCLQLQD6nKxdBA01xinTREj87ol0Z3QoYQhnosCiyKzBGDKw4K5SndSi74 C2wwWtFJyR17zvH0WHsDyk4TfSPQlep0dUQRAowYY3DFSjfGX++CMEDCYt69p8+4 /2WxipqaFkKQVg== 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=fm1; bh=PK64kgieblOCiJ31LZT2JIcXwksMy bgwurk+R3ZPZpA=; b=j5UCaHSC6n+7HnmNPiZp5S3ztyxyvfzWaZp3/lf+pMgvZ t7EyEWmodPPBZhRBeKsvh6Bd9jQGJi6XJ4Ic00Uk7lTrxz5qBqj71GJrrbb8rS0z 3ySw6LU7u+ZyS+m7mxPMvE50hkwszaHsUgIYEpcaRw+aR7BqQfnAnlLbTYrGfL8Y iKFPUZU9tZDZA+T8dLOpfYYqG98/gUFKeV/iRLsP5AdikAkMduYP5C9s+AigDvCw Z88T5hTpORPRen6BR9xb3CuX+5+x6V4VTBMl2k0NDwcro7eTI00iXAUIxLWTbgNG TzcbjR0muBRwjDZR9XeC0S3tVR+O/phLR3UxRW6Mw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdehgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepuddtgedrvddtledrudekke drgedtnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59-669.internal.cloudapp.net (unknown [104.209.188.40]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F3A924005C for ; Sun, 17 Jan 2021 03:13:16 -0500 (EST) Content-Type: multipart/alternative; boundary="===============1246808207129635236==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210117081316.9F3A924005C@mailuser.nyi.internal> Date: Sun, 17 Jan 2021 03:13:16 -0500 (EST) 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, 17 Jan 2021 08:31:04 -0000 --===============1246808207129635236== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+0/-1/=F0=9F=92=AC0) 1 issues closed: - Prominently explain the role of the two documents https://github.com/ml= swg/mls-architecture/issues/29 [editorial]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============1246808207129635236== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 17, 2021

Issues

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

1 issues closed:

Repositories tracked by this digest:

--===============1246808207129635236==-- From nobody Wed Jan 20 04:34:54 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 1050C3A11BB for ; Wed, 20 Jan 2021 04:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E17VTkt670RJ for ; Wed, 20 Jan 2021 04:34:51 -0800 (PST) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050::465:101]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DCB3A11BC for ; Wed, 20 Jan 2021 04:34:50 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (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-101.mailbox.org (Postfix) with ESMTPS id 4DLQ2d1pMDzQlWQ; Wed, 20 Jan 2021 13:34:49 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id 2MELhC_77rUS; Wed, 20 Jan 2021 13:34:45 +0100 (CET) Date: Wed, 20 Jan 2021 13:34:42 +0100 (CET) From: Konrad Kohbrok To: Benjamin Beurdouche , Raphael Robert Cc: ML Messaging Layer Security Message-ID: <2030165147.99189.1611146082580@office.mailbox.org> In-Reply-To: <186C9715-C8E7-4F59-99F4-66B2D86AAAB4@inria.fr> References: <186C9715-C8E7-4F59-99F4-66B2D86AAAB4@inria.fr> 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: -5.77 / 15.00 / 15.00 X-Rspamd-Queue-Id: D797D1857 X-Rspamd-UID: 5e9ef9 Archived-At: Subject: Re: [MLS] Improving client authentication 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: Wed, 20 Jan 2021 12:34:53 -0000 Hi everyone, In light of this discussion, I've re-opened PR #439 (https://github.com/mls= wg/mls-protocol/pull/439), which proposed to make identities unique on a pe= r-group basis. I've changed the PR to include signature keys as well. I'd a= ppreciate any feedback! Cheers, Konrad > Benjamin Beurdouche hat am 09.12.2020 10:2= 3 geschrieben: >=20 >=20 > Hi Raphael, Hi all, >=20 > I finally had time to have a look at your proposal and I agree with it. I= think this is a nice improvement. >=20 > See more inline: >=20 >=20 >=20 > > On 29 Nov 2020, at 18:13, Raphael Robert wrote: > >=20 > >=20 > > Hi all, > >=20 > > Recently there was some discussion about identities and credentials in = MLS [1][2], in particular whether identities and signatures should be uniqu= e per group. The architecture draft defines things as follows: > >=20 > > "Formally, a Client is a set of cryptographic objects composed by publi= c values such as a name (an identity), a public encryption key and a public= signature key. Ownership of a Client by a user is=C2=A0determined by the f= act that the user has knowledge of the associated secret values. When a Cli= ent is part of a Group, it is called a Member and its signature key pair un= iquely defines its identity=C2=A0to other clients or members in the Group. = In some messaging systems, clients belonging to the same user must all shar= e the same identity key pair, but MLS does not assume this. > >=20 > > Users will typically own multiple Clients, potentially one or more per = end-user devices (phones, web clients or other devices...) and may choose t= o authenticate using the same signature key=C2=A0across devices, using one = signature key per device or even one signature key per group.=E2=80=9D > >=20 > > In other words: while not encouraged, clients can have the same identit= y and the same signature key. As such, they become mostly indistinguishable= from each other, except for their index in the tree. This was initially wo= rded that way to clearly support real-world use cases where clients indeed = have the same credential and MLS can just be used as a key negotiation prot= ocol that builds on top of that. So far this has not received a lot of scru= tiny, but I can see scenarios where this can clearly lead to attacks. A fir= st scenario is described by Britta in [2]. Another attack =E2=80=93 where a= ttackers use said indistinguishability for impersonation =E2=80=93 could go= as follows: > >=20 > > - Alice has two devices, A1 and A2. Both devices use the same credentia= l, meaning they have the same identity and signature key. > > - An attacker briefly compromises A2 and creates a legitimate key packa= ge. > > - The attacker then creates an UpdateProposal with that key package and= uses the index of A1 as the sender in the MLSPlaintext framing, as well as= a RemoveProposal for A2. > > - Other members receive and process these proposals, and to them the Up= dateProposal looks like it was issued by A1 (since the index is the one fro= m A1 and the signature key is shared between A1 and A2). > > - Finally one of the other members sends a Commit referencing the propo= sals, seemingly evicting A2 from the group. > > - The attacker however still knows the HPKE private leaf key of A1 and = is therefore still part of the group and can act as a passive attacker unti= l A1 is evicted. > > - Incoming messages will look broken for A1, but it might take a while = before A1 notices, if ever. > >=20 > > Besides UpdateProposals, A2 could also send a full Commit or applicatio= n messages in the name of A1. Maybe other attacks could be mounted that way= . >=20 > To start with, I agree this is a valid threat that we should consider. >=20 > This attack is something that we have known for a while and is part of mu= ltiple variants of > this problem, but there are no clear solutions in the context of a strong= threat model. > This is simply because for MLS we have a significantly stronger threat mo= del than all other > messaging systems have as we often consider active malicious insider and = full state device > compromises which lead to many-group compromises. >=20 > For instance, if I am correct, the attack you mentioned is valid because = it works across devices, > so the natural solution is key separation. But this solution would not wo= rk - even if there were > one signature key per group on the device - in the case where you conside= r that compromising > the device will lead to a compromise of all signature keys on the device = (of all groups). >=20 > Is this a reason=C2=A0for not doing anything here? No.=C2=A0Even though w= e can=E2=80=99t achieve perfect security, > especially in the context of strong attackers performing targeted attacks= , **I am very inclined > to agree with you and force requiring the signature key to be unique per = group** as it provides > better defense in depth. This makes me immediately think about the proble= m of detecting the key-reuse > which is not an easy task to handle. An honest DS would be helpful as it = could help check that all > the stored key packages for a user have different signature public keys, = but that=E2=80=99s not perfect > and my intuition is that the best case is a situation where we can prove = some security only in > the absence of an attack and not in cases of compromise. Note that this p= roblem of key reuse > detection already exists and is not new, so that can=E2=80=99t be an argu= ment against *requiring* unique keys. >=20 > > I think these kind of attacks are bad enough to look at things again. I= propose the following: > >=20 > > 1. Restrict the sharing of credentials: Identities and signature keys M= UST each be unique per group. >=20 > I am in favor of doing this. As you note below, we can also leverage OS k= eystores and > hardware features to limit the ability of the attacker to compromise all = keys (including across groups) at once. > In that situation we can reduce the risk to an attacker being able to sig= n arbitrary things > without having access to the actual key, which is good for both FS and PC= S. >=20 >=20 > > 2. Solve the use case of per-user devices differently. > >=20 > > Regarding the latter, I think we already have all the ingredients we ne= ed. The protocol spec has the following definition of credentials: > >=20 > > struct { > > CredentialType credential_type; > > select (Credential.credential_type) { > > case basic: > > BasicCredential; > >=20 > > case x509: > > Certificate chain<1..2^32-1>; > > }; > > } Credential; > >=20 > > We can use the fact that a whole chain can be provided for the X509 typ= e. So in case an application wants to use a per-user certificate, this cert= ificate could just move up in the chain and sign a per-device certificate t= hat has a unique identity and signature key. And btw, the same chain could = also be allowed for the BasicCredential type with a small spec change. >=20 > I also agree with this, intermediates can be used in a very efficient way= . >=20 > Something less relevant to this discussion but I want to mention it here.= .. > This raises an issue that I have seen a lot over the last few years: we n= eed something > which performs a similar role to the WebPKI but doesn=E2=80=99t have the = complexity of X.509. > Note that half of the attacks against TLS implementations are actually at= tacks against > ASN1/X.509 parsers, and we don=E2=80=99t really need this complexity for = MLS. >=20 > We should probably use X.509 in many cases because it is well supported b= y HSMs > but in the long run, I think we should create WG and start thinking of a = replacement to > X.509 for places (not the Web) that don=E2=80=99t need the complexity. >=20 >=20 >=20 > > Why is this better than before? Isn=E2=80=99t this just shifting the pr= oblem, because the per-user certificate could still issue an arbitrary numb= er of per-device certificates? > >=20 > > Firstly, impersonation attacks become harder (if not impossible) becaus= e the signature keys used to sign handshake & application messages are no l= onger shared across multiple devices. > >=20 > > Secondly, the (private) signature key of the per-user certificate is no= w only used very rarely, namely in the situation where a new per-device cer= tificate needs to be issued. This opens up new possibilities to better prot= ect that key: it doesn=E2=80=99t have to be on the device necessarily, or i= t could be stored in a secure enclave, or it could be encrypted with a pass= phrase the user needs to provide, etc. None of these protection mechanisms = could be applied to the per-device certificate, because its signing key nee= ds to be readily available at all times (e.g. mobile messaging apps typical= ly do operations in the background without requiring any action from the us= er, like sending end-to-end encrypted delivery receipts). > >=20 > > Thirdly, we could limit the validity of the per-device certificate. As = mentioned above, that signature key is still relatively exposed and might a= s accessible to an attacker as the rest of the group state during a brief c= ompromise. Limiting for how much time a per-device certificate is valid, wo= uld at least mitigate the risk a bit. We could allow updates to the per-dev= ice certificate under the condition that a) the UpdateProposal is signed wi= th the old certificate, b) that the identity doesn=E2=80=99t change and c) = that the per-user certificate is still the same. > >=20 > > I think the above proposal would make authentication in MLS better whil= e still catering for the initial use cases. >=20 > Overall, I think these proposals are good and we I suggest we do this ! > Thanks for looking into it. >=20 > Ben. >=20 >=20 > >=20 > > Raphael > >=20 > >=20 > > [1]=C2=A0https://github.com/mlswg/mls-protocol/pull/439 > > [2]=C2=A0https://mailarchive.ietf.org/arch/msg/mls/6tjSWyAesfU125IFRDfM= hRLtsPM/ > >=20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Sun Jan 24 00:31:15 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 524183A10DA for ; Sun, 24 Jan 2021 00:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, 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=kvqisNr/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oponIS96 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 4JyCo7GU3bl3 for ; Sun, 24 Jan 2021 00:31:11 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2283A10D7 for ; Sun, 24 Jan 2021 00:31:10 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 156695C010C for ; Sun, 24 Jan 2021 03:14:14 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 24 Jan 2021 03:14:14 -0500 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= fm1; bh=OapcpVnW19A52adyWAyd89e30cwAfWgUiuhk34qAPb4=; b=kvqisNr/ AvNSsux9wT+ZHWRIl4bGDHqJozS4bH8RboxX4ysNF4K8WdRor2LFDoxtASeueMkm 7vrfJpc90B2rTiLmB+aIUqFSaqWhxou0CcFt1Mw254/Ah1+SFcrw3D6wEpvEpCSM WQwSPevY2NsgdR7ChvZK/n8Xwjp3vPbu1ToVziK3IaLqNJhjcjzTDDABwfuZ1YyF lCNYei8Bc5NZPnJdo/zGfVzcCqt37dUYruzOS9Z+C4ixQJEAgp9dj0OHYkUf0ovA M4JYky8flhczr8baCXn/gAjfg8F8yzgSPQCJV4yKojAOtofMRLFEcPMf0Kcx3QdX 1l+Cj/GV6/mv/Q== 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=fm1; bh=OapcpVnW19A52adyWAyd89e30cwAf WgUiuhk34qAPb4=; b=oponIS96z4eCr9WfIQXDjwLoZtsh/Rh3v+LN6S1fU9swK no6tPwNSuqngjck9RLl2fTyJrmUr53fql6IvlJ7Zkt2p/uyoqn2vDDbVlMHKu2I3 Jr+lXVxlURJgQYm+sRH2XK74MnwLC6ubs9+jUNEnIRJy6eIjfyJtEl/65qIrVqlG jrkQNW6NLpjTtwfbc/LUDvKvf1nNM4wuhIpqJS6ZwSteQASCCaYRonfAozanckGn A//4vSOk3zQBWA3hBuhnEcoi4ncd2a4EEhrFXoEi3HqPD3mnKOCNW+KBwkhUZBmY I7gg2fiuhVNJriF3OSSjMIxrjZDmYhijCcK8GXAww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvddvhedrvddvvddrge eknecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-880.internal.cloudapp.net (unknown [52.225.222.48]) by mail.messagingengine.com (Postfix) with ESMTPA id DC817240057 for ; Sun, 24 Jan 2021 03:14:13 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6169853369946934013==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210124081413.DC817240057@mailuser.nyi.internal> Date: Sun, 24 Jan 2021 03:14:13 -0500 (EST) 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, 24 Jan 2021 08:31:13 -0000 --===============6169853369946934013== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+0/-5/=F0=9F=92=AC5) 5 issues received 5 new comments: - #74 Review from Sof=C3=ADa Celi (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/74=20 - #50 Provide details about Deniability (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/50 [editorial]=20 - #47 More clarity around the privacy specifications (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/47=20 - #45 Access control policy (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/45=20 - #44 Ghost Users / Authn Security Considerations (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/44 [editorial] [securi= ty]=20 5 issues closed: - Review from Sof=C3=ADa Celi https://github.com/mlswg/mls-architecture/i= ssues/74=20 - Provide details about Deniability https://github.com/mlswg/mls-architec= ture/issues/50 [editorial]=20 - More clarity around the privacy specifications https://github.com/mlswg= /mls-architecture/issues/47=20 - Ghost Users / Authn Security Considerations https://github.com/mlswg/ml= s-architecture/issues/44 [editorial] [security]=20 - Access control policy https://github.com/mlswg/mls-architecture/issues/= 45=20 Pull requests ------------- * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - more editorial changes (by uhoreg) https://github.com/mlswg/mls-protocol/pull/454=20 1 pull requests received 1 new comments: - #439 Identities SHOULD be unique per group (1 by kkohbrok) https://github.com/mlswg/mls-protocol/pull/439=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============6169853369946934013== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 24, 2021

Issues

mlswg/mls-architecture (+0/-5/=F0=9F=92=AC5)

5 issues received 5 new comments:

5 issues closed:

Pull requests

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

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============6169853369946934013==--