From nobody Mon Feb 4 14:26:28 2019 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 A8002127598 for ; Mon, 4 Feb 2019 14:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 bEA57f5XHb16 for ; Mon, 4 Feb 2019 14:26:25 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0: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 177EC12867A for ; Mon, 4 Feb 2019 14:26:25 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id u16so2595300otk.8 for ; Mon, 04 Feb 2019 14:26:25 -0800 (PST) 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=G6D+4g8QHkinZnIVpNIVs5E8OkH/cgLngfJ+wOhSzWU=; b=t8taCsQ5QeLE1H7Xc7WYJV3pt0FsV84hUOzQKYL9K+MoltV2oa71+56EK/fdlW0i6h U6wMzLzAVLlF4L+hybDS+nAu71K5eJIyjgKEnDAP4FIlMjB77u1vN722r6RxQ/qbhMOr 7KU6y/GJNF8/9jBoMfiJ6AwaXHhhgwGb0W+B8Sq6+CDta/pxGgVDF9HGH1C5Lc7g4tuv gcQAJ+kiB8VC3CDwFhxFf8sQYRGw5gZstUOkVCJAwZkbCzmycvMH3b/XrP+0RUZIZPZz UsxjNPjQzb8KUzzq0gVlowBBBvDXyQHrg40E7QAlnysOJWWsdprjVnqvq++uZGg/b09e t/wQ== 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=G6D+4g8QHkinZnIVpNIVs5E8OkH/cgLngfJ+wOhSzWU=; b=mxZFkABuKqfhmLsEe7IxP0DCNx5QW8jmkoFxIYT7anXrPrGyZg49bezwJUcsIJ911C 9588TX+/DtZG5LM3gNE1KrR/m6tx6RS/18Y4scUWTd/NiGaKeoh0iTWYPfuc1/wXxe59 2vFtPdCEAw7PNSgWxM08eqoriaOmX1RsX1m7npbHXaYvARTs5OT45cMbj1ITa6p7nZYF H28wiRzlpeAZApKpmDYFZRzMfKy9MaulqfGVnSCfNCX9JAVJ5dNMZtGwYW6rJW2yygGJ KtuzlNP3mxYwcbfIKfI+shRJB+QbXVOPMkzoif8Cktw6HYNxcl//WDe9lGGZgOSMaRYf NrjQ== X-Gm-Message-State: AHQUAuYRTSbIoRE7B0AN+Cy23A015MTT2PmOfHk3Ff4xNTfdEgZ4NVQN su3rV5u1wfQQGuzT0yYHi6m6zBzn7UOOCKCbvQXw6kjYFZ0= X-Google-Smtp-Source: AHgI3IZa+MCZRYdrhsydx9qSewh4JDiQHCm2UX4GcPn3sOPOVZJfNaWu2q6BZqMogmiFWlEwWk3dHMSFveAx8EENZU8= X-Received: by 2002:aca:3708:: with SMTP id e8mr847796oia.51.1549319184010; Mon, 04 Feb 2019 14:26:24 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 4 Feb 2019 17:26:06 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000009b7019058118fb5b" Archived-At: Subject: [MLS] Delta-Remove may not be feasible X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 22:26:27 -0000 --0000000000009b7019058118fb5b Content-Type: text/plain; charset="UTF-8" Hey all, I was just looking at the list of open issues, in particular #104 (Sever-initated removal). It occurred to me that we had forgotten to record the idea (raised by EKR, me, and Yevgeniy at various times) of using a "delta" approach to make removal more efficient. When I sat down to try to figure out how to actually do it, I discovered that none of the obvious approaches work with Curve25519 / Curve448! It turns out that the private->public mapping for those curves is not a homomorphism with regard to addition or multiplication. I sent a ping to the CFRG list to see if anyone has any good ideas: https://mailarchive.ietf.org/arch/msg/cfrg/JVg30dldjr4pcwZ1perpA1k-OGQ Cheers, --Richard --0000000000009b7019058118fb5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,
=
I was just looking at the list of open issues, in particular= #104 (Sever-initated removal).=C2=A0 It occurred to me that we had forgott= en to record the idea (raised by EKR, me, and Yevgeniy at various times) of= using a "delta" approach to make removal more efficient.

When I sat down to try to figure out how to actually = do it, I discovered that none of the obvious approaches work with Curve2551= 9 / Curve448!=C2=A0 It turns out that the private->public mapping for th= ose curves is not a homomorphism with regard to addition or multiplication.= =C2=A0 I sent a ping to the CFRG list to see if anyone has any good ideas:<= br>


Cheers,
=
--Richard
--0000000000009b7019058118fb5b-- From nobody Wed Feb 6 02:07:50 2019 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 3224C124D68 for ; Wed, 6 Feb 2019 02:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Xo0xk6AyGcNQ for ; Wed, 6 Feb 2019 02:07:46 -0800 (PST) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF2F12426E for ; Wed, 6 Feb 2019 02:07:44 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 40A29A3BAB for ; Wed, 6 Feb 2019 11:07:42 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id MAwY5dPASYlM for ; Wed, 6 Feb 2019 11:07:35 +0100 (CET) To: mls@ietf.org References: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> From: Konrad Kohbrok Message-ID: <321d21c2-22ab-def4-7014-8948eeaa0dea@datashrine.de> Date: Wed, 6 Feb 2019 12:07:33 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] KDF instead of hashing up the 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: Wed, 06 Feb 2019 10:07:49 -0000 A question I ran into while working on the PR: Currently, there is the notion of "Derive-Key-Pair" function that produces a key pair from an octet string. Do we want to keep that function for modularity/composability purposes at the possible price of an additional KDF expand operation per key derivation? This is probably just a formal detail, but I wasn't quite sure what the best way forward would be. The options as I see them are as follows: Consider a node A that wants to update its secret. Option 1, derive the private KEM key directly, no Derive-Key-Pair function. Instead a Derive-Public-Key function: x_a <-$- {0,1}^n // This is A's new secret octet string a <-- KDF(x_a,"kem_key") // This is A's private KEM-key A <-- Derive-Public-Key(a) // This is A's public KEM-key x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet string b <-- KDF(x_b,"kem_key") // This is B's new private KEM-key B <-- Derive-Public-Key(b) // This is B's public KEM-key Option 2, stick with a Derive-Key-Pair function, but add additional KDF expand to ensure key separation: x_a <-$- {0,1}^n // This is B's new seed octet string x_a' <-- KDF(x_a,"secret_seed") // This is A's new secret octet string (a,A) <-- Derive-Key-Pair(x_a') // This is A's new private/public key pair x_b <-- KDF(x_a,"parent_secret") // This is B's new seed octet string x_b' <-- KDF(x_b,"secret_seed") // This is B's new secret octet string (b,A) <-- Derive-Key-Pair(x_b) // This is B's new private/public key pair Option 3, use Derive-Key-Pair function directly on seed. This would add the requirement to the Derive-Key-Pair notion, that it (internally) uses a KDF to derive the private key. x_a <-$- {0,1}^n (a,A) <-- Derive-Key-Pair(x_a) // This is A's new private/public key pair x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet string (b,B) <-- Derive-Key-Pair(x_b) // This is B's new private/public key pair My guess is that in most cases the Derive-Key-Pair function will in the end call a KDF to get the private key anyway, which means that we have one superfluous KDF expand operation. Konrad On 23/01/2019 17:47, Richard Barnes wrote: > Ah, ok, I get it.  I misunderstood "new secret" as "fresh entropy". > > In that case, this falls into the "sure, if it makes the analysis better" > bucket.  We've been treating hashes/HKDF invocations as basically free.  At some > point we might need to worry about that, but I suspect that today is not that day. > > Want to make a PR? > > --Richard > > > On Wed, Jan 23, 2019 at 10:19 AM Konrad Kohbrok > wrote: > > Exactly, thanks Karthik! > > Say we have the same tree as in the example in 5.4: > >          G >        /   \ >       /     \ >      E       _ >     / \     / \ >    A   B   C   D > > Then A generates a fresh secret X_1secret and derives the following new secrets: > X_1kemkey=HKDF(X_1secret,"kemkey") > X_2secret=HKDF(X_1secret,"parent") > > X_2kemkey=HKDF(X_2secret,"kemkey") > X_3secret=HKDF(X_2secret,"parent") > > X_3kemkey=HKDF(X_3secret,"kemkey") > > A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and > E(pk(D),X_3secret) to D. > > Hopefully that makes the idea a little clearer. Sorry for the terrible notation. > > Konrad > > On 23/01/2019 16:59, Karthikeyan Bhargavan wrote: > > If I understand correctly, Chris and Konrad are not suggesting changing > the secrets. > > Instead, they are suggesting that H(.) be implemented as something like: > > > > H(x) = HKDF(x,label=”parent”) > > > > where x is the tree secret for the current node. > > > > Similarly, when generating the KEM private key for a node, we use > > > > KGEN(x) = HKDF(x,label=“kem key”) > > > > This would be a good way of making sure that each key in the protocol is > > independent, but at no additional cost. > > Am I understanding this correctly, Konrad? > > > >> On 23 Jan 2019, at 15:29, Richard Barnes >> wrote: > >> > >> Note this is a little bit expensive in terms of message size; it changes the > >> size of an update from log(N) to log(N)^2.  It does not change the number of > >> DH operations > >> > >> This is because you have to send the fresh secret for each intermediate node > >> in the tree to all its descendants.  Comparing the secrets you generate in > >> each case, from leaf to root, along a path of depth 3 with S0 at the leaf: > >> > >> Current: S0, S1 = H(S0), S2 = H^2(S0), S3 = H^3(S0) > >> Proposed: S0, S1 = KDF(T0, S0), S2 = KDF(T1, S1), S3 = KDF(T2, S2) > >> > >> Where T* are the fresh secrets called for here.  This doesn't change to whom > >> you encrypt things, but changes what you encrypt to each copath node: > >> > >> Current -> Proposed > >> S1 -> S1, T1, T2 > >> S2 -> S2, T2 > >> S3 -> S3 > >> > >> (This is of course because you need to enable each recipient to compute > up the > >> tree.)  So there's your log->log^2. > >> > >> This discussion is not to say that I'm opposed to this idea.  It just looks > >> like it has some non-negligible cost, so we should make sure we know what > >> we're getting for that cost. > >> > >> --Ricahrd > >> > >> > >> > >> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok >> >> wrote: > >> > >>     Hey everyone, > >> > >>     I just discussed the current draft with my advisor Chris Brzuska and he > >>     came up > >>     with a suggestion that I thought I'd just quickly relay here. As I > have only > >>     started following the discussion recently, I apologize if this was > already > >>     brought up in the past. > >> > >>     In terms of key separation, wouldn't it make for a cleaner design, if we > >>     used a > >>     KDF instead of a hash function? Instead of  generating a new > leaf-node secret > >>     and then hashing it to compute the new secret for the parent node, it > would be > >>     better to generate a new secret and then from that secret > independently (i.e. > >>     with different labels) compute the new leaf secret and the new secret > for the > >>     parent node. This key independence would also make the proof easier. In > >>     terms of > >>     overhead, this would mean two KDF operations instead of one hashing > operation. > >> > >>     Cheers, > >>     Konrad > >> > >>     _______________________________________________ > >>     MLS mailing list > >>     MLS@ietf.org > > >>     https://www.ietf.org/mailman/listinfo/mls > >> > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mls > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Feb 6 03:37:49 2019 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 734E2126C7E for ; Wed, 6 Feb 2019 03:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a48wzai0Q23l for ; Wed, 6 Feb 2019 03:37:45 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82B8124D68 for ; Wed, 6 Feb 2019 03:37:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,339,1544482800"; d="scan'208";a="368229441" Received: from wifi-pro-83-011.paris.inria.fr ([128.93.83.11]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2019 12:37:42 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Benjamin Beurdouche In-Reply-To: <321d21c2-22ab-def4-7014-8948eeaa0dea@datashrine.de> Date: Wed, 6 Feb 2019 12:37:42 +0100 Cc: ML Messaging Layer Security Content-Transfer-Encoding: quoted-printable Message-Id: <1AF700AD-243F-4BDD-AC44-F57CAF115E80@inria.fr> References: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> <321d21c2-22ab-def4-7014-8948eeaa0dea@datashrine.de> To: Konrad Kohbrok X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] KDF instead of hashing up the 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: Wed, 06 Feb 2019 11:37:48 -0000 Hi Konrad, I think I got the idea, but let me try to reformulate with the following = tree: AB / \ A B What we currently want to do: For A: x_a <-$- {0,1}^n // This is A's new secret octet string a <-- KDF(x_a,"kem_key") // This is A's private KEM-key A <-- Derive-Public-Key(a) // This is A's public KEM-key For AB: OLD =3D x_ab <-- Hash(x_a) // This is AB's new secret octet string NEW =3D x_ab <-- KDF(x_a,=E2=80=9Dparent_key") // This is AB's new = secret octet string ab <-- KDF(x_ab,"kem_key") // This is AB's new private KEM-key AB <-- Derive-Public-Key(ab) // This is AB's public KEM-key What we need for a computational security proof is a (=E2=80=9Ctechnical")= key separation between A and AB=E2=80=99s secrets (a & ab) hence moving the draft = towards using a KDF. (I think I remember the TLS story which was expand one and split versus expand twice). I completely agree with that and that doesn=E2=80=99t = cost anything : ) Regarding the multiple options: to me option 1 and 3 are really the same = as I consider the following relationship: (y,Y) <-- Derive-Key-Pair(X)=20 :=3D y <-- KDF(X,=E2=80=9Dkem_key=E2=80=9D); Y <-- Derive-Public-Key(y); Am I wrong in saying that I believe option 1 already gives us everything = we need ? I really like that design actually which fits the derivation scheme for = the message protection. Best, B. > On Feb 6, 2019, at 11:07 AM, Konrad Kohbrok = wrote: >=20 > A question I ran into while working on the PR: Currently, there is the = notion of > "Derive-Key-Pair" function that produces a key pair from an octet = string. >=20 > Do we want to keep that function for modularity/composability purposes = at the > possible price of an additional KDF expand operation per key = derivation? This is > probably just a formal detail, but I wasn't quite sure what the best = way forward > would be. >=20 > The options as I see them are as follows: >=20 > Consider a node A that wants to update its secret. >=20 > Option 1, derive the private KEM key directly, no Derive-Key-Pair = function. > Instead a Derive-Public-Key function: >=20 > x_a <-$- {0,1}^n // This is A's new secret octet string > a <-- KDF(x_a,"kem_key") // This is A's private KEM-key > A <-- Derive-Public-Key(a) // This is A's public KEM-key > x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet = string > b <-- KDF(x_b,"kem_key") // This is B's new private KEM-key > B <-- Derive-Public-Key(b) // This is B's public KEM-key >=20 >=20 > Option 2, stick with a Derive-Key-Pair function, but add additional = KDF expand > to ensure key separation: >=20 > x_a <-$- {0,1}^n // This is B's new seed octet string > x_a' <-- KDF(x_a,"secret_seed") // This is A's new secret octet string > (a,A) <-- Derive-Key-Pair(x_a') // This is A's new private/public key = pair > x_b <-- KDF(x_a,"parent_secret") // This is B's new seed octet string > x_b' <-- KDF(x_b,"secret_seed") // This is B's new secret octet string > (b,A) <-- Derive-Key-Pair(x_b) // This is B's new private/public key = pair >=20 >=20 > Option 3, use Derive-Key-Pair function directly on seed. This would = add the > requirement to the Derive-Key-Pair notion, that it (internally) uses a = KDF to > derive the private key. >=20 > x_a <-$- {0,1}^n > (a,A) <-- Derive-Key-Pair(x_a) // This is A's new private/public key = pair > x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet = string > (b,B) <-- Derive-Key-Pair(x_b) // This is B's new private/public key = pair >=20 >=20 > My guess is that in most cases the Derive-Key-Pair function will in = the end call > a KDF to get the private key anyway, which means that we have one = superfluous > KDF expand operation. >=20 > Konrad >=20 >=20 >=20 > On 23/01/2019 17:47, Richard Barnes wrote: >> Ah, ok, I get it. I misunderstood "new secret" as "fresh entropy". >>=20 >> In that case, this falls into the "sure, if it makes the analysis = better" >> bucket. We've been treating hashes/HKDF invocations as basically = free. At some >> point we might need to worry about that, but I suspect that today is = not that day. >>=20 >> Want to make a PR? >>=20 >> --Richard >>=20 >>=20 >> On Wed, Jan 23, 2019 at 10:19 AM Konrad Kohbrok = > > wrote: >>=20 >> Exactly, thanks Karthik! >>=20 >> Say we have the same tree as in the example in 5.4: >>=20 >> G >> / \ >> / \ >> E _ >> / \ / \ >> A B C D >>=20 >> Then A generates a fresh secret X_1secret and derives the = following new secrets: >> X_1kemkey=3DHKDF(X_1secret,"kemkey") >> X_2secret=3DHKDF(X_1secret,"parent") >>=20 >> X_2kemkey=3DHKDF(X_2secret,"kemkey") >> X_3secret=3DHKDF(X_2secret,"parent") >>=20 >> X_3kemkey=3DHKDF(X_3secret,"kemkey") >>=20 >> A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and >> E(pk(D),X_3secret) to D. >>=20 >> Hopefully that makes the idea a little clearer. Sorry for the = terrible notation. >>=20 >> Konrad >>=20 >> On 23/01/2019 16:59, Karthikeyan Bhargavan wrote: >>> If I understand correctly, Chris and Konrad are not suggesting = changing >> the secrets. >>> Instead, they are suggesting that H(.) be implemented as something = like: >>>=20 >>> H(x) =3D HKDF(x,label=3D=E2=80=9Dparent=E2=80=9D) >>>=20 >>> where x is the tree secret for the current node. >>>=20 >>> Similarly, when generating the KEM private key for a node, we use >>>=20 >>> KGEN(x) =3D HKDF(x,label=3D=E2=80=9Ckem key=E2=80=9D) >>>=20 >>> This would be a good way of making sure that each key in the = protocol is >>> independent, but at no additional cost. >>> Am I understanding this correctly, Konrad? >>>=20 >>>> On 23 Jan 2019, at 15:29, Richard Barnes > >> wrote: >>>>=20 >>>> Note this is a little bit expensive in terms of message size; it = changes the >>>> size of an update from log(N) to log(N)^2. It does not change the = number of >>>> DH operations >>>>=20 >>>> This is because you have to send the fresh secret for each = intermediate node >>>> in the tree to all its descendants. Comparing the secrets you = generate in >>>> each case, from leaf to root, along a path of depth 3 with S0 at = the leaf: >>>>=20 >>>> Current: S0, S1 =3D H(S0), S2 =3D H^2(S0), S3 =3D H^3(S0) >>>> Proposed: S0, S1 =3D KDF(T0, S0), S2 =3D KDF(T1, S1), S3 =3D = KDF(T2, S2) >>>>=20 >>>> Where T* are the fresh secrets called for here. This doesn't = change to whom >>>> you encrypt things, but changes what you encrypt to each copath = node: >>>>=20 >>>> Current -> Proposed >>>> S1 -> S1, T1, T2 >>>> S2 -> S2, T2 >>>> S3 -> S3 >>>>=20 >>>> (This is of course because you need to enable each recipient to = compute >> up the >>>> tree.) So there's your log->log^2. >>>>=20 >>>> This discussion is not to say that I'm opposed to this idea. It = just looks >>>> like it has some non-negligible cost, so we should make sure we = know what >>>> we're getting for that cost. >>>>=20 >>>> --Ricahrd >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok = >>> > >> wrote: >>>>=20 >>>> Hey everyone, >>>>=20 >>>> I just discussed the current draft with my advisor Chris = Brzuska and he >>>> came up >>>> with a suggestion that I thought I'd just quickly relay here. = As I >> have only >>>> started following the discussion recently, I apologize if this = was >> already >>>> brought up in the past. >>>>=20 >>>> In terms of key separation, wouldn't it make for a cleaner = design, if we >>>> used a >>>> KDF instead of a hash function? Instead of generating a new >> leaf-node secret >>>> and then hashing it to compute the new secret for the parent = node, it >> would be >>>> better to generate a new secret and then from that secret >> independently (i.e. >>>> with different labels) compute the new leaf secret and the new = secret >> for the >>>> parent node. This key independence would also make the proof = easier. In >>>> terms of >>>> overhead, this would mean two KDF operations instead of one = hashing >> operation. >>>>=20 >>>> Cheers, >>>> Konrad >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mls >>>=20 >>=20 >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 6 23:37:35 2019 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 74E121310F5 for ; Wed, 6 Feb 2019 23:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 dChB02s_HIGe for ; Wed, 6 Feb 2019 23:37:29 -0800 (PST) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041CF131129 for ; Wed, 6 Feb 2019 23:37:28 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 49074A12D5; Thu, 7 Feb 2019 08:37:26 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id 975R1m-rKImt; Thu, 7 Feb 2019 08:37:20 +0100 (CET) To: Benjamin Beurdouche Cc: ML Messaging Layer Security References: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> <321d21c2-22ab-def4-7014-8948eeaa0dea@datashrine.de> <1AF700AD-243F-4BDD-AC44-F57CAF115E80@inria.fr> From: Konrad Kohbrok Message-ID: <05a6578c-2cc9-5338-e5df-3f13b9eb216f@datashrine.de> Date: Thu, 7 Feb 2019 09:37:19 +0200 MIME-Version: 1.0 In-Reply-To: <1AF700AD-243F-4BDD-AC44-F57CAF115E80@inria.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] KDF instead of hashing up the 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: Thu, 07 Feb 2019 07:37:34 -0000 Hey Benjamin, sure, that sounds good. I was just wondering if we want to keep the notion of a "Derive-Key-Pair" function, e.g., for a case where a private key is not necessarily a (pseudo-)random string you get out of a KDF. But if everyone is ok with that assumption and the additional notion of a "Derive-Public-Key" function, then I'm absolutely happy with that. Konrad On 06/02/2019 13:37, Benjamin Beurdouche wrote: > Hi Konrad, > > I think I got the idea, but let me try to reformulate with the following tree: > > AB > / \ > A B > > What we currently want to do: > > For A: > x_a <-$- {0,1}^n // This is A's new secret octet string > a <-- KDF(x_a,"kem_key") // This is A's private KEM-key > A <-- Derive-Public-Key(a) // This is A's public KEM-key > > For AB: > OLD = x_ab <-- Hash(x_a) // This is AB's new secret octet string > NEW = x_ab <-- KDF(x_a,”parent_key") // This is AB's new secret octet string > ab <-- KDF(x_ab,"kem_key") // This is AB's new private KEM-key > AB <-- Derive-Public-Key(ab) // This is AB's public KEM-key > > What we need for a computational security proof is a (“technical") key separation > between A and AB’s secrets (a & ab) hence moving the draft towards using a KDF. > (I think I remember the TLS story which was expand one and split versus > expand twice). I completely agree with that and that doesn’t cost anything : ) > > Regarding the multiple options: to me option 1 and 3 are really the same as I > consider the following relationship: > (y,Y) <-- Derive-Key-Pair(X) > := > y <-- KDF(X,”kem_key”); > Y <-- Derive-Public-Key(y); > > Am I wrong in saying that I believe option 1 already gives us everything we need ? > I really like that design actually which fits the derivation scheme for the message protection. > > Best, > B. > >> On Feb 6, 2019, at 11:07 AM, Konrad Kohbrok wrote: >> >> A question I ran into while working on the PR: Currently, there is the notion of >> "Derive-Key-Pair" function that produces a key pair from an octet string. >> >> Do we want to keep that function for modularity/composability purposes at the >> possible price of an additional KDF expand operation per key derivation? This is >> probably just a formal detail, but I wasn't quite sure what the best way forward >> would be. >> >> The options as I see them are as follows: >> >> Consider a node A that wants to update its secret. >> >> Option 1, derive the private KEM key directly, no Derive-Key-Pair function. >> Instead a Derive-Public-Key function: >> >> x_a <-$- {0,1}^n // This is A's new secret octet string >> a <-- KDF(x_a,"kem_key") // This is A's private KEM-key >> A <-- Derive-Public-Key(a) // This is A's public KEM-key >> x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet string >> b <-- KDF(x_b,"kem_key") // This is B's new private KEM-key >> B <-- Derive-Public-Key(b) // This is B's public KEM-key >> >> >> Option 2, stick with a Derive-Key-Pair function, but add additional KDF expand >> to ensure key separation: >> >> x_a <-$- {0,1}^n // This is B's new seed octet string >> x_a' <-- KDF(x_a,"secret_seed") // This is A's new secret octet string >> (a,A) <-- Derive-Key-Pair(x_a') // This is A's new private/public key pair >> x_b <-- KDF(x_a,"parent_secret") // This is B's new seed octet string >> x_b' <-- KDF(x_b,"secret_seed") // This is B's new secret octet string >> (b,A) <-- Derive-Key-Pair(x_b) // This is B's new private/public key pair >> >> >> Option 3, use Derive-Key-Pair function directly on seed. This would add the >> requirement to the Derive-Key-Pair notion, that it (internally) uses a KDF to >> derive the private key. >> >> x_a <-$- {0,1}^n >> (a,A) <-- Derive-Key-Pair(x_a) // This is A's new private/public key pair >> x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet string >> (b,B) <-- Derive-Key-Pair(x_b) // This is B's new private/public key pair >> >> >> My guess is that in most cases the Derive-Key-Pair function will in the end call >> a KDF to get the private key anyway, which means that we have one superfluous >> KDF expand operation. >> >> Konrad >> >> >> >> On 23/01/2019 17:47, Richard Barnes wrote: >>> Ah, ok, I get it. I misunderstood "new secret" as "fresh entropy". >>> >>> In that case, this falls into the "sure, if it makes the analysis better" >>> bucket. We've been treating hashes/HKDF invocations as basically free. At some >>> point we might need to worry about that, but I suspect that today is not that day. >>> >>> Want to make a PR? >>> >>> --Richard >>> >>> >>> On Wed, Jan 23, 2019 at 10:19 AM Konrad Kohbrok >> > wrote: >>> >>> Exactly, thanks Karthik! >>> >>> Say we have the same tree as in the example in 5.4: >>> >>> G >>> / \ >>> / \ >>> E _ >>> / \ / \ >>> A B C D >>> >>> Then A generates a fresh secret X_1secret and derives the following new secrets: >>> X_1kemkey=HKDF(X_1secret,"kemkey") >>> X_2secret=HKDF(X_1secret,"parent") >>> >>> X_2kemkey=HKDF(X_2secret,"kemkey") >>> X_3secret=HKDF(X_2secret,"parent") >>> >>> X_3kemkey=HKDF(X_3secret,"kemkey") >>> >>> A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and >>> E(pk(D),X_3secret) to D. >>> >>> Hopefully that makes the idea a little clearer. Sorry for the terrible notation. >>> >>> Konrad >>> >>> On 23/01/2019 16:59, Karthikeyan Bhargavan wrote: >>>> If I understand correctly, Chris and Konrad are not suggesting changing >>> the secrets. >>>> Instead, they are suggesting that H(.) be implemented as something like: >>>> >>>> H(x) = HKDF(x,label=”parent”) >>>> >>>> where x is the tree secret for the current node. >>>> >>>> Similarly, when generating the KEM private key for a node, we use >>>> >>>> KGEN(x) = HKDF(x,label=“kem key”) >>>> >>>> This would be a good way of making sure that each key in the protocol is >>>> independent, but at no additional cost. >>>> Am I understanding this correctly, Konrad? >>>> >>>>> On 23 Jan 2019, at 15:29, Richard Barnes >> >> wrote: >>>>> >>>>> Note this is a little bit expensive in terms of message size; it changes the >>>>> size of an update from log(N) to log(N)^2. It does not change the number of >>>>> DH operations >>>>> >>>>> This is because you have to send the fresh secret for each intermediate node >>>>> in the tree to all its descendants. Comparing the secrets you generate in >>>>> each case, from leaf to root, along a path of depth 3 with S0 at the leaf: >>>>> >>>>> Current: S0, S1 = H(S0), S2 = H^2(S0), S3 = H^3(S0) >>>>> Proposed: S0, S1 = KDF(T0, S0), S2 = KDF(T1, S1), S3 = KDF(T2, S2) >>>>> >>>>> Where T* are the fresh secrets called for here. This doesn't change to whom >>>>> you encrypt things, but changes what you encrypt to each copath node: >>>>> >>>>> Current -> Proposed >>>>> S1 -> S1, T1, T2 >>>>> S2 -> S2, T2 >>>>> S3 -> S3 >>>>> >>>>> (This is of course because you need to enable each recipient to compute >>> up the >>>>> tree.) So there's your log->log^2. >>>>> >>>>> This discussion is not to say that I'm opposed to this idea. It just looks >>>>> like it has some non-negligible cost, so we should make sure we know what >>>>> we're getting for that cost. >>>>> >>>>> --Ricahrd >>>>> >>>>> >>>>> >>>>> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok >>>> >> >> wrote: >>>>> >>>>> Hey everyone, >>>>> >>>>> I just discussed the current draft with my advisor Chris Brzuska and he >>>>> came up >>>>> with a suggestion that I thought I'd just quickly relay here. As I >>> have only >>>>> started following the discussion recently, I apologize if this was >>> already >>>>> brought up in the past. >>>>> >>>>> In terms of key separation, wouldn't it make for a cleaner design, if we >>>>> used a >>>>> KDF instead of a hash function? Instead of generating a new >>> leaf-node secret >>>>> and then hashing it to compute the new secret for the parent node, it >>> would be >>>>> better to generate a new secret and then from that secret >>> independently (i.e. >>>>> with different labels) compute the new leaf secret and the new secret >>> for the >>>>> parent node. This key independence would also make the proof easier. In >>>>> terms of >>>>> overhead, this would mean two KDF operations instead of one hashing >>> operation. >>>>> >>>>> Cheers, >>>>> Konrad >>>>> >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >> > >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >> > >>>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>> >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls > From nobody Fri Feb 8 04:17:19 2019 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 8FE4C12EB11 for ; Fri, 8 Feb 2019 04:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 v9nPo6bEh4EH for ; Fri, 8 Feb 2019 04:17:13 -0800 (PST) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBA212867A for ; Fri, 8 Feb 2019 04:17:11 -0800 (PST) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 898DAA113A for ; Fri, 8 Feb 2019 13:17:09 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id x3frv5WDco_T for ; Fri, 8 Feb 2019 13:17:06 +0100 (CET) To: mls@ietf.org References: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> <321d21c2-22ab-def4-7014-8948eeaa0dea@datashrine.de> <1AF700AD-243F-4BDD-AC44-F57CAF115E80@inria.fr> <05a6578c-2cc9-5338-e5df-3f13b9eb216f@datashrine.de> From: Konrad Kohbrok Message-ID: Date: Fri, 8 Feb 2019 14:17:02 +0200 MIME-Version: 1.0 In-Reply-To: <05a6578c-2cc9-5338-e5df-3f13b9eb216f@datashrine.de> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] KDF instead of hashing up the 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, 08 Feb 2019 12:17:17 -0000 Next question: Is it worth editing the RFC beyond the "Cryptographic Objects" headline? There is a lot of DH-specific stuff that seems to be somewhat outdated anyway if we aim for a KEM-agnostic design. Konrad 07/02/2019 09:37, Konrad Kohbrok wrote: > Hey Benjamin, > > sure, that sounds good. I was just wondering if we want to keep the notion of a > "Derive-Key-Pair" function, e.g., for a case where a private key is not > necessarily a (pseudo-)random string you get out of a KDF. > > But if everyone is ok with that assumption and the additional notion of a > "Derive-Public-Key" function, then I'm absolutely happy with that. > > Konrad > > On 06/02/2019 13:37, Benjamin Beurdouche wrote: >> Hi Konrad, >> >> I think I got the idea, but let me try to reformulate with the following tree: >> >> AB >> / \ >> A B >> >> What we currently want to do: >> >> For A: >> x_a <-$- {0,1}^n // This is A's new secret octet string >> a <-- KDF(x_a,"kem_key") // This is A's private KEM-key >> A <-- Derive-Public-Key(a) // This is A's public KEM-key >> >> For AB: >> OLD = x_ab <-- Hash(x_a) // This is AB's new secret octet string >> NEW = x_ab <-- KDF(x_a,”parent_key") // This is AB's new secret octet string >> ab <-- KDF(x_ab,"kem_key") // This is AB's new private KEM-key >> AB <-- Derive-Public-Key(ab) // This is AB's public KEM-key >> >> What we need for a computational security proof is a (“technical") key separation >> between A and AB’s secrets (a & ab) hence moving the draft towards using a KDF. >> (I think I remember the TLS story which was expand one and split versus >> expand twice). I completely agree with that and that doesn’t cost anything : ) >> >> Regarding the multiple options: to me option 1 and 3 are really the same as I >> consider the following relationship: >> (y,Y) <-- Derive-Key-Pair(X) >> := >> y <-- KDF(X,”kem_key”); >> Y <-- Derive-Public-Key(y); >> >> Am I wrong in saying that I believe option 1 already gives us everything we need ? >> I really like that design actually which fits the derivation scheme for the message protection. >> >> Best, >> B. >> >>> On Feb 6, 2019, at 11:07 AM, Konrad Kohbrok wrote: >>> >>> A question I ran into while working on the PR: Currently, there is the notion of >>> "Derive-Key-Pair" function that produces a key pair from an octet string. >>> >>> Do we want to keep that function for modularity/composability purposes at the >>> possible price of an additional KDF expand operation per key derivation? This is >>> probably just a formal detail, but I wasn't quite sure what the best way forward >>> would be. >>> >>> The options as I see them are as follows: >>> >>> Consider a node A that wants to update its secret. >>> >>> Option 1, derive the private KEM key directly, no Derive-Key-Pair function. >>> Instead a Derive-Public-Key function: >>> >>> x_a <-$- {0,1}^n // This is A's new secret octet string >>> a <-- KDF(x_a,"kem_key") // This is A's private KEM-key >>> A <-- Derive-Public-Key(a) // This is A's public KEM-key >>> x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet string >>> b <-- KDF(x_b,"kem_key") // This is B's new private KEM-key >>> B <-- Derive-Public-Key(b) // This is B's public KEM-key >>> >>> >>> Option 2, stick with a Derive-Key-Pair function, but add additional KDF expand >>> to ensure key separation: >>> >>> x_a <-$- {0,1}^n // This is B's new seed octet string >>> x_a' <-- KDF(x_a,"secret_seed") // This is A's new secret octet string >>> (a,A) <-- Derive-Key-Pair(x_a') // This is A's new private/public key pair >>> x_b <-- KDF(x_a,"parent_secret") // This is B's new seed octet string >>> x_b' <-- KDF(x_b,"secret_seed") // This is B's new secret octet string >>> (b,A) <-- Derive-Key-Pair(x_b) // This is B's new private/public key pair >>> >>> >>> Option 3, use Derive-Key-Pair function directly on seed. This would add the >>> requirement to the Derive-Key-Pair notion, that it (internally) uses a KDF to >>> derive the private key. >>> >>> x_a <-$- {0,1}^n >>> (a,A) <-- Derive-Key-Pair(x_a) // This is A's new private/public key pair >>> x_b <-- KDF(x_a,"parent_secret") // This is B's new secret octet string >>> (b,B) <-- Derive-Key-Pair(x_b) // This is B's new private/public key pair >>> >>> >>> My guess is that in most cases the Derive-Key-Pair function will in the end call >>> a KDF to get the private key anyway, which means that we have one superfluous >>> KDF expand operation. >>> >>> Konrad >>> >>> >>> >>> On 23/01/2019 17:47, Richard Barnes wrote: >>>> Ah, ok, I get it. I misunderstood "new secret" as "fresh entropy". >>>> >>>> In that case, this falls into the "sure, if it makes the analysis better" >>>> bucket. We've been treating hashes/HKDF invocations as basically free. At some >>>> point we might need to worry about that, but I suspect that today is not that day. >>>> >>>> Want to make a PR? >>>> >>>> --Richard >>>> >>>> >>>> On Wed, Jan 23, 2019 at 10:19 AM Konrad Kohbrok >>> > wrote: >>>> >>>> Exactly, thanks Karthik! >>>> >>>> Say we have the same tree as in the example in 5.4: >>>> >>>> G >>>> / \ >>>> / \ >>>> E _ >>>> / \ / \ >>>> A B C D >>>> >>>> Then A generates a fresh secret X_1secret and derives the following new secrets: >>>> X_1kemkey=HKDF(X_1secret,"kemkey") >>>> X_2secret=HKDF(X_1secret,"parent") >>>> >>>> X_2kemkey=HKDF(X_2secret,"kemkey") >>>> X_3secret=HKDF(X_2secret,"parent") >>>> >>>> X_3kemkey=HKDF(X_3secret,"kemkey") >>>> >>>> A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and >>>> E(pk(D),X_3secret) to D. >>>> >>>> Hopefully that makes the idea a little clearer. Sorry for the terrible notation. >>>> >>>> Konrad >>>> >>>> On 23/01/2019 16:59, Karthikeyan Bhargavan wrote: >>>>> If I understand correctly, Chris and Konrad are not suggesting changing >>>> the secrets. >>>>> Instead, they are suggesting that H(.) be implemented as something like: >>>>> >>>>> H(x) = HKDF(x,label=”parent”) >>>>> >>>>> where x is the tree secret for the current node. >>>>> >>>>> Similarly, when generating the KEM private key for a node, we use >>>>> >>>>> KGEN(x) = HKDF(x,label=“kem key”) >>>>> >>>>> This would be a good way of making sure that each key in the protocol is >>>>> independent, but at no additional cost. >>>>> Am I understanding this correctly, Konrad? >>>>> >>>>>> On 23 Jan 2019, at 15:29, Richard Barnes >>> >> wrote: >>>>>> >>>>>> Note this is a little bit expensive in terms of message size; it changes the >>>>>> size of an update from log(N) to log(N)^2. It does not change the number of >>>>>> DH operations >>>>>> >>>>>> This is because you have to send the fresh secret for each intermediate node >>>>>> in the tree to all its descendants. Comparing the secrets you generate in >>>>>> each case, from leaf to root, along a path of depth 3 with S0 at the leaf: >>>>>> >>>>>> Current: S0, S1 = H(S0), S2 = H^2(S0), S3 = H^3(S0) >>>>>> Proposed: S0, S1 = KDF(T0, S0), S2 = KDF(T1, S1), S3 = KDF(T2, S2) >>>>>> >>>>>> Where T* are the fresh secrets called for here. This doesn't change to whom >>>>>> you encrypt things, but changes what you encrypt to each copath node: >>>>>> >>>>>> Current -> Proposed >>>>>> S1 -> S1, T1, T2 >>>>>> S2 -> S2, T2 >>>>>> S3 -> S3 >>>>>> >>>>>> (This is of course because you need to enable each recipient to compute >>>> up the >>>>>> tree.) So there's your log->log^2. >>>>>> >>>>>> This discussion is not to say that I'm opposed to this idea. It just looks >>>>>> like it has some non-negligible cost, so we should make sure we know what >>>>>> we're getting for that cost. >>>>>> >>>>>> --Ricahrd >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok >>>>> >>> >> wrote: >>>>>> >>>>>> Hey everyone, >>>>>> >>>>>> I just discussed the current draft with my advisor Chris Brzuska and he >>>>>> came up >>>>>> with a suggestion that I thought I'd just quickly relay here. As I >>>> have only >>>>>> started following the discussion recently, I apologize if this was >>>> already >>>>>> brought up in the past. >>>>>> >>>>>> In terms of key separation, wouldn't it make for a cleaner design, if we >>>>>> used a >>>>>> KDF instead of a hash function? Instead of generating a new >>>> leaf-node secret >>>>>> and then hashing it to compute the new secret for the parent node, it >>>> would be >>>>>> better to generate a new secret and then from that secret >>>> independently (i.e. >>>>>> with different labels) compute the new leaf secret and the new secret >>>> for the >>>>>> parent node. This key independence would also make the proof easier. In >>>>>> terms of >>>>>> overhead, this would mean two KDF operations instead of one hashing >>>> operation. >>>>>> >>>>>> Cheers, >>>>>> Konrad >>>>>> >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>> > >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>> >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>> > >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> >>>> >>>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >> > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Fri Feb 8 05:07:49 2019 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 213C912EB11 for ; Fri, 8 Feb 2019 05:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibrXpxsBF-5h for ; Fri, 8 Feb 2019 05:07:46 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F441288BD for ; Fri, 8 Feb 2019 05:07:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,347,1544482800"; d="scan'208";a="368580064" Received: from wifi-pro-82-044.paris.inria.fr ([128.93.82.44]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2019 14:07:39 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Benjamin Beurdouche In-Reply-To: Date: Fri, 8 Feb 2019 14:07:39 +0100 Cc: ML Messaging Layer Security Content-Transfer-Encoding: quoted-printable Message-Id: <3AEA12C9-60EE-4018-9339-34AA26E0402F@inria.fr> References: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> <321d21c2-22ab-def4-7014-8948eeaa0dea@datashrine.de> <1AF700AD-243F-4BDD-AC44-F57CAF115E80@inria.fr> <05a6578c-2cc9-5338-e5df-3f13b9eb216f@datashrine.de> To: Konrad Kohbrok X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] KDF instead of hashing up the 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, 08 Feb 2019 13:07:48 -0000 > On Feb 8, 2019, at 1:17 PM, Konrad Kohbrok = wrote: >=20 > Next question: Is it worth editing the RFC beyond the "Cryptographic = Objects" > headline? There is a lot of DH-specific stuff that seems to be = somewhat outdated > anyway if we aim for a KEM-agnostic design. >=20 > Konrad Unclear, but I don=E2=80=99t think it is worth it. I am already handling = most of theses changes as part Issue #95 already. Changes seems quite confined to the "Ratchet Tree Nodes=E2=80=9D section = otherwise. Something useful would be, in this section, to change from Hash to KDF = and replace the mention of DH by a KEM as well. Mentions of hashing outside this = section seem related to the key schedule, so these do not need to be changed. B.= From nobody Fri Feb 8 09:15:21 2019 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 8864112867A for ; Fri, 8 Feb 2019 09:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ewLwztEbcXDm for ; Fri, 8 Feb 2019 09:15:18 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0: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 8A6511200ED for ; Fri, 8 Feb 2019 09:15:18 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id 32so6952601ota.12 for ; Fri, 08 Feb 2019 09:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CytonYcPVNVie2jz5MV7JrFNkZJ3tOzxxwkYEOAAT1c=; b=UpkTbQeokkb8ub8YhTWjv9Rvr8uv+ZkRmP7CKj165d00kY4KB9FKj7cInrHLec77XB kbzWRmrUbz4tXOm8JDWFxRDSQr8uDcdIXnDM3wDgQavs8O/E6JZoDjo9GHOoij0U2JUi EWkqm/jE1KDTrm7GNN8OrkcioyaxQi3mPI7TNuu3a1u/OPx0z28JbQV51FkX5sIplOfs mI+d7LYgBlUv6/fgf95a4lXOAUsaEUnxLA4pJRAMq7DMDPA9uWZ7qo304Vte+4pSpS/O f5UdNaF6LUGOz/gAhomWwfnS0htEBv4gH0F0sJ2ILmsvkV2+Koz5BOGdPVdRjEA4WdMz 3cbQ== 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=CytonYcPVNVie2jz5MV7JrFNkZJ3tOzxxwkYEOAAT1c=; b=WaVg9PfQs8TyawP6ldw2WWTVyHUHo0yWJOs4wOS/g9QcLsH2//2q0oodZNVCEAy0cr YD741levN5ZyjXmyANC8Nz+lQMHZez41pqCohM6cd4umBjBEgFJrjut7EKop9Ph28LeH 9CLMclnOBC5j30AJCrBXnIFCQDLNug1zyvX65FZQR4dUDPdhsYLVRyxIbtb7PZt60KQm HWxHG+GVKdY15nfxP78Ldf2yh8x4Bu8un3SqP9S2SpSC7sML5ck51awfLPg03W97iV3/ WIe6ctd68FZgoR26sNBCn3lkCS6MLCadC3x+JL+MakiPqYWijX/L4fVSFvU6KbZ6TqKR Khdw== X-Gm-Message-State: AHQUAuYVshizXmwTQ1rlrzVY9UH1NlEmFqu9hVmHQ/RwfJv9RrvE+xQa 1gHefbiskJnrqLMH6/o8jkqKugC0C8wk9Dspk8zKqZdCP2g= X-Google-Smtp-Source: AHgI3IZSQgdR5Fk9tW4cJK/zF3vCyz2FfiQQMMB90AUcLMVd/JsaRReLNZMyEomYa8q7r1S1e0sEGROx0rupOTkwdr0= X-Received: by 2002:a9d:6a92:: with SMTP id l18mr7306392otq.81.1549646117443; Fri, 08 Feb 2019 09:15:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 8 Feb 2019 12:15:06 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000005bafb80581651a57" Archived-At: Subject: Re: [MLS] February MLS interop event X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 17:15:21 -0000 --0000000000005bafb80581651a57 Content-Type: text/plain; charset="UTF-8" Summary of conclusions from this call: - Folks weren't quite ready to do live interop - In general, we should do interop async, via test vectors, and use calls to debrief / discuss issues - Next interop check-in targeted for Feb 18 - Still targeting -03 test vectors in mls-implementations repo - ... with #115 to fix application key schedule - A couple of actual test changes would be useful - Tests for the resolution algorithm - Tests for the key schedule (decoupled from a session) Please indicate your availability for the next check-in in this Doodle: https://doodle.com/poll/7b7hurwg268e86a9 On Sat, Jan 26, 2019 at 1:25 PM Richard Barnes wrote: > OK, based on the Doodle results, let's shoot for 16:00-19:00 UTC > > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=MLS+Interop&iso=20190208T16&p1=1440&ah=3 > > We can use the following Webex bridge: > > Join from a video conferencing system or application > Meeting link: https://cisco.webex.com/meet/richbarn > Dial: richbarn@cisco.webex.com > Join using Microsoft Skype for Business: richbarn.cisco@lync.webex.com > Toll Free: +1-866-432-9903 > Toll: +1-408-525-6800 > Access Code: 201006237 > > If you're interested in joining, please make sure you're in the MLS > Implementors Wire channel, which we'll use for text-based coordination. > > > https://app.wire.com/join/?key=3tL-NJOoCKZlDXNU1H2c&code=kZOc0ujnDQ9Tq98tLfSt > > > On Tue, Jan 15, 2019 at 8:01 PM Richard Barnes wrote: > >> Hey all, >> >> A few of us who are writing code for MLS are thinking of having an >> informal interop event in early February. If you'd like to participate, >> please fill out this Doodle to help pick dates: >> >> https://doodle.com/poll/2yd3b2eydchis82b#table >> >> The interop target will be draft-ietf-mls-protocol-03. We will try to >> get everyone passing a common set of test vectors, covering, e.g.: >> >> - Tree math >> - Derive-Key-Pair >> - Message parsing and serialization >> - Fully crypto calculations for a simple scenario >> >> This will be a remote meeting / teleconference. I will send out Webex >> details once we've picked a date/time. >> >> --Richard >> >> --0000000000005bafb80581651a57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Summary of conclusions from this cal= l:

- Folks weren't quite ready to do live inte= rop
- In general, we should do interop async, via test vectors, a= nd use calls to debrief / discuss issues
- Next interop check-in = targeted for Feb 18
=C2=A0 - Still targeting -03 test vectors in = mls-implementations repo
=C2=A0 - ... with #115 to fix applicatio= n key schedule
- A couple of actual test changes would be useful<= br>
=C2=A0 - Tests for the resolution algorithm
=C2=A0 = - Tests for the key schedule (decoupled from a session)

<= /div>
Please indicate your availability for the next check-in in this D= oodle:


=

On Sat, Jan 26, 2019 at 1:25 PM Richard Barnes <rlb@ipv.sx> wro= te:
OK, based on the Doodle results= , let's shoot for 16:00-19:00 UTC


We can use the = following Webex bridge:

Join from a video conferen= cing system or application
Meeting link: https://cisco.webex.com/meet/richbarn<= /a>
Dial: = richbarn@cisco.webex.com
Join using Microsoft Skype for Business: richbarn.c= isco@lync.webex.com
Toll Free: +1-866-432-9903
Toll: +1-408-525-6= 800
Access Code: 201006237

If you're intere= sted in joining, please make sure you're in the MLS Implementors Wire c= hannel, which we'll use for text-based coordination.

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 15, 2019 at 8:01 PM Richar= d Barnes <rlb@ipv.sx> wrote:
Hey all,

A few of us who are writing code for MLS are thinking of h= aving an informal interop event in early February.=C2=A0 If you'd like = to participate, please fill out this Doodle to help pick dates:
<= br>

The interop target will be draft-ietf-mls-protocol-03.=C2=A0 We= will try to get everyone passing a common set of test vectors, covering, e= .g.:

- Tree math
- Derive-Key-Pair
- Message parsing and serialization
- Fully crypto calcula= tions for a simple scenario

This will be a re= mote meeting / teleconference.=C2=A0 I will send out Webex details once we&= #39;ve picked a date/time.

--Richard

--0000000000005bafb80581651a57-- From nobody Tue Feb 12 18:49:03 2019 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 052421277D2 for ; Tue, 12 Feb 2019 18:49:01 -0800 (PST) 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 st6keik0d0Hb for ; Tue, 12 Feb 2019 18:48:59 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 AF31F130F2B for ; Tue, 12 Feb 2019 18:48:59 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id p25so705765qtb.3 for ; Tue, 12 Feb 2019 18:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=oEFGVmXGz5z30PzZzgdJav6n+Re4ZdLHZxjfsmfDx9g=; b=SgYBgE6Z1du2HPC7nMV/KSue2f8aZvCWGjb1ZFy/sUK7kqGWgwVSqxs1ono0xfFWtf thzuiQTnkpX/Ghwalq6+L8QCjn+3EG5rEOwE8xof5IUR2HUXB0DkvjVHuevg9F+MpIMS VVX9D4O3onJUxrjVI76gbTydqpy12VFu8TYnU= 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=oEFGVmXGz5z30PzZzgdJav6n+Re4ZdLHZxjfsmfDx9g=; b=e/KwPbSIHxPUa6eGq1X9d1dadkmPnhVZznamNjVIY4VQPRN7lTwNCZAMvXodX8k0bt NmrACWynR59SrY6Y0jf9xQZe4xyXE+o/bkIdvtj4iUricER5lf2CVYPc8hLQI+HXFE3H OqbK5JVrAGIz5QUKXo9NW2EDLC3sMXe5GbwJk5JdZCFRwld19wfXbnwAuT/TIqQyZA44 8hTm4f73orIRBMLJdo6DPX6sbPlFPyZdw7nQFWpJurRCz30KwM5vbXzMG/Ye3nrmQ4fJ iC7m4Lq5PncMItKQX8JoIDP4JgLZB+FqfV2sPZ03Sd/NQGl9v967F5LuSp9r5yEKGtRM Mxrg== X-Gm-Message-State: AHQUAuajJaBcYL8ypk/WY1sxSfMCcZJfYqQKJ3Jpw4hH60Q3qiiQKA1s DVkw9jxmH61qcalMpvry8IqTi8kKRSc= X-Google-Smtp-Source: AHgI3IbOq3x2KGH5benM6iEHvP3GkSRqWdbr4oGToR1RRnPBLiBW3UlAy2Ch8e2ShoZEaJqZlTgzHA== X-Received: by 2002:a0c:d968:: with SMTP id t37mr5078724qvj.195.1550026138244; Tue, 12 Feb 2019 18:48:58 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id m65sm14797024qkf.48.2019.02.12.18.48.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:48:57 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <2F1087EE-17F6-41E5-8BE5-FF782E136042@sn3rd.com> Date: Tue, 12 Feb 2019 21:48:56 -0500 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [MLS] mls wg milestones 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, 13 Feb 2019 02:49:01 -0000 All, Ben has reminded us that our current milestones need to be updated. = Instead of the chairs randomly picking some dates we=E2=80=99d like to = hear from you what you think about the following changes: 1. Merge the following because message protection ended up in the key = management draft: Initial working group document adopted for message protection Initial working group documents for architecture and key management to become Initial working group documents for architecture and key management = (includes message protection) and mark them as done. 2) Add the following because we=E2=80=99re planning to adopt a = federation draft and Emad said he can get an initial draft done before = Prague: Date: May 2019 Milestone: Initial working group document adopted for federation (key = establishment, authentication, and confidentiality services) 3) Push the following dates out: Add 9 month because because we=E2=80=99re planning on a pause: Sep 2019 Submit message protection protocol to IESG as Proposed = Standard Jun 2019 Submit key management protocol to IESG as Proposed Standard Add 6 months: Jan 2019 Submit architecture document to IESG as Informational spt= From nobody Wed Feb 13 22:05:37 2019 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 CB14C131139 for ; Wed, 13 Feb 2019 22:05:35 -0800 (PST) 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, 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=autonomia.digital 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 0L2Bl1SmKsCy for ; Wed, 13 Feb 2019 22:05:32 -0800 (PST) Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF0A131016 for ; Wed, 13 Feb 2019 22:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=autonomia.digital; h= date:from:to:cc:subject:message-id:mime-version:content-type; s= mail; bh=edryhGgUFxQQ6idUf5p4j0MZsvzAwnM0O3AGY3I0o6g=; b=VK/2749 71WOnobLflJ6uf/JQrbLeGexVAfyCrpI7wh/2KhJg+kGMOFILh/FftNHa2HJNCnP /viT1DhJ135mCaJyl79R9gByH5Ag+4rksGPhjv1UM51CJj9fiTHUXwUS0FRHvLJm swJTzOTI9KhbQ38qPozm1NS0Wyl4pWJpZmtM= Received: (qmail 16868 invoked by uid 0); 14 Feb 2019 05:57:09 -0000 Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 14 Feb 2019 05:57:09 -0000 Date: Thu, 14 Feb 2019 01:05:20 -0500 From: Sofia To: mls@ietf.org Cc: shivankaulsahib@gmail.com Message-ID: <20190214060520.GA3126@Sofias-MacBook-Pro.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [MLS] Short review of MLS drafts from the OTRv4 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: Thu, 14 Feb 2019 06:05:36 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, everyone! Hope you are good! First of all, thanks so much for all the efforts that this group has made! I attended the past interop meeting but it was hard to collaborate remotely ;) We reviewed both drafts of MLS (https://github.com/mlswg/mls-architecture/b= lob/master/draft-ietf-mls-architecture.md and https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protoc= ol.md) in little detail, as they seem to be an ongoing work. The first thing that stood out is that some formatting and restructure migh= t be needed. I really like these two issues: https://github.com/mlswg/mls-protoc= ol/issues/110 and https://github.com/mlswg/mls-protocol/issues/108, as they show that it = will be nice (and maybe it will make easier for readers) to have a little bit of more structure. Some improvements on the markdown syntax might be good as w= ell ;) We also think that maybe more formal definitions of the security properties provided by MLS might be needed. Specifically, for 'forward secrecy', for example, the definition given on this paper might be in place: https://eprint.iacr.org/2000/014.pdf We are also unsure on the 'type' of forward secrecy provided. The Signal's = X3DH protocol, for example, provides a forward secrecy between strong and weak. = We are unsure if the way the Delivery Service, as defined in MLS, when providi= ng the authentication keys and initial keying material, achieves which type of for= ward secrecy. But, of course, this can be a misunderstood from our side. At some points, it might be nice to give recommendations in the spec: "It is left to the application to determine the interval of time between Up= date messages.". It is maybe good to provide an example of this time frame. It is also unclear at some points the notation used for the Diffie-Hellman = or Elliptic Curve parameters. Related to this, is unsure if this protocol takes into account the cofactor issues. We are unsure if there is a will of including deniability in this. On some points it states: """ [[ OPEN ISSUE: Signatures under the identity keys, while simple, have the side-effect of preclude deniability. We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a pairwise channel that provides deniability for the message contents.]] """ """ Non-Repudiation and Deniability As described in {{client-compromise}}, MLS provides data origin authenticat= ion within a group, such that one group member cannot send a message that appea= rs to be from another group member. Additionally, some services require that a recipient be able to prove to the messaging service that a message was sent= by a given Client, in order to report abuse. MLS supports both of these use ca= ses. In some deployments, these services are provided by mechanisms which allow = the receiver to prove a message's origin to a third party (this if often called "non-repudiation"), but it should also be possible to operate MLS in a "den= iable" mode where such proof is not possible. [[OPEN ISSUE: Exactly how to supply = this is still a protocol question.]] """ If this is something that wants to be included, we will be very happy to an= swer questions. Nevertheless, there is no way, currently, to achieve the same de= niability properties OTRv4 has in a group setting. We are also unsure of the difference between deniability and non-repudation. This is very high-level review. We are very sorry if we misunderstood somet= hing. We will be very happy to further check issues, if wanted. We can also help = on trying to give more structure, but I'm unsure where this is done: on the github instance? Please, let us know where we can help. Hope this is helpful! -- Sof=EDa Celi (aka cherenkov) @claucece / @cherenkov_d Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE73QaX1aS5W8U9iQ8OZJhRPidmW8FAlxlBRwACgkQOZJhRPid mW/qig/+OpcqA7aeObU5NR5GQ7VRPcXgnXGPZUad7w4jiDjXR3ZPX0s6VGbUvTHM cGXfae9ce+0jO+QOXcF5fKW52OuPfYP13ijRsV6nED06byC/UFqLx9mxRo1jLlU7 y1w3l28MZ4GlhEiU4CcQgHG12U8khuZ+UjBcU1w2X0A6PBebePJI0BzyMO8p9AJ/ OrB/ZkuV70KMMancxXOnndQSgR5yMcpKacbjEAuAUfSetCA7M2xcmoJMF87odtJO e/ahGx954jPaBw9CVD/ojWqg/nwaHzotvLnAKFh196sT80zvQ+JjNW7EOYNYE+6z FTUW9/abnDsGWcHDP+xDJlSEUdcUAfP0B4ajwiazMn6EHvU/jmRMr6vo1sgOzdcD 7GJXn4YTalYVaSkdTXdZKkUiYqt8rlTZhSNCmSxpMzAeOQJHXAJpe8khApu4Hi/c aofM1Qn0QCtjhqOFpRbzCSp+4ZyEYEyOLxnB38+jQ2zoBYLWmEAZd4jdxdIGpvb9 d8df2No0ysEsQ9x6gCJiSAKZf0ZjXRIJDEg7zK1o9JQiOUDg2UMeRgyXFjbwoacO A7A1NUpTd9ArPuag6nMM0UVoy69IT0O0eRQGrqoNtIV2Bt95UQF84ZO2b/AvDQ8m JfbdQHKEIF4HLEXnJqKW7frJTJQSwPIknaGveMnSC5rgTk5heyc= =jb3E -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From nobody Thu Feb 14 01:17:46 2019 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 1082713115A for ; Thu, 14 Feb 2019 01:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Xroz3i04oBDk for ; Thu, 14 Feb 2019 01:17:42 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA42513115C for ; Thu, 14 Feb 2019 01:17:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,368,1544482800"; d="scan'208";a="296148603" Received: from wifi-pro-82-097.paris.inria.fr ([128.93.82.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2019 10:17:29 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Benjamin Beurdouche In-Reply-To: <20190214060520.GA3126@Sofias-MacBook-Pro.local> Date: Thu, 14 Feb 2019 10:17:27 +0100 Cc: ML Messaging Layer Security , shivankaulsahib@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: <7D4524B0-67E4-4AC7-9B61-804527A6BB3E@inria.fr> References: <20190214060520.GA3126@Sofias-MacBook-Pro.local> To: =?utf-8?Q?Sof=C3=ADa_Celi?= X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] Short review of MLS drafts from the OTRv4 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: Thu, 14 Feb 2019 09:17:45 -0000 Hi Sof=C3=ADa, Thanks a lot for the review, this is always very helpful ! (see inlined) > On Feb 14, 2019, at 7:05 AM, Sofia wrote: >=20 > Hi, everyone! >=20 > Hope you are good! >=20 > First of all, thanks so much for all the efforts that this group has = made! I > attended the past interop meeting but it was hard to collaborate = remotely ;) >=20 > We reviewed both drafts of MLS = (https://github.com/mlswg/mls-architecture/blob/master/draft-ietf-mls-arch= itecture.md > and = https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.= md) > in little detail, as they seem to be an ongoing work. >=20 > The first thing that stood out is that some formatting and restructure = might be > needed. I really like these two issues: = https://github.com/mlswg/mls-protocol/issues/110 > and https://github.com/mlswg/mls-protocol/issues/108, as they show = that it will > be nice (and maybe it will make easier for readers) to have a little = bit of > more structure. Some improvements on the markdown syntax might be good = as well ;) I think we completely agree one this. In general it is worth to note = that I believe the WG generally understands quite well the protocol compared to the = description written down in the two documents, but this is no excuse especially for people = joining now and for future readers of the document. All editors will ensure that the = text makes considerable progress in terms of readability and level of details. This = quite difficult to achieve in practice but we will spend a lot of time on it=E2=80=A6 :)=20= > We also think that maybe more formal definitions of the security = properties > provided by MLS might be needed. Specifically, for 'forward secrecy', = for > example, the definition given on this paper might be in place: > https://eprint.iacr.org/2000/014.pdf > We are also unsure on the 'type' of forward secrecy provided. The = Signal's X3DH > protocol, for example, provides a forward secrecy between strong and = weak. We > are unsure if the way the Delivery Service, as defined in MLS, when = providing the > authentication keys and initial keying material, achieves which type = of forward > secrecy. But, of course, this can be a misunderstood from our side. I believe that the mechanism used to fetch ephemeral init keys in MLS is = very similar to the one you would use to fetch a "pre-key" for Signal. The = difference is how the keys are mixed in the group secret which will provide = specific guarantees. I opened https://github.com/mlswg/mls-architecture/issues/48 > At some points, it might be nice to give recommendations in the spec: > "It is left to the application to determine the interval of time = between Update > messages.". It is maybe good to provide an example of this time frame. At IETF last summer we agreed that we need to provide example = recommandations regarding key-update frequency in the specification but I believe that = we probably will wait a bit longer to have real world measurements before we can do = that as it depends on the use-case (frequency of each group operation) and the = number of members in the group, hence is not super easy to simulate. https://github.com/mlswg/mls-architecture/issues/49 > It is also unclear at some points the notation used for the = Diffie-Hellman or > Elliptic Curve parameters. Related to this, is unsure if this protocol = takes > into account the cofactor issues. Thank you for reminding us, we will look into this. https://github.com/mlswg/mls-protocol/issues/118 > We are unsure if there is a will of including deniability in this. On = some > points it states: >=20 > """ > [[ OPEN ISSUE: Signatures under the identity keys, while simple, have > the side-effect of preclude deniability. We may wish to allow other > options, such as (ii) a key chained off of the identity key, or = (iii) > some other key obtained through a different manner, such as a > pairwise channel that provides deniability for the message > contents.]] > """ >=20 > """ > Non-Repudiation and Deniability > As described in {{client-compromise}}, MLS provides data origin = authentication > within a group, such that one group member cannot send a message that = appears to > be from another group member. Additionally, some services require that = a > recipient be able to prove to the messaging service that a message was = sent by > a given Client, in order to report abuse. MLS supports both of these = use cases. > In some deployments, these services are provided by mechanisms which = allow the > receiver to prove a message's origin to a third party (this if often = called > "non-repudiation"), but it should also be possible to operate MLS in a = "deniable" > mode where such proof is not possible. [[OPEN ISSUE: Exactly how to = supply this > is still a protocol question.]] > """ >=20 > If this is something that wants to be included, we will be very happy = to answer > questions. Nevertheless, there is no way, currently, to achieve the = same deniability > properties OTRv4 has in a group setting. There was limited discussion in the working group and I believe = deniability is not in the charter. That said, I believe that our goal, at least mine, is to make sure that = we can provide deniability optionally on top of the current design, typically by = sharing the signature public keys over pairwise deniable channels at the cost of linearity. = This is something you might want to ask to the list or the chairs. In the mean time I = added an issue. https://github.com/mlswg/mls-architecture/issues/50 > We are also unsure of the difference between deniability and = non-repudation. >=20 > This is very high-level review. We are very sorry if we misunderstood = something. > We will be very happy to further check issues, if wanted. We can also = help on > trying to give more structure, but I'm unsure where this is done: on = the > github instance? Thanks a lot for the offer, I believe the best way to currently for the = document is to keep submit issues in the Github or PRs for limited changes so that we = can make these better. On the protocol side there are many things to look at such = as federation, user initiated add or eventually ephemeral signatures, and I am sure = help will be very appreciated as this review was... : ) Best, Benjamin >=20 > Please, let us know where we can help. >=20 > Hope this is helpful! > -- > Sof=C3=ADa Celi (aka cherenkov) > @claucece / @cherenkov_d > Cryptographic research and implementation at CAD: = https://autonomia.digital/ > EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Thu Feb 14 01:24:17 2019 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 62419131056 for ; Thu, 14 Feb 2019 01:24:16 -0800 (PST) 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 IPfPShC3IXpk for ; Thu, 14 Feb 2019 01:24:13 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 553F612F1A2 for ; Thu, 14 Feb 2019 01:24:13 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id d9so4388682edh.12 for ; Thu, 14 Feb 2019 01:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=txaOzCleYFUH8TyQn7mTjyvfYkAu12d5cOxSDH8yUkw=; b=f/OfuZuChPWig7ukwZRh4+WA9+Mli8fBOnWbSq9mFZmxdCKIQAnwFUuxG3zNapHiKY ggoiONRZobBDa/7vq47ELo4HJC5bBUSF4DqX6R+LkT4s1ub2wLIhQUHSMNxszJJxrd5A 7YTejifaBW9bLelHBJlXHyON6i+7GvTH4fB78nAsgvo2g2W9QxaF5GfGNwmRREytEOIs Y8L4Xvg8h9HaJg29RP435Wxtx7TaTbdQ6858V3wme8las93AiCN8YdimMDRIN+CiC+VY ovkcm2PY+yPKIhFplOvLQ3oJE9stFhTy0zcjEi27RQ5Zt0ugTh4hwpWvyI8B3jGVsc1f Cy5w== 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=txaOzCleYFUH8TyQn7mTjyvfYkAu12d5cOxSDH8yUkw=; b=t0ShSXk4cp+2zj1z+MCaKtrHv4E1xcExe+p/O7FNrZxSTw/J/iNf9o4wRI4YdtBZxi W1YGvn1d7vmqn3TjlzDTPlkYOJJFhQI2WBEDu1LzXSPOmZ2/y7PHdRutCOZF2br/IcUs PwHKCzs3o+ZLecQsNyEDpgxkTjaVhCpRC1CSwDfSSzMwuXwEYyj3T/kireM64iVj/6MH IkIHQ1I69RqAPdjFOhxlaFC9tyhR7Z6lwwjSHOEo2WH9i8KBAKLn+Jz4eAnuk0rMk3VJ IX3vAA16PQXqg7cVazSOQLJ9nKxCxImohcENhPGC1VQ+i7tEkV9lBWzXC0v2od0zvhtt Axsg== X-Gm-Message-State: AHQUAuZkT35bH0G1Fliv1ZllugiD1sF5kn8GetaQfV6XS9+B/zQ5aQ3N 3XIizms1KN1P6U0FHsBAqi3ufk1MWTA= X-Google-Smtp-Source: AHgI3IbpmyBo3XMP+gq0VX/My5sAVntL9m12kamyV2+CZ9SxOW1NWnXXJglN5jrePhHXm0VwsZZHDQ== X-Received: by 2002:a17:906:a3c3:: with SMTP id ca3mr2039048ejb.25.1550136251291; Thu, 14 Feb 2019 01:24:11 -0800 (PST) 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 i50sm525419eda.65.2019.02.14.01.24.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 01:24:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Raphael Robert In-Reply-To: <20190214060520.GA3126@Sofias-MacBook-Pro.local> Date: Thu, 14 Feb 2019 10:24:09 +0100 Cc: shivankaulsahib@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190214060520.GA3126@Sofias-MacBook-Pro.local> To: Sofia , mls@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] Short review of MLS drafts from the OTRv4 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: Thu, 14 Feb 2019 09:24:16 -0000 Hi Sofia, Thanks for the review! I=E2=80=99ll focus on your questions regarding deniability for now.=20 > We are unsure if there is a will of including deniability in this. On = some > points it states: >=20 > """ > [[ OPEN ISSUE: Signatures under the identity keys, while simple, have > the side-effect of preclude deniability. We may wish to allow other > options, such as (ii) a key chained off of the identity key, or = (iii) > some other key obtained through a different manner, such as a > pairwise channel that provides deniability for the message > contents.]] > """ >=20 > """ > Non-Repudiation and Deniability > As described in {{client-compromise}}, MLS provides data origin = authentication > within a group, such that one group member cannot send a message that = appears to > be from another group member. Additionally, some services require that = a > recipient be able to prove to the messaging service that a message was = sent by > a given Client, in order to report abuse. MLS supports both of these = use cases. > In some deployments, these services are provided by mechanisms which = allow the > receiver to prove a message's origin to a third party (this if often = called > "non-repudiation"), but it should also be possible to operate MLS in a = "deniable" > mode where such proof is not possible. [[OPEN ISSUE: Exactly how to = supply this > is still a protocol question.]] > """ >=20 > If this is something that wants to be included, we will be very happy = to answer > questions. Nevertheless, there is no way, currently, to achieve the = same deniability > properties OTRv4 has in a group setting. >=20 > We are also unsure of the difference between deniability and = non-repudation. The will is definitely there to allow deniability in MLS. However since = that property is quite divisive, the current status quo is that it = should be optional. In practical terms, *some* deniability could be achieved by distributing = the message signing keys through a deniable channel (similar to how the = sender keys concept works). In a way this puts deniability =E2=80=9Cout = of scope=E2=80=9D in the sense that the distribution of signing keys is = not in the charter. To my knowledge, there is no other substantial = proposal on how deniability could be achieved, but it would be great to = hear more from you on that subject! Raphael From nobody Sat Feb 16 19:36:14 2019 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 E4E33124BF6 for ; Sat, 16 Feb 2019 19:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uGbM-7Se0kiU for ; Sat, 16 Feb 2019 19:36:10 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 23FEE1228B7 for ; Sat, 16 Feb 2019 19:36:10 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id m1so23060249otf.5 for ; Sat, 16 Feb 2019 19:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E6LYKJjaH76SWsPy6SBk6qFTClxjcX5lWnvEcLbveYY=; b=VOQsrDHNTIeHC8CKgN0G9zo6awRNzkI9+Zf2iTQNQTJGRiBXJmBm00ow29i2wno3c8 tcfNo4I5IB99YHNmK8HZ4VVVJTm0Za0ekVzaS5GKuR90e/ADmHhpWdAVrYNPsvJKUX2b CNDcJtBTImdRyUJtTGO2RBaNmROZmrao3l8PJ81JT3gnxzGT98FJ7huAl25hKc9avoV1 d9WjijUDUVJuEZ2zeuikI8fj5f6ueaum1Owcq+ig8hRuaG0j+/Ho65hlBtfvlChDPjVK yIx24BHmp2FL+k69FNKmnhTJ0mWUgOnNVlIj4v4N3OabaG1AMiNWuLMEXP0GTuxrA/pH BMTQ== 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=E6LYKJjaH76SWsPy6SBk6qFTClxjcX5lWnvEcLbveYY=; b=SckonPPKhpTVWVpOYe+a9xZV0XjDbjdfn+podwiYDya8ynkKSPucoznTxJGUfp2nr2 mS9QO8m/I5ZraJtc6oB82OC/6cbGerrNiW7SvDn/DYOSXloANsy1N1ddqyseHb+y800J N7vmN8GgDElRisxDDgYo8c1t0Nz9TawZVbUvA7xAeVUmiR4SD+opYQksU4pJkaDdiS5F 9IwwphPX5IJg9+USHcDDCIlxCSZ+ruL0qX80DnaGoZBAxeWNAnpKzMoKfuLnbFlhB81i MPa4LKCHd9r+BefZbiocrsy3QWDN+XV00EGmt0JxUE8synzXt99y0dgTf87BsasvZU4D /1ng== X-Gm-Message-State: AHQUAuYJSMEuT9g5s+Hcsyxbw6VOeFR4OHdwLx4k7Pl350/k3JEZCqLN h0NMasp7zUqgQs746A3LaDum3ZvjEYVsKoOzrzuCbHL/E20= X-Google-Smtp-Source: AHgI3IbruBJey6navqzjEYLSmbkN8C1CNdJVbnk+99eJXozcdbZIyeTEDlhuzjwiOVnndsvHvJt8MIc42YMzsfOsDnk= X-Received: by 2002:a9d:3f34:: with SMTP id m49mr10079141otc.23.1550374568654; Sat, 16 Feb 2019 19:36:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Sat, 16 Feb 2019 22:35:56 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000006f0f7905820eb5a6" Archived-At: Subject: Re: [MLS] February MLS interop event X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 03:36:13 -0000 --0000000000006f0f7905820eb5a6 Content-Type: text/plain; charset="UTF-8" Update: We'll aim for a check-in next Wednesdsay, Feb 20, at 16:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?msg=MLS+Interop&iso=20190220T11&p1=263&ah=1 I'll send out Webex coordinates in the MLS Implementors Wire channel. On Fri, Feb 8, 2019 at 12:15 PM Richard Barnes wrote: > Summary of conclusions from this call: > > - Folks weren't quite ready to do live interop > - In general, we should do interop async, via test vectors, and use calls > to debrief / discuss issues > - Next interop check-in targeted for Feb 18 > - Still targeting -03 test vectors in mls-implementations repo > - ... with #115 to fix application key schedule > - A couple of actual test changes would be useful > - Tests for the resolution algorithm > - Tests for the key schedule (decoupled from a session) > > Please indicate your availability for the next check-in in this Doodle: > > https://doodle.com/poll/7b7hurwg268e86a9 > > > On Sat, Jan 26, 2019 at 1:25 PM Richard Barnes wrote: > >> OK, based on the Doodle results, let's shoot for 16:00-19:00 UTC >> >> >> https://www.timeanddate.com/worldclock/fixedtime.html?msg=MLS+Interop&iso=20190208T16&p1=1440&ah=3 >> >> We can use the following Webex bridge: >> >> Join from a video conferencing system or application >> Meeting link: https://cisco.webex.com/meet/richbarn >> Dial: richbarn@cisco.webex.com >> Join using Microsoft Skype for Business: richbarn.cisco@lync.webex.com >> Toll Free: +1-866-432-9903 >> Toll: +1-408-525-6800 >> Access Code: 201006237 >> >> If you're interested in joining, please make sure you're in the MLS >> Implementors Wire channel, which we'll use for text-based coordination. >> >> >> https://app.wire.com/join/?key=3tL-NJOoCKZlDXNU1H2c&code=kZOc0ujnDQ9Tq98tLfSt >> >> >> On Tue, Jan 15, 2019 at 8:01 PM Richard Barnes wrote: >> >>> Hey all, >>> >>> A few of us who are writing code for MLS are thinking of having an >>> informal interop event in early February. If you'd like to participate, >>> please fill out this Doodle to help pick dates: >>> >>> https://doodle.com/poll/2yd3b2eydchis82b#table >>> >>> The interop target will be draft-ietf-mls-protocol-03. We will try to >>> get everyone passing a common set of test vectors, covering, e.g.: >>> >>> - Tree math >>> - Derive-Key-Pair >>> - Message parsing and serialization >>> - Fully crypto calculations for a simple scenario >>> >>> This will be a remote meeting / teleconference. I will send out Webex >>> details once we've picked a date/time. >>> >>> --Richard >>> >>> --0000000000006f0f7905820eb5a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Update: We'll aim for a check-in= next Wednesdsay, Feb 20, at 16:00 UTC


I'll send out Webex coor= dinates in the MLS Implementors Wire channel.

On Fri, Feb 8,= 2019 at 12:15 PM Richard Barnes <rlb@ipv.sx> wrote:
Summary of conclusions from this call:

- Fo= lks weren't quite ready to do live interop
- In general, we s= hould do interop async, via test vectors, and use calls to debrief / discus= s issues
- Next interop check-in targeted for Feb 18
= =C2=A0 - Still targeting -03 test vectors in mls-implementations repo
=
=C2=A0 - ... with #115 to fix application key schedule
- A c= ouple of actual test changes would be useful
=C2=A0 - Tests f= or the resolution algorithm
=C2=A0 - Tests for the key schedule (= decoupled from a session)

Please indicate your= availability for the next check-in in this Doodle:

ht= tps://doodle.com/poll/7b7hurwg268e86a9

=
On Sat= , Jan 26, 2019 at 1:25 PM Richard Barnes <rlb@ipv.sx> wrote:
OK, based on the Doodle results, let's = shoot for 16:00-19:00 UTC


We can use the following We= bex bridge:

Join from a video conferencing system = or application
Meeting link: https://cisco.webex.com/meet/richbarn
Dial:= richbarn@cis= co.webex.com
Join using Microsoft Skype for Business: richbarn.cisco@lync.we= bex.com
Toll Free: +1-866-432-9903
Toll: +1-408-525-6800
Acces= s Code: 201006237

If you're interested in join= ing, please make sure you're in the MLS Implementors Wire channel, whic= h we'll use for text-based coordination.



On Tue, Jan 15, 2019 at 8:01 PM Richard Barnes <= ;rlb@ipv.sx> wrote:
Hey all,

=
A few of us who are writing code for MLS are thinking of having an inf= ormal interop event in early February.=C2=A0 If you'd like to participa= te, please fill out this Doodle to help pick dates:

https://doodle.com/poll/2yd3b2eydchis82b#table

= The interop target will be draft-ietf-mls-protocol-03.=C2=A0 We will try to= get everyone passing a common set of test vectors, covering, e.g.:
- Tree math
- Derive-Key-Pair
- Message= parsing and serialization
- Fully crypto calculations for a = simple scenario

This will be a remote meeting= / teleconference.=C2=A0 I will send out Webex details once we've picke= d a date/time.

--Richard

<= /div>
--0000000000006f0f7905820eb5a6-- From nobody Mon Feb 18 14:22:47 2019 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 95E60131055 for ; Mon, 18 Feb 2019 14:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LgYBDOebrt0F for ; Mon, 18 Feb 2019 14:22:43 -0800 (PST) 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 1C63B13104B for ; Mon, 18 Feb 2019 14:22:43 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id 98so31028865oty.1 for ; Mon, 18 Feb 2019 14:22:43 -0800 (PST) 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=eKLn4117ZcVbl/v6X57F0u18NgwWRD4ctGa4GXFX82I=; b=dEP0dz7UnoMOCs0fwPNFPEnstmcbrU8HoEP7D7RC10KkxMYvNCRiuoIzLAncKFYu1g l2ecOoZP1Y+i6EORVVjynSD5nsGzz4qprH7Rfwi9FGUM/Ax2R96W1hKVGYCk8LPfQho6 arlgltPLJXdNjrnJz5bIG3BdTIB1icvjWeex/FX15bI23VXCNDrgOgqKYWvcrLYDyqzm wMc4C81D1zYS7vS7a5F3WTTlkcgwc0zqBTtJU1BSZY5I2EREVwfMEWV8t1/UuLPdYG24 qedTP0VAJyNYoNMRUxkuTdFxjIJudV0+cEYdkHM0Y6K6/kAH5IZhGqUCMliXTlKuRSVM Uv3g== 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=eKLn4117ZcVbl/v6X57F0u18NgwWRD4ctGa4GXFX82I=; b=Igw9OKU7F4GEEfTg897YGLSVb0mU2mOMfiwWBqrFYvlFFcWOBj8gdnAoJMyx9XRivd VaUxzh+VEfrICYjjLaFEujBkbkpxfbxkQXmDmFpQawYGnRbVT0ehyDKsHgbpFmhOAehM ZYwLZs61Abp6W/3Pm59sXgWzjYfn76m6iheKQYzMKGnYHn/8JFrtog2w8hb8/6sVfGIr IzOBXhRT9Ns6czC+eMIXqSGKHwrTNBefTW0AvPNvgL5mRoTBwsIiipDZcOuJPiWFnBd7 v2C8I+EjYI3h1XCyqANHMroQqq5IAphQZIu15E5bT4aPQ5Lxo/aGpL6XFDylCJIP41K+ LrpA== X-Gm-Message-State: AHQUAuYW8aIXWeQBuk4/Yr2iTNfAa7sj3O0Ew4fecNHZMZyMHF4jw5Wv 9YtIs/2vbJkimA91UY7sybOLmmC/eKrms4DiiSsmzp3E2Oc= X-Google-Smtp-Source: AHgI3IaNOAEtY2SUJST96y9sBoG1PavXMfpLmmaLkQNJJK0vGsJwamwmNLyZazsEyFNEY7eOs6P063Zp0/WrS7BC9CQ= X-Received: by 2002:a9d:6347:: with SMTP id y7mr15081724otk.331.1550528561753; Mon, 18 Feb 2019 14:22:41 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 18 Feb 2019 17:22:28 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000023452d0582329071" Archived-At: Subject: [MLS] Authentication vulnerability in mls-03; better framing to the rescue 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, 18 Feb 2019 22:22:45 -0000 --00000000000023452d0582329071 Content-Type: text/plain; charset="UTF-8" Hey all, Over the weekend, I drafted a proposed common framing layer that would entail some changes to how authentication is done. To make sure this wasn't harmful, I build some Tamarin models this morning of the two-party scenario in -03 and my proposed -04. The bad news is that Tamarin pointed out a weakness in -03; the good news is that the proposed -04 structure fixes it, at least in the two-party case. The vulnerability in -03 unfolds as follows [2]: - Client A posts an InitKey - Client B downloads the InitKey and constructs a Welcome and Add messages - Attacker intercepts Welcome and Add - Attacker creates a new Welcome message with his own InitKey, and replaces the MAC on the Add message with one derived from his InitKey - As a result: - Client B will encrypt messages to the attacker thinking they are encrypting to Client A - Client B will never successfully receive a message, because the attacker doesn't have Client A's private key, and Client A doesn't have the encryption key. This vulnerability arises because the Welcome message is too loosely coupled to the Add message, allowing the init_key to be sent by someone other than the sender of the Add. There are two approaches to improving this binding that seem to solve the problem (as verified by Tamarin): a) Moving the confirmation MAC under the message signature [3] b) Including a hash of the WelcomeInfo in the Add message [4] (The former prevents the attacker from replacing the MAC; the latter the Welcome message.) Option (a) was already included in PR#120; in addition to fixing this problem, it makes for better parallelism between Application and Handshake messages. Option (b) also seems worth doing, since it gets the Welcome into the transcript, and allows other participants to verify that it was correct. I've updated PR#120 to also include (b). If folks have other thoughts on that PR or this analysis, they would be helpful. Likewise, if anyone wanted to take the Tamarin models linked below and extend them to larger cases (3 or 4 parties shouldn't be crazy), that would help give more confidence in this change. Thanks, --Richard [1] https://github.com/mlswg/mls-protocol/pull/120 [2] https://github.com/bifurcation/tamarin-ake/blob/master/mls-03.spthy [3] https://github.com/bifurcation/tamarin-ake/blob/master/mls-04a.spthy [4] https://github.com/bifurcation/tamarin-ake/blob/master/mls-04b.spthy --00000000000023452d0582329071 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
He= y all,

Over the weekend, I drafted a proposed comm= on framing layer that would entail some changes to how authentication is do= ne.=C2=A0 To make sure this wasn't harmful, I build some Tamarin models= this morning of the two-party scenario in -03 and my proposed -04.=C2=A0 T= he bad news is that Tamarin pointed out a weakness in -03; the good news is= that the proposed -04 structure fixes it, at least in the two-party case.<= /div>

The vulnerability in -03 unfolds as follows [2]:

- Client A posts an InitKey
- Client B do= wnloads the InitKey and constructs a Welcome and Add messages
- A= ttacker intercepts Welcome and Add
- Attacker creates a new Welco= me message with his own InitKey, and replaces the MAC on the Add message wi= th one derived from his InitKey
- As a result:
=C2=A0 - Client B will encrypt messages to the attacker thinking they are= encrypting to Client A
=C2=A0 - Client B will never successfully= receive a message, because the attacker doesn't have Client A's pr= ivate key, and Client A doesn't have the encryption key.
=
This vulnerability arises because the Welco= me message is too loosely coupled to the Add message, allowing the init_key= to be sent by someone other than the sender of the Add.=C2=A0 There are tw= o approaches to improving this binding that seem to solve the problem (as v= erified by Tamarin):

a) Moving the confirmation MA= C under the message signature [3]
b) Including a hash of the = WelcomeInfo in the Add message [4]

(The former= prevents the attacker from replacing the MAC; the latter the Welcome messa= ge.) Option (a) was already included in PR#120; in addition to fixing this = problem, it makes for better parallelism between Application and Handshake = messages.=C2=A0 Option (b) also seems worth doing, since it gets the Welcom= e into the transcript, and allows other participants to verify that it was = correct.

I've updated PR#120 to also include (b).=C2= =A0 If folks have other thoughts on that PR or this analysis, they would be= helpful. Likewise, if anyone wanted to take the Tamarin models linked belo= w and extend them to larger cases (3 or 4 parties shouldn't be crazy), = that would help give more confidence in this change.

Thanks,
--Richard

--00000000000023452d0582329071-- From nobody Mon Feb 18 14:27:57 2019 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 A35CF131054 for ; Mon, 18 Feb 2019 14:27:56 -0800 (PST) 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, 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=autonomia.digital 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 xU1pZr7HrVtn for ; Mon, 18 Feb 2019 14:27:54 -0800 (PST) Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1001274D0 for ; Mon, 18 Feb 2019 14:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=autonomia.digital; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mail; bh=yYrKRU2DvgjxIFe69j6dK26IRL 9qDLpPjV2TSoKNwtc=; b=kQGTG5BmMAHHz7b2qYLqHSGG1sl8cQ4EE+uKOQO2yW FSaUJpAxFyOYGj+iqEjaSR+izDdYmYr6D/SYa08+xkoPO3rpLB8wPHiyRBinyo1k 9jinvE4J+vdH4wTi6OAkBfrMtzpXqxI/bx73YejknYbpgwl452vG36++2iD+S3y4 0= Received: (qmail 2731 invoked by uid 0); 18 Feb 2019 22:19:18 -0000 Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 18 Feb 2019 22:19:18 -0000 Date: Mon, 18 Feb 2019 17:27:42 -0500 From: Sofia To: Raphael Robert Cc: mls@ietf.org, shivankaulsahib@gmail.com Message-ID: <20190218222741.GA11370@Sofias-MacBook-Pro.local> References: <20190214060520.GA3126@Sofias-MacBook-Pro.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: User-Agent: Whatever/1.0 Archived-At: Subject: Re: [MLS] Short review of MLS drafts from the OTRv4 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, 18 Feb 2019 22:27:57 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Raphel et al, > The will is definitely there to allow deniability in MLS. However since t= hat > property is quite divisive, the current status quo is that it should be o= ptional. > In practical terms, *some* deniability could be achieved by distributing = the > message signing keys through a deniable channel (similar to how the sende= r keys > concept works). In a way this puts deniability =E2=80=9Cout of scope=E2= =80=9D in the sense > that the distribution of signing keys is not in the charter. To my knowle= dge, > there is no other substantial proposal on how deniability could be achiev= ed, > but it would be great to hear more from you on that subject! Mmm... are those MAC keys for message authentication or something else? Well, it depends in the kind of deniability you want to attain and how "str= ong" it will be. I've been re-reading some of the papers of the deniability prop= erties for a group chat setting. I'll send the ideas and concepts :) I hope that is useful. Maybe that can be an starting point for a discussion.. Thanks! -- Sof=C3=ADa Celi (aka cherenkov) @claucece / @cherenkov_d Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE73QaX1aS5W8U9iQ8OZJhRPidmW8FAlxrMVkACgkQOZJhRPid mW+7CQ//d7jwdIJIaON6+iYPxracpt1UY2C8zHjZaiSL22XTIePvOirUXv3YCoBb pc0ZTlDuhzw7TzSodC0ZTeSlaQjjR7vb9FWgGaLD2okX6bmR4Jt+ypRFjH5Niq9t pVpCMSZ6VAldSKIWdvR9kqXwslY5eXfYmsHv8FqYD7gz7wLyux+chg7W63ND8EZ3 inGhdPMn8ljCkcxcMgKg44iXOU7pNvIUqUFOvFnnLOcFIzapg/AOSUibXfg2hM8I Na7MbGh7ZiUGbLgW9+Gp9T0GHbxU+Fu5suachVl6Jjjn8XzywVOyxcEf9hPNLIw6 MIMUWsL+IJ4QrKDjaDZtMndAGxacXZz2NUbQGUb4tjuGSCfr5kvO74poTn4BClsS bPBNCRsjOarWMu8bzw6jppWUhmU0APVJzCXj7yov8oQ06CFPSt1ZF2yiAn08WacV MpS4tkvlINc13up4HFhoc4XjD4TFgO+9kjIZcYN/7Nw0wPCaYVz4PTWW1Nk3Bjzv sFWRrZeXy+/o+F+5b/zJJV+KrJPzXBFOVKshuYid6Jb31NYgbyF7CzWv0UnDGTmJ /ShGkJp1ZtdefGMoJX5Vj6HG/I+zDQJjBat/c7SZWRjmA+HhL6Mgxnz2uijfG/yI GMMKiiE44osNnJh5khzs5l58vHDGtwY3qbnVwsvcjO/jeF1xwI4= =+7FZ -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From nobody Mon Feb 18 14:34:21 2019 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 9DC44130E90 for ; Mon, 18 Feb 2019 14:34:19 -0800 (PST) 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, 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=autonomia.digital 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 9kgv4emYrh5k for ; Mon, 18 Feb 2019 14:34:17 -0800 (PST) Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35B5131055 for ; Mon, 18 Feb 2019 14:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=autonomia.digital; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mail; bh=Vxc3e8mMoxfb8eWzkjnLk33Y4n 5NGb/3xZT/QKuhTCc=; b=hSSZ0W9M8EAROz2zGzc6mqKg63AgRac3h5uXGdwfGp U0DnA7/EeK2zk/M1rUQ9wrBJtg8cdGf1EUsMdhjMOHRNvZf/HE+zkhNTQE1kl5r6 2Vy39HqxGRuYaqzw7BTIUmLKjm/Zwjmq4gNFMUJ7hFqxw+fwU0LdWXZCkCF5wPKb s= Received: (qmail 3098 invoked by uid 0); 18 Feb 2019 22:25:41 -0000 Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 18 Feb 2019 22:25:41 -0000 Date: Mon, 18 Feb 2019 17:34:05 -0500 From: =?iso-8859-1?Q?Sof=EDa?= Celi To: Benjamin Beurdouche Cc: ML Messaging Layer Security , shivankaulsahib@gmail.com Message-ID: <20190218223405.GB11370@Sofias-MacBook-Pro.local> References: <20190214060520.GA3126@Sofias-MacBook-Pro.local> <7D4524B0-67E4-4AC7-9B61-804527A6BB3E@inria.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline In-Reply-To: <7D4524B0-67E4-4AC7-9B61-804527A6BB3E@inria.fr> User-Agent: Whatever/1.0 Archived-At: Subject: Re: [MLS] Short review of MLS drafts from the OTRv4 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, 18 Feb 2019 22:34:20 -0000 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Benjamin et al, > Thanks a lot for the review, this is always very helpful ! > (see inlined) Thanks you all! > > We reviewed both drafts of MLS (https://github.com/mlswg/mls-architectu= re/blob/master/draft-ietf-mls-architecture.md > > and https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-pr= otocol.md) > > in little detail, as they seem to be an ongoing work. > > > > The first thing that stood out is that some formatting and restructure = might be > > needed. I really like these two issues: https://github.com/mlswg/mls-pr= otocol/issues/110 > > and https://github.com/mlswg/mls-protocol/issues/108, as they show that= it will > > be nice (and maybe it will make easier for readers) to have a little bi= t of > > more structure. Some improvements on the markdown syntax might be good = as well ;) > > I think we completely agree one this. In general it is worth to note that= I believe the WG > generally understands quite well the protocol compared to the description= written > down in the two documents, but this is no excuse especially for people jo= ining now > and for future readers of the document. All editors will ensure that the = text makes > considerable progress in terms of readability and level of details. This = quite difficult > to achieve in practice but we will spend a lot of time on it=E2=80=A6 :) Yeah, I understood that as well. No worries. I can try to help on that as w= ell. :) > > We also think that maybe more formal definitions of the security proper= ties > > provided by MLS might be needed. Specifically, for 'forward secrecy', f= or > > example, the definition given on this paper might be in place: > > https://eprint.iacr.org/2000/014.pdf > > We are also unsure on the 'type' of forward secrecy provided. The Signa= l's X3DH > > protocol, for example, provides a forward secrecy between strong and we= ak. We > > are unsure if the way the Delivery Service, as defined in MLS, when pro= viding the > > authentication keys and initial keying material, achieves which type of= forward > > secrecy. But, of course, this can be a misunderstood from our side. > > I believe that the mechanism used to fetch ephemeral init keys in MLS is = very > similar to the one you would use to fetch a "pre-key" for Signal. The dif= ference > is how the keys are mixed in the group secret which will provide specific= guarantees. > > I opened https://github.com/mlswg/mls-architecture/issues/48 I'll answer on the issue. But if it is the same mechanism used by the Signal protocol then it probably has 'middle' forward secrecy.. > > At some points, it might be nice to give recommendations in the spec: > > "It is left to the application to determine the interval of time betwee= n Update > > messages.". It is maybe good to provide an example of this time frame. > > At IETF last summer we agreed that we need to provide example recommandat= ions > regarding key-update frequency in the specification but I believe that we= probably > will wait a bit longer to have real world measurements before we can do t= hat as it > depends on the use-case (frequency of each group operation) and the number > of members in the group, hence is not super easy to simulate. > > https://github.com/mlswg/mls-architecture/issues/49 Oh, right! I'll keep a watch on the issue ;) > > It is also unclear at some points the notation used for the Diffie-Hell= man or > > Elliptic Curve parameters. Related to this, is unsure if this protocol = takes > > into account the cofactor issues. > > Thank you for reminding us, we will look into this. > > https://github.com/mlswg/mls-protocol/issues/118 I have putted more thoughts on the issue. This is something I can definitely help on. Maybe I'll submit a PR around this. But manly what is confusing right now is how actually the 'Derive-Key-Pair' func works. > > We are unsure if there is a will of including deniability in this. On s= ome > > points it states: > > > > """ > > [[ OPEN ISSUE: Signatures under the identity keys, while simple, have > > the side-effect of preclude deniability. We may wish to allow other > > options, such as (ii) a key chained off of the identity key, or (iii) > > some other key obtained through a different manner, such as a > > pairwise channel that provides deniability for the message > > contents.]] > > """ > > > > """ > > Non-Repudiation and Deniability > > As described in {{client-compromise}}, MLS provides data origin authent= ication > > within a group, such that one group member cannot send a message that a= ppears to > > be from another group member. Additionally, some services require that a > > recipient be able to prove to the messaging service that a message was = sent by > > a given Client, in order to report abuse. MLS supports both of these us= e cases. > > In some deployments, these services are provided by mechanisms which al= low the > > receiver to prove a message's origin to a third party (this if often ca= lled > > "non-repudiation"), but it should also be possible to operate MLS in a = "deniable" > > mode where such proof is not possible. [[OPEN ISSUE: Exactly how to sup= ply this > > is still a protocol question.]] > > """ > > > > If this is something that wants to be included, we will be very happy t= o answer > > questions. Nevertheless, there is no way, currently, to achieve the sam= e deniability > > properties OTRv4 has in a group setting. > > There was limited discussion in the working group and I believe deniabili= ty is not in the charter. > That said, I believe that our goal, at least mine, is to make sure that w= e can provide > deniability optionally on top of the current design, typically by sharing= the signature > public keys over pairwise deniable channels at the cost of linearity. Thi= s is something > you might want to ask to the list or the chairs. In the mean time I added= an issue. > > https://github.com/mlswg/mls-architecture/issues/50 Awesome! Thanks so much for the issue! > > We are also unsure of the difference between deniability and non-repuda= tion. > > > > This is very high-level review. We are very sorry if we misunderstood s= omething. > > We will be very happy to further check issues, if wanted. We can also h= elp on > > trying to give more structure, but I'm unsure where this is done: on the > > github instance? > > Thanks a lot for the offer, I believe the best way to currently for the d= ocument is to > keep submit issues in the Github or PRs for limited changes so that we ca= n make > these better. On the protocol side there are many things to look at such = as federation, > user initiated add or eventually ephemeral signatures, and I am sure help= will > be very appreciated as this review was... : ) Nice! I will surely do. Once I get more into the primitives details, I can = help on other things. Thanks! -- Sof=C3=ADa Celi (aka cherenkov) @claucece / @cherenkov_d Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE73QaX1aS5W8U9iQ8OZJhRPidmW8FAlxrMtkACgkQOZJhRPid mW/Kkg//QD18gUhvdho7TgxOKVKRsfZ+0hTWlq/ofK/ldmkfZPayTqQgeFySgKj+ cnPzhFEn16R9KSW0K6WUKYdfhRbW3E7m3NDmxumnKVShSvlGukSOHrrP/tOI6ntt ejsSRy1KXxt8fRSoD2LhwF4A3HePnbL/kALkqEyqrfugrTY8PTz0z6M8uCnMrOUj YFWSrG9uDjv91hIkVwApYEhNEUrbsN5cDDOgSv+6Bxbmy2An5bVdd1RdHhe/GBNx C62thjpNI9FVkhSkPZHVXnOurvJyjJIC4UeR0cJbndfie8gEwYBz/O02J19mxu0C a1RltnXAyW5cjN7yhVUVNCKcoJ5yO+o+LTW5lfIJMhg498bporihFQyUUHbBuoAa cFCc18a4pczemQAP2y5wEL9zndJxUo5CvLqr3R7yoaCLZfIFbU3oE8fS3PpPd8pJ r3Hbc1Lc1d3c7HhfPs59NwynIPmMHgUj8LJ3XIhbEDcg7cTrmgv2tOUh1ITooGkZ J1toXwVg9MD9Q5kd0Hm6RYhtYbJSXAl4lnWLGmUj6A860/asakV2pn3aLn8FMAL9 oqDlh/5F+/H/VNP9hjkT+DclUNpx59q1l255yNipE/4g5najZiOtrfk30OnKv13t DCQcjuVwz0u0HaDLOxX7IVSHRjNGat4Um2oDxk0DxcBeeOuev5A= =Aer+ -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From nobody Fri Feb 22 12:16:53 2019 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 84A731277D2 for ; Fri, 22 Feb 2019 12:16:52 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zkldifew4vc for ; Fri, 22 Feb 2019 12:16:51 -0800 (PST) Received: from smtpext4.darkmatter.ae (smtpext4.darkmatter.ae [185.180.84.5]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FC6130E66 for ; Fri, 22 Feb 2019 12:16:49 -0800 (PST) IronPort-PHdr: =?us-ascii?q?9a23=3AZtsvfBfVVDU4s8P6ckZUTjsxlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcS/ZR7h7PlgxGXEQZ/co6odzbaO4+a4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9HiTahYr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v6bpgRh31hy?= =?us-ascii?q?cdLzM38H/ZhNFsjKxVoxyhphNwzJLbboyOKPpxZaHdcc8GSWZdXMtcUTFKDIOm?= =?us-ascii?q?b4sICuoMJfpVr43jqFoBtxS+AxSjC/31yjRVm3H23bM10/4iEQHH2gwrAtUDvW?= =?us-ascii?q?jQrNrrO6YdS+a1w7TWwjXZdf9YxDf955bSchAioPGMW6l9ftfLxkk1FAPFi0+f?= =?us-ascii?q?qZD5PzyLzOQBqXKU4PR5WO+plmUpqBlxryCyysswkIXFmJwZx1/e+Slk2oo4Ic?= =?us-ascii?q?G0RFZmbdK4CpdcqT+WOoRsTs4gTGxkoiI3xqEetZ61YicHy4gryhvaZvCZb4eI?= =?us-ascii?q?7AzsWeOeLDhkmn5ldreyihew/EWvzuDxU9W73VdUoiZblNTHq2oD2AbJ6sedT/?= =?us-ascii?q?tw5kKh2TGS2A/N8uxEOkU0lbbDK54m374wioIfsUTdES/yn0X7lKyWeVsk++iz?= =?us-ascii?q?8ujofLrnpoOCO4Nulw7xKL4ums+6AesiLggOQ3aU+f6m2LL540L1WLRKjvsona?= =?us-ascii?q?nFqJ3WONgXqrSnDwNL3Ysv8QuzAy2i3dgEhXUHKUhKeBODj4jnIVHOJ/X4AO+j?= =?us-ascii?q?jlSojjhqyOrJPrv8DZrTNHjPiqrvfbZj5E5GywozzNZf6olJBb4bOvLzWUrxu8?= =?us-ascii?q?bEDh8lLQO02fzrB89j2Y8GQ2KAHreZML/OsV+P/u8vJu2MZJQOtTb8Nfcl+/Du?= =?us-ascii?q?gWU+mV8Hcqn6lacQPTq9Gu9OIkiFbzzrmNhLWTMPuhEWTeH2hhuFSzEFNFioWK?= =?us-ascii?q?dpzzU2GIugAYrZDrutjaaC3SHzSrRSa3BPDFyBCzHTd4ieWPYKQC6bOMxkmyAY?= =?us-ascii?q?WKLnQoJ3hkLmjxPz17cydrmcwSYfr5+2jNU=3D?= X-IPAS-Result: =?us-ascii?q?A2lbAABgWHBc/1oB4AphAx0BAQUBBwUBgVIHAQsBgVSCQAq?= =?us-ascii?q?DfZlGDJRNgXsMAROBZIJwAwIZhAo1CA0BAwEBAQEBAQIBAQEBgQYLgjoigxkRH?= =?us-ascii?q?zgBFQ0CJgIEMBURAQQTCLBzgS8aAoUohGyBC4Fzgn1dhC4lgnQ/JokqG4JDglc?= =?us-ascii?q?CiW4lJZkhBwKCPYQ8i18hgXGFW4MvA4gRik6SDgICAgIJAhSBSAGCDTMag1+QX?= =?us-ascii?q?XKObIEfAQE?= X-IronPort-AV: E=Sophos;i="5.58,401,1544472000"; d="scan'208";a="1501603" Received: from unknown (HELO keys-ext2.darkmatter.ae) ([10.224.1.90]) by ADMSS-00-D-002-DATA2-KDC.darkmatter.uae with ESMTP/TLS/DES-CBC3-SHA; 23 Feb 2019 00:16:41 +0400 Received: from ForcepointDLP ([10.224.1.90]) by keys-ext2.darkmatter.ae (PGP Universal service); Sat, 23 Feb 2019 00:16:41 +0400 X-PGP-Universal: processed; by keys-ext2.darkmatter.ae on Sat, 23 Feb 2019 00:16:41 +0400 Received: from ActiveEmail (ActiveEmail [127.0.0.1]) by ActiveEmail.localdomain (Service) with ESMTP id 4927F1800094 for ; Sat, 23 Feb 2019 00:13:38 +0400 (+04) Received: from email.darkmatter.ae (adkdcsvmc001.darkmatter.uae [10.224.74.11]) by ActiveEmail.localdomain (Service) with ESMTP id 2FD0F1800093 for ; Sat, 23 Feb 2019 00:13:38 +0400 (+04) Received: from ADKDCSVMC002.darkmatter.uae (10.224.74.12) by ADKDCSVMC001.darkmatter.uae (10.224.74.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Sat, 23 Feb 2019 00:16:41 +0400 Received: from ADKDCSVMC002.darkmatter.uae ([fe80::2cfe:4c2f:6749:c622]) by ADKDCSVMC002.darkmatter.uae ([fe80::2cfe:4c2f:6749:c622%12]) with mapi id 15.01.1531.010; Sat, 23 Feb 2019 00:16:41 +0400 From: Alexander Sherkin To: "mls@ietf.org" Thread-Topic: MLS Compatibility with PQC Thread-Index: AdTK6u/TqKU4F6B6RHCF92dbQJyksQ== Date: Fri, 22 Feb 2019 20:16:40 +0000 Message-ID: <40c09894a54d4d319539185d5372ce73@darkmatter.ae> Accept-Language: en-CA, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.224.74.90] x-exclaimer-md-config: 77ff947c-8af8-48f1-8d81-f67dcf75dbee MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: [MLS] MLS Compatibility with PQC 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, 22 Feb 2019 20:16:52 -0000 SGVsbG8sDQoNClRoZSBjdXJyZW50IHByb3RvY29sIGRyYWZ0IHNwZWNpZmljYWxseSByZWxpZXMg b24gRGlmZmllLUhlbGxtYW4gY3J5cHRvIHByaW1pdGl2ZS4gVGhpcyBtYWtlcyBwZXJmZWN0IHNl bnNlIHdoZW4gY2xhc3NpYyBjcnlwdG8gaXMgdXNlZCwgYnV0IG1heSBiZSBhIGxpbWl0YXRpb24g d2hlbiBwb3N0LXF1YW50dW0gY3J5cHRvIChQUUMpIGlzIHJlcXVpcmVkLg0KDQpJZiB3ZSBhc3N1 bWUgdGhhdCBwb3dlcmZ1bCBlbm91Z2ggcXVhbnR1bSBjb21wdXRlcnMgd2lsbCBiZWNvbWUgYSBy ZWFsaXR5IGluIHRoZSBuZXh0IDEwLTE1IHllYXJzLCBhbnkgZGF0YSBwcm90ZWN0ZWQgd2l0aCBj bGFzc2ljIGNyeXB0byB3ZSBleGNoYW5nZSB0b2RheSB3aWxsIGJlIGRlY3J5cHRhYmxlIGJ5IGEg dGhpcmQgcGFydHkgaW4gMTAtMTUgeWVhcnMuIEhlbmNlLCB1c2luZyBjbGFzc2ljIGNyeXB0byBm b3IgbmV3IHN5c3RlbXMgbWF5IG5vdCBiZSBhIGdvb2QgaWRlYS4NCg0KQXQgdGhlIHNhbWUgdGlt ZSwgaXQgc2VlbXMgdGhhdCB0aGUgcHJvdG9jb2wgaXMgd2VsbCBwb3NpdGlvbmVkIHRvIHJlbHkg b24gS0VNIGNyeXB0byBwcmltaXRpdmUuIFJlbHlpbmcgb24gS0VNIGluc3RlYWQgb2YgREggYWxs b3dzIGZvciBhIHdpZGVyIHJhbmdlIG9mIG9wdGlvbnMgaW5jbHVkaW5nIFBRQyBwcmltaXRpdmVz IHN1Y2ggYXMgTmV3IEhvcGUgYW5kIENyeXN0YWxzIEt5YmVyIG1ha2luZyB0aGUgcHJvdG9jb2wg UFFDLXJlYWR5IGF0IGxlYXN0IGZyb20gdGhlIGNvbmZpZGVudGlhbGl0eSBwZXJzcGVjdGl2ZS4N Cg0KVG8gbWFrZSBpdCBtb3JlIGdlbmVyYWwsIEtFTSBwcmltaXRpdmUgbWF5IGJlIGRlZmluZWQg YXMgKEMsIHMpID0gS0VNLUVuY2Fwc3VsYXRlKFB1YmxpY0tleSkgYW5kIHMgPSBLRU0tRGVjYXBz dWxhdGUoUHJpdmF0ZUtleSwgQykuDQoNClRob3VnaHRzPw0KDQpUaGFuayB5b3UuDQpBbGV4Lg0K DQoNCg0KQWxleGFuZGVyIFNoZXJraW4gfCBTb2Z0d2FyZSBBcmNoaXRlY3QNClRlbDogIHwgTW9i OiArMSA0MTYgNDE0IDcxMTcNCkFsZXhhbmRlci5TaGVya2luQGRhcmttYXR0ZXIuYWUNCg0KVGhl IGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkLCBpbmNsdWRpbmcgYXR0YWNobWVudHMsIGlzIGludGVu ZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24ocykgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJl c3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkIG1hdGVy aWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciB1 c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24gdGhpcyBpbmZv cm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJl Y2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVzdHJveSBhbnkgY29waWVzIG9mIHRoaXMgaW5m b3JtYXRpb24uDQoNCg0KDQoNCg0KDQoNCg0K From nobody Fri Feb 22 15:16:09 2019 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 034D9128BCC for ; Fri, 22 Feb 2019 15:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IFa3hISQImlh for ; Fri, 22 Feb 2019 15:16:04 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 7EC3D126C15 for ; Fri, 22 Feb 2019 15:16:04 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id t7so3299796otk.8 for ; Fri, 22 Feb 2019 15:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YC8cVuuM9ujQpbj8niDhdCZ8eUzRkfgOAq+hAOo/TGU=; b=FmwN/AfKwy12fQeKvWlgj+N3cji9S1HsEOyiAUnw+aggmzFyFroO33AA6XzSuqc3gq EVX7L3PNs1fCMz9fLhWdmbEo0QgyyU+76npQQV3TRF/zjT9tS5xduV/e8owGDhZ3YBZw ri1DFFmh98fVCl3KrpGpPBRZfP0C49ZRSOeuP7wqLF3qxLXpcx7y99fD0Bfp2KA57gr3 ow3iOvuiJYGddyJBZUMMuqKWuKFG9xBx9Lh+me5mOmcpDeN7AMi8Zho7uPZnSdhp8/TA I5x+1M14pep1IBRxCKPKgOJBrV8H+K1435TOX7ze2aThBnLr3XNDamlSK7h2RCoghpbo M4nw== 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=YC8cVuuM9ujQpbj8niDhdCZ8eUzRkfgOAq+hAOo/TGU=; b=fGx6GzPsgEwY/FxwV3U6VqLy3KrFNjFM9B1m/TPYFTahPE0C+ShTefCYY8NEDAGpDH Y+Z30Cs31L4SuWzCT3RKz+a8prXFlSlo/v+baEqQeGW8FUfMlDdffdTWt/8A+1rTI4+4 YI9WzM13JpDbUE/OypkiLL+NaJ5x3cihY/fHqo4bFxVit8I0wFSWe3Me95IAnXRu2TI0 WfMmwZYwEouywPe+ZMlYHv3IHQCbrdZ0skR7tjgLvrHntq/JiGaqkSpniXBPEDCrCM4W 1d+r+vhzpZI3tnO2iQ3OiU/r5fG6pZdoK18hbOWkDL1n1vubNjh9E7nUlqkGv469CKb1 cirA== X-Gm-Message-State: AHQUAub024m8R4a1RD5epvLECV/MABCared2KqSO/ZFJphUkmB/4iRwu cBnBl6gkZjZceflHE21upPhr45G9SyM+K0y3MR8GoA== X-Google-Smtp-Source: AHgI3IYh2oPclLDaDR8cQJkd4I4XAspLb+mRAo3ppxmWDwiBavx5faKWBKWgVNSaKGanmJ6x2TbY6xi18nT5GIN2PV8= X-Received: by 2002:a9d:6a09:: with SMTP id g9mr4385423otn.162.1550877362698; Fri, 22 Feb 2019 15:16:02 -0800 (PST) MIME-Version: 1.0 References: <40c09894a54d4d319539185d5372ce73@darkmatter.ae> In-Reply-To: <40c09894a54d4d319539185d5372ce73@darkmatter.ae> From: Richard Barnes Date: Fri, 22 Feb 2019 18:15:48 -0500 Message-ID: To: Alexander Sherkin Cc: "mls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b503c058283c6a4" Archived-At: Subject: Re: [MLS] MLS Compatibility with PQC 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, 22 Feb 2019 23:16:08 -0000 --0000000000004b503c058283c6a4 Content-Type: text/plain; charset="UTF-8" Hi Alex, Karthik and I have been working on a hybrid PKE primitive in CFRG, with the idea that it could be re-used in MLS: https://tools.ietf.org/html/draft-barnes-cfrg-hpke-00 In the CFRG discussion of that draft, several folks suggested that we adapt it to accommodate a general KEM. I have a draft-01 of that in the works that does that. So there is something of a plan here! Another thing that some folks have observed is that the length fields for public keys are two octets long. Would the keys for the schemes you're interested in overflow those fields? Thanks, --Richard On Fri, Feb 22, 2019 at 3:16 PM Alexander Sherkin < Alexander.Sherkin@darkmatter.ae> wrote: > Hello, > > The current protocol draft specifically relies on Diffie-Hellman crypto > primitive. This makes perfect sense when classic crypto is used, but may be > a limitation when post-quantum crypto (PQC) is required. > > If we assume that powerful enough quantum computers will become a reality > in the next 10-15 years, any data protected with classic crypto we exchange > today will be decryptable by a third party in 10-15 years. Hence, using > classic crypto for new systems may not be a good idea. > > At the same time, it seems that the protocol is well positioned to rely on > KEM crypto primitive. Relying on KEM instead of DH allows for a wider range > of options including PQC primitives such as New Hope and Crystals Kyber > making the protocol PQC-ready at least from the confidentiality perspective. > > To make it more general, KEM primitive may be defined as (C, s) = > KEM-Encapsulate(PublicKey) and s = KEM-Decapsulate(PrivateKey, C). > > Thoughts? > > Thank you. > Alex. > > > > Alexander Sherkin | Software Architect > Tel: | Mob: +1 416 414 7117 > Alexander.Sherkin@darkmatter.ae > > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in reliance upon > this information by persons or entities other than the intended recipient > is prohibited. If you received this in error, please contact the sender and > destroy any copies of this information. > > > > > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000004b503c058283c6a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

Karthik and I have been working on a hybrid PKE primitive in CFRG, with = the idea that it could be re-used in MLS:

<= br>
In the CFRG discussion of that draft, several folks suggested= that we adapt it to accommodate a general KEM.=C2=A0 I have a draft-01 of = that in the works that does that.=C2=A0 So there is something of a plan her= e!

Another thing that some folks have observed is = that the length fields for public keys are two octets long.=C2=A0 Would the= keys for the schemes you're interested in overflow those fields?
=

Thanks,
--Richard



On Fri, Feb 22, 2019 at 3:16 PM Alexander She= rkin <Alexander.Sherkin@darkmatter.ae> wrote:
Hello,

The current protocol draft specifically relies on Diffie-Hellman crypto pri= mitive. This makes perfect sense when classic crypto is used, but may be a = limitation when post-quantum crypto (PQC) is required.

If we assume that powerful enough quantum computers will become a reality i= n the next 10-15 years, any data protected with classic crypto we exchange = today will be decryptable by a third party in 10-15 years. Hence, using cla= ssic crypto for new systems may not be a good idea.

At the same time, it seems that the protocol is well positioned to rely on = KEM crypto primitive. Relying on KEM instead of DH allows for a wider range= of options including PQC primitives such as New Hope and Crystals Kyber ma= king the protocol PQC-ready at least from the confidentiality perspective.<= br>
To make it more general, KEM primitive may be defined as (C, s) =3D KEM-Enc= apsulate(PublicKey) and s =3D KEM-Decapsulate(PrivateKey, C).

Thoughts?

Thank you.
Alex.



Alexander Sherkin | Software Architect
Tel:=C2=A0 | Mob: +1 416 414 7117
Alexan= der.Sherkin@darkmatter.ae

The information transmitted, including attachments, is intended only for th= e person(s) or entity to which it is addressed and may contain confidential= and/or privileged material. Any review, retransmission, dissemination or o= ther use of, or taking of any action in reliance upon this information by p= ersons or entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and destroy any copies of= this information.








_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000004b503c058283c6a4-- From nobody Fri Feb 22 19:28:18 2019 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 3C099130E30 for ; Fri, 22 Feb 2019 19:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lBzdl2B6NDqg for ; Fri, 22 Feb 2019 19:28:14 -0800 (PST) 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 D7FAF126F72 for ; Fri, 22 Feb 2019 19:28:13 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id c18so3591066otl.13 for ; Fri, 22 Feb 2019 19:28:13 -0800 (PST) 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=cydd69VkW7Q6A8o0oRbTCBmnD2RNKP8k10xmqH4gd+o=; b=yAlda0gr49H2r/YdMJ6ls5OhdzX/n0RIip+AvF19UF6QVS3e7DWuJaOkfKFzvPWlkv dKW8B/s5HYxKqGORRtqV0yDRxvYquEwka1s1Rq+hVvLXhTpG6tbxsSBEujPpnNiJtDh4 hScP1GuIEEaG6nJSB6j05fXAVRyGwIrWo5b7mPdvsqfM99imBSxtgLwKGhjdT6BNfQco tArdBBdgkjjzRLnlXxJEx/76sqzgEMpIjBysd8NfGQ79+n5/5ex3o+n/yGu6tfe+LXb/ 3ii0ou17qtaznRIpBVPZ9ZgKz+7Yr/zTCtN6RXL/R7ctRVriQBnvD8/i1lyFL24B5rq+ E1hA== 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=cydd69VkW7Q6A8o0oRbTCBmnD2RNKP8k10xmqH4gd+o=; b=hfYATopYGNUExgjrrmzvtqa/te5tTIUfp4wyf1IcD0BYzpYM/YXjkHD5Yc0nkUplm1 QoEPtKgHKt0J+AQaW3JW7Xkmvr7oQ5XR3lLz9h1NMX4wnByVayuEwXVybptFKal31eF4 Q5imR9lSGdHq1mChAZeI6I02DClFWCGMykwNk6G5JKeCwQRssgpXX3cRsvChflp8It0s g+uCgtDDHjWh6HI33wZnkxs2tZ2mG3He8KZJVh8E0SC8bebwP65gSWwPUdYh77R8KlYt 96SkfO7nA8MziFz1tAMCGay9kxSzcG9WdhsdtJq17KQZuod+sDigWX05zLQ5znMILP0P s5IA== X-Gm-Message-State: AHQUAubK43bgk40JcWzC7+UpuDraOvq3eSx9D1r3RRqSNr1Br8AtNd1F /qd7TQfYVSEOgkt0o0pbKGpq0AnJ7uzHDyR20R2Kl6Ig X-Google-Smtp-Source: AHgI3IZt+AwelLgtUwXJFgdpfOM8Lcj0eAPJby1T9Qq+nowbcfIP7Hr0iaBP8W5CBt6tDgdOg2U8ovzRdlH9QwZbr48= X-Received: by 2002:a05:6830:1108:: with SMTP id w8mr4660639otq.167.1550892492759; Fri, 22 Feb 2019 19:28:12 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Fri, 22 Feb 2019 22:27:56 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000001db44b0582874c8e" Archived-At: Subject: [MLS] Simplifying the key schedule 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, 23 Feb 2019 03:28:16 -0000 --0000000000001db44b0582874c8e Content-Type: text/plain; charset="UTF-8" At the last interim, we filed an issue to discuss simplifying the key schedule. In particular, folks were unhappy that the whole, possibly gigantic GroupState object has to be hashed on every epoch change. When I sat down to think about how to simplify, though, it wasn't clear what direction to go in, because it wasn't clear exactly what people were finding painful. I'll posit from the start that I'm pretty sure that we need to somehow include the tree, the roster, and the message transcript into the key schedule. The transcript inclusion follows from the same reasons as it does in TLS; the roster and tree are needed because the whole transcript isn't accessible to a new joiner (so the new joiner can't infer those values from the transcript). With that said, there are multiple ways to represent those values for inclusion the key schedule: 1. Directly (as now) 2. As hashes 3. As structured hashes, e.g., a Merkle or "ampelmann" tree People are clearly unhappy with (1). The difference between 2 and 3 (and between variants of 3) is what value we're trying to achieve. (2) reduces the amount of hashing somewhat, but it doesn't change the amount of state you have to keep -- each member has to keep the full roster and tree, and hash the whole thing when it changes. For (3), it seems like there are weak and strong forms. In the weak form, we make it so that the member has to hash a sub-linear-size amount of data to update its representation of the tree/roster when it changes (e.g., in a Merkle tree, you have to recompute log(N) nodes). But each member still has to have the whole structure. In the strong form, we arrange the protocol so that a member can operate while holding a sub-linear amount of state (e.g., just a copath/frontier in some tree). Note that the strong form would entail pretty major protocol changes, e.g., bringing back the Merkle membership proofs that were in earlier versions of the protocol. For similar reasons, this would also entail larger messages. So basically, the mapping of options to values is: 1. Overall simplicity 2. A smaller coefficient on the linear amount of data hashed 3(weak). Sub-linear amount of data hashed 3(strong). Sub-linear amount of state In my personal value judgement, I would probably end up somewhere between (2) and (3,weak). It seems pretty unavoidable to me that members will have *some* linear-size state for the group, even if it's only a names for the members; adding say a key and a roster entry for each of those doesn't seem like a huge increment. So appealing though the state savings would be, they're not compelling enough to merit the protocol complexity and overhead. All that said, I would be interested in other folks' thoughts on which options are to be preferred here, or if there are other options that come to mind. Thanks, --Richard --0000000000001db44b0582874c8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the last interim, we filed an issue to discuss sim= plifying the key schedule.=C2=A0 In particular, folks were unhappy that the= whole, possibly gigantic GroupState object has to be hashed on every epoch= change.=C2=A0 When I sat down to think about how to simplify, though, it w= asn't clear what direction to go in, because it wasn't clear exactl= y what people were finding painful.

I'll posit= from the start that I'm pretty sure that we need to somehow include th= e tree, the roster, and the message transcript into the key schedule.=C2=A0= The transcript inclusion follows from the same reasons as it does in TLS; = the roster and tree are needed because the whole transcript isn't acces= sible to a new joiner (so the new joiner can't infer those values from = the transcript).

With that said, there are mul= tiple ways to represent those values for inclusion the key schedule:
<= div>
1. Directly (as now)
2. As hashes
3.= As structured hashes, e.g., a Merkle or "ampelmann" tree

People are clearly unhappy with (1).=C2=A0 The difference= between 2 and 3 (and between variants of 3) is what value we're trying= to achieve.=C2=A0 (2) reduces the amount of hashing somewhat, but it doesn= 't change the amount of state you have to keep -- each member has to ke= ep the full roster and tree, and hash the whole thing when it changes.

For (3), it seems like there are weak and strong forms= .=C2=A0 In the weak form, we make it so that the member has to hash a sub-l= inear-size amount of data to update its representation of the tree/roster w= hen it changes (e.g., in a Merkle tree, you have to recompute log(N) nodes)= .=C2=A0 But each member still has to have the whole structure.=C2=A0 In the= strong form, we arrange the protocol so that a member can operate while ho= lding a sub-linear amount of state (e.g., just a copath/frontier in some tr= ee).=C2=A0 Note that the strong form would entail pretty major protocol cha= nges, e.g., bringing back the Merkle membership proofs that were in earlier= versions of the protocol.=C2=A0 For similar reasons, this would also entai= l larger messages.

So basically, the mapping o= f options to values is:

1. Overall simplicity
2. A smaller coefficient on the linear amount of data hashed
3(weak). Sub-linear amount of data hashed
3(strong). Sub-li= near amount of state

In my personal value judgemen= t, I would probably end up somewhere between (2) and (3,weak).=C2=A0 It see= ms pretty unavoidable to me that members will have *some* linear-size state= for the group, even if it's only a names for the members; adding say a= key and a roster entry for each of those doesn't seem like a huge incr= ement.=C2=A0 So appealing though the state savings would be, they're no= t compelling enough to merit the protocol complexity and overhead.

All that said, I would be interested in other folks= 9; thoughts on which options are to be preferred here, or if there are othe= r options that come to mind.

Thanks,
--Richard

--0000000000001db44b0582874c8e-- From nobody Sat Feb 23 21:17:25 2019 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 34DE1130E68 for ; Sat, 23 Feb 2019 21:17:24 -0800 (PST) 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 qABIa1WTVBHV for ; Sat, 23 Feb 2019 21:17:21 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0: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 02228130E0A for ; Sat, 23 Feb 2019 21:17:20 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id 196so2944037pgf.13 for ; Sat, 23 Feb 2019 21:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=pCHz7A3jICDM7irncqhN93xNdlJ+mcU61AkKqV1+XgY=; b=KK31lK8rsfqNd2PV+QpnO/z69kKz/0RKnRB3Qnq6WvbUoToHcGr0K7lZAPTb/fOgKZ EitLSope4e+0152za4QrwUS55MbtViKV7Wi/WigXeAIyg2Ui8yBDpLaWeeLHnHBHoGYZ aUfSpXn51hF4iRGEYA/9eax8OR/BMieh1Jg6Q1P3sqoVNV+TSIbkJZsnkxJbl1EE5X0k ZddkX3YFVbA8wTX3gVjkHrAQoIogfDbB6ZtcdHiVQOTz2oca40VWDb1iU2HJBEL++5zv qjhR1k0XCq82D6rW13qwLMZ324EfR2OWHSeXPOUbfuq/PltqvYqAFPwoTEfloRdIMb5D GxsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pCHz7A3jICDM7irncqhN93xNdlJ+mcU61AkKqV1+XgY=; b=G4QKTGS/XENPQxV8XPO2GZ/A8ax4Da8zMtKjRNqqZ7+UNkTZA5fuA2o/e9q7QsvKYX AbKMC0ytFMfgk/wdbnIFn2lquuCF0+wumgPNLf+CtPomaoZ4ppGPlXOxm9L8wLOcDC1O x/L7xnnPDpodS8Jvfbs63q4PKsyYoOyQ8L2a5mN+ab6x35lPUqCKiYSyoSQcf+kc72/k JXD9E3Zfo2Z4cq/JvddDLayai9t3HOb1QYesVaUSBQ2mfaWPetAUXt6FZjlk6GSvfMYE DiCNrql21u+x+lbIILi1hDV3XOt89Pr6gvDCj1RilPMTgTXMQehLP0vKW8b2WsWvB5zT JNVw== X-Gm-Message-State: AHQUAubdYUbQjIECUwrJ6ppnBJoaUfK3f8gp+Yem2ncL5HOkhCVBghki upr/b2DNmI04LvJoMJwIUyj9511vmIkmWA== X-Google-Smtp-Source: AHgI3IYwVA2Xd1RLesFUrVoPxDOFaLyMvgmLIujIzz4HDqz01+yPhRGyyL/cB0peeMau9SDmSvf3Vw== X-Received: by 2002:a63:ed42:: with SMTP id m2mr11696442pgk.147.1550985439705; Sat, 23 Feb 2019 21:17:19 -0800 (PST) Received: from [192.168.2.182] (mx-ll-180.183.72-41.dynamic.3bb.co.th. [180.183.72.41]) by smtp.gmail.com with ESMTPSA id m64sm14708428pfi.149.2019.02.23.21.17.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Feb 2019 21:17:18 -0800 (PST) To: mls@ietf.org References: From: Joel Alwen Message-ID: <88df2d10-8ffa-11ce-64a9-be2da501892a@wickr.com> Date: Sun, 24 Feb 2019 12:17:16 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Simplifying the key schedule X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 05:17:24 -0000 Hi Richard, Sandro Corretti and I just discussed the questions you brought up in your email about the key schedule and we've come round to the opinion that of the options you present we prefer: - for the roster a merkle tree seems to be a good solution - for the ratchet tree an ampelmann hashing scheme should work well In our opinion linear state size (with reasonably small constants) is the lesser of the three evils when compared to needing extensive hashing for each tree update and needing larger packet sizes for the protocol (e.g. due to membership proofs). Having said that I wanted to suggest an alternative. Namely, including the ID's of leaves as part of what gets hashed for the ratchet tree. This makes including the roster redundant which means we would save on all the merkle tree storage as well as the hashing during join/leave ops. The only cost I see is that we might want to include the *hash* of ID's as part of the state to avoid having to recompute when that party updates their PK. (But that still needs less storage than a full merkle tree on the roster so its also an improvement.) While we are on the subject of amplemann tree's I wanted to make a suggestion for how to deal with blank nodes. I think its conceptually simpler (and thus hopefully also less error prone / easier to code) then using the resolution of blank nodes to define their values in the ampelmann hash. We let the value of each node begin with an indicator bit b (or octet if thats more practical). So node values are strings of the form b || PK. (Alternatively for leaves it would be b || PK || H(ID).) When b indicates the node is blank (b=1) we simply define PK (and H(ID)) to be all 0s. I'm also in favour of Raphael's suggestion to define the hash of a node to be H(L || R || V) where L and R are the hash of the left and right child while V denotes the value of the current node. It seems simpler than H(H(L || R) || V). - Joel On 2/23/19 10:27 AM, Richard Barnes wrote: > At the last interim, we filed an issue to discuss simplifying the key > schedule.  In particular, folks were unhappy that the whole, possibly > gigantic GroupState object has to be hashed on every epoch change.  When > I sat down to think about how to simplify, though, it wasn't clear what > direction to go in, because it wasn't clear exactly what people were > finding painful. > > I'll posit from the start that I'm pretty sure that we need to somehow > include the tree, the roster, and the message transcript into the key > schedule.  The transcript inclusion follows from the same reasons as it > does in TLS; the roster and tree are needed because the whole transcript > isn't accessible to a new joiner (so the new joiner can't infer those > values from the transcript). > > With that said, there are multiple ways to represent those values for > inclusion the key schedule: > > 1. Directly (as now) > 2. As hashes > 3. As structured hashes, e.g., a Merkle or "ampelmann" tree > > People are clearly unhappy with (1).  The difference between 2 and 3 > (and between variants of 3) is what value we're trying to achieve.  (2) > reduces the amount of hashing somewhat, but it doesn't change the amount > of state you have to keep -- each member has to keep the full roster and > tree, and hash the whole thing when it changes. > > For (3), it seems like there are weak and strong forms..  In the weak > form, we make it so that the member has to hash a sub-linear-size amount > of data to update its representation of the tree/roster when it changes > (e.g., in a Merkle tree, you have to recompute log(N) nodes)..  But each > member still has to have the whole structure.  In the strong form, we > arrange the protocol so that a member can operate while holding a > sub-linear amount of state (e.g., just a copath/frontier in some tree).  > Note that the strong form would entail pretty major protocol changes, > e.g., bringing back the Merkle membership proofs that were in earlier > versions of the protocol.  For similar reasons, this would also entail > larger messages. > > So basically, the mapping of options to values is: > > 1. Overall simplicity > 2. A smaller coefficient on the linear amount of data hashed > 3(weak). Sub-linear amount of data hashed > 3(strong). Sub-linear amount of state > > In my personal value judgement, I would probably end up somewhere > between (2) and (3,weak).  It seems pretty unavoidable to me that > members will have *some* linear-size state for the group, even if it's > only a names for the members; adding say a key and a roster entry for > each of those doesn't seem like a huge increment.  So appealing though > the state savings would be, they're not compelling enough to merit the > protocol complexity and overhead. > > All that said, I would be interested in other folks' thoughts on which > options are to be preferred here, or if there are other options that > come to mind. > > Thanks, > --Richard > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Sun Feb 24 02:15:48 2019 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 EC530127287 for ; Sun, 24 Feb 2019 02:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNfJUtF53n_i for ; Sun, 24 Feb 2019 02:15:44 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBF4126C01 for ; Sun, 24 Feb 2019 02:15:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,407,1544482800"; d="scan'208";a="297142449" Received: from 91-165-78-144.subs.proxad.net (HELO [192.168.0.3]) ([91.165.78.144]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2019 11:15:41 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Benjamin Beurdouche In-Reply-To: <88df2d10-8ffa-11ce-64a9-be2da501892a@wickr.com> Date: Sun, 24 Feb 2019 11:15:41 +0100 Cc: ML Messaging Layer Security Content-Transfer-Encoding: 7bit Message-Id: References: <88df2d10-8ffa-11ce-64a9-be2da501892a@wickr.com> To: Joel Alwen X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] Simplifying the key schedule X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 10:15:46 -0000 Hi Joel, > On Feb 24, 2019, at 6:17 AM, Joel Alwen wrote: > > Hi Richard, > > Sandro Corretti and I just discussed the questions you brought up in > your email about the key schedule and we've come round to the opinion > that of the options you present we prefer: > > - for the roster a merkle tree seems to be a good solution > - for the ratchet tree an ampelmann hashing scheme should work well > > In our opinion linear state size (with reasonably small constants) is > the lesser of the three evils when compared to needing extensive hashing > for each tree update and needing larger packet sizes for the protocol > (e.g. due to membership proofs). > > Having said that I wanted to suggest an alternative. Namely, including > the ID's of leaves as part of what gets hashed for the ratchet tree. > This makes including the roster redundant which means we would save on > all the merkle tree storage as well as the hashing during join/leave > ops. The only cost I see is that we might want to include the *hash* of > ID's as part of the state to avoid having to recompute when that party > updates their PK. (But that still needs less storage than a full merkle > tree on the roster so its also an improvement.) I am not sure to understand what you mean here :) while it might be poorly documented all the user init keys in TreeKEM are already mixed in the epoch secret because the Group AKE mandates to agree on whom is in the group at all times. Our issue is that a newcomer cannot use that information to explicitly check the identities. In general, I agree that the TreeKEM section of the draft lacks clarity on what it provides, and I believe it will be helpful to improve upon it so I will take a pass on it with Karthik before the interim. Cheers, B. > While we are on the subject of amplemann tree's I wanted to make a > suggestion for how to deal with blank nodes. I think its conceptually > simpler (and thus hopefully also less error prone / easier to code) then > using the resolution of blank nodes to define their values in the > ampelmann hash. We let the value of each node begin with an indicator > bit b (or octet if thats more practical). So node values are strings of > the form b || PK. (Alternatively for leaves it would be b || PK || > H(ID).) When b indicates the node is blank (b=1) we simply define PK > (and H(ID)) to be all 0s. > > I'm also in favour of Raphael's suggestion to define the hash of a node > to be H(L || R || V) where L and R are the hash of the left and right > child while V denotes the value of the current node. It seems simpler > than H(H(L || R) || V). > > - Joel From nobody Mon Feb 25 07:32:49 2019 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 EEA091200D8 for ; Mon, 25 Feb 2019 07:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gkPf5mIaIem9 for ; Mon, 25 Feb 2019 07:32:44 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 8572E130F30 for ; Mon, 25 Feb 2019 07:32:18 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id g1so8131341otj.11 for ; Mon, 25 Feb 2019 07:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VAddBZZbImz3JLxgVHeN2PfDLjUm0OLg6AgMvhkiGm8=; b=Z2lyPw6ctrlMzoL0dqU3V61VrZu4NmtMXv+jvdKgPDzOoUYjI+c4E0bgjYZgRL8MF2 vSTd8sPcPw4YZyqQsQWlxSy7Fogd97nMgfIOTzBv98KbvYa1gSZudl5JRy9XKWMiCPkn pxdMbrFbn6kbSMuvHkMOnCb9ynwYpVqtQH5bosforIqWbeZVEbXHWjs+e+ZfZHvNiKCG yYntFZ8SdWiaIkuZK9oc+AV3GpauoHvV6W4Qm8QBYL2rwtxIs77I6O7zvZYiAYx4AF3e GYxsCaNvOZvY6hw1Kxf8OK6MxCnXiQHYADIbVCsQzUQJQ7jlXnD44hzdD9XF7CGKtRGO ZfKQ== 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=VAddBZZbImz3JLxgVHeN2PfDLjUm0OLg6AgMvhkiGm8=; b=P3jZ8Cdm+Hrohb4tDazGCEU1vF06aH8IOqF6g1lqG4Px3DTSSoGykr6c41sMMDFtSJ RnlDn4/e1rMKTn3qrPW+u8z13teWXFATUJ2XchDxt0LGOCC9faUHXfQ3m3s8Zt366sJo cDWhoeeiJjfiDQU5YQM/uKGOou/Ip8hYu14DDwpj4HwHxWv99Xc47uyTpnG6qIUpB46D 44hIWkSstnIRL2baxwEOQ7Z6P3Uo4RAX+8+LOZkka2yTaPtse1HdXFWtsUqMgq8g3jJ4 QO1X47Vwe3qHAnV35jkFfPbeSzKKPBBM+vD7LFA2iY6Dgfmjz7kcyf1Cxh/kODtUVnQR a5og== X-Gm-Message-State: AHQUAuaDO8kyrtAVjgDVXTe5SGhgakIE3Nl0eiYghC2H14T6dsruAJSc 5BRbAOB/FEbUaET0zMBgApJ75/pURLtitTghh0rRO9eK X-Google-Smtp-Source: AHgI3IYnNOoZiXfn+fZENpMRGP6n4MOWXNrXBWii01/S0N7XkMPeU9ocFs3XxlL0Ok9f69E/xOg/t/aYM8iAx5zQXe0= X-Received: by 2002:a05:6830:15c7:: with SMTP id j7mr3542721otr.331.1551108737621; Mon, 25 Feb 2019 07:32:17 -0800 (PST) MIME-Version: 1.0 References: <88df2d10-8ffa-11ce-64a9-be2da501892a@wickr.com> In-Reply-To: <88df2d10-8ffa-11ce-64a9-be2da501892a@wickr.com> From: Richard Barnes Date: Mon, 25 Feb 2019 10:32:00 -0500 Message-ID: To: Joel Alwen Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000005071f10582b9a5b6" Archived-At: Subject: Re: [MLS] Simplifying the key schedule 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, 25 Feb 2019 15:32:48 -0000 --0000000000005071f10582b9a5b6 Content-Type: text/plain; charset="UTF-8" Hi Joel, Some notes inline: On Sun, Feb 24, 2019 at 12:17 AM Joel Alwen wrote: > Hi Richard, > > Sandro Corretti and I just discussed the questions you brought up in > your email about the key schedule and we've come round to the opinion > that of the options you present we prefer: > > - for the roster a merkle tree seems to be a good solution > - for the ratchet tree an ampelmann hashing scheme should work well > > In our opinion linear state size (with reasonably small constants) is > the lesser of the three evils when compared to needing extensive hashing > for each tree update and needing larger packet sizes for the protocol > (e.g. due to membership proofs). > Thanks for the clear priorities! > Having said that I wanted to suggest an alternative. Namely, including > the ID's of leaves as part of what gets hashed for the ratchet tree. > This makes including the roster redundant which means we would save on > all the merkle tree storage as well as the hashing during join/leave > ops. The only cost I see is that we might want to include the *hash* of > ID's as part of the state to avoid having to recompute when that party > updates their PK. (But that still needs less storage than a full merkle > tree on the roster so its also an improvement.) > This seems sensible to me. So you would basically end up with a unified tree with the following shape: - Leaves hold (DHPublicKey, Credential, NodeHash) - Intermediate nodes hold (DHPublicKey, LeftHash, RightHash, NodeHash) It actually looks to me like this is a wash from a storage POV -- in each case, you have 2n-1 DH keys, n credentials, and n-1 hashes. But it probably saves you some hashing in some cases. > While we are on the subject of amplemann tree's I wanted to make a > suggestion for how to deal with blank nodes. I think its conceptually > simpler (and thus hopefully also less error prone / easier to code) then > using the resolution of blank nodes to define their values in the > ampelmann hash. We let the value of each node begin with an indicator > bit b (or octet if thats more practical). So node values are strings of > the form b || PK. (Alternatively for leaves it would be b || PK || > H(ID).) When b indicates the node is blank (b=1) we simply define PK > (and H(ID)) to be all 0s. > This is actually already kind of covered in the current spec. The nodes in the ratchet tree are of type optional, which is 0x01 || PK when populated and 0x00 when blank. So if we just use that same struct for the V input to the ampelmann hashing, things should be pretty straightforward to code. > I'm also in favour of Raphael's suggestion to define the hash of a node > to be H(L || R || V) where L and R are the hash of the left and right > child while V denotes the value of the current node. It seems simpler > than H(H(L || R) || V). > The only difference that occurs to me here is that there's a factor of 2 in proof size to be had: If you don't care about the children, you can just send H(L || R) instead of sending (L, R). Of course, there's a corresponding factor of two in hashing, so there's another trade-off space to select from. --Richard > > - Joel > > > On 2/23/19 10:27 AM, Richard Barnes wrote: > > At the last interim, we filed an issue to discuss simplifying the key > > schedule. In particular, folks were unhappy that the whole, possibly > > gigantic GroupState object has to be hashed on every epoch change. When > > I sat down to think about how to simplify, though, it wasn't clear what > > direction to go in, because it wasn't clear exactly what people were > > finding painful. > > > > I'll posit from the start that I'm pretty sure that we need to somehow > > include the tree, the roster, and the message transcript into the key > > schedule. The transcript inclusion follows from the same reasons as it > > does in TLS; the roster and tree are needed because the whole transcript > > isn't accessible to a new joiner (so the new joiner can't infer those > > values from the transcript). > > > > With that said, there are multiple ways to represent those values for > > inclusion the key schedule: > > > > 1. Directly (as now) > > 2. As hashes > > 3. As structured hashes, e.g., a Merkle or "ampelmann" tree > > > > People are clearly unhappy with (1). The difference between 2 and 3 > > (and between variants of 3) is what value we're trying to achieve. (2) > > reduces the amount of hashing somewhat, but it doesn't change the amount > > of state you have to keep -- each member has to keep the full roster and > > tree, and hash the whole thing when it changes. > > > > For (3), it seems like there are weak and strong forms.. In the weak > > form, we make it so that the member has to hash a sub-linear-size amount > > of data to update its representation of the tree/roster when it changes > > (e.g., in a Merkle tree, you have to recompute log(N) nodes).. But each > > member still has to have the whole structure. In the strong form, we > > arrange the protocol so that a member can operate while holding a > > sub-linear amount of state (e.g., just a copath/frontier in some tree). > > Note that the strong form would entail pretty major protocol changes, > > e.g., bringing back the Merkle membership proofs that were in earlier > > versions of the protocol. For similar reasons, this would also entail > > larger messages. > > > > So basically, the mapping of options to values is: > > > > 1. Overall simplicity > > 2. A smaller coefficient on the linear amount of data hashed > > 3(weak). Sub-linear amount of data hashed > > 3(strong). Sub-linear amount of state > > > > In my personal value judgement, I would probably end up somewhere > > between (2) and (3,weak). It seems pretty unavoidable to me that > > members will have *some* linear-size state for the group, even if it's > > only a names for the members; adding say a key and a roster entry for > > each of those doesn't seem like a huge increment. So appealing though > > the state savings would be, they're not compelling enough to merit the > > protocol complexity and overhead. > > > > All that said, I would be interested in other folks' thoughts on which > > options are to be preferred here, or if there are other options that > > come to mind. > > > > 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 > --0000000000005071f10582b9a5b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel,

Some notes inline:<= br>

On Sun, Feb 24, 2019 at 12:17 AM Joel Alwen <jalwen@wickr.com> wrote:
Hi Richard,

Sandro Corretti and I just discussed the questions you brought up in
your email about the key schedule and we've come round to the opinion that of the options you present we prefer:

- for the roster a merkle tree seems to be a good solution
- for the ratchet tree an ampelmann hashing scheme should work well

In our opinion linear state size (with reasonably small constants) is
the lesser of the three evils when compared to needing extensive hashing for each tree update and needing larger packet sizes for the protocol
(e.g. due to membership proofs).

Thanks= for the clear priorities!
=C2=A0
Having said that I wanted to suggest an alternative. Namely, including
the ID's of leaves as part of what gets hashed for the ratchet tree. This makes including the roster redundant which means we would save on
all the merkle tree storage as well as the hashing during join/leave
ops. The only cost I see is that we might want to include the *hash* of
ID's as part of the state to avoid having to recompute when that party<= br> updates their PK. (But that still needs less storage than a full merkle
tree on the roster so its also an improvement.)

This seems sensible to me.=C2=A0 So you would basically end up wit= h a unified tree with the following shape:

- Leave= s hold (DHPublicKey, Credential, NodeHash)
- Intermediate nod= es hold (DHPublicKey, LeftHash, RightHash, NodeHash)

It actually looks to me like this is a wash from a storage POV -- in eac= h case, you have 2n-1 DH keys, n credentials, and n-1 hashes.=C2=A0 But it = probably saves you some hashing in some cases.

=C2= =A0
While we are on the subject of amplemann tree's I wanted to make a
suggestion for how to deal with blank nodes. I think its conceptually
simpler (and thus hopefully also less error prone / easier to code) then using the resolution of blank nodes to define their values in the
ampelmann hash. We let the value of each node begin with an indicator
bit b (or octet if thats more practical). So node values are strings of
the form b || PK. (Alternatively for leaves it would be b || PK ||
H(ID).) When b indicates the node is blank (b=3D1) we simply define PK
(and H(ID)) to be all 0s.

This is actua= lly already kind of covered in the current spec.=C2=A0 The nodes in the rat= chet tree are of type optional<DHPublicKey>, which is 0x01 || PK when= populated and 0x00 when blank.=C2=A0 So if we just use that same struct fo= r the V input to the ampelmann hashing, things should be pretty straightfor= ward to code.
=C2=A0
I'm also in favour of Raphael's suggestion to define the hash of a = node
to be H(L || R || V) where L and R are the hash of the left and right
child while V denotes the value of the current node. It seems simpler
than H(H(L || R) || V).

The only difference = that occurs to me here is that there's a factor of 2 in proof size to b= e had: If you don't care about the children, you can just send H(L || R= ) instead of sending (L, R).=C2=A0 Of course, there's a corresponding f= actor of two in hashing, so there's another trade-off space to select f= rom.

--Richard

=C2=A0
=

- Joel


On 2/23/19 10:27 AM, Richard Barnes wrote:
> At the last interim, we filed an issue to discuss simplifying the key<= br> > schedule.=C2=A0 In particular, folks were unhappy that the whole, poss= ibly
> gigantic GroupState object has to be hashed on every epoch change.=C2= =A0 When
> I sat down to think about how to simplify, though, it wasn't clear= what
> direction to go in, because it wasn't clear exactly what people we= re
> finding painful.
>
> I'll posit from the start that I'm pretty sure that we need to= somehow
> include the tree, the roster, and the message transcript into the key<= br> > schedule.=C2=A0 The transcript inclusion follows from the same reasons= as it
> does in TLS; the roster and tree are needed because the whole transcri= pt
> isn't accessible to a new joiner (so the new joiner can't infe= r those
> values from the transcript).
>
> With that said, there are multiple ways to represent those values for<= br> > inclusion the key schedule:
>
> 1. Directly (as now)
> 2. As hashes
> 3. As structured hashes, e.g., a Merkle or "ampelmann" tree<= br> >
> People are clearly unhappy with (1).=C2=A0 The difference between 2 an= d 3
> (and between variants of 3) is what value we're trying to achieve.= =C2=A0 (2)
> reduces the amount of hashing somewhat, but it doesn't change the = amount
> of state you have to keep -- each member has to keep the full roster a= nd
> tree, and hash the whole thing when it changes.
>
> For (3), it seems like there are weak and strong forms..=C2=A0 In the = weak
> form, we make it so that the member has to hash a sub-linear-size amou= nt
> of data to update its representation of the tree/roster when it change= s
> (e.g., in a Merkle tree, you have to recompute log(N) nodes)..=C2=A0 B= ut each
> member still has to have the whole structure.=C2=A0 In the strong form= , we
> arrange the protocol so that a member can operate while holding a
> sub-linear amount of state (e.g., just a copath/frontier in some tree)= .=C2=A0
> Note that the strong form would entail pretty major protocol changes,<= br> > e.g., bringing back the Merkle membership proofs that were in earlier<= br> > versions of the protocol.=C2=A0 For similar reasons, this would also e= ntail
> larger messages.
>
> So basically, the mapping of options to values is:
>
> 1. Overall simplicity
> 2. A smaller coefficient on the linear amount of data hashed
> 3(weak). Sub-linear amount of data hashed
> 3(strong). Sub-linear amount of state
>
> In my personal value judgement, I would probably end up somewhere
> between (2) and (3,weak).=C2=A0 It seems pretty unavoidable to me that=
> members will have *some* linear-size state for the group, even if it&#= 39;s
> only a names for the members; adding say a key and a roster entry for<= br> > each of those doesn't seem like a huge increment.=C2=A0 So appeali= ng though
> the state savings would be, they're not compelling enough to merit= the
> protocol complexity and overhead.
>
> All that said, I would be interested in other folks' thoughts on w= hich
> options are to be preferred here, or if there are other options that > come to mind.
>
> 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
--0000000000005071f10582b9a5b6-- From nobody Mon Feb 25 12:01:11 2019 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 84518131054 for ; Mon, 25 Feb 2019 12:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bn_rzEUjXsbK for ; Mon, 25 Feb 2019 12:01:02 -0800 (PST) Received: from smtpext4.darkmatter.ae (smtpext4.darkmatter.ae [185.180.84.5]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026B113104D for ; Mon, 25 Feb 2019 12:00:58 -0800 (PST) IronPort-PHdr: =?us-ascii?q?9a23=3ASryaJhzmkbJ5/2DXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?2uMfIJqq85mqBkHD//Il1AaPAd2Lraocw8Pt8InYEVQa5piAtH1QOLdtbDQizf?= =?us-ascii?q?ssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1?= =?us-ascii?q?JuPoEYLOksi7ze+/94HQbglSmDaxfa55IQmrownWqsQYm5ZpJLwryhvOrHtIeu?= =?us-ascii?q?BWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3o05MLwqxbO?= =?us-ascii?q?SxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDwULs6Wymt771zRRHoli?= =?us-ascii?q?kJKiI5/m/UhMx+jq1boR2uqABkzo7OfI2VNuBzcr/Bcd4YQ2dKQ8ZfVzZGAoO5?= =?us-ascii?q?d4YCE+4BMvhXrobnoVsBsAWxBROxD+3yyj9HmGX23a470+QnDArL2xAtH9YQv3?= =?us-ascii?q?Xbttr1MrodXv6vzKXS0DvDb+1Z2S3+6IjJdBAsuuyDUqhqccrSzEkgDR/FjkmO?= =?us-ascii?q?poz/JT+azPoCvnGd4uF9W+yvjGsnpBtwojip3sosjojJhoQWyl/a6Cp5wYA1Kc?= =?us-ascii?q?ekR058ZN6oCIdQti+bN4tqXsMtXXtotDwmxb0BvJ63ZCkKx4o7xx7RcfCHdJKI?= =?us-ascii?q?4h37WOmMOzh4nnFleLeliBau7Uiv1Pf8WtOu31lUqCdOj9rCtmgV2hDO9sSLUO?= =?us-ascii?q?Vx8lmu1DqVygzf8OVJLVwsmabGN5It2KA8moQcvEjZHCL7l1/6gauKekk89Oin?= =?us-ascii?q?9efqbqnjq5KZKYN7lg/+Pborl8GwHes0LAYOUm2a9Om+27Du+Uj0T6lLg/EojK?= =?us-ascii?q?XUto3RK94Bqa6jGQBV154u6xO4Dzi7ztsVhWIHLFdZeBKfiIjpJk3OLOj4Dfih?= =?us-ascii?q?h1Ssly9mx/PYMbzhGZXBN2bMkbj9fbpg8UJT1RA8zcpc55JREL4BPO7zVVHrtN?= =?us-ascii?q?DCFBA2LRS4w+fhCNpjyoMTQX+DDrODPK/Mr1OF6fgjL/SWaIIRpDrxM/0l6OTv?= =?us-ascii?q?jX89l18dZ66p3Z4PZX2kGvRpPUqYbmDqgtgcD2gKpBAyQvHqiFKcSz5TZHeyX6?= =?us-ascii?q?Qn6z4mEo2mF4TDRoW3j7ydwCe0AIdWanpcBV+SCXvobZmLW+8QaCKOJc9sijkE?= =?us-ascii?q?Vby6S4I61BGhqhP6y7R9IurT4C0Yuorp1MJp6O3LiREy6Tt0AtyH02GJVG55hW?= =?us-ascii?q?IIRyco3Kxlukx8xQTL7a8tuf1TFdVJ67tjWx08OIWUm/Z+AfjzQhyHZcffG3i8?= =?us-ascii?q?RdDzKDU8Xts3z9IUK319Fs+hjxaLiwOuDq8ckbCGHtoP8q/G3Hn3D8p00XXD3b?= =?us-ascii?q?U9gkNgS8YZZj7uvbJ26wWGX92BqE6ejav/Lak=3D?= X-IPAS-Result: =?us-ascii?q?A2kHAAD9SHRc/1oB4AphAxoBAQEBAQIBAQEBBwIBAQEBgVM?= =?us-ascii?q?DAQEBAQsBgQ0BRgWBEQ+BGwqDfpYBghdxSZRNFIErFx0DBQgBAwEYAQoLgUmCd?= =?us-ascii?q?QIXhBg2Bw0BAwEBAQEBAQIBAQEBgQUMgjoiGAQxHC8LBAEBAQEBAQEBASQBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEUAggzCQMPAQEYAQEBAQMBAQMBHQomEwgCCRACA?= =?us-ascii?q?QgNAQMEAQEGAQEBHwMCAgIFEA8BCxQJCAEBBA4EAQgGgxOCAat2gS8aAoQXAoE?= =?us-ascii?q?PhFYPgn6CfV2DKIEGJYJ0PyZrgxKDHgEBA4ErARIBHAoFAgkKCwoCBgmCQ4JXA?= =?us-ascii?q?olvASUlggCDfYcbhDaHWAcCgkCEEwEoRYNxhQqCIiGBcViFA4MxA4gTj2RBjEE?= =?us-ascii?q?CAgICCQIUgU4BgRZaDwgzGnOCbAmCHAMXgQABAgk8ggOFFIU/co1NgR+BHwEB?= X-IronPort-AV: E=Sophos;i="5.58,412,1544472000"; d="png'150?scan'150,208,217,150";a="1520137" Received: from unknown (HELO keys-ext1.darkmatter.ae) ([10.224.1.90]) by ADMSS-00-D-002-DATA2-KDC.darkmatter.uae with ESMTP/TLS/DES-CBC3-SHA; 26 Feb 2019 00:00:53 +0400 Received: from ForcepointDLP ([10.224.1.90]) by keys-ext1.darkmatter.ae (PGP Universal service); Tue, 26 Feb 2019 00:00:52 +0400 X-PGP-Universal: processed; by keys-ext1.darkmatter.ae on Tue, 26 Feb 2019 00:00:52 +0400 Received: from ActiveEmail (ActiveEmail [127.0.0.1]) by ActiveEmail.localdomain (Service) with ESMTP id A86CE1800094; Mon, 25 Feb 2019 23:57:47 +0400 (+04) Received: from email.darkmatter.ae (adkdcsvmc002.darkmatter.uae [10.224.74.12]) by ActiveEmail.localdomain (Service) with ESMTP id 88AD91800093; Mon, 25 Feb 2019 23:57:47 +0400 (+04) Received: from ADKDCSVMC002.darkmatter.uae (10.224.74.12) by ADKDCSVMC002.darkmatter.uae (10.224.74.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1591.10; Tue, 26 Feb 2019 00:00:51 +0400 Received: from ADKDCSVMC002.darkmatter.uae ([fe80::2cfe:4c2f:6749:c622]) by ADKDCSVMC002.darkmatter.uae ([fe80::2cfe:4c2f:6749:c622%12]) with mapi id 15.01.1591.008; Tue, 26 Feb 2019 00:00:51 +0400 From: Alexander Sherkin To: Richard Barnes CC: "mls@ietf.org" Thread-Topic: [MLS] MLS Compatibility with PQC Thread-Index: AdTK6u/TqKU4F6B6RHCF92dbQJyksf//8CkA//s/jcA= Date: Mon, 25 Feb 2019 20:00:51 +0000 Message-ID: <956c4f3a40594c889fd9ac5197c57258@darkmatter.ae> References: <40c09894a54d4d319539185d5372ce73@darkmatter.ae> In-Reply-To: Accept-Language: en-CA, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.224.74.90] x-exclaimer-md-config: 77ff947c-8af8-48f1-8d81-f67dcf75dbee MIME-Version: 1.0 Content-Language: en-US Content-Type: multipart/related; boundary="_006_956c4f3a40594c889fd9ac5197c57258darkmatterae_"; type="multipart/alternative" Archived-At: Subject: Re: [MLS] MLS Compatibility with PQC 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, 25 Feb 2019 20:01:09 -0000 --_006_956c4f3a40594c889fd9ac5197c57258darkmatterae_ Content-Type: multipart/alternative; boundary="_000_956c4f3a40594c889fd9ac5197c57258darkmatterae_" --_000_956c4f3a40594c889fd9ac5197c57258darkmatterae_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmljZS4gSSB0aGluayB0aGUgS0VNLWJhc2VkIGFwcHJvYWNoIHdpbGwgbWFrZSBpdCBtdWNoIHNp bXBsZXIgZm9yIFBRQyBjaXBoZXIgc3VpdGUgaW50ZWdyYXRpb24uIEFub3RoZXIgcGFydCBpcyBh bGxvd2luZyBmb3IgUFFDIHNpZ25hdHVyZXMgc3VjaCBhcyBTUEhJTkNTLiBBcmd1YWJseSwgUFFD IGF1dGhlbnRpY2l0eSBtYXkgbm90IGJlIHN1Y2ggYW4gdXJnZW50IHByb2JsZW0gYmVjYXVzZSBh biBhdHRhY2tlciBuZWVkcyBhIHF1YW50dW0gY29tcHV0ZXIgbm93IHRvIGJlIGFibGUgdG8gYXR0 YWNrIG1lc3NhZ2UgYXV0aGVudGljaXR5LiBJbiBjb250cmFzdCwgbWVzc2FnZXMgaW50ZXJjZXB0 ZWQgYW5kIHJlY29yZGVkIG5vdyBtYXkgYmUgZGVjcnlwdGVkIGJ5IGEgcXVhbnR1bSBjb21wdXRl IGluIHRoZSBmdXR1cmU7IGhlbmNlLCB0aGUgdXJnZW50IG5lZWQgZm9yIFBRQyBmb3IgY29uZmlk ZW50aWFsaXR5Lg0KDQpLeWJlciBwdWJsaWMga2V5IGxlbmd0aCBpcyBhYm91dCAxLjVLYiwgYW5k IHByaXZhdGUga2V5IGxlbmd0aCBpcyBhYm91dCAzS2IuIFNwaGluY3MrIHB1YmxpYyBrZXkgaXMg NjQgYnl0ZXMsIGFuZCB0aGUgcHJpdmF0ZSBrZXkgaXMgMTI4IGJ5dGVzLg0KDQpUd28gb2N0ZXQg bGVuZ3RoIGlzIHByb2JhYmx5IGZpbmUgZm9yIExhdHRpY2UtYmFzZWQgc2NoZW1lcy4gSG93ZXZl ciwgQ29kZS1iYXNlZCBjcnlwdG8gc2NoZW1lcyBtYXkgaGF2ZSBwdWJsaWMga2V5cyBvbiB0aGUg b3JkZXIgb2YgMSBNYi4gQ29kZS1iYXNlZCBjcnlwdG8gbWF5IGJlIGNvbnNpZGVyZWQgYXMgb25l IG9mIHRoZSBtb3N0IGNvbnNlcnZhdGl2ZSBjaG9pY2VzIHNvIHN1cHBvcnRpbmcgQ29kZS1iYXNl ZCBjcnlwdG8gd291bGQgYmUgbmljZSBpZiBwb3NzaWJsZS4NCg0KVGhhbmtzLg0KQWxleC4NCg0K DQoNCg0KQWxleGFuZGVyIFNoZXJraW4NCiAgICAgICAgU29mdHdhcmUgQXJjaGl0ZWN0DQoNCg0K DQpbY2lkOmltYWdlMmMwN2FlLlBOR0BlZjkyZGNlOS40Mjg1NzRhZV08aHR0cDovL3d3dy5kYXJr bWF0dGVyLmFlPg0KDQoyIFJvYmVydCBTcGVjayBQYXJrd2F5LCBTdWl0ZSAxNjEwDQpNaXNzaXNz YXVnYSBPTiAgTDRaIDFIOA0KQ2FuYWRhDQpNVCsxIDQxNiA0MTQgNzExNzx0ZWw6KzElMjA0MTYl MjA0MTQlMjA3MTE3Pg0KRU1BbGV4YW5kZXIuU2hlcmtpbkBkYXJrbWF0dGVyLmFlPG1haWx0bzpB bGV4YW5kZXIuU2hlcmtpbkBkYXJrbWF0dGVyLmFlPg0KDQpkYXJrbWF0dGVyLmFlPGh0dHA6Ly9k YXJrbWF0dGVyLmFlPg0KDQpbTGlua2VkaW5dPGh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9jb21w YW55L2RhcmstbWF0dGVyLWxsYz4gW1R3aXR0ZXJdIDxodHRwczovL3R3aXR0ZXIuY29tL0d1YXJk ZWRieUdlbml1cz4NCg0KVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaXMgaW50ZW5kZWQg b25seSBmb3IgdGhlIHBlcnNvbihzKSBvciBlbnRpdHkgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQg YW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJ ZiB5b3UgcmVjZWl2ZSB0aGlzIGVtYWlsIGJ5IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVk aWF0ZWx5LCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0gYW5kIGZvciB3aGF0ZXZlciBwdXJwb3NlLiBBbnkg dW5hdXRob3JpemVkIHVzZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLg0KDQpGcm9tOiBNTFMgW21h aWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFybmVzDQpT ZW50OiBGZWJydWFyeSAyMiwgMjAxOSA2OjE2IFBNDQpUbzogQWxleGFuZGVyIFNoZXJraW4gPEFs ZXhhbmRlci5TaGVya2luQGRhcmttYXR0ZXIuYWU+DQpDYzogbWxzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW01MU10gTUxTIENvbXBhdGliaWxpdHkgd2l0aCBQUUMNCg0KSGkgQWxleCwNCg0KS2Fy dGhpayBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbiBhIGh5YnJpZCBQS0UgcHJpbWl0aXZlIGlu IENGUkcsIHdpdGggdGhlIGlkZWEgdGhhdCBpdCBjb3VsZCBiZSByZS11c2VkIGluIE1MUzoNCg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhcm5lcy1jZnJnLWhwa2UtMDANCg0K SW4gdGhlIENGUkcgZGlzY3Vzc2lvbiBvZiB0aGF0IGRyYWZ0LCBzZXZlcmFsIGZvbGtzIHN1Z2dl c3RlZCB0aGF0IHdlIGFkYXB0IGl0IHRvIGFjY29tbW9kYXRlIGEgZ2VuZXJhbCBLRU0uICBJIGhh dmUgYSBkcmFmdC0wMSBvZiB0aGF0IGluIHRoZSB3b3JrcyB0aGF0IGRvZXMgdGhhdC4gIFNvIHRo ZXJlIGlzIHNvbWV0aGluZyBvZiBhIHBsYW4gaGVyZSENCg0KQW5vdGhlciB0aGluZyB0aGF0IHNv bWUgZm9sa3MgaGF2ZSBvYnNlcnZlZCBpcyB0aGF0IHRoZSBsZW5ndGggZmllbGRzIGZvciBwdWJs aWMga2V5cyBhcmUgdHdvIG9jdGV0cyBsb25nLiAgV291bGQgdGhlIGtleXMgZm9yIHRoZSBzY2hl bWVzIHlvdSdyZSBpbnRlcmVzdGVkIGluIG92ZXJmbG93IHRob3NlIGZpZWxkcz8NCg0KVGhhbmtz LA0KLS1SaWNoYXJkDQoNCg0KDQpPbiBGcmksIEZlYiAyMiwgMjAxOSBhdCAzOjE2IFBNIEFsZXhh bmRlciBTaGVya2luIDxBbGV4YW5kZXIuU2hlcmtpbkBkYXJrbWF0dGVyLmFlPG1haWx0bzpBbGV4 YW5kZXIuU2hlcmtpbkBkYXJrbWF0dGVyLmFlPj4gd3JvdGU6DQpIZWxsbywNCg0KVGhlIGN1cnJl bnQgcHJvdG9jb2wgZHJhZnQgc3BlY2lmaWNhbGx5IHJlbGllcyBvbiBEaWZmaWUtSGVsbG1hbiBj cnlwdG8gcHJpbWl0aXZlLiBUaGlzIG1ha2VzIHBlcmZlY3Qgc2Vuc2Ugd2hlbiBjbGFzc2ljIGNy eXB0byBpcyB1c2VkLCBidXQgbWF5IGJlIGEgbGltaXRhdGlvbiB3aGVuIHBvc3QtcXVhbnR1bSBj cnlwdG8gKFBRQykgaXMgcmVxdWlyZWQuDQoNCklmIHdlIGFzc3VtZSB0aGF0IHBvd2VyZnVsIGVu b3VnaCBxdWFudHVtIGNvbXB1dGVycyB3aWxsIGJlY29tZSBhIHJlYWxpdHkgaW4gdGhlIG5leHQg MTAtMTUgeWVhcnMsIGFueSBkYXRhIHByb3RlY3RlZCB3aXRoIGNsYXNzaWMgY3J5cHRvIHdlIGV4 Y2hhbmdlIHRvZGF5IHdpbGwgYmUgZGVjcnlwdGFibGUgYnkgYSB0aGlyZCBwYXJ0eSBpbiAxMC0x NSB5ZWFycy4gSGVuY2UsIHVzaW5nIGNsYXNzaWMgY3J5cHRvIGZvciBuZXcgc3lzdGVtcyBtYXkg bm90IGJlIGEgZ29vZCBpZGVhLg0KDQpBdCB0aGUgc2FtZSB0aW1lLCBpdCBzZWVtcyB0aGF0IHRo ZSBwcm90b2NvbCBpcyB3ZWxsIHBvc2l0aW9uZWQgdG8gcmVseSBvbiBLRU0gY3J5cHRvIHByaW1p dGl2ZS4gUmVseWluZyBvbiBLRU0gaW5zdGVhZCBvZiBESCBhbGxvd3MgZm9yIGEgd2lkZXIgcmFu Z2Ugb2Ygb3B0aW9ucyBpbmNsdWRpbmcgUFFDIHByaW1pdGl2ZXMgc3VjaCBhcyBOZXcgSG9wZSBh bmQgQ3J5c3RhbHMgS3liZXIgbWFraW5nIHRoZSBwcm90b2NvbCBQUUMtcmVhZHkgYXQgbGVhc3Qg ZnJvbSB0aGUgY29uZmlkZW50aWFsaXR5IHBlcnNwZWN0aXZlLg0KDQpUbyBtYWtlIGl0IG1vcmUg Z2VuZXJhbCwgS0VNIHByaW1pdGl2ZSBtYXkgYmUgZGVmaW5lZCBhcyAoQywgcykgPSBLRU0tRW5j YXBzdWxhdGUoUHVibGljS2V5KSBhbmQgcyA9IEtFTS1EZWNhcHN1bGF0ZShQcml2YXRlS2V5LCBD KS4NCg0KVGhvdWdodHM/DQoNClRoYW5rIHlvdS4NCkFsZXguDQoNCg0KDQpBbGV4YW5kZXIgU2hl cmtpbiB8IFNvZnR3YXJlIEFyY2hpdGVjdA0KVGVsOiAgfCBNb2I6ICsxIDQxNiA0MTQgNzExNw0K QWxleGFuZGVyLlNoZXJraW5AZGFya21hdHRlci5hZTxtYWlsdG86QWxleGFuZGVyLlNoZXJraW5A ZGFya21hdHRlci5hZT4NCg0KVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkLCBpbmNsdWRpbmcg YXR0YWNobWVudHMsIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24ocykgb3IgZW50aXR5 IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZC9vciBwcml2aWxlZ2VkIG1hdGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlz c2VtaW5hdGlvbiBvciBvdGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJl bGlhbmNlIHVwb24gdGhpcyBpbmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVy IHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZWQgdGhpcyBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVzdHJveSBh bnkgY29waWVzIG9mIHRoaXMgaW5mb3JtYXRpb24uDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxpc3QN Ck1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbHMNCg== --_000_956c4f3a40594c889fd9ac5197c57258darkmatterae_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xh aW1lciBTaWduYXR1cmUgTWFuYWdlciBFeGNoYW5nZSBFZGl0aW9uIG9uIDEyOjAwOjUxIFR1ZXNk YXksIDI2IEZlYnJ1YXJ5IDIwMTkgLS0+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiPlAuSW1wcmludFVuaXF1ZUlEIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpMSS5JbXBy aW50VW5pcXVlSUQgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5JbXByaW50VW5pcXVl SUQgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NClRBQkxFLkltcHJpbnRVbmlxdWVJRFRhYmxl IHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rp b24xDQp9DQo8L3N0eWxlPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3Nv ZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZp bml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+TmljZS4gSSB0aGluayB0aGUgS0VNLWJhc2VkIGFwcHJvYWNo IHdpbGwgbWFrZSBpdCBtdWNoIHNpbXBsZXIgZm9yIFBRQyBjaXBoZXIgc3VpdGUgaW50ZWdyYXRp b24uIEFub3RoZXIgcGFydCBpcyBhbGxvd2luZyBmb3IgUFFDIHNpZ25hdHVyZXMNCiBzdWNoIGFz IFNQSElOQ1MuIEFyZ3VhYmx5LCBQUUMgYXV0aGVudGljaXR5IG1heSBub3QgYmUgc3VjaCBhbiB1 cmdlbnQgcHJvYmxlbSBiZWNhdXNlIGFuIGF0dGFja2VyIG5lZWRzIGEgcXVhbnR1bSBjb21wdXRl ciBub3cgdG8gYmUgYWJsZSB0byBhdHRhY2sgbWVzc2FnZSBhdXRoZW50aWNpdHkuIEluIGNvbnRy YXN0LCBtZXNzYWdlcyBpbnRlcmNlcHRlZCBhbmQgcmVjb3JkZWQgbm93IG1heSBiZSBkZWNyeXB0 ZWQgYnkgYSBxdWFudHVtIGNvbXB1dGUNCiBpbiB0aGUgZnV0dXJlOyBoZW5jZSwgdGhlIHVyZ2Vu dCBuZWVkIGZvciBQUUMgZm9yIGNvbmZpZGVudGlhbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkt5YmVyIHB1YmxpYyBrZXkgbGVuZ3RoIGlzIGFib3V0IDEuNUti LCBhbmQgcHJpdmF0ZSBrZXkgbGVuZ3RoIGlzIGFib3V0IDNLYi4gU3BoaW5jcyYjNDM7IHB1Ymxp YyBrZXkgaXMgNjQgYnl0ZXMsIGFuZCB0aGUgcHJpdmF0ZSBrZXkgaXMNCiAxMjggYnl0ZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ud28gb2N0ZXQgbGVuZ3RoIGlz IHByb2JhYmx5IGZpbmUgZm9yIExhdHRpY2UtYmFzZWQgc2NoZW1lcy4gSG93ZXZlciwgQ29kZS1i YXNlZCBjcnlwdG8gc2NoZW1lcyBtYXkgaGF2ZSBwdWJsaWMga2V5cyBvbiB0aGUgb3JkZXIgb2YN CiAxIE1iLiBDb2RlLWJhc2VkIGNyeXB0byBtYXkgYmUgY29uc2lkZXJlZCBhcyBvbmUgb2YgdGhl IG1vc3QgY29uc2VydmF0aXZlIGNob2ljZXMgc28gc3VwcG9ydGluZyBDb2RlLWJhc2VkIGNyeXB0 byB3b3VsZCBiZSBuaWNlIGlmIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5BbGV4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxicj4NCjxi cj4NCjx0YWJsZSBjbGFzcz0iSW1wcmludFVuaXF1ZUlEVGFibGUiIHN0eWxlPSJCT1JERVItQ09M TEFQU0U6IGNvbGxhcHNlIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIx MDAlIiBib3JkZXI9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIzNTAiPjxmb250IHN0 eWxlPSJmb250LWZhbWlseTpWZXJkYW5hO2ZvbnQtc2l6ZToxMHB0O2NvbG9yOiM5NkQ3MDA7Zm9u dC13ZWlnaHQ6Ym9sZDsiPkFsZXhhbmRlciBTaGVya2luPC9mb250Pjxicj4NCjx0YWJsZSBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hOyBm b250LXNpemU6OXB0OyBjb2xvcjojMDAwMDAwOyB0ZXh0LWFsaWduOiBsZWZ0OyB2ZXJ0aWNhbC1h bGlnbjogdG9wOyIgY2xhc3M9IjY3ZTBkZWY1LWNiNzYtNGQyYi05ZGQyLWRhYjIwYjZhY2E1OFRh YmxlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0idGV4dC1hbGlnbjogbGVmdDsgdmVydGljYWwtYWxp Z246IHRvcDsgIj4NCjx0ZCBhbGlnbj0iTm90U2V0IiBzdHlsZT0iIj48Zm9udCBzdHlsZT0iZm9u dC1mYW1pbHk6VmVyZGFuYTtmb250LXNpemU6OXB0O2NvbG9yOiMwMDAwMDA7Ij48L2ZvbnQ+PC90 ZD4NCjx0ZCBhbGlnbj0iTm90U2V0IiBzdHlsZT0iIj48Zm9udCBzdHlsZT0iZm9udC1mYW1pbHk6 VmVyZGFuYTtmb250LXNpemU6OXB0O2NvbG9yOiMwMDAwMDA7Ij5Tb2Z0d2FyZSBBcmNoaXRlY3Q8 L2ZvbnQ+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxicj4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPGJyPg0KPHRkIG5vd3JhcD0iIj48YSBocmVmPSJodHRwOi8vd3d3LmRhcmttYXR0 ZXIuYWUiIHRhcmdldD0iIj48aW1nIHdpZHRoPSIyMTkiIGhlaWdodD0iMzYiIHN0eWxlPSJib3Jk ZXI6IDBweCBTb2xpZCA7ICIgc3JjPSJjaWQ6aW1hZ2UyYzA3YWUuUE5HQGVmOTJkY2U5LjQyODU3 NGFlIj48L2E+PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxmb250IHN0eWxlPSJG T05ULVNJWkU6IDhwdDsgQ09MT1I6ICNhMWExYTEiIHNpemU9IiYjNDM7MCI+PGZvbnQgY29sb3I9 IiNhNWE1YTUiPjxicj4NCjxmb250IHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5hO2ZvbnQtc2l6 ZTo4cHQ7Y29sb3I6QmxhY2s7Ij4yIFJvYmVydCBTcGVjayBQYXJrd2F5LCBTdWl0ZSAxNjEwPGJy Pg0KTWlzc2lzc2F1Z2EgT04gJm5ic3A7TDRaIDFIODwvZm9udD48YnI+DQo8Zm9udCBzdHlsZT0i Zm9udC1mYW1pbHk6VmVyZGFuYTtmb250LXNpemU6OHB0O2NvbG9yOkJsYWNrOyI+Q2FuYWRhPC9m b250Pjxicj4NCjxmb250IGNvbG9yPSJibGFjayI+PGZvbnQgZmFjZT0iVmVyZGFuYSI+PHN0cm9u Zz48Zm9udCBjb2xvcj0iIzk2ZDcwMCIgc2l6ZT0iMSI+TTxmb250IGNvbG9yPSIjZmZmZmZmIj5U PC9mb250PjwvZm9udD48L3N0cm9uZz48L2ZvbnQ+PC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpWZXJkYW5hO2ZvbnQtc2l6ZTo4cHQ7Y29sb3I6QmxhY2s7Ij48YSBocmVmPSJ0ZWw6JiM0 MzsxIDQxNiA0MTQgNzExNyIgdGl0bGU9IiIgdGFyZ2V0PSIiIHN0eWxlPSJmb250LWZhbWlseTpW ZXJkYW5hO2ZvbnQtc2l6ZTo4cHQ7Y29sb3I6QmxhY2s7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6VmVyZGFuYTsgZm9udC1zaXplOjhwdDsgY29sb3I6QmxhY2s7Ij4mIzQzOzENCiA0MTYgNDE0 IDcxMTc8L3NwYW4+PC9hPjwvc3Bhbj48YnI+DQo8Zm9udCBmYWNlPSJWZXJkYW5hIj48Zm9udCBj b2xvcj0iIzk2ZDcwMCIgc2l6ZT0iMSI+PHN0cm9uZz5FPGZvbnQgY29sb3I9IiNmZmZmZmYiPk08 L2ZvbnQ+PC9zdHJvbmc+PC9mb250PjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVy ZGFuYTtmb250LXNpemU6OHB0O2NvbG9yOkJsYWNrOyI+PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRl ci5TaGVya2luQGRhcmttYXR0ZXIuYWUiIHRpdGxlPSJDbGljayB0byBzZW5kIGVtYWlsIHRvIEFs ZXhhbmRlciBTaGVya2luIiB0YXJnZXQ9IiIgc3R5bGU9ImZvbnQtZmFtaWx5OlZlcmRhbmE7Zm9u dC1zaXplOjhwdDtjb2xvcjpCbGFjazsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpWZXJkYW5h OyBmb250LXNpemU6OHB0OyBjb2xvcjpCbGFjazsiPkFsZXhhbmRlci5TaGVya2luQGRhcmttYXR0 ZXIuYWU8L3NwYW4+PC9hPjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6VmVyZGFuYTtmb250LXNpemU6OHB0O2NvbG9yOiM5NkQ3MDA7Zm9udC13ZWlnaHQ6Ym9sZDsi PjxhIGhyZWY9Imh0dHA6Ly9kYXJrbWF0dGVyLmFlIiB0aXRsZT0iIiB0YXJnZXQ9IiIgc3R5bGU9 ImZvbnQtZmFtaWx5OlZlcmRhbmE7Zm9udC1zaXplOjhwdDtjb2xvcjojOTZENzAwO2ZvbnQtd2Vp Z2h0OmJvbGQ7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYTsgZm9udC1zaXplOjhw dDsgY29sb3I6Izk2RDcwMDsgZm9udC13ZWlnaHQ6Ym9sZDsiPmRhcmttYXR0ZXIuYWU8L3NwYW4+ PC9hPjwvc3Bhbj48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20v Y29tcGFueS9kYXJrLW1hdHRlci1sbGMiIHRhcmdldD0iIj48aW1nIHdpZHRoPSIzMiIgaGVpZ2h0 PSIzMiIgc3R5bGU9ImJvcmRlcjogMHB4IFNvbGlkIDsgIiBzcmM9ImNpZDppbWFnZTg5OTBlNy5Q TkdAOTExZDVlMjIuNGQ4NjgyMWMiIGFsdD0iTGlua2VkaW4iPjwvYT4mbmJzcDs8YSBocmVmPSJo dHRwczovL3R3aXR0ZXIuY29tL0d1YXJkZWRieUdlbml1cyIgdGFyZ2V0PSIiPjxpbWcgd2lkdGg9 IjMyIiBoZWlnaHQ9IjMyIiBzdHlsZT0iYm9yZGVyOiAwcHggU29saWQgOyAiIHNyYz0iY2lkOmlt YWdlN2I2NmU3LlBOR0BkNzM2NDk4NS40ODkwYWY0MyIgYWx0PSJUd2l0dGVyIj48L2E+DQo8cCBp ZD0idW5kZWZpbmVkIj48L3A+DQo8YnI+DQo8Zm9udCBzaXplPSIxIiBmYWNlPSJWZXJkYW5hIj5U aGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVy c29uKHMpIG9yIGVudGl0eSB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElmIHlvdSByZWNlaXZlIHRo aXMgZW1haWwgYnkgZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHksIGRlbGV0ZQ0K IHRoZSBvcmlnaW5hbCBtZXNzYWdlIGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24sIHVzZSBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtIGFuZCBmb3Igd2hhdGV2ZXIgcHVycG9zZS4gQW55IHVuYXV0aG9yaXplZCB1 c2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC48YnI+DQo8L2ZvbnQ+PC9mb250PjwvZm9udD48YnI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBNTFMgW21haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+UmljaGFyZCBCYXJuZXM8YnI+DQo8Yj5TZW50OjwvYj4gRmVicnVhcnkg MjIsIDIwMTkgNjoxNiBQTTxicj4NCjxiPlRvOjwvYj4gQWxleGFuZGVyIFNoZXJraW4gJmx0O0Fs ZXhhbmRlci5TaGVya2luQGRhcmttYXR0ZXIuYWUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBtbHNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTFNdIE1MUyBDb21wYXRpYmlsaXR5IHdp dGggUFFDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgQWxleCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+S2FydGhpayBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbiBhIGh5YnJp ZCBQS0UgcHJpbWl0aXZlIGluIENGUkcsIHdpdGggdGhlIGlkZWEgdGhhdCBpdCBjb3VsZCBiZSBy ZS11c2VkIGluIE1MUzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJh cm5lcy1jZnJnLWhwa2UtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYmFybmVzLWNmcmctaHBrZS0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIENGUkcgZGlzY3Vzc2lvbiBv ZiB0aGF0IGRyYWZ0LCBzZXZlcmFsIGZvbGtzIHN1Z2dlc3RlZCB0aGF0IHdlIGFkYXB0IGl0IHRv IGFjY29tbW9kYXRlIGEgZ2VuZXJhbCBLRU0uJm5ic3A7IEkgaGF2ZSBhIGRyYWZ0LTAxIG9mIHRo YXQgaW4gdGhlIHdvcmtzIHRoYXQgZG9lcyB0aGF0LiZuYnNwOyBTbyB0aGVyZSBpcyBzb21ldGhp bmcgb2YgYSBwbGFuIGhlcmUhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgdGhpbmcgdGhhdCBzb21lIGZvbGtzIGhhdmUgb2JzZXJ2 ZWQgaXMgdGhhdCB0aGUgbGVuZ3RoIGZpZWxkcyBmb3IgcHVibGljIGtleXMgYXJlIHR3byBvY3Rl dHMgbG9uZy4mbmJzcDsgV291bGQgdGhlIGtleXMgZm9yIHRoZSBzY2hlbWVzIHlvdSdyZSBpbnRl cmVzdGVkIGluIG92ZXJmbG93IHRob3NlIGZpZWxkcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1SaWNoYXJkPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEZyaSwgRmViIDIyLCAyMDE5IGF0IDM6MTYgUE0gQWxleGFuZGVyIFNoZXJr aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuU2hlcmtpbkBkYXJrbWF0dGVyLmFlIiB0 YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlNoZXJraW5AZGFya21hdHRlci5hZTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGVsbG8sPGJyPg0KPGJyPg0KVGhlIGN1cnJlbnQgcHJvdG9jb2wgZHJhZnQgc3BlY2lm aWNhbGx5IHJlbGllcyBvbiBEaWZmaWUtSGVsbG1hbiBjcnlwdG8gcHJpbWl0aXZlLiBUaGlzIG1h a2VzIHBlcmZlY3Qgc2Vuc2Ugd2hlbiBjbGFzc2ljIGNyeXB0byBpcyB1c2VkLCBidXQgbWF5IGJl IGEgbGltaXRhdGlvbiB3aGVuIHBvc3QtcXVhbnR1bSBjcnlwdG8gKFBRQykgaXMgcmVxdWlyZWQu PGJyPg0KPGJyPg0KSWYgd2UgYXNzdW1lIHRoYXQgcG93ZXJmdWwgZW5vdWdoIHF1YW50dW0gY29t cHV0ZXJzIHdpbGwgYmVjb21lIGEgcmVhbGl0eSBpbiB0aGUgbmV4dCAxMC0xNSB5ZWFycywgYW55 IGRhdGEgcHJvdGVjdGVkIHdpdGggY2xhc3NpYyBjcnlwdG8gd2UgZXhjaGFuZ2UgdG9kYXkgd2ls bCBiZSBkZWNyeXB0YWJsZSBieSBhIHRoaXJkIHBhcnR5IGluIDEwLTE1IHllYXJzLiBIZW5jZSwg dXNpbmcgY2xhc3NpYyBjcnlwdG8gZm9yIG5ldyBzeXN0ZW1zIG1heQ0KIG5vdCBiZSBhIGdvb2Qg aWRlYS48YnI+DQo8YnI+DQpBdCB0aGUgc2FtZSB0aW1lLCBpdCBzZWVtcyB0aGF0IHRoZSBwcm90 b2NvbCBpcyB3ZWxsIHBvc2l0aW9uZWQgdG8gcmVseSBvbiBLRU0gY3J5cHRvIHByaW1pdGl2ZS4g UmVseWluZyBvbiBLRU0gaW5zdGVhZCBvZiBESCBhbGxvd3MgZm9yIGEgd2lkZXIgcmFuZ2Ugb2Yg b3B0aW9ucyBpbmNsdWRpbmcgUFFDIHByaW1pdGl2ZXMgc3VjaCBhcyBOZXcgSG9wZSBhbmQgQ3J5 c3RhbHMgS3liZXIgbWFraW5nIHRoZSBwcm90b2NvbCBQUUMtcmVhZHkgYXQgbGVhc3QNCiBmcm9t IHRoZSBjb25maWRlbnRpYWxpdHkgcGVyc3BlY3RpdmUuPGJyPg0KPGJyPg0KVG8gbWFrZSBpdCBt b3JlIGdlbmVyYWwsIEtFTSBwcmltaXRpdmUgbWF5IGJlIGRlZmluZWQgYXMgKEMsIHMpID0gS0VN LUVuY2Fwc3VsYXRlKFB1YmxpY0tleSkgYW5kIHMgPSBLRU0tRGVjYXBzdWxhdGUoUHJpdmF0ZUtl eSwgQykuPGJyPg0KPGJyPg0KVGhvdWdodHM/PGJyPg0KPGJyPg0KVGhhbmsgeW91Ljxicj4NCkFs ZXguPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQWxleGFuZGVyIFNoZXJraW4gfCBTb2Z0d2FyZSBB cmNoaXRlY3Q8YnI+DQpUZWw6Jm5ic3A7IHwgTW9iOiAmIzQzOzEgNDE2IDQxNCA3MTE3PGJyPg0K PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5TaGVya2luQGRhcmttYXR0ZXIuYWUiIHRhcmdldD0i X2JsYW5rIj5BbGV4YW5kZXIuU2hlcmtpbkBkYXJrbWF0dGVyLmFlPC9hPjxicj4NCjxicj4NClRo ZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCwgaW5jbHVkaW5nIGF0dGFjaG1lbnRzLCBpcyBpbnRl bmRlZCBvbmx5IGZvciB0aGUgcGVyc29uKHMpIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRy ZXNzZWQgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQvb3IgcHJpdmlsZWdlZCBtYXRl cmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRpb24gb3Igb3RoZXIg dXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlvbg0KIGluIHJlbGlhbmNlIHVwb24gdGhpcyBp bmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGludGVuZGVk IHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVzdHJveSBhbnkgY29waWVzIG9mIHRoaXMg aW5mb3JtYXRpb24uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpNTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk1MU0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21scyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_956c4f3a40594c889fd9ac5197c57258darkmatterae_-- --_006_956c4f3a40594c889fd9ac5197c57258darkmatterae_ Content-Type: image/png; name="image2c07ae.PNG" Content-Description: image2c07ae.PNG Content-Disposition: inline; filename="image2c07ae.PNG"; size=5249; creation-date="Mon, 25 Feb 2019 20:00:51 GMT"; modification-date="Mon, 25 Feb 2019 20:00:51 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAANsAAAAkCAYAAAAAR0+MAAAACXBIWXMAAC4iAAAuIgGq4t2SAAAU M0lEQVR4Xu2cacx2R1nH4aVsiqGlUBCQsre0BWnRPng/qOwNUCKgggJC3eISXJAghgDiEiJGKWug GpREoSprRJYQsQhhkS0CCpZFEaiAIHsBWf3/rnNdM9fMmXPuu/cX3w/Ph987M9c2c5brnjlzzvNe 6exzDx8mKMXGy8o5pb5J9e1gm+2jPYqxJA+yb0/oc7krOU4Q8pFtL1tj2Z5zHMz11a+1Qb4PEWOq r8cK/YiRPYxsd2fbOVjqoz2mtXE0sQ7mtrRHsqke12C3/pb0tIHGR1V56qSYH3x1PEq2XrbGsn17 AXuqX2uDfB8ixlRfjxX6ESN7GNnuzrZzsNRHe0xr42hiHQfJ9j5Vvq3ywtHBV8ejZOtlayzbtxew p/q1Nsj3IWJM9fVYoR8xsoeR7e5sOwdLfbTHtDaOJtb/d7Lpn38VJBs8XVwljKA6HiVbL1tj2b69 gD3Vr7VBvg8RY6qvxwr9iJE9jGx3Z9s5WOqjPaa1cTSxjodkk8CSTXXKPxNXxQiq41Gy9bI1lu3b C9hT/Vob5PsQMab6eqzQjxjZw8h2d7adg6U+2mNaG0cT6zhYRpZkAwkpnydshquOR8nWy9ZYtm8v YE/1a22Q70PEmOrrsUI/YmQPI9vd2XYOlvpoj2ltHE2s4yHZVLEkCySzGU71qwp3Okq2XrbGsn17 AXuqX2uDfB8ixlRfjxX6ESN7GNnuzrZzsNRHe0xr42hiHS8zmxpldgske6G4muqyO0q2XrbGsn17 AXuqX2uDfB8ixlRfjxX6ESN7GNnuzrZzsNRHe0xr42hiHU/LSAlGSfci8R102AdZQ7bXFNdS/TtB 9YLL0F1DlMFQHxH6EdKXmCpLzB04hl+P5KVMnCDZKEbPCcKO2WNQ9x+roLmA1xTlHFGX33VUXtlt VE464gn0nNfhuRjh/eRjIsY1sk0g3YhyPALfq4U9dLac+3w8W9gMZIdXVlz2DPJ57Jj8Qjewwdf2 HaTjHOr+ld3B3Jb2QIa/3fOOxQi73j5wuZ0flQXaQKN5ZgMp+vYr1SGdNUEgAg0gST8i/jOQzPA2 ug+o/SbxBHGa2rP4W/hhUWKrJOa7NNZT0okypO+5qXi/iPHksWXZh1Wy1H61yp8RJEP03/NAYcdM LEH9Ca5zYkyH9xEfEh+JflV+UjxVN8Wxs/UrLNmN1ObVTIwN239XeZ79Svcofo9sn+Wx45gY08UC XaH3c35FunI81FW+OumbGOJ5kpl9oHbue9YOmdc5tuuLXxL5PM58RiQ7fH9KMKYThe6Juf0SioH/ P4qri1mMPJbBuP5N/IPgGK4nyrninw9K0CTXAq+SLZmbT24J1CPdW8TSbGl08q+I54pri6aPJeT/ GpWljxTvt3OigXQ9t5LdN1WaD2XUt/Af4kdEGUfi50Rjr5jPEH3fZ4rPiMnuoNi/TrKT3AZOlexr rsvj+7R8zrKEzMin45FidFyvFyP7DLPUe/HN/l4/b3ReJS/XI9tfkbbgB+axIc8km4Ze5+1HCMbE j+MXQx62uR7tTk7i2ApAx3kdlRZjRPIppfNR8SBiAIP59aQs5ADRVqkZrk04flFzO/EGkX135W3i u8UoZubW4qsRu+vjUtGOc84tJf+KyuKf62ul+F9xruhj/7TrMxcKH4fdnNdV/V9cZ3jcD0ivX8Jm uX4T8SVswO2ifK+4XrK1+JXD+0j3TZV53FF/rXCfCeJ03F80vuDtF6d+vLT6K8JuiYiX46Z+vi5u qPpjttg1hLzVbTSz2JhItv/JuqiP/FJd16Mst0uMbLtE2LntN1TeVaUlG/xCNoo65QCmyDL7rCTb P/cxcntNJ96h9nepLPHU7vldtzVfyG2VDxaNf26LkmzZt2ekc9lLRYntzJJNsgvRYaeLzzMay5M+ 7ifUPv0cv2mxd5pkC/AF1V+vsjzDTTeXcSDd53qf1J4lWwfPKH8vRr7AKuR2ovfj3ig+A7+hLHAf ZrbH9/Lc7uV96fVfFYzJEiXJi80WPiGUbHY9mNkWY0SbMteTDRPICeVEScmNQhaOjPtAzFo3EEvL F+D55om68M7hE+VnZaD2H6v8JzHrRzxTxE3Xxz5ZfFLMxpZ4sygv5wfcUj7cNNmX57N7irtKxq8R sPZ+5yD+FyW7scjPS2szG+8t/8pluU8u4sb9e0qyqR72BZddrPLY9KNniXZzyT6c7fu6aJJN7QbJ vg/bQLJZDJVPER4jkvzwHoLrznkIHi6aVY77/6Hrels2Jm4rm58VWXeBeJL7FtR+h+vMzn00hs3p PqZmVnL/j4tHCVZ1huSlLh6p9gUiNsZKwro/0L6v2vlewecS1/fEySonmYfKsvQA6rmdZGTrKTXZ 7MAGlAsRfRS8zQ7eY8S3IraXXxVnZv/Ez6dxhA9Lu172AyLfRBmb2US2f49K02d71U8VzVLEuZvr Ay50bxM3JTeXyYjjsXgeu5cofXUMZ7bAY1D+gSc8q4G3hTzbBS6bJVtui78UxTfqGck/q9I2ABau UeYiEX4R846uG1Bn9053tmjGIf5GFJvqM41J7WZmc94tig/0fXX9j2bH/xKWjJ0vjy/9V1mUDy1G yYEdteZZhjLXU/lGldMMt3jCq1z2ST5rN0sH5zdFtgG2ht/NGEBt4MIzA33L24b0eraovl1/TbJ5 LE5SbBn39rb86+gThV/W3uZ3JHt4yCm9rrFuHlbPz+jcLT+zRT21HyGY5RpdtknttZntxpJ9XmR7 Vh+/38mAWSCPdwk+kOjHzIwwshWLyXYnEf4R6yWi2GQfj2FLwGQPbPywpNcP/YbrbUgWXEXkWKOE ZXa0x6lqW67jX2AjWRrn5oIIlgMDzzs2w2WqYwMznBJu6aapsq6P1DYb3kexjCv9qHwlNp3fvdXu Z8GL5c9JKh9VU4rLVWdZlf2DUbKVmQ0kizon++MR2/m62mdgk+xGyUYCXx7yVD66npt6jjpGyfYZ Yc9jua8+ftQFN8XXOv3iM5v0v6eyiaHylwU3lsWJWOL9ovlwfQG+ty0xHds0GLN7sql8SdguMEo2 Vk1sMHG/cH0M6uJ9qv+WyP3Okk12zGzl2NXO9m9X28YIasP5xSAbe/2BKssMNwKdo5t0c9b4xqlt 2SX5vC3Y7czxeQ92dewCyV+ebdzufNf9hsqQGar/kch9BKNkY6v2x8X9QTLKhwhuTrNL6Dlkc4xj k10wWkY20A+o3r1/q8eYsGRTmWOwBGL5Wm6gvgzU5nnm3oIfhtK3WEq2a0vHu64ch8TmnSTj+Wtk xEj6HxOjWJkysyXfvZIt/COW2CfZSoxe5jxT5H6bDRLns5Jxb+R75UHCzhEQ3/vg/eRJOeBsoJLd T3xB9dxJM0ivayAb/erkZJsSbInoo+NvRY7LO8D8lQlrdnvvhN55j4iEvJl0/TPOx4Q/WzTYBomI vnLM7F/o5A8Q/bFYsoVdZ9+3WTmwoVDG5DEyJdlAdWBLGvs7C2a5HDPDKoFZndnXZCnGUrKVmTnZ Ph+d2sCqIuRhw65lE8dtMzazqcx+W5NtoCszG3icWbJJlimzkttbmUGWkexpIscqydbb0w6yPOtV 2ju/PKilwd5dss/lYF39MnH7XZMskM9Ibn/IGqh9icXj4X/aAHiGZM0YVPL1iXxL33zhUPQOz3PR R1BmthSrKVd40sJx2s2a/XPMgZwvFUY/BMFsZlPd3v/48XLDfiF0rgeSkB8mYvAaoOi8fK0o13va 3rZnF165lFiCl/752Yqlvj0vux54Tt6IsBkxm9lUWtwRC+cWhskmRrZBk2wOjyG80+OHm1mfuuF1 dslnMfBVGf3245jh8ov8Wg2T7baqc4H4djBkdxGfliwHoeRrittjEwHV3onJp8QHNhHKFx0O79JC f33RP7jT5oE+x2E71sYYSM/XLP0YytZ/j/uMZB9Tyda2/IfHO3pmC9jhK89OCZYdvNfqY8FoGZmS zY6Xz76yDc+p56FzePme/aHMbPIL7kyMFIc6S1Ybm9vA48OG0uvPcV0Bn8RsZhOLybbC1g2SAc2s 5HxQ8J7wjIx+0CnPku4GwvpU22IIiwGSR99D0AvenfoG0nSvRDBDyjuKT+Eg3qI6LwZPE+i+X7L/ dh1cJuzFJvrBjbfK5DOV4r6ql0RSO0p7/4SdeHTIE6MXy3wQyqc2EYOSJdsPhR2lmG39C3Y1+b6P m+NS983w5Uf4jyjPbPgGaj/Zzw83ZdGncjTzwk2k75fFfGliS2uQHjh/8Y6U3eSsOxd5RrrRMvLP RenHbA8OHxefgqkd3EZ62/X1WMB9cZIo/UbdsZlNZR7Hysy2SDOzgex3XkYmmJ0ne47PbX31NNVb 3SzZxJdV5wdU98rmnUkefbB51HzFVCqCj3oj0bITv5QvVZuNg58UzHBsJGjpOPlKl+ME5wiWOUPk Q8l7vReI6Kv0q3I6idMJ4INQPtotds7dhfVnthU2H3pbzSDTL4zFPJhvkAjbjSSGSmZ4jr2P8ydx AxqTbdAkm9f/Tmh2sL75vMqOw/sLW5aCZ4k+XrMbCbLl4+3y1b5kASsD+2qik5dkUz0oy0i34VmX H5psw810pjCbsBeseF7lNobalI+K82vnuPUpyZbsuf7R/66UDZLEFVpGesmKjGfeO+k+IIEL0kV5 B+n8Y4F2GQmqp93IDeePj8hDF3Yv9nvNsAFJyYP6bGbJdS8/pZLteKZbOgl/Kzveik+gdomT2z2u u0yDO9UGaRduw3d+vR/LKd6VWH/5oMRtZHu5kiHbK3E2p8WYxWgZWd6zOb/W9Rk8VEz9tox2I3mZ bXpKcb5oPoCmFDwvlZ1XtWGYbCrLzJYJ3+QPs2Wk9H2yjd5xllXDAH54++vBrF+uR8f8PduBfnDb a1ZIfj07JRvHlSi7kRnZNfVBm69w/EPkNtm85FUQu7fRL/8lZNYH/OWE2fDPA6Rc3OJHnnRc6Fup 7R2UG3dE+UQniDi5DJIdvxh3EBGHZwZmh8ZO9SeLclIl6+Ei5LiQNzZGy0jes6S/Tj88Jvhrh2Lj dTaM7DwkW5gtI1VPHyIXLnJdg2S8AM8xS7Il+63J1smbZaTakJeR3DD9O0RgJzrHybA8YpmUY1L/ UTEaRzOzgdpbNkiGzJaRYueZDRS/KTPIkjzvhJdkS/rZS239UPCnS6GPeLzTs/sZI/7+JgeZ4Tp+ uewFsdp+IJyA5sAKsuHrkuy/C/zpB88E9QCm5ZzpUxySZNvfv7E1X3y81EnfXJdxq02ylT9fcRte aKaZzS4w/bOkamIJkrB8ruOweRL64GlTrMbuZMEzbx5boOVVOa8km/0ghI3KD4myjAS3nbWdA8li LBGD7/fCvvm6hVKw1M0z/Ag9hxb7gBlz9AkT/6dNP4a7hV1P8uv5QdH3+TIxsg1IlNlH2UG0s87r nIM8s/Ux+DZ3+iC/zsZ8TcVkke2Av4U7EQPepBcluEGpq8SGC29BJfPgy8km+NussqUaIEvwN0Ks n19+zsGGl69lV0664NniG5LlOOXLkgCfDr655Aci982D/S8KfG6hkv5z3HdJbjNbjqk6fxdm28SB ZJwX220Ke8GNG3pD9bKNjE3UxU+IL4e9wybHpTqv8TrgewQXOWIBr0eaZAPJ+/gBG1vFn1K8Blv9 EnOO+AIoYgePFU2cvMxzbqEYvGIocVVyneiv8RV/KpoxqLyL664IhyKOIeC/7pidiwSJQmJY3yPk M5KX86z6KAb7FuWvXxK83ObHOduSR09ByXNKSTRX5GR7q0rbXg98AGI12W4qeMCetlWdqKNTyc3E n6zr4i3GYgbDNnzZmj156rsi2QjGbb66OaxPwcMsNwt/vs4sGnHRkYBpG77EZznJc6DZgtszNrc3 O/6iNx8zmx7+7egsJm3+gFX2m7CH71VdccyG2eX06Jc+Bc+afB/aHKv0TTvBn+BYbGIIxscfpaLj G0A/rmkMKtF3/5WDbOfJBiRcuTbCro2wvpP/DUW+hvTR7NS15HPUwL3icWy8xOEekm7Rn00MrlOM cReIq5UP/x0CMWwjJMeQfnNrYV8QQXde/Lo28c4g0CzZAh0UiXaKwK5QT6QNZCfwCb++tPpyshnZ Z6pPB1kONukyxUcnoYnHScntVK/kPrbZV7tgl5hVNtlXn2oTstCP2KaHKW6l1cV48rgq6UZqQZft Etk/dLlcJo59RPhP9TFzn/1Y88/xZ8nmNi0MvHy823GJ5PxV8cypnqylgczBJ/z60upHyWb21afa hCz0I7bpYYpbaXUxnjyuSr6RGtBlu0T2D10ul4ljHxH+U33M3Gc/1vxz/B2TTf/YzKYDyMvH14kT l05KlS8NZA4+4deXVj9KNrOvPtUmZKEfsU0PU9xKq4vx5HFV8o3UgC7bJbJ/6HK5TBz7iPCf6mPm Pvux5p/j75FslIKdKv4SevGkVPnSQObgE359afWjZDP76lNtQhb6Edv0MMWttLoYTx5XJd9IDeiy XSL7hy6Xy8Sxjwj/qT5m7rMfa/45/hVINg0+Eo0vA3jIN+XSSanypYHMwSf8+tLqR8lm9tWn2oQs 9CO26WGKW2l1MZ48rkq+kRrQZbtE9g9dLpeJYx8R/lN9zNxnP9b8c/wdk00Dt2QTs/+qbjqoOVW+ NJA5+IRfX1r9KNnMvvpUm5CFfsQ2PUxxK60uxpPHVck3UgO6bJfI/qHL5TJx7CPCf6qPmfvsx5p/ jr/7zMab8FfoAPiAt1EunZQqXxrIHHzCry+tfpRsZl99qk3IQj9imx6muJVWF+PJ46rkG6kBXbZL ZP/Q5XKZOPYR4T/Vx8x99mPNP8ffPdn4aNcSrT8JSyelypcGMifH70urHyWb2VefahOy0I/Ypocp bqXVxXjyuCr5RmpAl+0S2T90uVwmjn1E+E/1MXOf/Vjzz/F3SbbDK/0fVHbyZgY1MwUAAAAASUVO RK5CYII= --_006_956c4f3a40594c889fd9ac5197c57258darkmatterae_ Content-Type: image/png; name="image8990e7.PNG" Content-Description: image8990e7.PNG Content-Disposition: inline; filename="image8990e7.PNG"; size=663; creation-date="Mon, 25 Feb 2019 20:00:51 GMT"; modification-date="Mon, 25 Feb 2019 20:00:51 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAACXBIWXMAAA7DAAAOwwHHb6hkAAAC SUlEQVRYR2NgSJv5f0AxVkF6YqyC9MRYBemJsQrSE2MVhOHUGRCMTY5aGKsg0FK5ssX/i1ce/d+x /fx/30nb/jNhU0cNjE2QO2vO/xvP3/+HgV9//v5PmLePNqGBTdCxcyPUagTYcvEB/RwgX7r4/8/f f6BWQ0DPzgv/GVLo5ACQReHTd/0/df/l/xsv3v+fd/j6fx5gtGBVSynGKgjCwOBmz5j1nzd7zn9G UoIepJYU9dgEQSneZ+K2/37A1A/DylXLwAYrVyxFEXfv2/yfI3P2f9GC+f+jZ+0GRtXF//17Lv1P W3Dgv1L5EsKOwSbIkTX7//dfqGmgeNUxsGG5Sw5BRSDg6fsv/127Nvy/9uzd/7///kFF////B2S/ /PTtf+TM3fgdgU0Q4oDfUKMgoAjqgMyFB6AiEPDlx6//Lz5+g/Iwwdefv/87dW/E7QhsgqQ4AAY+ ff/5/+rTd/+/AS1EB1suPvzPkDwdwx4wxiZIqgN2Xnn0XzB37n+GpGn/FYAl6JUnb6EyEAByFBfQ TGx2UeyAz8AoMGhYhdAPVJO3/AhUFgGUK4AJEskOOMYmSIoDnn34+l+qaCGKfve+LVBZBNCqWY6i Bo6xCVLqADdg1kQHw8cBOYtRywG6O6Bg2WGoCASMOoAmDmAD1oLrzt37vxnYCIHhwGk7wQ7wn7wd RXzR8Zv/hfLmoeg3alqDogaE5YBtDGQ1cIxVMBWIQUUnMoY1RkA0uhzQYaj6iVADw1gF6YmxCtIT YxWkJ8YqSE+MVZBueOZ/ABxdinkisai7AAAAAElFTkSuQmCC --_006_956c4f3a40594c889fd9ac5197c57258darkmatterae_ Content-Type: image/png; name="image7b66e7.PNG" Content-Description: image7b66e7.PNG Content-Disposition: inline; filename="image7b66e7.PNG"; size=803; creation-date="Mon, 25 Feb 2019 20:00:51 GMT"; modification-date="Mon, 25 Feb 2019 20:00:51 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAACXBIWXMAAA7DAAAOwwHHb6hkAAAC 1UlEQVRYR8WWS2jUUBSGW4vjAxVEFHysqkhx0ZVIwZ3FpRuXbrW6Fd0IIoi4FO3ChWsXCrbVtlqf 1YqIigWfWBxhtIIFH5lkHplXJpnjf9K5nTE5SWYspAc+Jvlv7jnnvs6djo7hNC0pohgnohgnohgn ohgnohgnovi/DGkNpHYJUWSG6khtXhBw87hOR6fzdO5TgY5Mm7RxVG8kckOjNTf5u6Y+Cp9Qp+ee QXsfZxpOAlgGp4df5ylXrVGzaWXH1Q8+z9H172Xqf5qVffkEBk7PfCzQXNGh3Q/Dk9gPx6YnuLKq UyMLXEoWqfe+Qat5Frw+fAKDKbs6W3adGBWHBjCSBOveRPDdk1+W+12QFZBcKm/TibcmdbY+Axqd nynWXcyPZOxHhfomMRsIqhJZDnQkGGZlu0an3hewVAGzKIpgz6MM5T1TW8PrK61Kpz8UqH8qS7uw TwxLnn5lKdOm9bfkGC6iiGy77+h0FvvA4aiC2dCzCM6/YZbM2bRWWnuFKCKBK6kSfUP2JUzhYmzq t0VdwwHTz4giTgEfn6jRtWKDOAG+zduMKIIV4BrO72JtH/ZKaEETRQaduHoNfi5SOmKnB9lXLGEi LDgjinVWjqRpfK7iOmrXePmOoSSHjp4RRQXW7vgb060D7doLzaJ1YbtfIYpNdCGJAVwyswXbLaut 2B/cAz13jejRM6LoBUlsGdPp8pcSRaXApfvAs5zbR/TlxScg6wTWfhXgArJ9wqBDL3PulAYVJTZu 4qLThwracnDGJyCBTRjtxWSJZrK2ewLCArNxseLzvhX/CdoKzogi6MSl0/vAoAs4hlz/+WrOWI57 7/MFxCdj8qdFJ9+ZtO02AvMlJfiJRBQVvIkwIr6K+R/PDmysnbiAuid02jDKG3S+XezbKv8KIc7U jpYCqjb1HPiOvt72hYcoVCevg6B3pQW1q/eFh6VCFONEFONEFGMjTX8B57Ce1IdKF4gAAAAASUVO RK5CYII= --_006_956c4f3a40594c889fd9ac5197c57258darkmatterae_-- From nobody Mon Feb 25 13:37:35 2019 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 E1DB0131132 for ; Mon, 25 Feb 2019 13:37:28 -0800 (PST) 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 (1024-bit key) header.d=universityofcambridgecloud.onmicrosoft.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 mHDhlRDyQ_hY for ; Mon, 25 Feb 2019 13:37:26 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F661310E6 for ; Mon, 25 Feb 2019 13:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UniversityOfCambridgeCloud.onmicrosoft.com; s=selector1-cam-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=42r8v1n6i5QdqllszHwh/Sy32zESwOtf4Ao/MiPhjsA=; b=fKMMl8SjZOYUJXtxchPKZCyuffDt64dzmikZv7uPi67QPEwr76VggzgBNqiDcR1W1Y2KBmXmTuN5JjRuw7p4hIaDurnT5Io3B98JqzWYngTyXfoVQe/MIssqc6tSKO9aob+a15hKA2qurfanwBPlO4QEE5nCdGv69/iEHO9l4RE= Received: from VI1PR0801MB1296.eurprd08.prod.outlook.com (10.167.197.146) by VI1PR0801MB1375.eurprd08.prod.outlook.com (10.167.198.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 21:37:21 +0000 Received: from VI1PR0801MB1296.eurprd08.prod.outlook.com ([fe80::99a3:16d:d203:82ea]) by VI1PR0801MB1296.eurprd08.prod.outlook.com ([fe80::99a3:16d:d203:82ea%3]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 21:37:21 +0000 From: "M.A.L. Weidner" To: "mls@ietf.org" Thread-Topic: ART Ideas in TreeKEM Thread-Index: AQHUzVJJoSxk3lmKTky1XqgDJ73oyA== Date: Mon, 25 Feb 2019 21:37:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM5P189CA0033.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:15::46) To VI1PR0801MB1296.eurprd08.prod.outlook.com (2603:10a6:800:3a::18) authentication-results: spf=none (sender IP is ) smtp.mailfrom=malw2@cam.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-gm-message-state: AHQUAubUjof3Aw6q+a1NA16F7BW/NwfIAq4GcJpRBouV/0vz4G0mrvxi WByKHVqadiOY7sE5WybOIxiTiFDYHtIpd2fB4Ws= x-google-smtp-source: AHgI3Iaz7wCfRa1BExwByTh4/qQI2EJFvWVVpnTcsiXwbep3Wd2Hu9RHEwQxrt6QwiUF/coXchXyJyb8Ele/sNLaCJc= x-received: by 2002:adf:f7c9:: with SMTP id a9mr14839710wrq.39.1551130639477; Mon, 25 Feb 2019 13:37:19 -0800 (PST) x-gmail-original-message-id: x-originating-ip: [209.85.221.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08becc09-011a-4238-f584-08d69b696c13 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1375; x-ms-traffictypediagnostic: VI1PR0801MB1375: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA4MDFNQjEzNzU7MjM6TjBsaXRFVG4wZXFuZXhEQ0xjdXljRGxD?= =?utf-8?B?RENKamo3aTBGVU1rUDdMakpCK0NTcWdOTUoyS3NhT3BzUFI3TS9iUlB3aG5N?= =?utf-8?B?SWg1NERkQXQ1QTRad09OVDk3SEdmZ3Fhc3dXVnRud1lKbTlzY1Vick9mam9W?= =?utf-8?B?bXBaOSs0d2dkdEJFVGVNNzFEbW93RU5ycTBkTy9LMkRxRms5ZGt6bzZPWURY?= =?utf-8?B?RmZPV2NWNWpLOUtpZjF6T01VdlV0dkJXL1FvMThqODlFdmZEcmF1MjJGSmhV?= =?utf-8?B?bmJzY1BDV1BIcUVFWkpyaTFYdjU1KzVJVjRRZzM5K2JyU0pkVEp2RGJhaEhk?= =?utf-8?B?SDVVODZQakRKdjMyc0ZNZmJCUHhLckFmLzl1RU80SXNLUnFpdHpYOUNzYUJr?= =?utf-8?B?WUU3NEVPU3N3b3o3NmF2eUZUZnllbFhSeGk5VnVBUUtwZmM3NkxNeEZ4QVlu?= =?utf-8?B?bFdFQzI0clpiTGQ3cWI2cVd3Z3NGNlF3clBmZytyNzJ2ZGt6d1lMQ1V6dmZk?= =?utf-8?B?c0dvbzFDYWZKeFZacGVEVjd2eHZXYWU1RUhTOGpVWVl3OElMSUF5QVhQcWRq?= =?utf-8?B?M2RGWkgwV2FwUGZtaTZhdjBtK2dwODJYbHowSUlsU2EySlJyOHFhTkN4M25Y?= =?utf-8?B?eGdwOThseWovRWtWZnYvTTNCMkxtQlBlTEtHNkhtRUwrbzlnQ3NaVDJQckcw?= =?utf-8?B?WGRHNE10UDh4cDVKeVFpL3lkaENxQmRKQ1NaWFdWYW9vb3JOVDI0b0RBcEtn?= =?utf-8?B?Z21KWW9rd1dYYXQ0YkxDcTV4eFdVV2ovTUxhbFp5bHFQYXNCeElLS1o1aUM1?= =?utf-8?B?RjlOd3d4SzdBVEE2bWQyTXVNTmRtdzU1NGxhMGV3MTRydDhjNHpzOWp6eCt3?= =?utf-8?B?K2s3M2hIQlJuL092a0E3TjVzbmZmRUUyY2xJUzdhSlZOcTIzK1c3TDVsZnZU?= =?utf-8?B?a1RyMjRNQnNWV05HUDJiZVZCK3d1aGMzRFY1NU5FNERJdkd2NytFYTRaSW5P?= =?utf-8?B?dlVpWmloRzFlOElTN1cvTFlPUngyNjh0Q1k5cjZMUWdLQkVPZEtuUGJzSXJC?= =?utf-8?B?aUlYdlR0cnRoSVJkVExGTWFNdE5CNFFEcGhJU2Qva2JIcXpIWHh0eHIxUVdJ?= =?utf-8?B?UWN3OHlyY2FMVFlxSWRUNS9ZV3V4OXlIZjMya0xBUlM5bkFQbFJqTFllRHFP?= =?utf-8?B?T0o2MndqNW90TklyQ3VYbHN0YXR3S3dKcXVUVGlmUGZJMXZTbjR5Lzl6NUov?= =?utf-8?B?bHEraE1WTG1UUlE4ak1nOTIrSWVhbVpnajRoR3BncUg2NitvdzhvWTI2aGZN?= =?utf-8?B?ZndOa25yNi95ZXErM2lHT3dvY1Q0aElCT2dHU3kyVXVYNFRGUE1TVFpiVEhD?= =?utf-8?B?VDhEbWtCVC93blZMRG03cmVlNm5ab3Z5QlFHaW9KQVFSRUhabS9RU05xV011?= =?utf-8?B?d1JqLzlwZkdVaVRCb0FwTm8wOGt4Tm0xMGFWOHVObS9sRktSMXA1RTIxVjVN?= =?utf-8?B?OThqWE13RUdaeFRQRC8wSmRZbm9iUitBNEpSM2s2YXZDcTBRWlNUWUREdU1t?= =?utf-8?B?RmcwUWtFMXdlWGpHZngwSGFVSDllbyt2bkZ2M2ZrMzIrMDlNZHFJUTBxcURW?= =?utf-8?B?dTZhbHU0aUpvdC9JOVV6RXZlcHNZNTZNUXJjNE5MM0FaRDBZajVwYlJsTE1p?= =?utf-8?B?ZjNVcEZVTlNTWldWMktRaHRlc0dxK2p4U1RSZ1BSajIzcXBNbGViOWYrRE9D?= =?utf-8?B?MzBYZXBnMDEwWThyVHVJVE95cmY4eUZ6ekRPRFVjMlk5UnA3eVJiR3JTSG1k?= =?utf-8?B?b0xaZjIrUXh2cjc4Nll6TXNjRDgwQlFvTTY2SjhrbnJ4cUR4V2k4ZXp5c01B?= =?utf-8?Q?h9ihIjDaYuGX8=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(136003)(396003)(346002)(52314003)(189003)(199004)(71190400001)(25786009)(8676002)(71200400001)(86362001)(66066001)(106356001)(486006)(105586002)(2351001)(97736004)(476003)(61266001)(1730700003)(61726006)(81156014)(81166006)(305945005)(7736002)(256004)(14444005)(2906002)(74482002)(2501003)(53936002)(186003)(8936002)(26005)(95326003)(478600001)(102836004)(14454004)(498394004)(316002)(786003)(6506007)(52116002)(9686003)(6512007)(68736007)(5660300002)(3846002)(6116002)(6436002)(99286004)(5640700003)(54896002)(6486002)(386003)(6916009)(3480700005)(55446002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0801MB1375; H:VI1PR0801MB1296.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cam.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ojv+ir1SlwjVzcXPGcJ02XIpCex8cZmezMetvZOUpS4s5eoNKI2pV+4emlcqUSoCsG9sLwJe9PG0H793UKq4tLJIIqDigEkGYbLZl0nVTqh5PNR2OHXMp0aYxI8vLBCo8MhIaJXLrgkprVuY/JWlnsws/wg/xEs5GfGIzrUm3H2Am6fq0POcLlKSrDZpDdOhsTI43sT65quA6gg4duy1JKXid0FYsXDN9Ev1TPPEPlRJ/DjlFU4vFIVQL+synbOiT0K5qJNz/4clOc3dZ3xkhJdue4a62GS68SnkjKYEQzN5lw2m9n/c3JD/hYAmZTLPEnWkcQqB/rCLMRWw0pufSRaA4zUm+lPq5cTPQCovcOqYnG/PdtsLxDHbcZ9yCOpaCRanx3zTjZR0BNYZOp1wagqmnbtyQMXwZ+G8sqNlIUg= Content-Type: multipart/alternative; boundary="_000_CADSARUs6Qt5srOTYGe6otaVfUZQK56HZgVJpzhssh8ad1Uxwmailgm_" MIME-Version: 1.0 X-OriginatorOrg: cam.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 08becc09-011a-4238-f584-08d69b696c13 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 21:37:20.6612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 49a50445-bdfa-4b79-ade3-547b4f3986e9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1375 Archived-At: Subject: [MLS] ART Ideas in TreeKEM 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, 25 Feb 2019 21:37:34 -0000 --_000_CADSARUs6Qt5srOTYGe6otaVfUZQK56HZgVJpzhssh8ad1Uxwmailgm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlYXRpbmdzIE1MUyBXb3JraW5nIEdyb3VwIQ0KDQpJIGhhdmUgYmVlbiBzdHVkeWluZyB0aGUg cHJvcG9zYWxzIGZvciBUcmVlS0VNLCBhbmQgZWFybGllciwgQVJULCBhbmQgbm90aWNlZCBhIHdh eSB0byB1c2UgQVJUJ3MgREggdHJlZSBpZGVhcyBpbiBUcmVlS0VNLCB3aXRob3V0IHNhY3JpZmlj aW5nIHRoZSBhYmlsaXR5IHRvIG1lcmdlIHVwZGF0ZXMgb3IgdXNlIGJsYW5rIG5vZGVzLiAgTXkg YXBvbG9naWVzIGlmIHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSBvciBpZiB0aGVyZSBh cmUgYW55IG1pc3Rha2VzLg0KDQpNeSBtYWluIG1vdGl2YXRpb24gaGVyZSBpcyB0byByZWR1Y2Ug dGhlIHNpemUgb2YgdXBkYXRlIG1lc3NhZ2VzLCBzaW5jZSB0aGUga2V5IGVuY3J5cHRlZCBrZXlz IGluIGFkZGl0aW9uIHRvIG5ldyBwdWJsaWMga2V5cyBtZWFucyB0aGF0IHRoZXkgYXJlIH4yeCBh cyBsYXJnZSBpbiBUcmVlS0VNIGFzIGluIEFSVC4NCg0KQmFzaWNhbGx5LCB3ZSB1c2UgVHJlZUtF TSwgYnV0IHdpdGggQVJUJ3Mga2V5IGRlcml2YXRpb24gImFzIiBIKFgpLiAgVGhhdCBpcywgd2hl biBhIG5vZGUgQzEgZ2V0cyB0aGUgbmV3IHNlY3JldCBYLCBpbnN0ZWFkIG9mIEgoWCksIGl0cyBw YXJlbnQgZ2V0cyB0aGUgbmV3IHNlY3JldA0KDQpIMihESChYLCBwcml2KEMyKSkpID0gSDIocHVi KEMyKSBeIFgpID0gSDIocHViKFgpIF4gcHJpdihDMikpDQoNCndoZXJlIEMyIGlzIHRoZSBuZWln aGJvciBvZiBDMSwgZm9yIHNvbWUgaGFzaCBmdW5jdGlvbiBIMi4gIFNpbmNlIFRyZWVLRU0gaXMg YWdub3N0aWMgYWJvdXQgSCwgd2UgY2FuICJkZWZpbmUiDQoNCkgoWCkgOj0gSDIoREgoWCwgcHJp dihDMikpKQ0KDQppbiB0aGlzIHdheSB3aXRob3V0IGlzc3VlLCBub3RpbmcgdGhhdCB0aGUgb25s eSB1c2VycyB3aG8gd2lsbCBoYXZlIHRvIGNvbXB1dGUgSDIoREgoWCwgcHJpdihDMikpKSBhcmUg ZGVzY2VuZGFudHMgb2YgQzEgKHdobyBrbm93IFgpIG9yIEMyICh3aG8ga25vdyBwcml2KEMyKSku DQoNCldlIGNhbiBtZXJnZSB1cGRhdGVzIGFzIHdpdGggInB1cmUiIFRyZWVLRU0sIGNob29zaW5n IG9uZSB1cGRhdGUgdG8gZG9taW5hdGUgYXQgbm9kZXMgd2hlcmUgdGhleSBjb25mbGljdC4gIFRo aXMgd2lsbCBjYXVzZSB0aGUgdHJlZSB0byBjZWFzZSBiZWluZyBhIERIIHRyZWUsIHdoaWNoIGlz IGZpbmUuICBOb3RlIHRoYXQgZGVzY2VuZGFudHMgb2YgQzIgd2lsbCBoYXZlIHRvIGtlZXAgYXJv dW5kIHByaXYoQzIpIGZvciBhIHNob3J0IHRpbWUgYWZ0ZXIgaXQgaXMgb3ZlcndyaXR0ZW4gaW4g Y2FzZSBvZiBzaW11bHRhbmVvdXMgdXBkYXRlcyAoc28gdGhhdCB0aGV5IGNhbiBjb21wdXRlIHRo ZSBwYXJlbnQgc2VjcmV0KSwgYnV0IHRoYXQgaXMgdHJ1ZSBmb3IgVHJlZUtFTSBhbnl3YXksIHNp bmNlIGFueSBzaW11bHRhbmVvdXMgdXBkYXRlIHdpbGwgc2VuZCBkYXRhIGVuY3J5cHRlZCB1bmRl ciBwdWIoQzIpLg0KDQpCbGFuayBub2RlcyBjYW4gYmUgaGFuZGxlZCBieSByZXZlcnRpbmcgdG8g cHVyZSBUcmVlS0VNOiBpZiBhIG5vZGUgd2l0aCBuZXcgc2VjcmV0IFggaGFzIGEgYmxhbmsgbmVp Z2hib3IsIHNldCB0aGUgcGFyZW50J3Mgc2VjcmV0IHRvIEgoWCkgYW5kIHNlbmQgdGhhdCBzZXBh cmF0ZWx5IHRvIGV2ZXJ5IHB1YmxpYyBrZXkgaW4gdGhlIHJlc29sdXRpb24uDQoNCk5vdyBpbnN0 ZWFkIG9mIGluY2x1ZGluZw0KDQpwdWIoWCksIEVuYyhwdWIoQzIpLCBIKFgpKQ0KDQppbiB0aGUg UmF0Y2hldE5vZGUgc3RydWN0IGZvciBub2RlIEMyLCB3ZSBuZWVkIG1lcmVseSBpbmNsdWRlIHB1 YihYKSwgc2F2aW5nIGJhbmR3aWR0aC4NCg0KUHJvczoNCiAgLSByZWR1Y2VzIHRoZSB1cGRhdGUg bWVzc2FnZSBzaXplIGJ5IGFib3V0IDUwJSBpbiB0aGUgdHlwaWNhbCBjYXNlIChJIHRoaW5rKS4N CiAgLSB3ZSBjYW4gYnVpbGQgYSB0ZXJuYXJ5IHRyZWUgdXNpbmcgMy1wYXJ0eSBKb3V4IERIIChh cyB3aXRoIEFSVCksIGdpdmluZyBhIGZ1cnRoZXIgbG9nXzMoMikgfiAwLjYzIHNjYWxpbmcgb24g dXBkYXRlIG1lc3NhZ2Ugc2l6ZS4gIChJIHRoaW5rIGl0J3MgcG9zc2libGUgdG8gZG8gdGhpcyB3 aXRoIHB1cmUgVHJlZUtFTSBhcyB3ZWxsLCBieSByZXBsYWNpbmcgdGhlIGVwaGVtZXJhbCBESCBl eGNoYW5nZSB3aXRoIGEgSm91eCBESCB3aGVuIGRvaW5nIGFzeW1tZXRyaWMgZW5jcnlwdGlvbi4p DQoNCkNvbnM6DQogIC0gZm9yY2VkIHRvIHVzZSBhIERIIHN0eWxlIGNyeXB0b3N5c3RlbSAoYmFk IGZvciBwb3N0LXF1YW50dW0/KSAoYXMgd2l0aCBBUlQpLg0KICAtIG5lZWQgbG9nKE4pIERIIG9w ZXJhdGlvbnMgdG8gY29tcHV0ZSB0aGUgbmV3IGtleSwgaW5zdGVhZCBvZiBsb2coTikgaGFzaGVz IChhcyB3aXRoIEFSVCkuICBTbyB0aGlzIGlzIGEgYmFkIGRlYWwgaWYgQ1BVIGN5Y2xlcyBhcmUg bW9yZSBleHBlbnNpdmUgdGhhbiBiYW5kd2lkdGguDQogIC0gY2FuIGFsc28gcmVkdWNlIGJhbmR3 aWR0aCBieSAyIGp1c3QgYnkgcmF0Y2hldGluZyBoYWxmIGFzIG9mdGVuLg0KDQpJIGhvcGUgeW91 IG1heSBmaW5kIHRoaXMgaW50ZXJlc3RpbmcuDQoNCkJlc3QsDQpNYXR0aGV3IFdlaWRuZXINCk1Q aGlsIHN0dWRlbnQsIFVuaXZlcnNpdHkgb2YgQ2FtYnJpZGdlDQo= --_000_CADSARUs6Qt5srOTYGe6otaVfUZQK56HZgVJpzhssh8ad1Uxwmailgm_ Content-Type: text/html; charset="utf-8" Content-ID: <8F61AC045329184B8BBBAF82D9C3E0AB@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2PkdyZWF0aW5ncyBNTFMgV29ya2luZyBHcm91cCE8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkkgaGF2ZSBiZWVuIHN0dWR5aW5nIHRoZSBwcm9wb3NhbHMgZm9yIFRyZWVL RU0sIGFuZCBlYXJsaWVyLCBBUlQsIGFuZCBub3RpY2VkIGEgd2F5IHRvIHVzZSBBUlQncyBESCB0 cmVlIGlkZWFzIGluIFRyZWVLRU0sIHdpdGhvdXQgc2FjcmlmaWNpbmcgdGhlIGFiaWxpdHkgdG8g bWVyZ2UgdXBkYXRlcyBvciB1c2UgYmxhbmsgbm9kZXMuJm5ic3A7IE15IGFwb2xvZ2llcyBpZiB0 aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUgb3IgaWYgdGhlcmUNCiBhcmUgYW55IG1pc3Rh a2VzLjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TXkgbWFpbiBtb3RpdmF0 aW9uIGhlcmUgaXMgdG8gcmVkdWNlIHRoZSBzaXplIG9mIHVwZGF0ZSBtZXNzYWdlcywgc2luY2Ug dGhlIGtleSBlbmNyeXB0ZWQga2V5cyBpbiBhZGRpdGlvbiB0byBuZXcgcHVibGljIGtleXMgbWVh bnMgdGhhdCB0aGV5IGFyZSB+MnggYXMgbGFyZ2UgaW4gVHJlZUtFTSBhcyBpbiBBUlQuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CYXNpY2FsbHksIHdlIHVzZSBUcmVlS0VNLCBidXQg d2l0aCBBUlQncyBrZXkgZGVyaXZhdGlvbiAmcXVvdDthcyZxdW90OyBIKFgpLiZuYnNwOyBUaGF0 IGlzLCB3aGVuIGEgbm9kZSBDMSBnZXRzIHRoZSBuZXcgc2VjcmV0IFgsIGluc3RlYWQgb2YgSChY KSwgaXRzIHBhcmVudCBnZXRzIHRoZSBuZXcgc2VjcmV0PGJyPg0KPGJyPg0KSDIoREgoWCwgcHJp dihDMikpKSA9IEgyKHB1YihDMikgXiBYKSA9IEgyKHB1YihYKSBeIHByaXYoQzIpKTxicj4NCjxi cj4NCndoZXJlIEMyIGlzIHRoZSBuZWlnaGJvciBvZiBDMSwgZm9yIHNvbWUgaGFzaCBmdW5jdGlv biBIMi4mbmJzcDsgU2luY2UgVHJlZUtFTSBpcyBhZ25vc3RpYyBhYm91dCBILCB3ZSBjYW4gJnF1 b3Q7ZGVmaW5lJnF1b3Q7PGJyPg0KPGJyPg0KSChYKSA6PSBIMihESChYLCBwcml2KEMyKSkpPGJy Pg0KPGJyPg0KaW4gdGhpcyB3YXkgd2l0aG91dCBpc3N1ZSwgbm90aW5nIHRoYXQgdGhlIG9ubHkg dXNlcnMgd2hvIHdpbGwgaGF2ZSB0byBjb21wdXRlIEgyKERIKFgsIHByaXYoQzIpKSkgYXJlIGRl c2NlbmRhbnRzIG9mIEMxICh3aG8ga25vdyBYKSBvciBDMiAod2hvIGtub3cgcHJpdihDMikpLjxi cj4NCjxicj4NCldlIGNhbiBtZXJnZSB1cGRhdGVzIGFzIHdpdGggJnF1b3Q7cHVyZSZxdW90OyBU cmVlS0VNLCBjaG9vc2luZyBvbmUgdXBkYXRlIHRvIGRvbWluYXRlIGF0IG5vZGVzIHdoZXJlIHRo ZXkgY29uZmxpY3QuJm5ic3A7IFRoaXMgd2lsbCBjYXVzZSB0aGUgdHJlZSB0byBjZWFzZSBiZWlu ZyBhIERIIHRyZWUsIHdoaWNoIGlzIGZpbmUuJm5ic3A7IE5vdGUgdGhhdCBkZXNjZW5kYW50cyBv ZiBDMiB3aWxsIGhhdmUgdG8ga2VlcCBhcm91bmQgcHJpdihDMikgZm9yIGEgc2hvcnQgdGltZSBh ZnRlcg0KIGl0IGlzIG92ZXJ3cml0dGVuIGluIGNhc2Ugb2Ygc2ltdWx0YW5lb3VzIHVwZGF0ZXMg KHNvIHRoYXQgdGhleSBjYW4gY29tcHV0ZSB0aGUgcGFyZW50IHNlY3JldCksIGJ1dCB0aGF0IGlz IHRydWUgZm9yIFRyZWVLRU0gYW55d2F5LCBzaW5jZSBhbnkgc2ltdWx0YW5lb3VzIHVwZGF0ZSB3 aWxsIHNlbmQgZGF0YSBlbmNyeXB0ZWQgdW5kZXIgcHViKEMyKS48YnI+DQo8YnI+DQpCbGFuayBu b2RlcyBjYW4gYmUgaGFuZGxlZCBieSByZXZlcnRpbmcgdG8gcHVyZSBUcmVlS0VNOiBpZiBhIG5v ZGUgd2l0aCBuZXcgc2VjcmV0IFggaGFzIGEgYmxhbmsgbmVpZ2hib3IsIHNldCB0aGUgcGFyZW50 J3Mgc2VjcmV0IHRvIEgoWCkgYW5kIHNlbmQgdGhhdCBzZXBhcmF0ZWx5IHRvIGV2ZXJ5IHB1Ymxp YyBrZXkgaW4gdGhlIHJlc29sdXRpb24uPGJyPg0KPGJyPg0KTm93IGluc3RlYWQgb2YgaW5jbHVk aW5nPGJyPg0KPGJyPg0KcHViKFgpLCBFbmMocHViKEMyKSwgSChYKSk8YnI+DQo8YnI+DQppbiB0 aGUgUmF0Y2hldE5vZGUgc3RydWN0IGZvciBub2RlIEMyLCB3ZSBuZWVkIG1lcmVseSBpbmNsdWRl IHB1YihYKSwgc2F2aW5nIGJhbmR3aWR0aC48YnI+DQo8YnI+DQpQcm9zOjxicj4NCiZuYnNwOyAt IHJlZHVjZXMgdGhlIHVwZGF0ZSBtZXNzYWdlIHNpemUgYnkgYWJvdXQgNTAlIGluIHRoZSB0eXBp Y2FsIGNhc2UgKEkgdGhpbmspLjxicj4NCiZuYnNwOyAtIHdlIGNhbiBidWlsZCBhIHRlcm5hcnkg dHJlZSB1c2luZyAzLXBhcnR5IEpvdXggREggKGFzIHdpdGggQVJUKSwgZ2l2aW5nIGEgZnVydGhl ciBsb2dfMygyKSB+IDAuNjMgc2NhbGluZyBvbiB1cGRhdGUgbWVzc2FnZSBzaXplLiZuYnNwOyAo SSB0aGluayBpdCdzIHBvc3NpYmxlIHRvIGRvIHRoaXMgd2l0aCBwdXJlIFRyZWVLRU0gYXMgd2Vs bCwgYnkgcmVwbGFjaW5nIHRoZSBlcGhlbWVyYWwgREggZXhjaGFuZ2Ugd2l0aCBhIEpvdXggREgg d2hlbiBkb2luZw0KIGFzeW1tZXRyaWMgZW5jcnlwdGlvbi4pPGJyPg0KPGJyPg0KQ29uczo8YnI+ DQombmJzcDsgLSBmb3JjZWQgdG8gdXNlIGEgREggc3R5bGUgY3J5cHRvc3lzdGVtIChiYWQgZm9y IHBvc3QtcXVhbnR1bT8pIChhcyB3aXRoIEFSVCkuPGJyPg0KJm5ic3A7IC0gbmVlZCBsb2coTikg REggb3BlcmF0aW9ucyB0byBjb21wdXRlIHRoZSBuZXcga2V5LCBpbnN0ZWFkIG9mIGxvZyhOKSBo YXNoZXMgKGFzIHdpdGggQVJUKS4mbmJzcDsgU28gdGhpcyBpcyBhIGJhZCBkZWFsIGlmIENQVSBj eWNsZXMgYXJlIG1vcmUgZXhwZW5zaXZlIHRoYW4gYmFuZHdpZHRoLjxicj4NCiZuYnNwOyAtIGNh biBhbHNvIHJlZHVjZSBiYW5kd2lkdGggYnkgMiBqdXN0IGJ5IHJhdGNoZXRpbmcgaGFsZiBhcyBv ZnRlbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgaG9wZSB5b3UgbWF5IGZpbmQg dGhpcyBpbnRlcmVzdGluZy48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJl c3QsPC9kaXY+DQo8ZGl2Pk1hdHRoZXcgV2VpZG5lcjwvZGl2Pg0KPGRpdj5NUGhpbCBzdHVkZW50 LCBVbml2ZXJzaXR5IG9mIENhbWJyaWRnZTwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_CADSARUs6Qt5srOTYGe6otaVfUZQK56HZgVJpzhssh8ad1Uxwmailgm_-- From nobody Mon Feb 25 14:07:58 2019 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 6979A1310DA for ; Mon, 25 Feb 2019 14:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8KIaNbMQEwO8 for ; Mon, 25 Feb 2019 14:07:54 -0800 (PST) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 D178F12D827 for ; Mon, 25 Feb 2019 14:07:53 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id g16so8676166oib.1 for ; Mon, 25 Feb 2019 14:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E7f3g113XJVaxRGPJ/hU62d8E26kFEOXLt8yASR08lg=; b=miLC4TBNMp6wp+RPt5msfQgVpUpvkZjPKw6MpSbFlG/Q5YmaU69odjN2StaQ4Q9RPg YuvH3Ok6mEE3WP06L9kciKr4S0XVA+1qI/SM4Yypa2YE7WvgySyAakJopRj+zM8uMTNC W+Rkn/+jZulQE4hFZMQqUdUZDfggJjVIeBOc6GIK/5+pjPOn7uCgvCiuz62rcjsu56n+ GRq6/sDOG0P2eCi6jfOfT62TLI1z4JG56xAey+LSYNkwVXX5TKEHS47vkJ02KxhmeS1b pzxuc5LQBOru8kb3Vui+wpsnOmBoN2aTyTWH3REnyg0pp0I2xqf6IOSPvrZQIn93wizo fCmg== 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=E7f3g113XJVaxRGPJ/hU62d8E26kFEOXLt8yASR08lg=; b=WSmZSvNO4Hzruq9OhhZmBYHs8aAWoaYUS6/Me6jlhkT0VOqJBiSqUJ8jscCafL8qFa 4USiLNDyrySfC7qDMu2kS2y7jSImzNQrC4LhfZ8PGtI8+SJnrzvM1uZfxk8x4wbff5MH 6IBKaD/rSYDapcY+Aap6OMdnKXdOuDZsWYpkxWlOnGSODaaryszwpqHTH8dqyilC8x+W 8k3AJNf8jGh0PjcZdjwdzyb0/b8BvOXzaCQUuY6shnkO5oWw6B0mwRb315NZzCbvDir9 xS3OhfNvcWJkhBAdwyMZ/0nCv1NkMJk6ugqiBL2FXxu0MnXnuboKdIbHYMTIFBA+4R/0 4k7g== X-Gm-Message-State: AHQUAubNlA1YhA8NqbstSWRVY5Gu7EDGymdQkEoIeHpFIByHZl1MSjLO Dsi4bK1z+BrUBQPcsxX5idobHm6/+gYhxCNt/KStXg== X-Google-Smtp-Source: AHgI3IaFif+ZV3utn8kqnbSDKF1PnBiGt0sMghPBbvuEAN0TjQnw4TFLpO9w5ZumIehd3Cs9Dd3wlF9/F09S6/HY8lg= X-Received: by 2002:aca:52cc:: with SMTP id g195mr346315oib.99.1551132472840; Mon, 25 Feb 2019 14:07:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 25 Feb 2019 17:07:35 -0500 Message-ID: To: "M.A.L. Weidner" Cc: "mls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000b27220582bf2cc0" Archived-At: Subject: Re: [MLS] ART Ideas in TreeKEM 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, 25 Feb 2019 22:07:57 -0000 --0000000000000b27220582bf2cc0 Content-Type: text/plain; charset="UTF-8" Hi Matthew, Thanks for the thoughts. Would it be accurate to summarize your proposal as a "hybrid mode", where when you update: - If both of a node's children are populated, then you do an "ART step", generating the parent from the children - Otherwise, you do a "TreeKEM step", encrypting the next secret to the resolution of the other child (Remove is probably similar; for Add there's no change needed.) Assuming that's right, this honestly doesn't sound like a tremendously compelling proposition to me. Your evaluation on the overhead seems mostly correct, but there have already been some complaints on the list about hashing overhead, so I'm not sure trading DH+smaller_messages for hashing is going to suit. I'm also worried that this hybridization will introduce a bunch of new complexity into the protocol and make it harder to implement and analyze. Open to arguments if other folks are enthusiastic, though. --Richard On Mon, Feb 25, 2019 at 4:37 PM M.A.L. Weidner wrote: > Greatings MLS Working Group! > > I have been studying the proposals for TreeKEM, and earlier, ART, and > noticed a way to use ART's DH tree ideas in TreeKEM, without sacrificing > the ability to merge updates or use blank nodes. My apologies if this has > been discussed before or if there are any mistakes. > > My main motivation here is to reduce the size of update messages, since > the key encrypted keys in addition to new public keys means that they are > ~2x as large in TreeKEM as in ART. > > Basically, we use TreeKEM, but with ART's key derivation "as" H(X). That > is, when a node C1 gets the new secret X, instead of H(X), its parent gets > the new secret > > H2(DH(X, priv(C2))) = H2(pub(C2) ^ X) = H2(pub(X) ^ priv(C2)) > > where C2 is the neighbor of C1, for some hash function H2. Since TreeKEM > is agnostic about H, we can "define" > > H(X) := H2(DH(X, priv(C2))) > > in this way without issue, noting that the only users who will have to > compute H2(DH(X, priv(C2))) are descendants of C1 (who know X) or C2 (who > know priv(C2)). > > We can merge updates as with "pure" TreeKEM, choosing one update to > dominate at nodes where they conflict. This will cause the tree to cease > being a DH tree, which is fine. Note that descendants of C2 will have to > keep around priv(C2) for a short time after it is overwritten in case of > simultaneous updates (so that they can compute the parent secret), but that > is true for TreeKEM anyway, since any simultaneous update will send data > encrypted under pub(C2). > > Blank nodes can be handled by reverting to pure TreeKEM: if a node with > new secret X has a blank neighbor, set the parent's secret to H(X) and send > that separately to every public key in the resolution. > > Now instead of including > > pub(X), Enc(pub(C2), H(X)) > > in the RatchetNode struct for node C2, we need merely include pub(X), > saving bandwidth. > > Pros: > - reduces the update message size by about 50% in the typical case (I > think). > - we can build a ternary tree using 3-party Joux DH (as with ART), > giving a further log_3(2) ~ 0.63 scaling on update message size. (I think > it's possible to do this with pure TreeKEM as well, by replacing the > ephemeral DH exchange with a Joux DH when doing asymmetric encryption.) > > Cons: > - forced to use a DH style cryptosystem (bad for post-quantum?) (as with > ART). > - need log(N) DH operations to compute the new key, instead of log(N) > hashes (as with ART). So this is a bad deal if CPU cycles are more > expensive than bandwidth. > - can also reduce bandwidth by 2 just by ratcheting half as often. > > I hope you may find this interesting. > > Best, > Matthew Weidner > MPhil student, University of Cambridge > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000000b27220582bf2cc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matthew,

Thanks for the t= houghts.=C2=A0 Would it be accurate to summarize your proposal as a "h= ybrid mode", where when you update:

- If both= of a node's children are populated, then you do an "ART step"= ;, generating the parent from the children
- Otherwise, you do a = "TreeKEM step", encrypting the next secret to the resolution of t= he other child

(Remove is probably similar; for Ad= d there's no change needed.)

Assuming that'= ;s right, this honestly doesn't sound like a tremendously compelling pr= oposition to me.=C2=A0 Your evaluation on the overhead seems mostly correct= , but there have already been some complaints on the list about hashing ove= rhead, so I'm not sure trading DH+smaller_messages for hashing is going= to suit.=C2=A0 I'm also worried that this hybridization will introduce= a bunch of new complexity into the protocol and make it harder to implemen= t and analyze.=C2=A0 Open to arguments if other folks are enthusiastic, tho= ugh.

--Richard





<= br>
On Mon,= Feb 25, 2019 at 4:37 PM M.A.L. Weidner <malw2@cam.ac.uk> wrote:
Greatings MLS Working Group!

I have been studying the proposals for TreeKEM, and earlier, ART, and = noticed a way to use ART's DH tree ideas in TreeKEM, without sacrificin= g the ability to merge updates or use blank nodes.=C2=A0 My apologies if th= is has been discussed before or if there are any mistakes.

My main motivation here is to reduce the size of update messages, sinc= e the key encrypted keys in addition to new public keys means that they are= ~2x as large in TreeKEM as in ART.

Basically, we use TreeKEM, but with ART's key derivation "as&= quot; H(X).=C2=A0 That is, when a node C1 gets the new secret X, instead of= H(X), its parent gets the new secret

H2(DH(X, priv(C2))) =3D H2(pub(C2) ^ X) =3D H2(pub(X) ^ priv(C2))

where C2 is the neighbor of C1, for some hash function H2.=C2=A0 Since Tree= KEM is agnostic about H, we can "define"

H(X) :=3D H2(DH(X, priv(C2)))

in this way without issue, noting that the only users who will have to comp= ute H2(DH(X, priv(C2))) are descendants of C1 (who know X) or C2 (who know = priv(C2)).

We can merge updates as with "pure" TreeKEM, choosing one update = to dominate at nodes where they conflict.=C2=A0 This will cause the tree to= cease being a DH tree, which is fine.=C2=A0 Note that descendants of C2 wi= ll have to keep around priv(C2) for a short time after it is overwritten in case of simultaneous updates (so that they can comput= e the parent secret), but that is true for TreeKEM anyway, since any simult= aneous update will send data encrypted under pub(C2).

Blank nodes can be handled by reverting to pure TreeKEM: if a node with new= secret X has a blank neighbor, set the parent's secret to H(X) and sen= d that separately to every public key in the resolution.

Now instead of including

pub(X), Enc(pub(C2), H(X))

in the RatchetNode struct for node C2, we need merely include pub(X), savin= g bandwidth.

Pros:
=C2=A0 - reduces the update message size by about 50% in the typical case (= I think).
=C2=A0 - we can build a ternary tree using 3-party Joux DH (as with ART), g= iving a further log_3(2) ~ 0.63 scaling on update message size.=C2=A0 (I th= ink it's possible to do this with pure TreeKEM as well, by replacing th= e ephemeral DH exchange with a Joux DH when doing asymmetric encryption.)

Cons:
=C2=A0 - forced to use a DH style cryptosystem (bad for post-quantum?) (as = with ART).
=C2=A0 - need log(N) DH operations to compute the new key, instead of log(N= ) hashes (as with ART).=C2=A0 So this is a bad deal if CPU cycles are more = expensive than bandwidth.
=C2=A0 - can also reduce bandwidth by 2 just by ratcheting half as often.

I hope you may find this interesting.

Best,
Matthew Weidner
MPhil student, University of Cambridge
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000000b27220582bf2cc0-- From nobody Tue Feb 26 01:02:09 2019 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 AC677130E9F for ; Tue, 26 Feb 2019 01:02:07 -0800 (PST) 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 i-z378gt0g71 for ; Tue, 26 Feb 2019 01:02:00 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450: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 ECDBD130E9E for ; Tue, 26 Feb 2019 01:01:59 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id g20so744937wmh.5 for ; Tue, 26 Feb 2019 01:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=et0FGulQz0MD/wckMsqj2M41ZI2ZxbXxs4ThreieLUI=; b=b62JHJtxN+8lkYmNrl1ziO8cKZUqPRCo44cu9Yv1rIjVGzGt1ZbZbIGoKqDPveIxFv YmAEPaQcAv3t7tt1VpN9aHhyy2gp8usU0jCK4iDpGrk7OCBgCvfS+h1Y7vWsjrYDQEaF 0zH9if8h8Je8QDzLAdpb7kpA6WzA+nJ+gSryOG7Nl2yL2wJtBErrNBYYUH3q7grOJN6T rZGnLYB3mVTHXsVSV/4X94NJUQKcWBJCuCgzSIY/e57+VkeT6flw2nJyC/IWbIPZQ884 Jy6Zn+gbfxqHLhomTDCHsYlxYmlmUwNQQftn/h5XIL0f2AMiU5pSIZ+84LQOlcwN7DGA k5ZQ== 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=et0FGulQz0MD/wckMsqj2M41ZI2ZxbXxs4ThreieLUI=; b=SzQ2Y4THSW2DlrAVy1JonppL0sfZPzJ8q3yVZPYtviMbpRHI0tdzKWIMp9Sm0q9aSg TJ5xBp9UJct/C2cPNtu+VkiBS4IxR3qGr/j88jvH14sxbP2WXzBQBzm8F6Njt7ZHlKYH O+urJX4S0tp3YaNx9CNGFLFfFeZ6iQ5PNT7UxZUL2vTbMkR9gT3/tX26GcFwC46B+xGV KOPXB3VcEa57fA+F5L5XdrQ+59OsKhcgL/1MPCVgJKTAI0IiN5UmibE+voutvWxPUc1D YeY+zkdHtIBm+ZypvcEm/grOtHOQe4a/FLQV/nN7vphNyU31RV/oY7ZBoTHih1NX/1/K PHjg== X-Gm-Message-State: AHQUAuaOv7Mbz8Ap86v7Mv/JwXF6JRQ9chdeLyT/B1w8jNeaNO9HCtaj DQuN72z6QcNibkf+USSw6ZNT/eLNQWs= X-Google-Smtp-Source: AHgI3IahCjQoo8WWJCcR70WpL7qtW5vGO2DBmAvBFicI5DEWgDI6vRyF7YSX0CnlTKtS4lLS1nJ8Rw== X-Received: by 2002:a1c:23c4:: with SMTP id j187mr1792027wmj.13.1551171717747; Tue, 26 Feb 2019 01:01:57 -0800 (PST) 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 p6sm37576807wre.63.2019.02.26.01.01.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 01:01:56 -0800 (PST) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DBF8A3D7-C74E-4E4A-AD94-A23E4E2DAE4C" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 26 Feb 2019 10:01:55 +0100 In-Reply-To: Cc: "M.A.L. Weidner" , Richard Barnes To: "mls@ietf.org" References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] ART Ideas in TreeKEM 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, 26 Feb 2019 09:02:08 -0000 --Apple-Mail=_DBF8A3D7-C74E-4E4A-AD94-A23E4E2DAE4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Matthew, One of the convincing reasons we saw when looking into ART vs. TreeKEM = was that the recipient of handshake messages can process them with O(1) = DH operations with TreeKEM as opposed to O(log n) with ART. This sounds = like a small difference at first, but we believe that it makes a big = difference in real life scenarios. Clients will mostly process handshake = messages (particularly in large dynamic groups), but only rarely send = them. The hunch is that TreeKEM is roughly an order of magnitude faster = for average operations in MLS. If we go back to O(log n) DH operations to derive the root secret we = would lose the speed advantage. Raphael > On 25 Feb 2019, at 23:07, Richard Barnes wrote: >=20 > Hi Matthew, >=20 > Thanks for the thoughts. Would it be accurate to summarize your = proposal as a "hybrid mode", where when you update: >=20 > - If both of a node's children are populated, then you do an "ART = step", generating the parent from the children > - Otherwise, you do a "TreeKEM step", encrypting the next secret to = the resolution of the other child >=20 > (Remove is probably similar; for Add there's no change needed.) >=20 > Assuming that's right, this honestly doesn't sound like a tremendously = compelling proposition to me. Your evaluation on the overhead seems = mostly correct, but there have already been some complaints on the list = about hashing overhead, so I'm not sure trading DH+smaller_messages for = hashing is going to suit. I'm also worried that this hybridization will = introduce a bunch of new complexity into the protocol and make it harder = to implement and analyze. Open to arguments if other folks are = enthusiastic, though. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Feb 25, 2019 at 4:37 PM M.A.L. Weidner > wrote: > Greatings MLS Working Group! >=20 > I have been studying the proposals for TreeKEM, and earlier, ART, and = noticed a way to use ART's DH tree ideas in TreeKEM, without sacrificing = the ability to merge updates or use blank nodes. My apologies if this = has been discussed before or if there are any mistakes. >=20 > My main motivation here is to reduce the size of update messages, = since the key encrypted keys in addition to new public keys means that = they are ~2x as large in TreeKEM as in ART. >=20 > Basically, we use TreeKEM, but with ART's key derivation "as" H(X). = That is, when a node C1 gets the new secret X, instead of H(X), its = parent gets the new secret >=20 > H2(DH(X, priv(C2))) =3D H2(pub(C2) ^ X) =3D H2(pub(X) ^ priv(C2)) >=20 > where C2 is the neighbor of C1, for some hash function H2. Since = TreeKEM is agnostic about H, we can "define" >=20 > H(X) :=3D H2(DH(X, priv(C2))) >=20 > in this way without issue, noting that the only users who will have to = compute H2(DH(X, priv(C2))) are descendants of C1 (who know X) or C2 = (who know priv(C2)). >=20 > We can merge updates as with "pure" TreeKEM, choosing one update to = dominate at nodes where they conflict. This will cause the tree to = cease being a DH tree, which is fine. Note that descendants of C2 will = have to keep around priv(C2) for a short time after it is overwritten in = case of simultaneous updates (so that they can compute the parent = secret), but that is true for TreeKEM anyway, since any simultaneous = update will send data encrypted under pub(C2). >=20 > Blank nodes can be handled by reverting to pure TreeKEM: if a node = with new secret X has a blank neighbor, set the parent's secret to H(X) = and send that separately to every public key in the resolution. >=20 > Now instead of including >=20 > pub(X), Enc(pub(C2), H(X)) >=20 > in the RatchetNode struct for node C2, we need merely include pub(X), = saving bandwidth. >=20 > Pros: > - reduces the update message size by about 50% in the typical case = (I think). > - we can build a ternary tree using 3-party Joux DH (as with ART), = giving a further log_3(2) ~ 0.63 scaling on update message size. (I = think it's possible to do this with pure TreeKEM as well, by replacing = the ephemeral DH exchange with a Joux DH when doing asymmetric = encryption.) >=20 > Cons: > - forced to use a DH style cryptosystem (bad for post-quantum?) (as = with ART). > - need log(N) DH operations to compute the new key, instead of = log(N) hashes (as with ART). So this is a bad deal if CPU cycles are = more expensive than bandwidth. > - can also reduce bandwidth by 2 just by ratcheting half as often. >=20 > I hope you may find this interesting. >=20 > Best, > Matthew Weidner > MPhil student, University of Cambridge > _______________________________________________ > 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=_DBF8A3D7-C74E-4E4A-AD94-A23E4E2DAE4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Matthew,

One of the = convincing reasons we saw when looking into ART vs. TreeKEM was that the = recipient of handshake messages can process them with O(1) DH operations = with TreeKEM as opposed to O(log n) with ART. This sounds like a small = difference at first, but we believe that it makes a big difference in = real life scenarios. Clients will mostly process handshake messages = (particularly in large dynamic groups), but only rarely send them. The = hunch is that TreeKEM is roughly an order of magnitude faster for = average operations in MLS.
If we go back to O(log = n) DH operations to derive the root secret we would lose the speed = advantage.

Raphael

On 25 Feb 2019, at 23:07, = Richard Barnes <rlb@ipv.sx> wrote:

Hi Matthew,

Thanks for the thoughts.  Would it = be accurate to summarize your proposal as a "hybrid mode", where when = you update:

- = If both of a node's children are populated, then you do an "ART step", = generating the parent from the children
- = Otherwise, you do a "TreeKEM step", encrypting the next secret to the = resolution of the other child

(Remove is probably similar; for Add = there's no change needed.)

Assuming that's right, this honestly doesn't sound like a = tremendously compelling proposition to me.  Your evaluation on the = overhead seems mostly correct, but there have already been some = complaints on the list about hashing overhead, so I'm not sure trading = DH+smaller_messages for hashing is going to suit.  I'm also worried = that this hybridization will introduce a bunch of new complexity into = the protocol and make it harder to implement and analyze.  Open to = arguments if other folks are enthusiastic, though.

--Richard







On Mon, Feb 25, 2019 at 4:37 PM M.A.L. Weidner = <malw2@cam.ac.uk> = wrote:
Greatings MLS Working Group!

I have been studying the proposals for TreeKEM, and = earlier, ART, and noticed a way to use ART's DH tree ideas in TreeKEM, = without sacrificing the ability to merge updates or use blank = nodes.  My apologies if this has been discussed before or if there are any mistakes.

My main motivation here is to reduce the size of update = messages, since the key encrypted keys in addition to new public keys = means that they are ~2x as large in TreeKEM as in ART.

Basically, we use TreeKEM, but with ART's key derivation = "as" H(X).  That is, when a node C1 gets the new secret X, instead = of H(X), its parent gets the new secret

H2(DH(X, priv(C2))) =3D H2(pub(C2) ^ X) =3D H2(pub(X) ^ priv(C2))

where C2 is the neighbor of C1, for some hash function H2.  Since = TreeKEM is agnostic about H, we can "define"

H(X) :=3D H2(DH(X, priv(C2)))

in this way without issue, noting that the only users who will have to = compute H2(DH(X, priv(C2))) are descendants of C1 (who know X) or C2 = (who know priv(C2)).

We can merge updates as with "pure" TreeKEM, choosing one update to = dominate at nodes where they conflict.  This will cause the tree to = cease being a DH tree, which is fine.  Note that descendants of C2 = will have to keep around priv(C2) for a short time after it is overwritten in case of simultaneous updates (so that they can = compute the parent secret), but that is true for TreeKEM anyway, since = any simultaneous update will send data encrypted under pub(C2).

Blank nodes can be handled by reverting to pure TreeKEM: if a node with = new secret X has a blank neighbor, set the parent's secret to H(X) and = send that separately to every public key in the resolution.
=
Now instead of including

pub(X), Enc(pub(C2), H(X))

in the RatchetNode struct for node C2, we need merely include pub(X), = saving bandwidth.

Pros:
  - reduces the update message size by about 50% in the typical = case (I think).
  - we can build a ternary tree using 3-party Joux DH (as with = ART), giving a further log_3(2) ~ 0.63 scaling on update message = size.  (I think it's possible to do this with pure TreeKEM as well, = by replacing the ephemeral DH exchange with a Joux DH when doing asymmetric encryption.)

Cons:
  - forced to use a DH style cryptosystem (bad for post-quantum?) = (as with ART).
  - need log(N) DH operations to compute the new key, instead of = log(N) hashes (as with ART).  So this is a bad deal if CPU cycles = are more expensive than bandwidth.
  - can also reduce bandwidth by 2 just by ratcheting half as = often.

I hope you may find this interesting.

Best,
Matthew Weidner
MPhil student, University of Cambridge
_______________________________________________
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=_DBF8A3D7-C74E-4E4A-AD94-A23E4E2DAE4C-- From nobody Wed Feb 27 05:14:40 2019 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 15CC8130FC5 for ; Wed, 27 Feb 2019 05:14:38 -0800 (PST) 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 BrqMqF9HIkfB for ; Wed, 27 Feb 2019 05:14:37 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 B71D3130FBF for ; Wed, 27 Feb 2019 05:14:36 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id p48so19085925qtk.2 for ; Wed, 27 Feb 2019 05:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=VWPDz8lpuIQeN8zsgYzgugSNOvKCwJWCLh02rkjJILo=; b=UoSgelN4sVH/0/Of2nTuKhOoq8vRKlxzihSJXbN7GACXNfyFD97TTO5aoXc+aLjkNg mzUq8hk5VEixGVUQG01Z6uxvb442lL4qE/r1VGdN7sfGIGRB5fkVV7pxwqlScAuuFmei XjHnF13/NT2+YKAfiTXVMUNw6eQZ2vnD5ZtOc= 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=VWPDz8lpuIQeN8zsgYzgugSNOvKCwJWCLh02rkjJILo=; b=ZG9niz4SRigIyK6F2kTxmYt1A744PXgn8CSMlseunWiRSc7veyZLEM8OAuXtXS3EVp wT15jSzDkPEGgoFop57IRrqCtnOvQ/5VsjvQIuW3QYmC4Wv5zSlQUz1i0hH1hoOuBAh0 uXUy9qqzLhzAtBnnhlUu6ptqdC0OOG5AsXN50NxbzpkykeDt7jtloVaH11XZ9DUy7kxN ZVEtos1coATTBaPdZqgc1budwGbtYNf1gF7UQF7P/ByzSxavzu1o5Peye8DqoylVj3SV yjUmVJExTpSVqqcDT6TjeX+w1sPsrzo6tuzNjxN8rHMK15y3oJaOkDjClyg+JFAJ638o HIfw== X-Gm-Message-State: APjAAAVcrnyyhKaSDpR0owgXKezh4PBKyL3ZWKZakUHraoj/5OBeE2Vi f4DBVufXdjYLLoqsZgrJX5IWJc2mWFDDXQ== X-Google-Smtp-Source: AHgI3IY++BARxuoKA9yo138uwA697FAa5bd1o7MbP6kb92VdOK+Nhw4ZkN7+wAkrVCr+zA4GiHbILw== X-Received: by 2002:ac8:2de4:: with SMTP id q33mr1542755qta.358.1551273275754; Wed, 27 Feb 2019 05:14:35 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id c10sm8391447qkk.91.2019.02.27.05.14.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 05:14:34 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <50BCD9AE-0D30-4587-9453-5AA4E9573003@sn3rd.com> Date: Wed, 27 Feb 2019 08:14:34 -0500 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.102.3) 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: Wed, 27 Feb 2019 13:14:38 -0000 Hello MLS working group, Just a reminder that the deadline for IETF 104 draft revisions is Monday = the 11th of March. 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, Tuesday (2hr) and Thursday (1h) so let us know if you have a = preference. We will be accepting remote presentations. Nick & Sean= From nobody Wed Feb 27 06:13:35 2019 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 E1059130DE7 for ; Wed, 27 Feb 2019 06:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=universityofcambridgecloud.onmicrosoft.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 d1AmfppjMn6k for ; Wed, 27 Feb 2019 06:13:30 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50138.outbound.protection.outlook.com [40.107.5.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0876A12F1AC for ; Wed, 27 Feb 2019 06:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UniversityOfCambridgeCloud.onmicrosoft.com; s=selector1-cam-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T8Rp+rZ8ybk7tXTcTCmpXMLjR+wzMVbyWhW0DtdUbX0=; b=d2nzUO8u4ns/Yblb5rql3NWWfDLFKlfTxoD1yLcWqwSeWnBQyxn9I5Os6uUGRir6yIy+OSFno+fdIl2Bfi59AfkGxlYxZjq0YU3jbs0DKm9y/hzVgk3l+0wvnrEqfBQagSAmChtkUO93jexSl//u4Keiqxl9ej+npkRAa1c83pc= Received: from AM5PR0801MB1281.eurprd08.prod.outlook.com (10.167.216.144) by AM5PR0801MB1971.eurprd08.prod.outlook.com (10.168.158.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Wed, 27 Feb 2019 14:13:26 +0000 Received: from AM5PR0801MB1281.eurprd08.prod.outlook.com ([fe80::a425:8068:2b75:8f47]) by AM5PR0801MB1281.eurprd08.prod.outlook.com ([fe80::a425:8068:2b75:8f47%3]) with mapi id 15.20.1643.019; Wed, 27 Feb 2019 14:13:26 +0000 From: "M.A.L. Weidner" To: Raphael Robert CC: "mls@ietf.org" , Richard Barnes Thread-Topic: [MLS] ART Ideas in TreeKEM Thread-Index: AQHUzVJJoSxk3lmKTky1XqgDJ73oyA== Date: Wed, 27 Feb 2019 14:13:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM6P193CA0033.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:3e::46) To AM5PR0801MB1281.eurprd08.prod.outlook.com (2603:10a6:203:1e::16) x-ms-exchange-messagesentrepresentingtype: 1 x-gm-message-state: APjAAAWNqCruyR2QAb3rwsYoGq7L515vygC1YpeCGXLlQpkxnnlu2Iz9 ZHt7shCJjZyH+q2pN/Afq2PRVmGeIy+HZLdf5Ac= x-google-smtp-source: APXvYqxnJJfjumo6B88BTmnnK3RMkSkd8BNlZf3pBWShi9V1RIBBi5OwGlhFFl9pNTz1NoDznu3Oke7FodMd1BnUE/w= x-received: by 2002:a5d:574b:: with SMTP id q11mr2489627wrw.41.1551276804881; Wed, 27 Feb 2019 06:13:24 -0800 (PST) x-gmail-original-message-id: x-originating-ip: [209.85.221.49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e80f1afa-5fdb-4335-ff09-08d69cbdbd5d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM5PR0801MB1971; x-ms-traffictypediagnostic: AM5PR0801MB1971: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtBTTVQUjA4MDFNQjE5NzE7MjM6cHRhcGExSnB6Zy8yZkFZYmJ2YU4rbEdS?= =?utf-8?B?NWQzVU5YaDlzeWRHSy9XaEgreVNqQmdGVG94QkJKcDR0OTR5RWJ6bFNNZ3NI?= =?utf-8?B?dWhIby91NW1OUFJZK3ZtN0NyUWZDN3pqc1hQdmw0MW1Nc1pzT1B3QnpFZm1Z?= =?utf-8?B?MHJQQVhKVDJaT0dnNWRVUDBqSld3RkoreEgwWll4clVoeDlFZnhyY3dsQk9n?= =?utf-8?B?VmVnN2gvMThkOTZsQ21wMzdzbDRNemRVR2trSER0T0xaU0tvQWZQWHlHdEx5?= =?utf-8?B?eXhyMm9RVVBWbEhBdWIvT1l1K1dHeW5zYm9vWkVpYkNCbkNYWjZvS0lkMVAy?= =?utf-8?B?SEl1cHcrbnExKzc5ckgyQXROZmxxdmczVWppdTJudjhKRTEyY0JGRFFLUDRz?= =?utf-8?B?ZVEwMit6cFVQdjhscGV2RTRDRVZTdjFpbFpMZFl5WE9yakVQNkxnbmFFZTN4?= =?utf-8?B?QTZxUmdxY1d3ZnNLbEozdlA2N1RIN0xabm1PREtKTnZFcmFOTXZXVFdSTnRO?= =?utf-8?B?bVVWL295RG5HWllDV3dldmRySU14OEZ6Q2VqZUhGeURDaVFRaDV1c3BWOFdk?= =?utf-8?B?VmJoN3RsNm1Zdmo3NjV4M0luMXcwZGVoc3BaQWI3NTc3VTZSUUZJWW9ReDdo?= =?utf-8?B?Rzk5U3J2M3hmNllkaEsraEJLMUI0R0g1SUgxeU8xem5MWU9FMHZVMUF3UURF?= =?utf-8?B?YWJVV2tiYU1uQ21vSVFZMWVWUjR1dFFMbzloRnRaNDFMUFB1TzdIazdwVXVK?= =?utf-8?B?OXJiVnBUZUhIS3M4NUZ5YWNZYitvLzFIQnNaUGxITWx5TTFMZE5LWGZCNjQw?= =?utf-8?B?aWt5SE9EUWNra2lHUlp2bVp5bERXenhMclgzbWRDTWxyNEtEc0VYamxKeXpw?= =?utf-8?B?aVFUMXJaeGJkRzlSMExzL2ExR21CaG42Q1NCcXNoWW00ZmJqOS9kNytsRFVH?= =?utf-8?B?V0RIN1V2M0FwRlhPUjhmcjM0ckVZODJYbnA0cG1FU3RlWUxPSENNK2lYcStN?= =?utf-8?B?dnZ5T3Fyd2pjOE9UQVlJSVlhVUw3aCtyQ0NONWRQa3h3RlhGWkNPTVJkT1NM?= =?utf-8?B?YUdrbU90b1p1OCtJUlBGeVVTL0JFOHJVUHJYQmtLbExxcVY0NEJBelowRHBT?= =?utf-8?B?dlYrQ2FXY0xFamZIKzN0V2Z5QzlVcFFWeXI4ZzVUUkVNR3o0ZlNkNzVsQUhZ?= =?utf-8?B?bTduVGM5WmxFMDIzQVJLOW9HYm1EY2hBakMyS1Q4YjFPeVl5RnE2UHhMbXpF?= =?utf-8?B?TkdseUpUU2QzRjBHZnhCY3pUckE2OHVVMFROZHUvbTFVRy9lay9KRHd0UVEz?= =?utf-8?B?NzFkUWQvNXpzak9tWk1xUG1Vd2FuRHZ4NGxPcUo2TVl1RTN3Q0l4TWZhdkl6?= =?utf-8?B?SlBDbW8yVEJWdlo2MTNSaHhoUUZmYW5tWU10ZGt2T2V4MjEwNUFtMG54TlBI?= =?utf-8?B?OFlYZVFQUmNGeG4zUTZYeVdMdmVWSkZTVmxaRXRwTEpLY3hTck1wUzhzYVFn?= =?utf-8?B?ZzJtQmV5Z0N6TzJlb1FjWVJPMzl0Y3ora2FocC9HTWdiWmEzZDg0UGNCTkZG?= =?utf-8?B?Y0VGamxJK214dmZac3I1R0xuNUNsMVdUTXJ3S05ZU08rV1ZrNHNLL1dNczRu?= =?utf-8?B?WDZmTkhza0xYWkkwdnhUNEZBNTI2aVNSTFJOTXZWaTh3Uy9EVEE5V050YzAv?= =?utf-8?B?MHVPNzRGb1NrbXBiL1BQbnBIcmdGMmJvY0o4OWdReUgwV3ZsUHZXeGF1K1ls?= =?utf-8?B?U0VKRTZ2bWRnZU9xNVpONEp5ZVM2OHF2dEVwQ3BCVHdrZ2dxMSsyZW5QbHFw?= =?utf-8?B?VXVkdkIrMUlvczRacnB2dDFLelNnNk94RkI5a0VpWFNMeDJIRTA0MDNiUm1M?= =?utf-8?B?NG1POGlXb2k2aU5GMWJrK2JwUWdqZ3czdW5HSlpaL1FQTjBSZ0RBK29KM09x?= =?utf-8?B?UlVjVTJ5OXRjOHUzN2libDhPMkI5MHlUc2kxbGwxVzJaZWtEU1RtNW1ENytV?= =?utf-8?B?d29hUThFOTd5d1lVd0ZFUVhialdiUXN3dDdDeVdvNFkwNm8vbWlzN1VCTXdV?= =?utf-8?B?d0hYMTNwSjU2ckYrWlI1d1VQUk1JV2FtbSs4UUxDcmpJRER2KzRDc1F4Ly9q?= =?utf-8?Q?LUETWU5oIAuBQyWOexgoXFKS4=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(396003)(376002)(346002)(189003)(199004)(52314003)(51914003)(6246003)(97736004)(6486002)(6506007)(386003)(6436002)(966005)(478600001)(236005)(14454004)(6512007)(54896002)(6306002)(53936002)(9686003)(99286004)(102836004)(61266001)(6346003)(52116002)(76176011)(2906002)(95326003)(71200400001)(71190400001)(256004)(14444005)(7736002)(8936002)(305945005)(53546011)(5660300002)(8676002)(55446002)(86362001)(81156014)(81166006)(498394004)(61726006)(4326008)(6862004)(25786009)(486006)(5070765005)(54906003)(26005)(68736007)(6116002)(105586002)(74482002)(186003)(786003)(316002)(229853002)(476003)(106356001)(66066001)(3846002)(446003)(11346002)(561944003)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0801MB1971; H:AM5PR0801MB1281.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cam.ac.uk does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=malw2@cam.ac.uk; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yUP+WqgeBdY6rwx3JlgS7eQWqoNl+UGmXTdx2r8GFM/A6KW9O414G1MbesjyjT2IT39+HF3X5n73Lok4p2FSwfHNjlQ80hwo9Slh8ElXDwoHwpHutz0hlm3GX3BRW4bzIIxctgoPWd1lgLGrX4Y1bezXmXQumMktvqX1sDUHqWqg652BE1knCojMdTObJlcx5Aw9IecdiSOdJfVRaSa3jUvGsGvlh4EQW1mEx3ofh6/HbD8wohwIWrjpOjuEv8QGcoFDMZmOuPZuL0uI5dIJrjE3mP6H1hN+X9jOiKZ/ibbau6UIA5+LpIkW/Bx7ZaFMgt3IKodi7MPzYy91Vw79ORx4jbARP6+9URsERYLBmgjlww/DTLAXGByprH1laRlcPIzCTp/C+zpzpI9rcvV3ieXfzJbfLyDpsT04sI+oW6M= Content-Type: multipart/alternative; boundary="_000_CADSARUuAiWt0b8A7XcAPMA08GE3RmW0M9zzqrScdrh4Rp4AXQmailg_" MIME-Version: 1.0 X-OriginatorOrg: cam.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: e80f1afa-5fdb-4335-ff09-08d69cbdbd5d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 14:13:25.9299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 49a50445-bdfa-4b79-ade3-547b4f3986e9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1971 Archived-At: Subject: Re: [MLS] ART Ideas in TreeKEM 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, 27 Feb 2019 14:13:34 -0000 --_000_CADSARUuAiWt0b8A7XcAPMA08GE3RmW0M9zzqrScdrh4Rp4AXQmailg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCBhbmQgUmFwaGFlbCwNCg0KPiBXb3VsZCBpdCBiZSBhY2N1cmF0ZSB0byBzdW1t YXJpemUgeW91ciBwcm9wb3NhbCBhcyBhICJoeWJyaWQgbW9kZSIsIHdoZXJlIHdoZW4geW91IHVw ZGF0ZToNCj4gLSBJZiBib3RoIG9mIGEgbm9kZSdzIGNoaWxkcmVuIGFyZSBwb3B1bGF0ZWQsIHRo ZW4geW91IGRvIGFuICJBUlQgc3RlcCIsIGdlbmVyYXRpbmcgdGhlIHBhcmVudCBmcm9tIHRoZSBj aGlsZHJlbg0KPiAtIE90aGVyd2lzZSwgeW91IGRvIGEgIlRyZWVLRU0gc3RlcCIsIGVuY3J5cHRp bmcgdGhlIG5leHQgc2VjcmV0IHRvIHRoZSByZXNvbHV0aW9uIG9mIHRoZSBvdGhlciBjaGlsZA0K VGhhdCdzIGEgZ29vZCB3YXkgdG8gZGVzY3JpYmUgaXQuICBPbmUgZXh0cmEgZGV0YWlsIGlzIHRo YXQgaWYgdHdvIHVwZGF0ZXMgYm90aCBhZmZlY3QgYSBub2RlLCB5b3UgY2hvb3NlIG9uZSB1cGRh dGUgdG8gd2luIGFuZCBzZXQgdGhlIG5ldyBzZWNyZXQgdG8gYmUgd2hhdCBpdCB3b3VsZCBoYXZl IGJlZW4gZ2l2ZW4gdGhhdCB1cGRhdGUgYWxvbmUsIGluc3RlYWQgb2YgZG9pbmcgREggb24gYm90 aCBuZXcgY2hpbGRyZW4uDQoNCj5UaGUgaHVuY2ggaXMgdGhhdCBUcmVlS0VNIGlzIHJvdWdobHkg YW4gb3JkZXIgb2YgbWFnbml0dWRlIGZhc3RlciBmb3IgYXZlcmFnZSBvcGVyYXRpb25zIGluIE1M Uy4NClllcywgdGhhdCBzZWVtcyBsaWtlIGEgZ29vZCBhcmd1bWVudCBhZ2FpbnN0IGl0LiAgSW4g cHJpbmNpcGxlIHdlIGhhdmUgYSB0cmFkZW9mZiBiZXR3ZWVuIGJhbmR3aWR0aCBhbmQgQ1BVIGNv c3QsIGJ1dCBpbiBwcmFjdGljZSB0aGUgYmFuZHdpZHRoIGNvc3QgaXMgc21hbGwgKHBlcmhhcHMg MSBLQi91cGRhdGU/KSB3aGlsZSB0aGlzIENQVSBjb3N0IGlzIGxhcmdlLCB1bmxlc3Mgd2UgYXJl IGluIGFuIHVudXN1YWxseSBuZXR3b3JrLWNvbnN0cmFpbmVkIGVudmlyb25tZW50Lg0KDQpCZXN0 LA0KTWF0dGhldw0KDQpPbiBUdWUsIEZlYiAyNiwgMjAxOSBhdCA5OjAxIEFNIFJhcGhhZWwgUm9i ZXJ0IDxyYXBoYWVsQHdpcmUuY29tPG1haWx0bzpyYXBoYWVsQHdpcmUuY29tPj4gd3JvdGU6DQpI aSBNYXR0aGV3LA0KDQpPbmUgb2YgdGhlIGNvbnZpbmNpbmcgcmVhc29ucyB3ZSBzYXcgd2hlbiBs b29raW5nIGludG8gQVJUIHZzLiBUcmVlS0VNIHdhcyB0aGF0IHRoZSByZWNpcGllbnQgb2YgaGFu ZHNoYWtlIG1lc3NhZ2VzIGNhbiBwcm9jZXNzIHRoZW0gd2l0aCBPKDEpIERIIG9wZXJhdGlvbnMg d2l0aCBUcmVlS0VNIGFzIG9wcG9zZWQgdG8gTyhsb2cgbikgd2l0aCBBUlQuIFRoaXMgc291bmRz IGxpa2UgYSBzbWFsbCBkaWZmZXJlbmNlIGF0IGZpcnN0LCBidXQgd2UgYmVsaWV2ZSB0aGF0IGl0 IG1ha2VzIGEgYmlnIGRpZmZlcmVuY2UgaW4gcmVhbCBsaWZlIHNjZW5hcmlvcy4gQ2xpZW50cyB3 aWxsIG1vc3RseSBwcm9jZXNzIGhhbmRzaGFrZSBtZXNzYWdlcyAocGFydGljdWxhcmx5IGluIGxh cmdlIGR5bmFtaWMgZ3JvdXBzKSwgYnV0IG9ubHkgcmFyZWx5IHNlbmQgdGhlbS4gVGhlIGh1bmNo IGlzIHRoYXQgVHJlZUtFTSBpcyByb3VnaGx5IGFuIG9yZGVyIG9mIG1hZ25pdHVkZSBmYXN0ZXIg Zm9yIGF2ZXJhZ2Ugb3BlcmF0aW9ucyBpbiBNTFMuDQpJZiB3ZSBnbyBiYWNrIHRvIE8obG9nIG4p IERIIG9wZXJhdGlvbnMgdG8gZGVyaXZlIHRoZSByb290IHNlY3JldCB3ZSB3b3VsZCBsb3NlIHRo ZSBzcGVlZCBhZHZhbnRhZ2UuDQoNClJhcGhhZWwNCg0KT24gMjUgRmViIDIwMTksIGF0IDIzOjA3 LCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86cmxiQGlwdi5zeD4+IHdyb3RlOg0K DQpIaSBNYXR0aGV3LA0KDQpUaGFua3MgZm9yIHRoZSB0aG91Z2h0cy4gIFdvdWxkIGl0IGJlIGFj Y3VyYXRlIHRvIHN1bW1hcml6ZSB5b3VyIHByb3Bvc2FsIGFzIGEgImh5YnJpZCBtb2RlIiwgd2hl cmUgd2hlbiB5b3UgdXBkYXRlOg0KDQotIElmIGJvdGggb2YgYSBub2RlJ3MgY2hpbGRyZW4gYXJl IHBvcHVsYXRlZCwgdGhlbiB5b3UgZG8gYW4gIkFSVCBzdGVwIiwgZ2VuZXJhdGluZyB0aGUgcGFy ZW50IGZyb20gdGhlIGNoaWxkcmVuDQotIE90aGVyd2lzZSwgeW91IGRvIGEgIlRyZWVLRU0gc3Rl cCIsIGVuY3J5cHRpbmcgdGhlIG5leHQgc2VjcmV0IHRvIHRoZSByZXNvbHV0aW9uIG9mIHRoZSBv dGhlciBjaGlsZA0KDQooUmVtb3ZlIGlzIHByb2JhYmx5IHNpbWlsYXI7IGZvciBBZGQgdGhlcmUn cyBubyBjaGFuZ2UgbmVlZGVkLikNCg0KQXNzdW1pbmcgdGhhdCdzIHJpZ2h0LCB0aGlzIGhvbmVz dGx5IGRvZXNuJ3Qgc291bmQgbGlrZSBhIHRyZW1lbmRvdXNseSBjb21wZWxsaW5nIHByb3Bvc2l0 aW9uIHRvIG1lLiAgWW91ciBldmFsdWF0aW9uIG9uIHRoZSBvdmVyaGVhZCBzZWVtcyBtb3N0bHkg Y29ycmVjdCwgYnV0IHRoZXJlIGhhdmUgYWxyZWFkeSBiZWVuIHNvbWUgY29tcGxhaW50cyBvbiB0 aGUgbGlzdCBhYm91dCBoYXNoaW5nIG92ZXJoZWFkLCBzbyBJJ20gbm90IHN1cmUgdHJhZGluZyBE SCtzbWFsbGVyX21lc3NhZ2VzIGZvciBoYXNoaW5nIGlzIGdvaW5nIHRvIHN1aXQuICBJJ20gYWxz byB3b3JyaWVkIHRoYXQgdGhpcyBoeWJyaWRpemF0aW9uIHdpbGwgaW50cm9kdWNlIGEgYnVuY2gg b2YgbmV3IGNvbXBsZXhpdHkgaW50byB0aGUgcHJvdG9jb2wgYW5kIG1ha2UgaXQgaGFyZGVyIHRv IGltcGxlbWVudCBhbmQgYW5hbHl6ZS4gIE9wZW4gdG8gYXJndW1lbnRzIGlmIG90aGVyIGZvbGtz IGFyZSBlbnRodXNpYXN0aWMsIHRob3VnaC4NCg0KLS1SaWNoYXJkDQoNCg0KDQoNCg0KDQoNCk9u IE1vbiwgRmViIDI1LCAyMDE5IGF0IDQ6MzcgUE0gTS5BLkwuIFdlaWRuZXIgPG1hbHcyQGNhbS5h Yy51azxtYWlsdG86bWFsdzJAY2FtLmFjLnVrPj4gd3JvdGU6DQpHcmVhdGluZ3MgTUxTIFdvcmtp bmcgR3JvdXAhDQoNCkkgaGF2ZSBiZWVuIHN0dWR5aW5nIHRoZSBwcm9wb3NhbHMgZm9yIFRyZWVL RU0sIGFuZCBlYXJsaWVyLCBBUlQsIGFuZCBub3RpY2VkIGEgd2F5IHRvIHVzZSBBUlQncyBESCB0 cmVlIGlkZWFzIGluIFRyZWVLRU0sIHdpdGhvdXQgc2FjcmlmaWNpbmcgdGhlIGFiaWxpdHkgdG8g bWVyZ2UgdXBkYXRlcyBvciB1c2UgYmxhbmsgbm9kZXMuICBNeSBhcG9sb2dpZXMgaWYgdGhpcyBo YXMgYmVlbiBkaXNjdXNzZWQgYmVmb3JlIG9yIGlmIHRoZXJlIGFyZSBhbnkgbWlzdGFrZXMuDQoN Ck15IG1haW4gbW90aXZhdGlvbiBoZXJlIGlzIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiB1cGRhdGUg bWVzc2FnZXMsIHNpbmNlIHRoZSBrZXkgZW5jcnlwdGVkIGtleXMgaW4gYWRkaXRpb24gdG8gbmV3 IHB1YmxpYyBrZXlzIG1lYW5zIHRoYXQgdGhleSBhcmUgfjJ4IGFzIGxhcmdlIGluIFRyZWVLRU0g YXMgaW4gQVJULg0KDQpCYXNpY2FsbHksIHdlIHVzZSBUcmVlS0VNLCBidXQgd2l0aCBBUlQncyBr ZXkgZGVyaXZhdGlvbiAiYXMiIEgoWCkuICBUaGF0IGlzLCB3aGVuIGEgbm9kZSBDMSBnZXRzIHRo ZSBuZXcgc2VjcmV0IFgsIGluc3RlYWQgb2YgSChYKSwgaXRzIHBhcmVudCBnZXRzIHRoZSBuZXcg c2VjcmV0DQoNCkgyKERIKFgsIHByaXYoQzIpKSkgPSBIMihwdWIoQzIpIF4gWCkgPSBIMihwdWIo WCkgXiBwcml2KEMyKSkNCg0Kd2hlcmUgQzIgaXMgdGhlIG5laWdoYm9yIG9mIEMxLCBmb3Igc29t ZSBoYXNoIGZ1bmN0aW9uIEgyLiAgU2luY2UgVHJlZUtFTSBpcyBhZ25vc3RpYyBhYm91dCBILCB3 ZSBjYW4gImRlZmluZSINCg0KSChYKSA6PSBIMihESChYLCBwcml2KEMyKSkpDQoNCmluIHRoaXMg d2F5IHdpdGhvdXQgaXNzdWUsIG5vdGluZyB0aGF0IHRoZSBvbmx5IHVzZXJzIHdobyB3aWxsIGhh dmUgdG8gY29tcHV0ZSBIMihESChYLCBwcml2KEMyKSkpIGFyZSBkZXNjZW5kYW50cyBvZiBDMSAo d2hvIGtub3cgWCkgb3IgQzIgKHdobyBrbm93IHByaXYoQzIpKS4NCg0KV2UgY2FuIG1lcmdlIHVw ZGF0ZXMgYXMgd2l0aCAicHVyZSIgVHJlZUtFTSwgY2hvb3Npbmcgb25lIHVwZGF0ZSB0byBkb21p bmF0ZSBhdCBub2RlcyB3aGVyZSB0aGV5IGNvbmZsaWN0LiAgVGhpcyB3aWxsIGNhdXNlIHRoZSB0 cmVlIHRvIGNlYXNlIGJlaW5nIGEgREggdHJlZSwgd2hpY2ggaXMgZmluZS4gIE5vdGUgdGhhdCBk ZXNjZW5kYW50cyBvZiBDMiB3aWxsIGhhdmUgdG8ga2VlcCBhcm91bmQgcHJpdihDMikgZm9yIGEg c2hvcnQgdGltZSBhZnRlciBpdCBpcyBvdmVyd3JpdHRlbiBpbiBjYXNlIG9mIHNpbXVsdGFuZW91 cyB1cGRhdGVzIChzbyB0aGF0IHRoZXkgY2FuIGNvbXB1dGUgdGhlIHBhcmVudCBzZWNyZXQpLCBi dXQgdGhhdCBpcyB0cnVlIGZvciBUcmVlS0VNIGFueXdheSwgc2luY2UgYW55IHNpbXVsdGFuZW91 cyB1cGRhdGUgd2lsbCBzZW5kIGRhdGEgZW5jcnlwdGVkIHVuZGVyIHB1YihDMikuDQoNCkJsYW5r IG5vZGVzIGNhbiBiZSBoYW5kbGVkIGJ5IHJldmVydGluZyB0byBwdXJlIFRyZWVLRU06IGlmIGEg bm9kZSB3aXRoIG5ldyBzZWNyZXQgWCBoYXMgYSBibGFuayBuZWlnaGJvciwgc2V0IHRoZSBwYXJl bnQncyBzZWNyZXQgdG8gSChYKSBhbmQgc2VuZCB0aGF0IHNlcGFyYXRlbHkgdG8gZXZlcnkgcHVi bGljIGtleSBpbiB0aGUgcmVzb2x1dGlvbi4NCg0KTm93IGluc3RlYWQgb2YgaW5jbHVkaW5nDQoN CnB1YihYKSwgRW5jKHB1YihDMiksIEgoWCkpDQoNCmluIHRoZSBSYXRjaGV0Tm9kZSBzdHJ1Y3Qg Zm9yIG5vZGUgQzIsIHdlIG5lZWQgbWVyZWx5IGluY2x1ZGUgcHViKFgpLCBzYXZpbmcgYmFuZHdp ZHRoLg0KDQpQcm9zOg0KICAtIHJlZHVjZXMgdGhlIHVwZGF0ZSBtZXNzYWdlIHNpemUgYnkgYWJv dXQgNTAlIGluIHRoZSB0eXBpY2FsIGNhc2UgKEkgdGhpbmspLg0KICAtIHdlIGNhbiBidWlsZCBh IHRlcm5hcnkgdHJlZSB1c2luZyAzLXBhcnR5IEpvdXggREggKGFzIHdpdGggQVJUKSwgZ2l2aW5n IGEgZnVydGhlciBsb2dfMygyKSB+IDAuNjMgc2NhbGluZyBvbiB1cGRhdGUgbWVzc2FnZSBzaXpl LiAgKEkgdGhpbmsgaXQncyBwb3NzaWJsZSB0byBkbyB0aGlzIHdpdGggcHVyZSBUcmVlS0VNIGFz IHdlbGwsIGJ5IHJlcGxhY2luZyB0aGUgZXBoZW1lcmFsIERIIGV4Y2hhbmdlIHdpdGggYSBKb3V4 IERIIHdoZW4gZG9pbmcgYXN5bW1ldHJpYyBlbmNyeXB0aW9uLikNCg0KQ29uczoNCiAgLSBmb3Jj ZWQgdG8gdXNlIGEgREggc3R5bGUgY3J5cHRvc3lzdGVtIChiYWQgZm9yIHBvc3QtcXVhbnR1bT8p IChhcyB3aXRoIEFSVCkuDQogIC0gbmVlZCBsb2coTikgREggb3BlcmF0aW9ucyB0byBjb21wdXRl IHRoZSBuZXcga2V5LCBpbnN0ZWFkIG9mIGxvZyhOKSBoYXNoZXMgKGFzIHdpdGggQVJUKS4gIFNv IHRoaXMgaXMgYSBiYWQgZGVhbCBpZiBDUFUgY3ljbGVzIGFyZSBtb3JlIGV4cGVuc2l2ZSB0aGFu IGJhbmR3aWR0aC4NCiAgLSBjYW4gYWxzbyByZWR1Y2UgYmFuZHdpZHRoIGJ5IDIganVzdCBieSBy YXRjaGV0aW5nIGhhbGYgYXMgb2Z0ZW4uDQoNCkkgaG9wZSB5b3UgbWF5IGZpbmQgdGhpcyBpbnRl cmVzdGluZy4NCg0KQmVzdCwNCk1hdHRoZXcgV2VpZG5lcg0KTVBoaWwgc3R1ZGVudCwgVW5pdmVy c2l0eSBvZiBDYW1icmlkZ2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpNTFMgbWFpbGluZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFpbHRvOk1MU0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlz dA0KTUxTQGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21scw0KDQo= --_000_CADSARUuAiWt0b8A7XcAPMA08GE3RmW0M9zzqrScdrh4Rp4AXQmailg_ Content-Type: text/html; charset="utf-8" Content-ID: <2BB654F3754F3244A53A8EFA9AE4A0BF@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2PkhpIFJpY2hhcmQgYW5kIFJhcGhhZWwsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+Jmd0OyBXb3VsZCBpdCBiZSBhY2N1cmF0ZSB0byBzdW1tYXJpemUgeW91 ciBwcm9wb3NhbCBhcyBhICZxdW90O2h5YnJpZCBtb2RlJnF1b3Q7LCB3aGVyZSB3aGVuIHlvdSB1 cGRhdGU6PC9kaXY+DQo8ZGl2PiZndDsgLSBJZiBib3RoIG9mIGEgbm9kZSdzIGNoaWxkcmVuIGFy ZSBwb3B1bGF0ZWQsIHRoZW4geW91IGRvIGFuICZxdW90O0FSVCBzdGVwJnF1b3Q7LCBnZW5lcmF0 aW5nIHRoZSBwYXJlbnQgZnJvbSB0aGUgY2hpbGRyZW48L2Rpdj4NCjxkaXY+Jmd0OyAtIE90aGVy d2lzZSwgeW91IGRvIGEgJnF1b3Q7VHJlZUtFTSBzdGVwJnF1b3Q7LCBlbmNyeXB0aW5nIHRoZSBu ZXh0IHNlY3JldCB0byB0aGUgcmVzb2x1dGlvbiBvZiB0aGUgb3RoZXIgY2hpbGQ8L2Rpdj4NCjxk aXY+VGhhdCdzIGEgZ29vZCB3YXkgdG8gZGVzY3JpYmUgaXQuJm5ic3A7IE9uZSBleHRyYSBkZXRh aWwgaXMgdGhhdCBpZiB0d28gdXBkYXRlcyBib3RoIGFmZmVjdCBhIG5vZGUsIHlvdSBjaG9vc2Ug b25lIHVwZGF0ZSB0byB3aW4gYW5kIHNldCB0aGUgbmV3IHNlY3JldCB0byBiZSB3aGF0IGl0IHdv dWxkIGhhdmUgYmVlbiBnaXZlbiB0aGF0IHVwZGF0ZSBhbG9uZSwgaW5zdGVhZCBvZiBkb2luZyBE SCBvbiBib3RoIG5ldyBjaGlsZHJlbi48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PiZndDtUaGUgaHVuY2ggaXMgdGhhdCBUcmVlS0VNIGlzIHJvdWdobHkgYW4gb3JkZXIgb2Yg bWFnbml0dWRlIGZhc3RlciBmb3IgYXZlcmFnZSBvcGVyYXRpb25zIGluIE1MUy48L2Rpdj4NCjxk aXY+WWVzLCB0aGF0IHNlZW1zIGxpa2UgYSBnb29kIGFyZ3VtZW50IGFnYWluc3QgaXQuJm5ic3A7 IEluIHByaW5jaXBsZSB3ZSBoYXZlIGEgdHJhZGVvZmYgYmV0d2VlbiBiYW5kd2lkdGggYW5kIENQ VSBjb3N0LCBidXQgaW4gcHJhY3RpY2UgdGhlIGJhbmR3aWR0aCBjb3N0IGlzIHNtYWxsIChwZXJo YXBzIDEgS0IvdXBkYXRlPykgd2hpbGUgdGhpcyBDUFUgY29zdCBpcyBsYXJnZSwgdW5sZXNzIHdl IGFyZSBpbiBhbiB1bnVzdWFsbHkgbmV0d29yay1jb25zdHJhaW5lZA0KIGVudmlyb25tZW50Ljxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QmVzdCw8L2Rpdj4NCjxkaXY+TWF0 dGhldzxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUdWUsIEZlYiAy NiwgMjAxOSBhdCA5OjAxIEFNIFJhcGhhZWwgUm9iZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86cmFw aGFlbEB3aXJlLmNvbSI+cmFwaGFlbEB3aXJlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsiPkhpIE1h dHRoZXcsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PbmUgb2YgdGhlIGNvbnZpbmNpbmcgcmVh c29ucyB3ZSBzYXcgd2hlbiBsb29raW5nIGludG8gQVJUIHZzLiBUcmVlS0VNIHdhcyB0aGF0IHRo ZSByZWNpcGllbnQgb2YgaGFuZHNoYWtlIG1lc3NhZ2VzIGNhbiBwcm9jZXNzIHRoZW0gd2l0aCBP KDEpIERIIG9wZXJhdGlvbnMgd2l0aCBUcmVlS0VNIGFzIG9wcG9zZWQgdG8gTyhsb2cgbikgd2l0 aCBBUlQuIFRoaXMgc291bmRzIGxpa2UgYSBzbWFsbCBkaWZmZXJlbmNlIGF0IGZpcnN0LCBidXQN CiB3ZSBiZWxpZXZlIHRoYXQgaXQgbWFrZXMgYSBiaWcgZGlmZmVyZW5jZSBpbiByZWFsIGxpZmUg c2NlbmFyaW9zLiBDbGllbnRzIHdpbGwgbW9zdGx5IHByb2Nlc3MgaGFuZHNoYWtlIG1lc3NhZ2Vz IChwYXJ0aWN1bGFybHkgaW4gbGFyZ2UgZHluYW1pYyBncm91cHMpLCBidXQgb25seSByYXJlbHkg c2VuZCB0aGVtLiBUaGUgaHVuY2ggaXMgdGhhdCBUcmVlS0VNIGlzIHJvdWdobHkgYW4gb3JkZXIg b2YgbWFnbml0dWRlIGZhc3RlciBmb3IgYXZlcmFnZQ0KIG9wZXJhdGlvbnMgaW4gTUxTLjwvZGl2 Pg0KPGRpdj5JZiB3ZSBnbyBiYWNrIHRvIE8obG9nIG4pIERIIG9wZXJhdGlvbnMgdG8gZGVyaXZl IHRoZSByb290IHNlY3JldCB3ZSB3b3VsZCBsb3NlIHRoZSBzcGVlZCBhZHZhbnRhZ2UuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SYXBoYWVsPGJyPg0KPGRpdj48YnI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+T24gMjUgRmViIDIwMTksIGF0IDIzOjA3LCBSaWNoYXJk IEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRhcmdldD0iX2JsYW5rIj5y bGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9ImdtYWlsLW1fLTg3ODE0 MzYxMDA4NjEzNzk3MDhBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj4NCjxkaXY+SGkgTWF0dGhldyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlRoYW5rcyBmb3IgdGhlIHRob3VnaHRzLiZuYnNwOyBXb3VsZCBpdCBiZSBhY2N1cmF0ZSB0byBz dW1tYXJpemUgeW91ciBwcm9wb3NhbCBhcyBhICZxdW90O2h5YnJpZCBtb2RlJnF1b3Q7LCB3aGVy ZSB3aGVuIHlvdSB1cGRhdGU6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIElmIGJv dGggb2YgYSBub2RlJ3MgY2hpbGRyZW4gYXJlIHBvcHVsYXRlZCwgdGhlbiB5b3UgZG8gYW4gJnF1 b3Q7QVJUIHN0ZXAmcXVvdDssIGdlbmVyYXRpbmcgdGhlIHBhcmVudCBmcm9tIHRoZSBjaGlsZHJl bjwvZGl2Pg0KPGRpdj4tIE90aGVyd2lzZSwgeW91IGRvIGEgJnF1b3Q7VHJlZUtFTSBzdGVwJnF1 b3Q7LCBlbmNyeXB0aW5nIHRoZSBuZXh0IHNlY3JldCB0byB0aGUgcmVzb2x1dGlvbiBvZiB0aGUg b3RoZXIgY2hpbGQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PihSZW1vdmUgaXMgcHJv YmFibHkgc2ltaWxhcjsgZm9yIEFkZCB0aGVyZSdzIG5vIGNoYW5nZSBuZWVkZWQuKTwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXNzdW1pbmcgdGhhdCdzIHJpZ2h0LCB0aGlzIGhvbmVz dGx5IGRvZXNuJ3Qgc291bmQgbGlrZSBhIHRyZW1lbmRvdXNseSBjb21wZWxsaW5nIHByb3Bvc2l0 aW9uIHRvIG1lLiZuYnNwOyBZb3VyIGV2YWx1YXRpb24gb24gdGhlIG92ZXJoZWFkIHNlZW1zIG1v c3RseSBjb3JyZWN0LCBidXQgdGhlcmUgaGF2ZSBhbHJlYWR5IGJlZW4gc29tZSBjb21wbGFpbnRz IG9uIHRoZSBsaXN0IGFib3V0IGhhc2hpbmcgb3ZlcmhlYWQsIHNvIEknbSBub3Qgc3VyZQ0KIHRy YWRpbmcgREgmIzQzO3NtYWxsZXJfbWVzc2FnZXMgZm9yIGhhc2hpbmcgaXMgZ29pbmcgdG8gc3Vp dC4mbmJzcDsgSSdtIGFsc28gd29ycmllZCB0aGF0IHRoaXMgaHlicmlkaXphdGlvbiB3aWxsIGlu dHJvZHVjZSBhIGJ1bmNoIG9mIG5ldyBjb21wbGV4aXR5IGludG8gdGhlIHByb3RvY29sIGFuZCBt YWtlIGl0IGhhcmRlciB0byBpbXBsZW1lbnQgYW5kIGFuYWx5emUuJm5ic3A7IE9wZW4gdG8gYXJn dW1lbnRzIGlmIG90aGVyIGZvbGtzIGFyZSBlbnRodXNpYXN0aWMsDQogdGhvdWdoLjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LS1SaWNoYXJkPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSJnbWFpbF9hdHRyIj5PbiBNb24sIEZlYiAyNSwgMjAxOSBhdCA0OjM3IFBNIE0uQS5MLiBXZWlk bmVyICZsdDs8YSBocmVmPSJtYWlsdG86bWFsdzJAY2FtLmFjLnVrIiB0YXJnZXQ9Il9ibGFuayI+ bWFsdzJAY2FtLmFjLnVrPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVy LWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkdyZWF0aW5ncyBNTFMgV29ya2luZyBHcm91cCE8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgaGF2ZSBiZWVuIHN0dWR5aW5nIHRoZSBwcm9w b3NhbHMgZm9yIFRyZWVLRU0sIGFuZCBlYXJsaWVyLCBBUlQsIGFuZCBub3RpY2VkIGEgd2F5IHRv IHVzZSBBUlQncyBESCB0cmVlIGlkZWFzIGluIFRyZWVLRU0sIHdpdGhvdXQgc2FjcmlmaWNpbmcg dGhlIGFiaWxpdHkgdG8gbWVyZ2UgdXBkYXRlcyBvciB1c2UgYmxhbmsgbm9kZXMuJm5ic3A7IE15 IGFwb2xvZ2llcyBpZiB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUgb3IgaWYgdGhlcmUN CiBhcmUgYW55IG1pc3Rha2VzLjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ TXkgbWFpbiBtb3RpdmF0aW9uIGhlcmUgaXMgdG8gcmVkdWNlIHRoZSBzaXplIG9mIHVwZGF0ZSBt ZXNzYWdlcywgc2luY2UgdGhlIGtleSBlbmNyeXB0ZWQga2V5cyBpbiBhZGRpdGlvbiB0byBuZXcg cHVibGljIGtleXMgbWVhbnMgdGhhdCB0aGV5IGFyZSB+MnggYXMgbGFyZ2UgaW4gVHJlZUtFTSBh cyBpbiBBUlQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CYXNpY2FsbHksIHdlIHVz ZSBUcmVlS0VNLCBidXQgd2l0aCBBUlQncyBrZXkgZGVyaXZhdGlvbiAmcXVvdDthcyZxdW90OyBI KFgpLiZuYnNwOyBUaGF0IGlzLCB3aGVuIGEgbm9kZSBDMSBnZXRzIHRoZSBuZXcgc2VjcmV0IFgs IGluc3RlYWQgb2YgSChYKSwgaXRzIHBhcmVudCBnZXRzIHRoZSBuZXcgc2VjcmV0PGJyPg0KPGJy Pg0KSDIoREgoWCwgcHJpdihDMikpKSA9IEgyKHB1YihDMikgXiBYKSA9IEgyKHB1YihYKSBeIHBy aXYoQzIpKTxicj4NCjxicj4NCndoZXJlIEMyIGlzIHRoZSBuZWlnaGJvciBvZiBDMSwgZm9yIHNv bWUgaGFzaCBmdW5jdGlvbiBIMi4mbmJzcDsgU2luY2UgVHJlZUtFTSBpcyBhZ25vc3RpYyBhYm91 dCBILCB3ZSBjYW4gJnF1b3Q7ZGVmaW5lJnF1b3Q7PGJyPg0KPGJyPg0KSChYKSA6PSBIMihESChY LCBwcml2KEMyKSkpPGJyPg0KPGJyPg0KaW4gdGhpcyB3YXkgd2l0aG91dCBpc3N1ZSwgbm90aW5n IHRoYXQgdGhlIG9ubHkgdXNlcnMgd2hvIHdpbGwgaGF2ZSB0byBjb21wdXRlIEgyKERIKFgsIHBy aXYoQzIpKSkgYXJlIGRlc2NlbmRhbnRzIG9mIEMxICh3aG8ga25vdyBYKSBvciBDMiAod2hvIGtu b3cgcHJpdihDMikpLjxicj4NCjxicj4NCldlIGNhbiBtZXJnZSB1cGRhdGVzIGFzIHdpdGggJnF1 b3Q7cHVyZSZxdW90OyBUcmVlS0VNLCBjaG9vc2luZyBvbmUgdXBkYXRlIHRvIGRvbWluYXRlIGF0 IG5vZGVzIHdoZXJlIHRoZXkgY29uZmxpY3QuJm5ic3A7IFRoaXMgd2lsbCBjYXVzZSB0aGUgdHJl ZSB0byBjZWFzZSBiZWluZyBhIERIIHRyZWUsIHdoaWNoIGlzIGZpbmUuJm5ic3A7IE5vdGUgdGhh dCBkZXNjZW5kYW50cyBvZiBDMiB3aWxsIGhhdmUgdG8ga2VlcCBhcm91bmQgcHJpdihDMikgZm9y IGEgc2hvcnQgdGltZSBhZnRlcg0KIGl0IGlzIG92ZXJ3cml0dGVuIGluIGNhc2Ugb2Ygc2ltdWx0 YW5lb3VzIHVwZGF0ZXMgKHNvIHRoYXQgdGhleSBjYW4gY29tcHV0ZSB0aGUgcGFyZW50IHNlY3Jl dCksIGJ1dCB0aGF0IGlzIHRydWUgZm9yIFRyZWVLRU0gYW55d2F5LCBzaW5jZSBhbnkgc2ltdWx0 YW5lb3VzIHVwZGF0ZSB3aWxsIHNlbmQgZGF0YSBlbmNyeXB0ZWQgdW5kZXIgcHViKEMyKS48YnI+ DQo8YnI+DQpCbGFuayBub2RlcyBjYW4gYmUgaGFuZGxlZCBieSByZXZlcnRpbmcgdG8gcHVyZSBU cmVlS0VNOiBpZiBhIG5vZGUgd2l0aCBuZXcgc2VjcmV0IFggaGFzIGEgYmxhbmsgbmVpZ2hib3Is IHNldCB0aGUgcGFyZW50J3Mgc2VjcmV0IHRvIEgoWCkgYW5kIHNlbmQgdGhhdCBzZXBhcmF0ZWx5 IHRvIGV2ZXJ5IHB1YmxpYyBrZXkgaW4gdGhlIHJlc29sdXRpb24uPGJyPg0KPGJyPg0KTm93IGlu c3RlYWQgb2YgaW5jbHVkaW5nPGJyPg0KPGJyPg0KcHViKFgpLCBFbmMocHViKEMyKSwgSChYKSk8 YnI+DQo8YnI+DQppbiB0aGUgUmF0Y2hldE5vZGUgc3RydWN0IGZvciBub2RlIEMyLCB3ZSBuZWVk IG1lcmVseSBpbmNsdWRlIHB1YihYKSwgc2F2aW5nIGJhbmR3aWR0aC48YnI+DQo8YnI+DQpQcm9z Ojxicj4NCiZuYnNwOyAtIHJlZHVjZXMgdGhlIHVwZGF0ZSBtZXNzYWdlIHNpemUgYnkgYWJvdXQg NTAlIGluIHRoZSB0eXBpY2FsIGNhc2UgKEkgdGhpbmspLjxicj4NCiZuYnNwOyAtIHdlIGNhbiBi dWlsZCBhIHRlcm5hcnkgdHJlZSB1c2luZyAzLXBhcnR5IEpvdXggREggKGFzIHdpdGggQVJUKSwg Z2l2aW5nIGEgZnVydGhlciBsb2dfMygyKSB+IDAuNjMgc2NhbGluZyBvbiB1cGRhdGUgbWVzc2Fn ZSBzaXplLiZuYnNwOyAoSSB0aGluayBpdCdzIHBvc3NpYmxlIHRvIGRvIHRoaXMgd2l0aCBwdXJl IFRyZWVLRU0gYXMgd2VsbCwgYnkgcmVwbGFjaW5nIHRoZSBlcGhlbWVyYWwgREggZXhjaGFuZ2Ug d2l0aCBhIEpvdXggREggd2hlbiBkb2luZw0KIGFzeW1tZXRyaWMgZW5jcnlwdGlvbi4pPGJyPg0K PGJyPg0KQ29uczo8YnI+DQombmJzcDsgLSBmb3JjZWQgdG8gdXNlIGEgREggc3R5bGUgY3J5cHRv c3lzdGVtIChiYWQgZm9yIHBvc3QtcXVhbnR1bT8pIChhcyB3aXRoIEFSVCkuPGJyPg0KJm5ic3A7 IC0gbmVlZCBsb2coTikgREggb3BlcmF0aW9ucyB0byBjb21wdXRlIHRoZSBuZXcga2V5LCBpbnN0 ZWFkIG9mIGxvZyhOKSBoYXNoZXMgKGFzIHdpdGggQVJUKS4mbmJzcDsgU28gdGhpcyBpcyBhIGJh ZCBkZWFsIGlmIENQVSBjeWNsZXMgYXJlIG1vcmUgZXhwZW5zaXZlIHRoYW4gYmFuZHdpZHRoLjxi cj4NCiZuYnNwOyAtIGNhbiBhbHNvIHJlZHVjZSBiYW5kd2lkdGggYnkgMiBqdXN0IGJ5IHJhdGNo ZXRpbmcgaGFsZiBhcyBvZnRlbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgaG9w ZSB5b3UgbWF5IGZpbmQgdGhpcyBpbnRlcmVzdGluZy48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkJlc3QsPC9kaXY+DQo8ZGl2Pk1hdHRoZXcgV2VpZG5lcjwvZGl2Pg0KPGRp dj5NUGhpbCBzdHVkZW50LCBVbml2ZXJzaXR5IG9mIENhbWJyaWRnZTwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KTUxTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpNTFNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5NTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9hPjxicj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpNTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Ok1MU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21scyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9hPjxicj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CADSARUuAiWt0b8A7XcAPMA08GE3RmW0M9zzqrScdrh4Rp4AXQmailg_-- From nobody Wed Feb 27 07:09:39 2019 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 EBD4E131007 for ; Wed, 27 Feb 2019 07:09:32 -0800 (PST) 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, 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=autonomia.digital 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 kqehg8PPwVXL for ; Wed, 27 Feb 2019 07:09:29 -0800 (PST) Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A388130FCF for ; Wed, 27 Feb 2019 07:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=autonomia.digital; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mail; bh=dBGFQYbina4cf+5lsh9ovLkEIe nYtEDebGScTyZv+l4=; b=nNObIMQb63wHoRjQR9l84NyliKUN0IM9GR5adtbC5H yzw59n92r0t2rzSMZWqLuZTFDq2XFONZ4IWCQtnV1hl5Oz2kvOfDKcN2OH2bKnXw 0f13Vb667y4lENN6cXLv6bNAF+sGfpBgiE2c45sqjoD9E5eeN/r0OjDESPkYxg/D 0= Received: (qmail 58409 invoked by uid 0); 27 Feb 2019 15:00:26 -0000 Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 27 Feb 2019 15:00:26 -0000 Date: Wed, 27 Feb 2019 10:09:13 -0500 From: Sofia To: Sean Turner Cc: mls@ietf.org Message-ID: <20190227150912.GB1071@Sofias-MacBook-Pro.local> References: <50BCD9AE-0D30-4587-9453-5AA4E9573003@sn3rd.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: <50BCD9AE-0D30-4587-9453-5AA4E9573003@sn3rd.com> User-Agent: Whatever/1.0 Archived-At: Subject: Re: [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: Wed, 27 Feb 2019 15:09:35 -0000 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, MLS WG, > We're also soliciting agenda requests for the meeting. There are two sess= ions, Tuesday (2hr) and Thursday (1h) so let us know if you have a preferen= ce. We will be accepting remote presentations. I was wondering that, as some threads around deniability have been open, if= there will be an interest in showing what deniability looks like in a group setti= ng. Let me know. Thanks! -- Sof=EDa Celi (aka cherenkov) @claucece / @cherenkov_d Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F --9zSXsLTf0vkW971A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE73QaX1aS5W8U9iQ8OZJhRPidmW8FAlx2qBMACgkQOZJhRPid mW+oEA/+LubiBxr6O+YvW9DDOvShvLBq+RGFn5ljvgGyADcPPtkZon3Ib1rYeDhM 61C/GRvrkqDGCXe7uxlCz4FPHSeCj2oGs+WzL6JgTMndgsFS8xYylKcSE2iUwxhT Yeh8c+0IY7mkGSofkaxIIZBV+eKKmE2+NakvhYNQxbTUPKQDYI3cT+Fo4kal4d3s Xzfxc9LBtuo0Qkip758eRNieQ2JgwqHDAcWe63qwsj8UIOOmBN4zpOremthw23FL XnUfbuvMMoEZKjTRLmPbzUmkg2DpiGGomyf8/8334X18hrnu9sM/TBWe1IWwgt/T n8BYJ2kzoqHkhowf5vvg39ufJjZUKTZMs3H+92oX6BT7r/SEOESbS2ji57Y51zr5 TKrEpqFeIsGdXaqu67ZygrNibZR2zyc2EaLpkLHFTvocHqtKsYQcLKeY73TYD6qc 1Ji+j7mcZnxmoMrfHJejJOd4efgalJPf0cZVFr18ZRTk3PQ8GEyKytGnjysyXQOJ /C2rNyhmfQNOggMPox9c9wWUzc2CJLtQ/uvW51YX+vmi47MHedEgWXjB2H8s1VXO fvbggB/HZotNaTF4XJQljKV8Z0RRVU6SzDqlxQ99vu79k9xWWd2FQ0QkAscqHbb8 WMUcSbskeKrN1LS6I21xyVt7C8l8VPbBXPGV0sUTucsesdl9oZk= =9WfI -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A--