From nobody Wed Dec 9 01:24:39 2020 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 0F4A83A0FBB for ; Wed, 9 Dec 2020 01:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_TVD_FUZZY_SECURITIES=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 I9jgkQsyG9MH for ; Wed, 9 Dec 2020 01:24:33 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267A83A0FB6 for ; Wed, 9 Dec 2020 01:24:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.78,405,1599516000"; d="scan'208,217";a="481925650" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2020 10:24:00 +0100 From: Benjamin Beurdouche Message-Id: <186C9715-C8E7-4F59-99F4-66B2D86AAAB4@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_284FCEBF-0492-443B-BEEB-8314A2D0E179" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Wed, 9 Dec 2020 10:23:59 +0100 In-Reply-To: Cc: ML Messaging Layer Security To: Raphael Robert References: X-Mailer: Apple Mail (2.3654.20.0.2.21) 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, 09 Dec 2020 09:24:37 -0000 --Apple-Mail=_284FCEBF-0492-443B-BEEB-8314A2D0E179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Raphael, Hi all, I finally had time to have a look at your proposal and I agree with it. = I think this is a nice improvement. See more inline: > On 29 Nov 2020, at 18:13, Raphael Robert = wrote: >=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 = unique per group. The architecture draft defines things as follows: >=20 > "Formally, a Client is a set of cryptographic objects composed by = public values such as a name (an identity), a public encryption key and = a public signature key. Ownership of a Client by a user is determined by = the fact that the user has knowledge of the associated secret values. = When a Client is part of a Group, it is called a Member and its = signature key pair uniquely defines its identity to other clients or = members in the Group. In some messaging systems, clients belonging to = the same user must all share 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 to authenticate using the same signature key across 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 = identity and the same signature key. As such, they become mostly = indistinguishable from each other, except for their index in the tree. = This was initially worded 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 protocol that builds on top of that. So far = this has not received a lot of scrutiny, but I can see scenarios where = this can clearly lead to attacks. A first scenario is described by = Britta in [2]. Another attack =E2=80=93 where attackers 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 = credential, meaning they have the same identity and signature key. > - An attacker briefly compromises A2 and creates a legitimate key = package. > - 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 = UpdateProposal looks like it was issued by A1 (since the index is the = one from A1 and the signature key is shared between A1 and A2). > - Finally one of the other members sends a Commit referencing the = proposals, 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 until 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 = application messages in the name of A1. Maybe other attacks could be = mounted that way. To start with, I agree this is a valid threat that we should consider. This attack is something that we have known for a while and is part of = multiple 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 = model than all other messaging systems have as we often consider active malicious insider and = full state device compromises which lead to many-group compromises. 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 = work - even if there were one signature key per group on the device - in the case where you = consider that compromising the device will lead to a compromise of all signature keys on the device = (of all groups). Is this a reason for not doing anything here? No. Even though we 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 = problem of detecting the key-reuse=20 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 = problem of key reuse detection already exists and is not new, so that can=E2=80=99t be an = argument against *requiring* unique keys. > 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 = MUST each be unique per group. I am in favor of doing this. As you note below, we can also leverage OS = keystores and=20 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 = sign arbitrary things without having access to the actual key, which is good for both FS and = PCS. > 2. Solve the use case of per-user devices differently. >=20 > Regarding the latter, I think we already have all the ingredients we = need. 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 = type. So in case an application wants to use a per-user certificate, = this certificate could just move up in the chain and sign a per-device = certificate that 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. I also agree with this, intermediates can be used in a very efficient = way. 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 = need 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 = attacks against ASN1/X.509 parsers, and we don=E2=80=99t really need this complexity for = MLS. We should probably use X.509 in many cases because it is well supported = by HSMs but in the long run, I think we should create WG and start thinking of a = replacement to=20 X.509 for places (not the Web) that don=E2=80=99t need the complexity. > Why is this better than before? Isn=E2=80=99t this just shifting the = problem, because the per-user certificate could still issue an arbitrary = number of per-device certificates?=20 >=20 > Firstly, impersonation attacks become harder (if not impossible) = because the signature keys used to sign handshake & application messages = are no longer shared across multiple devices.=20 >=20 > Secondly, the (private) signature key of the per-user certificate is = now only used very rarely, namely in the situation where a new = per-device certificate needs to be issued. This opens up new = possibilities to better protect that key: it doesn=E2=80=99t have to be = on the device necessarily, or it could be stored in a secure enclave, or = it could be encrypted with a passphrase the user needs to provide, etc. = None of these protection mechanisms could be applied to the per-device = certificate, because its signing key needs to be readily available at = all times (e.g. mobile messaging apps typically do operations in the = background without requiring any action from the user, 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 as accessible to an attacker as the rest of the group state during = a brief compromise. Limiting for how much time a per-device certificate = is valid, would at least mitigate the risk a bit. We could allow updates = to the per-device certificate under the condition that a) the = UpdateProposal is signed with 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 = while still catering for the initial use cases. Overall, I think these proposals are good and we I suggest we do this ! Thanks for looking into it. Ben. >=20 > Raphael >=20 >=20 > [1] https://github.com/mlswg/mls-protocol/pull/439 = > [2] = https://mailarchive.ietf.org/arch/msg/mls/6tjSWyAesfU125IFRDfMhRLtsPM/ = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_284FCEBF-0492-443B-BEEB-8314A2D0E179 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Raphael, Hi all,

I = finally had time to have a look at your proposal and I agree with it. I = think this is a nice improvement.

See more inline:

On 29 = Nov 2020, at 18:13, Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:

Hi all,

Recently there was some = discussion about identities and credentials in MLS [1][2], in particular = whether identities and signatures should be unique per group. The = architecture draft defines things as follows:

"Formally, a Client is a set of = cryptographic objects composed by public values such as a name (an = identity), a public encryption key and a public signature key. Ownership = of a Client by a user is determined by the fact that the user has = knowledge of the associated secret values. When a Client is part of a = Group, it is called a Member and its signature key pair uniquely defines = its identity to other clients or members in the Group. In some = messaging systems, clients belonging to the same user must all share the = same identity key pair, but MLS does not assume this.

Users will typically own multiple Clients, potentially one or = more per end-user devices (phones, web clients or other devices...) and = may choose to authenticate using the same signature key across = devices, using one signature key per device or even one signature key = per group.=E2=80=9D

In= other words: while not encouraged, clients can have the same identity = and the same signature key. As such, they become mostly = indistinguishable from each other, except for their index in the tree. = This was initially worded 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 protocol that builds on top of that. So far = this has not received a lot of scrutiny, but I can see scenarios where = this can clearly lead to attacks. A first scenario is described by = Britta in [2]. Another attack =E2=80=93 where attackers use said = indistinguishability for impersonation =E2=80=93 could go as = follows:

 -= Alice has two devices, A1 and A2. Both devices use the same credential, = meaning they have the same identity and signature key.
 - An attacker briefly compromises A2 and creates a = legitimate key package.
 - 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 UpdateProposal looks like it was issued = by A1 (since the index is the one from A1 and the signature key is = shared between A1 and A2).
 - Finally one of = the other members sends a Commit referencing the proposals, 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 until A1 is = evicted.
 - Incoming messages will look broken = for A1, but it might take a while before A1 notices, if ever.

Besides UpdateProposals, = A2 could also send a full Commit or application messages in the name of = A1. Maybe other attacks could be mounted that = way.

To = start with, I agree this is a valid threat that we should = consider.

This attack is something = that we have known for a while and is part of multiple 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 model than all = other
messaging systems have as we often consider active = malicious insider and full state device
compromises which lead = to many-group compromises.

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 work - even if there = were
one signature key per group on the device - in the case = where you consider that compromising
the device will lead to a = compromise of all signature keys on the device (of all = groups).

Is this a reason for = not doing anything here? No. Even though we 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 problem 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 problem of key reuse
detection already exists = and is not new, so that can=E2=80=99t be an argument against *requiring* = unique keys.

I think these kind of attacks are bad enough to look at = things again. I propose the following:

1. Restrict the sharing of credentials: = Identities and signature keys MUST each be unique per = group.

I am = in favor of doing this. As you note below, we can also leverage OS = keystores 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 sign arbitrary things
without having access to = the actual key, which is good for both FS and PCS.

2. Solve the use case of = per-user devices differently.

Regarding the latter, I think we = already have all the ingredients we need. The protocol spec has the = following definition of credentials:

struct {
    CredentialType credential_type;
    select (Credential.credential_type) {
        case basic:
            = BasicCredential;

        case x509:
            Certificate = chain<1..2^32-1>;
    };
} Credential;

We can use the fact that a whole chain can be provided for = the X509 type. So in case an application wants to use a per-user = certificate, this certificate could just move up in the chain and sign a = per-device certificate that 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.

I also agree with this, intermediates can be used = in a very efficient way.

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 need 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 attacks against
ASN1/X.509 = parsers, and we don=E2=80=99t really need this complexity for = MLS.

We should probably use X.509 in = many cases because it is well supported by 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.


Why is = this better than before? Isn=E2=80=99t this just shifting the problem, = because the per-user certificate could still issue an arbitrary number = of per-device certificates? 

Firstly, impersonation attacks become = harder (if not impossible) because the signature keys used to sign = handshake & application messages are no longer shared across = multiple devices. 

Secondly, the (private) signature key of the per-user = certificate is now only used very rarely, namely in the situation where = a new per-device certificate needs to be issued. This opens up new = possibilities to better protect that key: it doesn=E2=80=99t have to be = on the device necessarily, or it could be stored in a secure enclave, or = it could be encrypted with a passphrase the user needs to provide, etc. = None of these protection mechanisms could be applied to the per-device = certificate, because its signing key needs to be readily available at = all times (e.g. mobile messaging apps typically do operations in the = background without requiring any action from the user, like sending = end-to-end encrypted delivery receipts).

Thirdly, we could limit the validity of = the per-device certificate. As mentioned above, that signature key is = still relatively exposed and might as accessible to an attacker as the = rest of the group state during a brief compromise. Limiting for how much = time a per-device certificate is valid, would at least mitigate the risk = a bit. We could allow updates to the per-device certificate under the = condition that a) the UpdateProposal is signed with the old certificate, = b) that the identity doesn=E2=80=99t change and c) that the per-user = certificate is still the same.

I think the above proposal would make = authentication in MLS better while still catering for the initial use = cases.

Overall, I think these proposals are good and we I = suggest we do this !
Thanks for looking into it.

Ben.


Raphael


[1] https://github.com/mlswg/mls-protocol/pull/439
[2] https://mailarchive.ietf.org/arch/msg/mls/6tjSWyAesfU125IFRDfMh= RLtsPM/

_____________________________________________= __
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_284FCEBF-0492-443B-BEEB-8314A2D0E179-- From nobody Sat Dec 12 23:45:57 2020 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 42BC03A15AB for ; Sat, 12 Dec 2020 23:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RJ+dJg+q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QWF6Tp+c 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 r2oDb7H4o83t for ; Sat, 12 Dec 2020 23:45:55 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39D23A15AA for ; Sat, 12 Dec 2020 23:45:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6CF115C00A8 for ; Sun, 13 Dec 2020 02:38:38 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 13 Dec 2020 02:38:38 -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=x77Dm70MERnNDBnqpvgydQzF0J/8o5QPnXizIxVo5Bk=; b=RJ+dJg+q 1wjeh8v9rzhTm6lhd6gAznQFAMaXopZ9sCOWMDlvusrULZWw0PJpSGKdzIdtCeEb iyKQPF5a4oISefXG/5rZ8FPs08dJSpc/vyK0MhHDpKtteAOQbRFdQaNBzbV7Ir4Z 7x/TCPGmatq+ez4qhVHdJF8cQ0jH1wUXmNN7aOIB20qQFiIgnjl9KoJkbFxJMzyp KMoRaOP010SUKP2SDeHTsyN1tJ9l5PoGOL6H4AHiuOkk+pmQ7qFc+sDiLylGRKET mCgvQ58zd/IZ4+gGhpMFW2kVJCtl665U3NlrhXPgBCr8Imck1MDy8da52sgSytw+ sCi6Z/5PgY5t+g== 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=x77Dm70MERnNDBnqpvgydQzF0J/8o 5QPnXizIxVo5Bk=; b=QWF6Tp+cc2yjxU0GjvR4xIMp6lQaFsNJYCtOl7veyr3k5 XLwcWh/WlhyEIaKyVrNiod+ttCqsLd5/a20ozvq/3ZtP2f4nlZQRFTBO1UX8wR4I zisi2j5ai/AFMLDIhJ46asevmvgviq2dxV7M/2IIwPHb8KplvJnPd+h0JJVpLCk+ 9UrJGKkxr9GrS0qcmZaUFEIAOHCuFeejS7FPiJbuzutQgUDnlYLgOSaVkRoA1wOk XWAmta0GiO2RjAo+Hnkvf76u6e4i0YLnnFcWPLm1gslfIS4d4K2kmF+1TJSMzz2n nRedK0+7pZDhlSbrqB/EOHKH82S2HPmKy3a68dqSg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekhedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedufedrjeejrdekuddrud eileenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az184-911.internal.cloudapp.net (unknown [13.77.81.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 41BE5240057 for ; Sun, 13 Dec 2020 02:38:38 -0500 (EST) Content-Type: multipart/alternative; boundary="===============3043275172798646060==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20201213073838.41BE5240057@mailuser.nyi.internal> Date: Sun, 13 Dec 2020 02:38:38 -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, 13 Dec 2020 07:45:56 -0000 --===============3043275172798646060== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC4) 3 pull requests received 4 new comments: - #446 Move joiner_secret to the end of the first KDF cycle in the Key Sc= hedule (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/446=20 - #442 Add an "AppAck" proposal (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/442=20 - #435 Fix parent hash verification (2 by bifurcation) https://github.com/mlswg/mls-protocol/pull/435=20 1 pull requests merged: - Move joiner_secret to the end of the first KDF cycle in the Key Schedule https://github.com/mlswg/mls-protocol/pull/446=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============3043275172798646060== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday December 13, 2020

Pull requests

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

3 pull requests received 4 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============3043275172798646060==-- From nobody Sun Dec 13 20:21:28 2020 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 3C00E3A0E7E; Sun, 13 Dec 2020 20:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wad0e0eeB9SO; Sun, 13 Dec 2020 20:21:26 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 987EB3A0E7B; Sun, 13 Dec 2020 20:21:25 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BE4LIU0010096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Dec 2020 23:21:23 -0500 Date: Sun, 13 Dec 2020 20:21:18 -0800 From: Benjamin Kaduk To: Benjamin Beurdouche Cc: Raphael Robert , ML Messaging Layer Security Message-ID: <20201214042118.GV64351@kduck.mit.edu> References: <186C9715-C8E7-4F59-99F4-66B2D86AAAB4@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <186C9715-C8E7-4F59-99F4-66B2D86AAAB4@inria.fr> 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: Mon, 14 Dec 2020 04:21:27 -0000 Hi Ben, Taking a bit of a tangent... On Wed, Dec 09, 2020 at 10:23:59AM +0100, Benjamin Beurdouche wrote: > > > On 29 Nov 2020, at 18:13, Raphael Robert wrote: > 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 need something which performs a similar role to the WebPKI but > doesn’t have the complexity of X.509. Note that half of the attacks > against TLS implementations are actually attacks against ASN1/X.509 > parsers, and we don’t really need this complexity for MLS. > > We should probably use X.509 in many cases because it is well supported > by 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’t > need the complexity. This isn't quite what you're hoping for, but there's some work in the COSE WG to subset X.509 certificates and produce a more compact encoding for them; the same machinery will be naturally usable for making "CBOR native" certificates (that use COSE for the signatures instead of operating on the ASN.1 DER) that don't allow the full complexity of X.509. The doc is draft-mattsson-cose-cbor-cert-compress (we'll be rechartering in order to pick it up as a WG item). -Ben From nobody Sun Dec 13 21:23:59 2020 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 608A13A005D for ; Sun, 13 Dec 2020 21:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhB9BW8kEho8 for ; Sun, 13 Dec 2020 21:23:57 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FCA3A00C4 for ; Sun, 13 Dec 2020 21:23:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.78,417,1599516000"; d="scan'208";a="482743938" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.9]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 14 Dec 2020 06:23:44 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Benjamin Beurdouche Mime-Version: 1.0 (1.0) Date: Mon, 14 Dec 2020 06:23:44 +0100 Message-Id: <823434A1-E786-4ADB-AECB-BC20881A5831@inria.fr> References: <20201214042118.GV64351@kduck.mit.edu> Cc: Raphael Robert , ML Messaging Layer Security In-Reply-To: <20201214042118.GV64351@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: iPhone Mail (18B92) 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: Mon, 14 Dec 2020 05:23:58 -0000 Good to know. I=E2=80=99ll have a look :) Thanks for the info Ben ! B. > On Dec 14, 2020, at 5:21 AM, Benjamin Kaduk wrote: >=20 > =EF=BB=BFHi Ben, >=20 > Taking a bit of a tangent... >=20 >> On Wed, Dec 09, 2020 at 10:23:59AM +0100, Benjamin Beurdouche wrote: >>=20 >>> On 29 Nov 2020, at 18:13, Raphael Robert wrote: >> 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 need 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 atta= cks >> against TLS implementations are actually attacks 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 >> by 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 > This isn't quite what you're hoping for, but there's some work in the COSE= > WG to subset X.509 certificates and produce a more compact encoding for > them; the same machinery will be naturally usable for making "CBOR native"= > certificates (that use COSE for the signatures instead of operating on the= > ASN.1 DER) that don't allow the full complexity of X.509. The doc is > draft-mattsson-cose-cbor-cert-compress (we'll be rechartering in order to > pick it up as a WG item). >=20 > -Ben From nobody Sat Dec 19 23:56:03 2020 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 74A953A0BF4 for ; Sat, 19 Dec 2020 23:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=R7lqQq8L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rL/Vugx2 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 oipMhrKTx3RY for ; Sat, 19 Dec 2020 23:55:55 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206E33A0BF2 for ; Sat, 19 Dec 2020 23:55:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 85E675C0067 for ; Sun, 20 Dec 2020 02:40:36 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 20 Dec 2020 02:40:36 -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=xxRAN3/qcL1hp3GtXhtLpnC6K0ZcRH1Fqh1DPXcfsVM=; b=R7lqQq8L ZCoq04YTmuaHUGWCoyfI3qEluQMc6hUCz4A8iWot498hi3eCRCxjKX0JhTRCj5I6 /1BzlYCePIaihrAb8oYfvPGYqWiXVUZj5UW+c3blIRCtIl6lpMMSsQFHROJWOtcz UNZvqzT6vEdNlBXB0Frfk0TZU/rDl0KUmWq3Efo6G9PY3l0a4dn/nVG2MAZci2T6 2d/gpLhE7cvMiZuYveXfHcAEUB/UgTUAbOJHxQxeka8IA0vUWm4AxrG0jHdmYKoR JfQAEzAubxaGBVEYFdlprEdQkitiUJowBjNsP30Hzs3EFgHV7b04qDM3Xd1bPaWY Q+pdKE2qyCKvGg== 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=xxRAN3/qcL1hp3GtXhtLpnC6K0ZcR H1Fqh1DPXcfsVM=; b=rL/Vugx2Hpd7DAabUZ7/hYko36MEcas7ln8w7U16ta0d2 SYcC3lHR0VbOyOiOeT5IW027GPGO7YnNAPcY+Lf5bTyhLvcWLcXWpZ+LAdFRKMcH roAt0eNagIY/HQcNjb6CRUhLKTUoYTm6fTuteLdTMd5AfbuFIzNgOvf6lVSRquCO PukoyaYGFftu2obpritDlpgukeReNh6OXodM3uqiNV27fOJ96ZaIY9NFIzVX1Q6A CBK0kSjYOPW/jJGeevLMzmCnK3STyDzvYK5MrivJXTUfy5Ieq0mHkddH7qGxJjbT s6CD9Y8/2iga/VlxRkoytxYdl6jU4qeToGOhlASWw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelledgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrjedtrdejuddrud dtleenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az59-708.internal.cloudapp.net (unknown [40.70.71.109]) by mail.messagingengine.com (Postfix) with ESMTPA id 5988F1080057 for ; Sun, 20 Dec 2020 02:40:36 -0500 (EST) Content-Type: multipart/alternative; boundary="===============1240572203506128198==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20201220074036.5988F1080057@mailuser.nyi.internal> Date: Sun, 20 Dec 2020 02:40:36 -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, 20 Dec 2020 07:55:58 -0000 --===============1240572203506128198== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+2/-0/=F0=9F=92=AC0) 2 issues created: - Pin HPKE version (by chris-wood) https://github.com/mlswg/mls-protocol/issues/448=20 - Motivate Ratchet Trees (by yaronf) https://github.com/mlswg/mls-protocol/issues/447=20 Pull requests ------------- * mlswg/mls-protocol (+2/-3/=F0=9F=92=AC3) 2 pull requests submitted: - Editorial changes (by uhoreg) https://github.com/mlswg/mls-protocol/pull/450=20 - Pin HPKE to -07. (by chris-wood) https://github.com/mlswg/mls-protocol/pull/449=20 1 pull requests received 3 new comments: - #449 Pin HPKE to -07. (3 by beurdouche, bifurcation, chris-wood) https://github.com/mlswg/mls-protocol/pull/449=20 3 pull requests merged: - Editorial changes https://github.com/mlswg/mls-protocol/pull/450=20 - Pin HPKE to -07. https://github.com/mlswg/mls-protocol/pull/449=20 - Add an "AppAck" proposal https://github.com/mlswg/mls-protocol/pull/442=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============1240572203506128198== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday December 20, 2020

Issues

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

2 issues created:

Pull requests

mlswg/mls-protocol (+2/-3/=F0=9F=92=AC3)

2 pull requests submitted:

1 pull requests received 3 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============1240572203506128198==-- From nobody Tue Dec 22 07:21:47 2020 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 9B0D63A1103; Tue, 22 Dec 2020 07:21:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <160865050558.14324.4946631946140813118@ietfa.amsl.com> Date: Tue, 22 Dec 2020 07:21:45 -0800 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-11.txt 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: Tue, 22 Dec 2020 15:21:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Benjamin Beurdouche Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-11.txt Pages : 88 Date : 2020-12-22 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-protocol-11 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Dec 26 23:56:04 2020 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 DF8A33A048B for ; Sat, 26 Dec 2020 23:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SMWQX3Oy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PXcpqE7M 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 BKGQe3EKGT01 for ; Sat, 26 Dec 2020 23:56:01 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202483A0596 for ; Sat, 26 Dec 2020 23:56:01 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 96054788 for ; Sun, 27 Dec 2020 02:49:39 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 27 Dec 2020 02:49:39 -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=h6DfAgdb67SF2brcESLt4W6BG7UWbENW6TQvk8KZBWo=; b=SMWQX3Oy 4NnjFiYSQoinmwj9CrLL/v7AoEKDU5coLKwPuUbqiO0l1KRd991Ob2wxKFmma00P MxWebUzjSgMMZsit8LqkNdxUWfzhEMf8gNv3QmSxl+TjR0yZubb6KVZEADlhdPlk HdhS3SfbLNHJKLS1lExBrT7ou8xouksqcjGz3s9CnWzeYVUnSN1mV1ci/AhYi5RD UnYgCZMMqSsjBKdL7EnrciW4c66BQ3w7TAXhEWbFa41gBoBzPvTWrtX3y84H2xpc 6lkEJGlvvVDjvM8D8Oi8C4RLxefNYfPMiIXABAbe2piAQpRSNKJ5PxUmVhGgp+z/ TK2OynPziyiiBQ== 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=h6DfAgdb67SF2brcESLt4W6BG7UWb ENW6TQvk8KZBWo=; b=PXcpqE7MtITSdg7vlEGXz/LqXRxvBVP64gds+5kW5j5vT j9XJXF/TDRT2DDoOSiODABUOR5nj83eY4aCvc3SeqhTiN9joBfKSkXsIw2G1Fx9B R2L0Tyc/Y0a+ovYM+ysITAJP+ExlWvF7e/hVMNecdcImFn20wpX6KsNicGjXvKZp tGLfZocTDBtLUpkJ2Q9KNkvAV8SKjggVKo6YRZ1EykTFcyG5t+/WLcPgWKCJ2z/s c9SjrUhunlpTJ8zC1KGoGW+rSp+H5myPtcfuK5D/YhaER4MHieShx5tsW14QMnmG M8qT2Mkp8YOj73aZvOVQPvZt5Uqzp5zrLIU/lx0oQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdduiedguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvtdehrd dvfeefnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-573.internal.cloudapp.net (unknown [40.65.205.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 1749924005B for ; Sun, 27 Dec 2020 02:49:39 -0500 (EST) Content-Type: multipart/alternative; boundary="===============5556875377647956775==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20201227074939.1749924005B@mailuser.nyi.internal> Date: Sun, 27 Dec 2020 02:49:39 -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, 27 Dec 2020 07:56:03 -0000 --===============5556875377647956775== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #448 Pin HPKE version (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/448 [editorial] [interoper= ability]=20 1 issues closed: - Pin HPKE version https://github.com/mlswg/mls-protocol/issues/448 [edit= orial] [interoperability]=20 Pull requests ------------- * mlswg/mls-protocol (+2/-3/=F0=9F=92=AC0) 2 pull requests submitted: - Add changelog for draft-11 (by bifurcation) https://github.com/mlswg/mls-protocol/pull/452=20 - Remove contradictory initialization of transcript hashes (by bifurcatio= n) https://github.com/mlswg/mls-protocol/pull/451=20 3 pull requests merged: - Add changelog for draft-11 https://github.com/mlswg/mls-protocol/pull/452=20 - Remove contradictory initialization of transcript hashes https://github.com/mlswg/mls-protocol/pull/451=20 - Strong tree signing https://github.com/mlswg/mls-protocol/pull/436=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============5556875377647956775== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday December 27, 2020

Issues

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

1 issues received 1 new comments:

1 issues closed:

Pull requests

mlswg/mls-protocol (+2/-3/=F0=9F=92=AC0)

2 pull requests submitted:

3 pull requests merged:

Repositories tracked by this digest:

--===============5556875377647956775==-- From nobody Thu Dec 31 03:47:35 2020 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 9EF1E3A0936 for ; Thu, 31 Dec 2020 03:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 mf14eul8eH8L for ; Thu, 31 Dec 2020 03:47:33 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 BAFF03A08BB for ; Thu, 31 Dec 2020 03:47:32 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id r5so17950320eda.12 for ; Thu, 31 Dec 2020 03:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YRD2BVYmKzIVpdtjdOsKcyUuk/l9ugtQ7FiBDEysaqo=; b=ngH4wIRdjdFCm0FhRY5KRAG+enaqLboNNOg3HXXGXqlMSbusGsSSsRELCMQaHmWSr1 s3Ryybl3cnczYKZT/X7/HrcCyRYulKw7fnoHFxoWGkx1hAdD57NAwSxYFHnoNgIWB0rY 4hfyi7R+7xSslI1DesGgfaaRFZeRT95PlYBRmlOezx5IfeDDjIcQV5KdZutR366m/aiy 151EPAepNcyw4hZoQC9G1nB5fvMrHJSqH6QCrtYifMQo6p4IdvOLPbVqMjh0OrgZnKA4 yeesCt9TO/O1nD069+VJF4vFhyQwVTR6DFru3XEL+wXIiIppS/9nADRWIt/Ju7k1njNg ALzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YRD2BVYmKzIVpdtjdOsKcyUuk/l9ugtQ7FiBDEysaqo=; b=ioVTAUwhu8Nxf5CWUArfQWdUqdZmAol+mBiVYOl5GbTI61ygjZl0Jk5TlfOeIZg0so fuot3ZjI8pEivuunwQg5SeEqYFMW20MI5qSMXQaSo2TMIu5e4hiu1oy+T2txNy0vnphI d+WxTKnRUk+Zk/qEDxJMuU3tZLM09Ej7M1Dan0k7xv7IynIgLBXw79r1PAcAlLP/GYzl RZArHAjfnl4T6CnZ8cJwIZJl7j84FfkzJYiaY+eIQ/O7O4rcZRMlk+KjXVCZQsszAJDi 9ll0X6hsvFm47spYKt2MXl5UxW6vPthpSxXY9HQBlAPiepCXg4A4qkOCcq4MivHO8txx U9rA== X-Gm-Message-State: AOAM531hA+8cKjKDlybWJi0ugLlwAPVbt2LARS7Mtf1AAh+zkaPeN1Sm ceuq5gmyALN9LglBczbU2vrKaJi68fBvXomw X-Google-Smtp-Source: ABdhPJysRn0zTxGH/0Jb19RfaUtF2pMQRf4PIW47hbeCnY6LcbM7QwIOrFUBJQfN8+25wa/crLoH4w== X-Received: by 2002:a50:cd8c:: with SMTP id p12mr53922803edi.380.1609415250675; Thu, 31 Dec 2020 03:47:30 -0800 (PST) Received: from rmbp.fritz.box ([37.209.98.242]) by smtp.gmail.com with ESMTPSA id rh2sm20003916ejb.68.2020.12.31.03.47.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Dec 2020 03:47:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Raphael Robert In-Reply-To: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> Date: Thu, 31 Dec 2020 12:47:28 +0100 Cc: Joel Alwen Content-Transfer-Encoding: quoted-printable Message-Id: <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> To: Messaging Layer Security WG 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: Thu, 31 Dec 2020 11:47:35 -0000 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.=20 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 { 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 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 From nobody Thu Dec 31 07:02:55 2020 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 7DA903A0CE2 for ; Thu, 31 Dec 2020 07:02:53 -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, HTML_MESSAGE=0.001, 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 aucFIP1UKE_2 for ; Thu, 31 Dec 2020 07:02:51 -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 E042E3A0CE1 for ; Thu, 31 Dec 2020 07:02:49 -0800 (PST) Received: from mailm216.d.ethz.ch (2001:67c:10ec:5603::30) 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; Thu, 31 Dec 2020 16:02:30 +0100 Received: from mailm213.d.ethz.ch (2001:67c:10ec:5603::27) by mailm216.d.ethz.ch (2001:67c:10ec:5603::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 31 Dec 2020 16:02:45 +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; Thu, 31 Dec 2020 16:02:45 +0100 From: "Mularczyk Marta" To: Raphael Robert CC: Joel Alwen , "daniel.jost@cs.nyu.edu" , Messaging Layer Security WG Thread-Topic: [MLS] New Parent Hash Thread-Index: AQHWuTjfZw1SmrLREUKS4j4Eh1hSAKoRUjgAgABCrXI= Date: Thu, 31 Dec 2020 15:02:45 +0000 Message-ID: References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com>, <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> In-Reply-To: <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.4.222.248] x-tm-snts-smtp: C60E91BC9CFCC6224A16B98FECA3BE6C403D60E3369B354E1DDEC68DB1669D8B2000:8 Content-Type: multipart/alternative; boundary="_000_cc448694ee224c4786a05281b38c8cbdinfethzch_" 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: Thu, 31 Dec 2020 15:02:54 -0000 --_000_cc448694ee224c4786a05281b38c8cbdinfethzch_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Raphael, There indeed seems to be a misunderstanding about how "resolution" is defin= ed. In the version of the draft I see, in 5.2 the resolution is defined as = "an ordered list of non-blank nodes that collectively cover all non-blank d= escendants of the node" and not just the first one. Also, 5.2 says that the= resolution of node 5 is the list [CD,C] and not [CD]. Can you point to the= version of the draft you're referring to? Best, Marta ________________________________ From: MLS on behalf of Raphael Robert Sent: Thursday, December 31, 2020 12:47:28 PM To: Messaging Layer Security WG Cc: Joel Alwen Subject: Re: [MLS] New Parent Hash 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 l= eaf nodes still goes undetected. I think it is due to a terminology conflict, but it would be great if you c= ould 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 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. I= n 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 additi= onally 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 li= ke (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 illust= rate. In other words, the new =93original child resolution=94 of S would be the s= ubtree 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 ver= sion of > strong parent hash to prevent the attacks from the earlier thread. We tri= ed to > make it as minimal as we could to help with deniability while still preve= nting > the attacks permitted by weak parent hashes. > > In a nutshell, when computing parent_hash at node v with parent p and sib= ling 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 leav= es > unmerged at p. > > As a sanity check, notice that as long as p's keys remain the same one ca= n > always recompute the same parent_hash value at v as was initially compute= d by > the member that set p's keys. (In other words, new members can verify tha= t 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 except= ion are > leaves being added as unmerged at w. But those leaves are also added as u= nmerged > 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 --_000_cc448694ee224c4786a05281b38c8cbdinfethzch_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Raphael,


There indeed seems to be a misunderstanding about how "resolution&q= uot; is defined. In the version of the draft I see, in 5.2 the resolution i= s defined as "an ordered list of non-blank nodes that collective= ly cover all non-blank descendants of the node" and not just the first one. Also, 5.2 says that the resolution of node 5 i= s the list [CD,C] and not [CD]. Can you point to the version of the dr= aft you're referring to?


Best,

Marta


From: MLS <mls-bounces= @ietf.org> on behalf of Raphael Robert <raphael=3D40wire.com@dmarc.ie= tf.org>
Sent: Thursday, December 31, 2020 12:47:28 PM
To: Messaging Layer Security WG
Cc: Joel Alwen
Subject: Re: [MLS] New Parent Hash
 
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 l= eaf nodes still goes undetected.

I think it is due to a terminology conflict, but it would be great if you c= ould 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. I= n 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 a= dditionally 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 li= ke (sorry that it=92s Rust, not Python):

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

There=92s a more efficient implementation of course, this is just to illust= rate.

In other words, the new =93original child resolution=94 of S would be the s= ubtree 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> wrote:<= br> >
> 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 pr= eventing
> 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 l= eaves
> 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 comp= uted 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, tha= t's coz as
> long as p's keys are unchanged so is the resolution of w. The only exc= eption are
> leaves being added as unmerged at w. But those leaves are also added a= s unmerged
> at p so they are left out of the hash.
>
> As for deniability, at least parent_hash only binds HPKE keys and noth= ing else
> (like, say, credentials or signatures). Its the best we were able to c= ome 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
--_000_cc448694ee224c4786a05281b38c8cbdinfethzch_-- From nobody Thu Dec 31 07:44:36 2020 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 1BC513A0D43 for ; Thu, 31 Dec 2020 07:44:35 -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 Cfj1r9skBSv3 for ; Thu, 31 Dec 2020 07:44:32 -0800 (PST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 327D13A0D44 for ; Thu, 31 Dec 2020 07:44:32 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id g20so25792563ejb.1 for ; Thu, 31 Dec 2020 07:44:32 -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=eHlRmvQ+LH5KHEad9qDO2/ETQhtYnumEqPtpsflVvww=; b=v77FiDxD7hrtRHrd6yXMAnnmPEfzHywXB0RCMkvwUBdy3xJxUeGWVo3cYoLFuGMNHR E8Ruz+HmdtTzB9hH3gsMJttOFmgrIWFHmkHSKD6R7ZxYA3fBs9KevLQ8s57ktV4nwohj oip0EVBzLFvJdPKN2akkasxZ/vzJXPwkZ/YaLLm1PEAToZatzXpgUsdBz8w75IaRZWxR yV5PxZKbBcFHLcgFECYr452JrDgbk3Nt3tAc9779lgpoweBwGzPA/D0zY66WfidJ0XZ7 I/bMViqC+s4XIYyyrhBLbsVVls2afCWvJacjM49sYelr/QtRWKje8Vd365U3A5BWA8Cd xCrw== 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=eHlRmvQ+LH5KHEad9qDO2/ETQhtYnumEqPtpsflVvww=; b=VIPekacRAnW29wMpjpTrNu7PDMjp6dnvaBDsJFVmTk6MkuPctXNi/pb5THK2kS7Fyc eP+EVzR52axDnK87mrzMartemhQuBQ3u398XemZ1qSibt4JMURY4U3mxh9tx7GCoaNtO BTKDGc3m6hLuvwwDws6Q9Ksy9IKA9g1tcKE4UTQRrmbgLyxH8fizyAYtSVupMu4OOhFV x6B7ttSAHubon3p1bRKZF3PUM81EmDyikJ+7xKevm2cdTJzWcWvuT6jrYm6ANz3p2DZr ueTNdYcLvsac82R0GWqnJkOIkBDpffW+tHGNzNSg7MbguuJZ8QQYw49wfRe5fk4eqPO5 3Dgw== X-Gm-Message-State: AOAM533WWlyR9eKSdXrKun/y7bgnmgjB+Mcho4weTS8OEA/fmAt80XYx vK4MlqoMBCiyrDCYS1LQZD1NEg== X-Google-Smtp-Source: ABdhPJyAMD8/l1CQJrgnH9tFMMfb4DYXL3H0R6yWwcnkUhZfBrhzsRPLa6XtWySbHnDsJL1mwfeaWg== X-Received: by 2002:a17:907:118e:: with SMTP id uz14mr52657809ejb.83.1609429470415; Thu, 31 Dec 2020 07:44:30 -0800 (PST) Received: from rmbp.fritz.box ([37.209.98.242]) by smtp.gmail.com with ESMTPSA id t15sm15917611eds.38.2020.12.31.07.44.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Dec 2020 07:44:29 -0800 (PST) From: Raphael Robert Message-Id: <8C376F0C-5105-40FD-9CFC-F5B18D4E53BC@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1DAB79FC-C5CC-42CF-AD4E-06AB9B197CE6" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Thu, 31 Dec 2020 16:44:27 +0100 In-Reply-To: Cc: Joel Alwen , "daniel.jost@cs.nyu.edu" , Messaging Layer Security WG To: Mularczyk Marta References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.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: Thu, 31 Dec 2020 15:44:35 -0000 --Apple-Mail=_1DAB79FC-C5CC-42CF-AD4E-06AB9B197CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Marta, I am talking about draft-11 (which is the only one that contains the new = strong parent hash scheme). Looking at it again, I agree that that particular sentence is indeed a = bit ambiguous. =E2=80=9CDescendants=E2=80=9D are direct descendants in = that case (or non-blank children of blank nodes). We should change that = confusing wording. However the part that follows is correct I think: =E2=80=A2 The resolution of a non-blank node comprises the node = itself, followed by its list of unmerged leaves, if any =E2=80=A2 The resolution of a blank leaf node is the empty list =E2=80=A2 The resolution of a blank intermediate node is the = result of concatenating the resolution of its left child with the = resolution of its right child, in that order If you apply these three rules recursively, you only get a list of = certain non-blank nodes in the subtree, not the whole subtree. In the = extreme case that the subtree does not have any blank nodes, you only = get the head of the subtree and its unmerged leaves (if any). As for the example, you are right that the resolution includes unmerged = leaves (I forgot about that because it was only added later), so the = resolution of node 5 is indeed [CD, C].=20 That being said, I still think the =E2=80=9Coriginal child resolution=E2=80= =9D of S should cover all non-blank nodes in the subtree of S that are = not in the unmerged leaves list of S. As mentioned before, in the = example from above that would be [CD, D] (C is removed because it is in = the unmerged leaves list). To avoid any confusion with the current resolution, I would propose the = following naming and definition: "Finally, child_subtree_nodes is the array of HPKEPublicKey values of = the nodes in the subtree under S but with the unmerged_leaves of P = omitted. The nodes in the subtree under S are all non-blank nodes of = that subtree including S itself, if S is not a blank node. The nodes in = the list are ordered by their indexes.=E2=80=9D Would that work? Thanks Raphael > On 31. Dec 2020, at 16:02, Mularczyk Marta = wrote: >=20 > Hi Raphael, >=20 > There indeed seems to be a misunderstanding about how "resolution" is = defined. In the version of the draft I see, in 5.2 the resolution is = defined as "an ordered list of non-blank nodes that collectively cover = all non-blank descendants of the node" and not just the first one. Also, = 5.2 says that the resolution of node 5 is the list [CD,C] and not [CD]. = Can you point to the version of the draft you're referring to? >=20 > Best, > Marta >=20 > From: MLS on behalf of Raphael Robert = > Sent: Thursday, December 31, 2020 12:47:28 PM > To: Messaging Layer Security WG > Cc: Joel Alwen > Subject: Re: [MLS] New Parent Hash > =20 > 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.=20 > 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 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 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 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 = --Apple-Mail=_1DAB79FC-C5CC-42CF-AD4E-06AB9B197CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Marta,

I am talking about draft-11 (which is the only one that = contains the new strong parent hash scheme).

Looking at it again, I agree that that particular = sentence is indeed a bit ambiguous. =E2=80=9CDescendants=E2=80=9D are = direct descendants in that case (or non-blank children of blank nodes). = We should change that confusing wording. However the part that follows = is correct I think:

=E2=80=A2 The resolution of a = non-blank node comprises the node itself, followed by its list of = unmerged leaves, if any
=E2=80=A2 = The resolution of a blank leaf node is the empty list
=E2=80=A2 The resolution of a = blank intermediate node is the result of concatenating the resolution of = its left child with the resolution of its right child, in that = order

If you = apply these three rules recursively, you only get a list of certain = non-blank nodes in the subtree, not the whole subtree. In the extreme = case that the subtree does not have any blank nodes, you only get the = head of the subtree and its unmerged leaves (if any).

As for the example, you = are right that the resolution includes unmerged leaves (I forgot about = that because it was only added later), so the resolution of node 5 is = indeed [CD, C]. 

That being said, I still think the =E2=80=9Coriginal child = resolution=E2=80=9D of S should cover all non-blank nodes in the subtree = of S that are not in the unmerged leaves list of S. As mentioned before, = in the example from above that would be [CD, D] (C is removed because it = is in the unmerged leaves list).

To avoid any confusion with the current = resolution, I would propose the following naming and = definition:

"Finally, child_subtree_nodes is the array = of HPKEPublicKey values of the nodes in the subtree under S = but with the unmerged_leaves of P omitted. The nodes in = the subtree under S are all non-blank nodes of that subtree including S = itself, if S is not a blank node. The nodes in the list are ordered by = their indexes.=E2=80=9D

Would that work?

Thanks

Raphael



On 31. Dec 2020, at 16:02, = Mularczyk Marta <marta.mularczyk@inf.ethz.ch> wrote:

Hi Raphael,

There indeed = seems to be a misunderstanding about how "resolution" is defined. In the = version of the draft I see, in 5.2 the resolution is defined as "an ordered list of non-blank nodes that collectively cover = all non-blank descendants of the node" and not just the first = one. Also, 5.2 says that the resolution of node 5 is the list [CD,C] and = not [CD]. Can you point to the version of the draft you're = referring to?

Best,
Marta

From: MLS= <mls-bounces@ietf.org> on behalf of Raphael Robert = <raphael=3D40wire.com@dmarc.ietf.org>
Sent: Thursday, December 31, 2020 = 12:47:28 PM
To: Messaging Layer Security = WG
Cc: Joel Alwen
Subject: Re: [MLS] New Parent = Hash
 
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);
        [
          &nb= sp; descendants(left_child, size),
          &nb= sp; vec![x],
          &nb= sp; 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=99= 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 = <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

= --Apple-Mail=_1DAB79FC-C5CC-42CF-AD4E-06AB9B197CE6-- From nobody Thu Dec 31 08:37:20 2020 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 AF6713A0D9C for ; Thu, 31 Dec 2020 08:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=matrix.org header.b=R50H8sQT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jdbLH+gY 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 kpYL1FBcNrSL for ; Thu, 31 Dec 2020 08:37:16 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10583A0D9B for ; Thu, 31 Dec 2020 08:37:16 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 370141710 for ; Thu, 31 Dec 2020 11:37:16 -0500 (EST) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 11:37:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matrix.org; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=5xjME xa/AGnyZSyVmxDfcjaG+kdIGQgmzYJhX+wcCuA=; b=R50H8sQTWqZdIgAdTy3Rq 2DDsat4/wurbeSnE5fkEjTRo3whvVfpAv5wi0aN3zVcrE5AvOJ6MwacoEfpVorCY zJSqAjoEZX3w7IXyNhfHt4hN/q+DR50jvrkcBnBfbeUm6262Z2w44kXmzMK1A8gF BzjKHsRq3a2KxB9z1MXx+OPHEgstVZBkNV7CnswA+UTXE0CAkMN+6P4+W6tK10oN lu1xSwXvaoWcRRo/7C0MZe5pGf8ni06kgmHlynEOcCMWevtxujn47ynU2HtU5lfq 6o2P10EeB1pznw3FIpOpCRugxzmWOt4LkLapBRX4O6UVq2RxevuW5Y7Asj4IzdB/ Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=5xjMExa/AGnyZSyVmxDfcjaG+kdIGQgmzYJhX+wcC uA=; b=jdbLH+gY5zZyoL04zKK2Us1lIChmos9i9FlRlfOcXvtXsc0cf31VPzPdz p1gJWjIFEnqlIZpZJA/5AWmXW19FrH4E1G0xg1R4/VrzxWMV1zHfZBmD5AODyHnb TQ+015cHEwcgMsgbPrDNdUDGsdpMLUrKswHky8XIoKT/B+qfkYx+YP7c0MFll2WR iDEhWqV5NpMzcfISnPT0OHdHszxjKngNKtXzOFJx8ou+nBmp83ftTq6dnd0wQbGu +wCwllJ7t6kKr8il08fmiUiqKkiajzDw6ZTyY63wcHVQ2tIowe1/1SxQJs5DokxB AkKk1HQfO+bi3AtVsptnnDS/LYYDg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdfjuhgsvghrthcuvehhrghthhhifdcuoehhuhgsvghr thgtsehmrghtrhhigidrohhrgheqnecuggftrfgrthhtvghrnhepfffgveeiueefffeuke eugffgledvuefgvdeikeelvdekhfefleettdejteeuleffnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehhuhgsvghrthgtsehmrghtrhhigidrohhrgh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B6C3D62A005E; Thu, 31 Dec 2020 11:36:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: In-Reply-To: <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> References: <68acccb2-9e5f-f52d-b32c-3b6e3195bc2d@wickr.com> <7A25FA3A-25E9-47AD-9D8F-112F24748062@wire.com> Date: Thu, 31 Dec 2020 11:36:53 -0500 From: "Hubert Chathi" To: mls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 31 Dec 2020 16:37:19 -0000 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 t= he desired security. 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 doe= s=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 funct= ion 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 jus= t 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 ne= w version of > > strong parent hash to prevent the attacks from the earlier thread. W= e 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 an= d 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 o= ne can > > always recompute the same parent_hash value at v as was initially co= mputed by > > the member that set p's keys. (In other words, new members can verif= y that the > > stored parent_hash values match whats in the tree.) In particular, t= hat's coz as > > long as p's keys are unchanged so is the resolution of w. The only e= xception 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 no= thing 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 >