From nobody Mon Oct 1 09:17:53 2018 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 DF2B0130E05 for ; Mon, 1 Oct 2018 09:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHwRY9wfIobK for ; Mon, 1 Oct 2018 09:17:50 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 EFEC3130DFE for ; Mon, 1 Oct 2018 09:17:49 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id k64-v6so11651526oia.13 for ; Mon, 01 Oct 2018 09:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=kK1OjND5bbm0q4VVANVJg5GJCtH9jw2hcDf5lKvyUwo=; b=Cn1rsbdwYonlmvfMxFL36EXuoCOdx1DiahlUv+6U2GuD6BBP64vwOI8TPcwn5QduSE Pb6k1vJIjWdTj8D4GB90McxpgSb7yM5a52jeAo+LWZzrsf4TPk8q/6tpYgpHp30+AeSX kla4R0uLktElieV38MzW/OSg1QRl0ZIFPAj0FogFgrd5YojQTcwXSaXd0XoH6OpdIiLh VSGeJs7yC5u5Cmu2lO3C5cACHsMK9Hs1OHblTCs2sSUG267o3t0410+txGPw/BkrlUhG p04VohehJKxwwgedaqjgtgy1lmD6Lnk+zbDs0g7w90tb6PAUuHW7KzAS+xeA3hn/C2X2 Gj2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kK1OjND5bbm0q4VVANVJg5GJCtH9jw2hcDf5lKvyUwo=; b=FEAW2033Uwu1iCqnzRcZUjZwmMm8ZzaqFBXLqbJzB3k2ipUWTCT8WKEdeEvm/JdeRK dkgASaNURIVtcgY4wboDqT0yBNoWjop+6IFgcIptKoDel4nt+jge5V9ws4Gasm/Ffhlh siR+16Vn0PNkI8BGPxSrXSx/s9vwRq7KHb1gumB3k2EqC376lJ8b1YJ+R8Era5N/ti1L npGhSdtY3/WqsCN8CCD9XHS/IuPs3pLe0MsAdMT3I42U/XYDnkBlP+PCFl4iFmdfJF7M oI8zq/nBpL8ycCOZUXDMpkVKWxWMUtkuFVDgvVAx7mJjaDEZWT5sxDDgKC7Z0KW3x3+H 17jw== X-Gm-Message-State: ABuFfoj1IlXiitAzYU61zJPwy9nzyD47pHuyaQOf9s7yj059d889MEEJ gZrDJhCmG5GwPCErBHjPIZOD+6oIb6WILlAzfg0puZUrQ7j7LQ== X-Google-Smtp-Source: ACcGV61E7xdn5whyRJfnZnfk4+hZ8XemQgBWp+Nf3fYIU7Xf/5fVLtoCoWQwXP+kcMTWM0R808KfjjKxMEHPGZfmDgA= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr5728276oib.155.1538410668830; Mon, 01 Oct 2018 09:17:48 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 1 Oct 2018 18:17:31 +0200 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000006f474405772d25ee" Archived-At: Subject: [MLS] Cost of the partial-tree approach 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, 01 Oct 2018 16:17:52 -0000 --0000000000006f474405772d25ee Content-Type: text/plain; charset="UTF-8" Hey all, There was some debate at the interim about the performance implications of the "partial-tree" approach to adds and removes [0] (derived from the "remove-without-double-join" approach described on the mailing list [1]). In particular, EKR expressed concern that this approach would cause message size to degrade from log to linear. To test this out, on the plane home I wrote a simulator that performs random group operations and compares two approaches: 1. The "full-tree" approach, which has optimal efficiency but also has double-joins 2. The "partial-tree" approach, which has no double-joins but sub-optimal efficiency I've made a little visualizer here: https://ipv.sx/treekem/blanking/ The tl;dr is that the partial-tree approach is only very bad if you have a very sparse tree, in particular, if you follow the "Init w/o 2J" approach of [0]. In all other cases, as long as updates happen sufficiently frequently, the two approaches are within a small constant factor of one another. The intuition here is that adds / removes degrade the tree (since they add blank nodes) while updates heal the tree (since they fill in blank nodes). If you have the simulator start out with a sparse tree (untick "Start full"), you'll see that initially, the "partial-tree" approach is very bad, pretty much linear, but it gets better as nodes update, and eventually merges with the "full-tree" line. If you start with a full tree, the lines don't diverge. Obviously, this isn't dispositive in one direction or another. But ISTM that this experiment indicates that the cost of the "partial-tree" approach might not be too bad, given that it clears up a significant ambiguity / saves the cost of double-join bookkeeping. --Richard [0] https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/no_more_double_joins.pdf [1] https://mailarchive.ietf.org/arch/msg/mls/Zzw2tqZC1FCbVZA9LKERsMIQXik --0000000000006f474405772d25ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

There was some debate at = the interim about the performance implications of the "partial-tree&qu= ot; approach to adds and removes [0] (derived from the "remove-without= -double-join" approach described on the mailing list [1]).=C2=A0 In pa= rticular, EKR expressed concern that this approach would cause message size= to degrade from log to linear.=C2=A0 To test this out, on the plane home I= wrote a simulator that performs random group operations and compares two a= pproaches:

1. The "full-tree" approach, which has optimal = efficiency but also has double-joins
2. The "partial-tree" app= roach, which has no double-joins but sub-optimal efficiency

I've= made a little visualizer here:

https://ipv.sx/treekem/blanking/

The tl;dr is that the = partial-tree approach is only very bad if you have a very sparse tree, in p= articular, if you follow the "Init w/o 2J" approach of [0].=C2=A0= In all other cases, as long as updates happen sufficiently frequently, the= two approaches are within a small constant factor of one another.=C2=A0 Th= e intuition here is that adds / removes degrade the tree (since they add bl= ank nodes) while updates heal the tree (since they fill in blank nodes).=C2= =A0

If you have the simulator start out with a sparse tree (untick = "Start full"), you'll see that initially, the "partial-t= ree" approach is very bad, pretty much linear, but it gets better as n= odes update, and eventually merges with the "full-tree" line.=C2= =A0 If you start with a full tree, the lines don't diverge.

Obvi= ously, this isn't dispositive in one direction or another.=C2=A0 But IS= TM that this experiment indicates that the cost of the "partial-tree&q= uot; approach might not be too bad, given that it clears up a significant a= mbiguity / saves the cost of double-join bookkeeping.

--Richard
<= br>[0] https://github.com/mlswg/wg-materials/bl= ob/master/interim-2018-09/no_more_double_joins.pdf
[1] https:= //mailarchive.ietf.org/arch/msg/mls/Zzw2tqZC1FCbVZA9LKERsMIQXik

=
--0000000000006f474405772d25ee-- From nobody Mon Oct 1 11:06:47 2018 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 136FA1252B7 for ; Mon, 1 Oct 2018 11:06:46 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OUQogdgxnyu for ; Mon, 1 Oct 2018 11:06:44 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 5ADDD1277CC for ; Mon, 1 Oct 2018 11:06:44 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id q4-v6so14019565otf.13 for ; Mon, 01 Oct 2018 11:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=avsAiR49UibfGMyEtZL36v11DuPYnmdNcEhK+u/NVTY=; b=c6Fz6ODYw/+JdnFf81VNjcTY9bHbmfO+w7JBRFPONQX94MDJRETCkmeWzV5AqP88US s7PGLUP6NT39KQYJS/NKD4O+p5hkKUiPr4M4TObFV/7lUxp0C4NDNEW0NwFG/1A62tyV YIpLrAQ1jxUbjvCAryw8qE8T4zLxEweuTpDmqDfWxMHoieY9rfIWInMh9LMQhVNKJgqv pqP6SwEC9/zNV5WxCik6ZbbMW32tz8zpkHD85PQN1q3aOMmCZLdRdclY5hMP08MfPgwG VAGpGjwsPKuKZB0UHgLEfN7y62Hkb7Zx5tCuIpBgqvQKMQuFSDn/XSrsIaElx95wpcuC HGyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=avsAiR49UibfGMyEtZL36v11DuPYnmdNcEhK+u/NVTY=; b=MJRMZGe8vRzaFJEF4PeH7ZyxtaSx5JZlrp4v8l0t5WsxpDJv5NXlqpMIemrG3sDwGe 0mQ+assjYc3Y5hTfS2GKMtySSkplu3xTzQwaN8CZbHawkVluXqW9URyJK+/YXpZlANoE FWplhzJqQT45LZr2ZYnA+9n+QBnQmmzHKLNUm+UvXgcdbVIEwvPEuc7vH3S3z+y6BN1+ qQUoYt34R9FaGtxXeEPXCO++PTufVppR7fO456DcH0fmVbtzTBuNTwwaimeBQI6vruLO unj5sHX9QmN7dG8DM6ePpwQqmNfubJlEj/32v0OJm2SVHXGq8OLTeRfgyqsS7qLr2Ix8 oweg== X-Gm-Message-State: ABuFfoidBVWRNxYrnRVmWesGpyZY4ZzC/8VLANBIgZW3zYZf3tpVV8I6 aXBvMQVNITpzdztF/p08KHzB38428EGceatti8rI3YeVarahuw== X-Google-Smtp-Source: ACcGV62r3sbrUHwN5CGQd5SKPxbP9PNp+jzstmCQfvuHT1op0PaIZLsrwpWNKUVpvfkPeUd6fkvAbqJMrRT01hhDmBo= X-Received: by 2002:a9d:2377:: with SMTP id k52mr3436457otd.238.1538417203361; Mon, 01 Oct 2018 11:06:43 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 1 Oct 2018 20:06:26 +0200 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000ec511f05772eaa91" Archived-At: Subject: [MLS] Removing ART; maybe adding partial-tree 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, 01 Oct 2018 18:06:46 -0000 --000000000000ec511f05772eaa91 Content-Type: text/plain; charset="UTF-8" Hey all, At the interim last week, there was agreement to remove the discussion of ART from the protocol draft and focus on TreeKEM. I have implemented that change in the following pull request: https://github.com/mlswg/mls-protocol/pull/66 If a couple of folks could give a quick review, it would be appreciated. I also put together a PR describing how to do the "partial tree" approach described at the interim and in my earlier message today. https://github.com/mlswg/mls-protocol/pull/67 Feedback welcome! Thanks, --Richard --000000000000ec511f05772eaa91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,
=
At the interim last week, there was agreement to remove the = discussion of ART from the protocol draft and focus on TreeKEM.=C2=A0 I hav= e implemented that change in the following pull request:


If a coupl= e of folks could give a quick review, it would be appreciated.=C2=A0 I also= put together a PR describing how to do the "partial tree" approa= ch described at the interim and in my earlier message today.
=

Fe= edback welcome!

Thanks,
--Richar= d
--000000000000ec511f05772eaa91-- From nobody Mon Oct 1 13:34:17 2018 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 BF8BE130F19 for ; Mon, 1 Oct 2018 13:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 5zd9cEeiiWpS for ; Mon, 1 Oct 2018 13:34:07 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 4F9DB130EF2 for ; Mon, 1 Oct 2018 13:34:07 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id f8-v6so13515079ljk.1 for ; Mon, 01 Oct 2018 13:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F/B8BzTlQ6y/R+ace/1S3mZkQXtIDgx7zavl0TAlud0=; b=K6s6UjEFccoOMJIE8zsyD17dzQYyR5gNxMhC+Z3RNIy/N4oSPT8x/+Vwsc4/V4+ZbX HYO2S3KTjEojp2a7yM1VRfmP6Fp8gnDnRUxa4CrMZDNA8RoG8Hjxt5REPbTNZ8mIKGIO gNbjeQUv47UH2eV8kfczsAsSgbqgPLfKFCsMQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F/B8BzTlQ6y/R+ace/1S3mZkQXtIDgx7zavl0TAlud0=; b=WQwe0KnJscb8nzme2izfrpgeOUivUZkXwwrelsz/9eeqGQ8YMK9SHWz38AQkcZH6tW 6yOA1Zqmsz+ZdUw7rutd6qGEt2QHMROGrY5ovBok590dh6GeObzjlLqGBAeIbvnINKzk WSwREG5ZUAtnF4fn/rlMAu13fYS517AIuWWrzBjpHHrEMKE+YmOJqnvQRlq1s7ynVzCt DHKMAA3Jt7WrD9f52TIRLlGPuqyMzmrl1TgQyZ8iLo2TPr1ErQsQjIQ+LK6s/xkdNh6K iQL/EfIhcgLLhJSeWkw/LXf2sAANR6xK/6bN03aZkW1ICQPVgBdXeZkmq3KWgvQl5bd+ ga6w== X-Gm-Message-State: ABuFfohQ31n9lmy/xmUvkdgyrNsHljRbUHFrmYpKSNjoHrebUe24JkbW u4zibekO6dZGQrv8dVg9LquRkrGVjFbf2vcaqwbdaflr7F0lXA== X-Google-Smtp-Source: ACcGV60kepetjctkAA0omcu/7nDISYCWnHQ2VXgPttoMpjK2WU9Sf4ZtN3zgNeVeUeJr0GzxMpLTJC9rPmRLO7KcB08= X-Received: by 2002:a2e:900c:: with SMTP id h12-v6mr4966502ljg.121.1538426045273; Mon, 01 Oct 2018 13:34:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cridland Date: Mon, 1 Oct 2018 21:33:54 +0100 Message-ID: To: Richard Barnes Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000f127ff057730b9e9" Archived-At: Subject: Re: [MLS] Removing ART; maybe adding partial-tree 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, 01 Oct 2018 20:34:15 -0000 --000000000000f127ff057730b9e9 Content-Type: text/plain; charset="UTF-8" On Mon, 1 Oct 2018 at 19:06, Richard Barnes wrote: > Hey all, > > At the interim last week, there was agreement to remove the discussion of > ART from the protocol draft and focus on TreeKEM. I have implemented that > change in the following pull request: > > https://github.com/mlswg/mls-protocol/pull/66 > > I'm not objecting to the change - I lack sufficient cryptographic knowledge to express an opinion - but it'd be very useful to read a synopsis of the reasoning behind it, and a summary of the discussion. I imagine future participants would find it useful too, and of course, all decisions need to go by the list anyway. I reviewed the PR for clarity/typos. > If a couple of folks could give a quick review, it would be appreciated. > I also put together a PR describing how to do the "partial tree" approach > described at the interim and in my earlier message today. > > https://github.com/mlswg/mls-protocol/pull/67 > Also reviewed for clarity/typos. I admit I'm mildly confused as to why adding a node needs to blank the direct path, but at the same time I'm not sure it makes any difference. (That is, here: https://github.com/mlswg/mls-protocol/pull/67/commits/7a7cd37aec0ceff773600564b5c9619c3d06a115#diff-a87cc9081154f564150420544170f1c9R1113 ). That's probably just my lack of understanding somewhere. > > Feedback welcome! > > Thanks, > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000f127ff057730b9e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, 1 Oct 2018 at 19:06, Richard Barnes <rlb@ipv.sx> w= rote:
Hey all,

At the interim last week, there was agreement to remove the discussi= on of ART from the protocol draft and focus on TreeKEM.=C2=A0 I have implem= ented that change in the following pull request:

<= a href=3D"https://github.com/mlswg/mls-protocol/pull/66" target=3D"_blank">= https://github.com/mlswg/mls-protocol/pull/66


I'm not objecting to the = change - I lack sufficient cryptographic knowledge to express an opinion - = but it'd be very useful to read a synopsis of the reasoning behind it, = and a summary of the discussion. I imagine future participants would find i= t useful too, and of course, all decisions need to go by the list anyway.

I reviewed the PR for clarity/typos.
=C2= =A0
If a couple of folks cou= ld give a quick review, it would be appreciated.=C2=A0 I also put together = a PR describing how to do the "partial tree" approach described a= t the interim and in my earlier message today.

https://github.com/mlswg/mls-protocol/pull/67
=

Also reviewed for clarity/typos. I admit I= 'm mildly confused as to why adding a node needs to blank the direct pa= th, but at the same time I'm not sure it makes any difference. (That is= , here:=C2=A0https://github.com/mlswg/mls-protocol/pull/67/commits/7a7cd37a= ec0ceff773600564b5c9619c3d06a115#diff-a87cc9081154f564150420544170f1c9R1113= ). That's probably just my lack of understanding somewhere.
<= div>=C2=A0

Feedback wel= come!

Thanks,
--Richard
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000f127ff057730b9e9-- From nobody Mon Oct 1 14:15:02 2018 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 30C28130EAF for ; Mon, 1 Oct 2018 14:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPqAL7wGY2W5 for ; Mon, 1 Oct 2018 14:14:56 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 8DF0C130DE9 for ; Mon, 1 Oct 2018 14:14:56 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id v69-v6so5144836oif.1 for ; Mon, 01 Oct 2018 14:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NPVbJfRT/R4omFnhvQxXp0/DEBPyFFYmj2Ezp3668CQ=; b=iiJHYZvSN/Kg++FWcjF+ECZtJV9V5ovYiZda5GHZZNaDf9+KpnsYkQpE0iWX30naHY FA19yYgdnRDp6MbtholMmiDtqySb61JbncE1eWjWLEmfevqfbcO4pWVL2SeDl6Oa/XmY KlijXcAlTLIyrwamW+ImY+FwLgoGsPVf9/dYsmAtE7/Zj+xzPUbFO/fs2cLXNbWdYxpe i3Ss739BkZUUTm7acnXPn+YRu0jiVYt+/GWVmu5baCgIbF1wRNTP2Yos/H0i2HN2e6ob j5rifm90QIhqeuqkWqkAtEp02uFEpLlgTb+XPZdy2RNpUbpoBqJ4x3d9XIzzgInHI/2y YtsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NPVbJfRT/R4omFnhvQxXp0/DEBPyFFYmj2Ezp3668CQ=; b=ZCzriUf8bG5sugCEG5dvRNTDuw8JEQ0jCa0sdw26e+f2izPZC/LU+D/7mhZjMuCPBM nI78y+4e6kSg/FuGaHasanM6luSkpqgtEwu3n+ilvzjFSbOa9yNrK6mYsXphkEBVY2jr 9P4IaeNMSwFymHYPv+t79BDVHl2ldUkSnoLzss46JFPtro5Gb01r4odu+FPV+VMdQf68 s4PGVQbYzT8osMeht8eTKZoL5f7b1hAy2hk05bB8CW90+1PyEjroRmLkvG8nWOzKhuNB IPNpyTs1yRuXkfMyanKZMdciUGDz4kajkkcbz6xrEIEoLDs4L55gfKb41qUYAfyGRcUr Ajww== X-Gm-Message-State: ABuFfohTNBnJ2lTI7OZndyHbbcj2quxMVOrKVMkcQflM2hsnW9JMos/o opyU8ucdC+Xhwso87gDtizjSbX/guAwus8iVBrpGKqrPKJA= X-Google-Smtp-Source: ACcGV62b5sKtJ1N7dIxvFdbblrX1eIswoPgi5nDM/gO+/jq0tjVBQ6nv5OV0aE66C72NjVZaBDNG4ziBNxK45T1H3sY= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr6331457oib.155.1538428495572; Mon, 01 Oct 2018 14:14:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 1 Oct 2018 23:14:38 +0200 Message-ID: To: Dave Cridland Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000fdf48a0577314b70" Archived-At: Subject: Re: [MLS] Removing ART; maybe adding partial-tree 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, 01 Oct 2018 21:15:00 -0000 --000000000000fdf48a0577314b70 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 1, 2018 at 10:34 PM Dave Cridland wrote: > > > On Mon, 1 Oct 2018 at 19:06, Richard Barnes wrote: > >> Hey all, >> >> At the interim last week, there was agreement to remove the discussion of >> ART from the protocol draft and focus on TreeKEM. I have implemented that >> change in the following pull request: >> >> https://github.com/mlswg/mls-protocol/pull/66 >> >> > I'm not objecting to the change - I lack sufficient cryptographic > knowledge to express an opinion - but it'd be very useful to read a > synopsis of the reasoning behind it, and a summary of the discussion. I > imagine future participants would find it useful too, and of course, all > decisions need to go by the list anyway. > To recap the discussions at the interim, I think the reasons are basically as follows, in descending order of importance: 1. ART requires each recipient of a message to do O(log N) DH operations, where as TreeKEM only requires O(1). This is a significant difference for large groups / small devices. 2. TreeKEM offers the possibility of doing Add/Remove without double join 3. TreeKEM offers the possibility of being able to merge Update messages While I don't think anyone has proved that (2) and (3) aren't possible with ART, the fact that it's contributive makes them more difficult. > I reviewed the PR for clarity/typos. > > >> If a couple of folks could give a quick review, it would be appreciated. >> I also put together a PR describing how to do the "partial tree" approach >> described at the interim and in my earlier message today. >> >> https://github.com/mlswg/mls-protocol/pull/67 >> > > Also reviewed for clarity/typos. I admit I'm mildly confused as to why > adding a node needs to blank the direct path, but at the same time I'm not > sure it makes any difference. (That is, here: > https://github.com/mlswg/mls-protocol/pull/67/commits/7a7cd37aec0ceff773600564b5c9619c3d06a115#diff-a87cc9081154f564150420544170f1c9R1113 > ). That's probably just my lack of understanding somewhere. > The reason is symmetric for Add and Remove. Recall that the invariant property the tree is supposed to have is that a node's secret value and private key are only known to the holders of leaves below that node in the tree. For both Add and Remove, you need to change the intermediate nodes above the target leaf, either to make it so that the removed member doesn't know them or so that the added member does. The question is what relationship those intermediate nodes have to the sender of the Add/Remove -- does the sender know the secret / private key or not? On the one hand, if the sender does know the private key, then you have a "double join" situation, where the sender knows something he's not supposed to. The phrase "double join" arises from the Add case, since the relevant intermediate node secrets are known both to the new member and to the sender of the Add. Effectively, they both occupy the new member's leaf, which complicates things quite a bit. For example, if you now want to evict the sender of the Add, you have to also evict the newly added leaf, etc. In the Remove case, the main impact of the double-join is that you don't have a true Remove operation, you only have a Take-over operation. That makes it difficult to imagine how you would ever compact the tree. On the other hand, if the sender doesn't know the private key, then the node has to be blank. In the Add case, there's no way (AFAIK) to set the intermediate node values to something that is known to (a) the existing members under those nodes and (b) the new member, without it also being known to the sender of the add. So the values that get decrypted to intermediate nodes during the Add are only for the purpose of computing the new root secret; the intermediate nodes can't have a non-blank value without violating the tree invariant. It may be possible to avoid blanks in the Remove case, but we would have to modify TreeKEM. You could still do the "hash to the root" trick to generate the fresh shared entropy for the epoch, but you couldn't just overwrite the values of the intermediate nodes (as is done now). You would have to fold in some entropy only known to the existing members. This is probably worth some thought. Anyway, hope that helps, --Richard > > >> >> Feedback welcome! >> >> Thanks, >> --Richard >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --000000000000fdf48a0577314b70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Oct 1, 2018 at 10:34 PM Dave Cridland <dave@cridland.net> wrote:


On Mon, 1 Oct 2018 at 19:06, Richard Barnes <rlb@ipv.sx&g= t; wrote:
Hey all,

At the interim last week, there was agreement to remove the discus= sion of ART from the protocol draft and focus on TreeKEM.=C2=A0 I have impl= emented that change in the following pull request:

https://github.com/mlswg/mls-protocol/pull/66


I'm not objecting to th= e change - I lack sufficient cryptographic knowledge to express an opinion = - but it'd be very useful to read a synopsis of the reasoning behind it= , and a summary of the discussion. I imagine future participants would find= it useful too, and of course, all decisions need to go by the list anyway.=

To recap the discu= ssions at the interim, I think the reasons are basically as follows, in des= cending order of importance:

1. ART requires each = recipient of a message to do O(log N) DH operations, where as TreeKEM only = requires O(1).=C2=A0 This is a significant difference for large groups / sm= all devices.
2. TreeKEM offers the possibility of doing Add/R= emove without double join
3. TreeKEM offers the possibility of be= ing able to merge Update messages

While I don&= #39;t think anyone has proved that (2) and (3) aren't possible with ART= , the fact that it's contributive makes them more difficult.
=
=C2=A0
=
I reviewed the PR for clar= ity/typos.
=C2=A0
= If a couple of folks could give a quick review, it would be appreciated.=C2= =A0 I also put together a PR describing how to do the "partial tree&qu= ot; approach described at the interim and in my earlier message today.
<= /div>


Also reviewed for = clarity/typos. I admit I'm mildly confused as to why adding a node need= s to blank the direct path, but at the same time I'm not sure it makes = any difference. (That is, here:=C2=A0https://github.com/m= lswg/mls-protocol/pull/67/commits/7a7cd37aec0ceff773600564b5c9619c3d06a115#= diff-a87cc9081154f564150420544170f1c9R1113 ). That's probably just = my lack of understanding somewhere.

The reason is symmetric for Add and Remove.=C2=A0

Recall that the invariant property the tree is suppos= ed to have is that a node's secret value and private key are only known= to the holders of leaves below that node in the tree.=C2=A0 For both Add a= nd Remove, you need to change the intermediate nodes above the target leaf,= either to make it so that the removed member doesn't know them or so t= hat the added member does.=C2=A0 The question is what relationship those in= termediate nodes have to the sender of the Add/Remove -- does the sender kn= ow the secret / private key or not?

On the one han= d, if the sender does know the private key, then you have a "double jo= in" situation, where the sender knows something he's not supposed = to.=C2=A0 The phrase "double join" arises from the Add case, sinc= e the relevant intermediate node secrets are known both to the new member a= nd to the sender of the Add.=C2=A0 Effectively, they both occupy the new me= mber's leaf, which complicates things quite a bit.=C2=A0 For example, i= f you now want to evict the sender of the Add, you have to also evict the n= ewly added leaf, etc.=C2=A0 In the Remove case, the main impact of the doub= le-join is that you don't have a true Remove operation, you only have a= Take-over operation.=C2=A0 That makes it difficult to imagine how you woul= d ever compact the tree.

On the other hand, if= the sender doesn't know the private key, then the node has to be blank= .=C2=A0 In the Add case, there's no way (AFAIK) to set the intermediate= node values to something that is known to (a) the existing members under t= hose nodes and (b) the new member, without it also being known to the sende= r of the add.=C2=A0 So the values that get decrypted to intermediate nodes = during the Add are only for the purpose of computing the new root secret; t= he intermediate nodes can't have a non-blank value without violating th= e tree invariant.=C2=A0

It may be possible to= avoid blanks in the Remove case, but we would have to modify TreeKEM.=C2= =A0 You could still do the "hash to the root" trick to generate t= he fresh shared entropy for the epoch, but you couldn't just overwrite = the values of the intermediate nodes (as is done now).=C2=A0 You would have= to fold in some entropy only known to the existing members.=C2=A0 This is = probably worth some thought.

Anyway, hope that= helps,
--Richard

=C2=A0
=C2=A0

F= eedback welcome!

Thanks,
--Richa= rd
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000fdf48a0577314b70-- From nobody Tue Oct 2 02:52:38 2018 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 8A64412777C for ; Tue, 2 Oct 2018 02:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ry38SspC_T18 for ; Tue, 2 Oct 2018 02:52:33 -0700 (PDT) Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) (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 30BB81271FF for ; Tue, 2 Oct 2018 02:52:33 -0700 (PDT) Received: by mail-ua1-x941.google.com with SMTP id y16-v6so472283uaa.7 for ; Tue, 02 Oct 2018 02:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5/7XTACmGimw5cr8q6hMa/uvdu5ult/aKqcTQsOKcaU=; b=ERivTv7UUO3Buq5Tf+5X1MTUY4m1x55QyxbXwdHnrOw4d/tdnDUXnKJsKoJqpf26hp GeajK1y/rysR6n/pS9abTNYmFYS06x8WynxO5JMbjN/AUaJhu26iwTOGoDwMShW5RuCr r0g8dN9dPkrsLfSSfwCaJAStqB/peoa09AfFw1Sj8hQjwY4nfk+6/tDgnCtTyXwOUn4S SlsanZ8c3SEaGuPjgl3nNdjAIPyrT3beDRQWBbyzkiIrn9fHsEDHMVHIcR/8np8+fPHH SR1i/dwBVQmS4mKkW7Jc3z2Va7qKyIm4cSrrAoIeoEXevOmz4klSxa+Ew0g8tK/clI4b WDVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5/7XTACmGimw5cr8q6hMa/uvdu5ult/aKqcTQsOKcaU=; b=dPL4ZltNKoTdfa5oER4Uh3QCxhoREw01Nfwym3Dz0B3yhcFBLhsyoam6V5Hz+mMMui VfWlR7ZFaGnDION3kDzoas8NSyPB2oQ9dDUMF2miSIP7gcJomIC//HVOOmxiE+CiYl/M 9gSGIQXc4Iz7drnzU1Re8kdvScO4lTCQUsFtERZFbKK1aCgD4FFD4K56AA/FFbRVe+yG gs4m3ti5wY+4u3dYBdREakvmzIWYoSZnDuNlCYmUqz5/ZB7Ryq+kUNSyvcnQ6FDOQwuL 1RB0H1NwX3lTy561Nm6vzdn1U/j4Nit/5YcL9zEb0zhGtDjunr34mhvCLrXiXWUAqCXa oWmg== X-Gm-Message-State: ABuFfogWR739OxX4H3dX/SW/IMzl6fj74pJbYaENoef+bRcPq+c5HL5D 0lXpkOpsxYjSLr7BbGh0YtyZEntCj1hg9e/nM5E= X-Google-Smtp-Source: ACcGV63jP28umsDRtc1/zTf9rpgHiD50/Te3YZYdCsAQGkGJEnIkD4eSv5fBJnj5Z7oX3v5LuX/HOZVTD19ovSTdTRw= X-Received: by 2002:a9f:3044:: with SMTP id i4-v6mr6518298uab.100.1538473952116; Tue, 02 Oct 2018 02:52:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cas Cremers Date: Tue, 2 Oct 2018 11:52:15 +0200 Message-ID: To: Richard Barnes Cc: dave@cridland.net, ML Messaging Layer Security Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] Removing ART; maybe adding partial-tree X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 09:52:37 -0000 Hi Dave and all, I would like to add one thing to Richard's explanation of the rationale for dropping ART in favor of TreeKEM for now: An important implicit assumption is that TreeKEM doesn't seem to offer less security guarantees than ART. However, given that the specification of protocols, threat models, and properties isn't completely fleshed out, we don't really yet know if this is true in any formal sense. Analysis is continuing in parallel, and we might need to backtrack in the worst case. This choice is not (and must not be) about efficiency alone. Best, Cas --=20 https://people.cispa.io/cas.cremers/index.html On Mon, Oct 1, 2018 at 11:15 PM Richard Barnes wrote: > > > > On Mon, Oct 1, 2018 at 10:34 PM Dave Cridland wrote: >> >> >> >> On Mon, 1 Oct 2018 at 19:06, Richard Barnes wrote: >>> >>> Hey all, >>> >>> At the interim last week, there was agreement to remove the discussion = of ART from the protocol draft and focus on TreeKEM. I have implemented th= at change in the following pull request: >>> >>> https://github.com/mlswg/mls-protocol/pull/66 >>> >> >> I'm not objecting to the change - I lack sufficient cryptographic knowle= dge to express an opinion - but it'd be very useful to read a synopsis of t= he reasoning behind it, and a summary of the discussion. I imagine future p= articipants would find it useful too, and of course, all decisions need to = go by the list anyway. > > > To recap the discussions at the interim, I think the reasons are basicall= y as follows, in descending order of importance: > > 1. ART requires each recipient of a message to do O(log N) DH operations,= where as TreeKEM only requires O(1). This is a significant difference for= large groups / small devices. > 2. TreeKEM offers the possibility of doing Add/Remove without double join > 3. TreeKEM offers the possibility of being able to merge Update messages > > While I don't think anyone has proved that (2) and (3) aren't possible wi= th ART, the fact that it's contributive makes them more difficult. > > >> >> I reviewed the PR for clarity/typos. >> >>> >>> If a couple of folks could give a quick review, it would be appreciated= . I also put together a PR describing how to do the "partial tree" approac= h described at the interim and in my earlier message today. >>> >>> https://github.com/mlswg/mls-protocol/pull/67 >> >> >> Also reviewed for clarity/typos. I admit I'm mildly confused as to why a= dding a node needs to blank the direct path, but at the same time I'm not s= ure it makes any difference. (That is, here: https://github.com/mlswg/mls-p= rotocol/pull/67/commits/7a7cd37aec0ceff773600564b5c9619c3d06a115#diff-a87cc= 9081154f564150420544170f1c9R1113 ). That's probably just my lack of underst= anding somewhere. > > > The reason is symmetric for Add and Remove. > > Recall that the invariant property the tree is supposed to have is that a= node's secret value and private key are only known to the holders of leave= s below that node in the tree. For both Add and Remove, you need to change= the intermediate nodes above the target leaf, either to make it so that th= e removed member doesn't know them or so that the added member does. The q= uestion is what relationship those intermediate nodes have to the sender of= the Add/Remove -- does the sender know the secret / private key or not? > > On the one hand, if the sender does know the private key, then you have a= "double join" situation, where the sender knows something he's not suppose= d to. The phrase "double join" arises from the Add case, since the relevan= t intermediate node secrets are known both to the new member and to the sen= der of the Add. Effectively, they both occupy the new member's leaf, which= complicates things quite a bit. For example, if you now want to evict the= sender of the Add, you have to also evict the newly added leaf, etc. In t= he Remove case, the main impact of the double-join is that you don't have a= true Remove operation, you only have a Take-over operation. That makes it= difficult to imagine how you would ever compact the tree. > > On the other hand, if the sender doesn't know the private key, then the n= ode has to be blank.. In the Add case, there's no way (AFAIK) to set the i= ntermediate node values to something that is known to (a) the existing memb= ers under those nodes and (b) the new member, without it also being known t= o the sender of the add. So the values that get decrypted to intermediate = nodes during the Add are only for the purpose of computing the new root sec= ret; the intermediate nodes can't have a non-blank value without violating = the tree invariant. > > It may be possible to avoid blanks in the Remove case, but we would have = to modify TreeKEM. You could still do the "hash to the root" trick to gene= rate the fresh shared entropy for the epoch, but you couldn't just overwrit= e the values of the intermediate nodes (as is done now). You would have to= fold in some entropy only known to the existing members. This is probably= worth some thought. > > Anyway, hope that helps, > --Richard > > >> >> >>> >>> >>> Feedback welcome! >>> >>> Thanks, >>> --Richard >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Oct 2 16:17:54 2018 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 60968131118 for ; Tue, 2 Oct 2018 16:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kugONetSYek6 for ; Tue, 2 Oct 2018 16:17:48 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 37CF41310CA for ; Tue, 2 Oct 2018 16:17:48 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id e18-v6so3695669oti.8 for ; Tue, 02 Oct 2018 16:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SD7rVYMQGvydIzyXDFondnnaEpsH3nIKeCyHvig9254=; b=Q8WCDrlNDqDVxqvRF3+r/76V1q7ahmY3gBE23Auk4g+4rKJ47kiXnXSiEEpV+6+3eZ 4oIz1Hs9/9ss8lqA/MdoCtDri81cElJlX54hwPPusIgTu6y50b30H81CNXkQZ4X6WLCH fQjV7PRitAgKCCls//BsvAQ45KaJ10oh8sh2MLrqx/yvwJPY6CREDw8aBtLAYaujllV9 Lktc+1Dj3gQ1hpTkXvhDXnGSQ9CObh6w4rD8TXGlp4WSOg69+RvuxQotqEK0Ayfg0NC+ ySXfGNrQSbHMzW9A0Gz7X56kIznZ9zO5ylQ8tZc/XLaZ+B3F0u4AV0d/ijaBshJ77ByL BQ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SD7rVYMQGvydIzyXDFondnnaEpsH3nIKeCyHvig9254=; b=SOSBmvr9BZS2qey4YHNXhwPKTBhbEDaVb4Zr6kyhizuyLJpeWXPOWl9fHdOSOB9EQ4 ODF4o4glzk1Pg89Mj495NZRExrTlI5mkqytVZDoz/HT9lR5yyyqd5tLBSrLOGIlUGFx+ AXDz9GMu0Ylb17YeDuyQsoJcAQip37uf5Jh0jM4z/Rv+nuzwugrbnjUoCiYG6cJ+c6oQ nR3U1lATaSk8mDXbz79m27bf7/+vAa+BTXaHevvKj3NSvRGSx6dxyWMFGEtl1vfhCB1W K3do+zj5E9RIRGBzOzBklXBle8lVI27p10QJJ6+JGxSJnPkAuaImxY/nyBy8KIm2Zcll 8jAw== X-Gm-Message-State: ABuFfogiu2e99lN5NutVIq0bYc3hczBhCx5j7YO85qttccxbWwT5Wrly qKX8s+vZvN9mvsJxpD+TtCHupmGsP2jtzQZv+6M0VjuJYsE= X-Google-Smtp-Source: ACcGV60RHwrmkgioixODQ++SWw/8RKKEXaQ4zzXy1QjqsYLObopJh7g5cZ3LJfMpf6+5qHLLoNOdgeZEBGdWI81bMG4= X-Received: by 2002:a9d:764d:: with SMTP id o13-v6mr9854323otl.116.1538522267311; Tue, 02 Oct 2018 16:17:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 3 Oct 2018 01:17:30 +0200 Message-ID: To: brendan=40cloudflare.com@dmarc.ietf.org Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000038f9f305774721c6" Archived-At: Subject: Re: [MLS] Supporting Large Groups X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 23:17:52 -0000 --00000000000038f9f305774721c6 Content-Type: text/plain; charset="UTF-8" Hi Brendan, I'd like to argue that this can be done by a client implementation without affecting the overall protocol. If an implementation can keep a group of clients in sync with regard to the appropriate secrets (primarily init keys, and a (leaf DH key, signature key) pair per group), then they can effectively act collectively as one member of the overall group. You could even imagine doing this by using MLS to sync across the subgroup. By the same token, since this can be done via sync within a subgroup, it doesn't seem like we need to do anything to the base MLS spec to support this style of composition. If folks have an interest in having a standard way to sync stuff, it might make an interesting follow-on spec. That said, the whole point of MLS vs. earlier linear / N^2 protocols is to be able to scale farther. Exactly how much farther will depend on your specific tolerances, but ISTM that O(10^5) should be acheivable with relatively modest overhead. --Richard On Wed, Sep 26, 2018 at 10:05 PM Brendan McMillion wrote: > Hello mls@ > > My current understanding of the MLS protocol is that every user must be > individually invited to every chat room that they're a member of. This has > a lot of bad usability and performance properties for the case where you > want to invite the same large set of people to several different rooms. For > example, you could think about "everyone@company.com" being invited to > rooms for "Product A", "Team B", etc. I think it would be easy enough to > address this in the standard: > > Rather than only being able to add one user at a time, you could introduce > a mailing list-type concept where many people are represented by a single > email address / public key. Group membership, and therefore the group > public key, would be maintained by the same system that stores user > identity keys. > > I think there are probably a lot of valid ways to construct a group public > key, so standardizing a specific construction would be less useful than > just defining the necessary properties and how it would interact with the > protocol. What makes sense to me is: groups have only init keys which are > known to all group members, and no identity keys. This means that group > members can read messages but not send them (with the exception of an > Update message). To speak in a room, a group member must first send an Add > message for themselves. They can send the Add message because they know all > of the room secrets, through their knowledge of the group init private key. > > An Update message can be sent on behalf of a group to occasionally update > the group init key, without requiring any specific member of the group to > join the room. Rather than signing the message to authenticate it, they > would have to provide some evidence from the Key Store that this is really > the group's updated init key. Note that in the interest of efficiency, a > group init key would likely be semi-static and re-used between several > rooms, unlike user init keys which are only used once. > > Any comments or suggestions are welcome. > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000038f9f305774721c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brendan,

I'd like to = argue that this can be done by a client implementation without affecting th= e overall protocol.=C2=A0 If an implementation can keep a group of clients = in sync with regard to the appropriate secrets (primarily init keys, and a = (leaf DH key, signature key) pair per group), then they can effectively act= collectively as one member of the overall group.=C2=A0 You could even imag= ine doing this by using MLS to sync across the subgroup.

By the same token, since this can be done via sync within a subgroup= , it doesn't seem like we need to do anything to the base MLS spec to s= upport this style of composition.=C2=A0 If folks have an interest in having= a standard way to sync stuff, it might make an interesting follow-on spec.=

That said, the whole point of MLS vs. earlier lin= ear / N^2 protocols is to be able to scale farther.=C2=A0 Exactly how much = farther will depend on your specific tolerances, but ISTM that O(10^5) shou= ld be acheivable with relatively modest overhead.

<= div>--Richard


=
On Wed, Sep 26, 2018 at 10:05 PM Brendan McMillion <bre= ndan=3D40cloudflare.com@= dmarc.ietf.org> wrote:
Hello mls@

My current understanding of the MLS protocol = is that every user must be individually invited to every chat room that the= y're a member of. This has a lot of bad usability and performance prope= rties for the case where you want to invite the same large set of people to= several different rooms. For example, you could think about "everyone@company.com= " being invited to rooms for "Product A", "Team B"= , etc. I think it would be easy enough to address this in the standard:
=
Rather than only being able to add one user at a time, you could introd= uce a mailing list-type concept where many people are represented by a sing= le email address / public key. Group membership, and therefore the group pu= blic key, would be maintained by the same system that stores user identity = keys.

I think there are probably a lot of valid ways to construct a = group public key, so standardizing a specific construction would be less us= eful than just defining the necessary properties and how it would interact = with the protocol. What makes sense to me is: groups have only init keys wh= ich are known to all group members, and no identity keys. This means that g= roup members can read messages but not send them (with the exception of an = Update message). To speak in a room, a group member must first send an Add = message for themselves. They can send the Add message because they know all= of the room secrets, through their knowledge of the group init private key= .

An Update message can be sent on behalf of a group to occasionally= update the group init key, without requiring any specific member of the gr= oup to join the room. Rather than signing the message to authenticate it, t= hey would have to provide some evidence from the Key Store that this is rea= lly the group's updated init key. Note that in the interest of efficien= cy, a group init key would likely be semi-static and re-used between severa= l rooms, unlike user init keys which are only used once.

Any comment= s or suggestions are welcome.
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000038f9f305774721c6-- From nobody Fri Oct 5 13:53:54 2018 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 0AD571277D2 for ; Fri, 5 Oct 2018 13:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0zxBSPu_yxc for ; Fri, 5 Oct 2018 13:53:49 -0700 (PDT) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 5266C1286E3 for ; Fri, 5 Oct 2018 13:53:49 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id l1so684563otj.5 for ; Fri, 05 Oct 2018 13:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sy6bOGIAQoVc06+OV74cBg1paqV/8Cl/L1oFl4c1NPo=; b=I7VuW8lw/kvb9r5uWdGp2gumlgfoUii9l1FpTPouv0dYVTQunJnLg98ZzxvTLBG8i5 U6jmkii+Xi84cUbyvbKpccR3bKhjsOead1C/TWQAs0szVW948SKL04W7d9Iov/VCWBRW TIh53V3O6ZKttw2RM+W+bh1xJ/JDGSAiu7pMQRq9eVEE6jBVv+CptuoMzy68MLvA7N5w 6z4VN9iZlwbsXMG2zYlG20aCQ1fW/JSHvP2cD63W1BU+nGuJehnC+X1j74q9SXx/yyM8 IT4QRHgpXxEmHV42ZsquZ90SuqWbBtnoAfq4sNHzi6qPl4WaeGfjGgy8YmaoRMJG5xV7 SEpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sy6bOGIAQoVc06+OV74cBg1paqV/8Cl/L1oFl4c1NPo=; b=I/cfnnwsEtYm2r7yxmqjGMgoB0yUc/uSzSHA6u4SJqaTSXmWiqp40c0RxYraGjprcj 73NoQiRmsIYfrmJISPyD+fagveiHmA1couNLmFF+F/1kNQ+J76KJzasTJxPEnhL45815 6R/Cx6W3DqEr1hCltjUaIh/kUb3oSvhQpsTfH7D0wGCzVVck4XS5C/QIBLNsvQrzwOf/ FqxCkTciC6MGCSwwWBey4TRx0qQNJweJH2SP4apjx1Tqyrp7+HnQGUiLckgDlb5dDall I6jgxG0q7acyYykUPfpbMSRPcClXXgRfwxWgu9LUZzbouWZwbGINCCuJZBV6ktaaBO30 DKUg== X-Gm-Message-State: ABuFfoi9ZXcd0YgPUfL637Aeg8+oINRwElzl7uEbItCL/yY+B2jsKa45 z8ZaNh5FOieR7N+1iYVk8cycu07fiQGzgDYWXvth/Q== X-Google-Smtp-Source: ACcGV61KWITdQ9vom0CkjxMeyFMxVyH5wG2bxkkIAZDgJcimzvnSuxllZowPE0e2IqBWKCBgKeD9mCprB1M4f0OechQ= X-Received: by 2002:a9d:42f1:: with SMTP id c46-v6mr6969492otj.331.1538772828464; Fri, 05 Oct 2018 13:53:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 5 Oct 2018 16:53:36 -0400 Message-ID: To: Cas Cremers Cc: Dave Cridland , mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d4ba0605778177d0" Archived-At: Subject: Re: [MLS] Removing ART; maybe adding partial-tree X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 20:53:53 -0000 --000000000000d4ba0605778177d0 Content-Type: text/plain; charset="UTF-8" One additional possibly-nice thing here: Adds can O(1) for existing members. Someone pointed out at the interim (I think Cas or Karthik) that in the Add case, there's no need for the existing members of the group to fold in new entropy into the group secrets, they just need to hash everything forward. This means that the sender of an add doesn't need to encrypt any fresh entropy to the group, and the existing group members don't need to decrypt it. The member sending the Add just needs to send the init_secret for the group to the new member and tell everyone to ratchet forward. Now, this doesn't mean that Adds are free. It's just that instead of paying in units of computation to send/process the message, you pay in terms of future updates being more expensive, due to the ancestors of the new member being blanked. If you have a tree of size N and do M adds, then the next Update/Remove will involve (log(N) + log(N) + M) encryptions/ciphertexts in the worst case. (The extra log(N) comes from existing nodes being blanked out.) That said, if the new node updates quickly, then you're back to a whole tree and only log(N) operations. --Richard On Tue, Oct 2, 2018 at 5:52 AM Cas Cremers wrote: > Hi Dave and all, > > I would like to add one thing to Richard's explanation of the > rationale for dropping ART in favor of TreeKEM for now: > > An important implicit assumption is that TreeKEM doesn't seem to offer > less security guarantees than ART. > > However, given that the specification of protocols, threat models, and > properties isn't completely fleshed out, we don't really yet know if > this is true in any formal sense. Analysis is continuing in parallel, > and we might need to backtrack in the worst case. > > This choice is not (and must not be) about efficiency alone. > > Best, > > Cas > > -- > https://people.cispa.io/cas.cremers/index.html > > On Mon, Oct 1, 2018 at 11:15 PM Richard Barnes wrote: > > > > > > > > On Mon, Oct 1, 2018 at 10:34 PM Dave Cridland wrote: > >> > >> > >> > >> On Mon, 1 Oct 2018 at 19:06, Richard Barnes wrote: > >>> > >>> Hey all, > >>> > >>> At the interim last week, there was agreement to remove the discussion > of ART from the protocol draft and focus on TreeKEM. I have implemented > that change in the following pull request: > >>> > >>> https://github.com/mlswg/mls-protocol/pull/66 > >>> > >> > >> I'm not objecting to the change - I lack sufficient cryptographic > knowledge to express an opinion - but it'd be very useful to read a > synopsis of the reasoning behind it, and a summary of the discussion. I > imagine future participants would find it useful too, and of course, all > decisions need to go by the list anyway. > > > > > > To recap the discussions at the interim, I think the reasons are > basically as follows, in descending order of importance: > > > > 1. ART requires each recipient of a message to do O(log N) DH > operations, where as TreeKEM only requires O(1). This is a significant > difference for large groups / small devices. > > 2. TreeKEM offers the possibility of doing Add/Remove without double join > > 3. TreeKEM offers the possibility of being able to merge Update messages > > > > While I don't think anyone has proved that (2) and (3) aren't possible > with ART, the fact that it's contributive makes them more difficult. > > > > > >> > >> I reviewed the PR for clarity/typos. > >> > >>> > >>> If a couple of folks could give a quick review, it would be > appreciated. I also put together a PR describing how to do the "partial > tree" approach described at the interim and in my earlier message today. > >>> > >>> https://github.com/mlswg/mls-protocol/pull/67 > >> > >> > >> Also reviewed for clarity/typos. I admit I'm mildly confused as to why > adding a node needs to blank the direct path, but at the same time I'm not > sure it makes any difference. (That is, here: > https://github.com/mlswg/mls-protocol/pull/67/commits/7a7cd37aec0ceff773600564b5c9619c3d06a115#diff-a87cc9081154f564150420544170f1c9R1113 > ). That's probably just my lack of understanding somewhere. > > > > > > The reason is symmetric for Add and Remove. > > > > Recall that the invariant property the tree is supposed to have is that > a node's secret value and private key are only known to the holders of > leaves below that node in the tree. For both Add and Remove, you need to > change the intermediate nodes above the target leaf, either to make it so > that the removed member doesn't know them or so that the added member > does. The question is what relationship those intermediate nodes have to > the sender of the Add/Remove -- does the sender know the secret / private > key or not? > > > > On the one hand, if the sender does know the private key, then you have > a "double join" situation, where the sender knows something he's not > supposed to. The phrase "double join" arises from the Add case, since the > relevant intermediate node secrets are known both to the new member and to > the sender of the Add. Effectively, they both occupy the new member's > leaf, which complicates things quite a bit. For example, if you now want > to evict the sender of the Add, you have to also evict the newly added > leaf, etc. In the Remove case, the main impact of the double-join is that > you don't have a true Remove operation, you only have a Take-over > operation. That makes it difficult to imagine how you would ever compact > the tree. > > > > On the other hand, if the sender doesn't know the private key, then the > node has to be blank.. In the Add case, there's no way (AFAIK) to set the > intermediate node values to something that is known to (a) the existing > members under those nodes and (b) the new member, without it also being > known to the sender of the add. So the values that get decrypted to > intermediate nodes during the Add are only for the purpose of computing the > new root secret; the intermediate nodes can't have a non-blank value > without violating the tree invariant. > > > > It may be possible to avoid blanks in the Remove case, but we would have > to modify TreeKEM. You could still do the "hash to the root" trick to > generate the fresh shared entropy for the epoch, but you couldn't just > overwrite the values of the intermediate nodes (as is done now). You would > have to fold in some entropy only known to the existing members. This is > probably worth some thought. > > > > Anyway, hope that helps, > > --Richard > > > > > >> > >> > >>> > >>> > >>> Feedback welcome! > >>> > >>> Thanks, > >>> --Richard > >>> _______________________________________________ > >>> 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 > --000000000000d4ba0605778177d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One additional possibly-nice thing here: Adds can O(1= ) for existing members.

Someone pointed out at the= interim (I think Cas or Karthik) that in the Add case, there's no need= for the existing members of the group to fold in new entropy into the grou= p secrets, they just need to hash everything forward.=C2=A0 This means that= the sender of an add doesn't need to encrypt any fresh entropy to the = group, and the existing group members don't need to decrypt it.=C2=A0 T= he member sending the Add just needs to send the init_secret for the group = to the new member and tell everyone to ratchet forward.

Now, this doesn't mean that Adds are free.=C2=A0 It's just th= at instead of paying in units of computation to send/process the message, y= ou pay in terms of future updates being more expensive, due to the ancestor= s of the new member being blanked.=C2=A0 If you have a tree of size N and d= o M adds, then the next Update/Remove will involve (log(N)=C2=A0+ log(N) + = M) encryptions/ciphertexts in the worst case.=C2=A0 (The extra log(N) comes= from existing nodes being blanked out.)

That = said, if the new node updates quickly, then you're back to a whole tree= and only log(N) operations.

--Richard

On Tue, Oct 2, 2018= at 5:52 AM Cas Cremers <cas.cr= emers@gmail.com> wrote:
Hi D= ave and all,

I would like to add one thing to Richard's explanation of the
rationale for dropping ART in favor of TreeKEM for now:

An important implicit assumption is that TreeKEM doesn't seem to offer<= br> less security guarantees than ART.

However, given that the specification of protocols, threat models, and
properties isn't completely fleshed out, we don't really yet know i= f
this is true in any formal sense.=C2=A0 Analysis is continuing in parallel,=
and we might need to backtrack in the worst case.

This choice is not (and must not be) about efficiency alone.

Best,

Cas

--
https://people.cispa.io/cas.cremers/index.html

On Mon, Oct 1, 2018 at 11:15 PM Richard Barnes <rlb@ipv.sx> wrote: >
>
>
> On Mon, Oct 1, 2018 at 10:34 PM Dave Cridland <dave@cridland.net> wrote:
>>
>>
>>
>> On Mon, 1 Oct 2018 at 19:06, Richard Barnes <rlb@ipv.sx> wro= te:
>>>
>>> Hey all,
>>>
>>> At the interim last week, there was agreement to remove the di= scussion of ART from the protocol draft and focus on TreeKEM.=C2=A0 I have = implemented that change in the following pull request:
>>>
>>> https://github.com/mlswg/mls-protocol/pul= l/66
>>>
>>
>> I'm not objecting to the change - I lack sufficient cryptograp= hic knowledge to express an opinion - but it'd be very useful to read a= synopsis of the reasoning behind it, and a summary of the discussion. I im= agine future participants would find it useful too, and of course, all deci= sions need to go by the list anyway.
>
>
> To recap the discussions at the interim, I think the reasons are basic= ally as follows, in descending order of importance:
>
> 1. ART requires each recipient of a message to do O(log N) DH operatio= ns, where as TreeKEM only requires O(1).=C2=A0 This is a significant differ= ence for large groups / small devices.
> 2. TreeKEM offers the possibility of doing Add/Remove without double j= oin
> 3. TreeKEM offers the possibility of being able to merge Update messag= es
>
> While I don't think anyone has proved that (2) and (3) aren't = possible with ART, the fact that it's contributive makes them more diff= icult.
>
>
>>
>> I reviewed the PR for clarity/typos.
>>
>>>
>>> If a couple of folks could give a quick review, it would be ap= preciated.=C2=A0 I also put together a PR describing how to do the "pa= rtial tree" approach described at the interim and in my earlier messag= e today.
>>>
>>> https://github.com/mlswg/mls-protocol/pul= l/67
>>
>>
>> Also reviewed for clarity/typos. I admit I'm mildly confused a= s to why adding a node needs to blank the direct path, but at the same time= I'm not sure it makes any difference. (That is, here: https://github.com/mlswg/mls-protocol/pull/67/commits/= 7a7cd37aec0ceff773600564b5c9619c3d06a115#diff-a87cc9081154f564150420544170f= 1c9R1113 ). That's probably just my lack of understanding somewhere= .
>
>
> The reason is symmetric for Add and Remove.
>
> Recall that the invariant property the tree is supposed to have is tha= t a node's secret value and private key are only known to the holders o= f leaves below that node in the tree.=C2=A0 For both Add and Remove, you ne= ed to change the intermediate nodes above the target leaf, either to make i= t so that the removed member doesn't know them or so that the added mem= ber does.=C2=A0 The question is what relationship those intermediate nodes = have to the sender of the Add/Remove -- does the sender know the secret / p= rivate key or not?
>
> On the one hand, if the sender does know the private key, then you hav= e a "double join" situation, where the sender knows something he&= #39;s not supposed to.=C2=A0 The phrase "double join" arises from= the Add case, since the relevant intermediate node secrets are known both = to the new member and to the sender of the Add.=C2=A0 Effectively, they bot= h occupy the new member's leaf, which complicates things quite a bit.= =C2=A0 For example, if you now want to evict the sender of the Add, you hav= e to also evict the newly added leaf, etc.=C2=A0 In the Remove case, the ma= in impact of the double-join is that you don't have a true Remove opera= tion, you only have a Take-over operation.=C2=A0 That makes it difficult to= imagine how you would ever compact the tree.
>
> On the other hand, if the sender doesn't know the private key, the= n the node has to be blank..=C2=A0 In the Add case, there's no way (AFA= IK) to set the intermediate node values to something that is known to (a) t= he existing members under those nodes and (b) the new member, without it al= so being known to the sender of the add.=C2=A0 So the values that get decry= pted to intermediate nodes during the Add are only for the purpose of compu= ting the new root secret; the intermediate nodes can't have a non-blank= value without violating the tree invariant.
>
> It may be possible to avoid blanks in the Remove case, but we would ha= ve to modify TreeKEM.=C2=A0 You could still do the "hash to the root&q= uot; trick to generate the fresh shared entropy for the epoch, but you coul= dn't just overwrite the values of the intermediate nodes (as is done no= w).=C2=A0 You would have to fold in some entropy only known to the existing= members.=C2=A0 This is probably worth some thought.
>
> Anyway, hope that helps,
> --Richard
>
>
>>
>>
>>>
>>>
>>> Feedback welcome!
>>>
>>> Thanks,
>>> --Richard
>>> _______________________________________________
>>> MLS mailing list
>>> MLS@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/mls<= br> >
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
--000000000000d4ba0605778177d0-- From nobody Fri Oct 5 14:05:17 2018 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 16A201286D9 for ; Fri, 5 Oct 2018 14:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8m4LledZ2kd for ; Fri, 5 Oct 2018 14:05:12 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 6D04E1277D2 for ; Fri, 5 Oct 2018 14:05:12 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id y81-v6so11501586oia.6 for ; Fri, 05 Oct 2018 14:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KwkUew0XRp9nY2hKeEd/9DNbdaqjn44lIasFHTzP4z4=; b=AIdFdVtv1NMNmHGOGQIsXCD0Wxd7K7M7EVScAr2jmKRjr9M4EkS2R2gYM986qLDQb/ 05sHIRNY2A2pyjUzBsr2wxgT4Fds2iWJ77n4cMBFVwm4QsxxwAIMU7HY1nSAg1scuJgm TLGnVdMxFhB+WV01RH//IcOG7NLcDzVp8z3vdClB1iDqF/hMj/kQKN3BaHhSmnFhsRi/ KTznmC1AvfCz+xCR1QhJBk3Y4WrvEoDnBoI5y6B4rj5L6adNMjZdMomtCnY3E1UGTTlN Li6jdUaW20pIpSIksM9XjpQYZdGIlWBEzpllTWDSNyrGhtQspGMeZFrt2AktXhqlwCD7 ZqRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KwkUew0XRp9nY2hKeEd/9DNbdaqjn44lIasFHTzP4z4=; b=hHtZXxXXgeTL/+b+BlGKflcARQsZ3pzFXluIJ6kDwbECxamMMTP77kmaXKDpYQhmo2 NTISpobMJBm33evGQiUrMW70asuhVdCoESHFXAnSFneDFkTdIzppVsuttI3JuqBorIz2 60PuECKbsPz88m7C3I2cZe2xkkSitHozyx2BHp/uMfJglLci7dWGRZWjD2RhW9dGYd9X HdNA/p9631pV6ke6oAglfkEJPZlXt4UY/+y02w5UbrcZrbmjHyDZZPpYS696jNArgCQT DFK48uP0uBlQ1YbKsyuL3F4hEQuZASuLk8su7afxlcIhD53tr4MBb4O1FgjdxmQaYTQ/ C2Wg== X-Gm-Message-State: ABuFfoi2x80+jfEfv1vGT6267j5ToP7gbIAyuWkuV2Ww1ocPIojgYjTk yHjnHlCpfZwIMyKbNj7cCBMOHTx5/t51/cBdmDsDfw== X-Google-Smtp-Source: ACcGV61aMt7Hn1s1MSQe+mnI2opXRA8yuQMXGUoY5yN7wWnYX26ZoYsmtNi26r6cYIM4m822JiudbYyyyStXyfN4d+U= X-Received: by 2002:aca:3c56:: with SMTP id j83-v6mr348571oia.155.1538773511546; Fri, 05 Oct 2018 14:05:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 5 Oct 2018 17:04:59 -0400 Message-ID: To: Cas Cremers Cc: Dave Cridland , mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000008bbcaa057781a074" Archived-At: Subject: Re: [MLS] Removing ART; maybe adding partial-tree X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 21:05:16 -0000 --0000000000008bbcaa057781a074 Content-Type: text/plain; charset="UTF-8" Forgot to mention, I updated the PR to do this: https://github.com/mlswg/mls-protocol/pull/67/commits/79f617200260682da5458d70f5972ef269babc7b Also, with this change, you could really do Init as a pile of Adds stapled together, with an Update tacked on the end if you want. In a related vein, note that if you have a group and all you ever do are Adds and Removes, then you basically have S/MIME / PGP with a degree of forward secrecy; everything's linear and based on static keys. Which re-emphasizes the point that TreeKEM with partial trees supports a smooth transition from that case to the full-tree, log(N) case. On Fri, Oct 5, 2018 at 4:53 PM Richard Barnes wrote: > One additional possibly-nice thing here: Adds can O(1) for existing > members. > > Someone pointed out at the interim (I think Cas or Karthik) that in the > Add case, there's no need for the existing members of the group to fold in > new entropy into the group secrets, they just need to hash everything > forward. This means that the sender of an add doesn't need to encrypt any > fresh entropy to the group, and the existing group members don't need to > decrypt it. The member sending the Add just needs to send the init_secret > for the group to the new member and tell everyone to ratchet forward. > > Now, this doesn't mean that Adds are free. It's just that instead of > paying in units of computation to send/process the message, you pay in > terms of future updates being more expensive, due to the ancestors of the > new member being blanked. If you have a tree of size N and do M adds, then > the next Update/Remove will involve (log(N) + log(N) + M) > encryptions/ciphertexts in the worst case. (The extra log(N) comes from > existing nodes being blanked out.) > > That said, if the new node updates quickly, then you're back to a whole > tree and only log(N) operations. > > --Richard > > On Tue, Oct 2, 2018 at 5:52 AM Cas Cremers wrote: > >> Hi Dave and all, >> >> I would like to add one thing to Richard's explanation of the >> rationale for dropping ART in favor of TreeKEM for now: >> >> An important implicit assumption is that TreeKEM doesn't seem to offer >> less security guarantees than ART. >> >> However, given that the specification of protocols, threat models, and >> properties isn't completely fleshed out, we don't really yet know if >> this is true in any formal sense. Analysis is continuing in parallel, >> and we might need to backtrack in the worst case. >> >> This choice is not (and must not be) about efficiency alone. >> >> Best, >> >> Cas >> >> -- >> https://people.cispa.io/cas.cremers/index.html >> >> On Mon, Oct 1, 2018 at 11:15 PM Richard Barnes wrote: >> > >> > >> > >> > On Mon, Oct 1, 2018 at 10:34 PM Dave Cridland >> wrote: >> >> >> >> >> >> >> >> On Mon, 1 Oct 2018 at 19:06, Richard Barnes wrote: >> >>> >> >>> Hey all, >> >>> >> >>> At the interim last week, there was agreement to remove the >> discussion of ART from the protocol draft and focus on TreeKEM. I have >> implemented that change in the following pull request: >> >>> >> >>> https://github.com/mlswg/mls-protocol/pull/66 >> >>> >> >> >> >> I'm not objecting to the change - I lack sufficient cryptographic >> knowledge to express an opinion - but it'd be very useful to read a >> synopsis of the reasoning behind it, and a summary of the discussion. I >> imagine future participants would find it useful too, and of course, all >> decisions need to go by the list anyway. >> > >> > >> > To recap the discussions at the interim, I think the reasons are >> basically as follows, in descending order of importance: >> > >> > 1. ART requires each recipient of a message to do O(log N) DH >> operations, where as TreeKEM only requires O(1). This is a significant >> difference for large groups / small devices. >> > 2. TreeKEM offers the possibility of doing Add/Remove without double >> join >> > 3. TreeKEM offers the possibility of being able to merge Update messages >> > >> > While I don't think anyone has proved that (2) and (3) aren't possible >> with ART, the fact that it's contributive makes them more difficult. >> > >> > >> >> >> >> I reviewed the PR for clarity/typos. >> >> >> >>> >> >>> If a couple of folks could give a quick review, it would be >> appreciated. I also put together a PR describing how to do the "partial >> tree" approach described at the interim and in my earlier message today. >> >>> >> >>> https://github.com/mlswg/mls-protocol/pull/67 >> >> >> >> >> >> Also reviewed for clarity/typos. I admit I'm mildly confused as to why >> adding a node needs to blank the direct path, but at the same time I'm not >> sure it makes any difference. (That is, here: >> https://github.com/mlswg/mls-protocol/pull/67/commits/7a7cd37aec0ceff773600564b5c9619c3d06a115#diff-a87cc9081154f564150420544170f1c9R1113 >> ). That's probably just my lack of understanding somewhere. >> > >> > >> > The reason is symmetric for Add and Remove. >> > >> > Recall that the invariant property the tree is supposed to have is that >> a node's secret value and private key are only known to the holders of >> leaves below that node in the tree. For both Add and Remove, you need to >> change the intermediate nodes above the target leaf, either to make it so >> that the removed member doesn't know them or so that the added member >> does. The question is what relationship those intermediate nodes have to >> the sender of the Add/Remove -- does the sender know the secret / private >> key or not? >> > >> > On the one hand, if the sender does know the private key, then you have >> a "double join" situation, where the sender knows something he's not >> supposed to. The phrase "double join" arises from the Add case, since the >> relevant intermediate node secrets are known both to the new member and to >> the sender of the Add. Effectively, they both occupy the new member's >> leaf, which complicates things quite a bit. For example, if you now want >> to evict the sender of the Add, you have to also evict the newly added >> leaf, etc. In the Remove case, the main impact of the double-join is that >> you don't have a true Remove operation, you only have a Take-over >> operation. That makes it difficult to imagine how you would ever compact >> the tree. >> > >> > On the other hand, if the sender doesn't know the private key, then the >> node has to be blank.. In the Add case, there's no way (AFAIK) to set the >> intermediate node values to something that is known to (a) the existing >> members under those nodes and (b) the new member, without it also being >> known to the sender of the add. So the values that get decrypted to >> intermediate nodes during the Add are only for the purpose of computing the >> new root secret; the intermediate nodes can't have a non-blank value >> without violating the tree invariant. >> > >> > It may be possible to avoid blanks in the Remove case, but we would >> have to modify TreeKEM. You could still do the "hash to the root" trick to >> generate the fresh shared entropy for the epoch, but you couldn't just >> overwrite the values of the intermediate nodes (as is done now). You would >> have to fold in some entropy only known to the existing members. This is >> probably worth some thought. >> > >> > Anyway, hope that helps, >> > --Richard >> > >> > >> >> >> >> >> >>> >> >>> >> >>> Feedback welcome! >> >>> >> >>> Thanks, >> >>> --Richard >> >>> _______________________________________________ >> >>> 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 >> > --0000000000008bbcaa057781a074 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgot to mention, I updated the PR = to do this:


Also, with this change, you coul= d really do Init as a pile of Adds stapled together, with an Update tacked = on the end if you want.=C2=A0

In a related ve= in, note that if you have a group and all you ever do are Adds and Removes,= then you basically have S/MIME / PGP with a degree of forward secrecy; eve= rything's linear and based on static keys.=C2=A0 Which re-emphasizes th= e point that TreeKEM with partial trees supports a smooth transition from t= hat case to the full-tree, log(N) case.

On Fri, Oct 5, 2018 at 4:53 PM Richard Ba= rnes <rlb@ipv.sx> wrote:
One additional possibly-nice thing here: Adds can O(1) fo= r existing members.

Someone pointed out at the int= erim (I think Cas or Karthik) that in the Add case, there's no need for= the existing members of the group to fold in new entropy into the group se= crets, they just need to hash everything forward.=C2=A0 This means that the= sender of an add doesn't need to encrypt any fresh entropy to the grou= p, and the existing group members don't need to decrypt it.=C2=A0 The m= ember sending the Add just needs to send the init_secret for the group to t= he new member and tell everyone to ratchet forward.

Now, this doesn't mean that Adds are free.=C2=A0 It's just that i= nstead of paying in units of computation to send/process the message, you p= ay in terms of future updates being more expensive, due to the ancestors of= the new member being blanked.=C2=A0 If you have a tree of size N and do M = adds, then the next Update/Remove will involve (log(N)=C2=A0+ log(N) + M) e= ncryptions/ciphertexts in the worst case.=C2=A0 (The extra log(N) comes fro= m existing nodes being blanked out.)

That said= , if the new node updates quickly, then you're back to a whole tree and= only log(N) operations.

--Richard

On Tue, Oct 2, 2018 at = 5:52 AM Cas Cremers <cas.cremers@gmail.com> wrote:
Hi Dave and all,

I would like to add one thing to Richard's explanation of the
rationale for dropping ART in favor of TreeKEM for now:

An important implicit assumption is that TreeKEM doesn't seem to offer<= br> less security guarantees than ART.

However, given that the specification of protocols, threat models, and
properties isn't completely fleshed out, we don't really yet know i= f
this is true in any formal sense.=C2=A0 Analysis is continuing in parallel,=
and we might need to backtrack in the worst case.

This choice is not (and must not be) about efficiency alone.

Best,

Cas

--
https://people.cispa.io/cas.cremers/index.html

On Mon, Oct 1, 2018 at 11:15 PM Richard Barnes <rlb@ipv.sx> wrote: >
>
>
> On Mon, Oct 1, 2018 at 10:34 PM Dave Cridland <dave@cridland.net> wrote:
>>
>>
>>
>> On Mon, 1 Oct 2018 at 19:06, Richard Barnes <rlb@ipv.sx> wro= te:
>>>
>>> Hey all,
>>>
>>> At the interim last week, there was agreement to remove the di= scussion of ART from the protocol draft and focus on TreeKEM.=C2=A0 I have = implemented that change in the following pull request:
>>>
>>> https://github.com/mlswg/mls-protocol/pul= l/66
>>>
>>
>> I'm not objecting to the change - I lack sufficient cryptograp= hic knowledge to express an opinion - but it'd be very useful to read a= synopsis of the reasoning behind it, and a summary of the discussion. I im= agine future participants would find it useful too, and of course, all deci= sions need to go by the list anyway.
>
>
> To recap the discussions at the interim, I think the reasons are basic= ally as follows, in descending order of importance:
>
> 1. ART requires each recipient of a message to do O(log N) DH operatio= ns, where as TreeKEM only requires O(1).=C2=A0 This is a significant differ= ence for large groups / small devices.
> 2. TreeKEM offers the possibility of doing Add/Remove without double j= oin
> 3. TreeKEM offers the possibility of being able to merge Update messag= es
>
> While I don't think anyone has proved that (2) and (3) aren't = possible with ART, the fact that it's contributive makes them more diff= icult.
>
>
>>
>> I reviewed the PR for clarity/typos.
>>
>>>
>>> If a couple of folks could give a quick review, it would be ap= preciated.=C2=A0 I also put together a PR describing how to do the "pa= rtial tree" approach described at the interim and in my earlier messag= e today.
>>>
>>> https://github.com/mlswg/mls-protocol/pul= l/67
>>
>>
>> Also reviewed for clarity/typos. I admit I'm mildly confused a= s to why adding a node needs to blank the direct path, but at the same time= I'm not sure it makes any difference. (That is, here: https://github.com/mlswg/mls-protocol/pull/67/commits/= 7a7cd37aec0ceff773600564b5c9619c3d06a115#diff-a87cc9081154f564150420544170f= 1c9R1113 ). That's probably just my lack of understanding somewhere= .
>
>
> The reason is symmetric for Add and Remove.
>
> Recall that the invariant property the tree is supposed to have is tha= t a node's secret value and private key are only known to the holders o= f leaves below that node in the tree.=C2=A0 For both Add and Remove, you ne= ed to change the intermediate nodes above the target leaf, either to make i= t so that the removed member doesn't know them or so that the added mem= ber does.=C2=A0 The question is what relationship those intermediate nodes = have to the sender of the Add/Remove -- does the sender know the secret / p= rivate key or not?
>
> On the one hand, if the sender does know the private key, then you hav= e a "double join" situation, where the sender knows something he&= #39;s not supposed to.=C2=A0 The phrase "double join" arises from= the Add case, since the relevant intermediate node secrets are known both = to the new member and to the sender of the Add.=C2=A0 Effectively, they bot= h occupy the new member's leaf, which complicates things quite a bit.= =C2=A0 For example, if you now want to evict the sender of the Add, you hav= e to also evict the newly added leaf, etc.=C2=A0 In the Remove case, the ma= in impact of the double-join is that you don't have a true Remove opera= tion, you only have a Take-over operation.=C2=A0 That makes it difficult to= imagine how you would ever compact the tree.
>
> On the other hand, if the sender doesn't know the private key, the= n the node has to be blank..=C2=A0 In the Add case, there's no way (AFA= IK) to set the intermediate node values to something that is known to (a) t= he existing members under those nodes and (b) the new member, without it al= so being known to the sender of the add.=C2=A0 So the values that get decry= pted to intermediate nodes during the Add are only for the purpose of compu= ting the new root secret; the intermediate nodes can't have a non-blank= value without violating the tree invariant.
>
> It may be possible to avoid blanks in the Remove case, but we would ha= ve to modify TreeKEM.=C2=A0 You could still do the "hash to the root&q= uot; trick to generate the fresh shared entropy for the epoch, but you coul= dn't just overwrite the values of the intermediate nodes (as is done no= w).=C2=A0 You would have to fold in some entropy only known to the existing= members.=C2=A0 This is probably worth some thought.
>
> Anyway, hope that helps,
> --Richard
>
>
>>
>>
>>>
>>>
>>> Feedback welcome!
>>>
>>> Thanks,
>>> --Richard
>>> _______________________________________________
>>> MLS mailing list
>>> MLS@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/mls<= br> >
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
--0000000000008bbcaa057781a074-- From nobody Thu Oct 11 08:39:23 2018 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 C8F7C130E7C for ; Thu, 11 Oct 2018 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwY28y4UacTU for ; Thu, 11 Oct 2018 08:39:20 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 BC35F130DE6 for ; Thu, 11 Oct 2018 08:39:19 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id a85-v6so5715550qkg.3 for ; Thu, 11 Oct 2018 08:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=XRKFtPEg0XQZFhd0hk2GNEsQbUVAyk7692ql3s+Tfiw=; b=AfZX+/BXAvNjS5N6oDw1mxhqDCQP5aKuiLltxbu07VQDR1OHKxB9Ah1RZ9OJCl7ZjH SMElfFDGMD49P2gA/vEbrefINPSP7vzgtZ0G91zjOznAVyrdFUULNUEjxjbcCqG/JRBz JHkTb1aQx20DI/p7CNj2BJyh9SKWzz/CbQF3U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=XRKFtPEg0XQZFhd0hk2GNEsQbUVAyk7692ql3s+Tfiw=; b=VKavmoE+d4r0vg0PhRIlnGemRywW1Pq6veejnGR4xtq7Ri4azexaj0k40T3uvT0hZp wOBtGBq393J9qbe6bE1JcPfewkLmdqcxEA0UVThV8HOazO96ZbU2FysJMk4+9XyfOgwa j/tAyfFirAys/QuRgekm9ddykJ8XLYR/cqt37NBa36bMtM90GLeJuYySADXA82lfWH1K Hzen2Flb9LP3laCtICGyRECa9cr+iG0Z8bpmCEho/PQbHAXEY0HRSw64XnBIA5n9wFYC fo8HkiGlPkbMBUDgjEgsaGfERhwMxPC5qZMMTIk4vubRgVhxgDHHH6P0OA64ErTRN5NC sI4g== X-Gm-Message-State: ABuFfoidwogmfYfWnz9wtr34bAjQ5rFrDUYUBTaMnVYfeFggqa5i4zs7 XewXJvHO4vxR9St/iepfMOoycQc6g9U= X-Google-Smtp-Source: ACcGV61rdyEkL4vLWyUN51Gr3JE+MMk9unIer5JqgmDuVZV/iEyKnu1UK0OnZp5ycOKYQJqbGfFW5w== X-Received: by 2002:a37:9941:: with SMTP id b62-v6mr1926695qke.53.1539272358741; Thu, 11 Oct 2018 08:39:18 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id o55-v6sm16238542qtk.58.2018.10.11.08.39.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 08:39:17 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <6988C8A0-1324-431A-9FD1-579D180CF21C@sn3rd.com> Date: Thu, 11 Oct 2018 11:39:15 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] MLS Interim 27-28 September 2018: minutes 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, 11 Oct 2018 15:39:22 -0000 The minutes are now up at: https://datatracker.ietf.org/wg/mls/meetings/ and in the gh repo: https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/minutes.md Cheers, spt From nobody Fri Oct 12 09:43:44 2018 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 641EE130E37 for ; Fri, 12 Oct 2018 09:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofUOrpnhYou1 for ; Fri, 12 Oct 2018 09:43:40 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33728130DF7 for ; Fri, 12 Oct 2018 09:43:40 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id d14-v6so14512357qto.4 for ; Fri, 12 Oct 2018 09:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=uzHTaqaYJBltOYf+SnJHOznccnmfyjH+KsSDoqrLF8I=; b=XTJsPuIoulUB2psjpA8/CXoBVi3gZrpAbtG9RMnAH1biV5S/POnjP1q0XtNCvrtqHx SNnD5Njv/Szxh4uI8zVf9D/Bsp63O1IzDbgn209MJKLK5WK3vzZfIme1FEhbZaDHQBUY v6WvJZhOkeTfE7NgXrL0gvlWgUxc2A12forNc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=uzHTaqaYJBltOYf+SnJHOznccnmfyjH+KsSDoqrLF8I=; b=mrabv3kP0jT9Z4lN6daLo6PdQTDZmfLniORF+7JaII+l4bbvs33/hjgquhpupZvBfd oAp9SP80bcrbFn3QV9GqcxBRdNGZ6xIxxlRenSmg15MXETFsxakeQR49DoJjfcyEqPeo 5IQwISnPFaJpS/y+e+3KnHzlhK/kCJ7ITxt6f0DyavqpBMjj6QwJxFsdc44vRn/aMkLV FLEPEidUCgT/kDi2fkKB8ywYKnP96gc0p4T3refOfXFWM9mW9U9oEr+3RT/Pn7qaZ5Rx QgMve3F/V91XVvM0VMq/yGUDGpulqG1nD2pzhCqfflsTM8ndd5tuNUjZ//6KcRitLILc ceZA== X-Gm-Message-State: ABuFfoj5vmiPTv+1OpmGdpLfOVLKIfXUAoUa0kJ20j+wo/DDI7UccXsv a1yv86bBuXRq3YIA7Ru/KDxGc7eL4QQ= X-Google-Smtp-Source: ACcGV60SO0TgRaZlq6h2Wj2GAs5e8U59ZIZ0xXJ1n7hOBBmHjCxXy9LaT55NyFhoyIAi8lx1tlwsvA== X-Received: by 2002:ac8:185d:: with SMTP id n29-v6mr6370852qtk.10.1539362619214; Fri, 12 Oct 2018 09:43:39 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id i79-v6sm1022573qke.17.2018.10.12.09.43.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 09:43:37 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 12 Oct 2018 12:43:36 -0400 References: <6988C8A0-1324-431A-9FD1-579D180CF21C@sn3rd.com> To: mls@ietf.org In-Reply-To: <6988C8A0-1324-431A-9FD1-579D180CF21C@sn3rd.com> Message-Id: <540A722D-F28C-421C-B428-74807BDFC9C9@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] MLS Interim 27-28 September 2018: minutes X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:43:43 -0000 I should have included my thanks to Katriel and Benjamin for taking = notes. spt > On Oct 11, 2018, at 11:39, Sean Turner wrote: >=20 > The minutes are now up at: > https://datatracker.ietf.org/wg/mls/meetings/ > and in the gh repo: > = https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/minutes.= md >=20 > Cheers, >=20 > spt From nobody Fri Oct 12 11:19:58 2018 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 AF2F4130E72 for ; Fri, 12 Oct 2018 11:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symbolic.software 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 67Zhg2bHewLK for ; Fri, 12 Oct 2018 11:19:52 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 8828B130E4F for ; Fri, 12 Oct 2018 11:19:52 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id z25-v6so18566300wmf.1 for ; Fri, 12 Oct 2018 11:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JC3yRUMK/J8MMhBfpmMnRUI8aZSHn+gF74KNj8Tzqzg=; b=aqR3/S9Mx+LmO+RtuVwc9y6tl26NCSnUOxvsZOVGc06BPIyMeys69okFvgOekhf44+ soE35gec4+fBUvntiorma2sSGYVT72vhyqJ0RrxS2hy4SUW2z4zT1Mur9TCgiis3P6zG QG0il4Sr0qPNPSgrOXHzAiGmbiUrVZ/x4KQQY= 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=JC3yRUMK/J8MMhBfpmMnRUI8aZSHn+gF74KNj8Tzqzg=; b=SHAt1EHV6KgdJuuKqn5zNannsZwrNzdheHj4Rub2Nq31Gct+l30pJTL2HRWdrki+Hn Mruufh922e8uMyWkAXwL4S8NNeQ/l/m6q8+hl9UgqgLb9i+g8smzkw17OPGIL8ia1w/e 7vDbVgXOV2UrpFCDGRJZwKpt68sInWqnuwgoTDblD0VC/97bUZZxFLhNz+BqkyV8NvMb fxGYgFP3ClCQb7xXrfFu4jjJOTZsXEJxngB4du4pwxuo/ASCbc6ZCvX58rkcMt+sp3x8 DB16nPIsx1NS+GfIFwFhCv4EoAyYR0Z85v7sObi7c8xe76F6ZYs3ZOJA+uolvUhp724v 19dA== X-Gm-Message-State: ABuFfohY9eoQu4FmRGVThWUjGhPORzzI0H30k3JfcpdQQXD1ApbPcSxo GZLZwNcWaSkltZ9KyDCG0KT64/IhtlHwHw== X-Google-Smtp-Source: ACcGV63N4ufk6gyPVq0T8itMnbIHPNX4CRE+Pp7mK1f93e6DgSd+slPEhfXOHrrrUzVJoIYuVzXdTw== X-Received: by 2002:a1c:9051:: with SMTP id s78-v6mr6033681wmd.10.1539368390473; Fri, 12 Oct 2018 11:19:50 -0700 (PDT) Received: from [192.168.1.35] (LFbn-1-472-13.w86-245.abo.wanadoo.fr. [86.245.179.13]) by smtp.gmail.com with ESMTPSA id t24-v6sm1989337wra.5.2018.10.12.11.19.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 11:19:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Nadim Kobeissi X-Mailer: iPhone Mail (16A405) In-Reply-To: <6988C8A0-1324-431A-9FD1-579D180CF21C@sn3rd.com> Date: Fri, 12 Oct 2018 20:19:48 +0200 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F61CBAD-A9E6-48B2-8D08-1926F976176E@symbolic.software> References: <6988C8A0-1324-431A-9FD1-579D180CF21C@sn3rd.com> To: Sean Turner Archived-At: Subject: Re: [MLS] MLS Interim 27-28 September 2018: minutes X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 18:19:56 -0000 Thanks for the minutes. It=E2=80=99s a shame that the discussion regarding whether the current focus= message protection gives to per-message forward secrecy was glossed over in= the minutes like this. I remember making an effort to convincingly illustra= te exactly how this isn=E2=80=99t worth it given how many keys will need to b= e stored locally. Having epoch-level forward secrecy will result in simpler specs, stronger ef= ficiency and reliability without a real compromise in real-word forward secr= ecy in the event of device compromise. There are also some implementation-level discussions that seem to be complet= ely missing. Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from my iPhone > On Oct 11, 2018, at 5:39 PM, Sean Turner wrote: >=20 > The minutes are now up at: > https://datatracker.ietf.org/wg/mls/meetings/ > and in the gh repo: > https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/minutes.= md >=20 > Cheers, >=20 > spt >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Oct 12 12:46:58 2018 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 7F0EA130E89 for ; Fri, 12 Oct 2018 12:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symbolic.software 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 LhjcYa_z-gsI for ; Fri, 12 Oct 2018 12:46:53 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 101631286E3 for ; Fri, 12 Oct 2018 12:46:53 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id z204-v6so14001316wmc.5 for ; Fri, 12 Oct 2018 12:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=mime-version:from:date:message-id:subject:to; bh=SU5nV61COy4NOO7CJSewl4aTzfIZLYDmSVuyjwHOJNU=; b=ilgg5XefcWOmgsg3BSwddXZTjtiwrYUcETzMDyZ4B+2AwYCdFKP5aGPbUu2kMcI6KA ysnzQ/XWDT/UFD93FHCzUViTpMiL5nMt1GZAUXhriZzvRHF9Vbuo44B9cREqUJKPfZk7 gpGPT64u/kV4qA8S8WbYUZxXRj3Izp9jV7aVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SU5nV61COy4NOO7CJSewl4aTzfIZLYDmSVuyjwHOJNU=; b=Sx7CEiPslBLx2Cew5XN1FwaEQD3JO0Sc3Iopvd0BXGSramiDOczD4kVvZLFpUCpZP4 ANOZrDPa2IuoBzCVV7EuKDaRZrXWTGiddr7MRgyph3vJ8FFo9XHdrxCVnDAsy3a3B+zK 1XQhAKAJrEd1/i/9uzAiUEm7aRjendppdqODgj8EXDzyHjO6yM8NmUefqV3FPdbcS5p5 2qhS6b1zQ4KT2xvaUaXcfT3dH726Q+EoFg6ZGAzcumsQ3GK/3L8Pb4its6axUJobqswR hFRQD10N4zC1/mtuCpP+ClNLzk4NEucjcixsPWzH1qmQ+0uZzwpA688GqRBZkV2oQPKP H7fg== X-Gm-Message-State: ABuFfohzNZSfm8piSLjpca0dQ9WD8Q2aYfLp2DdT960l8d3MvoOfXtST YSL1RLDeax4dT+czaUrq2qiI0p/695IAcGra7B9lIAjF5/xF/Q== X-Google-Smtp-Source: ACcGV60pJiVe7SijiVZZfoG05tH7XN9St1W2oGBx8CZPl6aoQu0LAlKz19vcZ6ggIUlbp4IJP233R4NeO8Skq9O6Sik= X-Received: by 2002:a1c:e5cf:: with SMTP id c198-v6mr6220707wmh.113.1539373610847; Fri, 12 Oct 2018 12:46:50 -0700 (PDT) MIME-Version: 1.0 From: Nadim Kobeissi Date: Fri, 12 Oct 2018 21:46:41 +0200 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000040669605780d59a6" Archived-At: Subject: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:46:56 -0000 --00000000000040669605780d59a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, I've been working on adapting Hierarchical Key Derivation (HKD) in order to obtain some kind of ephemeral signatures that may be useful in MLS. I've arrived at a point where I'm optimistic that this is a direction worth pursuing and might indeed be a solution to this problem. HKD was at some point a candidate for how signature keys are managed per epoch in the Tor Hidden Service design [0]. HKD logic has also been implemented in Bitcoin wallets for a while now [1]. HKD constructions can be also derived from existing popular fast signature algorithms such as Ed25519 with minimal changes [2], making them an easy fit for MLS. Very simply, the functionality that HKD signature schemes bring to MLS is the following: - Alice sends a public signing key to Bob during epoch n. - At the onset of epoch n+1, Bob is able to immediately calculate Alice's public signing key for epoch n+1 based purely on his knowledge o= f Alice's public signing key for epoch 0. Alice doesn't need to send new signing key information to Bob. - At this point, Bob can delete Alice's public signing key for epoch n. - More importantly, Alice herself can delete Alice's private signing key for epoch n, keeping only her private signing key for epoch n+1. The way that this could work in MLS would be heavily based on HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead will point out the relevant sections (which are short, well-written and worth reading:) - Section 2 describes the original concept as used for Bitcoin wallet derivation. - Section 4 describes the modifications to Ed25519 to enable HKD constructions. - Section 5 describes how private and public child keys are generated (Fig. 1 is also helpful.) My questions: - How are we deriving epoch identifiers? Are they simply counters, or each epoch identified by a nonce that's communicated confidentially? If = you read [2], you'll see why this can be important. - Performance impact seems to be negligible for Montgomery-based signing primitives, but I'm interested in more insight on this. - Is anyone else interested in having a standard HDKeys-Ed25519 implementation? I've been working on one in JavaScript an= d plan to eventually also write one in Go. Perhaps Richard would like to h= elp with a C++ version? - I'm also interested in hearing your thoughts on this generally. During the interim meeting (as well as before it), it was frequently discussed how ephemeral signatures may be useful for MLS. This also appears to be slated as a discussion topic for IETF 103, so it would be great if we could continue the discussion there as well. References: [0] https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t= xt#n1979 [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office --00000000000040669605780d59a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

I've been= working on adapting Hierarchical Key Derivation (HKD) in order to obtain s= ome kind of ephemeral signatures that may be useful in MLS. I've arrive= d at a point where I'm optimistic that this is a direction worth pursui= ng and might indeed be a solution to this problem.

HKD was at some point a candidate for how signature keys are managed per e= poch in the Tor Hidden Service design [0]. HKD logic has also been implemen= ted in Bitcoin wallets for a while now [1]. HKD constructions can be also d= erived from existing popular fast signature algorithms such as Ed25519 with= minimal changes [2], making them an easy fit for MLS. Very simply, the fun= ctionality that HKD signature schemes bring to MLS is the following:
<= div>
  • Alice sends a public signing key to Bob during epoch n.
  • At the onset of epoch n+1, Bob is able to immediately calculate Alice&= #39;s public signing key for epoch n+1 based purely on his knowledge of Ali= ce's public signing key for epoch 0. Alice doesn't need to send new= signing key information to Bob.
  • At this point, Bob can delete Alic= e's public signing key for epoch n.
  • More importantly, Alice her= self can delete Alice's private signing key for epoch n, keeping only h= er private signing key for epoch n+1.
The way that this could= work in MLS would be heavily based on HDKeys-Ed25519 [2]. I'll resist = paraphrasing the paper, and instead will point out the relevant sections (w= hich are short, well-written and worth reading:)
  • Se= ction 2 describes the original concept as used for Bitcoin wallet derivatio= n.
  • Section 4 describes the modifications to Ed25519 to enable HKD c= onstructions.
  • Section 5 describes how private and public child keys= are generated (Fig. 1 is also helpful.)
My questions:<= /div>
  • How are we deriving epoch identifiers? Are they simply co= unters, or each epoch identified by a nonce that's communicated confide= ntially? If you read [2], you'll see why this can be important.
    • Performance impact seems to be negligible for Montgomery-based signing pri= mitives, but I'm interested in more insight on this.
  • Is anyone = else interested in having a standard HDKeys-Ed25519=C2=A0implementation? I&= #39;ve been working on one in JavaScript and plan to eventually also write = one in Go. Perhaps Richard would like to help with a C++ version?
  • I= 'm also interested in hearing your thoughts on this generally.
During the interim meeting (as well as before it), it was frequ= ently discussed how ephemeral signatures may be useful for MLS. This also a= ppears to be slated as a discussion topic for IETF 103, so it would be grea= t if we could continue the discussion there as well.=C2=A0

=
References:
=

Nadim Kobeissi
Symbolic Sof= tware=C2=A0=E2=80=A2 https://symbolic.soft= ware
Sent from office
<= /div>
--00000000000040669605780d59a6-- From nobody Fri Oct 12 13:04:03 2018 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 3D182126DBF for ; Fri, 12 Oct 2018 13:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 obZ06hNS20bP for ; Fri, 12 Oct 2018 13:03:59 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 07FDD130E8F for ; Fri, 12 Oct 2018 13:03:58 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id l1so13489188otj.5 for ; Fri, 12 Oct 2018 13:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SvD+3DBkKiVrahYsO5HVrSC9bxuq7S6vKSrYNLV0Xgw=; b=cLqK+L9D8jl+AJ0ImfRIBZC9xNWUkv8RNx1F/az0EjS6rBA9qqiYLLcpWq8w1n4TVk BW9OAHjczASqeQmB/mSnZI7CdrGsL6zySTqlYYD3+tDQIrxkTJadgN2xoEyeLDEzvs+3 vVEWtjKaDG63lzTsUwNlS36Phkw3PyJNaAjSETR8UfVx3c8ye7XVvkAcifwG/J7uqguk zkjFztqH5X95LYATEGSY/Ft+dy1/9GVQ9WSRjAR7Kbqf3LBcGtXgVHdqHjucM/JBfMt4 sWj6HNF36GJHjw9ATd7j6UhkNgeEG8kNOdBVHSdEcRvQt2kYseX/cacQfRangV1U6Kx1 fyzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SvD+3DBkKiVrahYsO5HVrSC9bxuq7S6vKSrYNLV0Xgw=; b=SqRPMPfA4f0QfkVzSgGNvdjQmhiuhbDx7GjDGemcN1j9XteKITPeYGkxwpvb8qO4gr Pfxww5ro6DI9sbHb8/699brta0AhT2N3w5Bz4BMhG8pB6T26VbBzn1HWDSL3mp4zusHn kh7QpYXxC2N3606SFKuTGjp5OeOJT0tTaT/kelZkcc2MhWcwbkMILIlSYjPEPe1VC7zx 39kgrwha78fdnedeBdVEuxOmsqL5qf27kAaGpr0LCCyb6WsItphlxGZJ4AMrUIw6aesJ /vCYpxKsO+6kAM7lUdbnAP9d+JyrWrIm+MInBA6F3F63nl4OJtQmrTqxGUnWwfyZQWQC NfsQ== X-Gm-Message-State: ABuFfohWME2y0XTrPRIB6uwaXLZRqe3pG1wfYoMWZ2OYqr0fbjcBRTDM yEKLePDB6KNHsbRiZ0lH/iPdeQD3OX2l3u4OyOLXnb1W X-Google-Smtp-Source: ACcGV62vlvQAfqrTIi6EakG4+2c+m45WuaINMuiG7GsJ1y+MXxbPi2HRVa81x/qzHu0DPPIItsqKMN/SV7FeJ3q6AxI= X-Received: by 2002:a9d:2af:: with SMTP id 44-v6mr4458417otl.244.1539374636774; Fri, 12 Oct 2018 13:03:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Fri, 12 Oct 2018 13:03:29 -0700 Message-ID: To: nadim@symbolic.software Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000066bbfb05780d96ea" Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 20:04:02 -0000 --00000000000066bbfb05780d96ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nadim, I suspect I'm missing something simple here in your proposal. According to your reference 2, one of the issues with the derivation of this type of hierarchical key is: that knowledge of a parent extended public key plus any non-hardened > private key descending from it is equivalent to knowing the parent extend= ed > private key (and thus every private and public key descending from it). > This means that extended public keys must be treated more carefully than > regular public keys. It is also the reason for the existence of hardened > keys, and why they are used for the account level in the tree. This way, = a > leak of account-specific (or below) private key never risks compromising > the master or other accounts. > What I think that means is that if an attacker ever gets access to both an extended public key and any extended private key, we have lost forward secrecy for all the MLS communications covered by any keys derived from any of the epoch pairs. Is that correct? This appears to make handling required of the parent extended public key roughly equivalent to the handling of a private key, so that your step: Alice sends a public signing key to Bob during epoch n. means that Alice must refrain from ever using the parent extended public key has a signing key, but must instantiate signing keys from the n + 0 epoch. Is that a correct understanding? Thanks, Ted On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi wrote: > Hello everyone, > > I've been working on adapting Hierarchical Key Derivation (HKD) in order > to obtain some kind of ephemeral signatures that may be useful in MLS. I'= ve > arrived at a point where I'm optimistic that this is a direction worth > pursuing and might indeed be a solution to this problem. > > HKD was at some point a candidate for how signature keys are managed per > epoch in the Tor Hidden Service design [0]. HKD logic has also been > implemented in Bitcoin wallets for a while now [1]. HKD constructions can > be also derived from existing popular fast signature algorithms such as > Ed25519 with minimal changes [2], making them an easy fit for MLS. Very > simply, the functionality that HKD signature schemes bring to MLS is the > following: > > - Alice sends a public signing key to Bob during epoch n. > - At the onset of epoch n+1, Bob is able to immediately calculate > Alice's public signing key for epoch n+1 based purely on his knowledge= of > Alice's public signing key for epoch 0. Alice doesn't need to send new > signing key information to Bob. > - At this point, Bob can delete Alice's public signing key for epoch n= . > - More importantly, Alice herself can delete Alice's private signing > key for epoch n, keeping only her private signing key for epoch n+1. > > The way that this could work in MLS would be heavily based on > HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead will > point out the relevant sections (which are short, well-written and worth > reading:) > > - Section 2 describes the original concept as used for Bitcoin wallet > derivation. > - Section 4 describes the modifications to Ed25519 to enable HKD > constructions. > - Section 5 describes how private and public child keys are generated > (Fig. 1 is also helpful.) > > My questions: > > - How are we deriving epoch identifiers? Are they simply counters, or > each epoch identified by a nonce that's communicated confidentially? I= f you > read [2], you'll see why this can be important. > - Performance impact seems to be negligible for Montgomery-based > signing primitives, but I'm interested in more insight on this. > - Is anyone else interested in having a standard > HDKeys-Ed25519 implementation? I've been working on one in JavaScript = and > plan to eventually also write one in Go. Perhaps Richard would like to= help > with a C++ version? > - I'm also interested in hearing your thoughts on this generally. > > During the interim meeting (as well as before it), it was frequently > discussed how ephemeral signatures may be useful for MLS. This also appea= rs > to be slated as a discussion topic for IETF 103, so it would be great if = we > could continue the discussion there as well. > > References: > [0] > https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng= .txt#n1979 > [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki > [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf > > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software > Sent from office > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000066bbfb05780d96ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nadim,

I suspect I'm = missing something simple here in your proposal.=C2=A0 According to your ref= erence 2, one of the issues with the derivation of this type of hierarchica= l key is:

=C2=A0that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and=20 thus every private and public key descending from it). This means that=20 extended public keys must be treated more carefully than regular public=20 keys. It is also the reason for the existence of hardened keys, and why they=20 are used for the account level in the tree. This way, a leak of=20 account-specific (or below) private key never risks compromising the=20 master or other accounts.

What I thin= k that means is that if an attacker ever gets access to both an extended pu= blic key and any extended private key, we have lost forward secrecy for all= the MLS communications covered by any keys derived from any of the epoch p= airs.=C2=A0 Is that correct?

This appears to make = handling required of the parent extended public key roughly equivalent to t= he handling of a private key, so that your step:

A= lice sends a public signing key to Bob during epoch n.

=
means that Alice must refrain from ever using the parent extended publ= ic key has a signing key, but must instantiate signing keys from the n + 0 = epoch.=C2=A0

Is that a correct understanding?=

Thanks,

Ted


= On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi <nadim@symbolic.software= > wrote:
Hello everyone,

I've been working on adapting Hi= erarchical Key Derivation (HKD) in order to obtain some kind of ephemeral s= ignatures that may be useful in MLS. I've arrived at a point where I= 9;m optimistic that this is a direction worth pursuing and might indeed be = a solution to this problem.

HKD was at some point = a candidate for how signature keys are managed per epoch in the Tor Hidden = Service design [0]. HKD logic has also been implemented in Bitcoin wallets = for a while now [1]. HKD constructions can be also derived from existing po= pular fast signature algorithms such as Ed25519 with minimal changes [2], m= aking them an easy fit for MLS. Very simply, the functionality that HKD sig= nature schemes bring to MLS is the following:
  • Alice sends= a public signing key to Bob during epoch n.
  • At the onset of ep= och n+1, Bob is able to immediately calculate Alice's public signing ke= y for epoch n+1 based purely on his knowledge of Alice's public signing= key for epoch 0. Alice doesn't need to send new signing key informatio= n to Bob.
  • At this point, Bob can delete Alice's public signing = key for epoch n.
  • More importantly, Alice herself can delete Alice&#= 39;s private signing key for epoch n, keeping only her private signing key = for epoch n+1.
The way that this could work in MLS would be h= eavily based on HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper,= and instead will point out the relevant sections (which are short, well-wr= itten and worth reading:)
  • Section 2 describes the o= riginal concept as used for Bitcoin wallet derivation.
  • Section 4 de= scribes the modifications to Ed25519 to enable HKD constructions.
  • S= ection 5 describes how private and public child keys are generated (Fig. 1 = is also helpful.)
My questions:
  • How a= re we deriving epoch identifiers? Are they simply counters, or each epoch i= dentified by a nonce that's communicated confidentially? If you read [2= ], you'll see why this can be important.
  • Performance impact see= ms to be negligible for Montgomery-based signing primitives, but I'm in= terested in more insight on this.
  • Is anyone else interested in havi= ng a standard HDKeys-Ed25519=C2=A0implementation? I've been working on = one in JavaScript and plan to eventually also write one in Go. Perhaps Rich= ard would like to help with a C++ version?
  • I'm also interested = in hearing your thoughts on this generally.
During the = interim meeting (as well as before it), it was frequently discussed how eph= emeral signatures may be useful for MLS. This also appears to be slated as = a discussion topic for IETF 103, so it would be great if we could continue = the discussion there as well.=C2=A0
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000066bbfb05780d96ea-- From nobody Fri Oct 12 13:22:19 2018 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 9FFA6130E78 for ; Fri, 12 Oct 2018 13:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symbolic.software 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 FIEFXrXu9Zci for ; Fri, 12 Oct 2018 13:22:14 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 47B4D126DBF for ; Fri, 12 Oct 2018 13:22:14 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id 61-v6so14690882wrb.6 for ; Fri, 12 Oct 2018 13:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OOz6MJg5r7nNI88g5qSBAoGJQYSYodjkvGnLDYbfjsg=; b=gsHVgNsxZsZuLubMNFdS38w1B7B0LtJikK+2NNW+tkXJ3PMseO+aOcgFnem1BDL+f3 zNajoHZ/2CQEP1PW8GAohchoEbcVEHZFFnnoavjp6BhV9+X+WZ0Dg57BJICFMo+uV06i t3mdUDFrxe7k01T27o4ForOogLbISmTQ13Ud0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OOz6MJg5r7nNI88g5qSBAoGJQYSYodjkvGnLDYbfjsg=; b=lnPToVSE2Ttr8AA13wFd6fJ19LNZJl6Tu2tXuZE/JmaoS7KzddGiT9K6O6qqzZHNRj Sr9D7b0NTbwKhHxT1/qFRWHTGwpLgBfu26UIPnsPDT9XZfnIy/BfGPk3eqXTtl+niGoT i1n7f6npK/l/myu5w2XHIQgx9YB+q/CWbtnWSlzmNm8Z5sYVIyJGsE4a013xAt4Snbz5 zHovHEpl4VuZBdh1YllB7rt6q+7gJUlPO65iS9dAm/PlzSNAsuiXiPKnhYMDrwF+1/Q3 zOZZ3MCd0FjsSLnplIVKHKBEgHrbr26ec5HxOOMikFRPYwyAdz7BokPn8FYJNVOofUGu flKg== X-Gm-Message-State: ABuFfogRRFo0J0TsG8kNi4NTdk3dz/1jlefjJa6x0hDfOJ2+a6MUQA5b TTj9fZkzwXWoJTtOjgaEuFxXkkcCqFAHf+U6cF5b7w== X-Google-Smtp-Source: ACcGV60OJYk3Sv0jvWVNjtc+CUWf3vJKooSlt8y/1IEyI9dA45hlBbBD8UPKqIRAnJMzYY0fHAQwqtbsu/JkW3nU/B4= X-Received: by 2002:adf:c6c7:: with SMTP id c7-v6mr6838562wrh.243.1539375732554; Fri, 12 Oct 2018 13:22:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nadim Kobeissi Date: Fri, 12 Oct 2018 22:22:02 +0200 Message-ID: To: ted.ietf@gmail.com Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000b7176d05780dd7b3" Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 20:22:18 -0000 --000000000000b7176d05780dd7b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Ted, Thanks for your quick read-through! You seem to be referring to [1], not to [2] as you wrote. In [1], the concept of "hardened" keys is defined and is also ported by [2] into Ed25519. > What I think that means is that if an attacker ever gets access to both an extended public key and any extended private key, we have lost forward secrecy for all the MLS communications covered by any keys derived from any of the epoch pairs. Is that correct? This is correct in the sense that it allows you to rewind the key derivation chain. However, this does not apply to hardened keys. This is precisely why I'm trying to understand how epoch identifiers are agreed upon, in order to see whether we can use them to restrict the HKD logic to use only "hardened" keys in MLS. Since hardened keys in [2] cannot themselves have children, it becomes important to understand whether we can select enough of them for an HKD design in MLS to have a meaningful impact, and how this selection/potential caching of hardened keys would work. > [...] means that Alice must refrain from ever using the parent extended public key has a signing key, but must instantiate signing keys from the n + 0 epoch. This could also be a solution, I suppose, but it sounds like it would result in weaker "signing forward secrecy" (or whatever we're calling this property) than focusing on hardened keys, although I'm frankly not sure off the top of my head. Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie wrote: > Hi Nadim, > > I suspect I'm missing something simple here in your proposal. According > to your reference 2, one of the issues with the derivation of this type o= f > hierarchical key is: > > that knowledge of a parent extended public key plus any non-hardened >> private key descending from it is equivalent to knowing the parent exten= ded >> private key (and thus every private and public key descending from it). >> This means that extended public keys must be treated more carefully than >> regular public keys. It is also the reason for the existence of hardened >> keys, and why they are used for the account level in the tree. This way,= a >> leak of account-specific (or below) private key never risks compromising >> the master or other accounts. >> > > What I think that means is that if an attacker ever gets access to both a= n > extended public key and any extended private key, we have lost forward > secrecy for all the MLS communications covered by any keys derived from a= ny > of the epoch pairs. Is that correct? > > This appears to make handling required of the parent extended public key > roughly equivalent to the handling of a private key, so that your step: > > Alice sends a public signing key to Bob during epoch n. > > means that Alice must refrain from ever using the parent extended public > key has a signing key, but must instantiate signing keys from the n + 0 > epoch. > > Is that a correct understanding? > > Thanks, > > Ted > > > On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi > wrote: > >> Hello everyone, >> >> I've been working on adapting Hierarchical Key Derivation (HKD) in order >> to obtain some kind of ephemeral signatures that may be useful in MLS. I= 've >> arrived at a point where I'm optimistic that this is a direction worth >> pursuing and might indeed be a solution to this problem. >> >> HKD was at some point a candidate for how signature keys are managed per >> epoch in the Tor Hidden Service design [0]. HKD logic has also been >> implemented in Bitcoin wallets for a while now [1]. HKD constructions ca= n >> be also derived from existing popular fast signature algorithms such as >> Ed25519 with minimal changes [2], making them an easy fit for MLS. Very >> simply, the functionality that HKD signature schemes bring to MLS is the >> following: >> >> - Alice sends a public signing key to Bob during epoch n. >> - At the onset of epoch n+1, Bob is able to immediately calculate >> Alice's public signing key for epoch n+1 based purely on his knowledg= e of >> Alice's public signing key for epoch 0. Alice doesn't need to send ne= w >> signing key information to Bob. >> - At this point, Bob can delete Alice's public signing key for epoch >> n. >> - More importantly, Alice herself can delete Alice's private signing >> key for epoch n, keeping only her private signing key for epoch n+1. >> >> The way that this could work in MLS would be heavily based on >> HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead will >> point out the relevant sections (which are short, well-written and worth >> reading:) >> >> - Section 2 describes the original concept as used for Bitcoin wallet >> derivation. >> - Section 4 describes the modifications to Ed25519 to enable HKD >> constructions. >> - Section 5 describes how private and public child keys are generated >> (Fig. 1 is also helpful.) >> >> My questions: >> >> - How are we deriving epoch identifiers? Are they simply counters, or >> each epoch identified by a nonce that's communicated confidentially? = If you >> read [2], you'll see why this can be important. >> - Performance impact seems to be negligible for Montgomery-based >> signing primitives, but I'm interested in more insight on this. >> - Is anyone else interested in having a standard >> HDKeys-Ed25519 implementation? I've been working on one in JavaScript= and >> plan to eventually also write one in Go. Perhaps Richard would like t= o help >> with a C++ version? >> - I'm also interested in hearing your thoughts on this generally. >> >> During the interim meeting (as well as before it), it was frequently >> discussed how ephemeral signatures may be useful for MLS. This also appe= ars >> to be slated as a discussion topic for IETF 103, so it would be great if= we >> could continue the discussion there as well. >> >> References: >> [0] >> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-n= g.txt#n1979 >> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki >> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf >> >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software >> Sent from office >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --000000000000b7176d05780dd7b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ted,
Thanks for your quick read-through!

You seem to be referring to [1], not to [2] as you wrote. = In [1], the concept of "hardened" keys is defined and is also por= ted by [2] into Ed25519.

> What I think that me= ans is that if an attacker ever gets access to both an extended public key = and any extended private key, we have lost forward secrecy for all the MLS = communications covered by any keys derived from any of the epoch pairs.=C2= =A0 Is that correct?

This is correct in the sense that it allows you to rewind the key der= ivation chain. However, this does not apply to hardened keys. This is preci= sely why I'm trying to understand how epoch identifiers are agreed upon= , in order to see whether we can use them to restrict the HKD logic to use = only "hardened" keys in MLS. Since hardened keys in [2] cannot th= emselves have children, it becomes important to understand whether we can s= elect enough of them for an HKD design in MLS to have a meaningful impact, = and how this selection/potential caching of hardened keys would work.
=

> [...] means that Alice must refrain from ever= using the parent extended public key has a signing key, but must instantia= te signing keys from the n + 0 epoch.=C2=A0=C2=A0

This could also be a solution, I suppose, but it sounds like it would= result in weaker "signing forward secrecy" (or whatever we'r= e calling this property) than focusing on hardened keys, although I'm f= rankly not sure off the top of my head.

Nadim Kobeissi
Symbolic Software=C2=A0=E2=80=A2 https://symbolic.software
Sent from office


On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Nadim,

I suspect I'm missing something simple here in your proposal.=C2= =A0 According to your reference 2, one of the issues with the derivation of= this type of hierarchical key is:

=C2=A0that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and=20 thus every private and public key descending from it). This means that=20 extended public keys must be treated more carefully than regular public=20 keys. It is also the reason for the existence of hardened keys, and why they=20 are used for the account level in the tree. This way, a leak of=20 account-specific (or below) private key never risks compromising the=20 master or other accounts.

What I thin= k that means is that if an attacker ever gets access to both an extended pu= blic key and any extended private key, we have lost forward secrecy for all= the MLS communications covered by any keys derived from any of the epoch p= airs.=C2=A0 Is that correct?

This appears to make = handling required of the parent extended public key roughly equivalent to t= he handling of a private key, so that your step:

A= lice sends a public signing key to Bob during epoch n.

=
means that Alice must refrain from ever using the parent extended publ= ic key has a signing key, but must instantiate signing keys from the n + 0 = epoch.=C2=A0

Is that a correct understanding?=

Thanks,

Ted


= On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi <nadim@symbolic.software= > wrote:
Hello everyone,

I've been working on adapting Hi= erarchical Key Derivation (HKD) in order to obtain some kind of ephemeral s= ignatures that may be useful in MLS. I've arrived at a point where I= 9;m optimistic that this is a direction worth pursuing and might indeed be = a solution to this problem.

HKD was at some point = a candidate for how signature keys are managed per epoch in the Tor Hidden = Service design [0]. HKD logic has also been implemented in Bitcoin wallets = for a while now [1]. HKD constructions can be also derived from existing po= pular fast signature algorithms such as Ed25519 with minimal changes [2], m= aking them an easy fit for MLS. Very simply, the functionality that HKD sig= nature schemes bring to MLS is the following:
  • Alice sends= a public signing key to Bob during epoch n.
  • At the onset of ep= och n+1, Bob is able to immediately calculate Alice's public signing ke= y for epoch n+1 based purely on his knowledge of Alice's public signing= key for epoch 0. Alice doesn't need to send new signing key informatio= n to Bob.
  • At this point, Bob can delete Alice's public signing = key for epoch n.
  • More importantly, Alice herself can delete Alice&#= 39;s private signing key for epoch n, keeping only her private signing key = for epoch n+1.
The way that this could work in MLS would be h= eavily based on HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper,= and instead will point out the relevant sections (which are short, well-wr= itten and worth reading:)
  • Section 2 describes the o= riginal concept as used for Bitcoin wallet derivation.
  • Section 4 de= scribes the modifications to Ed25519 to enable HKD constructions.
  • S= ection 5 describes how private and public child keys are generated (Fig. 1 = is also helpful.)
My questions:
  • How a= re we deriving epoch identifiers? Are they simply counters, or each epoch i= dentified by a nonce that's communicated confidentially? If you read [2= ], you'll see why this can be important.
  • Performance impact see= ms to be negligible for Montgomery-based signing primitives, but I'm in= terested in more insight on this.
  • Is anyone else interested in havi= ng a standard HDKeys-Ed25519=C2=A0implementation? I've been working on = one in JavaScript and plan to eventually also write one in Go. Perhaps Rich= ard would like to help with a C++ version?
  • I'm also interested = in hearing your thoughts on this generally.
During the = interim meeting (as well as before it), it was frequently discussed how eph= emeral signatures may be useful for MLS. This also appears to be slated as = a discussion topic for IETF 103, so it would be great if we could continue = the discussion there as well.=C2=A0
Nadim Kobeissi
Symbolic Soft= ware=C2=A0=E2=80=A2 https://symbolic.softw= are
Sent from office
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000b7176d05780dd7b3-- From nobody Fri Oct 12 17:43:44 2018 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 0574E130E9D for ; Fri, 12 Oct 2018 17:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 qk2B9jLdUJ-8 for ; Fri, 12 Oct 2018 17:43:38 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0: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 64971130E98 for ; Fri, 12 Oct 2018 17:43:38 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id v5-v6so6633123plz.13 for ; Fri, 12 Oct 2018 17:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/a1DH8xCyMveaLP0nWs0R2M1c6y+JzBBZHrNZhVQgUI=; b=xxQ0TeKGwNXegOs7mu/nO/3aC5gv6uCzmrEp43R4kGOsUxPfTSaY3obcMcM0AA2fuc mpUFwMMjS4hwXEcG2XKEMSAWF8Gf/dclu29s1yRsAUJR177uFupYiHfm4Mg73eozUoR7 6n4TvnJE8BGiqKsZs4Hb3tzA0GfIRK6/jCI94= 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=/a1DH8xCyMveaLP0nWs0R2M1c6y+JzBBZHrNZhVQgUI=; b=U73ZaULCz4e/WoHgdjdgJpaP4L9+BwcK440lVBv3B4QBSu42zCJH5LbxVOY83bHYuF ohDTp8Lk7cxmdpLW8H0dHnkOrpanIApD/poCH0VFpJmwSnbJ5c0XciAs0qp9UnXOOFc9 ijVYlCT3oPBnoV/ynEOeFpFG28EJJEZd7eM/lNwrYHm5xLJ4iEZ065MYtlQc8TUxFzHj JnOflTVrA7sLaXu+QzL66Wy4Z8M75nMdHmjiP8go1tsb2SMP73RFD2zFcCr+fie0Sfx7 0XENYZc+QP2Q9Z0rQ7l3UEXYt65Srwl6XkVi4A+jggAn3f2qkIErJeMuNFuuc7817wUI SaGA== X-Gm-Message-State: ABuFfojz31k4rlNH539BRsKxUd/zdqu0V5hcs19vZ4ueyp5/c/aGqLes uSWyxADQGTd9JqntsXeX2Z7PBg== X-Google-Smtp-Source: ACcGV61SYFq+vTaleorodWoTI/IrmtMF0nnjHEsaFK5ktc81X/CCvFh6MKcnHDjXhQtOqgTkBtFa7A== X-Received: by 2002:a17:902:4681:: with SMTP id p1-v6mr279326pld.97.1539391417405; Fri, 12 Oct 2018 17:43:37 -0700 (PDT) Received: from ?IPv6:2601:646:c601:83b0:3085:955:c8ad:b00a? ([2601:646:c601:83b0:3085:955:c8ad:b00a]) by smtp.gmail.com with ESMTPSA id y19-v6sm4639285pff.14.2018.10.12.17.43.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 17:43:36 -0700 (PDT) From: Brendan McMillion Message-Id: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FA4CE8AB-6746-4759-8B43-B8E9444CFBD8" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Fri, 12 Oct 2018 17:43:34 -0700 In-Reply-To: Cc: ted.ietf@gmail.com, mls@ietf.org To: Nadim Kobeissi References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 00:43:42 -0000 --Apple-Mail=_FA4CE8AB-6746-4759-8B43-B8E9444CFBD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Nadim I believe the typical way to build a forward-secure signature scheme is = with a certification tree. You=E2=80=99d: 1. Generate a root keypair. 2. Generate N leaf keypairs. 3. Sign each leaf keypair and the epoch it is meant to be used in, with = the root keypair. 4. Delete the root private key. Your root public key is what=E2=80=99s distributed to everybody. A = signature at a given epoch is the tuple: (leaf public key, sig over leaf = key from root key, sig over data from leaf key). Could you talk about why a scheme like the above is not suitable here? = Also, since I didn=E2=80=99t go to the interim, what problem do = forward-signature signature schemes solve for MLS? > On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi = wrote: >=20 > Dear Ted, > Thanks for your quick read-through! >=20 > You seem to be referring to [1], not to [2] as you wrote. In [1], the = concept of "hardened" keys is defined and is also ported by [2] into = Ed25519. >=20 > > What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >=20 > This is correct in the sense that it allows you to rewind the key = derivation chain. However, this does not apply to hardened keys. This is = precisely why I'm trying to understand how epoch identifiers are agreed = upon, in order to see whether we can use them to restrict the HKD logic = to use only "hardened" keys in MLS. Since hardened keys in [2] cannot = themselves have children, it becomes important to understand whether we = can select enough of them for an HKD design in MLS to have a meaningful = impact, and how this selection/potential caching of hardened keys would = work. >=20 > > [...] means that Alice must refrain from ever using the parent = extended public key has a signing key, but must instantiate signing keys = from the n + 0 epoch. =20 >=20 > This could also be a solution, I suppose, but it sounds like it would = result in weaker "signing forward secrecy" (or whatever we're calling = this property) than focusing on hardened keys, although I'm frankly not = sure off the top of my head. >=20 > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software = > Sent from office >=20 >=20 > On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie > wrote: > Hi Nadim, >=20 > I suspect I'm missing something simple here in your proposal. = According to your reference 2, one of the issues with the derivation of = this type of hierarchical key is: >=20 > that knowledge of a parent extended public key plus any non-hardened = private key descending from it is equivalent to knowing the parent = extended private key (and thus every private and public key descending = from it). This means that extended public keys must be treated more = carefully than regular public keys. It is also the reason for the = existence of hardened keys, and why they are used for the account level = in the tree. This way, a leak of account-specific (or below) private key = never risks compromising the master or other accounts. >=20 > What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >=20 > This appears to make handling required of the parent extended public = key roughly equivalent to the handling of a private key, so that your = step: >=20 > Alice sends a public signing key to Bob during epoch n. >=20 > means that Alice must refrain from ever using the parent extended = public key has a signing key, but must instantiate signing keys from the = n + 0 epoch. =20 >=20 > Is that a correct understanding? >=20 > Thanks, >=20 > Ted >=20 >=20 > On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi = wrote: > Hello everyone, >=20 > I've been working on adapting Hierarchical Key Derivation (HKD) in = order to obtain some kind of ephemeral signatures that may be useful in = MLS. I've arrived at a point where I'm optimistic that this is a = direction worth pursuing and might indeed be a solution to this problem. >=20 > HKD was at some point a candidate for how signature keys are managed = per epoch in the Tor Hidden Service design [0]. HKD logic has also been = implemented in Bitcoin wallets for a while now [1]. HKD constructions = can be also derived from existing popular fast signature algorithms such = as Ed25519 with minimal changes [2], making them an easy fit for MLS. = Very simply, the functionality that HKD signature schemes bring to MLS = is the following: > Alice sends a public signing key to Bob during epoch n. > At the onset of epoch n+1, Bob is able to immediately calculate = Alice's public signing key for epoch n+1 based purely on his knowledge = of Alice's public signing key for epoch 0. Alice doesn't need to send = new signing key information to Bob. > At this point, Bob can delete Alice's public signing key for epoch n. > More importantly, Alice herself can delete Alice's private signing key = for epoch n, keeping only her private signing key for epoch n+1. > The way that this could work in MLS would be heavily based on = HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead will = point out the relevant sections (which are short, well-written and worth = reading:) > Section 2 describes the original concept as used for Bitcoin wallet = derivation. > Section 4 describes the modifications to Ed25519 to enable HKD = constructions. > Section 5 describes how private and public child keys are generated = (Fig. 1 is also helpful.) > My questions: > How are we deriving epoch identifiers? Are they simply counters, or = each epoch identified by a nonce that's communicated confidentially? If = you read [2], you'll see why this can be important. > Performance impact seems to be negligible for Montgomery-based signing = primitives, but I'm interested in more insight on this. > Is anyone else interested in having a standard HDKeys-Ed25519 = implementation? I've been working on one in JavaScript and plan to = eventually also write one in Go. Perhaps Richard would like to help with = a C++ version? > I'm also interested in hearing your thoughts on this generally. > During the interim meeting (as well as before it), it was frequently = discussed how ephemeral signatures may be useful for MLS. This also = appears to be slated as a discussion topic for IETF 103, so it would be = great if we could continue the discussion there as well.=20 >=20 > References: > [0] = https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.= txt#n1979 = > [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki = > [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf = >=20 > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software = > Sent from office > _______________________________________________ > 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=_FA4CE8AB-6746-4759-8B43-B8E9444CFBD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hey = Nadim

I believe the = typical way to build a forward-secure signature scheme is with a = certification tree. You=E2=80=99d:

1. Generate a root keypair.
2. Generate N leaf keypairs.
3. Sign = each leaf keypair and the epoch it is meant to be used in, with the root = keypair.
4. Delete the root private key.

Your root public key is = what=E2=80=99s distributed to everybody. A signature at a given epoch is = the tuple: (leaf public key, sig over leaf key from root key, sig over = data from leaf key).

Could you talk about why a scheme like the above is not = suitable here? Also, since I didn=E2=80=99t go to the interim, what = problem do forward-signature signature schemes solve for MLS?

On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi <nadim@symbolic.software> wrote:

Dear Ted,
Thanks for your quick = read-through!

You seem to be referring to [1], not to [2] as you wrote. In = [1], the concept of "hardened" keys is defined and is also ported by [2] = into Ed25519.

> What I think that means is that if an attacker ever gets = access to both an extended public key and any extended private key, we = have lost forward secrecy for all the MLS communications covered by any = keys derived from any of the epoch pairs.  Is that correct?

This is = correct in the sense that it allows you to rewind the key derivation = chain. However, this does not apply to hardened keys. This is precisely = why I'm trying to understand how epoch identifiers are agreed upon, in = order to see whether we can use them to restrict the HKD logic to use = only "hardened" keys in MLS. Since hardened keys in [2] cannot = themselves have children, it becomes important to understand whether we = can select enough of them for an HKD design in MLS to have a meaningful = impact, and how this selection/potential caching of hardened keys would = work.

> [...] means that Alice must refrain from ever using the = parent extended public key has a signing key, but must instantiate = signing keys from the n + 0 epoch.  

This could also be a = solution, I suppose, but it sounds like it would result in weaker = "signing forward secrecy" (or whatever we're calling this property) than = focusing on hardened keys, although I'm frankly not sure off the top of = my head.

Nadim Kobeissi
Symbolic = Software =E2=80=A2 https://symbolic.software
Sent from = office


On = Fri, Oct 12, 2018 at 10:03 PM Ted Hardie <ted.ietf@gmail.com> = wrote:
Hi = Nadim,

I = suspect I'm missing something simple here in your proposal.  = According to your reference 2, one of the issues with the derivation of = this type of hierarchical key is:

 that knowledge = of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and=20= thus every private and public key descending from it). This means that=20= extended public keys must be treated more carefully than regular public=20= keys. It is also the reason for the existence of hardened keys, and why they=20= are used for the account level in the tree. This way, a leak of=20 account-specific (or below) private key never risks compromising the=20 master or other accounts.

What I think that means is that if an = attacker ever gets access to both an extended public key and any = extended private key, we have lost forward secrecy for all the MLS = communications covered by any keys derived from any of the epoch = pairs.  Is that correct?

This appears to make handling required = of the parent extended public key roughly equivalent to the handling of = a private key, so that your step:

Alice sends a public signing key to Bob = during epoch n.

means that Alice must refrain from ever using the parent = extended public key has a signing key, but must instantiate signing keys = from the n + 0 epoch. 

Is that a correct understanding?

Thanks,

Ted


On Fri, Oct 12, 2018 = at 12:47 PM Nadim Kobeissi <nadim@symbolic.software> wrote:
Hello everyone,

I've been working on adapting Hierarchical Key Derivation = (HKD) in order to obtain some kind of ephemeral signatures that may be = useful in MLS. I've arrived at a point where I'm optimistic that this is = a direction worth pursuing and might indeed be a solution to this = problem.

HKD = was at some point a candidate for how signature keys are managed per = epoch in the Tor Hidden Service design [0]. HKD logic has also been = implemented in Bitcoin wallets for a while now [1]. HKD constructions = can be also derived from existing popular fast signature algorithms such = as Ed25519 with minimal changes [2], making them an easy fit for MLS. = Very simply, the functionality that HKD signature schemes bring to MLS = is the following:
  • Alice= sends a public signing key to Bob during epoch n.
  • At the onset of epoch n+1, Bob is able to immediately = calculate Alice's public signing key for epoch n+1 based purely on his = knowledge of Alice's public signing key for epoch 0. Alice doesn't need = to send new signing key information to Bob.
  • At this = point, Bob can delete Alice's public signing key for epoch n.
  • More importantly, Alice herself can delete Alice's private = signing key for epoch n, keeping only her private signing key for epoch = n+1.
The way that this could work in MLS would = be heavily based on HDKeys-Ed25519 [2]. I'll resist paraphrasing the = paper, and instead will point out the relevant sections (which are = short, well-written and worth reading:)
  • Section 2 describes the original concept as = used for Bitcoin wallet derivation.
  • Section 4 = describes the modifications to Ed25519 to enable HKD = constructions.
  • Section 5 describes how private and = public child keys are generated (Fig. 1 is also = helpful.)
My questions:
  • How are we deriving epoch = identifiers? Are they simply counters, or each epoch identified by a = nonce that's communicated confidentially? If you read [2], you'll see = why this can be important.
  • Performance impact seems = to be negligible for Montgomery-based signing primitives, but I'm = interested in more insight on this.
  • Is anyone else = interested in having a standard HDKeys-Ed25519 implementation? I've = been working on one in JavaScript and plan to eventually also write one = in Go. Perhaps Richard would like to help with a C++ version?
  • I'm also interested in hearing your thoughts on this = generally.
During the interim meeting (as = well as before it), it was frequently discussed how ephemeral signatures = may be useful for MLS. This also appears to be slated as a discussion = topic for IETF 103, so it would be great if we could continue the = discussion there as well. 

References:
[0] https://gitweb.torproject.org/torspec.git/tree/proposals/224-re= nd-spec-ng.txt#n1979
[1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki<= /a>
[2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf

Nadim Kobeissi
Symbolic Software =E2=80=A2 https://symbolic.software
Sent from = office
<= /div> _______________________________________________
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=_FA4CE8AB-6746-4759-8B43-B8E9444CFBD8-- From nobody Fri Oct 12 18:03:16 2018 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 9E800130EA8 for ; Fri, 12 Oct 2018 18:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz-acW_9i0vQ for ; Fri, 12 Oct 2018 18:03:01 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 EA54F130ECE for ; Fri, 12 Oct 2018 18:03:00 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id a85-v6so8765259qkg.3 for ; Fri, 12 Oct 2018 18:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=fcs0JotwN5iChYG6+Cx+tKPiw3sTt4XJGpo08dtMSc0=; b=gUzZ8oRau7IB7P+th/u72rJsoOIOMI43x2z1kPXbkx1r+CaEun28DC6tVCN8vbIgFu 9mL/g13CQxPV6UYus16AFv6BPuP2Qhp5Ey0hfkBjOwIOIWL3ZmMBxji4YbpNWn29V/0o cgAFrz2yMMF1J21GfdBVJlurwEVsIhNsNMvCY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=fcs0JotwN5iChYG6+Cx+tKPiw3sTt4XJGpo08dtMSc0=; b=R+ongClKYRv1Y4Z/cZoCEt9hXsy157Z9v3E6SmriGyCZ2QbKx8FRq3Qlpn9PUXigeQ RY/i0cqhT5FKtoHsiVeWcQlFVhV83GF4F05wvVFWBAzJFiNeKux2BOfQmH28/GjekCMI JL/Ii9SU6FXhUdEfmlNSlqZKFX4rk7PBQLyJ+NyG8hn6ljxxMz2bWNKBDjmuPVcN5KlU RNCpS4hnljKl/FGoOMhl/yGwnvQ+OWW27ktqNbZzfcId4Bv+oNDwfrL8+qHDKnXYDjB2 BCeivDdjuOoDY6Glv+7hKPhITN4RUMxwSIHowbjdhQvXrHEjJG8KpVhjDUS+JrVmPy8+ Mk/A== X-Gm-Message-State: ABuFfogumboQ2BMMWiN75FkLjbvyHIRCpyZWNe75QBXWh0ie45zwDK/E VycJUCVFX3iZ3ao0j18X7Y0QnlP9GNw= X-Google-Smtp-Source: ACcGV63tF7MNFi0hl2Fp7Lt4SsZ3gXreWCKY4O2QNDIoBFEdXiINlUkjGMS5AURIqI2d7ciq9YhOuQ== X-Received: by 2002:a37:2a14:: with SMTP id q20-v6mr7944148qkh.248.1539392579970; Fri, 12 Oct 2018 18:02:59 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id m61-v6sm1350065qte.30.2018.10.12.18.02.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 18:02:59 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_A01EFC1A-BA49-40C7-8071-B9996B0DA1FD" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <2659DADC-1EEB-4947-8329-CAC83ADDCE97@sn3rd.com> References: <153938255773.29257.10827766621859025576.idtracker@ietfa.amsl.com> To: mls@ietf.org Date: Fri, 12 Oct 2018 21:02:55 -0400 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] Fwd: IETF 103 Final Agenda X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 01:03:14 -0000 --Apple-Mail=_A01EFC1A-BA49-40C7-8071-B9996B0DA1FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI - our sessions are scheduled for: MONDAY, November 5, 2018 1610-1810 Afternoon Session II Chitlada 2 SEC mls Messaging Layer Security WG THURSDAY, November 8, 2018 1120-1220 Morning Session II Chitlada 1 SEC mls Messaging Layer Security WG I will forward the remote attendees information Monday of IETF week. = You can find the MeetEcho link on the html agenda link below. spt Begin forwarded message: >=20 > From: IETF Agenda > Subject: IETF 103 Final Agenda > Date: October 12, 2018 at 18:15:57 EDT > To: "IETF Announcement List" > Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org > Reply-To: agenda@ietf.org >=20 > IETF 103 > Bangkok, Thailand > November 3-9, 2018 > Hosts: Huawei and Cisco >=20 > The IETF 103 final agenda is now available.=20 >=20 > https://datatracker.ietf.org/meeting/103/agenda.html > https://datatracker.ietf.org/meeting/103/agenda.txt >=20 > While this is considered the final agenda for printing, changes may be = made to the agenda up until and during the meeting. Updates will be = reflected on the web versions of the agenda.=20 >=20 >=20 > IETF 103 Information: https://www.ietf.org/how/meetings/103/ > Register online at: https://www.ietf.org/how/meetings/register/ >=20 >=20 >=20 > Unofficial Side Meetings >=20 > As communicated back in May = (https://www.ietf.org/mail-archive/web/ietf/current/msg107813.html), the = IESG is running an agenda experiment on Friday of the IETF 103 meeting = week. >=20 > Monday through Thursday, we will have two rooms available for = attendees to reserve for side meetings, as usual. On Friday, because = there will be no working group meetings, we will have eight rooms = available for unofficial side meetings. Projectors will be provided in = all of the meeting rooms. Meetecho will not be recording or providing = remote participation on Friday. Please note that all side meetings must = conclude by 13:30. >=20 > We realize that keeping track of all of these side meetings may prove = challenging, so a calendar with subscription details can be found here: = https://www.ietf.org/how/meetings/103/side-meetings/ >=20 >=20 >=20 > Don=E2=80=99t forget to register for these exciting IETF 103 events! >=20 > Hackathon=20 > Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py > More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/ > Keep up to date by subscribing to:=20 > https://www.ietf.org/mailman/listinfo/hackathon >=20 > Code Sprint > Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp > More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint >=20 --Apple-Mail=_A01EFC1A-BA49-40C7-8071-B9996B0DA1FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI = - our sessions are scheduled for:

MONDAY, November 5, 2018
1610-1810 = Afternoon Session II
Chitlada 2 SEC = mls Messaging Layer Security WG

THURSDAY, November 8, 2018
1120-1220 Morning Session II
Chitlada 1 = SEC mls Messaging Layer Security WG

I will forward the = remote attendees information Monday of IETF week.  You can find the = MeetEcho link on the html agenda link below.

spt

Begin forwarded message:

From: = IETF Agenda <agenda@ietf.org>
Subject: = IETF 103 Final = Agenda
Date: = October 12, 2018 at 18:15:57 = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org
Reply-To: = agenda@ietf.org

IETF 103
Bangkok, Thailand
November= 3-9, 2018
Hosts: Huawei and Cisco

The IETF 103 final agenda is now available.

https://datatracker.ietf.org/meeting/103/agenda.html
https://datatracker.ietf.org/meeting/103/agenda.txt

While this is considered the final agenda for = printing, changes may be made to the agenda up until and during the = meeting. Updates will be reflected on the web versions of the agenda. =


IETF 103 Information: = https://www.ietf.org/how/meetings/103/
Register online at: = https://www.ietf.org/how/meetings/register/



Unofficial Side Meetings

As communicated back in May = (https://www.ietf.org/mail-archive/web/ietf/current/msg107813.html), = the IESG is running an agenda experiment on Friday of the IETF 103 = meeting week.

Monday through Thursday, we = will have two rooms available for attendees to reserve for side = meetings, as usual. On Friday, because there will be no working group = meetings, we will have eight rooms available for unofficial side = meetings. Projectors will be provided in all of the meeting rooms. = Meetecho will not be recording or providing remote participation on = Friday. Please note that all side meetings must conclude by 13:30.

We realize that keeping track of all of these = side meetings may prove challenging, so a calendar with subscription = details can be found here: = https://www.ietf.org/how/meetings/103/side-meetings/



Don=E2=80=99t forget to = register for these exciting IETF 103 events!

Hackathon
Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py
= More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint


= --Apple-Mail=_A01EFC1A-BA49-40C7-8071-B9996B0DA1FD-- From nobody Fri Oct 12 22:45:29 2018 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 493E1130EBC for ; Fri, 12 Oct 2018 22:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symbolic.software 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 Ia12uV9mr_wJ for ; Fri, 12 Oct 2018 22:45:21 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 9C19F130EBA for ; Fri, 12 Oct 2018 22:45:20 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id y11-v6so14048771wma.3 for ; Fri, 12 Oct 2018 22:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c27VnqvTYa18TU9aD7cPgMjkk0IG13+OH/GgoYpo2vE=; b=kn0XORGi8l26Xlf4wGUEcGYHVUTQO5ysy2msWYCB/nv4eCOt4gITdWeNtrVjUENt6q +XVpu8DC0Ca1/R1TmCmDzQNpndpgHeWQGyY0OQ3ik+i3t6JDnHB9bDte7bw6o5Xm4F4m o7EclN+dIcaC3daHwYKso/2tGfY0gb8Ab+oEk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c27VnqvTYa18TU9aD7cPgMjkk0IG13+OH/GgoYpo2vE=; b=gfeVi/nmWFXOOroYo+GcXu0imWtYnEcYuNCHkw6hPx8q3nsUv+OSBip08U86MVLUdT 95eZ+9Te1Uy+TWZRF0X+PrQrxwpbkJSmvmHfR/JEtq4rxTO3yDy/Hb1h2hvHw8EqKQxG /RaUKBQeZ2q4qeNCtjKc4iEHVzUT4HwexuKoo+YlJIE2UClJis1P1td0ZNbidoEacd0q aJSfQW1YlF4pjLsB7ilVmh3F2MxQYcvrAKiumtriIvZK4qDVKj09EfdjBQRWicysACpi v6kwmKsGqxbUPme7koqkCsn1wVrHcAf4XrWaCSUbeoX/MsyNpN0a5TigESh9fsBgXrLT 6v4w== X-Gm-Message-State: ABuFfohENMLBQakWSCSYWLQK1SMRLxyDeEy6JkQFfARz8I+KGxYeUexE JNQ3V9ldWCCudae/mP9Yc0/octKe01ywhTk6r4nyFw== X-Google-Smtp-Source: ACcGV62ZrT7H7msRvvpBtK/HzoLXUsfIB22R81esZ+WwBI8rr/vFIzVwHZQ2jlxgt8eSXUkBbup33Pu3pkJkfQVtJys= X-Received: by 2002:a1c:14d1:: with SMTP id 200-v6mr7453110wmu.106.1539409518745; Fri, 12 Oct 2018 22:45:18 -0700 (PDT) MIME-Version: 1.0 References: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> In-Reply-To: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> From: Nadim Kobeissi Date: Sat, 13 Oct 2018 07:45:09 +0200 Message-ID: To: brendan@cloudflare.com Cc: ted.ietf@gmail.com, mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000008771d5057815b582" Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 05:45:27 -0000 --0000000000008771d5057815b582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Brendan, Your proposed scheme could work, too. The disadvantages it presents, it seems to me, aren't severe: - Your proposed scheme seems to have a larger performance overhead: each leaf keypair/epoch tuple would have to be generated and signed in advanc= e. - We'd need to know the number of epochs we're allowing for this MLS session in advance. - We may not be able to parametrize the choice of upcoming signature keys based on a dynamically generated epoch identifier with the same deg= ree of freedom that HKD would give us. > Also, since I didn=E2=80=99t go to the interim, what problem do forward-s= ignature signature schemes solve for MLS? We're simply trying to limit the impact of device compromise. We're able to do this more easily for encryption keys, but signatures are more tricky. Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillion wrote: > Hey Nadim > > I believe the typical way to build a forward-secure signature scheme is > with a certification tree. You=E2=80=99d: > > 1. Generate a root keypair. > 2. Generate N leaf keypairs. > 3. Sign each leaf keypair and the epoch it is meant to be used in, with > the root keypair. > 4. Delete the root private key. > > Your root public key is what=E2=80=99s distributed to everybody. A signat= ure at a > given epoch is the tuple: (leaf public key, sig over leaf key from root > key, sig over data from leaf key). > > Could you talk about why a scheme like the above is not suitable here? > Also, since I didn=E2=80=99t go to the interim, what problem do forward-s= ignature > signature schemes solve for MLS? > > On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi > wrote: > > Dear Ted, > Thanks for your quick read-through! > > You seem to be referring to [1], not to [2] as you wrote. In [1], the > concept of "hardened" keys is defined and is also ported by [2] into > Ed25519. > > > What I think that means is that if an attacker ever gets access to both > an extended public key and any extended private key, we have lost forward > secrecy for all the MLS communications covered by any keys derived from a= ny > of the epoch pairs. Is that correct? > > This is correct in the sense that it allows you to rewind the key > derivation chain. However, this does not apply to hardened keys. This is > precisely why I'm trying to understand how epoch identifiers are agreed > upon, in order to see whether we can use them to restrict the HKD logic t= o > use only "hardened" keys in MLS. Since hardened keys in [2] cannot > themselves have children, it becomes important to understand whether we c= an > select enough of them for an HKD design in MLS to have a meaningful impac= t, > and how this selection/potential caching of hardened keys would work. > > > [...] means that Alice must refrain from ever using the parent extended > public key has a signing key, but must instantiate signing keys from the = n > + 0 epoch. > > This could also be a solution, I suppose, but it sounds like it would > result in weaker "signing forward secrecy" (or whatever we're calling thi= s > property) than focusing on hardened keys, although I'm frankly not sure o= ff > the top of my head. > > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software > Sent from office > > > On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie wrote: > >> Hi Nadim, >> >> I suspect I'm missing something simple here in your proposal. According >> to your reference 2, one of the issues with the derivation of this type = of >> hierarchical key is: >> >> that knowledge of a parent extended public key plus any non-hardened >>> private key descending from it is equivalent to knowing the parent exte= nded >>> private key (and thus every private and public key descending from it). >>> This means that extended public keys must be treated more carefully tha= n >>> regular public keys. It is also the reason for the existence of hardene= d >>> keys, and why they are used for the account level in the tree. This way= , a >>> leak of account-specific (or below) private key never risks compromisin= g >>> the master or other accounts. >>> >> >> What I think that means is that if an attacker ever gets access to both >> an extended public key and any extended private key, we have lost forwar= d >> secrecy for all the MLS communications covered by any keys derived from = any >> of the epoch pairs. Is that correct? >> >> This appears to make handling required of the parent extended public key >> roughly equivalent to the handling of a private key, so that your step: >> >> Alice sends a public signing key to Bob during epoch n. >> >> means that Alice must refrain from ever using the parent extended public >> key has a signing key, but must instantiate signing keys from the n + 0 >> epoch. >> >> Is that a correct understanding? >> >> Thanks, >> >> Ted >> >> >> On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi >> wrote: >> >>> Hello everyone, >>> >>> I've been working on adapting Hierarchical Key Derivation (HKD) in orde= r >>> to obtain some kind of ephemeral signatures that may be useful in MLS. = I've >>> arrived at a point where I'm optimistic that this is a direction worth >>> pursuing and might indeed be a solution to this problem. >>> >>> HKD was at some point a candidate for how signature keys are managed pe= r >>> epoch in the Tor Hidden Service design [0]. HKD logic has also been >>> implemented in Bitcoin wallets for a while now [1]. HKD constructions c= an >>> be also derived from existing popular fast signature algorithms such as >>> Ed25519 with minimal changes [2], making them an easy fit for MLS. Very >>> simply, the functionality that HKD signature schemes bring to MLS is th= e >>> following: >>> >>> - Alice sends a public signing key to Bob during epoch n. >>> - At the onset of epoch n+1, Bob is able to immediately calculate >>> Alice's public signing key for epoch n+1 based purely on his knowled= ge of >>> Alice's public signing key for epoch 0. Alice doesn't need to send n= ew >>> signing key information to Bob. >>> - At this point, Bob can delete Alice's public signing key for epoch >>> n. >>> - More importantly, Alice herself can delete Alice's private signing >>> key for epoch n, keeping only her private signing key for epoch n+1. >>> >>> The way that this could work in MLS would be heavily based on >>> HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead wil= l >>> point out the relevant sections (which are short, well-written and wort= h >>> reading:) >>> >>> - Section 2 describes the original concept as used for Bitcoin >>> wallet derivation. >>> - Section 4 describes the modifications to Ed25519 to enable HKD >>> constructions. >>> - Section 5 describes how private and public child keys are >>> generated (Fig. 1 is also helpful.) >>> >>> My questions: >>> >>> - How are we deriving epoch identifiers? Are they simply counters, >>> or each epoch identified by a nonce that's communicated confidential= ly? If >>> you read [2], you'll see why this can be important. >>> - Performance impact seems to be negligible for Montgomery-based >>> signing primitives, but I'm interested in more insight on this. >>> - Is anyone else interested in having a standard >>> HDKeys-Ed25519 implementation? I've been working on one in JavaScrip= t and >>> plan to eventually also write one in Go. Perhaps Richard would like = to help >>> with a C++ version? >>> - I'm also interested in hearing your thoughts on this generally. >>> >>> During the interim meeting (as well as before it), it was frequently >>> discussed how ephemeral signatures may be useful for MLS. This also app= ears >>> to be slated as a discussion topic for IETF 103, so it would be great i= f we >>> could continue the discussion there as well. >>> >>> References: >>> [0] >>> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-= ng.txt#n1979 >>> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki >>> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf >>> >>> Nadim Kobeissi >>> Symbolic Software =E2=80=A2 https://symbolic.software >>> Sent from office >>> _______________________________________________ >>> 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 > > > --0000000000008771d5057815b582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brendan,
Your proposed scheme could work, too. Th= e disadvantages it presents, it seems to me, aren't severe:
  • Your proposed scheme seems to have a larger performance over= head: each leaf keypair/epoch tuple would have to be generated and signed i= n advance.
  • We'd need to know the number of epochs we're all= owing for this MLS session in advance.
  • We may not be able to parame= trize the choice of upcoming signature keys based on a dynamically generate= d epoch identifier with the same degree of freedom that HKD would give us.<= /li>
> Also, since I = didn=E2=80=99t go to the interim, what problem do forward-signature signatu= re schemes solve for MLS?

We're si= mply trying to limit the impact of device compromise. We're able to do = this more easily for encryption keys, but signatures are more tricky.
=

Nadim Kobeissi
Symbolic Sof= tware=C2=A0=E2=80=A2 https://symbolic.soft= ware
Sent from office


On Sat= , Oct 13, 2018 at 2:43 AM Brendan McMillion <brendan@cloudflare.com> wrote:
Hey Nadim

I believe the typical way to build a f= orward-secure signature scheme is with a certification tree. You=E2=80=99d:=

1. Generate a root keypair.
2. Generate= N leaf keypairs.
3. Sign each leaf keypair and the epoch it is m= eant to be used in, with the root keypair.
4. Delete the root pri= vate key.

Your root public key is what=E2=80=99s d= istributed to everybody. A signature at a given epoch is the tuple: (leaf p= ublic key, sig over leaf key from root key, sig over data from leaf key).

Could you talk about why a scheme like the above is= not suitable here? Also, since I didn=E2=80=99t go to the interim, what pr= oblem do forward-signature signature schemes solve for MLS?
=
On Oct 12, 2018, at 1:22 PM, Nadim Kobei= ssi <nadim@= symbolic.software> wrote:

Dear Ted,
Thanks for your= quick read-through!

You seem to be referring to [= 1], not to [2] as you wrote. In [1], the concept of "hardened" ke= ys is defined and is also ported by [2] into Ed25519.

<= div>> What I think that means is that if an attacker ever gets access to= both an extended public key and any extended private key, we have lost for= ward secrecy for all the MLS communications covered by any keys derived fro= m any of the epoch pairs.=C2=A0 Is that correct?

This is correct in t= he sense that it allows you to rewind the key derivation chain. However, th= is does not apply to hardened keys. This is precisely why I'm trying to= understand how epoch identifiers are agreed upon, in order to see whether = we can use them to restrict the HKD logic to use only "hardened" = keys in MLS. Since hardened keys in [2] cannot themselves have children, it= becomes important to understand whether we can select enough of them for a= n HKD design in MLS to have a meaningful impact, and how this selection/pot= ential caching of hardened keys would work.

&= gt; [...] means that Alice must refrain from ever using the parent extended= public key has a signing key, but must instantiate signing keys from the n= + 0 epoch.=C2=A0=C2=A0

This could also be a= solution, I suppose, but it sounds like it would result in weaker "si= gning forward secrecy" (or whatever we're calling this property) t= han focusing on hardened keys, although I'm frankly not sure off the to= p of my head.

Nadim Kobeis= si
Symbolic Software=C2=A0=E2=80=A2 h= ttps://symbolic.software
Sent from office


On Fri, Oc= t 12, 2018 at 10:03 PM Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Nadim,

= I suspect I'm missing something simple here in your proposal.=C2=A0 Acc= ording to your reference 2, one of the issues with the derivation of this t= ype of hierarchical key is:

=C2=A0that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and=20 thus every private and public key descending from it). This means that=20 extended public keys must be treated more carefully than regular public=20 keys. It is also the reason for the existence of hardened keys, and why they=20 are used for the account level in the tree. This way, a leak of=20 account-specific (or below) private key never risks compromising the=20 master or other accounts.

What I thin= k that means is that if an attacker ever gets access to both an extended pu= blic key and any extended private key, we have lost forward secrecy for all= the MLS communications covered by any keys derived from any of the epoch p= airs.=C2=A0 Is that correct?

This appears to make = handling required of the parent extended public key roughly equivalent to t= he handling of a private key, so that your step:

A= lice sends a public signing key to Bob during epoch n.

=
means that Alice must refrain from ever using the parent extended publ= ic key has a signing key, but must instantiate signing keys from the n + 0 = epoch.=C2=A0

Is that a correct understanding?=

Thanks,

Ted


= On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi <nadim@symbolic.software> wrote= :
Hello = everyone,

I've been working on adapting Hierarchical= Key Derivation (HKD) in order to obtain some kind of ephemeral signatures = that may be useful in MLS. I've arrived at a point where I'm optimi= stic that this is a direction worth pursuing and might indeed be a solution= to this problem.

HKD was at some point a candidat= e for how signature keys are managed per epoch in the Tor Hidden Service de= sign [0]. HKD logic has also been implemented in Bitcoin wallets for a whil= e now [1]. HKD constructions can be also derived from existing popular fast= signature algorithms such as Ed25519 with minimal changes [2], making them= an easy fit for MLS. Very simply, the functionality that HKD signature sch= emes bring to MLS is the following:
  • Alice sends a public = signing key to Bob during epoch n.
  • At the onset of epoch n+1, B= ob is able to immediately calculate Alice's public signing key for epoc= h n+1 based purely on his knowledge of Alice's public signing key for e= poch 0. Alice doesn't need to send new signing key information to Bob.<= /li>
  • At this point, Bob can delete Alice's public signing key for ep= och n.
  • More importantly, Alice herself can delete Alice's priva= te signing key for epoch n, keeping only her private signing key for epoch = n+1.
The way that this could work in MLS would be heavily bas= ed on HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and inste= ad will point out the relevant sections (which are short, well-written and = worth reading:)
  • Section 2 describes the original co= ncept as used for Bitcoin wallet derivation.
  • Section 4 describes th= e modifications to Ed25519 to enable HKD constructions.
  • Section 5 d= escribes how private and public child keys are generated (Fig. 1 is also he= lpful.)
My questions:
  • How are we deri= ving epoch identifiers? Are they simply counters, or each epoch identified = by a nonce that's communicated confidentially? If you read [2], you'= ;ll see why this can be important.
  • Performance impact seems to be n= egligible for Montgomery-based signing primitives, but I'm interested i= n more insight on this.
  • Is anyone else interested in having a stand= ard HDKeys-Ed25519=C2=A0implementation? I've been working on one in Jav= aScript and plan to eventually also write one in Go. Perhaps Richard would = like to help with a C++ version?
  • I'm also interested in hearing= your thoughts on this generally.
During the interim me= eting (as well as before it), it was frequently discussed how ephemeral sig= natures may be useful for MLS. This also appears to be slated as a discussi= on topic for IETF 103, so it would be great if we could continue the discus= sion there as well.=C2=A0

References:
[0]=C2=A0https://gitweb.torproject.org/torspec.= git/tree/proposals/224-rend-spec-ng.txt#n1979

Nadim Kobeissi
Sy= mbolic Software=C2=A0= =E2=80=A2 https://= symbolic.software
Sent from office
=
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

<= /div>
--0000000000008771d5057815b582-- From nobody Mon Oct 15 16:27:49 2018 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 0A96E124BE5 for ; Mon, 15 Oct 2018 16:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ofmxccuYwtz3 for ; Mon, 15 Oct 2018 16:27:46 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A601126F72 for ; Mon, 15 Oct 2018 16:27:46 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id DAD4B1D06DD for ; Mon, 15 Oct 2018 16:27:14 -0700 (PDT) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by c8a.amsl.com (Postfix) with ESMTPSA id B30841D06DB for ; Mon, 15 Oct 2018 16:27:14 -0700 (PDT) Received: by mail-it1-f177.google.com with SMTP id i76-v6so29999301ita.3 for ; Mon, 15 Oct 2018 16:27:45 -0700 (PDT) X-Gm-Message-State: ABuFfog8kdf+9nKgK7lCAGal+3bptJA/0bn0xi+Igcu6Hly9S1kzoq6G 0d4e12jQnDx1j6yxBKQ1Z/8yKE7otMkqNOl5C8s= X-Google-Smtp-Source: ACcGV63bIqy61frMITLgV2VKYmf2ptZ+BPl0IXL0sv47HMxN2IIUrmcKw1lET58OpuzTatw3U32IjSiJlbsmNOEvib0= X-Received: by 2002:a24:670a:: with SMTP id u10-v6mr14171492itc.114.1539646065241; Mon, 15 Oct 2018 16:27:45 -0700 (PDT) MIME-Version: 1.0 From: Glen Date: Mon, 15 Oct 2018 16:27:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [MLS] Resend Request - Re: Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 23:27:48 -0000 Dear MLS list users... Over this past weekend, the IETF was hit with a flood of forged emails sent to many lists and aliases demanding that money be sent to a "bitcoin wallet" in exchange for the deletion of compromising videos of accountholders' personal activities. Obviously it was just junk spam, but the level was quite high. To mitigate it, we inserted a temporary blocking rule for the phrase "bitcoin wallet" into the global spam system, preventing such email from flowing through, based on the strong match for the spam, and the certain knowledge that the IETF does not write standards for bitcoin wallets. Just now, Sean contacted IETF-ACTION about some missing messages to this list over the weekend. In checking the problem, I noted that earlier messages in this thread said, in part: > HKD logic has also been implemented in Bitcoin wallets for a while now Like winning the lottery, this (I thought) improbable phrase matched our rule and caused any replies quoting this phrase to be discarded by our spam system. In the hope that the attack is over, I've now taken out this rule. If you sent a reply to the above-mentioned thread over the weekend, and don't see it in the list archive here: https://mailarchive.ietf.org/arch/browse/mls/ then please resend your email to the list at this time. It should go through without issue now. I apologize for the inconvenience. Glen -- Glen Barney IT Director AMS (IETF Secretariat) From nobody Mon Oct 15 17:03:00 2018 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 5AD2A1271FF for ; Mon, 15 Oct 2018 17:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 qVhjbSmOu8hL for ; Mon, 15 Oct 2018 17:02:53 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 995AC124C04 for ; Mon, 15 Oct 2018 17:02:53 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id o14so20741866oth.4 for ; Mon, 15 Oct 2018 17:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=j4JO9BIe13YIbkN8IdkmIg4LpDhUc6DGLSshDrpChW8=; b=qY975x1vu78CSDlGP6d4zR/dgZ0s9ZjmNz4zRcd5OpjDVaOCisYAzoMXajLI+pxqHc gnxM3nUHyswMp6SPaUWDAbsJOzKeqNL/VwYFgPqG0giLYyFoZEQnPzZfRO9vOiNK4ac6 Yr9gOSr6igOIyPlPt9x6NojlKyayXz/EH8c/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=j4JO9BIe13YIbkN8IdkmIg4LpDhUc6DGLSshDrpChW8=; b=ukHN4quQZsgEUsuUXlkaI6TmgpYt870q5R6wg4/Nr+aEYoqX0HJ8M/V9ikNc74zzBo VwIw+4l65aweyltumjrU3xkbiF5hcadYpBVgGWb2dG7KR5Z2pBOiQQH06GOWvZmEuOdc +ExwJxrDpm6uyTMDcJCsxTbxDL8BrlkZyKNQYbX1aB5khcgK4YiPG7efbfzIW+FPJLuG j5Yft72rHNeo+U+rqWZ8hqbLvdqZJUhE4/jnPNxzZqX3Bac/3e5uVDriKft88u7+sqOA wzGLy6poAnaYesspFnj+Hch5kR2QtGkMm1/2OnHLuAgU/wuwVEPI1e9n2eiBY7vG6jmB XvYA== X-Gm-Message-State: ABuFfohUdIPwBdmxGfH8Izl7MblqNNcL10Rr/Kq0UbyVOe84WLc1r6tj BEkAYme8HTPlcoku+kXBVH+Ym0getrCL9rDg0VZBA4zYjnK/Yw== X-Google-Smtp-Source: ACcGV61P8CXrR7gPsed0cXPUpRGw99MOxsrZYwObmZxEsnUpYck3JcA4o9ehxznzsCgmiOyLKdCKDg7wsms9dfYAv5U= X-Received: by 2002:a9d:11f5:: with SMTP id y50mr12866485oty.306.1539648172608; Mon, 15 Oct 2018 17:02:52 -0700 (PDT) MIME-Version: 1.0 References: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> In-Reply-To: From: Brendan McMillion Date: Mon, 15 Oct 2018 17:02:40 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000068661d05784d46f9" Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 00:02:59 -0000 --00000000000068661d05784d46f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > We'd need to know the number of epochs we're allowing for this MLS session in advance. I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a tree c= onstruction that allows an unbounded number of intervals and fast setup. The root key would sign only two children: a left child which is the root of a tree of height 1 whose leaf(s) are used for signing data, and a right child. Once the left child is used up, the right child signs two children in the same way the root key did, but now the left child is the root of a tree of height 2. Every time you have to use the right-most node, the left child gets twice as large. Here=E2=80=99s a diagram, if the description isn=E2=80=99t clear: https://i.imgur.com/DosZ3Sf.png So the signer=E2=80=99s private key and signatures are proportional to log(= T), the current epoch count. > We're simply trying to limit the impact of device compromise. We're able to do this more easily for encryption keys, but signatures are more tricky. I agree it's valuable that if participant A is offline for a long time and B=E2=80=99s key is compromised at epoch n, then when A comes back online sh= e can still trust everything signed by B in previous epochs. I think you can also get something similar to post-compromise security with the above construction: Once B is no longer compromised, he would continue walking the tree and generating new keypairs where the attacker doesn=E2=80=99t kno= w the private keys. So to sign a message, the attacker would need to certify their own keypairs. This can be prevented by all the group participants refusing to accept more than one distinct public key per node in the tree. On Fri, Oct 12, 2018 at 10:45 PM Nadim Kobeissi wrote: > Dear Brendan, > Your proposed scheme could work, too. The disadvantages it presents, it > seems to me, aren't severe: > > - Your proposed scheme seems to have a larger performance overhead: > each leaf keypair/epoch tuple would have to be generated and signed in > advance. > - We'd need to know the number of epochs we're allowing for this MLS > session in advance. > - We may not be able to parametrize the choice of upcoming signature > keys based on a dynamically generated epoch identifier with the same d= egree > of freedom that HKD would give us. > > > Also, since I didn=E2=80=99t go to the interim, what problem do > forward-signature signature schemes solve for MLS? > > We're simply trying to limit the impact of device compromise. We're able > to do this more easily for encryption keys, but signatures are more trick= y. > > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software > Sent from office > > > On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillion > wrote: > >> Hey Nadim >> >> I believe the typical way to build a forward-secure signature scheme is >> with a certification tree. You=E2=80=99d: >> >> 1. Generate a root keypair. >> 2. Generate N leaf keypairs. >> 3. Sign each leaf keypair and the epoch it is meant to be used in, with >> the root keypair. >> 4. Delete the root private key. >> >> Your root public key is what=E2=80=99s distributed to everybody. A signa= ture at a >> given epoch is the tuple: (leaf public key, sig over leaf key from root >> key, sig over data from leaf key). >> >> Could you talk about why a scheme like the above is not suitable here? >> Also, since I didn=E2=80=99t go to the interim, what problem do forward-= signature >> signature schemes solve for MLS? >> >> On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi >> wrote: >> >> Dear Ted, >> Thanks for your quick read-through! >> >> You seem to be referring to [1], not to [2] as you wrote. In [1], the >> concept of "hardened" keys is defined and is also ported by [2] into >> Ed25519. >> >> > What I think that means is that if an attacker ever gets access to bot= h >> an extended public key and any extended private key, we have lost forwar= d >> secrecy for all the MLS communications covered by any keys derived from = any >> of the epoch pairs. Is that correct? >> >> This is correct in the sense that it allows you to rewind the key >> derivation chain. However, this does not apply to hardened keys. This is >> precisely why I'm trying to understand how epoch identifiers are agreed >> upon, in order to see whether we can use them to restrict the HKD logic = to >> use only "hardened" keys in MLS. Since hardened keys in [2] cannot >> themselves have children, it becomes important to understand whether we = can >> select enough of them for an HKD design in MLS to have a meaningful impa= ct, >> and how this selection/potential caching of hardened keys would work. >> >> > [...] means that Alice must refrain from ever using the parent extende= d >> public key has a signing key, but must instantiate signing keys from the= n >> + 0 epoch. >> >> This could also be a solution, I suppose, but it sounds like it would >> result in weaker "signing forward secrecy" (or whatever we're calling th= is >> property) than focusing on hardened keys, although I'm frankly not sure = off >> the top of my head. >> >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software >> Sent from office >> >> >> On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie wrote: >> >>> Hi Nadim, >>> >>> I suspect I'm missing something simple here in your proposal. Accordin= g >>> to your reference 2, one of the issues with the derivation of this type= of >>> hierarchical key is: >>> >>> that knowledge of a parent extended public key plus any non-hardened >>>> private key descending from it is equivalent to knowing the parent ext= ended >>>> private key (and thus every private and public key descending from it)= . >>>> This means that extended public keys must be treated more carefully th= an >>>> regular public keys. It is also the reason for the existence of harden= ed >>>> keys, and why they are used for the account level in the tree. This wa= y, a >>>> leak of account-specific (or below) private key never risks compromisi= ng >>>> the master or other accounts. >>>> >>> >>> What I think that means is that if an attacker ever gets access to both >>> an extended public key and any extended private key, we have lost forwa= rd >>> secrecy for all the MLS communications covered by any keys derived from= any >>> of the epoch pairs. Is that correct? >>> >>> This appears to make handling required of the parent extended public ke= y >>> roughly equivalent to the handling of a private key, so that your step: >>> >>> Alice sends a public signing key to Bob during epoch n. >>> >>> means that Alice must refrain from ever using the parent extended publi= c >>> key has a signing key, but must instantiate signing keys from the n + 0 >>> epoch. >>> >>> Is that a correct understanding? >>> >>> Thanks, >>> >>> Ted >>> >>> >>> On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi >>> wrote: >>> >>>> Hello everyone, >>>> >>>> I've been working on adapting Hierarchical Key Derivation (HKD) in >>>> order to obtain some kind of ephemeral signatures that may be useful i= n >>>> MLS. I've arrived at a point where I'm optimistic that this is a direc= tion >>>> worth pursuing and might indeed be a solution to this problem. >>>> >>>> HKD was at some point a candidate for how signature keys are managed >>>> per epoch in the Tor Hidden Service design [0]. HKD logic has also bee= n >>>> implemented in Bitcoin wallets for a while now [1]. HKD constructions = can >>>> be also derived from existing popular fast signature algorithms such a= s >>>> Ed25519 with minimal changes [2], making them an easy fit for MLS. Ver= y >>>> simply, the functionality that HKD signature schemes bring to MLS is t= he >>>> following: >>>> >>>> - Alice sends a public signing key to Bob during epoch n. >>>> - At the onset of epoch n+1, Bob is able to immediately calculate >>>> Alice's public signing key for epoch n+1 based purely on his knowle= dge of >>>> Alice's public signing key for epoch 0. Alice doesn't need to send = new >>>> signing key information to Bob. >>>> - At this point, Bob can delete Alice's public signing key for >>>> epoch n. >>>> - More importantly, Alice herself can delete Alice's private >>>> signing key for epoch n, keeping only her private signing key for e= poch n+1. >>>> >>>> The way that this could work in MLS would be heavily based on >>>> HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead wi= ll >>>> point out the relevant sections (which are short, well-written and wor= th >>>> reading:) >>>> >>>> - Section 2 describes the original concept as used for Bitcoin >>>> wallet derivation. >>>> - Section 4 describes the modifications to Ed25519 to enable HKD >>>> constructions. >>>> - Section 5 describes how private and public child keys are >>>> generated (Fig. 1 is also helpful.) >>>> >>>> My questions: >>>> >>>> - How are we deriving epoch identifiers? Are they simply counters, >>>> or each epoch identified by a nonce that's communicated confidentia= lly? If >>>> you read [2], you'll see why this can be important. >>>> - Performance impact seems to be negligible for Montgomery-based >>>> signing primitives, but I'm interested in more insight on this. >>>> - Is anyone else interested in having a standard >>>> HDKeys-Ed25519 implementation? I've been working on one in JavaScri= pt and >>>> plan to eventually also write one in Go. Perhaps Richard would like= to help >>>> with a C++ version? >>>> - I'm also interested in hearing your thoughts on this generally. >>>> >>>> During the interim meeting (as well as before it), it was frequently >>>> discussed how ephemeral signatures may be useful for MLS. This also ap= pears >>>> to be slated as a discussion topic for IETF 103, so it would be great = if we >>>> could continue the discussion there as well. >>>> >>>> References: >>>> [0] >>>> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec= -ng.txt#n1979 >>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki >>>> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf >>>> >>>> Nadim Kobeissi >>>> Symbolic Software =E2=80=A2 https://symbolic.software >>>> Sent from office >>>> _______________________________________________ >>>> 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 >> >> >> --00000000000068661d05784d46f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> We'd ne= ed to know the number of epochs we're allowing for this MLS session in = advance.

I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a tree construction= that allows an unbounded number of intervals and fast setup. The root key=20 would sign only two children: a left child which is the root of a tree=20 of height 1 whose leaf(s) are used for signing data, and a right child.=20 Once the left child is used up, the right child signs two children in=20 the same way the root key did, but now the left child is the root of a=20 tree of height 2. Every time you have to use the right-most node, the=20 left child gets twice as large.=C2=A0Here=E2=80=99s=C2=A0a diagram, if the = description isn=E2=80=99t clear: https://i.imgur.com/DosZ3Sf.png

So the s= igner=E2=80=99s private key and signatures are proportional to log(T), the = current epoch count.

> We're simply trying to limit the impact of device compromise. We'r= e=20 able to do this more easily for encryption keys, but signatures are more tricky.

I agree it's valuable that if= =20 participant A is offline for a long time and B=E2=80=99s key is compromised= at=20 epoch n, then when A comes back online she can still trust everything=20 signed by B in previous epochs. I think you can also get something=20 similar to post-compromise security with the above construction: Once B=20 is no longer compromised, he would continue walking the tree and=20 generating new keypairs where the attacker doesn=E2=80=99t know the private= =20 keys. So to sign a message, the attacker would need to certify their own keypairs. This can be prevented by all the group participants refusing=20 to accept more than one distinct public key per node in the tree.

On Fri, Oct 12, 2018 at 1= 0:45 PM Nadim Kobeissi <nadim@symbolic.software> wrote:
Dear Brendan,
Your proposed= scheme could work, too. The disadvantages it presents, it seems to me, are= n't severe:
  • Your proposed scheme seems to hav= e a larger performance overhead: each leaf keypair/epoch tuple would have t= o be generated and signed in advance.
  • We'd need to know the num= ber of epochs we're allowing for this MLS session in advance.
  • W= e may not be able to parametrize the choice of upcoming signature keys base= d on a dynamically generated epoch identifier with the same degree of freed= om that HKD would give us.
> Also, since I didn=E2=80=99t go to the = interim, what problem do forward-signature signature schemes solve for MLS?=

We're simply trying to limit the = impact of device compromise. We're able to do this more easily for encr= yption keys, but signatures are more tricky.

Nadim Kobeissi
Symbolic Software=C2=A0=E2=80=A2 https://symbolic.software
Sent from office


=
On Sat, Oct 13, 2018 at 2:43 AM= Brendan McMillion <brendan@cloudflare.com> wrote:
Hey Nadim

I believe the typical way to build a forward-= secure signature scheme is with a certification tree. You=E2=80=99d:
<= div>
1. Generate a root keypair.
2. Generate N leaf= keypairs.
3. Sign each leaf keypair and the epoch it is meant to= be used in, with the root keypair.
4. Delete the root private ke= y.

Your root public key is what=E2=80=99s distribu= ted to everybody. A signature at a given epoch is the tuple: (leaf public k= ey, sig over leaf key from root key, sig over data from leaf key).

Could you talk about why a scheme like the above is not su= itable here? Also, since I didn=E2=80=99t go to the interim, what problem d= o forward-signature signature schemes solve for MLS?

On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi <= ;nadim@symboli= c.software> wrote:

Dear Ted,
T= hanks for your quick read-through!

You seem to be = referring to [1], not to [2] as you wrote. In [1], the concept of "har= dened" keys is defined and is also ported by [2] into Ed25519.

> What I think that means is that if an attacker ever = gets access to both an extended public key and any extended private key, we= have lost forward secrecy for all the MLS communications covered by any ke= ys derived from any of the epoch pairs.=C2=A0 Is that correct?
=
This is correct in the sense that it allows you to rewind th= e key derivation chain. However, this does not apply to hardened keys. This= is precisely why I'm trying to understand how epoch identifiers are ag= reed upon, in order to see whether we can use them to restrict the HKD logi= c to use only "hardened" keys in MLS. Since hardened keys in [2] = cannot themselves have children, it becomes important to understand whether= we can select enough of them for an HKD design in MLS to have a meaningful= impact, and how this selection/potential caching of hardened keys would wo= rk.

> [...] means that Alice must refrain = from ever using the parent extended public key has a signing key, but must = instantiate signing keys from the n + 0 epoch.=C2=A0=C2=A0
=
This could also be a solution, I suppose, but it sounds like= it would result in weaker "signing forward secrecy" (or whatever= we're calling this property) than focusing on hardened keys, although = I'm frankly not sure off the top of my head.

=
Nadim Kobeissi
Symbolic Software=C2=A0=E2=80=A2 https://symbolic.software
Sent from office<= /span>


On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie <ted.ietf@gmail.com> wrote:
= Hi Nadim,

I suspect I'm missing something simp= le here in your proposal.=C2=A0 According to your reference 2, one of the i= ssues with the derivation of this type of hierarchical key is:
=C2=A0that k= nowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and=20 thus every private and public key descending from it). This means that=20 extended public keys must be treated more carefully than regular public=20 keys. It is also the reason for the existence of hardened keys, and why they=20 are used for the account level in the tree. This way, a leak of=20 account-specific (or below) private key never risks compromising the=20 master or other accounts.

What I thin= k that means is that if an attacker ever gets access to both an extended pu= blic key and any extended private key, we have lost forward secrecy for all= the MLS communications covered by any keys derived from any of the epoch p= airs.=C2=A0 Is that correct?

This appears to make = handling required of the parent extended public key roughly equivalent to t= he handling of a private key, so that your step:

A= lice sends a public signing key to Bob during epoch n.

=
means that Alice must refrain from ever using the parent extended publ= ic key has a signing key, but must instantiate signing keys from the n + 0 = epoch.=C2=A0

Is that a correct understanding?=

Thanks,

Ted


= On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi <nadim@symbolic.software> wrote= :
Hello = everyone,

I've been working on adapting Hierarchical= Key Derivation (HKD) in order to obtain some kind of ephemeral signatures = that may be useful in MLS. I've arrived at a point where I'm optimi= stic that this is a direction worth pursuing and might indeed be a solution= to this problem.

HKD was at some point a candidat= e for how signature keys are managed per epoch in the Tor Hidden Service de= sign [0]. HKD logic has also been implemented in Bitcoin wallets for a whil= e now [1]. HKD constructions can be also derived from existing popular fast= signature algorithms such as Ed25519 with minimal changes [2], making them= an easy fit for MLS. Very simply, the functionality that HKD signature sch= emes bring to MLS is the following:
  • Alice sends a public = signing key to Bob during epoch n.
  • At the onset of epoch n+1, B= ob is able to immediately calculate Alice's public signing key for epoc= h n+1 based purely on his knowledge of Alice's public signing key for e= poch 0. Alice doesn't need to send new signing key information to Bob.<= /li>
  • At this point, Bob can delete Alice's public signing key for ep= och n.
  • More importantly, Alice herself can delete Alice's priva= te signing key for epoch n, keeping only her private signing key for epoch = n+1.
The way that this could work in MLS would be heavily bas= ed on HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and inste= ad will point out the relevant sections (which are short, well-written and = worth reading:)
  • Section 2 describes the original co= ncept as used for Bitcoin wallet derivation.
  • Section 4 describes th= e modifications to Ed25519 to enable HKD constructions.
  • Section 5 d= escribes how private and public child keys are generated (Fig. 1 is also he= lpful.)
My questions:
  • How are we deri= ving epoch identifiers? Are they simply counters, or each epoch identified = by a nonce that's communicated confidentially? If you read [2], you'= ;ll see why this can be important.
  • Performance impact seems to be n= egligible for Montgomery-based signing primitives, but I'm interested i= n more insight on this.
  • Is anyone else interested in having a stand= ard HDKeys-Ed25519=C2=A0implementation? I've been working on one in Jav= aScript and plan to eventually also write one in Go. Perhaps Richard would = like to help with a C++ version?
  • I'm also interested in hearing= your thoughts on this generally.
During the interim me= eting (as well as before it), it was frequently discussed how ephemeral sig= natures may be useful for MLS. This also appears to be slated as a discussi= on topic for IETF 103, so it would be great if we could continue the discus= sion there as well.=C2=A0
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

<= /div>
--00000000000068661d05784d46f9-- From nobody Mon Oct 15 17:34:49 2018 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 A0899126F72 for ; Mon, 15 Oct 2018 17:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0g5HA4ia8Qe for ; Mon, 15 Oct 2018 17:34:45 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 A0EF5126CB6 for ; Mon, 15 Oct 2018 17:34:45 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id w67so20777861ota.7 for ; Mon, 15 Oct 2018 17:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KX/iHk6hNTnheUWY59Y72cSm28xOYL7vEOVxmUG8iJQ=; b=K+XyvkVk4WJ8vl7RmcvXyhh1XdUOLObgsGr9nTQ2KCucmjWPlxcTQtrCenNAed8q+E vKvgSW1/dBjrQioNeI4uMIT7dN9ojYsQH8/y8BhtNvS7lYhxncfC4+uooqUY8utAiUAf cAGKDUYYBvODJ+U5E/pVFyJYgx0k5ZCo3ZX3lvY4xmALsTOs07l2JeuhQga1toRjfSCU /zypzumP2F+qpP9Mhxqrhgj3fBWaky69VkAuZoCEuCeYCLteROA9t5qAt4x8xm7Vb9jf WwS/MilEj5x8W9OBdiMfrZkIG+p1MlA5aaUZLzNDzjFNCcYylAl6E+RMN7s+lXXq1PDy 88Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KX/iHk6hNTnheUWY59Y72cSm28xOYL7vEOVxmUG8iJQ=; b=ZbJnn9gKOIT8a4bmqqOTzbRXTaGi5hUJUVg7S5DDrYdJweUNfgk+vlaATdOjD7tatr 6alDLmsP4NFgu+4D/xoWsA3BjKAdrCd6HqEXH92KGOuoUUBrEht9Z9rs49pQU+24yKcs iALAG0H42ex+3L3ADMSAx66ZMsSW/yoZ6mspZ+O6y+pTHJfuvlUCjCb4MPIXARgsf+Ln jt4HlwmHowGgX1S0GgV1rFWOuRa/lZ2t5DcrhxsibrpMMSEAtyrEepz8c8iDoEEZPCUz JMQDd7tBhq7fDbNDM0ZrRr57tj9WtuZAc8FhgFfeKXfucyThnDLW41GhnQrFRZiFNYYc dagA== X-Gm-Message-State: ABuFfoi+176HLk3pSJ1SM0OEuA+wzLMzaKAsAiMEArGSxxx7N2Wac6Ia sQmWnnCJpHeybqNbjHklANHNhwgurEpDh3OKtwo4Ag== X-Google-Smtp-Source: ACcGV62qD0B240Tz8F9U+SqYJEW9Y2+VMpmuRmqQZ5HwicOn8qgGYQD8HkWMkrcdMVtcu3qI2lQYiAgObAi3U5ZVfO8= X-Received: by 2002:a9d:2377:: with SMTP id k52mr12722880otd.238.1539650084693; Mon, 15 Oct 2018 17:34:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 15 Oct 2018 20:34:26 -0400 Message-ID: To: Glen Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000006087a905784db800" Archived-At: Subject: Re: [MLS] Resend Request - Re: Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 00:34:48 -0000 --0000000000006087a905784db800 Content-Type: text/plain; charset="UTF-8" Thank you for your diligence, Glen. Glad we got the false positive addressed. On Mon, Oct 15, 2018 at 7:28 PM Glen wrote: > Dear MLS list users... > > Over this past weekend, the IETF was hit with a flood of forged emails > sent to many lists and aliases demanding that money be sent to a > "bitcoin wallet" in exchange for the deletion of compromising videos > of accountholders' personal activities. Obviously it was just junk > spam, but the level was quite high. To mitigate it, we inserted a > temporary blocking rule for the phrase "bitcoin wallet" into the > global spam system, preventing such email from flowing through, based > on the strong match for the spam, and the certain knowledge that the > IETF does not write standards for bitcoin wallets. > > Just now, Sean contacted IETF-ACTION about some missing messages to > this list over the weekend. In checking the problem, I noted that > earlier messages in this thread said, in part: > > > HKD logic has also been implemented in Bitcoin wallets for a while now > > Like winning the lottery, this (I thought) improbable phrase matched > our rule and caused any replies quoting this phrase to be discarded by > our spam system. > > In the hope that the attack is over, I've now taken out this rule. > > If you sent a reply to the above-mentioned thread over the weekend, > and don't see it in the list archive here: > > https://mailarchive.ietf.org/arch/browse/mls/ > > then please resend your email to the list at this time. It should go > through without issue now. > > I apologize for the inconvenience. > > Glen > -- > Glen Barney > IT Director > AMS (IETF Secretariat) > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000006087a905784db800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your diligence, Glen.=C2=A0 Glad we got the = false positive addressed.

On Mon, Oct 15, 2018 at 7:28 PM Glen <glen@amsl.com> wrote:
https://mailarchive.ietf.org/arch/browse/mls/

then please resend your email to the list at this time.=C2=A0 It should go<= br> through without issue now.

I apologize for the inconvenience.

Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000006087a905784db800-- From nobody Tue Oct 16 06:51:53 2018 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 04DE6130E0A for ; Tue, 16 Oct 2018 06:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 RvNpQo1NpsQi for ; Tue, 16 Oct 2018 06:51:32 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6365A130E0C for ; Tue, 16 Oct 2018 06:51:31 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id d15-v6so21396883edq.6 for ; Tue, 16 Oct 2018 06:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=LczJu0tdEdt/SFxVkVTrTKxQoIxRueZxpvyz5w03M7k=; b=vdopvciE0+bpKrK8cl1Jl5sRzUWuuRLGKO7qQxt3tZ74ssFKlFwpZaSOmSyxNG0RoP NTBuKpb53lCHv/kWoQF7ua/uVFN5kkGG55qzuWQBkSQTC3wZlgJrqYza3CO87EojaJ1n zODmVJgKAIxIfDC6NAklSe6xRaJC4dQUIBawGJjcwz8whzAwU/65/8LDh/ETcaWkDLFm Yi85ZOzr11w3cmPWzgLt7io/paE+5Dh6pjhWv/FrJlwlcOGgxgyojww87/J5+uwpQ0Ik xu9SdIjubC7SXxpVS+hCz4MsXd66M3EPJrownDgZEbhFde9/5hf1pfPSxn9V11d15LWs 93Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=LczJu0tdEdt/SFxVkVTrTKxQoIxRueZxpvyz5w03M7k=; b=NSqSwkpYbkSlzJHjfiK56BJMA73bBAAHgBvkSrhtM72nHJ9DulX6qIpdzdwJZ5yKzk B/sS4cbtsD6au83l3AwZFEhs5h0qhmy96Oy+7dfifHDmAdhpDsGkqids07z8HThuZaOc zABMFLva5N5mI3geMBEcj6wvc102YolGaWGLy6elpNfbjKNK3cFNQ/J3Ci+E6qygUKPq a5l6JFr0BGiGK2miwknfQhW27UZV/x08QrgfwjQVNLwgveSjJKGDnLchLNNzBCw74GxT GtvqXOjkSJ9UnTJu5LjoGMmnIqT8IJOydQoqyBxlUcqV++JbA/L4D2+ZhaO79yxvyMuP wnHg== X-Gm-Message-State: ABuFfojOiAl/JGpW4Kr8U0wJ4tj8NimhaLubXivELESlUnLIxZmpBk9o V4QifTCsPKmB0yhlV6ZGGz+iJJsFxXA= X-Google-Smtp-Source: ACcGV619JIvjdVVK/QLHrRPhOx0Fn3dpb/Q9N5mXUjLf0fQ8720ELAb906kuMMeS9w6zDCojj7kqVg== X-Received: by 2002:a17:906:7746:: with SMTP id o6-v6mr23805071ejn.48.1539697888906; Tue, 16 Oct 2018 06:51:28 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id s7-v6sm2965479eju.51.2018.10.16.06.51.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 06:51:27 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_07E8F347-DA10-44C2-B943-3CAF8D56E3BF" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 16 Oct 2018 15:51:26 +0200 References: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> To: mls@ietf.org In-Reply-To: Message-Id: <2B6A9B66-E834-44EB-B3F9-3C4A75482382@wire.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 13:51:51 -0000 --Apple-Mail=_07E8F347-DA10-44C2-B943-3CAF8D56E3BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It looks like my email was caught by the temporary anti-spam rule. So = here it is again: Hi all, =20 I'd like to give some more context around this. The subject of the = discussion is Forward Secrecy (FS) and Post-Compromise Security (PCS) = for message authentication. The subject is rather well defined for = message encryption (as Nadim pointed out) thanks to a clear definition = PCS and distinction between FS and PCS given in [1]. I think it would be helpful to define exactly what security guarantees = we want to introduce with respect to FS and PCS for message = authentication. Currently, the MLS Arcitecture draft [2] states "Each = member device owns a long term identity key pair that uniquely defines = its identity to other Members of the Group." in 2.1.=20 With that in mind, we need to be very specific on what "compromise" = actually means w.r.t. authentication. I.e. if we don't use long-term = identity keys to sign messages directly (and rather use ephemeral = signatures as proposed by Nadim and Brendan) but still keep long-term = keys on the devices, a device compromise is not the same as a = cryptanalytic compromise. In the former case the long-term key is = compromised, in the latter it is not. To illustrate this with encryption PCS: If an attacker compromises Alice's device (and copies all secret values = from it), the attacker will be able to passively eavesdrop on the = conversation. Alice can send an Update handshake message from her compromised device = to the group to introduce freshness and force everyone to use a new = group secret that includes that freshness. This will exclude the = attacker, passive eavesdropping won't be possible anymore. The same would also be true for weaker forms of compromise, where only a = partial state has been compromised through e.g. cryptanalysis. Raphael References: [1] https://eprint.iacr.org/2016/221.pdf = [2] https://tools.ietf.org/html/draft-omara-mls-architecture-01 = > On 16 Oct 2018, at 02:02, Brendan McMillion = wrote: >=20 > > We'd need to know the number of epochs we're allowing for this MLS = session in advance. >=20 > I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a = tree construction that allows an unbounded number of intervals and fast = setup. The root key would sign only two children: a left child which is = the root of a tree of height 1 whose leaf(s) are used for signing data, = and a right child. Once the left child is used up, the right child signs = two children in the same way the root key did, but now the left child is = the root of a tree of height 2. Every time you have to use the = right-most node, the left child gets twice as large. Here=E2=80=99s a = diagram, if the description isn=E2=80=99t clear: = https://i.imgur.com/DosZ3Sf.png >=20 > So the signer=E2=80=99s private key and signatures are proportional to = log(T), the current epoch count. >=20 > > We're simply trying to limit the impact of device compromise. We're = able to do this more easily for encryption keys, but signatures are more = tricky. >=20 > I agree it's valuable that if participant A is offline for a long time = and B=E2=80=99s key is compromised at epoch n, then when A comes back = online she can still trust everything signed by B in previous epochs. I = think you can also get something similar to post-compromise security = with the above construction: Once B is no longer compromised, he would = continue walking the tree and generating new keypairs where the attacker = doesn=E2=80=99t know the private keys. So to sign a message, the = attacker would need to certify their own keypairs. This can be prevented = by all the group participants refusing to accept more than one distinct = public key per node in the tree. >=20 > On Fri, Oct 12, 2018 at 10:45 PM Nadim Kobeissi = wrote: > Dear Brendan, > Your proposed scheme could work, too. The disadvantages it presents, = it seems to me, aren't severe: > Your proposed scheme seems to have a larger performance overhead: each = leaf keypair/epoch tuple would have to be generated and signed in = advance. > We'd need to know the number of epochs we're allowing for this MLS = session in advance. > We may not be able to parametrize the choice of upcoming signature = keys based on a dynamically generated epoch identifier with the same = degree of freedom that HKD would give us. > > Also, since I didn=E2=80=99t go to the interim, what problem do = forward-signature signature schemes solve for MLS? >=20 > We're simply trying to limit the impact of device compromise. We're = able to do this more easily for encryption keys, but signatures are more = tricky. >=20 > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software = > Sent from office >=20 >=20 > On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillion = > wrote: > Hey Nadim >=20 > I believe the typical way to build a forward-secure signature scheme = is with a certification tree. You=E2=80=99d: >=20 > 1. Generate a root keypair. > 2. Generate N leaf keypairs. > 3. Sign each leaf keypair and the epoch it is meant to be used in, = with the root keypair. > 4. Delete the root private key. >=20 > Your root public key is what=E2=80=99s distributed to everybody. A = signature at a given epoch is the tuple: (leaf public key, sig over leaf = key from root key, sig over data from leaf key). >=20 > Could you talk about why a scheme like the above is not suitable here? = Also, since I didn=E2=80=99t go to the interim, what problem do = forward-signature signature schemes solve for MLS? >=20 >> On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi > wrote: >>=20 >> Dear Ted, >> Thanks for your quick read-through! >>=20 >> You seem to be referring to [1], not to [2] as you wrote. In [1], the = concept of "hardened" keys is defined and is also ported by [2] into = Ed25519. >>=20 >> > What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >>=20 >> This is correct in the sense that it allows you to rewind the key = derivation chain. However, this does not apply to hardened keys. This is = precisely why I'm trying to understand how epoch identifiers are agreed = upon, in order to see whether we can use them to restrict the HKD logic = to use only "hardened" keys in MLS. Since hardened keys in [2] cannot = themselves have children, it becomes important to understand whether we = can select enough of them for an HKD design in MLS to have a meaningful = impact, and how this selection/potential caching of hardened keys would = work. >>=20 >> > [...] means that Alice must refrain from ever using the parent = extended public key has a signing key, but must instantiate signing keys = from the n + 0 epoch. =20 >>=20 >> This could also be a solution, I suppose, but it sounds like it would = result in weaker "signing forward secrecy" (or whatever we're calling = this property) than focusing on hardened keys, although I'm frankly not = sure off the top of my head. >>=20 >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software = >> Sent from office >>=20 >>=20 >> On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie > wrote: >> Hi Nadim, >>=20 >> I suspect I'm missing something simple here in your proposal. = According to your reference 2, one of the issues with the derivation of = this type of hierarchical key is: >>=20 >> that knowledge of a parent extended public key plus any non-hardened = private key descending from it is equivalent to knowing the parent = extended private key (and thus every private and public key descending = from it). This means that extended public keys must be treated more = carefully than regular public keys. It is also the reason for the = existence of hardened keys, and why they are used for the account level = in the tree. This way, a leak of account-specific (or below) private key = never risks compromising the master or other accounts. >>=20 >> What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >>=20 >> This appears to make handling required of the parent extended public = key roughly equivalent to the handling of a private key, so that your = step: >>=20 >> Alice sends a public signing key to Bob during epoch n. >>=20 >> means that Alice must refrain from ever using the parent extended = public key has a signing key, but must instantiate signing keys from the = n + 0 epoch. =20 >>=20 >> Is that a correct understanding? >>=20 >> Thanks, >>=20 >> Ted >>=20 >>=20 >> On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi = > wrote: >> Hello everyone, >>=20 >> I've been working on adapting Hierarchical Key Derivation (HKD) in = order to obtain some kind of ephemeral signatures that may be useful in = MLS. I've arrived at a point where I'm optimistic that this is a = direction worth pursuing and might indeed be a solution to this problem. >>=20 >> HKD was at some point a candidate for how signature keys are managed = per epoch in the Tor Hidden Service design [0]. HKD logic has also been = implemented in Bitcoin wallets for a while now [1]. HKD constructions = can be also derived from existing popular fast signature algorithms such = as Ed25519 with minimal changes [2], making them an easy fit for MLS. = Very simply, the functionality that HKD signature schemes bring to MLS = is the following: >> Alice sends a public signing key to Bob during epoch n. >> At the onset of epoch n+1, Bob is able to immediately calculate = Alice's public signing key for epoch n+1 based purely on his knowledge = of Alice's public signing key for epoch 0. Alice doesn't need to send = new signing key information to Bob. >> At this point, Bob can delete Alice's public signing key for epoch n. >> More importantly, Alice herself can delete Alice's private signing = key for epoch n, keeping only her private signing key for epoch n+1. >> The way that this could work in MLS would be heavily based on = HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead will = point out the relevant sections (which are short, well-written and worth = reading:) >> Section 2 describes the original concept as used for Bitcoin wallet = derivation. >> Section 4 describes the modifications to Ed25519 to enable HKD = constructions. >> Section 5 describes how private and public child keys are generated = (Fig. 1 is also helpful.) >> My questions: >> How are we deriving epoch identifiers? Are they simply counters, or = each epoch identified by a nonce that's communicated confidentially? If = you read [2], you'll see why this can be important. >> Performance impact seems to be negligible for Montgomery-based = signing primitives, but I'm interested in more insight on this. >> Is anyone else interested in having a standard HDKeys-Ed25519 = implementation? I've been working on one in JavaScript and plan to = eventually also write one in Go. Perhaps Richard would like to help with = a C++ version? >> I'm also interested in hearing your thoughts on this generally. >> During the interim meeting (as well as before it), it was frequently = discussed how ephemeral signatures may be useful for MLS. This also = appears to be slated as a discussion topic for IETF 103, so it would be = great if we could continue the discussion there as well.=20 >>=20 >> References: >> [0] = https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.= txt#n1979 = >> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki = >> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf = >>=20 >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software = >> Sent from office >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_07E8F347-DA10-44C2-B943-3CAF8D56E3BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = looks like my email was caught by the temporary anti-spam rule. So here = it is again:

Hi = all,
 
I'd like = to give some more context around this. The subject of the discussion is = Forward Secrecy (FS) and Post-Compromise Security (PCS) for message = authentication. The subject is rather well defined for message = encryption (as Nadim pointed out) thanks to a clear definition PCS and = distinction between FS and PCS given in [1].

I think it would be helpful to define = exactly what security guarantees we want to introduce with respect to FS = and PCS for message authentication. Currently, the MLS Arcitecture draft = [2] states "Each member device owns a long term identity key pair that = uniquely defines its identity to other Members of the Group." in = 2.1. 
With that in mind, we need to be very = specific on what "compromise" actually means w.r.t. authentication. I.e. = if we don't use long-term identity keys to sign messages directly (and = rather use ephemeral signatures as proposed by Nadim and Brendan) but = still keep long-term keys on the devices, a device compromise is not the = same as a cryptanalytic compromise. In the former case the long-term key = is compromised, in the latter it is not.

To illustrate this with encryption = PCS:
If an attacker compromises Alice's device (and = copies all secret values from it), the attacker will be able to = passively eavesdrop on the conversation.
Alice can = send an Update handshake message from her compromised device to the = group to introduce freshness and force everyone to use a new group = secret that includes that freshness. This will exclude the attacker, = passive eavesdropping won't be possible anymore.
The = same would also be true for weaker forms of compromise, where only a = partial state has been compromised through e.g. cryptanalysis.


Raphael

References:
[1] https://eprint.iacr.org/2016/221.pdf
[2] https://tools.ietf.org/html/draft-omara-mls-architecture-01=


On 16 = Oct 2018, at 02:02, Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> = wrote:

> We'd need to know the number of epochs we're = allowing for this MLS session in advance.

I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a tree = construction that allows an unbounded number of intervals and fast setup. The root key=20 would sign only two children: a left child which is the root of a tree=20= of height 1 whose leaf(s) are used for signing data, and a right child.=20= Once the left child is used up, the right child signs two children in=20 the same way the root key did, but now the left child is the root of a=20= tree of height 2. Every time you have to use the right-most node, the=20 left child gets twice as large. Here=E2=80=99s a diagram, if = the description isn=E2=80=99t clear: https://i.imgur.com/DosZ3Sf.png

So the signer=E2=80=99s = private key and signatures are proportional to log(T), the current epoch = count.

> We're simply trying to limit the impact of device compromise. We're=20 able to do this more easily for encryption keys, but signatures are more tricky.

I agree it's valuable that if=20 participant A is offline for a long time and B=E2=80=99s key is = compromised at=20 epoch n, then when A comes back online she can still trust everything=20 signed by B in previous epochs. I think you can also get something=20 similar to post-compromise security with the above construction: Once B=20= is no longer compromised, he would continue walking the tree and=20 generating new keypairs where the attacker doesn=E2=80=99t know the = private=20 keys. So to sign a message, the attacker would need to certify their own keypairs. This can be prevented by all the group participants refusing=20= to accept more than one distinct public key per node in the = tree.

On Fri, Oct 12, 2018 at 10:45 PM Nadim Kobeissi = <nadim@symbolic.software> wrote:
Dear Brendan,
Your proposed scheme could work, = too. The disadvantages it presents, it seems to me, aren't severe:
  • Your proposed scheme seems to have a larger = performance overhead: each leaf keypair/epoch tuple would have to be = generated and signed in advance.
  • We'd need to know = the number of epochs we're allowing for this MLS session in = advance.
  • We may not be able to parametrize the choice = of upcoming signature keys based on a dynamically generated epoch = identifier with the same degree of freedom that HKD would give = us.
> Also, since I didn=E2=80=99t = go to the interim, what problem do forward-signature signature schemes = solve for MLS?

We're simply trying to limit the impact of device compromise. = We're able to do this more easily for encryption keys, but signatures = are more tricky.

Nadim Kobeissi
Symbolic Software =E2=80=A2 https://symbolic.software
Sent from = office


On Sat, Oct 13, 2018 = at 2:43 AM Brendan McMillion <brendan@cloudflare.com> wrote:
Hey= Nadim

I believe the = typical way to build a forward-secure signature scheme is with a = certification tree. You=E2=80=99d:

1. Generate a root keypair.
2. Generate N leaf keypairs.
3. Sign = each leaf keypair and the epoch it is meant to be used in, with the root = keypair.
4. Delete the root private key.

Your root public key is = what=E2=80=99s distributed to everybody. A signature at a given epoch is = the tuple: (leaf public key, sig over leaf key from root key, sig over = data from leaf key).

Could you talk about why a scheme like the above is not = suitable here? Also, since I didn=E2=80=99t go to the interim, what = problem do forward-signature signature schemes solve for MLS?

On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi = <nadim@symbolic.software> wrote:

Dear Ted,
Thanks for your quick read-through!

You seem to be referring to [1], not to = [2] as you wrote. In [1], the concept of "hardened" keys is defined and = is also ported by [2] into Ed25519.

> What I think that means is that if = an attacker ever gets access to both an extended public key and any = extended private key, we have lost forward secrecy for all the MLS = communications covered by any keys derived from any of the epoch = pairs.  Is that correct?

This is = correct in the sense that it allows you to rewind the key derivation = chain. However, this does not apply to hardened keys. This is precisely = why I'm trying to understand how epoch identifiers are agreed upon, in = order to see whether we can use them to restrict the HKD logic to use = only "hardened" keys in MLS. Since hardened keys in [2] cannot = themselves have children, it becomes important to understand whether we = can select enough of them for an HKD design in MLS to have a meaningful = impact, and how this selection/potential caching of hardened keys would = work.

> [...] means that Alice must refrain from ever using the = parent extended public key has a signing key, but must instantiate = signing keys from the n + 0 epoch.  

This could also be a = solution, I suppose, but it sounds like it would result in weaker = "signing forward secrecy" (or whatever we're calling this property) than = focusing on hardened keys, although I'm frankly not sure off the top of = my head.

Nadim Kobeissi
Symbolic = Software =E2=80=A2 https://symbolic.software
Sent from = office


On = Fri, Oct 12, 2018 at 10:03 PM Ted Hardie <ted.ietf@gmail.com> wrote:
Hi Nadim,

I suspect I'm missing something simple = here in your proposal.  According to your reference 2, one of the = issues with the derivation of this type of hierarchical key = is:

 that = knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and=20= thus every private and public key descending from it). This means that=20= extended public keys must be treated more carefully than regular public=20= keys. It is also the reason for the existence of hardened keys, and why they=20= are used for the account level in the tree. This way, a leak of=20 account-specific (or below) private key never risks compromising the=20 master or other accounts.

What I think that means is that if an = attacker ever gets access to both an extended public key and any = extended private key, we have lost forward secrecy for all the MLS = communications covered by any keys derived from any of the epoch = pairs.  Is that correct?

This appears to make handling required = of the parent extended public key roughly equivalent to the handling of = a private key, so that your step:

Alice sends a public signing key to Bob = during epoch n.

means that Alice must refrain from ever using the parent = extended public key has a signing key, but must instantiate signing keys = from the n + 0 epoch. 

Is that a correct understanding?

Thanks,

Ted


On Fri, Oct 12, 2018 = at 12:47 PM Nadim Kobeissi <nadim@symbolic.software> wrote:
Hello everyone,

I've been working on adapting Hierarchical Key Derivation = (HKD) in order to obtain some kind of ephemeral signatures that may be = useful in MLS. I've arrived at a point where I'm optimistic that this is = a direction worth pursuing and might indeed be a solution to this = problem.

HKD = was at some point a candidate for how signature keys are managed per = epoch in the Tor Hidden Service design [0]. HKD logic has also been = implemented in Bitcoin wallets for a while now [1]. HKD constructions = can be also derived from existing popular fast signature algorithms such = as Ed25519 with minimal changes [2], making them an easy fit for MLS. = Very simply, the functionality that HKD signature schemes bring to MLS = is the following:
  • Alice= sends a public signing key to Bob during epoch n.
  • At the onset of epoch n+1, Bob is able to immediately = calculate Alice's public signing key for epoch n+1 based purely on his = knowledge of Alice's public signing key for epoch 0. Alice doesn't need = to send new signing key information to Bob.
  • At this = point, Bob can delete Alice's public signing key for epoch n.
  • More importantly, Alice herself can delete Alice's private = signing key for epoch n, keeping only her private signing key for epoch = n+1.
The way that this could work in MLS would = be heavily based on HDKeys-Ed25519 [2]. I'll resist paraphrasing the = paper, and instead will point out the relevant sections (which are = short, well-written and worth reading:)
  • Section 2 describes the original concept as = used for Bitcoin wallet derivation.
  • Section 4 = describes the modifications to Ed25519 to enable HKD = constructions.
  • Section 5 describes how private and = public child keys are generated (Fig. 1 is also = helpful.)
My questions:
  • How are we deriving epoch = identifiers? Are they simply counters, or each epoch identified by a = nonce that's communicated confidentially? If you read [2], you'll see = why this can be important.
  • Performance impact seems = to be negligible for Montgomery-based signing primitives, but I'm = interested in more insight on this.
  • Is anyone else = interested in having a standard HDKeys-Ed25519 implementation? I've = been working on one in JavaScript and plan to eventually also write one = in Go. Perhaps Richard would like to help with a C++ version?
  • I'm also interested in hearing your thoughts on this = generally.
During the interim meeting (as = well as before it), it was frequently discussed how ephemeral signatures = may be useful for MLS. This also appears to be slated as a discussion = topic for IETF 103, so it would be great if we could continue the = discussion there as well. 

References:
[0] https://gitweb.torproject.org/torspec.git/tree/proposals/224-re= nd-spec-ng.txt#n1979
[1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki<= /a>
[2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf

Nadim Kobeissi
Symbolic Software =E2=80=A2 https://symbolic.software
Sent from = office
<= /div> _______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS = mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

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

= --Apple-Mail=_07E8F347-DA10-44C2-B943-3CAF8D56E3BF-- From nobody Thu Oct 18 10:34:07 2018 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 4F96012F1AC for ; Thu, 18 Oct 2018 10:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 QEjLTUGaxU6e for ; Thu, 18 Oct 2018 10:34:04 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 AAB8B128CE4 for ; Thu, 18 Oct 2018 10:34:04 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id p23so30550869otf.11 for ; Thu, 18 Oct 2018 10:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=17wWqQZ2u2TC6H5T+q05so/7/uqlMsA93xTSwctHZLU=; b=dol9a6q4EjScBPViRv08NFfeGXzWbRUrzuP5IsOJqbxjYR9ELGS4MrmLFhTt/DBfWd 0DDPRa+IrIgWYF8kldpweQVedTswjhOUNi8FtVYvXO2n2ZHs/m53v1X+iCQ/nSYBDHYq SChq1VeO/5KH49plGE5ZA8TXTwJLeHOt4L50I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=17wWqQZ2u2TC6H5T+q05so/7/uqlMsA93xTSwctHZLU=; b=UXhBdtKqgMi9FzBfO1O+7RsqlBkGxOrsjLTY9+gZIsb9wA3/0qv29HY4YFAtbWvG1P Gd63wIwwtIVqaFJZ3ZXKr4WZgWql7k1JzqLAmgOr+L+NodkRF0+G3K+KEkCIwEvinTQg yF243e6Pte1pSl5mPI6ucUlKq3gSfwDRf+rI6FldDLiP+bnLu/dZ2XNEiDu7tXsVFX1y tld+fAVHSQbILD6ERIw5k5WkzwI4jd6AE1iGjlge8rcpGrlBVSWBpFlX5r9x8BLod9Mx al/PhU1llQIiDXukViJKCnhmqV+NGVgivVXN+zgsPJjBV0Ozald+4HlU03IiwNVA8PO5 J1Qg== X-Gm-Message-State: ABuFfohohckRZoJ7q9/05fTvlLP6pOQcBwhfG6W+RvqZ2NGaaqBauyth mkCXDYufPGHe74nSyBxLH+CKyI6/NXh1HFhhVu5+jT/MHh8= X-Google-Smtp-Source: ACcGV62QHJT1WfQ+cFDTP4s6xLH1FhJ19oIilhZfzzLkHnTjqxMxOxxd7J3h3ssA1TgvMjuUlmQ9XDcz+Xi/7MhpoEs= X-Received: by 2002:a9d:2843:: with SMTP id h3mr21116916otd.171.1539884043338; Thu, 18 Oct 2018 10:34:03 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Thu, 18 Oct 2018 10:33:51 -0700 Message-ID: To: "mls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006625b405788431ab" Archived-At: Subject: [MLS] IETF 103 deadlines and call for agenda items 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, 18 Oct 2018 17:34:06 -0000 --0000000000006625b405788431ab Content-Type: text/plain; charset="UTF-8" Hello MLS working group, Just a reminder that the deadline for IETF 103 draft revisions is Monday the 22nd of October. If there are draft updates, please submit the latest revision before then and send a note to the mailing list to let the working group know. We're also soliciting agenda requests for the meeting. There are two sessions, Monday (2hr) and Thursday (1h) so let us know if you have a preference. We will be accepting remote presentations. Nick & Sean --0000000000006625b405788431ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello MLS working group,

Just a reminde= r that the deadline for IETF 103 draft revisions is Monday the 22nd of Octo= ber. If there are draft updates, please submit the latest revision before t= hen and send a note to the mailing list to let the working group know.

We're also soliciting agenda requests for the meet= ing.=C2=A0There are two sessions, Monday (2hr) and Thursday (1h) so let us = know if you have a preference. We will be accepting remote presentations.

Nick & Sean
--0000000000006625b405788431ab-- From nobody Fri Oct 19 12:00:26 2018 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 8045F131095; Fri, 19 Oct 2018 11:56:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: mls@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539252.6592.5146090471801994799.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:32 -0700 Archived-At: Subject: [MLS] mls - Requested sessions have been scheduled for IETF 103 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: Fri, 19 Oct 2018 18:56:40 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mls Session 1 (2:00 requested) Monday, 5 November 2018, Afternoon Session II 1610-1810 Room Name: Chitlada 2 size: 250 --------------------------------------------- mls Session 2 (1:00 requested) Thursday, 8 November 2018, Morning Session II 1120-1220 Room Name: Chitlada 1 size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/mls.ics Request Information: --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 125 Conflicts to Avoid: First Priority: acme artarea cfrg dispatch iasa2 httpbis perc quic rtcweb saag secdispatch tls Second Priority: curdle dprive lamps sidrops stir suit teep People who must be present: Eric Rescorla Sean Turner Cullen Jennings Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 22 07:04:08 2018 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 660B712896A; Mon, 22 Oct 2018 07:04:01 -0700 (PDT) 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: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <154021704139.6470.15400170000946177384@ietfa.amsl.com> Date: Mon, 22 Oct 2018 07:04:01 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-02.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: Mon, 22 Oct 2018 14:04:02 -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 Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-02.txt Pages : 44 Date : 2018-10-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 participants 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-02 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 Mon Oct 22 07:33:41 2018 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 6361B128A5C for ; Mon, 22 Oct 2018 07:33:39 -0700 (PDT) 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=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnu6kthk5MJ9 for ; Mon, 22 Oct 2018 07:33:37 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 9CBAD12870E for ; Mon, 22 Oct 2018 07:33:36 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id z15so614143otm.12 for ; Mon, 22 Oct 2018 07:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vvmmZZEcwYgLOPZjCgEj7/3IGQrufkUPZ5rDGxnXXH0=; b=tqa7fM5JxmouBBpoqHtwolR9QQnnOwn5UkAq7XYcJw7QU76MQH145cttmkyLvwEFOu 1i9ueNPScaoca8OI1nNAS6MwCid9GjUnD0EWjlfS37Xr3qNJtNT2qhDJ+UjDxiILbZC2 XT6rFYUUOCRibfa021k4uEiaZAR1f3F4uRpUDOnkT+kz23lt+PrSCFV2yJ27oYcSXDuD L4WsPDZEGJwssPPbDLzE7DFNADJEzacvWwgxr9HijiKb4i8EkLKULYm242jfSAWRprb5 Wa+azCt/rWv3vdMXMs3JdZEZY+VLBvm2W7OqxG5x4o9fxJ1sAgN9raEl2H4clTXyOTSM 3Gvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vvmmZZEcwYgLOPZjCgEj7/3IGQrufkUPZ5rDGxnXXH0=; b=Is4ctqKztSqU6qB30Lgor6C5AK2v9wFbHOpvvQa/FLcs4Zf/rGkwrruoMk3voLMAuF aKz2p79htfruT/P5VykG7AyZ1IH/WMPJnxQdzzn6oXD5oXuZrJ8X6j/YH02wdDof0wgd 9o+TCTIazP6MRnwGpCaXJlZA91HOl73klE4Nas9MKWE5nQxabFWqKQEH0ttqFmItthwP Hdm+AEmSntFhWIzswWkN3p7XVjT3NUc8xqzv+vhqj8SgrAuZ45TYhFtcWI0alO2oHkKp BMviAJJIvyva+0mKy7CfI4K5sp8yr9uDG6EiP/zNplApdalUvjPZLotn6y5ymjXj8Xdg uVEQ== X-Gm-Message-State: ABuFfoimK6+sNJgodgdkesfwyzRwHak5UmyhaDk8FLppD+1oM71WdklH SKfLWgIqO+dH7Wo1WEBOtTjybXQPrZFgKtYplBLRroWm/5g= X-Google-Smtp-Source: ACcGV61b91E0nkaM0ZaWMa8hGojq9POOCDYMqHFA5t1LWv4gAKFVVCyw6Y/5r9l9wxuanh+ej5AyfnU3rsjaICqEQ8E= X-Received: by 2002:a9d:2377:: with SMTP id k52mr29944054otd.238.1540218815460; Mon, 22 Oct 2018 07:33:35 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 22 Oct 2018 10:33:22 -0400 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000005f4f270578d2232b" Archived-At: Subject: [MLS] Key confirmation - Extra MAC needed? 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, 22 Oct 2018 14:33:39 -0000 --0000000000005f4f270578d2232b Content-Type: text/plain; charset="UTF-8" Hey all, In the just-released -02 draft of MLS, I've added a key confirmation step to the handshake authentication process. Important question after "=====" below... In the previous draft, there was an authentication mechanism that ensured that if two group members ended up with different GroupState objects, then they would have different keys. However, it did not provide any way for group members to recognize that this was the case, except for AEAD checks on encrypted messages failing. With explicit key confirmation, the recipient of a Handshake message knows that if processing of the handshake message succeeds, then the recipient has the same GroupState as the sender. This provides a degree of protection against malicious insiders that send different TreeKEM values to different parts of the tree. Namely, only the subset of the tree that got the key matching the key confirmation will accept the Handshake message; the others will be locked out. (Assuming a broadcast channel; if the sender can send different key confirmations to different recipients, then this is no help.). This isn't complete protection, but at least the locked-out members know they've been locked out, and can complain about it. ===== The major question here is whether it's sufficient to derive a key confirmation value from the key schedule and publish it, or whether the value derived in the key schedule should be used as a MAC key to generate a MAC over the message transcript. I've posted PRs for both; the latter is what I merged in -02 Derive: https://github.com/mlswg/mls-protocol/pull/72 MAC: https://github.com/mlswg/mls-protocol/pull/71 On the one hand, the MAC-based approach is what is done in TLS. It feels safer, because we never publish anything that's in the key schedule diagram. On the other hand, the Derive-Secret operation used to create the key confirmation value in the key schedule is **already** based on HMAC. So it doesn't seem like the extra MAC step is adding that much value. If we can convince ourselves that the Derive approach (without the extra MAC) is sufficient, I would prefer to do that, since it's simpler. But feedback on this point would be very much appreciated. --Richard --0000000000005f4f270578d2232b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,
=
In the just-released -02 draft of MLS, I've added a key = confirmation step to the handshake authentication process.=C2=A0 Important = question after "=3D=3D=3D=3D=3D" below...

In the previous draft, there was an authentication mechanism that ens= ured that if two group members ended up with different GroupState objects, = then they would have different keys.=C2=A0 However, it did not provide any = way for group members to recognize that this was the case, except for AEAD = checks on encrypted messages failing.=C2=A0 With explicit key confirmation,= the recipient of a Handshake message knows that if processing of the hands= hake message succeeds, then the recipient has the same GroupState as the se= nder.

This provides a degree of protection against= malicious insiders that send different TreeKEM values to different parts o= f the tree.=C2=A0 Namely, only the subset of the tree that got the key matc= hing the key confirmation will accept the Handshake message; the others wil= l be locked out. (Assuming a broadcast channel; if the sender can send diff= erent key confirmations to different recipients, then this is no help.). Th= is isn't complete protection, but at least the locked-out members know = they've been locked out, and can complain about it.

=3D=3D=3D=3D=3D

The major question here = is whether it's sufficient to derive a key confirmation value from the = key schedule and publish it, or whether the value derived in the key schedu= le should be used as a MAC key to generate a MAC over the message transcrip= t.=C2=A0=C2=A0 I've posted PRs for both; the latter is what I merged in= -02
MAC: https://g= ithub.com/mlswg/mls-protocol/pull/71

On th= e one hand, the MAC-based approach is what is done in TLS.=C2=A0 It feels s= afer, because we never publish anything that's in the key schedule diag= ram.

On the other hand, the Derive-Secret operatio= n used to create the key confirmation value in the key schedule is **alread= y** based on HMAC.=C2=A0 So it doesn't seem like the extra MAC step is = adding that much value.

If we can convince ourselv= es that the Derive approach (without the extra MAC) is sufficient, I would = prefer to do that, since it's simpler.=C2=A0 But feedback on this point= would be very much appreciated.

--Richard




<= /div> --0000000000005f4f270578d2232b-- From nobody Mon Oct 22 09:12:09 2018 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 D67451274D0; Mon, 22 Oct 2018 09:12:06 -0700 (PDT) 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: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <154022472684.6470.15844142818621686395@ietfa.amsl.com> Date: Mon, 22 Oct 2018 09:12:06 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-architecture-01.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: Mon, 22 Oct 2018 16:12:07 -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) Architecture Authors : Emad Omara Benjamin Beurdouche Eric Rescorla Srinivas Inguva Albert Kwon Alan Duric Filename : draft-ietf-mls-architecture-01.txt Pages : 16 Date : 2018-10-22 Abstract: This document describes the architecture and requirements for the Messaging Layer Security (MLS) protocol. MLS provides a security layer for group messaging applications with from two to a large number of clients. It is meant to protect against eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-architecture-01 https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-architecture-01 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 Mon Oct 22 09:36:20 2018 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 B78B8130E30 for ; Mon, 22 Oct 2018 09:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ZKTcR68eZhIk for ; Mon, 22 Oct 2018 09:36:10 -0700 (PDT) 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 4EC3A1277D2 for ; Mon, 22 Oct 2018 09:36:10 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id z21-v6so38536959edb.11 for ; Mon, 22 Oct 2018 09:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=yTuSKPN8ATaiM6p+gDS+UIOBriQEr7HA6UHPDNmkdtU=; b=ckhNA7pkixaphLw+awtxB2SQb9f66cR9LdooxMfloIDZbGcBuAe8NzzrQQyDQbwQ/4 6E8e5g8ffKH96bEUZtLvqEhJXiwFJkvp3A8KPhuBDmjMnlZKUk/uqQcv9G7wI59SHCXf rhVbBny4oNWNIIKgU3dpMZr3aHs6hs87mS75z9u9iYNn/TofQcUtFViavREoNM2a0mzD +97370YPOQQFZLxv1+Iu23e+Qt/oJHXOmNgykN1Zu5X1cyZMLcu0dyM58X/KX+aVDoGP l+Xcyxe9m5pKckPm4fas8xYJvfM2dvEPnB4Z5TsUusC/7l+mjgp5mccX02taukClz7Km 8RHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=yTuSKPN8ATaiM6p+gDS+UIOBriQEr7HA6UHPDNmkdtU=; b=MxI0KHhVc7uFfbQbNkW0EdDD83+MBABJVj/2nTq/g+u+DF+GGX/HpM7pokoPSQsIEg ptjy8GFICGw/WAwnZlT2EsAfx1zY4KjmoBg0hIQFiCJGqzj5Z1aSu+Dr8R2p1tro/XUw dqTCTxgenqtIs2nwV7NoiHviXcxEB6HIIvHd+1EZ5RoPkpx87ChAQWnKcDwa2sCznymo K5YDff9LqgI/6t2YmIObo5hZzS4xPJ6jsCt8Rg4WU8Z5QCuvh9IH0oSRLptRL3h7FBR2 ZgaVXDGgNVulWuFpQxLAcojliaRJHNNlu6nOooEWEIbGaIZn7Nj0/vn2X/6Jk/iBidDb Dl9g== X-Gm-Message-State: ABuFfoiqP8Ie74SpyLR+vj+tpLLSw7L3Sc6cPGX0pQwf/qjvWeK2wEX0 tx5xBrgZX52G4elKc4Cw4kB7BIEyu8o= X-Google-Smtp-Source: ACcGV61E9hs6yjc7YjTPgiYYgk3ufYpXzZ03DFCp4FVYGISZYPImoVGd6Rcw4aF+DrmwWj4Bo2u1rA== X-Received: by 2002:a17:906:9143:: with SMTP id y3-v6mr3033132ejw.71.1540226168333; Mon, 22 Oct 2018 09:36:08 -0700 (PDT) Received: from rmbp.fritz.box (HSI-KBW-095-208-247-123.hsi5.kabel-badenwuerttemberg.de. [95.208.247.123]) by smtp.gmail.com with ESMTPSA id g19-v6sm12019388edh.36.2018.10.22.09.36.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 09:36:07 -0700 (PDT) From: Raphael Robert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: Date: Mon, 22 Oct 2018 18:36:05 +0200 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: [MLS] IETF 103 Hackathon 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, 22 Oct 2018 16:36:16 -0000 Hey all, The IETF 103 Hackathon is approaching and I'd like to invite anyone who = is interested in hacking early MLS implementations to participate! A list of current implementations as well as some initial test vectors = can be found here: https://github.com/mlswg/mls-implementations It would be interesting to hear who else will participate and if there = are more implementations out there. The goal I propose is to see if we = can get some interop between different implementations on the = (serialised) handshake message level. Raphael= From nobody Mon Oct 22 09:53:40 2018 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 0E3F1128C65 for ; Mon, 22 Oct 2018 09:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc1eL4FeDqCd for ; Mon, 22 Oct 2018 09:53:35 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 9E3AF124BE5 for ; Mon, 22 Oct 2018 09:53:35 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id l197-v6so32774002oib.8 for ; Mon, 22 Oct 2018 09:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VlRXiklcj7y0pRD5Kd7SqoD/K94U1Tp751Rk+JtJylk=; b=I0w+m3DIkUdjBl/Pebr0sFJX8aA7xr+XNf8CTxOZGFb5kQXE6lfBN009M3AZ6vwiV+ hGc/AvNj3d0b+2C8/qR48qqNqzpaWh/ZtX1xdGB46/Chdsa6a9jC2ajxCY6UOCZdOP9v rzVeqxUGoKmS6NDovocpEBsinjfyDMqLpCaiYmj+wFl/TdKUbxGis1czLzcRk/i37aJs E3Y3iNXuB2OiL/1BN9OJNFsB1n57O9ot6p1aiAjHbeR9t6U4ufFeEbcyealqhQT4KPpo XDmxwmeL1i2QUkH2ZINLNGFIFoCLmHGvvzG8mWzmgNNT5y+eeDARC8gfSn/86K1hiRLK G6ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VlRXiklcj7y0pRD5Kd7SqoD/K94U1Tp751Rk+JtJylk=; b=pZH06iZpksCLwtp/G7m1Ci/IRFkx/6fwavzAzgwjPUWihdcmlzELz1ymMPcCg+vcKU 4owiFv0xnWLIMPS5qFk4XdIKBZI3mQM+VjFlZL4Vj+hoosnsvofQA1Y9rSsP/8sPqG80 LI8oBs+GRKNtIHPVhwV4jDTXa0NrdE1RpxgaDIuPLZU1CE2bJO1UTo5mvCBmRM95y96z cmxKATxz4Z5hga0xfxCln9v5XzylfJKueKzHlnaRktA5ep/lWoOeyoJOp2ZLHQKp3089 k4YXxwZwsRAcd7JxTzHIM9Y09JedI0YIINzrnk1sNHDgBnzpckIr4g5sTlaWG6Rq307z m8cw== X-Gm-Message-State: ABuFfohiG3N3CZ48/LxAammcZlR2QApN58BuZUwLRDhvQUj3k4LJTfQO dDHAVdO4YPOaWcH41FhIlzZZpZ1ly+HGX7MSQEyB1g== X-Google-Smtp-Source: ACcGV61JV3xYSN171esYIVY49zK8SnWrNr0fMlP2bba23mjuXTyMFw/l/NEd6O7mRht6e/anPTLoCp+iPI7ZwpUlLXk= X-Received: by 2002:aca:6a13:: with SMTP id f19-v6mr26148515oic.260.1540227214660; Mon, 22 Oct 2018 09:53:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 22 Oct 2018 12:53:20 -0400 Message-ID: To: Raphael Robert Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000000ea090578d418b4" Archived-At: Subject: Re: [MLS] IETF 103 Hackathon 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, 22 Oct 2018 16:53:39 -0000 --00000000000000ea090578d418b4 Content-Type: text/plain; charset="UTF-8" Thanks, Raphael! I will be there, and looking forward to getting interop. To be concrete about the interop target: In between now and the hackathon, I'm going to work on getting mlspp updated to support the just-published -02 draft. It seems like we can probably build a ladder of test cases and work up: - Generate and parse UserInitKeys from one stack to another - Create a two-member group by sending Welcome and Add messages from one stack to another - Send updates within the two-member group - etc. What ciphersuite(s) are you targeting? IIRC, mlspp only does the P-256 one right now, but could probably be made to do Curve25519. On Mon, Oct 22, 2018 at 12:37 PM Raphael Robert wrote: > Hey all, > > The IETF 103 Hackathon is approaching and I'd like to invite anyone who is > interested in hacking early MLS implementations to participate! > > A list of current implementations as well as some initial test vectors can > be found here: https://github.com/mlswg/mls-implementations > > It would be interesting to hear who else will participate and if there are > more implementations out there. The goal I propose is to see if we can get > some interop between different implementations on the (serialised) > handshake message level. > > Raphael > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000000ea090578d418b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Raphael!=C2=A0 I will be there, and looking f= orward to getting interop.

To be concrete about th= e interop target: In between now and the hackathon, I'm going to work o= n getting mlspp updated to support the just-published -02 draft.
=
It seems like we can probably build a ladder of test cases a= nd work up:
- Generate and parse UserInitKeys from one stack to a= nother
- Create a two-member group by sending Welcome and Add= messages from one stack to another
- Send updates within the two= -member group
- etc.

What ciphersuite(s)= are you targeting?=C2=A0 IIRC, mlspp only does the P-256 one right now, bu= t could probably be made to do Curve25519.

On Mon, Oct 22, 2018 at 12:37= PM Raphael Robert <raphael@wire.com= > wrote:
Hey all,

The IETF 103 Hackathon is approaching and I'd like to invite anyone who= is interested in hacking early MLS implementations to participate!

A list of current implementations as well as some initial test vectors can = be found here: https://github.com/mlswg/mls-implementati= ons

It would be interesting to hear who else will participate and if there are = more implementations out there. The goal I propose is to see if we can get = some interop between different implementations on the (serialised) handshak= e message level.

Raphael
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000000ea090578d418b4-- From nobody Mon Oct 22 10:10:45 2018 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 36FB5129C6B for ; Mon, 22 Oct 2018 10:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 7gPKzcaM8UtF for ; Mon, 22 Oct 2018 10:10:39 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 05EF6127333 for ; Mon, 22 Oct 2018 10:10:39 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id e2-v6so2239705edn.2 for ; Mon, 22 Oct 2018 10:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=0nXkPcQ2qb3OGfeHkm62RngroExtWTJDPUTMg+BX9AA=; b=iz/TzOwFIlQdvxxKt2mlRSe4xJKlu/d41GzKEq6zYqceeidlmY8L+6+NwbMTW6wVWt UL7V2feKzFxQfpfU+2b4jQfkpaYUbrb12XKl7K21dg7huzZjqotYkihbRmys6h7tDMdv L0BZrK8FHA3JYakSp2TjwyEVF1jPzuIm/S6l+KNCAXLz4qNHWrKGkbUIjnlgzWHr4N2A SwaBzDDskJGCGv6p1+p1eGqXTCXp3fQA04CYd8W2BzONb9j2dWR2GrTJZc0Wq8j08DO9 JAnKJp1wF+1kVHMG4AmhHiuUEaBUtNQ+plChqhd1OLvK5tpad9Q3mZamc4eT5Czg/4c8 1uEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=0nXkPcQ2qb3OGfeHkm62RngroExtWTJDPUTMg+BX9AA=; b=GzbVmcFWLYnpqgg/qwNZpQnmVZTaH/aU7m26Wl97AqVAO1+aDwq/CmO/ahTlL5DPUE t61//tXCq5ltFpNlp696znErFdnWJ2Vz+YNfTtBLTzkiuPs4l+jziBPCidQhmmQ3QWqa xxX0x6ijYc2gBzXJEct3ZRWOsaehGN5OJuXVfkDPW0M5zVAdm00kT6NXxaFzM6xwGZZC kK+sI74M+4E4LtvTOA6zBbkHmzkJUanqfeeKS9bgNYrQJ49SsYYQDlQ+ws2Ocv5yyLUR wfXzpMGeQ6jhFNIEMWZHmcq73AEPF2PRiCDxINkZd+0ST8jAUJDxiR6qyW0bFWgr2wGg +fiw== X-Gm-Message-State: ABuFfoigWHiGD26xExnTIXlXIRJtINBvmurZl+Req0UdTDXn0tYLLhWH XWN60PfMQQMs78Z9Mt1wE/6h9/ntUTY= X-Google-Smtp-Source: ACcGV62xc0s1ivYaZyrGtHx7Wd5Dm1e3pZ4uOeFLm+EKNR4Ad27dbLkmXdXFrhOrA89XyRMaVpH6Hg== X-Received: by 2002:a17:906:41d1:: with SMTP id g17-v6mr844902ejl.58.1540228236953; Mon, 22 Oct 2018 10:10:36 -0700 (PDT) Received: from rmbp.fritz.box (HSI-KBW-095-208-247-123.hsi5.kabel-badenwuerttemberg.de. [95.208.247.123]) by smtp.gmail.com with ESMTPSA id l34-v6sm12406006eda.54.2018.10.22.10.10.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 10:10:36 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_EB1B13F3-52D8-465D-9376-19EA9BF6D1FC" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 22 Oct 2018 19:10:34 +0200 References: To: mls@ietf.org In-Reply-To: Message-Id: <5B0ED18B-5758-48F6-89D4-0514D8FFF336@wire.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] IETF 103 Hackathon 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, 22 Oct 2018 17:10:42 -0000 --Apple-Mail=_EB1B13F3-52D8-465D-9376-19EA9BF6D1FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good approach! For now the test vectors are just for tree math, but = I=E2=80=99ll add more as soon as I can. We can probably build stories = (Alice adds Bob, Bob updates, Bob adds Charlie and removes Alice, etc.) = and publish test vectors for each step. For now melissa can only do Curve25519. I=E2=80=99d like to propose we = take that ciphersuite as the first one for relevant test vectors. For real-time communication and to coordinate details around interop, = there is a dedicated Wire channel open to anyone: = https://app.wire.com/join/?key=3D3tL-NJOoCKZlDXNU1H2c&code=3DkZOc0ujnDQ9Tq= 98tLfSt = > On 22 Oct 2018, at 18:53, Richard Barnes wrote: >=20 > Thanks, Raphael! I will be there, and looking forward to getting = interop. >=20 > To be concrete about the interop target: In between now and the = hackathon, I'm going to work on getting mlspp updated to support the = just-published -02 draft. >=20 > It seems like we can probably build a ladder of test cases and work = up: > - Generate and parse UserInitKeys from one stack to another > - Create a two-member group by sending Welcome and Add messages from = one stack to another > - Send updates within the two-member group > - etc. >=20 > What ciphersuite(s) are you targeting? IIRC, mlspp only does the = P-256 one right now, but could probably be made to do Curve25519. >=20 >=20 > On Mon, Oct 22, 2018 at 12:37 PM Raphael Robert > wrote: > Hey all, >=20 > The IETF 103 Hackathon is approaching and I'd like to invite anyone = who is interested in hacking early MLS implementations to participate! >=20 > A list of current implementations as well as some initial test vectors = can be found here: https://github.com/mlswg/mls-implementations = >=20 > It would be interesting to hear who else will participate and if there = are more implementations out there. The goal I propose is to see if we = can get some interop between different implementations on the = (serialised) handshake message level. >=20 > Raphael > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_EB1B13F3-52D8-465D-9376-19EA9BF6D1FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = approach! For now the test vectors are just for tree math, but I=E2=80=99l= l add more as soon as I can. We can probably build stories (Alice adds = Bob, Bob updates, Bob adds Charlie and removes Alice, etc.) and publish = test vectors for each step.

For now melissa can only do Curve25519. I=E2=80=99d like to = propose we take that ciphersuite as the first one for relevant test = vectors.

For = real-time communication and to coordinate details around interop, there = is a dedicated Wire channel open to anyone: https://app.wire.com/join/?key=3D3tL-NJOoCKZlDXNU1H2c&code=3D= kZOc0ujnDQ9Tq98tLfSt


On 22 Oct 2018, at 18:53, Richard Barnes <rlb@ipv.sx> wrote:

Thanks, Raphael!  I will be there, and = looking forward to getting interop.

To be concrete about the interop = target: In between now and the hackathon, I'm going to work on getting = mlspp updated to support the just-published -02 draft.

It seems like we can = probably build a ladder of test cases and work up:
- = Generate and parse UserInitKeys from one stack to another
- Create a two-member group by sending = Welcome and Add messages from one stack to another
- = Send updates within the two-member group
- = etc.

What = ciphersuite(s) are you targeting?  IIRC, mlspp only does the P-256 = one right now, but could probably be made to do Curve25519.


On = Mon, Oct 22, 2018 at 12:37 PM Raphael Robert <raphael@wire.com> = wrote:
Hey all,

The IETF 103 Hackathon is approaching and I'd like to invite anyone who = is interested in hacking early MLS implementations to participate!

A list of current implementations as well as some initial test vectors = can be found here: https://github.com/mlswg/mls-implementations
=
It would be interesting to hear who else will participate and if there = are more implementations out there. The goal I propose is to see if we = can get some interop between different implementations on the = (serialised) handshake message level.

Raphael
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_EB1B13F3-52D8-465D-9376-19EA9BF6D1FC-- From nobody Mon Oct 22 10:37:08 2018 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 E0DB1128D0C for ; Mon, 22 Oct 2018 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kOQONLmEXShf for ; Mon, 22 Oct 2018 10:37:05 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 1B3551252B7 for ; Mon, 22 Oct 2018 10:37:05 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id s6-v6so16947268ioa.11 for ; Mon, 22 Oct 2018 10:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=fZPHB+Hvs6ykKsyka/YgUCm1amQkzo+XWxuCbOtZDls=; b=rWTcmWgKUfnLnsh2bfl5cTf4fm10Oc4HS/NySuxutwxS1MchQeZYXxjluSaxccYqqf CWZLzDZnf7/9p9JlF/0cQc1xYoBy4ZFk6BkO//qTLML8j3jLPStMxgXIt2ZZxSIGIU1N /lAQHnaxgqi2MNxqUXUnOIvkFHKYBL49RUHY1fZXfOtSrk2vxFzThWjSSRI6Rtsm5syc Pr2H/9mwsl4lp11l2Yx0/uFBX6JEuEdRHvhyAOoWwQ797sHO0Ka+cDuC5owq02B5CHAb 31ykCli+UGFbT3wLyt+NtvDfXKRVqqxhK4YYrGV1FxYK0nOd2Rf6JBAQZ8zNHTj1WZ/X in9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fZPHB+Hvs6ykKsyka/YgUCm1amQkzo+XWxuCbOtZDls=; b=HErsMxjAqjBBlgSRe1XqdLviDEuxDbp8OK7Iuls+cDZVzMI5pIZ80Ne72Gkq3WBayO 7d6zBJPAuXquIepQtjlB7gf4ZmTV8GssIB9C6dYIn0iAK7kgk3WVuvcI4APD/ZJLFBsK 9/XRW8Royooos3fSNVTU3Azr+dMU/f+lYPk9rjTHDzm4ZMQNhMtdmRfraMkNNlWM6k4D xR418BUXMkC7KDrBpKjRjoAFHYeVcqfSE1gtET7TMae0m+lEEQmMgDFMJLENYLBakhJk LlsaAk8y+sHtf9ERbF8jIu1l2SMm+5GPUK8xny5PnpemiE1DNpqiJdYxys0HpEYOXDBv VFWQ== X-Gm-Message-State: AGRZ1gK+58NkUwqZLZmjEXpX+noVNHMA+1BSGRsnb309oisKxx3MJx3X o5JCqqzj025rQnipnrdnhfR22n8XUkYP6a7bazJLZkZKdRgfxw== X-Google-Smtp-Source: AJdET5f5mDmqyX31HDC+TG3pedDAy/Kp3rl+cM+J+ewhWCglCPpWP+hDyW+ysxHWqThsIxdnp18eZGyLXq/PK6gjXT4= X-Received: by 2002:a6b:b2d8:: with SMTP id b207-v6mr8364295iof.147.1540229823766; Mon, 22 Oct 2018 10:37:03 -0700 (PDT) MIME-Version: 1.0 From: Jon Toohill Date: Mon, 22 Oct 2018 10:36:37 -0700 Message-ID: To: mls@ietf.org Cc: Emad Omara , Gary Belvin Content-Type: multipart/alternative; boundary="0000000000008518010578d4b36c" Archived-At: Subject: [MLS] Malicious user segmenting the group 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, 22 Oct 2018 17:37:07 -0000 --0000000000008518010578d4b36c Content-Type: text/plain; charset="UTF-8" Hey MLS folks, I'm still skimming through the mailing list archives to get up to speed, so apologies if this has already been discussed & solved. I saw the following note in a recent version of the protocol draft: [[ OPEN ISSUE: It is not possible for the recipient of a handshake message > to verify that ratchet tree information in the message is accurate, because > each node can only compute the secret and private key for nodes in its > direct path. This creates the possibility that a malicious participant > could cause a denial of service by sending a handshake message with invalid > values for public keys in the ratchet tree. ]] > It seems like this could be solved by having the handshake message sender prove in zero knowledge (i.e. without revealing their secret or the parent secret) that they derived the parent public key correctly. ZK-SNARKs are one way of doing that, but my admittedly weak understanding is that generating proofs might be too computationally expensive for mobile devices. Does this seem like a worthwhile direction to investigate? Does anyone know of a more efficient construction that could be used in MLS? -Jon Toohill --0000000000008518010578d4b36c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey MLS folks,

I'm= still skimming through the mailing list archives to get up to speed, so ap= ologies if this has already been discussed & solved. I saw the followin= g note in a recent version of the protocol draft:

[[ OPEN ISSUE: It is not possi= ble for the recipient of a handshake message to verify that ratchet tree in= formation in the message is accurate, because each node can only compute th= e secret and private key for nodes in its direct path. This creates the pos= sibility that a malicious participant could cause a denial of service by se= nding a handshake message with invalid values for public keys in the ratche= t tree. ]]

It seems like this could be = solved by having the handshake message sender prove in zero knowledge (i.e.= without revealing their secret or the parent secret) that they derived the= parent public key correctly. ZK-SNARKs are one way of doing that, but my a= dmittedly weak understanding is that generating proofs might be too computa= tionally expensive for mobile devices. Does this seem like a worthwhile dir= ection to investigate? Does anyone know of a more efficient construction th= at could be used in MLS?

-Jon Toohill
<= /div> --0000000000008518010578d4b36c-- From nobody Mon Oct 22 11:10:51 2018 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 975A1128B14 for ; Mon, 22 Oct 2018 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFRrj6pFiBQZ for ; Mon, 22 Oct 2018 11:10:48 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 A9AA6124BE5 for ; Mon, 22 Oct 2018 11:10:48 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id s69-v6so32973180oie.10 for ; Mon, 22 Oct 2018 11:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GfCLNiqEh5JXz1DSBrGoV7f23jSJaxXbodSh7xTCo8Q=; b=QqW3gFpNl877sQMAtUASpuNA8T2S5/F9aJoMWg+hQd0MfPg20tCpDNdbmuS3z80fUF NzCib9g+Ot6Q9q1HYjOIC95G6n33HBY6th37J5baD16MFJP+SsZUHbQ/EiQR5LN+R+7W wqp7640O2b7BFPzLye5p5zhfgtqYfo3O3GWgqsKHShjpETMBdFNNuC0NWG0bGsAx4HSe HLjxpclAA8Ktosqb3CrDkeemfu4QWPCVjv4vp2H1SgwzWcGyUNTya5BjCPVup7jSRTF1 ilazAdrmBnsce+sglbQFJgXF3Ju/5QmtV34zTG6Ct+s7EKYN9u1TsJOEkivYeC/jqe6Y KV6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GfCLNiqEh5JXz1DSBrGoV7f23jSJaxXbodSh7xTCo8Q=; b=PmSh4GVX8I2PU/Hk49Ircw21W1aEd2fu+P0t+9R+vY9tzFRE0iZSUsBF2FmlxwK2jt UEeDZG4GP8ntvra1U2KZ9DVH6OiDJk/a7PJqnJtb153h9jdqsOY1TejWOXPIope7qSMD 0ddO8lJ9KfonJ2PLsrzEjxgHMmnawmbzyal7436mlBiMbYUEPAnA6+Feg7Rpt/71ckOa rBAnhMU2+L7m5P8MK03tuKpl03VLzfyjUv+EvzqxlRcqiPTFnIpN1qSBbzLrdTssMmQ7 nft9v9jv84P1v5q/yF/uOo52MQIquoPFt4WilaXv8ewdR6/iUoU940ITZBs5c0Ge8Sma ytog== X-Gm-Message-State: ABuFfogaNHjFKimCT9eANWZZYGCZ6DOfO2cSrp1U1X0IPiQ1q6GY25bl Sj1vpL1kP+P9vZiEWSDXbPmzWxAYvzzUwZDC13Ef4slI X-Google-Smtp-Source: ACcGV63GA1H+D+0nKY5ka+TzVVJym3WQxj3twvAQUENCefZmPGXEYWqOKZHHFbx3Ov2zE/3pHTWNE+svTayhNwIpF8w= X-Received: by 2002:aca:540c:: with SMTP id i12-v6mr25942157oib.49.1540231847229; Mon, 22 Oct 2018 11:10:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 22 Oct 2018 14:10:33 -0400 Message-ID: To: jtoohill=40google.com@dmarc.ietf.org Cc: mls@ietf.org, Emad Omara , gbelvin@google.com Content-Type: multipart/alternative; boundary="000000000000204dba0578d52cde" Archived-At: Subject: Re: [MLS] Malicious user segmenting the group 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, 22 Oct 2018 18:10:51 -0000 --000000000000204dba0578d52cde Content-Type: text/plain; charset="UTF-8" Hi Jon, This is definitely an active issue. See my message earlier today about authentication / key confirmation. There have been some discussions of ZKPs for this, but AFAIK, no workable proposal has emerged. The problem is that what you want to prove is that a sequence of keys are the result of transforming a chain of hashes from hash outputs to key pairs -- if you want to do a ZKP with a general hash function, the ZKP is very expensive, and if you adapt the hash function to have nicer proof properties, you lose some of the cryptographic properties you would want. My current thinking is that we should probably try to address this at the protocol level. In some of the pre-BoF discussions, we had talked about doing some specification of ACK / NACK messages. Now that at least some endpoints can recognize a bad message, it seems like we could define a NACK that says "that handshake message was invalid" and basically let endpoints veto invalid messages. If someone wants to come up with a concrete proposal, I would love to discuss further. --Richard On Mon, Oct 22, 2018 at 1:37 PM Jon Toohill wrote: > Hey MLS folks, > > I'm still skimming through the mailing list archives to get up to speed, > so apologies if this has already been discussed & solved. I saw the > following note in a recent version of the protocol draft: > > [[ OPEN ISSUE: It is not possible for the recipient of a handshake message >> to verify that ratchet tree information in the message is accurate, because >> each node can only compute the secret and private key for nodes in its >> direct path. This creates the possibility that a malicious participant >> could cause a denial of service by sending a handshake message with invalid >> values for public keys in the ratchet tree. ]] >> > > It seems like this could be solved by having the handshake message sender > prove in zero knowledge (i.e. without revealing their secret or the parent > secret) that they derived the parent public key correctly. ZK-SNARKs are > one way of doing that, but my admittedly weak understanding is that > generating proofs might be too computationally expensive for mobile > devices. Does this seem like a worthwhile direction to investigate? Does > anyone know of a more efficient construction that could be used in MLS? > > -Jon Toohill > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000204dba0578d52cde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jon,

This is definite= ly an active issue.=C2=A0 See my message earlier today about authentication= / key confirmation.

There have been some disc= ussions of ZKPs for this, but AFAIK, no workable proposal has emerged.=C2= =A0 The problem is that what you want to prove is that a sequence of keys a= re the result of transforming a chain of hashes from hash outputs to key pa= irs -- if you want to do a ZKP with a general hash function, the ZKP is ver= y expensive, and if you adapt the hash function to have nicer proof propert= ies, you lose some of the cryptographic properties you would want.

My current thinking is that we should probably try to addr= ess this at the protocol level.=C2=A0 In some of the pre-BoF discussions, w= e had talked about doing some specification of ACK / NACK messages.=C2=A0 N= ow that at least some endpoints can recognize a bad message, it seems like = we could define a NACK that says "that handshake message was invalid&q= uot; and basically let endpoints veto invalid messages.

If someone wants to come up with a concrete proposal, I would love to= discuss further.

--Richard
On Mon, Oct 22, 2018 at 1:37 P= M Jon Toohill <jtoohill=3D40google.com@dmarc.ietf.org> wrote:
Hey MLS folks,

I'm still skimming through the mailing list archives to get up to spe= ed, so apologies if this has already been discussed & solved. I saw the= following note in a recent version of the protocol draft:

[[ OPEN ISSUE: It is = not possible for the recipient of a handshake message to verify that ratche= t tree information in the message is accurate, because each node can only c= ompute the secret and private key for nodes in its direct path. This create= s the possibility that a malicious participant could cause a denial of serv= ice by sending a handshake message with invalid values for public keys in t= he ratchet tree. ]]

It seems like this = could be solved by having the handshake message sender prove in zero knowle= dge (i.e. without revealing their secret or the parent secret) that they de= rived the parent public key correctly. ZK-SNARKs are one way of doing that,= but my admittedly weak understanding is that generating proofs might be to= o computationally expensive for mobile devices. Does this seem like a worth= while direction to investigate? Does anyone know of a more efficient constr= uction that could be used in MLS?

-Jon Toohill
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000204dba0578d52cde-- From nobody Mon Oct 22 11:34:18 2018 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 C2866128766 for ; Mon, 22 Oct 2018 11:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J4Q7i68JZjV for ; Mon, 22 Oct 2018 11:34:14 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 A75B61277C8 for ; Mon, 22 Oct 2018 11:34:14 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id c23so39283678otl.9 for ; Mon, 22 Oct 2018 11:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=nKHtVHdJWmTmlUZBAthaGLgU3s1FOfHLEVEybfMp57g=; b=scMN6Tg6P26ZcvtAAe4FyDO2O36XC0zNWaRk5sQtCzEO3pMVd57Ofw4NpwoR4JXrd3 /qrr05YV4Z4KmzkxRIgoh1756DUCxWrujm7I+uJ576XJhjjdQ3xFaATryw+Pl6sXEsz5 5ijr6NAkCKqABGbFP/AmUgq774ikxecS+eJnZvN1rlDbcbA24EN+/RU6650crKaRrDs6 uPNAorYVIuG/+5HEthU6XuMiNLUk/o6xOzYkBCJ68BhjuXWe6QfTvmY7nm+y7eF/EizP azfP2hBnHdBjvDiSrCmD+zCh/GINCiWextyMB8H1Fn+r0M+Kt4/Vjg42z63HyrUmpmUC QYBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nKHtVHdJWmTmlUZBAthaGLgU3s1FOfHLEVEybfMp57g=; b=XK+9hG1pQpeQ9wNOdd3uGQ9kQCPdahnb3dE2lngDFcwPTQWHHZOYYBSs7oVpgrvJwa DBAioqdCEROuJWSGLoyxdbwItgREAjEiv6YhNThb7V8ZbFJwnkVWHmiVnhABim0895eN 0PJp1QsbmAUXIF78GoaOQdHG7eYV+yUn7GbNsZklvRSJrGUPE+YJpRgaYL+akwVLE297 VH0JXyDVGALbCh+4DHXVxFEk0bu+WfgNJzoO/Ot2ynbmH0OLYnNAp+x5UrlIycETBP0v 4n0hPR5wy9ie0z4n77723oJgsutA/l6s0jlhBsWSgQ4/JYTOIk/W/VGX0U9D4PbKvspK yEhw== X-Gm-Message-State: ABuFfojCshhJCtxgsgRM+2TrNPQF+StabIRxmdP/kAwH0wYIkd2psk4l H8fNns6rebItXneZX7HKCl8e1gz2vS9D4PuY7ARzgZrm5aM= X-Google-Smtp-Source: ACcGV60odgE+Up9ivY60UHocmcnlP8cdcRspO6S4XEWX4uJdPJ9f8/QAQtSyXSdc5ZOpvUXWpcblRnNRrQnoRkSZvy8= X-Received: by 2002:a9d:339a:: with SMTP id u26mr31648169otc.81.1540233253651; Mon, 22 Oct 2018 11:34:13 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 22 Oct 2018 14:34:00 -0400 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000f49cd10578d57f77" Archived-At: Subject: [MLS] Move / Add-in-place / Compounding 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, 22 Oct 2018 18:34:17 -0000 --000000000000f49cd10578d57f77 Content-Type: text/plain; charset="UTF-8" Hey MLS folks, tl;dr: - Would there be interest in a Move operation? - How about an operation to Add a new member in an open slot instead of the right edge? In looking at the "partial tree" stuff (#67), it occurred to me that once you have partial trees with blank leaves, you can in principle do two new operations: An existing member can move from one leaf in the tree to another; and an existing member can add a new member at a leaf that is currently blank. These operations would work roughly as follows: - Move: - Blank out old dirpath - Move credential from old slot to new slow - Send update along new dirpath - Add-in-place: - Blank out dirpath for slot - Install new member's leaf key in slot - Install new member's credential in slot For Move, you would also want to have people step down the size of the tree. For example, if you go from having 10 leaves (X _ X X _ _ _ _ _ X) to four leaves (X X X X) as the result of a move, then the resulting tree should only have height 2, not 4 (as is required for 10 leaves). Fortunately, this is trivial with the tree math defined in the document; you just truncate the node vector, and the calculated root gets correspondingly smaller. I've prototyped this out in my JS stack [1][2]. Once you've built a tree, and removed a couple of members, you can click one of the "Move" buttons to move that node to the lowest open slot. As you can see, it's not a ton of code. In any case, this seems to me to be potentially useful, since it addresses the issue that was raised in the BoF that the size of the resources for a group increases monotically. Move allows you to reclaim resources that are unused (assuming some orchestration outside of MLS), and Add-in-place allows us to be conservative with resources that are already allocated (cf. realloc). If folks think these sound like useful tools, I'll write up a PR and we can discuss in BKK. --Richard [1] https://ipv.sx/treekem/ [2] https://github.com/bifurcation/treekem/commit/7f470422ba61ce668c3ab1d6b2d18edd9d6e06fd --000000000000f49cd10578d57f77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey MLS folks,

tl;dr:
- Would there be interest in a M= ove operation?
- How about an operation to Add a new member in an= open slot instead of the right edge?

In looki= ng at the "partial tree" stuff (#67), it occurred to me that once= you have partial trees with blank leaves, you can in principle do two new = operations: An existing member can move from one leaf in the tree to anothe= r; and an existing member can add a new member at a leaf that is currently = blank.=C2=A0 These operations would work roughly as follows:

=
- Move:
=C2=A0=C2=A0=C2=A0 - Blank out old dirpath
=
=C2=A0=C2=A0=C2=A0 - Move credential from old slot to new slow
=C2=A0=C2=A0=C2=A0 - Send update along new dirpath
<= /div>
- Add-in-place:
=C2=A0=C2=A0=C2=A0 - Blank out dirpath = for slot
=C2=A0=C2=A0=C2=A0 - Install new member's leaf key i= n slot
=C2=A0=C2=A0=C2=A0 - Install new member's credential i= n slot

For Move, you would also want to have people step = down the size of the tree.=C2=A0 For example, if you go from having 10 leav= es (X _ X X _ _ _ _ _ X) to four leaves (X X X X) as the result of a move, = then the resulting tree should only have height 2, not 4 (as is required fo= r 10 leaves).=C2=A0 Fortunately, this is trivial with the tree math defined= in the document; you just truncate the node vector, and the calculated roo= t gets correspondingly smaller.

I've prototype= d this out in my JS stack [1][2].=C2=A0 Once you've built a tree, and r= emoved a couple of members, you can click one of the "Move" butto= ns to move that node to the lowest open slot.=C2=A0 As you can see, it'= s not a ton of code.

In any case, this seems to me= to be potentially useful, since it addresses the issue that was raised in = the BoF that the size of the resources for a group increases monotically.= =C2=A0 Move allows you to reclaim resources that are unused (assuming some = orchestration outside of MLS), and Add-in-place allows us to be conservativ= e with resources that are already allocated (cf. realloc).
If folks think these sound like useful tools, I'll write u= p a PR and we can discuss in BKK.

--Richard

--000000000000f49cd10578d57f77-- From nobody Mon Oct 22 12:00:11 2018 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 1117E130DCE for ; Mon, 22 Oct 2018 12:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 rEbjtuXVkaCA for ; Mon, 22 Oct 2018 12:00:02 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 83E98128B14 for ; Mon, 22 Oct 2018 12:00:01 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id x2-v6so4093131eds.3 for ; Mon, 22 Oct 2018 12:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=mAueBbODvtqPkB5gzzn0PTBjUbqqvUYTKqR1hMwdOag=; b=m7nm1Mbmx8QKlV4E3zbUpMcjMAlLJ2p3wyOAjIDVkVI6s8ZGWasL9Si52NLsJSYetN jLydrkUfckUO5mqf2eyfYROXIS9T+Xhu46gaCXF2o7u/hCcDWUES29mL9j4TtTtkqbu/ vde9lPlEeJb/one+6OUvRN5fpX2mSQvqFc/XGKTu2EGQqI0nHy0YnE5p+4TatMX6LcDr /rYCfkJbSFC16kZzz7VbldYTLv9thZ5vhP8YK0c4oic4GZo765tjz8f5HAtgPbtU1myJ SIq0s+3MU97ZEl36lz96qTmf2hyhUWuIhyTH0IxPfWTTn66CAfDsRlQs1bt7lQat2V88 WVvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=mAueBbODvtqPkB5gzzn0PTBjUbqqvUYTKqR1hMwdOag=; b=Keo7JmmVf+Z+cC9YuMCtHKSG404V3tNreolvlP4rgbzFqUIn/k+40po4im5/BjfBQz xXiQ0ezM0v+AkmT9um7biqD8K9IRiEB1K12/9ol21UZHFVnnDGHqpmiwnmTQ1stOP1Ue /xn3MmI5Pdo1qiZY3eiFYUecC+7T7d7oKtu5HWAPVSS4EU4vIaGuihoxTQUbhI6IFJ7h SBZsJrdjVZ/pJL6uyxEdb9AtxVO2RKOidlOWccf3fNckUtYE7nptzSF39fRZzw9wAZrh +W1X4VMghHXhNOryjSgVzglRvupaEHARFm93voM+KezkcXA55YQzbvD0FWHeltQyYJgk Vd3g== X-Gm-Message-State: ABuFfoj7Ta/zDe1kSX4f7rhiMdEMM0oDuACq/xNWFZvBj0w5fKKh44mM QbbBpbU3lgV6QBtX5kVyMa4DLLUTD3s= X-Google-Smtp-Source: ACcGV61ld5R9jf4yy10vsUF4nUOOzYnkEL89wzjGJG7lHe25rC1elwBGTr8mH65/CyAKbQ7yQlF70A== X-Received: by 2002:a50:abc2:: with SMTP id u60-v6mr14382595edc.185.1540234799520; Mon, 22 Oct 2018 11:59:59 -0700 (PDT) Received: from rmbp.fritz.box (HSI-KBW-095-208-247-123.hsi5.kabel-badenwuerttemberg.de. [95.208.247.123]) by smtp.gmail.com with ESMTPSA id x53-v6sm14711622edx.63.2018.10.22.11.59.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 11:59:58 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_1E3B772A-9379-4A47-A542-14E880FBD9BA" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 22 Oct 2018 20:59:57 +0200 References: To: mls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Move / Add-in-place / Compounding 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, 22 Oct 2018 19:00:09 -0000 --Apple-Mail=_1E3B772A-9379-4A47-A542-14E880FBD9BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think these two operations make perfect sense (had the same ones in = mind). Some comments: Regarding Move: We should work on a recommendation of when to do a Move instead of an = Update, and also of when to do a Move even if no Update was planned. The recommendation could initially be something naive, such as: when the = ratio of blank leaves / full leaves is greater than xxx, do a Move.=20 Regarding Add-in-place: I think this has the potential of becoming the default, as opposed to = the current Add. Maybe both operations could be one and the same if we = just add an index to the current Add. In that case the recommendation = for the index would simply be the left-most empty leaf node. If both operations are correctly applied by clients, the tree should = have the optimal size. There is however a case where trees will not shrink, but only if the = following three conditions are met: - A large number of members left the group (large is relative to the = group size) - A large number of the remaining members never come online again and = therefore cannot move themselves (large is again relative to the = remaining group size) - Only very few new members are added subsequently I suspect that the above scenario is however an edge case. If it occurs = =E2=80=9Cin the wild=E2=80=9D it might eventually get solved on a social = level (when unresponsive members get removed by active ones). > On 22 Oct 2018, at 20:34, Richard Barnes wrote: >=20 > Hey MLS folks, >=20 > tl;dr:=20 > - Would there be interest in a Move operation? > - How about an operation to Add a new member in an open slot instead = of the right edge? >=20 > In looking at the "partial tree" stuff (#67), it occurred to me that = once you have partial trees with blank leaves, you can in principle do = two new operations: An existing member can move from one leaf in the = tree to another; and an existing member can add a new member at a leaf = that is currently blank. These operations would work roughly as = follows: >=20 > - Move: > - Blank out old dirpath > - Move credential from old slot to new slow > - Send update along new dirpath > - Add-in-place: > - Blank out dirpath for slot > - Install new member's leaf key in slot > - Install new member's credential in slot >=20 > For Move, you would also want to have people step down the size of the = tree. For example, if you go from having 10 leaves (X _ X X _ _ _ _ _ = X) to four leaves (X X X X) as the result of a move, then the resulting = tree should only have height 2, not 4 (as is required for 10 leaves). = Fortunately, this is trivial with the tree math defined in the document; = you just truncate the node vector, and the calculated root gets = correspondingly smaller. >=20 > I've prototyped this out in my JS stack [1][2]. Once you've built a = tree, and removed a couple of members, you can click one of the "Move" = buttons to move that node to the lowest open slot. As you can see, it's = not a ton of code. >=20 > In any case, this seems to me to be potentially useful, since it = addresses the issue that was raised in the BoF that the size of the = resources for a group increases monotically. Move allows you to reclaim = resources that are unused (assuming some orchestration outside of MLS), = and Add-in-place allows us to be conservative with resources that are = already allocated (cf. realloc). >=20 > If folks think these sound like useful tools, I'll write up a PR and = we can discuss in BKK. >=20 > --Richard >=20 > [1] https://ipv.sx/treekem/ > [2] = https://github.com/bifurcation/treekem/commit/7f470422ba61ce668c3ab1d6b2d1= 8edd9d6e06fd = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_1E3B772A-9379-4A47-A542-14E880FBD9BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think these two operations make perfect sense (had the same ones in = mind). Some comments:

Regarding Move:
We should work on a = recommendation of when to do a Move instead of an Update, and also of = when to do a Move even if no Update was planned.
The = recommendation could initially be something naive, such as: when the = ratio of blank leaves / full leaves is greater than xxx, do a = Move. 

Regarding Add-in-place:
I think this has = the potential of becoming the default, as opposed to the current Add. = Maybe both operations could be one and the same if we just add an index = to the current Add. In that case the recommendation for the index would = simply be the left-most empty leaf node.

If both operations are correctly = applied by clients, the tree should have the optimal size.
There is however a case where trees will not shrink, but only = if the following three conditions are met:

 - A large number of members left = the group (large is relative to the group size)
 - A large number of the remaining members never come = online again and therefore cannot move themselves (large is again = relative to the remaining group size)
 - Only = very few new members are added subsequently

I suspect that the above scenario is = however an edge case. If it occurs =E2=80=9Cin the wild=E2=80=9D it = might eventually get solved on a social level (when unresponsive members = get removed by active ones).


On 22 Oct 2018, at 20:34, = Richard Barnes <rlb@ipv.sx> wrote:

Hey MLS folks,

tl;dr:
- Would there be = interest in a Move operation?
- How about an = operation to Add a new member in an open slot instead of the right = edge?

In looking at the "partial tree" stuff (#67), it occurred to = me that once you have partial trees with blank leaves, you can in = principle do two new operations: An existing member can move from one = leaf in the tree to another; and an existing member can add a new member = at a leaf that is currently blank.  These operations would work = roughly as follows:

- Move:
    - Blank out = old dirpath
    - = Move credential from old slot to new slow
    - Send update along new = dirpath
- Add-in-place:
    - Blank out dirpath for slot
    - Install new member's leaf key in = slot
    - Install new member's = credential in slot

For = Move, you would also want to have people step down the size of the = tree.  For example, if you go from having 10 leaves (X _ X X _ _ _ = _ _ X) to four leaves (X X X X) as the result of a move, then the = resulting tree should only have height 2, not 4 (as is required for 10 = leaves).  Fortunately, this is trivial with the tree math defined = in the document; you just truncate the node vector, and the calculated = root gets correspondingly smaller.

I've prototyped this out in my JS stack = [1][2].  Once you've built a tree, and removed a couple of members, = you can click one of the "Move" buttons to move that node to the lowest = open slot.  As you can see, it's not a ton of code.

In any case, this seems = to me to be potentially useful, since it addresses the issue that was = raised in the BoF that the size of the resources for a group increases = monotically.  Move allows you to reclaim resources that are unused = (assuming some orchestration outside of MLS), and Add-in-place allows us = to be conservative with resources that are already allocated (cf. = realloc).

If folks think these sound like useful tools, I'll write up a = PR and we can discuss in BKK.

--Richard

[1] https://ipv.sx/treekem/
[2] https://github.com/bifurcation/treekem/commit/7f470422ba61ce668= c3ab1d6b2d18edd9d6e06fd
_______________________________________________
MLS = mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_1E3B772A-9379-4A47-A542-14E880FBD9BA-- From nobody Tue Oct 23 05:16:00 2018 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 1BC9A12785F for ; Tue, 23 Oct 2018 05:15:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 myjhReBNcuSY for ; Tue, 23 Oct 2018 05:15:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BA4130E35 for ; Tue, 23 Oct 2018 05:15:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0C35C300A40 for ; Tue, 23 Oct 2018 08:15:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6xnamSbAyCif for ; Tue, 23 Oct 2018 08:15:49 -0400 (EDT) Received: from [5.5.33.214] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 8D381300258; Tue, 23 Oct 2018 08:15:48 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_69371053-640A-4148-BEDE-FD2E765E6DC0" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 23 Oct 2018 08:15:48 -0400 In-Reply-To: Cc: mls@ietf.org To: Raphael Robert , Richard Barnes References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Move / Add-in-place / Compounding X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 12:15:58 -0000 --Apple-Mail=_69371053-640A-4148-BEDE-FD2E765E6DC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Don't add and move make synchronization concerns worse? Can two clients = ask for the same empty-when-they-looked node? Russ > On Oct 22, 2018, at 2:59 PM, Raphael Robert wrote: >=20 > I think these two operations make perfect sense (had the same ones in = mind). Some comments: >=20 > Regarding Move: > We should work on a recommendation of when to do a Move instead of an = Update, and also of when to do a Move even if no Update was planned. > The recommendation could initially be something naive, such as: when = the ratio of blank leaves / full leaves is greater than xxx, do a Move.=20= >=20 > Regarding Add-in-place: > I think this has the potential of becoming the default, as opposed to = the current Add. Maybe both operations could be one and the same if we = just add an index to the current Add. In that case the recommendation = for the index would simply be the left-most empty leaf node. >=20 > If both operations are correctly applied by clients, the tree should = have the optimal size. > There is however a case where trees will not shrink, but only if the = following three conditions are met: >=20 > - A large number of members left the group (large is relative to the = group size) > - A large number of the remaining members never come online again and = therefore cannot move themselves (large is again relative to the = remaining group size) > - Only very few new members are added subsequently >=20 > I suspect that the above scenario is however an edge case. If it = occurs =E2=80=9Cin the wild=E2=80=9D it might eventually get solved on a = social level (when unresponsive members get removed by active ones). >=20 >=20 >> On 22 Oct 2018, at 20:34, Richard Barnes > wrote: >>=20 >> Hey MLS folks, >>=20 >> tl;dr:=20 >> - Would there be interest in a Move operation? >> - How about an operation to Add a new member in an open slot instead = of the right edge? >>=20 >> In looking at the "partial tree" stuff (#67), it occurred to me that = once you have partial trees with blank leaves, you can in principle do = two new operations: An existing member can move from one leaf in the = tree to another; and an existing member can add a new member at a leaf = that is currently blank. These operations would work roughly as = follows: >>=20 >> - Move: >> - Blank out old dirpath >> - Move credential from old slot to new slow >> - Send update along new dirpath >> - Add-in-place: >> - Blank out dirpath for slot >> - Install new member's leaf key in slot >> - Install new member's credential in slot >>=20 >> For Move, you would also want to have people step down the size of = the tree. For example, if you go from having 10 leaves (X _ X X _ _ _ _ = _ X) to four leaves (X X X X) as the result of a move, then the = resulting tree should only have height 2, not 4 (as is required for 10 = leaves). Fortunately, this is trivial with the tree math defined in the = document; you just truncate the node vector, and the calculated root = gets correspondingly smaller. >>=20 >> I've prototyped this out in my JS stack [1][2]. Once you've built a = tree, and removed a couple of members, you can click one of the "Move" = buttons to move that node to the lowest open slot. As you can see, it's = not a ton of code. >>=20 >> In any case, this seems to me to be potentially useful, since it = addresses the issue that was raised in the BoF that the size of the = resources for a group increases monotically. Move allows you to reclaim = resources that are unused (assuming some orchestration outside of MLS), = and Add-in-place allows us to be conservative with resources that are = already allocated (cf. realloc). >>=20 >> If folks think these sound like useful tools, I'll write up a PR and = we can discuss in BKK. >>=20 >> --Richard >>=20 >> [1] https://ipv.sx/treekem/ >> [2] = https://github.com/bifurcation/treekem/commit/7f470422ba61ce668c3ab1d6b2d1= 8edd9d6e06fd = >> _______________________________________________ >> 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=_69371053-640A-4148-BEDE-FD2E765E6DC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Don't add and move make synchronization concerns worse?  = Can two clients ask for the same empty-when-they-looked node?

Russ


On Oct 22, 2018, at 2:59 PM, = Raphael Robert <raphael@wire.com> wrote:

I think these two = operations make perfect sense (had the same ones in mind). Some = comments:

Regarding = Move:
We should work on a recommendation of when to = do a Move instead of an Update, and also of when to do a Move even if no = Update was planned.
The recommendation could = initially be something naive, such as: when the ratio of blank leaves / = full leaves is greater than xxx, do a Move. 
Regarding Add-in-place:
I think this has the potential of becoming the default, as = opposed to the current Add. Maybe both operations could be one and the = same if we just add an index to the current Add. In that case the = recommendation for the index would simply be the left-most empty leaf = node.

If both = operations are correctly applied by clients, the tree should have the = optimal size.
There is however a case where trees = will not shrink, but only if the following three conditions are = met:

 - A = large number of members left the group (large is relative to the group = size)
 - A large number of the remaining = members never come online again and therefore cannot move themselves = (large is again relative to the remaining group size)
 - Only very few new members are added = subsequently

I = suspect that the above scenario is however an edge case. If it occurs = =E2=80=9Cin the wild=E2=80=9D it might eventually get solved on a social = level (when unresponsive members get removed by active ones).


On 22 = Oct 2018, at 20:34, Richard Barnes <rlb@ipv.sx> wrote:

Hey MLS folks,

tl;dr:
- Would there be = interest in a Move operation?
- How about an = operation to Add a new member in an open slot instead of the right = edge?

In looking at the "partial tree" stuff (#67), it occurred to = me that once you have partial trees with blank leaves, you can in = principle do two new operations: An existing member can move from one = leaf in the tree to another; and an existing member can add a new member = at a leaf that is currently blank.  These operations would work = roughly as follows:

- Move:
    - Blank out = old dirpath
    - = Move credential from old slot to new slow
    - Send update along new = dirpath
- Add-in-place:
    - Blank out dirpath for slot
    - Install new member's leaf key in = slot
    - Install new member's = credential in slot

For = Move, you would also want to have people step down the size of the = tree.  For example, if you go from having 10 leaves (X _ X X _ _ _ = _ _ X) to four leaves (X X X X) as the result of a move, then the = resulting tree should only have height 2, not 4 (as is required for 10 = leaves).  Fortunately, this is trivial with the tree math defined = in the document; you just truncate the node vector, and the calculated = root gets correspondingly smaller.

I've prototyped this out in my JS stack = [1][2].  Once you've built a tree, and removed a couple of members, = you can click one of the "Move" buttons to move that node to the lowest = open slot.  As you can see, it's not a ton of code.

In any case, this seems = to me to be potentially useful, since it addresses the issue that was = raised in the BoF that the size of the resources for a group increases = monotically.  Move allows you to reclaim resources that are unused = (assuming some orchestration outside of MLS), and Add-in-place allows us = to be conservative with resources that are already allocated (cf. = realloc).

If folks think these sound like useful tools, I'll write up a = PR and we can discuss in BKK.

--Richard

[1] https://ipv.sx/treekem/
[2] https://github.com/bifurcation/treekem/commit/7f470422ba61ce668= c3ab1d6b2d18edd9d6e06fd
_______________________________________________
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=_69371053-640A-4148-BEDE-FD2E765E6DC0-- From nobody Tue Oct 23 06:34:20 2018 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 E80CA130F59 for ; Tue, 23 Oct 2018 06:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ULzuegT2OF38 for ; Tue, 23 Oct 2018 06:34:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27701130FA5 for ; Tue, 23 Oct 2018 06:34:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BAAAB300A49 for ; Tue, 23 Oct 2018 09:34:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IBqPyDCKfoy8 for ; Tue, 23 Oct 2018 09:34:02 -0400 (EDT) Received: from [5.5.33.215] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 4E861300523; Tue, 23 Oct 2018 09:34:01 -0400 (EDT) From: Russ Housley Message-Id: <58A76FA7-6A4B-4E78-8631-A20CD20AE533@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A51D4B3B-A145-4744-9789-42630026A6F7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 23 Oct 2018 09:33:58 -0400 In-Reply-To: Cc: mls@ietf.org To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Key confirmation - Extra MAC needed? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 13:34:18 -0000 --Apple-Mail=_A51D4B3B-A145-4744-9789-42630026A6F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Hey all, >=20 > In the just-released -02 draft of MLS, I've added a key confirmation = step to the handshake authentication process. Important question after = "=3D=3D=3D=3D=3D" below... >=20 > In the previous draft, there was an authentication mechanism that = ensured that if two group members ended up with different GroupState = objects, then they would have different keys. However, it did not = provide any way for group members to recognize that this was the case, = except for AEAD checks on encrypted messages failing. With explicit key = confirmation, the recipient of a Handshake message knows that if = processing of the handshake message succeeds, then the recipient has the = same GroupState as the sender. >=20 > This provides a degree of protection against malicious insiders that = send different TreeKEM values to different parts of the tree. Namely, = only the subset of the tree that got the key matching the key = confirmation will accept the Handshake message; the others will be = locked out. (Assuming a broadcast channel; if the sender can send = different key confirmations to different recipients, then this is no = help.). This isn't complete protection, but at least the locked-out = members know they've been locked out, and can complain about it. >=20 > =3D=3D=3D=3D=3D >=20 > The major question here is whether it's sufficient to derive a key = confirmation value from the key schedule and publish it, or whether the = value derived in the key schedule should be used as a MAC key to = generate a MAC over the message transcript. I've posted PRs for both; = the latter is what I merged in -02 >=20 > Derive: https://github.com/mlswg/mls-protocol/pull/72 = > MAC: https://github.com/mlswg/mls-protocol/pull/71 = >=20 > On the one hand, the MAC-based approach is what is done in TLS. It = feels safer, because we never publish anything that's in the key = schedule diagram. >=20 > On the other hand, the Derive-Secret operation used to create the key = confirmation value in the key schedule is **already** based on HMAC. So = it doesn't seem like the extra MAC step is adding that much value. >=20 > If we can convince ourselves that the Derive approach (without the = extra MAC) is sufficient, I would prefer to do that, since it's simpler. = But feedback on this point would be very much appreciated. The Derive approach is straightforward. If this leaks in any surprising = way, then draft-ietf-tls-exported-authenticator has a problem too, = right? Russ --Apple-Mail=_A51D4B3B-A145-4744-9789-42630026A6F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hey all,

In the just-released -02 draft of MLS, = I've added a key confirmation step to the handshake authentication = process.  Important question after "=3D=3D=3D=3D=3D" below...

In = the previous draft, there was an authentication mechanism that ensured = that if two group members ended up with different GroupState objects, = then they would have different keys.  However, it did not provide = any way for group members to recognize that this was the case, except = for AEAD checks on encrypted messages failing.  With explicit key = confirmation, the recipient of a Handshake message knows that if = processing of the handshake message succeeds, then the recipient has the = same GroupState as the sender.

This provides a degree of protection = against malicious insiders that send different TreeKEM values to = different parts of the tree.  Namely, only the subset of the tree = that got the key matching the key confirmation will accept the Handshake = message; the others will be locked out. (Assuming a broadcast channel; = if the sender can send different key confirmations to different = recipients, then this is no help.). This isn't complete protection, but = at least the locked-out members know they've been locked out, and can = complain about it.

=3D=3D=3D=3D=3D

The major question here is whether it's = sufficient to derive a key confirmation value from the key schedule and = publish it, or whether the value derived in the key schedule should be = used as a MAC key to generate a MAC over the message = transcript.   I've posted PRs for both; the latter is what I = merged in -02

Derive: = https://github.com/mlswg/mls-protocol/pull/72
MAC: https://github.com/mlswg/mls-protocol/pull/71

On = the one hand, the MAC-based approach is what is done in TLS.  It = feels safer, because we never publish anything that's in the key = schedule diagram.

On the other hand, the Derive-Secret operation used to create = the key confirmation value in the key schedule is **already** based on = HMAC.  So it doesn't seem like the extra MAC step is adding that = much value.

If = we can convince ourselves that the Derive approach (without the extra = MAC) is sufficient, I would prefer to do that, since it's simpler.  = But feedback on this point would be very much = appreciated.

The Derive approach is straightforward. =  If this leaks in any surprising way, then draft-ietf-tls-exported-authenticator has a problem = too, right?

Russ

= --Apple-Mail=_A51D4B3B-A145-4744-9789-42630026A6F7-- From nobody Tue Oct 23 07:45:22 2018 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 C9DF9128BCC for ; Tue, 23 Oct 2018 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHk2b0CCXk5a for ; Tue, 23 Oct 2018 07:45:17 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 89020128D09 for ; Tue, 23 Oct 2018 07:45:12 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id p23so1603745otf.11 for ; Tue, 23 Oct 2018 07:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RWYUm1h700o6QCOWGNOmS6VHuLKIJAft30Pk/vmZzlA=; b=kRJxgJDF7+7WpbOHSOSE8C/vHyeE5zQYF6wcNEnPkpa6l9MDk04S1WZGiKfYlT6x+D Fj1gWVDUoSEsGV4n6vE6VnQdvsji8EU4Di0pwPExLqhkHvkstMEKsx6TFigar4TJRf4n j9OqvvKp9ZSaTPMfrByWNvDMk2UouSnAnzxUwvKIMl5LXpYAC37qw3JWSBmLsovWGpOm 5tTxrEYcD4gUcLlhkzDuWE1Zmgzk/PqbeaeXc2i0BhPyr+NvY4rt5zciDBazrGRmNRDa XgW6PFAiaCPBtiGPQpPZu3nu4Bzn5s9JaNMifY6ksqmryywnPsCYUF1ZAuqIvzPZefe3 9fbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RWYUm1h700o6QCOWGNOmS6VHuLKIJAft30Pk/vmZzlA=; b=e4b/7vG0LS78I/rq44k4XiyRRd34pDWD8u5chAWixFd/ZeOXRm6MyFGrEYb9erJdNC U8QpCYGx//l5Ov51k8Q/Yxqbew7fQXGU0vCUvcarMnFIIIlCm/CyIDmkfWyf8N1L0j6o toDDjwucxa8JHR9SxFd/pHwaPVK5BrI2XysG1B43KdI/ljinA8W00IA8G2VnuWTs+vT5 mp7odp+Kmup59z1lv8aDjUbpP3N+BfUAmuaY42xldgo6Fd4TFs/A5IHshd2+k13Cg0Dn FMz6r5buHnqZlZjTXXSM8ibnN+fOXL25kZ/oS2/vEbO/Z+nOBiVo8Uk9gI840oiIPcxB 1XHw== X-Gm-Message-State: AGRZ1gK4U3W55Z36u7iUWI6fzcBvk83NLYdiVF9diH6TVpZHp+9exTpt i16rDV64T0zZEPb8INMIa+50hQaMtqOI932iyULHMA== X-Google-Smtp-Source: AJdET5e4qTiE+0z0uFycopLONXSSsErmU5A0HhTfve/A63nRm8t8FWhheZKSDK5eHbvBSj6SLDB78j7GhaxbyJSMGRo= X-Received: by 2002:a9d:1c85:: with SMTP id l5mr294944ota.331.1540305911476; Tue, 23 Oct 2018 07:45:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 23 Oct 2018 07:44:56 -0700 Message-ID: To: Russ Housley Cc: Raphael Robert , mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000b3087e0578e66a51" Archived-At: Subject: Re: [MLS] Move / Add-in-place / Compounding X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 14:45:21 -0000 --000000000000b3087e0578e66a51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree there are synchronization problems, but I don't think they're appreciably worse than before. Right now, when you have an Update or Add conflict now, the retry logic is "do it again"; for Remove, it's either "do it again" or "never mind", depending on whether the thing you conflicted with was a Remove for the same slot. When you have a conflict with Move / Add-in-place, the retry logic is "do it again with a different slot" or "never mind", where the latter hits if you were going to move to a lower slot to compact the tree, but all the lower slots are now filled. So the only major difference relative to the above is that you need to pick a new target. That seems as straightforward as a lowest_available_slot() method, which returns the next leaf if the tree is full. In any case, once we settle down on the set of operations, we should take another stab at describing retry considerations. I filed an issue [1]. --Richard [1] https://github.com/mlswg/mls-protocol/issues/76 On Tue, Oct 23, 2018 at 5:15 AM Russ Housley wrote: > Don't add and move make synchronization concerns worse? Can two clients > ask for the same empty-when-they-looked node? > > Russ > > > On Oct 22, 2018, at 2:59 PM, Raphael Robert wrote: > > I think these two operations make perfect sense (had the same ones in > mind). Some comments: > > Regarding Move: > We should work on a recommendation of when to do a Move instead of an > Update, and also of when to do a Move even if no Update was planned. > The recommendation could initially be something naive, such as: when the > ratio of blank leaves / full leaves is greater than xxx, do a Move. > > Regarding Add-in-place: > I think this has the potential of becoming the default, as opposed to the > current Add. Maybe both operations could be one and the same if we just a= dd > an index to the current Add. In that case the recommendation for the inde= x > would simply be the left-most empty leaf node. > > If both operations are correctly applied by clients, the tree should have > the optimal size. > There is however a case where trees will not shrink, but only if the > following three conditions are met: > > - A large number of members left the group (large is relative to the > group size) > - A large number of the remaining members never come online again and > therefore cannot move themselves (large is again relative to the remainin= g > group size) > - Only very few new members are added subsequently > > I suspect that the above scenario is however an edge case. If it occurs > =E2=80=9Cin the wild=E2=80=9D it might eventually get solved on a social = level (when > unresponsive members get removed by active ones). > > > On 22 Oct 2018, at 20:34, Richard Barnes wrote: > > Hey MLS folks, > > tl;dr: > - Would there be interest in a Move operation? > - How about an operation to Add a new member in an open slot instead of > the right edge? > > In looking at the "partial tree" stuff (#67), it occurred to me that once > you have partial trees with blank leaves, you can in principle do two new > operations: An existing member can move from one leaf in the tree to > another; and an existing member can add a new member at a leaf that is > currently blank. These operations would work roughly as follows: > > - Move: > - Blank out old dirpath > - Move credential from old slot to new slow > - Send update along new dirpath > - Add-in-place: > - Blank out dirpath for slot > - Install new member's leaf key in slot > - Install new member's credential in slot > > For Move, you would also want to have people step down the size of the > tree. For example, if you go from having 10 leaves (X _ X X _ _ _ _ _ X) > to four leaves (X X X X) as the result of a move, then the resulting tree > should only have height 2, not 4 (as is required for 10 leaves). > Fortunately, this is trivial with the tree math defined in the document; > you just truncate the node vector, and the calculated root gets > correspondingly smaller. > > I've prototyped this out in my JS stack [1][2]. Once you've built a tree= , > and removed a couple of members, you can click one of the "Move" buttons = to > move that node to the lowest open slot. As you can see, it's not a ton o= f > code. > > In any case, this seems to me to be potentially useful, since it addresse= s > the issue that was raised in the BoF that the size of the resources for a > group increases monotically. Move allows you to reclaim resources that a= re > unused (assuming some orchestration outside of MLS), and Add-in-place > allows us to be conservative with resources that are already allocated (c= f. > realloc). > > If folks think these sound like useful tools, I'll write up a PR and we > can discuss in BKK. > > --Richard > > [1] https://ipv.sx/treekem/ > [2] > https://github.com/bifurcation/treekem/commit/7f470422ba61ce668c3ab1d6b2d= 18edd9d6e06fd > _______________________________________________ > 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 > > > --000000000000b3087e0578e66a51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree there are synchronization pr= oblems, but I don't think they're appreciably worse than before.=C2= =A0

Right now, when you have an Update or Add= conflict now, the retry logic is "do it again"; for Remove, it&#= 39;s either "do it again" or "never mind", depending on= whether the thing you conflicted with was a Remove for the same slot.=C2= =A0

When you have a conflict with Move / Add-= in-place, the retry logic is "do it again with a different slot" = or "never mind", where the latter hits if you were going to move = to a lower slot to compact the tree, but all the lower slots are now filled= .=C2=A0 So the only major difference relative to the above is that you need= to pick a new target.=C2=A0 That seems as straightforward as a lowest_avai= lable_slot() method, which returns the next leaf if the tree is full.
<= /div>

In any case, once we settle down on the set of ope= rations, we should take another stab at describing retry considerations.=C2= =A0 I filed an issue [1].

--Richard
=

On Tue, Oct 23, 2018 at 5= :15 AM Russ Housley <housley@vig= ilsec.com> wrote:
Don't add= and move make synchronization concerns worse?=C2=A0 Can two clients ask fo= r the same empty-when-they-looked node?

Russ
=


On Oct 22, 2018, at = 2:59 PM, Raphael Robert <raphael@wire.com> wrote:

I think these two operations make perfect sense (= had the same ones in mind). Some comments:

Regarding Mov= e:
We should work on a recommendation of when to do a Move instea= d of an Update, and also of when to do a Move even if no Update was planned= .
The recommendation could initially be something naive, such as:= when the ratio of blank leaves / full leaves is greater than xxx, do a Mov= e.=C2=A0

Regarding Add-in-place:
I think= this has the potential of becoming the default, as opposed to the current = Add. Maybe both operations could be one and the same if we just add an inde= x to the current Add. In that case the recommendation for the index would s= imply be the left-most empty leaf node.

If both op= erations are correctly applied by clients, the tree should have the optimal= size.
There is however a case where trees will not shrink, but o= nly if the following three conditions are met:

=C2= =A0- A large number of members left the group (large is relative to the gro= up size)
=C2=A0- A large number of the remaining members never co= me online again and therefore cannot move themselves (large is again relati= ve to the remaining group size)
=C2=A0- Only very few new members= are added subsequently

I suspect that the above s= cenario is however an edge case. If it occurs =E2=80=9Cin the wild=E2=80=9D= it might eventually get solved on a social level (when unresponsive member= s get removed by active ones).


On 22 Oct 2018, at 20:34, Richard Barnes <rlb@ipv.sx> wrote:
Hey MLS folks,

<= /div>
tl;dr:
- Would there be interest in a Move operati= on?
- How about an operation to Add a new member in an open slot = instead of the right edge?

In looking at the &= quot;partial tree" stuff (#67), it occurred to me that once you have p= artial trees with blank leaves, you can in principle do two new operations:= An existing member can move from one leaf in the tree to another; and an e= xisting member can add a new member at a leaf that is currently blank.=C2= =A0 These operations would work roughly as follows:

- Move:
=C2=A0=C2=A0=C2=A0 - Blank out old dirpath
=C2=A0=C2=A0=C2=A0 - Move credential from old slot to new slow
<= div>
=C2=A0=C2=A0=C2=A0 - Send update along new dirpath
- Add-in-place:
=C2=A0=C2=A0=C2=A0 - Blank out dirpath for slot<= /div>
=C2=A0=C2=A0=C2=A0 - Install new member's leaf key in slot
=C2=A0=C2=A0=C2=A0 - Install new member's credential in slot
For Move, you would also want to have people step down the = size of the tree.=C2=A0 For example, if you go from having 10 leaves (X _ X= X _ _ _ _ _ X) to four leaves (X X X X) as the result of a move, then the = resulting tree should only have height 2, not 4 (as is required for 10 leav= es).=C2=A0 Fortunately, this is trivial with the tree math defined in the d= ocument; you just truncate the node vector, and the calculated root gets co= rrespondingly smaller.

I've prototyped this ou= t in my JS stack [1][2].=C2=A0 Once you've built a tree, and removed a = couple of members, you can click one of the "Move" buttons to mov= e that node to the lowest open slot.=C2=A0 As you can see, it's not a t= on of code.

In any case, this seems to me to be po= tentially useful, since it addresses the issue that was raised in the BoF t= hat the size of the resources for a group increases monotically.=C2=A0 Move= allows you to reclaim resources that are unused (assuming some orchestrati= on outside of MLS), and Add-in-place allows us to be conservative with reso= urces that are already allocated (cf. realloc).

If folks think these sound like useful tools, I'll write up a PR and = we can discuss in BKK.

--Richard

_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

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

--000000000000b3087e0578e66a51-- From nobody Tue Oct 23 08:08:34 2018 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 2705613102D for ; Tue, 23 Oct 2018 08:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMkHw5O2NaV7 for ; Tue, 23 Oct 2018 08:08:27 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 6245F130EE1 for ; Tue, 23 Oct 2018 08:08:26 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id x4so1716554otg.3 for ; Tue, 23 Oct 2018 08:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4fj16CdPEAxegQbh3gdaYMSuxVuazSuuVuE7T0Gt4cI=; b=jspHF+8tqs3T6Y0HkHinxRF7SvL8AKP7x9uUS4jJwkKtjeFbCOOzrkMix8nRAACTLw MVFoy7gcKA5Bd9cvw/scs9tV6TtySoU4dbgHuXXBAhMYL55slxkZKUSxEwI47HD+4X37 qTxITu4RreQNxZZyKofcc3X4jrabdui0lefN8HD35TCPmHtx5Pt3jNbm4rtvaQkHqROG Xv7cFC0PBzwg//XL3NDgMhN3KzReqlpZ5W9NY7ab5l6kGt+qJezPxzhIDX+4XNKSOknc zUL4TN8aXe8zZ5J7dnd5A/StCsalkVVjXuUhRHKk2OctzfBzOhTrPCaE4WQBRP0t4wMT CtNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4fj16CdPEAxegQbh3gdaYMSuxVuazSuuVuE7T0Gt4cI=; b=t+Jvpz1B+Ct8FD8Y45jGF00kIPzixx+uaSRfN9ThJsgoZ50f6/6sGadExCYXeU4b5S drJcsymruy8UDk1jN2RpSyOyNulQgvOO8dle3//XGPlJ9iIY7R/WK0DJqIAqBUx/mzJk qIXQVK5JaFSX0aaASkq14SEaeUwG595pTdq7Ev2AyX1AkRl3G/lZFs6dY4vfp3VviziZ eQjT077G5v4cH4nLcfE3hLxvf9sack1CgF2dilLC6/pPIwKf5P1WJfIlzfMrrmP1ixB1 Au7GDUkGAornJ7xM/wQaNAkVMkIz+B0SFC26oQApvrnISWZCBq1xqGKdkrO6FK+fFxHb FvNQ== X-Gm-Message-State: ABuFfogPo1x9WMAcsWg28XRGt+c/C4uFcOKMGs4TIeMjQWSuVF23oZB4 pqWR3Bghzf6PBbcCNxYFMmVkiMMKbPvg6G7RE1l6bbVN X-Google-Smtp-Source: ACcGV63htQSM2HbCJrBPSTr83bHx3G/KFpNZaMbtnMASRGTh8aJkJqtRZwjgD6K9mF/Tt69lCQJqIE9L7HQ1zIqebYw= X-Received: by 2002:a9d:2377:: with SMTP id k52mr32825531otd.238.1540307305522; Tue, 23 Oct 2018 08:08:25 -0700 (PDT) MIME-Version: 1.0 References: <58A76FA7-6A4B-4E78-8631-A20CD20AE533@vigilsec.com> In-Reply-To: <58A76FA7-6A4B-4E78-8631-A20CD20AE533@vigilsec.com> From: Richard Barnes Date: Tue, 23 Oct 2018 08:08:06 -0700 Message-ID: To: Russ Housley Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000ca79e30578e6bd1e" Archived-At: Subject: Re: [MLS] Key confirmation - Extra MAC needed? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 15:08:33 -0000 --000000000000ca79e30578e6bd1e Content-Type: text/plain; charset="UTF-8" On Tue, Oct 23, 2018 at 6:34 AM Russ Housley wrote: > > Hey all, > > In the just-released -02 draft of MLS, I've added a key confirmation step > to the handshake authentication process. Important question after "=====" > below... > > In the previous draft, there was an authentication mechanism that ensured > that if two group members ended up with different GroupState objects, then > they would have different keys. However, it did not provide any way for > group members to recognize that this was the case, except for AEAD checks > on encrypted messages failing. With explicit key confirmation, the > recipient of a Handshake message knows that if processing of the handshake > message succeeds, then the recipient has the same GroupState as the sender. > > This provides a degree of protection against malicious insiders that send > different TreeKEM values to different parts of the tree. Namely, only the > subset of the tree that got the key matching the key confirmation will > accept the Handshake message; the others will be locked out. (Assuming a > broadcast channel; if the sender can send different key confirmations to > different recipients, then this is no help.). This isn't complete > protection, but at least the locked-out members know they've been locked > out, and can complain about it. > > ===== > > The major question here is whether it's sufficient to derive a key > confirmation value from the key schedule and publish it, or whether the > value derived in the key schedule should be used as a MAC key to generate a > MAC over the message transcript. I've posted PRs for both; the latter is > what I merged in -02 > > Derive: https://github.com/mlswg/mls-protocol/pull/72 > MAC: https://github.com/mlswg/mls-protocol/pull/71 > > On the one hand, the MAC-based approach is what is done in TLS. It feels > safer, because we never publish anything that's in the key schedule diagram. > > On the other hand, the Derive-Secret operation used to create the key > confirmation value in the key schedule is **already** based on HMAC. So it > doesn't seem like the extra MAC step is adding that much value. > > If we can convince ourselves that the Derive approach (without the extra > MAC) is sufficient, I would prefer to do that, since it's simpler. But > feedback on this point would be very much appreciated. > > > The Derive approach is straightforward. If this leaks in any surprising > way, then draft-ietf-tls-exported-authenticator has a problem too, right? > I don't think that necessarily follows. That draft follows the MAC approach, in that the values it exports from the TLS key schedule are used as inputs to a MAC, and only the MAC output is published. That said, I agree it's instructive to look at uses of the TLS exporter to identify parallel risks here. You would want to find some case where an exported value is used as a public value. Unfortunately, the only other major usage of exporters that comes to mind is DTLS-SRTP, which exports a key and salt. You could use that to argue either way, since the salt is notionally public, but in practice is never published. --Richard --000000000000ca79e30578e6bd1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Oct 23, 2018 at 6:34 AM Russ Housley <housley@vigilsec.com> wrote:
<= br>
Hey all,

In the just-released = -02 draft of MLS, I've added a key confirmation step to the handshake a= uthentication process.=C2=A0 Important question after "=3D=3D=3D=3D=3D= " below...

In the previous draft, there w= as an authentication mechanism that ensured that if two group members ended= up with different GroupState objects, then they would have different keys.= =C2=A0 However, it did not provide any way for group members to recognize t= hat this was the case, except for AEAD checks on encrypted messages failing= .=C2=A0 With explicit key confirmation, the recipient of a Handshake messag= e knows that if processing of the handshake message succeeds, then the reci= pient has the same GroupState as the sender.

This = provides a degree of protection against malicious insiders that send differ= ent TreeKEM values to different parts of the tree.=C2=A0 Namely, only the s= ubset of the tree that got the key matching the key confirmation will accep= t the Handshake message; the others will be locked out. (Assuming a broadca= st channel; if the sender can send different key confirmations to different= recipients, then this is no help.). This isn't complete protection, bu= t at least the locked-out members know they've been locked out, and can= complain about it.

=3D=3D=3D=3D=3D
=
The major question here is whether it's sufficient to de= rive a key confirmation value from the key schedule and publish it, or whet= her the value derived in the key schedule should be used as a MAC key to ge= nerate a MAC over the message transcript.=C2=A0=C2=A0 I've posted PRs f= or both; the latter is what I merged in -02

On th= e one hand, the MAC-based approach is what is done in TLS.=C2=A0 It feels s= afer, because we never publish anything that's in the key schedule diag= ram.

On the other hand, the Derive-Secret operatio= n used to create the key confirmation value in the key schedule is **alread= y** based on HMAC.=C2=A0 So it doesn't seem like the extra MAC step is = adding that much value.

If we can convince ourselv= es that the Derive approach (without the extra MAC) is sufficient, I would = prefer to do that, since it's simpler.=C2=A0 But feedback on this point= would be very much appreciated.
=

The Derive approach is straightforward.=C2=A0 If this leaks = in any surprising way, then=C2=A0draft-ietf-tls-exported-authenticato= r has a problem too, right?

<= div>I don't think that necessarily follows.=C2=A0 That draft follows th= e MAC approach, in that the values it exports from the TLS key schedule are= used as inputs to a MAC, and only the MAC output is published.
<= br>
That said, I agree it's instructive to look at uses of th= e TLS exporter to identify parallel risks here.=C2=A0 You would want to fin= d some case where an exported value is used as a public value.=C2=A0 Unfort= unately, the only other major usage of exporters that comes to mind is DTLS= -SRTP, which exports a key and salt.=C2=A0 You could use that to argue eith= er way, since the salt is notionally public, but in practice is never publi= shed.

--Richard

--000000000000ca79e30578e6bd1e-- From nobody Tue Oct 23 08:13:03 2018 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 BFEA312EB11 for ; Tue, 23 Oct 2018 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=fZMV/q2F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N/t5Nq0n 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 07MTAaa0D-cO for ; Tue, 23 Oct 2018 08:12:58 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA03130E2A for ; Tue, 23 Oct 2018 08:12:58 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8DEE321D12 for ; Tue, 23 Oct 2018 11:12:57 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 23 Oct 2018 11:12:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= 3QTaa7dA+tWKRvD95pvAmXkNDGcou3LkbRu9Mtpr7K8=; b=fZMV/q2FVvL7sKtK TgHMlgmDASCRyTIzYmkTSPNW/P8ekoNF7FLtaskLB0vXlVbtyuPLUuUQcpAfNdKD ez+VlHybtgG2IBcsKda8IPeQ5R28sxemgKvA/igLwqhPwWxBCzAHr6oXWTnxnCx/ PNY/c4A8zx3vKe45YyFaMhhTwJg= 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=3QTaa7dA+tWKRvD95pvAmXkNDGcou3LkbRu9Mtpr7 K8=; b=N/t5Nq0nYt9N76zDAgh8yw1SSgBCGJt3MYBH8oq90GkZYW/NMKoo6tBOQ 3ocLVMFF9Ed5mpT7Xc5sGQ0p5lUWIwU0tCXwoSmGBErNBn1uGtix7gm/G6o5c5lt IQKeFsdFdUU5RidaB/KtoQnJUygah5jBOxOIhcVYKCM+mcxV49ZAYqiUoBGYOvlj SqRYKqSUJOI4t6NsakshHsgJqOaJOwgfIEUbudBXGPWpXw8ULuFRwQGggNuhIlRF Ivex5k7CN7HOz6R3Ht3x99/6a0UgTlzLHEeQSoaMwkPEliH/P1MqaHPgb4Ac5v7q 5itv2ghR/eI0zq6X8gu2xOUL5GqRg== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 340DE9E172; Tue, 23 Oct 2018 11:12:57 -0400 (EDT) Message-Id: <1540307577.2861642.1551828416.05A754F2@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154030757728616420" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b315a288 Date: Tue, 23 Oct 2018 16:12:57 +0100 In-Reply-To: References: <58A76FA7-6A4B-4E78-8631-A20CD20AE533@vigilsec.com> Archived-At: Subject: Re: [MLS] Key confirmation - Extra MAC needed? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 15:13:02 -0000 This is a multi-part message in MIME format. --_----------=_154030757728616420 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I wouldn't die on this hill, but I prefer the MAC design just for cleanness reasons in analysis. Collapsing the final two MAC invocations in the derivation doesn't seem like it gets you very much. Note that we wouldn't have to MAC over the message transcript---over the constant zero might be enough. k On Tue, 23 Oct 2018, at 4:08 PM, Richard Barnes wrote: > > > On Tue, Oct 23, 2018 at 6:34 AM Russ Housley > wrote:>> >>> Hey all, >>> >>> In the just-released -02 draft of MLS, I've added a key confirmation >>> step to the handshake authentication process. Important question >>> after "=====" below...>>> >>> In the previous draft, there was an authentication mechanism that >>> ensured that if two group members ended up with different GroupState >>> objects, then they would have different keys. However, it did not >>> provide any way for group members to recognize that this was the >>> case, except for AEAD checks on encrypted messages failing.. With >>> explicit key confirmation, the recipient of a Handshake message >>> knows that if processing of the handshake message succeeds, then the >>> recipient has the same GroupState as the sender.>>> >>> This provides a degree of protection against malicious insiders that >>> send different TreeKEM values to different parts of the tree. >>> Namely, only the subset of the tree that got the key matching the >>> key confirmation will accept the Handshake message; the others will >>> be locked out. (Assuming a broadcast channel; if the sender can send >>> different key confirmations to different recipients, then this is no >>> help.). This isn't complete protection, but at least the locked-out >>> members know they've been locked out, and can complain about it.>>> >>> ===== >>> >>> The major question here is whether it's sufficient to derive a key >>> confirmation value from the key schedule and publish it, or whether >>> the value derived in the key schedule should be used as a MAC key to >>> generate a MAC over the message transcript. I've posted PRs for >>> both; the latter is what I merged in -02>>> >>> Derive: https://github.com/mlswg/mls-protocol/pull/72 >>> MAC: https://github.com/mlswg/mls-protocol/pull/71 >>> >>> On the one hand, the MAC-based approach is what is done in TLS. It >>> feels safer, because we never publish anything that's in the key >>> schedule diagram.>>> >>> On the other hand, the Derive-Secret operation used to create the >>> key confirmation value in the key schedule is **already** based on >>> HMAC. So it doesn't seem like the extra MAC step is adding that >>> much value.>>> >>> If we can convince ourselves that the Derive approach (without the >>> extra MAC) is sufficient, I would prefer to do that, since it's >>> simpler. But feedback on this point would be very much appreciated.>> >> The Derive approach is straightforward. If this leaks in any >> surprising way, then draft-ietf-tls-exported-authenticator has a >> problem too, right?> > I don't think that necessarily follows. That draft follows the MAC > approach, in that the values it exports from the TLS key schedule are > used as inputs to a MAC, and only the MAC output is published.> > That said, I agree it's instructive to look at uses of the TLS > exporter to identify parallel risks here. You would want to find some > case where an exported value is used as a public value. > Unfortunately, the only other major usage of exporters that comes to > mind is DTLS-SRTP, which exports a key and salt. You could use that > to argue either way, since the salt is notionally public, but in > practice is never published.> > --Richard > > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --_----------=_154030757728616420 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I wouldn't die on this hill, but I prefer the MAC design just for cleanness reasons in analysis. Collapsing the final two MAC invocations in the derivation doesn't seem like it gets you very much.

Note that we wouldn't have to MAC over the message transcript---over the constant zero might be enough.

k


On Tue, 23 Oct 2018, at 4:08 PM, Richard Barnes wrote:


On Tue, Oct 23, 2018 at 6:34 AM Russ Housley <housley@vigilsec.com> wrote:

Hey all,

In the just-released -02 draft of MLS, I've added a key confirmation step to the handshake authentication process.  Important question after "=====" below...

In the previous draft, there was an authentication mechanism that ensured that if two group members ended up with different GroupState objects, then they would have different keys.  However, it did not provide any way for group members to recognize that this was the case, except for AEAD checks on encrypted messages failing..  With explicit key confirmation, the recipient of a Handshake message knows that if processing of the handshake message succeeds, then the recipient has the same GroupState as the sender.

This provides a degree of protection against malicious insiders that send different TreeKEM values to different parts of the tree.  Namely, only the subset of the tree that got the key matching the key confirmation will accept the Handshake message; the others will be locked out. (Assuming a broadcast channel; if the sender can send different key confirmations to different recipients, then this is no help.). This isn't complete protection, but at least the locked-out members know they've been locked out, and can complain about it.

=====

The major question here is whether it's sufficient to derive a key confirmation value from the key schedule and publish it, or whether the value derived in the key schedule should be used as a MAC key to generate a MAC over the message transcript.   I've posted PRs for both; the latter is what I merged in -02

On the one hand, the MAC-based approach is what is done in TLS.  It feels safer, because we never publish anything that's in the key schedule diagram.

On the other hand, the Derive-Secret operation used to create the key confirmation value in the key schedule is **already** based on HMAC.  So it doesn't seem like the extra MAC step is adding that much value.

If we can convince ourselves that the Derive approach (without the extra MAC) is sufficient, I would prefer to do that, since it's simpler.  But feedback on this point would be very much appreciated.

The Derive approach is straightforward.  If this leaks in any surprising way, then draft-ietf-tls-exported-authenticator has a problem too, right?

I don't think that necessarily follows.  That draft follows the MAC approach, in that the values it exports from the TLS key schedule are used as inputs to a MAC, and only the MAC output is published.

That said, I agree it's instructive to look at uses of the TLS exporter to identify parallel risks here.  You would want to find some case where an exported value is used as a public value.  Unfortunately, the only other major usage of exporters that comes to mind is DTLS-SRTP, which exports a key and salt.  You could use that to argue either way, since the salt is notionally public, but in practice is never published.

--Richard

_______________________________________________
MLS mailing list

--_----------=_154030757728616420-- From nobody Tue Oct 23 08:14:53 2018 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 D70E6130DD5 for ; Tue, 23 Oct 2018 08:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CbCtxgby3D8 for ; Tue, 23 Oct 2018 08:14:49 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 45E4D130E37 for ; Tue, 23 Oct 2018 08:14:49 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id w81-v6so1398857oiw.9 for ; Tue, 23 Oct 2018 08:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LxYMYf4m2t+ujeENxnGmoPVaixrvHPgAQuMSx7PxGzA=; b=CyyzvRs6VxTxywSxtpvyTrLUfW4H5AodblkElQ1Lp3xKGKTiwd+cX+xJe0SAUfr+jL ctCHuPEqwRfgzpMGmnTHJPXkTTZejTq6abyr8QLcnomQGU2MeYRIoaQw8NJLpDmzXb5U 0mcrl5RvnsBvKzeoXEsgByDOeYV6tv8HsJDB/Q2+dWanMAqMtv5bXL6VFJJy1eSLQIvo dRkoFtqLkQcIypMdMCNZWL3Opf4BYgVR1yKPcDzPvcKNhAFk0Np40fnBNvSBsUZAe+O2 VprWkR+2RqbQpwICK3+/ZPaMFhRkLQ6lyYCAxhxe2iz1M5wqKD5ztTr2tWZtNnWPCpCn VKPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LxYMYf4m2t+ujeENxnGmoPVaixrvHPgAQuMSx7PxGzA=; b=b6mKwGtgWImOZgYTyP7UhQ0fxTAoA7XekzWUuIMt1oTlEPvjSlT7v/UqeK/09AB6kg m9MOEjEWKRgVztzIvZ7YIpW2FXDKqnqXTjrUUqYb+PYcKTeEMxNX29j1YRp7NBj99Df8 RjnTtyoE5Rh1RWRtaQ9CU5zluG4hf3Dyk9SHLnf65oO+6vglopt1TlaolgR/Bj5m2V/o 3xinM7I9fyGVxsG/HJ1reKjVAgoQfrFU9N6j76XzGH4LPyuHTaFkUPklqkgZ39ZmsWmj i9yhH2h42yBlQUD6TEk1Mh0V62LR6n/BERYuAks/EW4GwCZyTyHP3pcEBqfUsMYhgnnN 4fYg== X-Gm-Message-State: ABuFfog4emZs98abIarcjgTmndmo9sI/XcwPpYkTxL6eYkzu8m2hfYwQ 2WmD6mZl5Hx0l/55p8xNj0i8LXHUoO2/0ooQlwL7wXGA X-Google-Smtp-Source: ACcGV62th1bCRNph9de4j6wHgVf5+VzDSnMP2wGMwQ4okGB8aPRA/a0TPsaUCiYUXgFsOE0nMHsT9FZ36Huyf23FjrI= X-Received: by 2002:aca:540c:: with SMTP id i12-v6mr27968656oib.49.1540307688387; Tue, 23 Oct 2018 08:14:48 -0700 (PDT) MIME-Version: 1.0 References: <58A76FA7-6A4B-4E78-8631-A20CD20AE533@vigilsec.com> <1540307577.2861642.1551828416.05A754F2@webmail.messagingengine.com> In-Reply-To: <1540307577.2861642.1551828416.05A754F2@webmail.messagingengine.com> From: Richard Barnes Date: Tue, 23 Oct 2018 08:14:30 -0700 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000009cc1820578e6d4cf" Archived-At: Subject: Re: [MLS] Key confirmation - Extra MAC needed? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 15:14:52 -0000 --0000000000009cc1820578e6d4cf Content-Type: text/plain; charset="UTF-8" Can you say more about how MAC'ing over "" makes things cleaner? On Tue, Oct 23, 2018 at 8:13 AM Katriel Cohn-Gordon wrote: > I wouldn't die on this hill, but I prefer the MAC design just for > cleanness reasons in analysis. Collapsing the final two MAC invocations in > the derivation doesn't seem like it gets you very much. > > Note that we wouldn't have to MAC over the message transcript---over the > constant zero might be enough. > > k > > > On Tue, 23 Oct 2018, at 4:08 PM, Richard Barnes wrote: > > > > On Tue, Oct 23, 2018 at 6:34 AM Russ Housley wrote: > > > Hey all, > > In the just-released -02 draft of MLS, I've added a key confirmation step > to the handshake authentication process. Important question after "=====" > below... > > In the previous draft, there was an authentication mechanism that ensured > that if two group members ended up with different GroupState objects, then > they would have different keys. However, it did not provide any way for > group members to recognize that this was the case, except for AEAD checks > on encrypted messages failing.. With explicit key confirmation, the > recipient of a Handshake message knows that if processing of the handshake > message succeeds, then the recipient has the same GroupState as the sender. > > This provides a degree of protection against malicious insiders that send > different TreeKEM values to different parts of the tree. Namely, only the > subset of the tree that got the key matching the key confirmation will > accept the Handshake message; the others will be locked out. (Assuming a > broadcast channel; if the sender can send different key confirmations to > different recipients, then this is no help.). This isn't complete > protection, but at least the locked-out members know they've been locked > out, and can complain about it. > > ===== > > The major question here is whether it's sufficient to derive a key > confirmation value from the key schedule and publish it, or whether the > value derived in the key schedule should be used as a MAC key to generate a > MAC over the message transcript. I've posted PRs for both; the latter is > what I merged in -02 > > Derive: https://github.com/mlswg/mls-protocol/pull/72 > MAC: https://github.com/mlswg/mls-protocol/pull/71 > > On the one hand, the MAC-based approach is what is done in TLS. It feels > safer, because we never publish anything that's in the key schedule diagram. > > On the other hand, the Derive-Secret operation used to create the key > confirmation value in the key schedule is **already** based on HMAC. So it > doesn't seem like the extra MAC step is adding that much value. > > If we can convince ourselves that the Derive approach (without the extra > MAC) is sufficient, I would prefer to do that, since it's simpler. But > feedback on this point would be very much appreciated. > > > The Derive approach is straightforward. If this leaks in any surprising > way, then draft-ietf-tls-exported-authenticator has a problem too, right? > > > I don't think that necessarily follows. That draft follows the MAC > approach, in that the values it exports from the TLS key schedule are used > as inputs to a MAC, and only the MAC output is published. > > That said, I agree it's instructive to look at uses of the TLS exporter to > identify parallel risks here. You would want to find some case where an > exported value is used as a public value. Unfortunately, the only other > major usage of exporters that comes to mind is DTLS-SRTP, which exports a > key and salt. You could use that to argue either way, since the salt is > notionally public, but in practice is never published. > > --Richard > > *_______________________________________________* > 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 > --0000000000009cc1820578e6d4cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you say more about how MAC'ing over "" m= akes things cleaner?=C2=A0

On Tue, Oct 23, 2018 at 8:13 AM Katriel Cohn-Gordon <me@katriel.co.uk> wrote:
I wouldn't die on this hi= ll, but I prefer the MAC design just for cleanness reasons in analysis. Col= lapsing the final two MAC invocations in the derivation doesn't seem li= ke it gets you very much.

Note that we wouldn't have to = MAC over the message transcript---over the constant zero might be enough.

k


On Tue, 23 Oct 2018, at 4:08 PM, Richard Barnes wrote:


On Tue, Oct 23, 2018 at 6:34 AM Russ Housley <housley@vigilsec.com<= /a>> wrote:

Hey all,

In the just-released -02 draft of MLS, I've added a key confirmati= on step to the handshake authentication process.=C2=A0 Important question a= fter "=3D=3D=3D=3D=3D" below...

In the previous draft, there was an authentication mechanism that ensu= red that if two group members ended up with different GroupState objects, t= hen they would have different keys.=C2=A0 However, it did not provide any w= ay for group members to recognize that this was the case, except for AEAD c= hecks on encrypted messages failing..=C2=A0 With explicit key confirmation,= the recipient of a Handshake message knows that if processing of the hands= hake message succeeds, then the recipient has the same GroupState as the se= nder.

This provides a degree of protection against malicious insiders that s= end different TreeKEM values to different parts of the tree.=C2=A0 Namely, = only the subset of the tree that got the key matching the key confirmation = will accept the Handshake message; the others will be locked out. (Assuming= a broadcast channel; if the sender can send different key confirmations to= different recipients, then this is no help.). This isn't complete prot= ection, but at least the locked-out members know they've been locked ou= t, and can complain about it.

=3D=3D=3D=3D=3D

The major question here is whether it's sufficient to derive a key= confirmation value from the key schedule and publish it, or whether the va= lue derived in the key schedule should be used as a MAC key to generate a M= AC over the message transcript.=C2=A0=C2=A0 I've posted PRs for both; t= he latter is what I merged in -02

On the one hand, the MAC-based approach is what is done in TLS.=C2=A0 = It feels safer, because we never publish anything that's in the key sch= edule diagram.

On the other hand, the Derive-Secret operation used to create the key = confirmation value in the key schedule is **already** based on HMAC.=C2=A0 = So it doesn't seem like the extra MAC step is adding that much value.

If we can convince ourselves that the Derive approach (without the ext= ra MAC) is sufficient, I would prefer to do that, since it's simpler.= =C2=A0 But feedback on this point would be very much appreciated.

The Derive approach is straightforward.=C2=A0 If this leaks in any sur= prising way, then=C2=A0draft-ietf-tls-exported-authenti= cator has a problem too, right?

I don't think that necessarily follows.=C2=A0 That draft follows t= he MAC approach, in that the values it exports from the TLS key schedule ar= e used as inputs to a MAC, and only the MAC output is published.

That said, I agree it's instructive to look at uses of the TLS exp= orter to identify parallel risks here.=C2=A0 You would want to find some ca= se where an exported value is used as a public value.=C2=A0 Unfortunately, = the only other major usage of exporters that comes to mind is DTLS-SRTP, wh= ich exports a key and salt.=C2=A0 You could use that to argue either way, s= ince the salt is notionally public, but in practice is never published.
=

--Richard

_______________________________________________
MLS mailing list

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000009cc1820578e6d4cf-- From nobody Tue Oct 23 08:22:31 2018 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 54E61130934 for ; Tue, 23 Oct 2018 08:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=Gs6xZBdJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dnzcpqoZ 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 zP4QOQBhQzRf for ; Tue, 23 Oct 2018 08:22:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B830412F18C for ; Tue, 23 Oct 2018 08:22:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F179921E81; Tue, 23 Oct 2018 11:22:26 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 23 Oct 2018 11:22:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= PXFtA/AHl6gzTmdxG6IrT26y4JHTpGU48zo5oh87n+o=; b=Gs6xZBdJxqqLPMsf GOXirFjMgdIOloga24rdtsvrVcg4jc7zJH4QcVEtsTytD5apxGLByKOUpz87eRGJ FXIHlzC0LTtR//3lcTJcKMToYYLQoPDkhJz/403F5NoxEzbOPvYGWK5F02nVpGp3 qd4dUCOWLutVijoiXZ6vHPpZ9aA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=PXFtA/AHl6gzTmdxG6IrT26y4JHTpGU48zo5oh87n +o=; b=dnzcpqoZBdQo5XQ/RspBkOYlitTiAU1WoZzVSHNPtJSGD6f073z7t7inX CqEibGKiBNWVhySagcBL/oeA14olCTqMKx2ExYUvIZrDQE3OoJi2VvVcktSLP+iq WjNIi8X1zvR5bBI6GPQ/u7Akj9DNo4OIYwpObcc+YnLlosVyWxjTY8rmY4aUseU8 /it4vL4QGBxGEfeA+EoQ5wTnPrzM5KQCunMC7i6Cd0MLydE8YmM7/SlQf+1pTaQY eAdySEeZwUHE7N30olhgG/uRs5sD9NHfIB/ceDuWaMMDLegLmQeBlRAE5CxJzVW5 LMKZnliy+ksX2KacCReyFWCfpqT1Q== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2F9A69E17B; Tue, 23 Oct 2018 11:22:26 -0400 (EDT) Message-Id: <1540308146.2864513.1551842104.702A4736@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: Richard Barnes Cc: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154030814628645130" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b315a288 In-Reply-To: References: <58A76FA7-6A4B-4E78-8631-A20CD20AE533@vigilsec.com> <1540307577.2861642.1551828416.05A754F2@webmail.messagingengine.com> Date: Tue, 23 Oct 2018 16:22:26 +0100 Archived-At: Subject: Re: [MLS] Key confirmation - Extra MAC needed? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 15:22:29 -0000 This is a multi-part message in MIME format. --_----------=_154030814628645130 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" "Publish a MAC with a secret key" seems like a safe-ish operation in general. "Publish a secret key from the key schedule" seems like a dangerous operation in general. The fact that the key schedule happens to derive keys in a sensible enough way that publishing one key doesn't affect security of the others is a very good feature, but in my head it seems a bit funny to conclude that it's safe to publish keys. IOW, the cleanness I am thinking of is the separation between how the key schedule works and what the protocol does with the derived keys. k On Tue, 23 Oct 2018, at 4:14 PM, Richard Barnes wrote: > Can you say more about how MAC'ing over "" makes things cleaner? --_----------=_154030814628645130 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
"Publish a MAC with a secret key" seems like a safe-ish operation in general.

"Publish a secret key from the key schedule" seems like a dangerous operation in general.

The fact that the key schedule happens to derive keys in a sensible enough way that publishing one key doesn't affect security of the others is a very good feature, but in my head it seems a bit funny to conclude that it's safe to publish keys. IOW, the cleanness I am thinking of is the separation between how the key schedule works and what the protocol does with the derived keys. 

k

On Tue, 23 Oct 2018, at 4:14 PM, Richard Barnes wrote:
Can you say more about how MAC'ing over "" makes things cleaner? 

--_----------=_154030814628645130-- From nobody Tue Oct 23 10:32:14 2018 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 B23AE124C04 for ; Tue, 23 Oct 2018 10:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 L6ZGPFJIpNoi for ; Tue, 23 Oct 2018 10:32:04 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 AA853130E65 for ; Tue, 23 Oct 2018 10:32:01 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id w19-v6so2439345eds.1 for ; Tue, 23 Oct 2018 10:32:01 -0700 (PDT) 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=9yvgFiABktSSbzVfbcZ+z+hAlwfDBpCZiPBhPzt5fVs=; b=1SPyI8qrmSJVeeAiBzG2PCdYuMJ1TuFKifoglSx6PoEVSnp0OXdQCxllMmOevxVtNm nveqg11HlyJKoAPe0EnQ4F0K8JuW7Wupzkmrv3+05Ylj8R0ZaJd8DGkr8qf9dWy0k7MW poajMnZ4sqjYHBKAzM7HS5UYuhGVt+30LyY8bmJkuMhWwV0jQ+Vcoaf2yvhdcxQGztdm W1m2YVLMzfgBpTbBIqBFrSTx92fl1+TfvGZK36y8KZd/mNFevetIuy+j/MsrWwsUrEof uLd1266R4s9rNflmZ+VhILKIiuFQRuNUvdvKzTngITIzC7ti+yK9rQxhQCb2apJ0KT5E WIeg== 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=9yvgFiABktSSbzVfbcZ+z+hAlwfDBpCZiPBhPzt5fVs=; b=dLVQETQ3u26YeykbfQzN7KNAW3FiAJ0lYJFCrSn00ADnJM3JbMVL7q+2+7o/ZU/riP ktlMjzc4O8wDxW7FsbXFEwhHCyPJSgmYcUJ/S6X3vx+PvbiiJ9YGQFi2YKwA5D6RsThA u42sISWHElPEW4ItG7we5wOtaZq/ApqZ6rVBI1bWTz17zWzCoQQY50bQXFe5swJfxJQ0 MmW2HZJpzaBHuKq9HzReQ1097EUklI1RD49bRM0viK1nSayvkB1rXLrA9d4XWisEhsGD XQQ90Tq9yb/Cqx2Rjl3TZiinFQ6h+g+cL+vL656OPM0ho4V9x6YedP/DYoBVH/chO6E/ uEQg== X-Gm-Message-State: AGRZ1gLSUtD+NezB5SJ0SkQqYieG8CklDFZ5DInz2IQxOm4zlQZhldP9 kjj/qr7i+2glKQFKcj/GZZQx+gQft3A= X-Google-Smtp-Source: AJdET5eLTRVLkj3kiAuZoJwgbwqDVrDvGtn9Vu0EWQ7e7vaeMB2HeNqq2n28PmpRWdPOxFNXktpcSg== X-Received: by 2002:a50:a699:: with SMTP id e25-v6mr3830245edc.225.1540315919107; Tue, 23 Oct 2018 10:31:59 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id a40-v6sm971891edd.61.2018.10.23.10.31.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Oct 2018 10:31:58 -0700 (PDT) From: Raphael Robert Message-Id: <5DD65297-F437-4F22-A3E6-C2955D428B1C@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8798F5BF-5A8D-41C4-9F92-4F1501474114" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 23 Oct 2018 19:31:56 +0200 In-Reply-To: Cc: jtoohill=40google.com@dmarc.ietf.org, Emad Omara , gbelvin@google.com To: mls@ietf.org References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Malicious user segmenting the group X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 17:32:07 -0000 --Apple-Mail=_8798F5BF-5A8D-41C4-9F92-4F1501474114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99d like to second that this is an active issue. I think there = are two kinds of attacks an ill-intentioned member could do (for an = Update HS): a) Send the wrong public keys b) KEM values that not part of a valid hash chain In both cases, not everyone can detect these attacks. Members can only = detect malformed values between the intersection node and the root. The = intersection node is the node where the direct paths of the updating = node and the member=E2=80=99s leaf node intersect. Any malformed value = that are below the intersection cannot be verified. This can lead to different reactions from members: 1. Some will detect that values are malformed, discard the HS message = altogether and keep the current epoch secret 2. Some will not detect the attack and hash up from a faulty value to = derive a new root secret (attack b) 3. Some will not detect the attack and hash up from a correct value, = but will later KEM to a faulty public key (attack a) In all cases this leads to partition with no obvious ways of = reconciliation. For case 1 members will know who the culprit was, which = is marginally better than case 2 and 3, where they don=E2=80=99t know. = For case 1 the attack could be surfaced to the user as some sort of = warning, so that users can manually resolve the situation by ultimately = removing the attacker from the group. Case 2 can be addressed with the key confirmation in [1], because = members will not derive the same root secret and fail on the HMAC = verification. They will thus also know who the culprit is. It would be interesting to see if efficient ZKPs exist, so that clients = can always come to the same conclusion on whether or not a message is = valid. There might also be another use case, where the verification could be = done by the server (assuming unencrypted handshake messages). This would = allow the server to discard faulty messages right away without = forwarding them to clients. It would also potentially address the = bottleneck situation we currently have with Welcome messages. In such a = scenario the server could cache the public keys of the tree nodes and = make them available to newcomers. This is obviously a complex subject = with some intricacies that should be discussed separately, but since = this is yet another reason to have ZKPs to verify handshake messages, I = wanted to mention it here. Finally, I wanted to mention that concept of ACK/ NACK messages adds a = notion of interaction and inter-client consensus that hasn=E2=80=99t = existed so far. Since there is no guarantee that clients who are = theoretically able to detect a faulty message will ever come online to = warn others, the group state could advance for quite some time and lead = to partition. [1] https://github.com/mlswg/mls-protocol/pull/72 > On 22 Oct 2018, at 20:10, Richard Barnes wrote: >=20 > Hi Jon, >=20 > This is definitely an active issue. See my message earlier today = about authentication / key confirmation. >=20 > There have been some discussions of ZKPs for this, but AFAIK, no = workable proposal has emerged. The problem is that what you want to = prove is that a sequence of keys are the result of transforming a chain = of hashes from hash outputs to key pairs -- if you want to do a ZKP with = a general hash function, the ZKP is very expensive, and if you adapt the = hash function to have nicer proof properties, you lose some of the = cryptographic properties you would want. >=20 > My current thinking is that we should probably try to address this at = the protocol level. In some of the pre-BoF discussions, we had talked = about doing some specification of ACK / NACK messages. Now that at = least some endpoints can recognize a bad message, it seems like we could = define a NACK that says "that handshake message was invalid" and = basically let endpoints veto invalid messages. >=20 > If someone wants to come up with a concrete proposal, I would love to = discuss further. >=20 > --Richard >=20 > On Mon, Oct 22, 2018 at 1:37 PM Jon Toohill = > wrote: > Hey MLS folks, >=20 > I'm still skimming through the mailing list archives to get up to = speed, so apologies if this has already been discussed & solved. I saw = the following note in a recent version of the protocol draft: >=20 > [[ OPEN ISSUE: It is not possible for the recipient of a handshake = message to verify that ratchet tree information in the message is = accurate, because each node can only compute the secret and private key = for nodes in its direct path. This creates the possibility that a = malicious participant could cause a denial of service by sending a = handshake message with invalid values for public keys in the ratchet = tree. ]] >=20 > It seems like this could be solved by having the handshake message = sender prove in zero knowledge (i.e. without revealing their secret or = the parent secret) that they derived the parent public key correctly. = ZK-SNARKs are one way of doing that, but my admittedly weak = understanding is that generating proofs might be too computationally = expensive for mobile devices. Does this seem like a worthwhile direction = to investigate? Does anyone know of a more efficient construction that = could be used in MLS? >=20 > -Jon Toohill > _______________________________________________ > 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=_8798F5BF-5A8D-41C4-9F92-4F1501474114 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99d like to second that this is an active issue. I think there are two = kinds of attacks an ill-intentioned member could do (for an Update = HS):

 a) Send = the wrong public keys
 b) KEM values that not = part of a valid hash chain

In both cases, not everyone can detect these attacks. Members = can only detect malformed values between the intersection node and the = root. The intersection node is the node where the direct paths of the = updating node and the member=E2=80=99s leaf node intersect. Any = malformed value that are below the intersection cannot be = verified.

This = can lead to different reactions from members:

 1. Some will detect that values = are malformed, discard the HS message altogether and keep the current = epoch secret
 2. Some will not detect the = attack and hash up from a faulty value to derive a new root secret = (attack b)
 3. Some will not detect the attack = and hash up from a correct value, but will later KEM to a faulty public = key (attack a)

In all cases this leads to partition with no obvious ways of = reconciliation. For case 1 members will know who the culprit was, which = is marginally better than case 2 and 3, where they don=E2=80=99t know. = For case 1 the attack could be surfaced to the user as some sort of = warning, so that users can manually resolve the situation by ultimately = removing the attacker from the group.
Case 2 can be = addressed with the key confirmation in [1], because members will not = derive the same root secret and fail on the HMAC verification. They will = thus also know who the culprit is.

It would be interesting to see if = efficient ZKPs exist, so that clients can always come to the same = conclusion on whether or not a message is valid.
There might also be another use case, where the verification = could be done by the server (assuming unencrypted handshake messages). = This would allow the server to discard faulty messages right away = without forwarding them to clients. It would also potentially address = the bottleneck situation we currently have with Welcome messages. In = such a scenario the server could cache the public keys of the tree nodes = and make them available to newcomers. This is obviously a complex = subject with some intricacies that should be discussed separately, but = since this is yet another reason to have ZKPs to verify handshake = messages, I wanted to mention it here.

Finally, I wanted to mention that = concept of ACK/ NACK messages adds a notion of interaction and = inter-client consensus that hasn=E2=80=99t existed so far. Since there = is no guarantee that clients who are theoretically able to detect a = faulty message will ever come online to warn others, the group state = could advance for quite some time and lead to partition.


[1] https://github.com/mlswg/mls-protocol/pull/72

On 22 Oct 2018, at 20:10, Richard Barnes <rlb@ipv.sx> wrote:

Hi Jon,
This is definitely an active = issue.  See my message earlier today about authentication / key = confirmation.

There have been some discussions of = ZKPs for this, but AFAIK, no workable proposal has emerged.  The = problem is that what you want to prove is that a sequence of keys are = the result of transforming a chain of hashes from hash outputs to key = pairs -- if you want to do a ZKP with a general hash function, the ZKP = is very expensive, and if you adapt the hash function to have nicer = proof properties, you lose some of the cryptographic properties you = would want.

My = current thinking is that we should probably try to address this at the = protocol level.  In some of the pre-BoF discussions, we had talked = about doing some specification of ACK / NACK messages.  Now that at = least some endpoints can recognize a bad message, it seems like we could = define a NACK that says "that handshake message was invalid" and = basically let endpoints veto invalid messages.

If someone wants to come up with a = concrete proposal, I would love to discuss further.

--Richard

On Mon, Oct 22, 2018 = at 1:37 PM Jon Toohill <jtoohill=3D40google.com@dmarc.ietf.org> wrote:
Hey MLS folks,

I'm still skimming through the mailing = list archives to get up to speed, so apologies if this has already been = discussed & solved. I saw the following note in a recent version of = the protocol draft:

[[ OPEN ISSUE: It is not = possible for the recipient of a handshake message to verify that ratchet = tree information in the message is accurate, because each node can only = compute the secret and private key for nodes in its direct path. This = creates the possibility that a malicious participant could cause a = denial of service by sending a handshake message with invalid values for = public keys in the ratchet tree. ]]

It seems like this could = be solved by having the handshake message sender prove in zero knowledge = (i.e. without revealing their secret or the parent secret) that they = derived the parent public key correctly. ZK-SNARKs are one way of doing = that, but my admittedly weak understanding is that generating proofs = might be too computationally expensive for mobile devices. Does this = seem like a worthwhile direction to investigate? Does anyone know of a = more efficient construction that could be used in MLS?

-Jon = Toohill
_______________________________________________
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=_8798F5BF-5A8D-41C4-9F92-4F1501474114-- From nobody Wed Oct 24 04:55:54 2018 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 EC40612F1AB for ; Wed, 24 Oct 2018 04:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78uIFIlEsOeG for ; Wed, 24 Oct 2018 04:55:49 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 22B89128A5C for ; Wed, 24 Oct 2018 04:55:48 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id l191-v6so5794772ita.4 for ; Wed, 24 Oct 2018 04:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=vwxFfeuVBq5CZveE0Mhrh6M/2m+M/GsKHUG3uBaNtHw=; b=d4jIRSk1PrcxF8JV5IjEVQtubJnQd/9VfcK/P/RSnSuwmPAWx5h9r+fmmg/inr2/l3 3/PxPOeXpUa/+1AOd4093k8S5QJ774ij6KdiuspC5lysep5wsg22AmbIGyaOqaC/+Mhq RDR94nQnY6PcrFTdY0/1Pqd2vfbqCU8Mol3tNt8e/g7+PQoqAg0zomFwvDP8JJ6OoO3N EHFaPGXDPshE7S55iyeECi2u0z4PTlOIFkUR28iGt5O625jsyp9oNhrIH4HCssrgtZqS Kz8rVw+O3xOUO/H2Mps+BnsVxfZ1d+V3/PqVEZhMbDnKtq4lcmABhd46Nh0k4iWZlr1c d1xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vwxFfeuVBq5CZveE0Mhrh6M/2m+M/GsKHUG3uBaNtHw=; b=S9ktqS2e8ifUtxIXsEEEk22JwPxMjlhjealPnhN0iyJlIF3N4H8HfUTN1LEn4ULn7c YkwsbjsVa3sOsZyvPq0OMUkTh1+qh48Kk9xICt7rDjPDw2l508flk9F/DqoYq/7Zlw3H 9bFejK8OMU+11NuYb0RR2rkRp+BsfLXMT2X8av+Ce3YKgH2Uwa/1WRqgqYk1gZfNmiMw rJmxxTh6m+afRvfG2EKsGdoKklGkvrZ2ZRlPP0CFojfOW0fGRnjrtKyZ3lZkG2hxsyAb eKij3DiauTjIRFziYITnzsQRHovKqxaRVYOjwXvvSSqBANF/UoIAbgg4NzuVhSrR16fh ZdvA== X-Gm-Message-State: AGRZ1gKmG6yaCLQ5aKdMQqHntlM2C4jSu/Hu490kH7WbL0W6iY2Ns6zJ ddpP2UNYl+mHiqi8MPVqOUrW10mM+qIImA== X-Google-Smtp-Source: AJdET5fEkxoKR6UVEd0QeERlAy9LcWai4CgSWJSHwlq6/t16V0s0tbN23mdP43cQYgfEyqWTP3lpvA== X-Received: by 2002:a24:4c52:: with SMTP id a79-v6mr546631itb.16.1540382147700; Wed, 24 Oct 2018 04:55:47 -0700 (PDT) Received: from [192.168.0.11] (zaq7ac575c8.zaq.ne.jp. [122.197.117.200]) by smtp.gmail.com with ESMTPSA id t190-v6sm2694480ita.39.2018.10.24.04.55.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 04:55:46 -0700 (PDT) To: mls@ietf.org References: <154022472684.6470.15844142818621686395@ietfa.amsl.com> From: Joel Alwen Message-ID: <87d55da3-2522-539d-b243-f10520829759@wickr.com> Date: Wed, 24 Oct 2018 20:55:44 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <154022472684.6470.15844142818621686395@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [MLS] I-D Action: draft-ietf-mls-architecture-01.txt 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, 24 Oct 2018 11:55:53 -0000 Hi everyone, I've read over the architecture draft and put together some thoughts that came to mind. Some are just small typos while others are a bit more substantial. Feel free to incorporate, ignore or talk to me about whatever! - Joël ------------------------- Comments on MLS Architecture -------------------- - Abstract : "It is meant to protect against eavesdropping, tampering, and message forgery." This omits PCS and FS which, IMO, is quite central to what we are doing. Thus, already in the abstract, I'd add something referring/hinting to FS and PCS (e.g. protecting against "past or future device compromises" or something else along those lines). The same goes for the Introduction as it currently also only talks about E2E security. After all, for the security notions outlined in the abstract and intro (i.e. basic E2E authentication and privacy) we could use MUCH simpler protocols (e.g. a static group key decided upon during group setup. Even just FS would be much easier E.g. a hash ratchet would do the trick.). This, is why I believe much (most?) of what we are doing (on the protocol level at least) is about getting PCS and FS on top of the usual E2E security. Despite this, as far as I can tell the first mention of FS and PCS are only in 2.3.5 under the heading "Membership and offline members". - It is not really clear to me why we require the Authentication Service (AS) to issue credentials binding identities to keys. I believe this should be optional. In particular, if users are able to ensure this binding on their own (e.g. using an external authenticated channel to, say, comparing key fingerprints or scan each others 2D barcodes) then it does not seem necessary to have the AS provide these credentials. My concern is that by not making this optional we are more restrictive than really need be. Ultimately what the MS should do is provide *some* mechanism for verifying the binding of identities to keys. Whether its via certificates from an AS attesting to the binding or some other mechanism performed by end users them selves seems less important to the rest of the MLS protocol. - I'm not a fan of having the DS do key storage for initial key material but have the AS store member (public) key material. (I also think the AS should store client public keys along with member identity (public) keys.) In general, to me a natural logical separation is that the AS is in charge of public key storage and dissemination while the DS handles of storage (buffering) and dissemination of traffic. Additionally, some issues with the current division of labor between the AS and DS that could then be avoided are:     - Its not clear why ordering for the storage of initial key material should matter.         - 3.1.5 "The DS must only persist data required for the delivery of messages and avoid Personally Identifiable Information (PII) or other sensitive metadata wherever possible." This sentence doesn't seem very compatible to me with the DS also persistently maintaining initial keys; especially together with credentials ultimately binding them to a member (or at least client's) identity. - At the meeting in Paris we very brief discussed that it could eventually make sense to have "the server" maintain some of the group state on behalf of clients (but, of course, without introducing any trust in the server beyond the current "universal ordering" and "no-DOS" assumptions). With that in mind it may eventually make sense to mention this role as part of the DS's tasks. Alternatively, this could be considered part of the AS's role or even a third service exclusive to this purpose. - 2.3.1 I'd specify that the initial *public* key material is stored with the DS. - 2.3.1 I don't see why the AS should be involved in binding the Client keys to the Member keys. It should suffice for the Client public key to be signed by owning member's keys. As far as I can tell this doesn't involve the AS. - I think a brief, 1 or 2 sentences clarifying key material names would be helpful. Something like: a member has one pair of long term "identity keys", a client has one pair of medium term "client keys" and many short term "initial keys". For example, this could come right after the concepts of Member's vs. Clients is introduced. - 3.1.4 "affect the group state". IMO the transcript (i.e. chat history) is part of group state. So appending a message to the transcript is a group state change. I guess what is meant here is the group's metadata? Given that this metadata is also referred to in other places (e.g. 3.1.5) would it make sense to include a sentence or two somewhere making a bit clearer the terms "group state",  "group metadata" and "group's private content" (as used in 3.2.2 for e.g.). In any case the difference between "state" in 3.1.4 vs. "metadata" in 3.1.5 isn't too clear to me. - 3.1.5.  "A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with the initial public keys signed by the AS." This seems like a very strong property to shoot for. (Also, given the discussion in Paris, deniability didn't seem to be a serious goal of MLS.) At the very least it would require the protocol packets not to be linkable to long term identities (OK but we must be careful with signatures) but also that the DS authenticate clients via (pseudonymous) identities. After all, if the DS does not identify clients at all, say, when they request packets buffered in some queue) then, at the very least, traffic analysis becomes too easy to perform (or alternatively DOS attacks become too easy if the queue is emptied). So just to be sure, is deniability with respect to compromised AS and DS really what we mean here? - 3.1.7 typo: the word "messages" is repeated. - 3.2.2 Message Integrity and Authentication: "and that one Client must not be able to send a message which other Clients accept as being from another Client." This seems weaker than what we want and get (from both the ART and TreeKEM drafts). Instead, we want that "no coalition of Clients can send a message which other Clients accept as being from a Client not already part of that coalition." A similar change should be made to the first sentence in 3.2.2.5 and 4.4. - 3.2.2.1 "MLS provides additional protection regarding secrecy of past messages and future messages." I suggest changing this to "...regarding secrecy and authenticity of past..." Especially in the PCS case authenticity is just as much a goal as privacy. But also for past (undelivered) messages when compromising a sender we still expect (and get) authenticity. In particular the sending keys are already deleted so the attacker is expected to not be able to create an alternative ciphertext for that AEAD encryption key. In more detail, authenticity should also be mentioned (next to privacy) in the more detailed paragraphs on FS and PCS in that subsection. - 3.2.2.1 The PCS version described here is too strong. MLS really only guarantees PCS if between time t and t' the attacker did not forge a message on behalf of the compromised client. (Not only can a forged message not be prevented by MLS, it also causes the compromised client's state to come out of sync with the rest of the group.) So instead, one solution is to say something like "MLS provides PCS security when the attacker remains passive between times t and t'". Although this is a somewhat stronger restriction on the adversary than we really need to get PCS it is a clear, succinct yet still reasonable notion we do satisfy.) - 3.2.2.1 "Regardless, MLS does not allow addition or removal of group members without informing all other members." Out of curiosity is this really true for ART and TreeKEM? Suppose A, B and C are in a group. A is corrupt so she sends a add-member message to B informing B that D has joined the group. We specified that the DS shouldn't "know" about group membership so it should permit forwarding this only to B. A priori, now B thinks D is in the group but C doesn't right? In fact, if B sends message to the group (not maybe an update though) its not clear to me that C will realize B thinks D is in the group... Worse, D will actually be able to decrypt the message. In fact, if D gets their hands on a messages sent by C they could also decrypt them (at least before an update occurs) since they are protected only by the group key which D knows. Any way, it might just be me, but I'm not too clear if, or at least, to which extent or in which sense we really get this property. - 3.2.2.3 "hence slightly weakening the PCS guarantees for attachments." I'd probably phrase this as "hence potentially extending the time before PCS guarantees take effect." rather than use the term "weaken" as its the same security notion. (I believe that in crypto papers the terms "stronger" and "weaker" are normally used to describe security games that strictly imply (or are implie by) each other. But, the parameters t and t' in PCS are not part of the definition of security game. Rather, they are a function of the adversary and all inputs and random coins used in the security game.) - 3.2.2.5 My take on the discussion about deniability in Paris was that there was a general consensus that deniability is not an interesting goal for MLS because what we could achieve is too weak to be interesting while notions strong enough to be worth it in practice are out of our reach... but to be sure I'd recommend at least checking the notes from the meeting to confirm. - 4 First paragraph. Typo: "in" repeated twice. - 4.1. Realistically we might want to also add leaking meta-data. E.g. who talks when to whom and how much they say as well as when updates are performed vs messages exchanged. - 4.4 "It will also be able to send messages impersonating the compromised Client until the Client updates its keying material (see Section 3.2.2.1)." I think, at least if an update has been forged on behalf of a compromised Client then even if the Client updates its key material it still wont be able to send messages. In fact, in this cast AFAIK A) forging can continue and B) the Client can no longer rejoin the group; at least not without wiping its state completely and re-joining from scratch. If this is true then we might consider adding a caveat to the quoted sentence reflecting that updates only recover sending capabilities if no update was forged in the meantime. On 10/23/2018 01:12 AM, internet-drafts@ietf.org wrote: > 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) Architecture > Authors : Emad Omara > Benjamin Beurdouche > Eric Rescorla > Srinivas Inguva > Albert Kwon > Alan Duric > Filename : draft-ietf-mls-architecture-01.txt > Pages : 16 > Date : 2018-10-22 > > Abstract: > This document describes the architecture and requirements for the > Messaging Layer Security (MLS) protocol. MLS provides a security > layer for group messaging applications with from two to a large > number of clients. It is meant to protect against eavesdropping, > tampering, and message forgery. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mls-architecture-01 > https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-architecture-01 > > > 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/ > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Oct 31 08:45:17 2018 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 70B0C130E2A for ; Wed, 31 Oct 2018 08:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wn5n6nHEaqBO for ; Wed, 31 Oct 2018 08:45:12 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 B384C130DDF for ; Wed, 31 Oct 2018 08:45:11 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id e5-v6so14027004eds.6 for ; Wed, 31 Oct 2018 08:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=lTXHZcEuPqv/g8Pg6OdHhfOU9pZr8IE622yeO4c7dKU=; b=S9BT8uWQcIBaQy5MWrHTktc+jAHidDkb4UGUtgfOlN6+Sabn3fEieDtuIsEJDKyGFf r5Y5b2hN/xaLNbYbVvPh9haqIv60llaBd+Xf0mXZEyBr6lxlm4Mgw9hnoDY1Ii8BdGag YMF9pkHMV5t8DKhecFEuBSB8kKVR/K5xvnJ4wgOWA5WhWQwLfyi+br/GPFtIAgpBcPgG EIIHsWadnTbHsSza3R15mlWzFvW4N44Pii9BQ7VJVpTozur1rNlZsarBqL8DJ3bhfGMM oqZNqOdJPuKlmq9N5FmjWe+0U42Vmn/OU2aEcqfYwMJGtKtiM/AdVq0Zi1MwyctiHgLv +G9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=lTXHZcEuPqv/g8Pg6OdHhfOU9pZr8IE622yeO4c7dKU=; b=X5ZnxtTUH5l1W1TBWfpbMKS2BPFoCVVzLsJJ9EK8bBah86vbpjDcoYkTS+kQp8Sh0g c7kHnMHE6lBZpjN/Aw/YKzICmvBaPRG3V2iEyOG9R8uNSWwIyd/n1O8fpPfyg2zBG1TY FpmwLrR3KuesdGXGH2KMUWISZXBU/liknYMsUl6JYZyz2EmbDyGieKtcn5kO/7c1b2/e dMDIfzJ0DL987REkMK5DNMMm4NltEPoC07nL9Hvxk2NMUSosZO22h9Jj+MBD/nAK8TyT btRhkURZTaVSbjEGW9zZSE/ZzNww2mwtL9BO/Sl2YNIRHbz1Jb50VZjX5TCnu7gmXk1E mcZg== X-Gm-Message-State: AGRZ1gJAt5+BSCmcQz/HYmJQAa3b+mENqojsZC9VjHW6a18sGk/mV2qV Kf0hB5nWy3W+C41F6xBRc9pvt0HGCoE= X-Google-Smtp-Source: AJdET5d59n4Yyzs09i3UOAJ7zYa5EJPv2ZKz/bLq+a9W2RFNYN3rTmljvavwwKsO4rzlWiIm10/09g== X-Received: by 2002:a17:906:4e14:: with SMTP id z20-v6mr1850641eju.187.1541000709358; Wed, 31 Oct 2018 08:45:09 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id z13-v6sm2190366edm.67.2018.10.31.08.45.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 08:45:08 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_218D8AC2-2FE5-473D-B6AB-EDB056BFB59D" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Wed, 31 Oct 2018 16:45:06 +0100 References: To: mls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Cost of the partial-tree approach 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, 31 Oct 2018 15:45:15 -0000 --Apple-Mail=_218D8AC2-2FE5-473D-B6AB-EDB056BFB59D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Having to choose between security and efficiency is always a terrible = choice to make. I'd like to explore an idea where the only choice is = about how the workload is distributed. I made some simulations to see how quickly the workload converges from = linear to ~log N for the partial-tree approach (see graph in [1]). The = setup was as follows: the tree creator added 1k members to a tree at = once. The members iteratively did updates in a random order. I measured = the copath length after each update (min, max and average). The length = of the copath is equivalent to the number of DH / KEM operations the = sender has to do, and thus the size of the message. Note that in a = punctured tree the copath is not the list of siblings of the direct path = anymore, rather every node of the copath needs to be "resolved" if it is = a blank node. In a tree with many blank nodes the new copath can = therefore be quite long. The graph clearly shows the efficiency is very bad for the initial set = of updates, but also quickly converges after only a fraction of the = updates have been done. My conclusion from this is that a full tree is not necessary to address = the efficiency issue. Instead of pre-populating the whole tree with node secrets, it might be = enough to only pre-populate a fraction of the nodes. With the blanking = mechanism, nodes can be arbitrarily blanked/populated. The only rule is = that leaf nodes need to know the node secrets of their (non-blanked) = parent nodes. This means that we can pre-populate whatever nodes are most suitable to = improve efficiency. This happens to be the case with the top of the tree = (the top being the part close to the root of the tree). The closer a = node is to the root, the more likely it is to be part of an arbitrary = copath. Conveniently, the same node is equally likely to be overwritten = during an update, henceforth removing the double-join state for that = node. Even more conveniently, the top of the tree contains far fewer = nodes than the rest of the tree, making the pre-population quite cheap. An example in numbers: A tree is vertically divided in "levels". A tree with 1k leaves has = log2(1k) ~ 10 levels. Let's say we pre-populate the upper 5 levels of = the tree (the "top"). The top contains about ~3% of the total number of = nodes in the tree. After only 1.5% of the members have updated (assuming = an even distribution of members who update) the top of the tree does not = contain double-joins anymore. The copath length for early updates is = drastically reduced as can be seen in [2]. The comparison with the empty = tree can be seen in [3]. However while this effectively increases efficiency, the double-join = issue remains during the early epochs of a tree. Now since the number = nodes that were pre-populated is relatively low, it might just be = practical to use a bookkeeping mechanism to track those nodes. If a node secret is known to a member that is not a descendent of that = node, this is considered to be a double-join. For every such node, we = can simply keep a list of illicit owners. Whenever a member is evicted from the group, additional blanking has to = be done: So far only the nodes in the direct path of evicted member had = to be blanked, now we also blank the nodes the evicted member = double-joined. It is important that all of blanking happens before new = values are KEMed to the resolved copath of the evicted member. This = guarantees that the evicted member doesn't have any access to any node = secrets anymore. The entries of the bookkeeping (the "book") have to be shared with newly = invited members. It is important that every member has the same view of = the book to guarantee that eviction can always be fully achieved. = Passing the book to a new member therefore has to be tamper-proof, = because especially inviting members might have an incentive to lie about = the nodes they double-joined. The book could simply be added to the = group state, so that its content is "pinned" when deriving epoch = secrets. This would guarantee that a new member either sees the same = book as the rest of the group, or they cannot derive the same epoch = secrets. The same mechanism of pre-populating nodes in the tree ("warming up" the = tree) could be used more generally when adding new members to the group. = Instead of just adding the UserInitKey of the new member, the inviting = member could warm up the direct path of the new member (except the leaf = node of the new member). This would avoid inserting new blank nodes in = the tree when adding a new member. Conversely, this could potentially also be done when evicting a member. = Instead of blanking the direct path of the member, the evicting member = could simply overwrite all or a part of the blanked nodes, avoiding a = punctured tree at the expense of increasing the bookkeeping effort. Note = that if a blank node is overwritten, the children of that node need to = know its secret. The secret needs to KEMed to all children. This happens = implicitly when overwriting a direct path, but needs to be done manually = when overwriting arbitrary blank nodes, which could occur as a result of = the bookkeeping. This could lead to a high number of KEM operations, and = blanking double-joined nodes (that are outside of the direct path of the = evicted member) might just be cheaper. As mentioned above, the blanking = has to be done before new values are KEMed to nodes in the tree. It remains to be seen in which situations this makes sense in terms of = efficiency and what the best balance is between additional bookkeeping = and puncturing the tree. Aside from some ground rules, further = simulations could give an indication. Assuming the bookkeeping mechanism works as intended and no other = problems arise, the choice comes down to how much warming up is desired. = Ultimately, this choice could be left to the members themselves, = assuming they all have the tree efficiency as a common interest. This = would allow for dynamic decision taking based on the tree structure. Raphael [1] https://imgur.com/a/wZtueOX [2] https://imgur.com/a/My8anBs [3] https://imgur.com/a/ZvmdfeH > On 1 Oct 2018, at 18:17, Richard Barnes wrote: >=20 > Hey all, >=20 > There was some debate at the interim about the performance = implications of the "partial-tree" approach to adds and removes [0] = (derived from the "remove-without-double-join" approach described on the = mailing list [1]). In particular, EKR expressed concern that this = approach would cause message size to degrade from log to linear. To = test this out, on the plane home I wrote a simulator that performs = random group operations and compares two approaches: >=20 > 1. The "full-tree" approach, which has optimal efficiency but also has = double-joins > 2. The "partial-tree" approach, which has no double-joins but = sub-optimal efficiency >=20 > I've made a little visualizer here: >=20 > https://ipv.sx/treekem/blanking/ >=20 > The tl;dr is that the partial-tree approach is only very bad if you = have a very sparse tree, in particular, if you follow the "Init w/o 2J" = approach of [0]. In all other cases, as long as updates happen = sufficiently frequently, the two approaches are within a small constant = factor of one another. The intuition here is that adds / removes = degrade the tree (since they add blank nodes) while updates heal the = tree (since they fill in blank nodes). =20 >=20 > If you have the simulator start out with a sparse tree (untick "Start = full"), you'll see that initially, the "partial-tree" approach is very = bad, pretty much linear, but it gets better as nodes update, and = eventually merges with the "full-tree" line. If you start with a full = tree, the lines don't diverge. >=20 > Obviously, this isn't dispositive in one direction or another. But = ISTM that this experiment indicates that the cost of the "partial-tree" = approach might not be too bad, given that it clears up a significant = ambiguity / saves the cost of double-join bookkeeping. >=20 > --Richard >=20 > [0] = https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/no_more_= double_joins.pdf = > [1] = https://mailarchive.ietf.org/arch/msg/mls/Zzw2tqZC1FCbVZA9LKERsMIQXik = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_218D8AC2-2FE5-473D-B6AB-EDB056BFB59D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Having to choose between security and efficiency is always a = terrible choice to make. I'd like to explore an idea where the only = choice is about how the workload is distributed.

I made some simulations to see how = quickly the workload converges from linear to ~log N for the = partial-tree approach (see graph in [1]). The setup was as follows: the = tree creator added 1k members to a tree at once. The members iteratively = did updates in a random order. I measured the copath length after each = update (min, max and average). The length of the copath is equivalent to = the number of DH / KEM operations the sender has to do, and thus the = size of the message. Note that in a punctured tree the copath is not the = list of siblings of the direct path anymore, rather every node of the = copath needs to be "resolved" if it is a blank node. In a tree with many = blank nodes the new copath can therefore be quite long.

The graph clearly shows = the efficiency is very bad for the initial set of updates, but also = quickly converges after only a fraction of the updates have been = done.
My conclusion from this is that a full tree = is not necessary to address the efficiency issue.
Instead of pre-populating the whole = tree with node secrets, it might be enough to only pre-populate a = fraction of the nodes. With the blanking mechanism, nodes can be = arbitrarily blanked/populated. The only rule is that leaf nodes need to = know the node secrets of their (non-blanked) parent nodes.
This means that we can pre-populate whatever nodes are most = suitable to improve efficiency. This happens to be the case with the top = of the tree (the top being the part close to the root of the tree). The = closer a node is to the root, the more likely it is to be part of an = arbitrary copath. Conveniently, the same node is equally likely to be = overwritten during an update, henceforth removing the double-join state = for that node. Even more conveniently, the top of the tree contains far = fewer nodes than the rest of the tree, making the pre-population quite = cheap.

An = example in numbers:
A tree is vertically divided in = "levels". A tree with 1k leaves has log2(1k) ~ 10 levels. Let's say we = pre-populate the upper 5 levels of the tree (the "top"). The top = contains about ~3% of the total number of nodes in the tree. After only = 1.5% of the members have updated (assuming an even distribution of = members who update) the top of the tree does not contain double-joins = anymore. The copath length for early updates is drastically reduced as = can be seen in [2]. The comparison with the empty tree can be seen in = [3].

However = while this effectively increases efficiency, the double-join issue = remains during the early epochs of a tree. Now since the number nodes = that were pre-populated is relatively low, it might just be practical to = use a bookkeeping mechanism to track those nodes.
If = a node secret is known to a member that is not a descendent of that = node, this is considered to be a double-join. For every such node, we = can simply keep a list of illicit owners.
Whenever = a member is evicted from the group, additional blanking has to be done: = So far only the nodes in the direct path of evicted member had to be = blanked, now we also blank the nodes the evicted member double-joined. = It is important that all of blanking happens before new values are KEMed = to the resolved copath of the evicted member. This guarantees that the = evicted member doesn't have any access to any node secrets = anymore.

The = entries of the bookkeeping (the "book") have to be shared with newly = invited members. It is important that every member has the same view of = the book to guarantee that eviction can always be fully achieved. = Passing the book to a new member therefore has to be tamper-proof, = because especially inviting members might have an incentive to lie about = the nodes they double-joined. The book could simply be added to the = group state, so that its content is "pinned" when deriving epoch = secrets. This would guarantee that a new member either sees the same = book as the rest of the group, or they cannot derive the same epoch = secrets.

The = same mechanism of pre-populating nodes in the tree ("warming up" the = tree) could be used more generally when adding new members to the group. = Instead of just adding the UserInitKey of the new member, the inviting = member could warm up the direct path of the new member (except the leaf = node of the new member). This would avoid inserting new blank nodes in = the tree when adding a new member.
Conversely, this = could potentially also be done when evicting a member. Instead of = blanking the direct path of the member, the evicting member could simply = overwrite all or a part of the blanked nodes, avoiding a punctured tree = at the expense of increasing the bookkeeping effort. Note that if a = blank node is overwritten, the children of that node need to know its = secret. The secret needs to KEMed to all children. This happens = implicitly when overwriting a direct path, but needs to be done manually = when overwriting arbitrary blank nodes, which could occur as a result of = the bookkeeping. This could lead to a high number of KEM operations, and = blanking double-joined nodes (that are outside of the direct path of the = evicted member) might just be cheaper. As mentioned above, the blanking = has to be done before new values are KEMed to nodes in the = tree.
It remains to be seen in which situations = this makes sense in terms of efficiency and what the best balance is = between additional bookkeeping and puncturing the tree. Aside from some = ground rules, further simulations could give an indication.

Assuming the bookkeeping = mechanism works as intended and no other problems arise, the choice = comes down to how much warming up is desired. Ultimately, this choice = could be left to the members themselves, assuming they all have the tree = efficiency as a common interest. This would allow for dynamic decision = taking based on the tree structure.

Raphael

[1] https://imgur.com/a/wZtueOX
[2] https://imgur.com/a/My8anBs
[3] https://imgur.com/a/ZvmdfeH

On 1 Oct = 2018, at 18:17, Richard Barnes <rlb@ipv.sx> wrote:

Hey all,

There was some debate at the interim about the performance = implications of the "partial-tree" approach to adds and removes [0] = (derived from the "remove-without-double-join" approach described on the = mailing list [1]).  In particular, EKR expressed concern that this = approach would cause message size to degrade from log to linear.  = To test this out, on the plane home I wrote a simulator that performs = random group operations and compares two approaches:

1. The "full-tree" approach, which has optimal efficiency but = also has double-joins
2. The "partial-tree" approach, = which has no double-joins but sub-optimal efficiency

I've made a little visualizer here:

https://ipv.sx/treekem/blanking/

The tl;dr is that the partial-tree approach is only very bad = if you have a very sparse tree, in particular, if you follow the "Init = w/o 2J" approach of [0].  In all other cases, as long as updates = happen sufficiently frequently, the two approaches are within a small = constant factor of one another.  The intuition here is that adds / = removes degrade the tree (since they add blank nodes) while updates heal = the tree (since they fill in blank nodes). 

If you have the simulator start out with a sparse tree = (untick "Start full"), you'll see that initially, the "partial-tree" = approach is very bad, pretty much linear, but it gets better as nodes = update, and eventually merges with the "full-tree" line.  If you = start with a full tree, the lines don't diverge.

Obviously, this isn't dispositive in one direction or = another.  But ISTM that this experiment indicates that the cost of = the "partial-tree" approach might not be too bad, given that it clears = up a significant ambiguity / saves the cost of double-join = bookkeeping.

--Richard

[0] https://github.com/mlswg/wg-materials/blob/master/interim-2018-= 09/no_more_double_joins.pdf
[1] https://mailarchive.ietf.org/arch/msg/mls/Zzw2tqZC1FCbVZA9LKERs= MIQXik

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

= --Apple-Mail=_218D8AC2-2FE5-473D-B6AB-EDB056BFB59D--