From nobody Thu Aug 2 17:49:11 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999BF130DE3 for ; Thu, 2 Aug 2018 17:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BOsadKDK9rt for ; Thu, 2 Aug 2018 17:49:08 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DCD130E51 for ; Thu, 2 Aug 2018 17:49:07 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id m11-v6so6971622oic.2 for ; Thu, 02 Aug 2018 17:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=4LSfJFpbD5zn/q7XYiUTMsHmt4juwy94ccLUEgTV4Us=; b=tt8OJBp/uMRUeU2cautp94G6Otm4zW33ihFjPleIMoohcUttTMW5oEP3XS2cF7H9RL uvnJVoQfABrFMB4nArkGcv6Xr2lEUgA2rMYZxC55fm5nAyF4AQIyRiX2vhgYUcJ71NhY mSZPXZcCHOBzKzhb3NfU5LkEL8M38nPrbEUr0= 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=4LSfJFpbD5zn/q7XYiUTMsHmt4juwy94ccLUEgTV4Us=; b=nmT5MtJCZISSW6Z8+ajKn8FyQ/OkMedFx1cGBWk1fEjo4Xaqnwl5eL/5xhT2Wcbvmw Y0Gz8brZhkzghz/fqmYOmTd2aPIxCd59PGAjFxyaTEKQM5WiV3yT9gZhoJ0J0lyXOEtb YGNQXxoomNnj6bAttCUE6rNX1JfuScfYOwZuuNSDFngHGVf/627HVMw050nV0xiDnApa fgGxARAau8uBXXd+ryEJzNXcdvxNGvtdgPedWAKW9ODBRFXSVpmn+k2Qqb7hE9MN2TPA z1Kei6+cf5/UAqNv7sAArPBKVfciViBhV18FyQlw2MYKhIxISeUvkqC+l9j2Xc60MZca xBsA== X-Gm-Message-State: AOUpUlHKnisye5Pg/7S72R/vS2LjWz91acnCnR0Wnr27+sxd2toJKhHS EXp0rTMGO5bCivlCC3H1zXnIKhYs8Kb0noira7s3fmerErk= X-Google-Smtp-Source: AAOMgpcRSoQsdw2loztbwhyifVziq/918yJqNeQy6Wq3jWGe2dhpakwQqkuB0WHwB4yzmaGgk27eeIMfNYY5xLmQj3I= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr1032257oib.155.1533257346709; Thu, 02 Aug 2018 17:49:06 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Thu, 2 Aug 2018 17:48:55 -0700 Message-ID: To: "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000801aa905727d4b80" Archived-At: Subject: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 00:49:10 -0000 --000000000000801aa905727d4b80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MLS WG, As we announced in Montreal, we are planning on holding an interim for MLS before the next IETF meeting. In order to make the most effective use of everyone=E2=80=99s time, we attempted to find a time that would work for th= e authors of the majority of the documents up for adoption. We also want to optimize for accessibility so that we make sure there are enough people to be productive. With these things in consideration, we propose the following date and time: September 27-28 (Thursday and Friday) Paris, France Host: TBD Please indicate if you would plan on attending an interim on these dates. If this date and location are not suitable and you planned to come, please indicate your expected level of participation in the interim in your response. Sean & Nick --000000000000801aa905727d4b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
MLS WG,

As we announced in M= ontreal, we are planning on holding an interim for MLS before the next IETF= meeting. In order to make the most effective use of everyone=E2=80=99s tim= e, we attempted to find a time that would work for the authors of the major= ity of the documents up for adoption. We also want to optimize for accessib= ility so that we make sure there are enough people to be productive.
<= div>
With these things in consideration, we propose the follo= wing date and time:
September 27-28 (Thursday and Friday)
Paris, France
Host: TBD

Please indica= te if you would plan on attending an interim on these dates. If this date a= nd location are not suitable and you planned to come, please indicate your = expected level of participation in the interim in your response.
=
Sean & Nick

--000000000000801aa905727d4b80-- From nobody Fri Aug 3 09:10:21 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FBF131006 for ; Fri, 3 Aug 2018 09:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5Ac7AaIGlbdt for ; Fri, 3 Aug 2018 09:10:16 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 9FB7D130EC2 for ; Fri, 3 Aug 2018 09:10:16 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id q11-v6so10674107oic.12 for ; Fri, 03 Aug 2018 09:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=brrNjPu83oWyWd4VtAFC2BBMx1kQ7gu8vW4dB/P9zXE=; b=KfAvw4fo+jGDgDdI+IJsWcorgPSfK3/D/pYwhn29GbB7sbOKQoLe7awsJ1yZcYRU83 7trB1vuqwTwjnrOvJBCN0sAp74aQd3Yb45d3IlRUSm0FCIfNN0O92/43oz57gjykWUP9 Id1360Z9pMsNYvr0/YADW0QtcJtPrTsvSpWnVFt2NZaavpEZqCK5pDM53LPAMpwjfpCO mz6RhxB9AdFRDGBkGRHJ8owaa5R2F8+F7enw5fd5kCwpw6mAnvYNmxwj1zop2b6FroKn Z9FxJPchdoLpa4jLbMBOqzom5JVTrBukd+cTX6oes1Av9yBMYEfMN/VnfRtR6YybJeI2 yRHQ== 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=brrNjPu83oWyWd4VtAFC2BBMx1kQ7gu8vW4dB/P9zXE=; b=KVEZkRUrInXYrIAfGXs1ZewGfEl1YtSvm+Syp3hDaZ5Gx4wde43+kT0+cngiIh2ljk l1Hdhjl/t7XQ6G5MDE2EREcLGBCm+4k3YpM1I8rbhSlnaCeGqJehK8EVZVAI9EcniAVP sd7sBTk5qvkBJzLG26cVIMX3QoF28d0n/37QLGNhxOjPTjVaKCNs2iNl8jyblEQHLT7a Mj7rv+ThCUrhyeHo/sLwAA0kCCIT7UkOAwIemxQUd63EYUoS8I3mfcuHzxL9K7tC8m0U 6faDOHL/N8BFM8Bt+Rla+mA61yOwvukuf1bOwy6QdM6+Zv56vxzdiMkEBovYqAMN5Mtr YGlQ== X-Gm-Message-State: AOUpUlEjFuQSZtKyaFDvZOoOPz51fA3102CZdKCUQdce5g2y7oU6PSdS d7Ez6BZlZy9TtLKBTPAIWk3jXivUkZ8qvLOaTgU8SiAE X-Google-Smtp-Source: AAOMgpf8GysFJITM0xY08PLxNTTy5c8zhHQC+jAtczINtHQMFEMSeKnRxKsGP+UtCl7YfBciYFfHyoTD24lVSxSGmhs= X-Received: by 2002:aca:f383:: with SMTP id r125-v6mr3670630oih.6.1533312615654; Fri, 03 Aug 2018 09:10:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 3 Aug 2018 12:10:03 -0400 Message-ID: To: nick=40cloudflare.com@dmarc.ietf.org Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000c93a2605728a29c5" Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 16:10:20 -0000 --000000000000c93a2605728a29c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Those dates/location should work fine for me. I will plan on being there. --Richard On Thu, Aug 2, 2018 at 8:49 PM Nick Sullivan wrote: > MLS WG, > > As we announced in Montreal, we are planning on holding an interim for ML= S > before the next IETF meeting. In order to make the most effective use of > everyone=E2=80=99s time, we attempted to find a time that would work for = the > authors of the majority of the documents up for adoption. We also want to > optimize for accessibility so that we make sure there are enough people t= o > be productive. > > With these things in consideration, we propose the following date and tim= e: > September 27-28 (Thursday and Friday) > Paris, France > Host: TBD > > Please indicate if you would plan on attending an interim on these dates. > If this date and location are not suitable and you planned to come, pleas= e > indicate your expected level of participation in the interim in your > response. > > Sean & Nick > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000c93a2605728a29c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Those dates/location should work fine for me.=C2=A0 I= will plan on being there.

--Richard
=

On Thu, Aug 2, 20= 18 at 8:49 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
MLS WG,

As we announced in Montreal, we are planning on holding an interim f= or MLS before the next IETF meeting. In order to make the most effective us= e of everyone=E2=80=99s time, we attempted to find a time that would work f= or the authors of the majority of the documents up for adoption. We also wa= nt to optimize for accessibility so that we make sure there are enough peop= le to be productive.

With these things in consider= ation, we propose the following date and time:
September 27-28 (T= hursday and Friday)
Paris, France
Host: TBD
<= br>
Please indicate if you would plan on attending an interim on = these dates. If this date and location are not suitable and you planned to = come, please indicate your expected level of participation in the interim i= n your response.

Sean & Nick

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000c93a2605728a29c5-- From nobody Fri Aug 3 09:45:01 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA65130F18 for ; Fri, 3 Aug 2018 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 rMXzLlloPw1q for ; Fri, 3 Aug 2018 09:44:57 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A631A130EC4 for ; Fri, 3 Aug 2018 09:44:56 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id s12-v6so5469869ljj.0 for ; Fri, 03 Aug 2018 09:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8doxYsYrXt2b8d7onpcHX9ro9F+TocIrGiYARpGKJQ4=; b=g4+x8sLWqtV3vJMOUwgzMIwXAFpCgxNqMtQmmBOSuqmgtkKFTfJaYAxq1QgCEXyI7/ GhrAKdG/xzd4kvWljx7MKHO8NTVoop99JjFluC35ThrchOv3lsDD+ssggb94g84rsQj0 gRAsGTPi0su4/Nwu09KOJwD+7wG2y+PowytoX5g4kkRt38H5Z5KFwktK+ffeM9Ob6Dzu JElSX+SFf1pJ9tEYwKxPV0m/D+Qfm6s2Wb81RP10V4QUFGv4a4NVwcDv2dSUgeWT+RRm 1JiYHt94ipJ4Net/EACc0mwdZQ6VX6By6K4owcSPgy3AjWLcKfRjL1ECpkcs5dncLAjF EMzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8doxYsYrXt2b8d7onpcHX9ro9F+TocIrGiYARpGKJQ4=; b=aJLfVjztPhq78tCmBmaAp/CMEp6qCUDnftuDUA2VE6Kwyoz5oSf/cSHUv+UTlApfyb s6m4hdgrtJmcmkxFw1WF5UpcYSgdSiQpSV1NR2aEpMWJc5ivhJ7nadHP0HL/eXHXlu/f 6nSIhfXYgDLsNb8m/lAHhXtjtdLcLkRk0sp4Zp55uxqLnB9m/tdAwxNAyLw7SVFUfuDZ 9HqhWQ96S5jBO12pvXYMun0gDxHD+dILscPSpQyfO4/AZ5vn0mmfsX33XYnbkBiOgVPf ckCHaMp5Byk38HKIhINPd2EHzcFWZbv1gGP7q5mZ05xsK67xPLJyt6PD/phAVzjUH8Fj n1yw== X-Gm-Message-State: AOUpUlEjLi3/t3pU+0qs4b+cML6qu8g1iFPM1viztCgIHi0/aLxOfU8E wzKEwOBuLDJSTXE21WkQnizYwagjrnKh/5U/FwSKHw== X-Google-Smtp-Source: AAOMgpdc2d+XEDdKdK2bu7CpOd8u6QF2sywFsay/tPv9HrPAvBArttwVMgMQI87A6pLeegRyjA3VuUrW9HkNM6e5SMk= X-Received: by 2002:a2e:1b83:: with SMTP id c3-v6mr5884191ljf.0.1533314694900; Fri, 03 Aug 2018 09:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 09:44:13 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 3 Aug 2018 09:44:13 -0700 Message-ID: To: Richard Barnes Cc: nick=40cloudflare.com@dmarc.ietf.org, mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000b801fc05728aa5e9" Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 16:44:59 -0000 --000000000000b801fc05728aa5e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Fri, Aug 3, 2018 at 9:10 AM, Richard Barnes wrote: > Those dates/location should work fine for me. I will plan on being there= . > > --Richard > > > On Thu, Aug 2, 2018 at 8:49 PM Nick Sullivan ietf.org> wrote: > >> MLS WG, >> >> As we announced in Montreal, we are planning on holding an interim for >> MLS before the next IETF meeting. In order to make the most effective us= e >> of everyone=E2=80=99s time, we attempted to find a time that would work = for the >> authors of the majority of the documents up for adoption. We also want t= o >> optimize for accessibility so that we make sure there are enough people = to >> be productive. >> >> With these things in consideration, we propose the following date and >> time: >> September 27-28 (Thursday and Friday) >> Paris, France >> Host: TBD >> >> Please indicate if you would plan on attending an interim on these dates= . >> If this date and location are not suitable and you planned to come, plea= se >> indicate your expected level of participation in the interim in your >> response. >> >> Sean & Nick >> >> _______________________________________________ >> 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 > > --000000000000b801fc05728aa5e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1


On Fri, Aug 3, 2018 at 9:10 AM, Richard B= arnes <rlb@ipv.sx> wrote:
Those dates/location should work fine for me.=C2=A0 I will p= lan on being there.

--Richard


O= n Thu, Aug 2, 2018 at 8:49 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
MLS WG,

As we announced in Montreal, we are planning on holding an interim fo= r MLS before the next IETF meeting. In order to make the most effective use= of everyone=E2=80=99s time, we attempted to find a time that would work fo= r the authors of the majority of the documents up for adoption. We also wan= t to optimize for accessibility so that we make sure there are enough peopl= e to be productive.

With these things in considera= tion, we propose the following date and time:
September 27-28 (Th= ursday and Friday)
Paris, France
Host: TBD
Please indicate if you would plan on attending an interim on t= hese dates. If this date and location are not suitable and you planned to c= ome, please indicate your expected level of participation in the interim in= your response.

Sean & Nick

_______________________________________________
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


--000000000000b801fc05728aa5e9-- From nobody Fri Aug 3 09:54:49 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEDA131006 for ; Fri, 3 Aug 2018 09:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 AOV2vqtCtbCZ for ; Fri, 3 Aug 2018 09:54:45 -0700 (PDT) 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 01150130F21 for ; Fri, 3 Aug 2018 09:54:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,439,1526335200"; d="asc'?scan'208,217";a="274933322" Received: from corp-nat.fw1.untrust.mtv2.mozilla.net (HELO [10.252.25.87]) ([63.245.221.198]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2018 18:54:42 +0200 From: Benjamin Beurdouche Message-Id: <3FD78BD9-87E9-4D8F-B717-85D8F25007E0@inria.fr> Content-Type: multipart/signed; boundary="Apple-Mail=_D2DA5EF7-6190-4B5C-A29F-7C8042E8101E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 3 Aug 2018 09:54:39 -0700 In-Reply-To: Cc: Richard Barnes , ML Messaging Layer Security To: Nick Sullivan References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 16:54:48 -0000 --Apple-Mail=_D2DA5EF7-6190-4B5C-A29F-7C8042E8101E Content-Type: multipart/alternative; boundary="Apple-Mail=_BAEE1CAD-A31C-4E90-A5B9-5702626AD7BB" --Apple-Mail=_BAEE1CAD-A31C-4E90-A5B9-5702626AD7BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Works for me. I=E2=80=99ll be there too... B. > On Aug 3, 2018, at 9:10 AM, Richard Barnes wrote: >=20 > Those dates/location should work fine for me. I will plan on being = there. >=20 > --Richard >=20 >=20 > On Thu, Aug 2, 2018 at 8:49 PM Nick Sullivan = > wrote: > MLS WG, >=20 > As we announced in Montreal, we are planning on holding an interim for = MLS before the next IETF meeting. In order to make the most effective = use of everyone=E2=80=99s time, we attempted to find a time that would = work for the authors of the majority of the documents up for adoption. = We also want to optimize for accessibility so that we make sure there = are enough people to be productive. >=20 > With these things in consideration, we propose the following date and = time: > September 27-28 (Thursday and Friday) > Paris, France > Host: TBD >=20 > Please indicate if you would plan on attending an interim on these = dates. If this date and location are not suitable and you planned to = come, please indicate your expected level of participation in the = interim in your response. >=20 > Sean & Nick >=20 > _______________________________________________ > 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=_BAEE1CAD-A31C-4E90-A5B9-5702626AD7BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Works= for me. I=E2=80=99ll be there too...
B.

On Aug 3, 2018, at 9:10 AM, Richard Barnes <rlb@ipv.sx> wrote:

Those dates/location should work fine for = me.  I will plan on being there.

--Richard


On Thu, Aug 2, 2018 at = 8:49 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
MLS WG,

As we announced in Montreal, we are = planning on holding an interim for MLS before the next IETF meeting. In = order to make the most effective use of everyone=E2=80=99s time, we = attempted to find a time that would work for the authors of the majority = of the documents up for adoption. We also want to optimize for = accessibility so that we make sure there are enough people to be = productive.

With= these things in consideration, we propose the following date and = time:
September 27-28 (Thursday and = Friday)
Paris, France
Host: = TBD

Please = indicate if you would plan on attending an interim on these dates. If = this date and location are not suitable and you planned to come, please = indicate your expected level of participation in the interim in your = response.

Sean = & Nick

_______________________________________________
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=_BAEE1CAD-A31C-4E90-A5B9-5702626AD7BB-- --Apple-Mail=_D2DA5EF7-6190-4B5C-A29F-7C8042E8101E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEuBxqANrVSPVBPOUAfmABPaR1P1QFAltkiM8ACgkQfmABPaR1 P1TrtA/9HoN9fDNnXliEr1FXAl01TZ/IZhzQglsCtf52ydFqon6nz44aOtjIqrsM uIsazCuZ930sW8lezdyyJpL+K/lwkWAtlhaVeJU1mEKXktNFfK3J2BBqfOAKt9lR aPAyPWo+gwnAeuqjEHCojiCVICq2vv30O0GdRXUUU15edmuNKRQa21dzombVIPAg C3EF50bcDV92+D+hvyiYh7Awlyy+RYryJ4cjZ00wlUkqoshL1Gu2rgRVb5zXI1UV Y+Gn4Yd83JRawbYUlGizyvBKiEhw8PTQ7uWrgUi5hK5jeX0h74dwOxakiJ22OW+6 VXB3kne4vQ6ejkfQ3L4fOsxkd+qw8fumNFiZdKTZPBaufbOUwgdNW15kcdYTFqeH wTadtNc24XuRE30srD8qGMTus/5DL+pf84FkgHs062ZAFdiaQ4XB+BHN/HIxpkmT ziFGgfeni704U56j+RC4BoPe+c4QxnOHiy905NMQK5zU5eBquXRKA8PvJPx6ydvv O/jk/SklTVwkZ40yu6Bkvj85HYSSopbEOFhQKYiGa7rfkQsL+UDBdwO8Flh4L5g2 vFunS4XjDeOMOIrMzyukAByVYlUlR1Y2wbDDD5a5jl3ALKATt6aCbLAK7NumPDy1 EsacB5rtnwjjEddvIwYswJh3qzcDUl+wQjQYIgwZSk6TOhWqLWM= =fR5j -----END PGP SIGNATURE----- --Apple-Mail=_D2DA5EF7-6190-4B5C-A29F-7C8042E8101E-- From nobody Fri Aug 3 09:57:27 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E9313104B for ; Fri, 3 Aug 2018 09:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 PIUt6nAqF_sh for ; Fri, 3 Aug 2018 09:57:23 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 8EC5F13104A for ; Fri, 3 Aug 2018 09:57:23 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id v8-v6so10990412oie.5 for ; Fri, 03 Aug 2018 09:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NpxCaJmIH4oz5hUAGjFbo5qzOKZD5m6X7VnbpiWmb38=; b=C4vNwKNrAjN5vCESBDarphX/lzpKV/IOFUg5l3UVUh6lcLQBB9pYbXBuoHKJyEeU09 jhXU4ewAYeVU3W5+TFw3bynkqbkXlPC2XsWJjLEWIhv5f9xuJkJlwfNJld61zTEV7RuH Bd+n53dtrdFE0aViLnm9D/5jaDs/uhSJk1Zux5soIYT1N9uIGS9XO8IXOP18lTth47u2 pQCa5/LwurNSy/3LM1EBGbepDk2qWmxAEMDQOleAEAhRxVOCsgiG7CR/+gsgJ+SW0yaI R5tCTcNgO6r+FxOCb+czIrCcIfpXkQgRTtQqUtbVdQCVU6B86J7FCb5afTHXALeLUxy3 Wr/Q== 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=NpxCaJmIH4oz5hUAGjFbo5qzOKZD5m6X7VnbpiWmb38=; b=WWRBtv2ixQuj7U/hM2vA9V7zI/WXQ0LCOrEH4CaFplUn5gyByib3p40me3W087G1// dJ6cdEyqzZCpSYDTGkHIqZ3guu8KeUrTMVjmgd7Gw79/I07K8Iu9vUF7tF4AsOOoDLlE SgF4r2haV87zuzmW4Fq4KZwOj91l2zZUi0IGa34r3yzOCLg3AaPkiauSlmjL3RWLX/u3 o+lKp+UXH8z1JLQOZi3DcqBuan7LeBhs4buSlUG6WQDp1OBqMB8VZtKoZJFwtMQEcUjN IJxX+XFLdl1hrO5FS/MUoymDutaNFCZzHcATNU21sHgyUsMjoQAfa4p9JFRdfO8neuD8 9/ww== X-Gm-Message-State: AOUpUlHlSov62hliPUnK7eZdwRbm9PEIjHq2HLCKUdnaAP+KJmISNM2i 10nEBC1fCeC1m16Mncl55bRA0D+gfh/bjjLIYuGliA== X-Google-Smtp-Source: AAOMgpfmwnYORxEyqe/LA9vMubAk9eV/BTDMhXz+TKorAVz5HNaQlJF8K5rSDy2npMI5+WGW2wIcWwCzTIM6gI/n5hM= X-Received: by 2002:aca:4994:: with SMTP id w142-v6mr3760674oia.114.1533315442768; Fri, 03 Aug 2018 09:57:22 -0700 (PDT) MIME-Version: 1.0 References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> <87sh49vk1r.fsf@fifthhorseman.net> In-Reply-To: From: Richard Barnes Date: Fri, 3 Aug 2018 12:57:11 -0400 Message-ID: To: Eric Rescorla Cc: Daniel Kahn Gillmor , mls@ietf.org, Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary="0000000000004b95fa05728ad2dc" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 16:57:27 -0000 --0000000000004b95fa05728ad2dc Content-Type: text/plain; charset="UTF-8" Thinking on this a bit more, it seems like encrypting handshake messages has some important operational implications. Encrypting handshake messages implies that nobody who isn't authorized by a member of the group can authenticate the list of members of the group. Effectively, handshake message encryption kills UserAdd; the only way to become a full member of the group is for someone in the group to add you. On the one hand, I'll grant that this is a nice security property. On the other hand, it complicates things for the new-device case, since the new device can't just join. Arguably, this is not tragic. An external party can always encrypt to the group, as long as it doesn't care about knowing who's in the group. And until someone else transmits, the new device isn't missing anything. So you could do something like the following: - When new device wants to join, it send the group an AddRequest that authenticates the new device and establishes a new key shared between it and the group, without changing the group's state - The next member to transmit MUST process the AddRequest and transmit either a GroupAdd or an AddRequestDenied message With that framework, you could have a similar UX to UserAdd, with the difference that whatever the new joiner sends before the GroupAdd won't have an authenticated list of recipients until the GroupAdd shows up. Once that arrives, however, the sender will be able to verify who received its past messages. (It does seem like it might be desirable to hide the past membership of the group from current members, but even then, you could selectively reveal the last generation.) (It seems like there are some parallels here to DH-based 0xRTT in TLS 1.3, though the exact analogy is escaping me.) In any case, I would be interested in feedback from folks with messaging apps as to whether a scheme like this seems like something that could be implemented with reasonable UX. --Richard On Mon, Jul 23, 2018 at 4:45 PM Eric Rescorla wrote: > n Mon, Jul 23, 2018 at 12:17 PM, Daniel Kahn Gillmor < > dkg@fifthhorseman.net> wrote: > >> On Mon 2018-07-23 08:49:01 -0700, Eric Rescorla wrote: >> > - What's with the hate over "handshake" and "application"? It's the >> same >> > distinction that TLS makes. >> > > Hi DKG, > > You're quoting Barnes here, not me. > > -Ekr > > "handshake" is something that implies a meeting or a conversational >> setup. here, we're talking about ongoing key updates as well as >> membership changes. "handshake" also implies two parties (if there are >> three-party handshake protocols in the real world, i'm unaware of them). >> So for both those reasons, i think it's inappropriate for the MLS >> context. >> >> I've also argued already on this list that MLS should be *distancing* >> itself from TLS, not trying to mimic it. (I don't even think the name >> MLS is appropriate, and i think we should change it to something that >> doesn't sound like TLS) >> >> People that want a secure two-party protocol with well-understood >> security guarantees *should* use TLS, not whatever MLS turns out to be. >> I definitely want us to *discourage* people from using MLS where TLS >> would suit their use case better. >> >> Let's not try to make these protocols too analogous, lest we confuse >> people and encourage people to turn TLS into a multi-party scheme. >> >> --dkg >> > > --0000000000004b95fa05728ad2dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking on this a bit more, it seems like encrypting= handshake messages has some important operational implications.
=
Encrypting handshake messages implies that nobody who isn= 9;t authorized by a member of the group can authenticate the list of member= s of the group.=C2=A0 Effectively, handshake message encryption kills UserA= dd; the only way to become a full member of the group is for someone in the= group to add you.=C2=A0 On the one hand, I'll grant that this is a nic= e security property.=C2=A0 On the other hand, it complicates things for the= new-device case, since the new device can't just join.=C2=A0

Arguably, this is not tragic.=C2=A0 An external party = can always encrypt to the group, as long as it doesn't care about knowi= ng who's in the group.=C2=A0 And until someone else transmits, the new = device isn't missing anything. So you could do something like the follo= wing:

- When new device wants to join, it send the= group an AddRequest that authenticates the new device and establishes a ne= w key shared between it and the group, without changing the group's sta= te
- The next member to transmit MUST process the AddRequest = and transmit either a GroupAdd or an AddRequestDenied message

With that framework, you could have a similar UX to UserAdd= , with the difference that whatever the new joiner sends before the GroupAd= d won't have an authenticated list of recipients until the GroupAdd sho= ws up.=C2=A0 Once that arrives, however, the sender will be able to verify = who received its past messages.=C2=A0 (It does seem like it might be desira= ble to hide the past membership of the group from current members, but even= then, you could selectively reveal the last generation.)
(It seems like there are some parallels here to DH-based 0xRTT = in TLS 1.3, though the exact analogy is escaping me.)

<= div>In any case, I would be interested in feedback from folks with messagin= g apps as to whether a scheme like this seems like something that could be = implemented with reasonable UX.

--Richard


On Mo= n, Jul 23, 2018 at 4:45 PM Eric Rescorla <ekr@rtfm.com> wrote:
n Mon, Jul 23, 2018 at 12:17 PM= , Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
=
On Mon 2018= -07-23 08:49:01 -0700, Eric Rescorla wrote:
> - What's with the hate over "handshake" and "applic= ation"?=C2=A0 It's the same
> distinction that TLS makes.

Hi DKG,

Yo= u're quoting Barnes here, not me.

-Ekr

"handshake" is something that implies a meeting or a conve= rsational
setup.=C2=A0 here, we're talking about ongoing key updates as well as membership changes.=C2=A0 "handshake" also implies two parties (i= f there are
three-party handshake protocols in the real world, i'm unaware of them)= .
So for both those reasons, i think it's inappropriate for the MLS
context.

I've also argued already on this list that MLS should be *distancing* itself from TLS, not trying to mimic it.=C2=A0 (I don't even think the = name
MLS is appropriate, and i think we should change it to something that
doesn't sound like TLS)

People that want a secure two-party protocol with well-understood
security guarantees *should* use TLS, not whatever MLS turns out to be.
I definitely want us to *discourage* people from using MLS where TLS
would suit their use case better.

Let's not try to make these protocols too analogous, lest we confuse people and encourage people to turn TLS into a multi-party scheme.

=C2=A0 =C2=A0 =C2=A0 --dkg

--0000000000004b95fa05728ad2dc-- From nobody Fri Aug 3 11:31:31 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F252B13105D for ; Fri, 3 Aug 2018 11:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HF7lDXVSIzp for ; Fri, 3 Aug 2018 11:31:27 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 04F751292F1 for ; Fri, 3 Aug 2018 11:31:27 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b15-v6so11448075oib.10 for ; Fri, 03 Aug 2018 11:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JGMUQCFO/xvooiFhNcgmvqtYbs9TawPYe0sQxOUL6Sk=; b=r0p6dKALqaEr1WclHP98tg+zWUdjK0Ll50vWV5ZyJFpjEJGN5Y+1vO0FWjbWpmjM2S 2/8tAO0m7OCoSiN1ohWDkC91ZOtpvsvY5RK8oSRzqhVd+q5my6D6ED9cJ1sHgb5kFH5I 2Xfjrd4fjhAgTthPABhkVSBdNk9yL57gnXMRM4IXg/svqWADQyjdUVVA1hENr0qBIH3R piWOZknBGVxPraRlr46LGW95hlLIA9T4dkQDXb3D0pMImbsH5Z/IKG4xBfsm9wcHluyj kYJUg3Qtd+7UJA1WUvIoy1Dm1CloNXjAoH+OFiMksbJAxOfSC83fOnz9aAbP0tsYrv9U foDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JGMUQCFO/xvooiFhNcgmvqtYbs9TawPYe0sQxOUL6Sk=; b=MOjfYpdbOcws9MEf72Dl3ggTybwqDmk2lqBWcskHped5uednfRPEd1x/EIx3tGchRJ uyJ9zhcjdzTKMOSpyKftO3z8T4EVUpCeNMs0uPOOFWH80td7qztWh9YbIqMdh5lhVUdr 4WV+r+JODFI/9Klx6PqBmw77v82NvCVnDH7/nCzZ6uaYwn4OFA5YswawIw1bxZ2t37nx UM1JJPvO/2GovQ2V/uYvlc4c9KvuHxzAbZD8CrhanlnRp9/RjLwsw+UyODqWeszHvGV3 y2/CpvaY5YtzveqAMIoaWyNXSD90FYSx99EwhzJ2iJSVS7ZJvf1P5j/M9IMCKPfbp0zy GNMg== X-Gm-Message-State: AOUpUlGji7wDFmUFIU+GTLQ2XLtx08kSKr8e/MVXg5875Tpe1NXxfT9z K5QYJXV1sjrWxucQfwEBjNGx08eO/YRNunJL8pkk4Q== X-Google-Smtp-Source: AAOMgpch88lqMlC8umuafL1VZuppXTMe5VTaRsj7MtmtNEwiAJYFmMx4sYAUUtrl9WXaXsPkxnnYpV/zUFwE6ixmPkw= X-Received: by 2002:aca:3c45:: with SMTP id j66-v6mr4052757oia.118.1533321086099; Fri, 03 Aug 2018 11:31:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 11:30:55 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Fri, 3 Aug 2018 11:30:55 -0700 Message-ID: To: Nick Sullivan Cc: "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a9e82d05728c2217" Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 18:31:29 -0000 --000000000000a9e82d05728c2217 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nick, Do you plan on making remote participation possible? Ted On Thu, Aug 2, 2018 at 5:48 PM, Nick Sullivan < nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > MLS WG, > > As we announced in Montreal, we are planning on holding an interim for ML= S > before the next IETF meeting. In order to make the most effective use of > everyone=E2=80=99s time, we attempted to find a time that would work for = the > authors of the majority of the documents up for adoption. We also want to > optimize for accessibility so that we make sure there are enough people t= o > be productive. > > With these things in consideration, we propose the following date and tim= e: > September 27-28 (Thursday and Friday) > Paris, France > Host: TBD > > Please indicate if you would plan on attending an interim on these dates. > If this date and location are not suitable and you planned to come, pleas= e > indicate your expected level of participation in the interim in your > response. > > Sean & Nick > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --000000000000a9e82d05728c2217 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nick,

Do you plan on maki= ng remote participation possible?

Ted

On Thu, Aug 2,= 2018 at 5:48 PM, Nick Sullivan <nick=3D40cloudflare.= com@dmarc.ietf.org> wrote:
=
MLS WG,

As we announced in M= ontreal, we are planning on holding an interim for MLS before the next IETF= meeting. In order to make the most effective use of everyone=E2=80=99s tim= e, we attempted to find a time that would work for the authors of the major= ity of the documents up for adoption. We also want to optimize for accessib= ility so that we make sure there are enough people to be productive.
<= div>
With these things in consideration, we propose the follo= wing date and time:
September 27-28 (Thursday and Friday)
Paris, France
Host: TBD

Please indica= te if you would plan on attending an interim on these dates. If this date a= nd location are not suitable and you planned to come, please indicate your = expected level of participation in the interim in your response.
=
Sean & Nick


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


--000000000000a9e82d05728c2217-- From nobody Fri Aug 3 12:13:28 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0902131105 for ; Fri, 3 Aug 2018 12:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=vqFPxgSW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NDptZL3c 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 Fxs8jX54kHHO for ; Fri, 3 Aug 2018 12:13:22 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B35A1310D9 for ; Fri, 3 Aug 2018 12:13:22 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D1DBC21B36 for ; Fri, 3 Aug 2018 15:13:21 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Fri, 03 Aug 2018 15:13:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=jqZhI8RzA3djKEmX+1X3ShXzd/ jXDrgGJfat6xfKxGM=; b=vqFPxgSWhG6SLV0sD0ZbYY8Akv2fVGfhVYsDkcL+hU GYKNwmjhdr9F63jb2vsTqz0qsfFmcHohYPEkIEQsmkpo1mYgEJLwqkGPD0DF+ny/ 17gHlhh30HkeBVfYpLgE9I3Y1ejBsCWYZi+iVgh5Ima+D1lnlzZfjW1x1IEOkKtk 4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=jqZhI8 RzA3djKEmX+1X3ShXzd/jXDrgGJfat6xfKxGM=; b=NDptZL3cr38SRfWaNgds5e 8M82EiW7J5ZXdCcgNoMk9K34xBdJR1h3aMJh3JVvYY5VSJwvwovLu38tsi6KiBUt 38TDR/TWBqld5iXA/ciZe3gb2FFrrkiK5yWemyEolKKyEJ0gFxnYSCaeu3c1YoR0 chlfxbvZvbdkeLZrjyAh8FSRmC4XtR0jA1Gv5eqvz25R/Qf+m509bx0iRdXR+FrA QifjCMFuPoTPKonH1eF6VrfZ6Cmaj2q8QiMzw0dMQL9oHyJX8RHKqvffSScx5vfW IixTTBSu7UhRSqtjy6mWziKjp0bt4/gPIQLe9qGI1bFPVWXiQftTK/tLWmgwL2tw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 74F179E492; Fri, 3 Aug 2018 15:13:21 -0400 (EDT) Message-Id: <1533323601.3545156.1462743400.3F2C68ED@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153332360135451560" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b In-Reply-To: <3FD78BD9-87E9-4D8F-B717-85D8F25007E0@inria.fr> Date: Fri, 03 Aug 2018 20:13:21 +0100 References: <3FD78BD9-87E9-4D8F-B717-85D8F25007E0@inria.fr> Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 19:13:27 -0000 This is a multi-part message in MIME format. --_----------=_153332360135451560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I can be there Thursday, leaving at some point on Friday. k On Fri, 3 Aug 2018, at 5:54 PM, Benjamin Beurdouche wrote: > Works for me. I=E2=80=99ll be there too... > B. >=20 >> On Aug 3, 2018, at 9:10 AM, Richard Barnes wrote: >>=20 >> Those dates/location should work fine for me. I will plan on >> being there.>>=20 >> --Richard >>=20 >>=20 >> On Thu, Aug 2, 2018 at 8:49 PM Nick Sullivan >> wrote:>>> MLS WG, >>>=20 >>> As we announced in Montreal, we are planning on holding an interim >>> for MLS before the next IETF meeting. In order to make the most >>> effective use of everyone=E2=80=99s time, we attempted to find a time t= hat >>> would work for the authors of the majority of the documents up for >>> adoption. We also want to optimize for accessibility so that we make >>> sure there are enough people to be productive.>>>=20 >>> With these things in consideration, we propose the following date >>> and time:>>> September 27-28 (Thursday and Friday) >>> Paris, France >>> Host: TBD >>>=20 >>> Please indicate if you would plan on attending an interim on these >>> dates. If this date and location are not suitable and you planned to >>> come, please indicate your expected level of participation in the >>> interim in your response.>>>=20 >>> Sean & Nick >>>=20 >>> _______________________________________________ >>> 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 > Email had 1 attachment: > * signature.asc 1k (application/pgp-signature) --_----------=_153332360135451560 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I can be there Thursday, l= eaving at some point on Friday.

k

On Fri, 3 Aug 2018, at 5:54 PM, Benjamin Beurdouche wrote:
Works = for me. I=E2=80=99ll be there too...
B.

On Aug 3, 2018, at 9:10 AM, Richard Barnes &= lt;rlb@ipv.sx> wrote:

Those dates/location should work fine for me.&nb= sp; I will plan on being there.

--Richard


On Thu, Aug 2, 2018 at= 8:49 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
MLS WG,

As we announced in Montreal, we are planning on holding an interim for= MLS before the next IETF meeting. In order to make the most effective use = of everyone=E2=80=99s time, we attempted to find a time that would work for= the authors of the majority of the documents up for adoption. We also want= to optimize for accessibility so that we make sure there are enough people= to be productive.

With these things in consideration, we propose the following date and = time:
September 27-28 (Thursday and Friday)
Paris, France
Host: TBD

Please indicate if you would plan on attending an interim on these dat= es. If this date and location are not suitable and you planned to come, ple= ase indicate your expected level of participation in the interim in your re= sponse.

Sean & Nick

________________________________= _______________
MLS mailing list
________________________________= _______________
MLS mailing list
https://www.ietf.org/mailman/lis= tinfo/mls
_______________________________________________
MLS mailing list

Email had 1 attachment:

  • signature.asc
      1k (application/pgp-signa= ture)

--_----------=_153332360135451560-- From nobody Sat Aug 4 11:43:46 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD57130DF1 for ; Sat, 4 Aug 2018 11:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01] 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 NdOtwWFLzY3p for ; Sat, 4 Aug 2018 11:43:41 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 1FAF61274D0 for ; Sat, 4 Aug 2018 11:43:40 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id c13-v6so8463031wrt.1 for ; Sat, 04 Aug 2018 11:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=8Ge1QQZGZO4eUhTCRka3Hr4xXVaiTswgV4HfSbTv00E=; b=iXM3yXBTSeaukJ8t5VYL781Rv5+NwM0F90Fx66KHxqK0dBEuEhKMB6sgiJSrP2nv80 TXVIMUpkilwMpVfwyPqXZXkQ6NnlbH1wzASNpKQ/3/rhCAs/9i12PdYzFcjZK5WQgDee PKs9zdTZmW5iZ2aHKH1XisGFs+TYnShIXiyZuhKJIFJ0Nwv/ubB/1YjdtdEXQQ5cnSbw kX2fQGraN4DPjkqSNZ+SF1YZa9j2Bba8C1t6VXdeE9+CjcIhDmdFLHLMYHMi8c3lmPrE 99PrwRdn5XEC5LtzrOny5TzTNnMbnZRjNARwezqKyLM/spUyQIipijQNmdv6ELNzdV+a eyKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=8Ge1QQZGZO4eUhTCRka3Hr4xXVaiTswgV4HfSbTv00E=; b=Xbw4dl5zS+7lo14doNDZc2eZwXpxWkm1EsepuFxTfqys3//kszVCNBun2IHT+B856Y XDJuw98x1vBL6SgvrY9S5HuU27GK5VElBQvmpR4QmJz+4EOa1LMwEUWSELy6VFCShkzY JnEahilPXNw7bSHDHrSanmhfb/dF79XZUSEAsDIiWKagCoGY2o7j9uhjHC5KR1QSwKks x0fxmvLioF1IvdG1LmhClCucI1RCPajseh4TmOrVS/iCzkWBAqF73SBfhCfHFvoY7TtV Az+SllV8emQTNjGF0C86tkvfn8XkKefMTUCZWITQuQWJe8DGCQDdOYiaruDtQW+WKRzP u1CA== X-Gm-Message-State: AOUpUlHrOWAU+vaZskFfGA2x5jgbpJmpAp5xl/vzM5/vX1SLGBKmQUz9 jbqNzBXby9gY8fCjTOuQMDrPYFK+8fyBfQ== X-Google-Smtp-Source: AAOMgpcbTtyUJMmt3O9Y5rQNCQM42QIUdbn7r5h6Lv/WppbOcZ67AV6tJXz3stJ/8jfypzBqKRnh9Q== X-Received: by 2002:adf:bb08:: with SMTP id r8-v6mr5309402wrg.244.1533408219037; Sat, 04 Aug 2018 11:43:39 -0700 (PDT) Received: from rmbp.fritz.box (HSI-KBW-095-208-247-123.hsi5.kabel-badenwuerttemberg.de. [95.208.247.123]) by smtp.gmail.com with ESMTPSA id v10-v6sm4903802wrm.18.2018.08.04.11.43.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Aug 2018 11:43:38 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_D49309EE-C8E3-47C3-9A0F-B9AB89654CA5" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 4 Aug 2018 20:43:36 +0200 References: <3FD78BD9-87E9-4D8F-B717-85D8F25007E0@inria.fr> <1533323601.3545156.1462743400.3F2C68ED@webmail.messagingengine.com> To: mls@ietf.org In-Reply-To: <1533323601.3545156.1462743400.3F2C68ED@webmail.messagingengine.com> Message-Id: <0F6F2F87-16F1-4ADB-A7AF-0E1B903AA2C1@wire.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 18:43:44 -0000 --Apple-Mail=_D49309EE-C8E3-47C3-9A0F-B9AB89654CA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The dates work for me and I plan to be there. Raphael > On 3 Aug 2018, at 21:13, Katriel Cohn-Gordon wrote: >=20 > I can be there Thursday, leaving at some point on Friday. >=20 > k >=20 > On Fri, 3 Aug 2018, at 5:54 PM, Benjamin Beurdouche wrote: >> Works for me. I=E2=80=99ll be there too... >> B. >>=20 >>> On Aug 3, 2018, at 9:10 AM, Richard Barnes > wrote: >>>=20 >>> Those dates/location should work fine for me. I will plan on being = there. >>>=20 >>> --Richard >>>=20 >>>=20 >>> On Thu, Aug 2, 2018 at 8:49 PM Nick Sullivan = > wrote: >>> MLS WG, >>>=20 >>> As we announced in Montreal, we are planning on holding an interim = for MLS before the next IETF meeting. In order to make the most = effective use of everyone=E2=80=99s time, we attempted to find a time = that would work for the authors of the majority of the documents up for = adoption. We also want to optimize for accessibility so that we make = sure there are enough people to be productive. >>>=20 >>> With these things in consideration, we propose the following date = and time: >>> September 27-28 (Thursday and Friday) >>> Paris, France >>> Host: TBD >>>=20 >>> Please indicate if you would plan on attending an interim on these = dates. If this date and location are not suitable and you planned to = come, please indicate your expected level of participation in the = interim in your response. >>>=20 >>> Sean & Nick >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf..org/mailman/listinfo/mls = >> Email had 1 attachment: >>=20 >> signature.asc >> 1k (application/pgp-signature) >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_D49309EE-C8E3-47C3-9A0F-B9AB89654CA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = dates work for me and I plan to be there.

Raphael

On 3 Aug = 2018, at 21:13, Katriel Cohn-Gordon <me@katriel.co.uk> = wrote:

I can be = there Thursday, leaving at some point on Friday.

k

On Fri, 3 Aug 2018, at 5:54 PM, Benjamin Beurdouche = wrote:
Works for me. I=E2=80=99= ll be there too...
B.

On = Aug 3, 2018, at 9:10 AM, Richard Barnes <rlb@ipv.sx> wrote:

Those dates/location should work fine for me.  I will = plan on being there.

--Richard


On Thu, Aug 2, 2018 at 8:49 PM = Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
MLS WG,

As we announced in = Montreal, we are planning on holding an interim for MLS before the next = IETF meeting. In order to make the most effective use of everyone=E2=80=99= s time, we attempted to find a time that would work for the authors of = the majority of the documents up for adoption. We also want to optimize = for accessibility so that we make sure there are enough people to be = productive.

With these things in consideration, we propose the following = date and time:
September 27-28 = (Thursday and Friday)
Paris, = France
Host: TBD

Please indicate if you would plan on attending an interim on = these dates. If this date and location are not suitable and you planned = to come, please indicate your expected level of participation in the = interim in your response.

Sean & Nick

_______________________________________________
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

Email had 1 attachment:

  • signature.asc
      1k (application/pgp-signature)

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
= --Apple-Mail=_D49309EE-C8E3-47C3-9A0F-B9AB89654CA5-- From nobody Sun Aug 5 14:51:59 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA281310C2 for ; Sun, 5 Aug 2018 14:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=kORbshgV; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=F0DNOVC7 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 7ELGkBo6nxQF for ; Sun, 5 Aug 2018 14:51:54 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 C877A1310BE for ; Sun, 5 Aug 2018 14:51:54 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w75LnCZv001923; Sun, 5 Aug 2018 14:51:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=i/zvqixLHdkMAbqrilFbq+5MO93J/65TZcRKVM9vZaI=; b=kORbshgVyay1K+Y/3LhL+CXfh0s1r3d6v+F3QEg+Y4y1EkdFbNsshRb3fxCqZlULonuG Q8cb+muj+omItZs29Xia24XwTGYttnHLXVAOVFEWNVCrDq2db1bHUlWjN0cTJd9MRmdx FDU3rpurTk1qsam2j47HDYk6bhYEdXQIx2c= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2kn7f1jtr2-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 05 Aug 2018 14:51:54 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 5 Aug 2018 17:51:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i/zvqixLHdkMAbqrilFbq+5MO93J/65TZcRKVM9vZaI=; b=F0DNOVC7LVAwY+egRw10HTjFZ300VXPFxPz1d3TxY0p6i4E4MjfToZx8iK9fCAqHDZ3qbYWG9JyuoASmaDBLz2iC4icjVEPAmnjUYpKbGnxA14moOCX5SeWf3hvwUOCyVjdRKEaJraxbe3k//3/NOQXs9IVLj7UZ1+ZfIuj0WEw= Received: from SN6PR15MB2205.namprd15.prod.outlook.com (52.135.64.145) by SN6PR15MB2495.namprd15.prod.outlook.com (52.135.66.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Sun, 5 Aug 2018 21:51:31 +0000 Received: from SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b]) by SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b%4]) with mapi id 15.20.1017.019; Sun, 5 Aug 2018 21:51:31 +0000 From: Jon Millican To: Raphael Robert , "mls@ietf.org" Thread-Topic: [MLS] Proposed timing for first interim Thread-Index: AQHUKsPeszGk0ee4pUydCgEMz84xoaSuM1eAgAAMdoCAACbBgIABigQAgAHXl4A= Date: Sun, 5 Aug 2018 21:51:31 +0000 Message-ID: <788B3799-337E-4ED8-BF2B-9004E727D2E1@fb.com> References: <3FD78BD9-87E9-4D8F-B717-85D8F25007E0@inria.fr> <1533323601.3545156.1462743400.3F2C68ED@webmail.messagingengine.com> <0F6F2F87-16F1-4ADB-A7AF-0E1B903AA2C1@wire.com> In-Reply-To: <0F6F2F87-16F1-4ADB-A7AF-0E1B903AA2C1@wire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:180::1:cafe] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR15MB2495; 20:vjR5vomxfkAoHnykssCFDJ8DseDG4dXEtKyBI+ElElUJyYB5n1CRIl8mddzb5i9fAfaKOfrNMx9HEn5RDtV/JmorPiPKxNSus4eUKDeXHmKaPudnwcnbehAgwJqD/AbK3XYxPmOUbAaJPBiWx81k03GEgOJV/gIf/mmO/S1bOpo= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8ef862bd-5fab-45fb-41a0-08d5fb1d9af7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:SN6PR15MB2495; x-ms-traffictypediagnostic: SN6PR15MB2495: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231311)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:SN6PR15MB2495; BCL:0; PCL:0; RULEID:; SRVR:SN6PR15MB2495; x-forefront-prvs: 0755F54DD9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(136003)(376002)(346002)(366004)(396003)(189003)(199004)(2900100001)(229853002)(54896002)(6512007)(102836004)(6306002)(7736002)(8676002)(2906002)(236005)(81156014)(6506007)(53546011)(46003)(93886005)(6436002)(81166006)(33656002)(5660300001)(82746002)(8936002)(478600001)(83716003)(6486002)(966005)(316002)(86362001)(97736004)(14444005)(256004)(5024004)(25786009)(76176011)(106356001)(36756003)(476003)(606006)(110136005)(6116002)(5250100002)(2501003)(2616005)(14454004)(99286004)(53936002)(105586002)(486006)(446003)(68736007)(6246003)(11346002)(186003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR15MB2495; H:SN6PR15MB2205.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FnGt53aJqQGPtJ21+yM/KU5b5qsSrbtirnSxFFyOIsXFUanKgJzVjHNlBbFQ/0y5CjFsd08wcBjUDMNmU0X3skj42SSlFex8UIclX9dzdgfYjTLbLK27DwrU+l85yUXq5ww7l+vEXIV6JpCfPnjwuZrk1+jgmVKnEC0kx/d6ggr0AA7HqJHfwZLz1lVz1gmSix4yKo1ppOF3jiXZn7ULU3KjI0uJ/ch6XrL91KTlegpo0dca46vaJ54ah3Z5bey2U+O+jRF0FIdcnBhPwsWHzKUNcglJBkWnUQgnAF0U6yyiW2B51NDVafdzi1eKML9+mUbIoIokbP+w1g1EByjKw3UoQF4iIkaM/qY35T8JXo4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_788B3799337E4ED8BF2B9004E727D2E1fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8ef862bd-5fab-45fb-41a0-08d5fb1d9af7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2018 21:51:31.3520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2495 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-05_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 21:51:58 -0000 --_000_788B3799337E4ED8BF2B9004E727D2E1fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzaG91bGQgYmUgYWJsZSB0byBtYWtlIHRoaXMgZGF0ZXMsIGFuZCB3aWxsIHBsYW4gdG8gYmUg dGhlcmUuDQoNClRoYW5rcywNCkpvbg0KDQpPbiAwNC8wOC8yMDE4LCAxOTo0NCwgIk1MUyBvbiBi ZWhhbGYgb2YgUmFwaGFlbCBSb2JlcnQiIDxtbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWxz LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiByYXBoYWVsQHdpcmUuY29tPG1haWx0bzpy YXBoYWVsQHdpcmUuY29tPj4gd3JvdGU6DQoNClRoZSBkYXRlcyB3b3JrIGZvciBtZSBhbmQgSSBw bGFuIHRvIGJlIHRoZXJlLg0KDQpSYXBoYWVsDQoNCg0KT24gMyBBdWcgMjAxOCwgYXQgMjE6MTMs IEthdHJpZWwgQ29obi1Hb3Jkb24gPG1lQGthdHJpZWwuY28udWs8bWFpbHRvOm1lQGthdHJpZWwu Y28udWs+PiB3cm90ZToNCg0KSSBjYW4gYmUgdGhlcmUgVGh1cnNkYXksIGxlYXZpbmcgYXQgc29t ZSBwb2ludCBvbiBGcmlkYXkuDQoNCmsNCg0KT24gRnJpLCAzIEF1ZyAyMDE4LCBhdCA1OjU0IFBN LCBCZW5qYW1pbiBCZXVyZG91Y2hlIHdyb3RlOg0KV29ya3MgZm9yIG1lLiBJ4oCZbGwgYmUgdGhl cmUgdG9vLi4uDQpCLg0KDQpPbiBBdWcgMywgMjAxOCwgYXQgOToxMCBBTSwgUmljaGFyZCBCYXJu ZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCg0KVGhvc2UgZGF0ZXMv bG9jYXRpb24gc2hvdWxkIHdvcmsgZmluZSBmb3IgbWUuICBJIHdpbGwgcGxhbiBvbiBiZWluZyB0 aGVyZS4NCg0KLS1SaWNoYXJkDQoNCg0KT24gVGh1LCBBdWcgMiwgMjAxOCBhdCA4OjQ5IFBNIE5p Y2sgU3VsbGl2YW4gPG5pY2s9NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KTUxTIFdHLA0KDQpBcyB3 ZSBhbm5vdW5jZWQgaW4gTW9udHJlYWwsIHdlIGFyZSBwbGFubmluZyBvbiBob2xkaW5nIGFuIGlu dGVyaW0gZm9yIE1MUyBiZWZvcmUgdGhlIG5leHQgSUVURiBtZWV0aW5nLiBJbiBvcmRlciB0byBt YWtlIHRoZSBtb3N0IGVmZmVjdGl2ZSB1c2Ugb2YgZXZlcnlvbmXigJlzIHRpbWUsIHdlIGF0dGVt cHRlZCB0byBmaW5kIGEgdGltZSB0aGF0IHdvdWxkIHdvcmsgZm9yIHRoZSBhdXRob3JzIG9mIHRo ZSBtYWpvcml0eSBvZiB0aGUgZG9jdW1lbnRzIHVwIGZvciBhZG9wdGlvbi4gV2UgYWxzbyB3YW50 IHRvIG9wdGltaXplIGZvciBhY2Nlc3NpYmlsaXR5IHNvIHRoYXQgd2UgbWFrZSBzdXJlIHRoZXJl IGFyZSBlbm91Z2ggcGVvcGxlIHRvIGJlIHByb2R1Y3RpdmUuDQoNCldpdGggdGhlc2UgdGhpbmdz IGluIGNvbnNpZGVyYXRpb24sIHdlIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBkYXRlIGFuZCB0aW1l Og0KU2VwdGVtYmVyIDI3LTI4IChUaHVyc2RheSBhbmQgRnJpZGF5KQ0KUGFyaXMsIEZyYW5jZQ0K SG9zdDogVEJEDQoNClBsZWFzZSBpbmRpY2F0ZSBpZiB5b3Ugd291bGQgcGxhbiBvbiBhdHRlbmRp bmcgYW4gaW50ZXJpbSBvbiB0aGVzZSBkYXRlcy4gSWYgdGhpcyBkYXRlIGFuZCBsb2NhdGlvbiBh cmUgbm90IHN1aXRhYmxlIGFuZCB5b3UgcGxhbm5lZCB0byBjb21lLCBwbGVhc2UgaW5kaWNhdGUg eW91ciBleHBlY3RlZCBsZXZlbCBvZiBwYXJ0aWNpcGF0aW9uIGluIHRoZSBpbnRlcmltIGluIHlv dXIgcmVzcG9uc2UuDQoNClNlYW4gJiBOaWNrDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpNTFMgbWFpbGluZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFp bHRvOk1MU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWxzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbWxzJmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgz eWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT0yR2t4SDEzcXk0TWtoUXR2V21L WG13RUp5WEdEUXIyTFNPVjdCVjFXZmxjJnM9WHRVd1hXZzhqRW8xbHJWMHBhbFFxUDV4TmczTVBz SE1OR3ZQRnhWaE1VayZlPT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpNTFMgbWFpbGluZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFpbHRvOk1MU0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fbWxzJmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZy PU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT0yR2t4SDEzcXk0TWtoUXR2V21LWG13RUp5WEdEUXIy TFNPVjdCVjFXZmxjJnM9WHRVd1hXZzhqRW8xbHJWMHBhbFFxUDV4TmczTVBzSE1OR3ZQRnhWaE1V ayZlPT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpN TFMgbWFpbGluZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFpbHRvOk1MU0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX21scyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5ZEJW VVhfYnZFcU1hODRRJm09MkdreEgxM3F5NE1raFF0dldtS1htd0VKeVhHRFFyMkxTT1Y3QlYxV2Zs YyZzPVh0VXdYV2c4akVvMWxyVjBwYWxRcVA1eE5nM01Qc0hNTkd2UEZ4VmhNVWsmZT0+DQpFbWFp bCBoYWQgMSBhdHRhY2htZW50Og0KwrcgICAgICAgICBzaWduYXR1cmUuYXNjDQogIDFrIChhcHBs aWNhdGlvbi9wZ3Atc2lnbmF0dXJlKQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0bzpN TFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQx YjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09MkdreEgxM3F5NE1raFF0dldtS1htd0VK eVhHRFFyMkxTT1Y3QlYxV2ZsYyZzPVh0VXdYV2c4akVvMWxyVjBwYWxRcVA1eE5nM01Qc0hNTkd2 UEZ4VmhNVWsmZT0+DQoNCg== --_000_788B3799337E4ED8BF2B9004E727D2E1fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <6040755A572C7B4FB1187F8A808BB685@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAz IDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpjb2RlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA3NDIwODE3 NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwNTYxNDA2NjA7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNob3VsZCBiZSBhYmxlIHRvIG1ha2Ug dGhpcyBkYXRlcywgYW5kIHdpbGwgcGxhbiB0byBiZSB0aGVyZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+T24gMDQvMDgvMjAxOCwgMTk6NDQsICZxdW90O01MUyBvbiBiZWhhbGYgb2YgUmFwaGFl bCBSb2JlcnQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZyI+ bWxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnJh cGhhZWxAd2lyZS5jb20iPnJhcGhhZWxAd2lyZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZSBkYXRlcyB3b3Jr IGZvciBtZSBhbmQgSSBwbGFuIHRvIGJlIHRoZXJlLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5SYXBoYWVsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5PbiAzIEF1ZyAyMDE4LCBhdCAyMToxMywgS2F0cmllbCBDb2huLUdvcmRv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lQGthdHJpZWwuY28udWsiPm1lQGthdHJpZWwuY28udWs8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZx dW90OyxzZXJpZiI+SSBjYW4gYmUgdGhlcmUgVGh1cnNkYXksIGxlYXZpbmcgYXQgc29tZSBwb2lu dCBvbiBGcmlkYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPms8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPk9uIEZyaSwgMyBBdWcg MjAxOCwgYXQgNTo1NCBQTSwgQmVuamFtaW4gQmV1cmRvdWNoZSB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRv O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7 LHNlcmlmIj5Xb3JrcyBmb3IgbWUuIEnigJlsbCBiZSB0aGVyZSB0b28uLi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj5CLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhIj5PbiBBdWcgMywgMjAxOCwgYXQgOToxMCBBTSwgUmljaGFyZCBCYXJuZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4Ij5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5UaG9zZSBkYXRlcy9sb2NhdGlvbiBzaG91bGQgd29y ayBmaW5lIGZvciBtZS4mbmJzcDsgSSB3aWxsIHBsYW4gb24gYmVpbmcgdGhlcmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4tLVJpY2hhcmQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2EiPk9uIFRodSwgQXVnIDIsIDIwMTggYXQgODo0OSBQTSBOaWNrIFN1 bGxpdmFuICZsdDtuaWNrPTxhIGhyZWY9Im1haWx0bzo0MGNsb3VkZmxhcmUuY29tQGRtYXJjLmll dGYub3JnIj40MGNsb3VkZmxhcmUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5NTFMgV0csPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5BcyB3ZSBh bm5vdW5jZWQgaW4gTW9udHJlYWwsIHdlIGFyZSBwbGFubmluZyBvbiBob2xkaW5nIGFuIGludGVy aW0gZm9yIE1MUyBiZWZvcmUgdGhlIG5leHQgSUVURiBtZWV0aW5nLiBJbiBvcmRlciB0byBtYWtl IHRoZSBtb3N0IGVmZmVjdGl2ZSB1c2Ugb2YgZXZlcnlvbmXigJlzDQogdGltZSwgd2UgYXR0ZW1w dGVkIHRvIGZpbmQgYSB0aW1lIHRoYXQgd291bGQgd29yayBmb3IgdGhlIGF1dGhvcnMgb2YgdGhl IG1ham9yaXR5IG9mIHRoZSBkb2N1bWVudHMgdXAgZm9yIGFkb3B0aW9uLiBXZSBhbHNvIHdhbnQg dG8gb3B0aW1pemUgZm9yIGFjY2Vzc2liaWxpdHkgc28gdGhhdCB3ZSBtYWtlIHN1cmUgdGhlcmUg YXJlIGVub3VnaCBwZW9wbGUgdG8gYmUgcHJvZHVjdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPldpdGggdGhlc2UgdGhpbmdzIGluIGNv bnNpZGVyYXRpb24sIHdlIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBkYXRlIGFuZCB0aW1lOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhIj5TZXB0ZW1iZXIgMjctMjggKFRodXJzZGF5IGFuZCBGcmlkYXkp PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlBhcmlzLCBGcmFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+SG9zdDogVEJEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj5QbGVhc2UgaW5kaWNhdGUgaWYgeW91IHdvdWxkIHBsYW4gb24gYXR0ZW5k aW5nIGFuIGludGVyaW0gb24gdGhlc2UgZGF0ZXMuIElmIHRoaXMgZGF0ZSBhbmQgbG9jYXRpb24g YXJlIG5vdCBzdWl0YWJsZSBhbmQgeW91IHBsYW5uZWQgdG8gY29tZSwgcGxlYXNlIGluZGljYXRl DQogeW91ciBleHBlY3RlZCBsZXZlbCBvZiBwYXJ0aWNpcGF0aW9uIGluIHRoZSBpbnRlcmltIGlu IHlvdXIgcmVzcG9uc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj5TZWFuICZhbXA7IE5pY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj5NTFMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj48YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIj5N TFNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj48 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZhbXA7ZD1Ed01GYVEmYW1wO2M9 NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDtt PTJHa3hIMTNxeTRNa2hRdHZXbUtYbXdFSnlYR0RRcjJMU09WN0JWMVdmbGMmYW1wO3M9WHRVd1hX ZzhqRW8xbHJWMHBhbFFxUDV4TmczTVBzSE1OR3ZQRnhWaE1VayZhbXA7ZT0iPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2Vvcmdp YSZxdW90OyxzZXJpZiI+TUxTIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2Vvcmdp YSZxdW90OyxzZXJpZiI+PGEgaHJlZj0ibWFpbHRvOk1MU0BpZXRmLm9yZyI+TUxTQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZiI+PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRo M3ljZDQxYjNNVXcmYW1wO3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7bT0yR2t4SDEzcXk0 TWtoUXR2V21LWG13RUp5WEdEUXIyTFNPVjdCVjFXZmxjJmFtcDtzPVh0VXdYV2c4akVvMWxyVjBw YWxRcVA1eE5nM01Qc0hNTkd2UEZ4VmhNVWsmYW1wO2U9Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21sczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjx1PjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L3U+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhIj5NTFMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxhIGhyZWY9Im1h aWx0bzpNTFNAaWV0Zi5vcmciPk1MU0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFt cDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZh bXA7bT0yR2t4SDEzcXk0TWtoUXR2V21LWG13RUp5WEdEUXIyTFNPVjdCVjFXZmxjJmFtcDtzPVh0 VXdYV2c4akVvMWxyVjBwYWxRcVA1eE5nM01Qc0hNTkd2UEZ4VmhNVWsmYW1wO2U9Ij5odHRwczov L3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5FbWFp bCBoYWQgMSBhdHRhY2htZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGNvZGU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPnNpZ25hdHVyZS5hc2M8L3NwYW4+PC9jb2RlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPiZuYnNwOyAxayAoYXBwbGljYXRpb24vcGdw LXNpZ25hdHVyZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVv dDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTUxTIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+TUxTQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbWxzJmFtcDtkPUR3TUZhUSZhbXA7 Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmYW1w O209MkdreEgxM3F5NE1raFF0dldtS1htd0VKeVhHRFFyMkxTT1Y3QlYxV2ZsYyZhbXA7cz1YdFV3 WFdnOGpFbzFsclYwcGFsUXFQNXhOZzNNUHNITU5HdlBGeFZoTVVrJmFtcDtlPSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_788B3799337E4ED8BF2B9004E727D2E1fbcom_-- From nobody Mon Aug 6 06:01:15 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF0130934 for ; Mon, 6 Aug 2018 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 1P2vdd9a9fDK for ; Mon, 6 Aug 2018 06:01:10 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07EDB130DDA for ; Mon, 6 Aug 2018 06:01:10 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id d189-v6so21953637oib.6 for ; Mon, 06 Aug 2018 06:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=a+YZs/QTBO0fvrBXa/CgSKKm1iy800AIX/beBgL1j5w=; b=HkG/FXpnMh6GudSS+x5uVOWabtSYhI+pZiG/WaFLO4pUDmgNTkhC6uK4LvhKlzHGei DVRcncVuQzQoUS7I/0L661a3II4MWzkAEGCzdW35xawrIlzG1QAx0vfNf3N7EXxE/zq+ kQPfknVepRmIGLynmn4jSDiTUGbiOpX9lt+x5nxUcEec81fsxivmt5Jg9FMBYE3vgWxu kBcObd5gR1ioK8JQmRK6dOaoQ6nQhJDpwsNovwNcp1eEUbw9EODRn4k7i9EZhbWD6/Kn UFQhWPkwyLIMcwcJht3xl4LdNm06CQNe8OvT/Cza4v0bAvFJuQYA3YSUTcA51+uhaX1Z wnyQ== 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=a+YZs/QTBO0fvrBXa/CgSKKm1iy800AIX/beBgL1j5w=; b=XGHTcIer2fSlnxGPPIdvyUq/JbxmndLPSzCUz8QTkPDju9XP7DDf0XbZpL/XMEBPYP 7g0iNpZxSl9z3WtIobt2ST1WpBO7LRSglApwYiu47AHtHjAnJOCsgDP2PcIG8d0GedRL X0+uDcXCqGfAp0AB3izp3/f7Fxmr/U1FZiv2JhbB8bhXddUgMJmi7i7BhO306pq9tNZg 0BEtseMtoesUkBe+pJulK1txspfnqe+1jT4ZfHXnE6L9CSDycmd2DsHXye/jPoklgFs0 /o7zVRs2o6vtLUXrx8IiV8IQZbFqCT2uUIqEUpIKdzieZKV/1ey+o3d3IbC6DFo9lANS fCeg== X-Gm-Message-State: AOUpUlGLz02WFBooJvvKh45wMC9q0SdJJPSujaRl1Vhb1Tq9f1hOGcwF D6avCTOq8ey6hb7PLgS9f7vveo6vkchQcX4cVe94/vdD X-Google-Smtp-Source: AAOMgpdO9lMHDOft435RZPtU2t3oMtsFd5oVbMoRSAJxq5IMUaVqTIvA8uHKi5g1IrzL9wgsAIiTXtJ9kVfDqUTSqyw= X-Received: by 2002:aca:d088:: with SMTP id j8-v6mr14770515oiy.276.1533560468879; Mon, 06 Aug 2018 06:01:08 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 6 Aug 2018 09:00:57 -0400 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000fd9cd30572c3dec4" Archived-At: Subject: [MLS] Remove without double-join (in TreeKEM) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 13:01:13 -0000 --000000000000fd9cd30572c3dec4 Content-Type: text/plain; charset="UTF-8" Hey all, On Friday, I got to thinking about how to do the Remove operation with TreeKEM, and I think I've got a way to do it that avoids double-join problems while still being pretty elegant. - When a member is removed from the group, remaining members update their local caches of the tree so that any nodes in the direct path of the removed leaf are set to blank - This means that for future group operations, some of the nodes you would encrypt to might not be blank - Extend the "encrypt to subgroup" function so that if the node at the head of the subgroup is blank (i.e., the subgroup is not full), then you work down the tree and encrypt to all the subtree heads. In the short run, this fragments the tree. In the worst case, if you delete every other member, you end up with linear updates. This is mitigated by a few nice features, though: 1. The tree "heals" as members update: Because an Update contains a direct path that overwrites any blanked-out nodes, from the perspective of the rest of the tree, subtrees with heads along that path are now whole from the perspective of nodes outside those subtrees. A healed tree will still be "stringy". 2. New members can be added into the blank leaves just by sending an Update (just like UserAdd / GroupAdd, but without growing the size of the tree). Existing members can relocate to a blank slot in the same way. With a bit more cleverness, it might be possible to shrink a tree back down to its minimal size after adding a bunch of members and removing them all. I've implemented a first pass at this approach in my JS demo stack at < https://ipv.sx/treekem/>. You can delete nodes after adding them, and updates still work. Adds appear to be broken for the moment, but I think that's surmountable. --- Now, it's still possible to do Remove by the sender of the Remove doing an Update for the removed, using a leaf secret the removed node doesn't know. That leaves the tree intact, at the cost of having the sender double-joined in the removed slot as well as his original slot. (Effectively, it's a take-over operation.) So we have now two choices for trade-offs around Remove: 1. Leave some parts of the tree empty and track subtree heads; no double join 2. Keep the tree full and only have normal copath logic; but accept double join Personally, I find the logic of double-join bookkeeping more intimidating than the logic to keep track of the tree. But I would be interested in what other folks think of these trade-offs. It might also be interesting to think of whether ART could be extended to do remove-without-double-join in something like the above way. It wasn't immediately obvious to me, but I didn't try very hard. --Richard --000000000000fd9cd30572c3dec4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

On Friday, I got to= thinking about how to do the Remove operation with TreeKEM, and I think I&= #39;ve got a way to do it that avoids double-join problems while still bein= g pretty elegant.

- When a member is removed from = the group, remaining members update their local caches of the tree so that = any nodes in the direct path of the removed leaf are set to blank
=
- This means that for future group operations, some of the nodes you w= ould encrypt to might not be blank
- Extend the "encrypt to = subgroup" function so that if the node at the head of the subgroup is = blank (i.e., the subgroup is not full), then you work down the tree and enc= rypt to all the subtree heads.

In the short run, t= his fragments the tree.=C2=A0 In the worst case, if you delete every other = member, you end up with linear updates.=C2=A0 This is mitigated by a few ni= ce features, though:

1. The tree "heals"= as members update: Because an Update contains a direct path that overwrite= s any blanked-out nodes, from the perspective of the rest of the tree, subt= rees with heads along that path are now whole from the perspective of nodes= outside those subtrees.=C2=A0 A healed tree will still be "stringy&qu= ot;.

2. New members can be added into the blan= k leaves just by sending an Update (just like UserAdd / GroupAdd, but witho= ut growing the size of the tree).=C2=A0 Existing members can relocate to a = blank slot in the same way.

With a bit more cl= everness, it might be possible to shrink a tree back down to its minimal si= ze after adding a bunch of members and removing them all.

I've implemented a first pass at this approach in my JS demo st= ack at <https://ipv.sx/treekem/&= gt;.=C2=A0 You can delete nodes after adding them, and updates still work.= =C2=A0 Adds appear to be broken for the moment, but I think that's surm= ountable.

---

Now, it= 's still possible to do Remove by the sender of the Remove doing an Upd= ate for the removed, using a leaf secret the removed node doesn't know.= =C2=A0 That leaves the tree intact, at the cost of having the sender double= -joined in the removed slot as well as his original slot.=C2=A0 (Effectivel= y, it's a take-over operation.)

So we have now= two choices for trade-offs around Remove:

1. Leav= e some parts of the tree empty and track subtree heads; no double join
2. Keep the tree full and only have normal copath logic; but accept d= ouble join

Personally, I find the logic of double-= join bookkeeping more intimidating than the logic to keep track of the tree= .=C2=A0 But I would be interested in what other folks think of these trade-= offs.

It might also be interesting to think of whe= ther ART could be extended to do remove-without-double-join in something li= ke the above way.=C2=A0 It wasn't immediately obvious to me, but I didn= 't try very hard.

--Richard
--000000000000fd9cd30572c3dec4-- From nobody Mon Aug 6 12:08:43 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45965130F1B for ; Mon, 6 Aug 2018 12:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01] 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 Yf3ROOMflwA1 for ; Mon, 6 Aug 2018 12:08:39 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 C03EF130F0E for ; Mon, 6 Aug 2018 12:08:38 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id s9-v6so14881850wmh.3 for ; Mon, 06 Aug 2018 12:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ryteb+cxcOlzYG3s59k48kL+rZvqubVDWWN0aRmKH4o=; b=R5/7oI20tnDssWOyhWf2LcWoo6cuFECUn4FiNXCzy737vp+nzOMgAW272FyZNBFYRM WCW6idHi3/ytXSFlIvOnujFDl6kP/XuhPMDcnRUm9KY5+AuiIPxZurZE/pnYqrBqkoUU s2YwGwboLhdRhqXk2/iVRd7OU150CjXivV5h1+gt/bUDqH1ArWhcGGGKDtcrvFjQbO6r Q6/rkpwBHXghKh053pOS20BoI/rqMZX7jwgxENf4U/Y/dj/8nTofbMDmQLIuueWu3SkF mUY4dblXaxN0kEj3tlA8I4SEIayo2PVfMnKJylUj0h7veTtr6iBORyhbse7xApcAROu1 n20Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=ryteb+cxcOlzYG3s59k48kL+rZvqubVDWWN0aRmKH4o=; b=mAS2FdFhbPn4KajASz9jQADF+kEm6z32jBrMDcO3WgF90JD7mq3Ap9M6PvFIVaOZBw 4Srjj98sDF1jmZlMqDg2hHXdk4ySA7vhtaHk6ie5TQsZ4MzogcCrIZFXVSiSB52NvHnz AQ/H+ZxYhIXiOvFAaLb94urtkWvut+l6hkSdi1l2RphzdCxaU3Mk5yXKJ7yXLLNwOaeL sGZVRcmjeqvHielRLb70I/yRYfLgJe4EXFWMusn3LggX3/ih78LOHHnIBBJLgKZjIQUf PvHJnVEEPcXwUrt8gwyWO2gB1KHx0fnFv4YNb0ubk1e3OMjPESfNIxMSaxAbstV+K4En HReg== X-Gm-Message-State: AOUpUlGblZpp3OLtACO/b69dW3Da0c+8FKZOGAzy0gRFaOiQKeuDSQwg njXbqZ/maPTkZg+4K1UzLWAAkIgj0fw/mQ== X-Google-Smtp-Source: AAOMgpe2YPgv0sO+A/B7BNTrYVezUxfLO4XNhUEergo605sHn3mmfhgxUmvs5J/MqDSNj4xixOzZgg== X-Received: by 2002:a1c:6c03:: with SMTP id h3-v6mr11950074wmc.38.1533582516767; Mon, 06 Aug 2018 12:08:36 -0700 (PDT) Received: from rmbp.fritz.box (HSI-KBW-095-208-247-123.hsi5.kabel-badenwuerttemberg.de. [95.208.247.123]) by smtp.gmail.com with ESMTPSA id g10-v6sm11474924wrv.90.2018.08.06.12.08.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 12:08:35 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_3455ED7E-C662-4831-872D-436361F76E10" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 6 Aug 2018 21:08:36 +0200 References: To: mls@ietf.org In-Reply-To: Message-Id: <1566E5D8-29A0-4CE7-A256-2445686F30E5@wire.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Remove without double-join (in TreeKEM) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 19:08:41 -0000 --Apple-Mail=_3455ED7E-C662-4831-872D-436361F76E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this is an interesting thought! In practice =E2=80=94 when = groups are somewhat dynamic =E2=80=94 the blanks in the tree would be = filled pretty quickly with new members. The only edge case I can think = of right now would be when a group starts with a large amount of = members, and it size decreases over time. But that scenario is generally = a problematic one regarding efficiency. Raphael > On 6 Aug 2018, at 15:00, Richard Barnes wrote: >=20 > Hey all, >=20 > On Friday, I got to thinking about how to do the Remove operation with = TreeKEM, and I think I've got a way to do it that avoids double-join = problems while still being pretty elegant. >=20 > - When a member is removed from the group, remaining members update = their local caches of the tree so that any nodes in the direct path of = the removed leaf are set to blank > - This means that for future group operations, some of the nodes you = would encrypt to might not be blank > - Extend the "encrypt to subgroup" function so that if the node at the = head of the subgroup is blank (i.e., the subgroup is not full), then you = work down the tree and encrypt to all the subtree heads. >=20 > In the short run, this fragments the tree. In the worst case, if you = delete every other member, you end up with linear updates. This is = mitigated by a few nice features, though: >=20 > 1. The tree "heals" as members update: Because an Update contains a = direct path that overwrites any blanked-out nodes, from the perspective = of the rest of the tree, subtrees with heads along that path are now = whole from the perspective of nodes outside those subtrees. A healed = tree will still be "stringy". >=20 > 2. New members can be added into the blank leaves just by sending an = Update (just like UserAdd / GroupAdd, but without growing the size of = the tree). Existing members can relocate to a blank slot in the same = way. >=20 > With a bit more cleverness, it might be possible to shrink a tree back = down to its minimal size after adding a bunch of members and removing = them all. >=20 > I've implemented a first pass at this approach in my JS demo stack at = >. You can delete = nodes after adding them, and updates still work. Adds appear to be = broken for the moment, but I think that's surmountable. >=20 > --- >=20 > Now, it's still possible to do Remove by the sender of the Remove = doing an Update for the removed, using a leaf secret the removed node = doesn't know. That leaves the tree intact, at the cost of having the = sender double-joined in the removed slot as well as his original slot. = (Effectively, it's a take-over operation.) >=20 > So we have now two choices for trade-offs around Remove: >=20 > 1. Leave some parts of the tree empty and track subtree heads; no = double join > 2. Keep the tree full and only have normal copath logic; but accept = double join >=20 > Personally, I find the logic of double-join bookkeeping more = intimidating than the logic to keep track of the tree.. But I would be = interested in what other folks think of these trade-offs. >=20 > It might also be interesting to think of whether ART could be extended = to do remove-without-double-join in something like the above way. It = wasn't immediately obvious to me, but I didn't try very hard. >=20 > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_3455ED7E-C662-4831-872D-436361F76E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think this is an interesting thought! In practice =E2=80=94 when groups = are somewhat dynamic =E2=80=94 the blanks in the tree would be filled = pretty quickly with new members. The only edge case I can think of right = now would be when a group starts with a large amount of members, and it = size decreases over time. But that scenario is generally a problematic = one regarding efficiency.

Raphael

On 6 Aug 2018, at 15:00, = Richard Barnes <rlb@ipv.sx> wrote:

Hey all,

On Friday, I got to thinking about how = to do the Remove operation with TreeKEM, and I think I've got a way to = do it that avoids double-join problems while still being pretty = elegant.

- = When a member is removed from the group, remaining members update their = local caches of the tree so that any nodes in the direct path of the = removed leaf are set to blank
- This = means that for future group operations, some of the nodes you would = encrypt to might not be blank
- Extend the "encrypt = to subgroup" function so that if the node at the head of the subgroup is = blank (i.e., the subgroup is not full), then you work down the tree and = encrypt to all the subtree heads.

In the short run, this fragments the = tree.  In the worst case, if you delete every other member, you end = up with linear updates.  This is mitigated by a few nice features, = though:

1. The = tree "heals" as members update: Because an Update contains a direct path = that overwrites any blanked-out nodes, from the perspective of the rest = of the tree, subtrees with heads along that path are now whole from the = perspective of nodes outside those subtrees.  A healed tree will = still be "stringy".

2. New members can be added into the = blank leaves just by sending an Update (just like UserAdd / GroupAdd, = but without growing the size of the tree).  Existing members can = relocate to a blank slot in the same way.

With a bit more = cleverness, it might be possible to shrink a tree back down to its = minimal size after adding a bunch of members and removing them = all.

I've = implemented a first pass at this approach in my JS demo stack at <https://ipv.sx/treekem/>.  You can delete nodes = after adding them, and updates still work.  Adds appear to be = broken for the moment, but I think that's surmountable.

---

Now, it's still possible to do Remove by the sender of the = Remove doing an Update for the removed, using a leaf secret the removed = node doesn't know.  That leaves the tree intact, at the cost of = having the sender double-joined in the removed slot as well as his = original slot.  (Effectively, it's a take-over = operation.)

So = we have now two choices for trade-offs around Remove:

1. Leave some parts of = the tree empty and track subtree heads; no double join
2. Keep the tree full and only have normal copath logic; but = accept double join

Personally, I find the logic of double-join bookkeeping more = intimidating than the logic to keep track of the tree..  But I = would be interested in what other folks think of these = trade-offs.

It = might also be interesting to think of whether ART could be extended to = do remove-without-double-join in something like the above way.  It = wasn't immediately obvious to me, but I didn't try very hard.

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

= --Apple-Mail=_3455ED7E-C662-4831-872D-436361F76E10-- From nobody Tue Aug 7 06:56:13 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B06130EE8 for ; Tue, 7 Aug 2018 06:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piwp88O_H3xL for ; Tue, 7 Aug 2018 06:56:09 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 ADB16130EED for ; Tue, 7 Aug 2018 06:56:09 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id u21-v6so11446303qku.2 for ; Tue, 07 Aug 2018 06:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r+/eCwzM6FSfop9QKQCZxEUUiVy1WpNUdePOkHYdn38=; b=Z5SO30g/2uYzmnRdMJH5AbM77iOg74rOByCrpAdwgb4j7bZQnakvGSOuPHcI+wV7SO 4JgNbUqUJPa6EXrAaY5jFTI3wmpMaYl1sSC8ARGdwAjqLuYCk/H9RWYTcNn+DGM5XfBI Fkg0KCbBPQ6hWpJUbO3TMJ1PKvTq+tKCUfHuU= 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=r+/eCwzM6FSfop9QKQCZxEUUiVy1WpNUdePOkHYdn38=; b=nsxkdfUauZ/vMennYOJtYW/9ltarNf09YqC4xOo/4ay/4NqMXK4iV9NQ4VZGcGvLOl b/Ro3JhJB0zsCtu4/J7Aje4FNe46xAVoE9XThz5iP3SBNE7P9aGCMh5gJiYSpY494Jd2 qHbqkjwOZzAOx1dgKqrhHkKUJ6HhgDdsOmWNl/lLy7L6w7WFyzqJCFxc9xqTXMx7UhMA 4BCzeblI9qOFk4/pz8maute21mWVbY9f0byoRi78UUfnVCgYopCEcocGiD7P1gM+8Y4O q7nJO21KIZ4m7yGIfDSdtn28DaTqcp9NLVcuUGicG2VhUuaYz6XH+tjAhojQT41XWWvR iPJg== X-Gm-Message-State: AOUpUlE5hhx/2Z5hnQubH9EuGN12lZwVxtF+q0VuW0iU5tJtGc5WoaRr eYzl07LKF3PA29f1DM7ZqBxjGA== X-Google-Smtp-Source: AAOMgpd7FuYH6jmLzS5d8szEphpyTG3E6nNo+maP+WZTlZT7G1wQwvBW4nlff50KltFsB6bAncZJGQ== X-Received: by 2002:a37:71c7:: with SMTP id m190-v6mr17535215qkc.275.1533650168925; Tue, 07 Aug 2018 06:56:08 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id i24-v6sm1031023qti.28.2018.08.07.06.56.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 06:56:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Tue, 7 Aug 2018 09:56:06 -0400 Cc: Nick Sullivan , "mls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5CEAAF99-D8DC-4C38-8635-DED2106FA151@sn3rd.com> References: To: Ted Hardie X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Proposed timing for first interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 13:56:12 -0000 > On Aug 3, 2018, at 14:30, Ted Hardie wrote: >=20 > Do you plan on making remote participation possible? I want to say yes, but it really depends on who ends up hosting, which = we=E2=80=99re still working on. spt= From nobody Tue Aug 7 07:12:54 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BADF130FED for ; Tue, 7 Aug 2018 07:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 L--IrHjkODMr for ; Tue, 7 Aug 2018 07:12:49 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 CD334130EC2 for ; Tue, 7 Aug 2018 07:12:49 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id s198-v6so28610349oih.11 for ; Tue, 07 Aug 2018 07:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IJ/HWgAKG9wNoXOqg1vu4DmNdi+NMb04raDVlh49xvA=; b=X2IPVRVwap8U6NFHL6Ssvemyj16WPe99Eqr5WT305qH80syUWiZfrWOdxkmDVfPWzy 0KvQKg9tbqopwlTCsqgZVxzdtK3rH7qvtUgxVK+nwBDwdX/86dhd86xCU13+pjP6vrtB lAgjPnQ7gCWwvxNpSzTOTX8emQN6hB+uiUuS8DKHmGkhioQc+QhwYUFsAAbG9CADOS0J vUCtSep89jk3w8oKMUxxHEGCJ58tGFF2F5dkMaORSOvm6mpCan6AfnYFt4r7WgOgmKPU l9jKGqovi0ofqdpoDk3mVRfZy1x0oRIAtkS9Mm33amMksi12Y5rqX7Hm9+hD6NyRgduF 58PA== 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=IJ/HWgAKG9wNoXOqg1vu4DmNdi+NMb04raDVlh49xvA=; b=Wk2Lf0A1pdw8xdvDUc9J8JpXjEJbg4Mfvaqm8aS3mGPu4argSdGWaB9qaQJ6TE8MI7 iUek1yQ8P9GpPGZ7bLkCi52z/I1fQseZDP1J48kyQwk/CAGvq1ft7EMM5DrA4Vcn4/6I /BlHn3UzPWwSbrj68AJtZkSIIN7GocBx5JJXfzL5mNiwzPXGyzsHCq/uzGv3rD7y2sfs uFGWIs3qEiKxIREOPhPbIsOcd46A1KpXWrUwFtIdZ1rOatRnx9rCMZE7LCclJQDMNA/b 6ZoFjX36kJBncp6eLnk1canLdilpxceL/28guHmR9vP6s2+uXY8lp4fbUS3it9R2q+4s Zxug== X-Gm-Message-State: AOUpUlFO7gL7YwX6LBZYJxm0y18w03NG3Bvs6b51aKXrtdlbPLhgfl25 RjrtZF1e9vAUoVGoXFav/Gf8AtIBDac7rKuF+zo3KQ== X-Google-Smtp-Source: AAOMgpeMSQ4PDh7KxELIMx0FuVG0pztg2aaR611YqcUsNZJJmCJyGFG+C6kbrg5bFuFYwihbf0eVeq7im8F6VePhZUc= X-Received: by 2002:aca:f383:: with SMTP id r125-v6mr18343889oih.6.1533651168916; Tue, 07 Aug 2018 07:12:48 -0700 (PDT) MIME-Version: 1.0 References: <1566E5D8-29A0-4CE7-A256-2445686F30E5@wire.com> In-Reply-To: <1566E5D8-29A0-4CE7-A256-2445686F30E5@wire.com> From: Richard Barnes Date: Tue, 7 Aug 2018 10:12:36 -0400 Message-ID: To: Raphael Robert Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000220dff0572d8fdf1" Archived-At: Subject: Re: [MLS] Remove without double-join (in TreeKEM) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 14:12:52 -0000 --000000000000220dff0572d8fdf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So just to prove out the power of this approach, I added an "autocompact" button to the TreeKEM JS demo: https://ipv.sx/treekem/ If you visit that link, you can build a group by clicking UserAdd or GroupAdd a few times, then do some Remove and Move operations. Then click the full moon to turn on autocompact (no good emoji for this semantic) and do a couple more removals -- notice that the tree automatically moves members into vacant slots, and reduces the tree to the minimum size needed. Obviously, to do this in a distributed group would require a lot of orchestration. But it's nice to see that it's allowed by the crypto. Also on that page, there's a "chaos" button that will push random buttons until you tell it to stop, if you just need some entertainment. Found a couple of bugs that way! --Richard On Mon, Aug 6, 2018 at 3:08 PM Raphael Robert wrote: > I think this is an interesting thought! In practice =E2=80=94 when groups= are > somewhat dynamic =E2=80=94 the blanks in the tree would be filled pretty = quickly > with new members. The only edge case I can think of right now would be wh= en > a group starts with a large amount of members, and it size decreases over > time. But that scenario is generally a problematic one regarding efficien= cy. > > Raphael > > On 6 Aug 2018, at 15:00, Richard Barnes wrote: > > Hey all, > > On Friday, I got to thinking about how to do the Remove operation with > TreeKEM, and I think I've got a way to do it that avoids double-join > problems while still being pretty elegant. > > - When a member is removed from the group, remaining members update their > local caches of the tree so that any nodes in the direct path of the > removed leaf are set to blank > - This means that for future group operations, some of the nodes you woul= d > encrypt to might not be blank > - Extend the "encrypt to subgroup" function so that if the node at the > head of the subgroup is blank (i.e., the subgroup is not full), then you > work down the tree and encrypt to all the subtree heads. > > In the short run, this fragments the tree. In the worst case, if you > delete every other member, you end up with linear updates. This is > mitigated by a few nice features, though: > > 1. The tree "heals" as members update: Because an Update contains a direc= t > path that overwrites any blanked-out nodes, from the perspective of the > rest of the tree, subtrees with heads along that path are now whole from > the perspective of nodes outside those subtrees. A healed tree will stil= l > be "stringy". > > 2. New members can be added into the blank leaves just by sending an > Update (just like UserAdd / GroupAdd, but without growing the size of the > tree). Existing members can relocate to a blank slot in the same way. > > With a bit more cleverness, it might be possible to shrink a tree back > down to its minimal size after adding a bunch of members and removing the= m > all. > > I've implemented a first pass at this approach in my JS demo stack at < > https://ipv.sx/treekem/>. You can delete nodes after adding them, and > updates still work. Adds appear to be broken for the moment, but I think > that's surmountable. > > --- > > Now, it's still possible to do Remove by the sender of the Remove doing a= n > Update for the removed, using a leaf secret the removed node doesn't know= . > That leaves the tree intact, at the cost of having the sender double-join= ed > in the removed slot as well as his original slot. (Effectively, it's a > take-over operation.) > > So we have now two choices for trade-offs around Remove: > > 1. Leave some parts of the tree empty and track subtree heads; no double > join > 2. Keep the tree full and only have normal copath logic; but accept doubl= e > join > > Personally, I find the logic of double-join bookkeeping more intimidating > than the logic to keep track of the tree.. But I would be interested in > what other folks think of these trade-offs. > > It might also be interesting to think of whether ART could be extended to > do remove-without-double-join in something like the above way. It wasn't > immediately obvious to me, but I didn't try very hard. > > --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 > --000000000000220dff0572d8fdf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So just to prove out the power of this approach, I ad= ded an "autocompact" button to the TreeKEM JS demo:

If you visit that link, you can build a group= by clicking UserAdd or GroupAdd a few times, then do some Remove and Move = operations.=C2=A0 Then click the full moon to turn on autocompact (no good = emoji for this semantic) and do a couple more removals -- notice that the t= ree automatically moves members into vacant slots, and reduces the tree to = the minimum size needed.

Obviously, to do thi= s in a distributed group would=20 require a lot of orchestration.=C2=A0 But it's nice to see that it'= s allowed=20 by the crypto.

Also on that page, there'= s a "chaos" button that will push random buttons until you tell i= t to stop, if you just need some entertainment.=C2=A0 Found a couple of bug= s that way!

--Richard

On Mon, Aug 6, 2018 at 3:08 PM Raphael Robert &= lt;raphael@wire.com> wrote:
<= /div>
I think this is an interesting thought! In practi= ce =E2=80=94 when groups are somewhat dynamic =E2=80=94 the blanks in the t= ree would be filled pretty quickly with new members. The only edge case I c= an think of right now would be when a group starts with a large amount of m= embers, and it size decreases over time. But that scenario is generally a p= roblematic one regarding efficiency.

Raphael
On 6 Aug 2018, at 15:00, Richard Barnes <= ;rlb@ipv.sx> wrote:<= /div>
Hey all,

On Friday, I got to th= inking about how to do the Remove operation with TreeKEM, and I think I'= ;ve got a way to do it that avoids double-join problems while still being p= retty elegant.

- When a member is removed from the= group, remaining members update their local caches of the tree so that any= nodes in the direct path of the removed leaf are set to blank
- This means that for future group operations, some of the nodes you woul= d encrypt to might not be blank
- Extend the "encrypt to sub= group" function so that if the node at the head of the subgroup is bla= nk (i.e., the subgroup is not full), then you work down the tree and encryp= t to all the subtree heads.

In the short run, this= fragments the tree.=C2=A0 In the worst case, if you delete every other mem= ber, you end up with linear updates.=C2=A0 This is mitigated by a few nice = features, though:

1. The tree "heals" as= members update: Because an Update contains a direct path that overwrites a= ny blanked-out nodes, from the perspective of the rest of the tree, subtree= s with heads along that path are now whole from the perspective of nodes ou= tside those subtrees.=C2=A0 A healed tree will still be "stringy"= .

2. New members can be added into the blank l= eaves just by sending an Update (just like UserAdd / GroupAdd, but without = growing the size of the tree).=C2=A0 Existing members can relocate to a bla= nk slot in the same way.

With a bit more cleve= rness, it might be possible to shrink a tree back down to its minimal size = after adding a bunch of members and removing them all.

=
I've implemented a first pass at this approach in my JS demo stack= at <https://ipv.s= x/treekem/>.=C2=A0 You can delete nodes after adding them, and updat= es still work.=C2=A0 Adds appear to be broken for the moment, but I think t= hat's surmountable.

---

Now, it's still possible to do Remove by the sender of the Remov= e doing an Update for the removed, using a leaf secret the removed node doe= sn't know.=C2=A0 That leaves the tree intact, at the cost of having the= sender double-joined in the removed slot as well as his original slot.=C2= =A0 (Effectively, it's a take-over operation.)

So we have now two choices for trade-offs around Remove:

1. Leave some parts of the tree empty and track subtree heads; no d= ouble join
2. Keep the tree full and only have normal copath logi= c; but accept double join

Personally, I find the l= ogic of double-join bookkeeping more intimidating than the logic to keep tr= ack of the tree..=C2=A0 But I would be interested in what other folks think= of these trade-offs.

It might also be interesting= to think of whether ART could be extended to do remove-without-double-join= in something like the above way.=C2=A0 It wasn't immediately obvious t= o me, but I didn't try very hard.

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

<= /div>_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000220dff0572d8fdf1-- From nobody Tue Aug 7 12:26:52 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85E7130F25 for ; Tue, 7 Aug 2018 12:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL9BQktTIviy for ; Tue, 7 Aug 2018 12:26:47 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98114130EA2 for ; Tue, 7 Aug 2018 12:26:47 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id y207-v6so30397481oie.13 for ; Tue, 07 Aug 2018 12:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ROyYnJsWFMBnZl1oRE5mXqGo866u9NKYIFQuYBZ0iCk=; b=xXWKym31cD2SmXtZecQ0YRyCIVTNIvRhDFhbTu21+RJ+Hy2dboMjhjwxi3NVHbTs/F 23YEHLT88gkR5oMCOBDOezeVYcnw2G91f2EEeovlgIECPjTLw7lRJDmWgXBUVRvUkgbb zt1IO/zst6Q3Pc+LJq74jz0tQKpOfgJ+oKQRc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ROyYnJsWFMBnZl1oRE5mXqGo866u9NKYIFQuYBZ0iCk=; b=H/quZD5ByRkaaVmvybv3S2/7YLApPlAXQ19FkELICVIFJpvT1qd+OTm24RwwTZPJBq 594DMm9/oWXD/x0POmZeo/wqkRKkrLENde2sc/Pxvbig9YOtgwJKzuzQ6Oo13rlMl9i7 e7dbWTWqs8RNU8LA9fRrGKjfbNOiXTuWlf1kE9EiAmPnB7VY4GREirUig9QIirR4fBzs cSdzdWoDWcOit2NAs6vmfVL2p7ObVxe3JBtjxQPT+/yslL5s02k7LjLZ8hx2KeUqNGiv v0gC9P+R3YgrXOfutG5WQO/lGxBvRSTdYFRjnZp7bFR58XFu2rEjxhI3YZ+jyBSdv9gW O27g== X-Gm-Message-State: AOUpUlEjHDr43zfWRcslyuGqZhCZog5ckfhpfN1Pf9Nvfnhs1SMspWf6 yU0d7yni8QtnbTGj9YqaVnP/QgpbLXS4IED4UlID5ID75Ws/Eg== X-Google-Smtp-Source: AAOMgpexrSBTicaXQw/3i35roR0zoqm837bPcxHn9vzuCymouNnsJ7/C65Z/Dva59RO8CaqdPIK6ybvwBnsEmPZYUh0= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr19232137oib.155.1533670006439; Tue, 07 Aug 2018 12:26:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:315c:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 12:26:25 -0700 (PDT) In-Reply-To: <88EC8310-83D9-483C-9514-B0C184245824@wire.com> References: <88EC8310-83D9-483C-9514-B0C184245824@wire.com> From: Nick Sullivan Date: Tue, 7 Aug 2018 12:26:25 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000efe24d0572dd5fe9" Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 19:26:50 -0000 --000000000000efe24d0572dd5fe9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Based on the feedback, the MLS WG will be adopting this document with the current set of authors. We invite the authors to submit -00 to the data tracker and work with the secretary to move the author's copy to the mlswg Github repo (https://github.com/mlswg). Thanks, Sean & Nick On Tue, Jul 24, 2018 at 1:54 PM, Raphael Robert wrote: > I support the adoption. > > On 24 Jul 2018, at 19:44, Nick Sullivan ietf.org> wrote: > > All, > > The sense of the MLS@IETF102 room was the WG should adopt > https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ as a WG > item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D i= n the > datatracker, but now it=E2=80=99s time to officially do the WG call for a= doption. > So, if you would like for this draft to become a WG document and you are > willing to review various versions as it moves through the process, then > please let the list know by 2359UTC 2018.08.03. If you are opposed to thi= s > being a WG document, please say so (and say why). > > Cheers, > > Nick and Sean > _______________________________________________ > 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 > > --000000000000efe24d0572dd5fe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on = the feedback, the MLS WG will be=C2= =A0adopting=C2=A0this do= cument with the current set of authors. We invite the authors to=C2=A0submi= t -00 to the data tracker and=C2=A0= work with the secretary to move the author's copy to the=C2=A0mlswg=C2=A0Github repo (https://github.com/mlswg).

Thanks,
Sean & Nick

On = Tue, Jul 24, 2018 at 1:54 PM, Raphael Robert <raphael@wire.com> wrote:
I support the adoption.

On 24 Jul 2018, at 19:44,= Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wro= te:

All,
The sense of the MLS@IETF102 room was the WG should adopt https://datatracker.ietf.org/doc/draft-omara-mls-arc= hitecture/ as a WG item. We have marked the draft as a "Candidate = for WG Adoption=E2=80=9D in the datatracker, but now it=E2=80=99s time to o= fficially do the WG call for adoption. So, if you would like for this draft= to become a WG document and you are willing to review various versions as = it moves through the process, then please let the list know by 2359UTC 2018= .08.03. If you are opposed to this being a WG document, please say so (and = say why).

Cheers,

Nick an= d Sean
_______________________________________________
MLS mailing listMLS@ietf.org
https:/= /www.ietf.org/mailman/listinfo/mls


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


--000000000000efe24d0572dd5fe9-- From nobody Tue Aug 7 12:27:02 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA392130F2F for ; Tue, 7 Aug 2018 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqSEvpYCmoUn for ; Tue, 7 Aug 2018 12:26:50 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1AA130EA2 for ; Tue, 7 Aug 2018 12:26:50 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id d189-v6so30465926oib.6 for ; Tue, 07 Aug 2018 12:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=anOxcCRcBCuT4xbBxCrV/Iv+9UiEkEMQOPsQ5skw+IE=; b=xX/4HDJC7hEQbTt86Bbb9oT4wys+dw58V/ZRiMpDLb2Lku7/xQ0JviBjabArn0f91l SE12vdIZNPNj2dp6kUzvkWf1i5AC/2CM4FfiFSsrjkoIdp4Xwyl07kxxByALwxundc+w nguN69Bcas29jAYijbGw0+v07/m7zvyY3ZGvE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=anOxcCRcBCuT4xbBxCrV/Iv+9UiEkEMQOPsQ5skw+IE=; b=Z3NWUJybMEJcXMGfD7G3YIUMKnmctqmlCpF0PjUNJFGz2pot4RmZA5xK8AbjrPXW6w 7TNUnTqirOvCjpuixub67pWhAQVYe930pHyAnihv5M/6hK1kdYqeycfVsHbPaRhkTPgJ 6Rk16NBubV8z6heKLu5dbNtgzlESDvnvvag6DydpqmGVhVmxu8a7acMWFyiz2SMQteD2 DXkkat9n/1ZCXoA13Dfgrf0nSXhoeZ+mCDFZ46FS3AOMNdjA1Qag7SchSiLU348GigVi T/zNTcvPZxeeq8+qgPdlIkKsFdGU9BOCgktK8uQrDMgHvecA+1ZX6ttewtv2VLdkS1iC 7eIQ== X-Gm-Message-State: AOUpUlEkcA33KEGzdAR6o01jDKLt6EVaUETeIa5zwYKFaQrr0bsWmTTQ N8C9URIZwsNoO8kyntprJhmqq6uLdC6CGQtcgHBCipONbEnDBQ== X-Google-Smtp-Source: AAOMgpdc4hL5Doe0B/lTIE+I/xlTrebP9v0NzvTWQDI2mEEY/BN4zaXLe1aNRipaFqfW99PLa3Y0cJQGd2RupM4lFp8= X-Received: by 2002:aca:ceca:: with SMTP id e193-v6mr19388885oig.37.1533670008989; Tue, 07 Aug 2018 12:26:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:315c:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 12:26:28 -0700 (PDT) In-Reply-To: References: From: Nick Sullivan Date: Tue, 7 Aug 2018 12:26:28 -0700 Message-ID: Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000016f09c0572dd6046" Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 19:26:53 -0000 --00000000000016f09c0572dd6046 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Based on the feedback, the MLS WG will be adopting this document with the current set of authors. We invite the authors to submit -00 to the data tracker and work with the secretary to move the author's copy to the mlswg Github repo (https://github.com/mlswg). Thanks, Sean & Nick On Tue, Jul 24, 2018 at 1:55 PM Raphael Robert wrote: > > I support the adoption. > > On 24 Jul 2018, at 19:44, Nick Sullivan ietf.org> wrote: > > All, > > The sense of the MLS@IETF102 room was the WG should adopt > https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ as a WG item. > We have marked the draft as a "Candidate for WG Adoption=E2=80=9D in the > datatracker, but now it=E2=80=99s time to officially do the WG call for a= doption. > So, if you would like for this draft to become a WG document and you are > willing to review various versions as it moves through the process, then > please let the list know by 2359UTC 2018.08.03. If you are opposed to thi= s > being a WG document, please say so (and say why). > > Cheers, > > Nick and Sean > > _______________________________________________ > 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 > --00000000000016f09c0572dd6046 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on = the feedback, the MLS WG will be=C2= =A0adopting=C2=A0this do= cument with the current set of authors. We invite the authors to=C2=A0submi= t -00 to the data tracker and=C2=A0= work with the secretary to move the author's copy to the=C2=A0mlswg=C2=A0Github repo (https://github.com/mlswg).

Thanks,
Sean & Nick

On Tue, Jul 24, 201= 8 at 1:55 PM Raphael Robert <raphael@wire.com> wrote:
<= br>
I support the adoption.

On 24 Jul 2018, at 19:44, N= ick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote= :

All,

= The sense of the MLS@IETF102 room was=C2=A0the WG=C2=A0should adopt https://datatracker.ietf.org/doc/draft-barnes-mls-prot= ocol/ as a WG item. We have marked the draft as a "Candidat= e for WG Adoption=E2=80=9D in the=C2=A0datatracker, but now it=E2=80=99s= time to officially do the WG call for adoption. So, if you would like for = this draft to become a WG document and you are willing to review various ve= rsions as it moves through the process, then please let the list know by 23= 59UTC 2018.08.03. If you are opposed to this being a WG document, please sa= y so (and say why).

Cheers,<= /div>

Nick and Sean

_______________________________________________
MLS mailing listMLS@ietf.org
https:/= /www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000016f09c0572dd6046-- From nobody Wed Aug 15 13:49:02 2018 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7DA130E07; Wed, 15 Aug 2018 13:49:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <153436614099.3061.12089010227296766217@ietfa.amsl.com> Date: Wed, 15 Aug 2018 13:49:01 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-00.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:49:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-00.txt Pages : 38 Date : 2018-08-15 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-protocol-00 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 15 15:02:03 2018 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAE9130EA9; Wed, 15 Aug 2018 15:01:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mls-chairs@ietf.org, mls@ietf.org, kaduk@mit.edu, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153437050570.3122.8861704506127804358.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 15:01:45 -0700 Archived-At: Subject: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 22:01:47 -0000 A new interim meeting request has just been submitted by Sean Turner. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2018-mls-01 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner City: Paris Country: FR Session 1: Date: 2018-09-27 Start Time: 09:00 Europe/Paris Duration: 08:00 Remote Participation Information: Remote participation information will be obtained at the time of approval Agenda Note: https://github.com/mlswg/wg-materials/tree/master/interim-2018-09 Session 2: Date: 2018-09-28 Start Time: 09:00 Europe/Paris Duration: 08:00 Remote Participation Information: Remote participation information will be obtained at the time of approval. Agenda Note: https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/README.md --------------------------------------------------------- From nobody Wed Aug 15 15:23:38 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8A9130DE9 for ; Wed, 15 Aug 2018 15:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzjQJqJ11MCo for ; Wed, 15 Aug 2018 15:23:34 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40152130E89 for ; Wed, 15 Aug 2018 15:23:34 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id f18-v6so3056360qtp.10 for ; Wed, 15 Aug 2018 15:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=+qarZRgXsAhIzPyxZz2b0F8u9EmYZdVuOHtgI+oAx4w=; b=FFYCkMVGZK8/hV0/Krp+BCTPAnDk0QKinOnwgeoV4QmwS1UcI8N06Uef7Wc4qfPNsP O3JdLq29x8hKlhQjbgDfdhzynT5nw82r6qL3jawVwHmWgdwlty6oRqtj7NZXrkA6ZsL8 jrKTnnLfcA8pRHI4cT5TbygheYNxf1WWfoQdE= 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=+qarZRgXsAhIzPyxZz2b0F8u9EmYZdVuOHtgI+oAx4w=; b=mQLEroL/VDABg52dhXl4Z4kNFSOVSiHyKyPIrXRfZPoge5g8KcluKi6efwVCHlmIrC v20z1lBGgCdA2D2KxgoEeR5o5Wpal56uVphrnRM10lm8tMpOhcMyJkzhU0D0isL5NFRR 4YjmrOjkKniq4Ll62Dz8gG1yFqoNU0W9n7O/ZmzVq9ItzsUMHUAHGk2dUficEaWyCbM1 zrL6Q3A9zADGU9raVJgDOsPCgN/Q8A8M2+txuj4j4HzVvX4PXZp3kQp8thwlVmXKm/kZ xpVs7xF6w7G7lAjlpnOgUY/Z2tNrZYXjJsl1/z7jjNoOhIw8Bu8kY/A7sbocvwosYOPQ t7dA== X-Gm-Message-State: AOUpUlEnbjLo3zfOTSJEVPF3IMtO0Vsm2wdHCTeE3624VrVOuDsvZ4Rw 417F9IIjb/t4zujI9AbsC00m0J86l8I= X-Google-Smtp-Source: AA+uWPymjI5ygBMxBJ3eNh6JaKCSS7FUmU1aX9KeDE6Bv8Ncil7l28rJQF3Qt2LfABcmrb3groMxEA== X-Received: by 2002:a0c:d6c3:: with SMTP id l3-v6mr24344756qvi.154.1534371813196; Wed, 15 Aug 2018 15:23:33 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id b30-v6sm14857027qtc.78.2018.08.15.15.23.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 15:23:32 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 15 Aug 2018 18:23:31 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] MLS Working Group Interim Meeting - registration required X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 22:23:36 -0000 You will have seen the interim meeting request recently sent to the list = [0]. Once Ben (our AD) approves it the official announcement will be = sent to the IETF-Announce and MLS lists. In the meantime, Nick and I = need to get an accurate headcount for those who plan to attend in person = and remotely. The registration link can be found at: https://github.com/mlswg/wg-materials/tree/master/interim-2018-09 We will close registration at 2359UTC on 27 August 2018. spt [0] = https://mailarchive.ietf.org/arch/msg/mls/KYyCx1aX65RGKIpL6atykrcxGsI= From nobody Wed Aug 15 15:34:59 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A1C130DCF for ; Wed, 15 Aug 2018 15:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD-w7GvBOZ02 for ; Wed, 15 Aug 2018 15:34:56 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1841A126CC7 for ; Wed, 15 Aug 2018 15:34:56 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id z8-v6so3085675qto.9 for ; Wed, 15 Aug 2018 15:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Exj/GO+aO1teM5gg+MxxruLwD5T2ZfkEXkOIINNzgM4=; b=TaNgCTu+u6H539MrNSxc+pZ6Ml0RvqNNhE7jfc7tyJgRnawFBCEohnHf9Ljzd4ltpX 0eo+1IMIzCtv4btDYI+L4Jy/gZt7+isfuSPM1ScHwncJyND4IAl2JQ2cCopDtOr2AGHZ nMfEEiATD0Bgy6vEbsHscKXzc3BKpgGDy++HA= 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=Exj/GO+aO1teM5gg+MxxruLwD5T2ZfkEXkOIINNzgM4=; b=iHSK6Tt6lVw7fj5uisp98Qxi4XqZtfxRE+XbOhxO/vlE8u51oSiChaiSVafe9SdxP0 Su3b3JtyYenXjuDbhY5Esl3fgtL5aMCTAWKv/cBkMqhU5uBM9rbX8cdNoUNO7C8PspUc iObwl5Z/B+pZaGrdT5RiZYlqJdyvHDDBEokc+7M42V8Nlp6mOj7ONWdGBHkUR8rSB1Xx 2vAMRZf26jBnGX33lFwq4BywF1/1KNfN6cBOFhIlyV34YUqzkOOJN0MS8DbvURwJybfn u56RwKnY5a3CQHbrFvJNzJ7TCpV3qQhX+31K3FXQ0tW6oPdiwDaAhQrHOX1LwWVaEyac QUfA== X-Gm-Message-State: AOUpUlHNYjtYSjyI2OzlaCF8D5/7MfcqCMDeSYKRKuDdIcyrzUyVOuT4 cDdTNdP1zpE8zqzBqGuVJ3mgdSY9ICM= X-Google-Smtp-Source: AA+uWPwC1VvjIyR8Zq87iR/uL59Lr56RSv9NKDit5QFyi5ZUzo4fmRKebwBl2DS4I0tEHxJMo3mizQ== X-Received: by 2002:ac8:2dc6:: with SMTP id q6-v6mr28059824qta.178.1534372495086; Wed, 15 Aug 2018 15:34:55 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id k34-v6sm17185261qtf.41.2018.08.15.15.34.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 15:34:54 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <02D1DDD0-AE3F-4B99-87BA-D1C1E582401C@sn3rd.com> Date: Wed, 15 Aug 2018 18:34:51 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] WG materials X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 22:34:58 -0000 Hi, in addition to the MLS WG=E2=80=99s meeting link in the datatracker = (https://datatracker.ietf.org/wg/mls/meetings/), we are also including = materials in our GH repo (https://github.com/mlswg/wg-materials). I = have linked to the GH repo for the upcoming interim announcements and = will continue to do for all future meetings. spt= From nobody Wed Aug 15 15:49:37 2018 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B27A8130EA9; Wed, 15 Aug 2018 15:49:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153437336856.3194.7956428995546724840@ietfa.amsl.com> Date: Wed, 15 Aug 2018 15:49:28 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting: 2018-09-27 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 22:49:29 -0000 The Messaging Layer Security (mls) Working Group will hold a multi-day interim meeting. Session 1: 2018-09-27 09:00 to 17:00 Europe/Paris Session 2: 2018-09-28 09:00 to 17:00 Europe/Paris Meeting Location: Paris, FR Agenda: https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/agenda.md Information about remote participation: Remote participation information will be obtained at the time of approval https://github.com/mlswg/wg-materials/tree/master/interim-2018-09 From nobody Wed Aug 15 16:47:12 2018 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC86130DE0; Wed, 15 Aug 2018 16:47:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <153437682359.3031.12660220552326506425@ietfa.amsl.com> Date: Wed, 15 Aug 2018 16:47:03 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-architecture-00.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 23:47:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : Messaging Layer Security Architecture Authors : Emad Omara Benjamin Beurdouche Eric Rescorla Srinivas Inguva Albert Kwon Alan Duric Filename : draft-ietf-mls-architecture-00.txt Pages : 16 Date : 2018-08-15 Abstract: This document describes the architecture and requirements for the Messaging Layer Security (MLS) protocol. MLS provides a security layer for group messaging applications with from two to a large number of clients. It is meant to protect against eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-architecture-00 https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 21 05:39:40 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7785130EF2 for ; Tue, 21 Aug 2018 05:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGFFIbi8KKoL for ; Tue, 21 Aug 2018 05:39:21 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 F04AE130E24 for ; Tue, 21 Aug 2018 05:39:20 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id e13-v6so8437018pff.7 for ; Tue, 21 Aug 2018 05:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=e7FZh06DOSXtzrafYpJwSAgABaAAMD2mA+jrhN7xW7A=; b=nVg/79SJHAf+pUuHwc8CbXgAFbLvdmlX7XjzaPPOCEl6kEQRhOC3kk3UA/pUbHH3Mc KxnRzB6qe/j4GdqS/JfVXU2z5u5HpaqIA0Bv64BozAKjKeRuLAGRqONCs6lsx1kLGwCr o3bTdhTA+UaUOwIct1XOXYrjKbnZScyA+1llg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=e7FZh06DOSXtzrafYpJwSAgABaAAMD2mA+jrhN7xW7A=; b=dyCyKUkktySTFBwJncI2trM0BF5XNdWXdxWPaID3PZgdn9kbf414/uso12fbvcliHq kWR1ddeVhL/P6KPg+znALKzsvn+ONsGRTYGsDn3tbLKw97X9mbNg2kPfmJHL4gIurt98 96vOGtrpuGncFZJUn4KpnEG0h7i9c/4QQJSWQcx+8dBbqeDsypHHPZKCITRAdmG6Ch/p P6j/5tOWqCE5Ujayjou7KwraEQeEc/9geHRwH4klk/uYEevqcvSu3XkwHimp58Lyqf8e 1uAZPirfa0oHqqksfZoXv95cYUq6Tknyaqhx7jPdZjCqTn/fWKEHwHg7xmHNKYW9Wzhv HTJg== X-Gm-Message-State: AOUpUlFKkvPS+MJL0onq0/Cq+j7AMy4s7f0W2NtTg4nTCVsfN2AEFz4L 125z/xR223NNISrpeXJ2soPSw0p6M5Q= X-Google-Smtp-Source: AA+uWPwi0vt72xkbAPnM76hX9OrPWTHdq5SEob5Xxr08T7nN1pRxWte0d37skAtGxm+KAz2Ee3WScw== X-Received: by 2002:a62:da47:: with SMTP id w7-v6mr52495278pfl.50.1534855160441; Tue, 21 Aug 2018 05:39:20 -0700 (PDT) Received: from [5.5.33.102] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id y86-v6sm20910651pfk.84.2018.08.21.05.39.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 05:39:19 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 21 Aug 2018 08:39:13 -0400 References: To: mls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] REMINDER: Re: MLS Working Group Interim Meeting - registration required X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 12:39:40 -0000 > On Aug 15, 2018, at 18:23, Sean Turner wrote: >=20 > You will have seen the interim meeting request recently sent to the = list [0]. Once Ben (our AD) approves it the official announcement will = be sent to the IETF-Announce and MLS lists. In the meantime, Nick and I = need to get an accurate headcount for those who plan to attend in person = and remotely. The registration link can be found at: > https://github.com/mlswg/wg-materials/tree/master/interim-2018-09 > We will close registration at 2359UTC on 27 August 2018. >=20 > spt >=20 > [0] = https://mailarchive.ietf.org/arch/msg/mls/KYyCx1aX65RGKIpL6atykrcxGsI A friendly reminder to register for the September Interim. spt= From nobody Tue Aug 21 18:51:52 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ADD130DE6 for ; Tue, 21 Aug 2018 18:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbZJEQy88DFz for ; Tue, 21 Aug 2018 18:51:48 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 8ED71130DE3 for ; Tue, 21 Aug 2018 18:51:48 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id k19-v6so208716pfi.1 for ; Tue, 21 Aug 2018 18:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=hOgmuW7qy6NyaRNatoZhsK07YcpYGasmF8B8EcE4MRc=; b=Gj4uBIYmXQINqSKvFiF69Qpbg1t25d94pTt7/87Z4e5QWo+uXt9NhFbWlm3wDq8LbY FyQapNYtU9qP/dKvU8WFO3xYeBWaJo7wM8f9DRGfaDePLLlx437NuzJriAio/APSQXOq LPVh6WKUIyCzyS+rU8LU/craCcZoleOA1WBj4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=hOgmuW7qy6NyaRNatoZhsK07YcpYGasmF8B8EcE4MRc=; b=oWnsZxQ+Dt7pym035neQWcgMC6tX91/8nL05ILBPN9DEh7n0hJ4jF9rzrFsT3puJyR zpZ1/HiaoxfFZFL15f9/R/Dr6OkPE4ti3Go1uFrbSkbS7XhiVnyvqBUpDsb/rNnv01mz 4Vm2vrSvTvOawWkmjsZp2nrupRhSfL95nAgThPy8CRldREj2jWZbOXN0xnBoJRbEZiQ0 MgIWD7yGyjoWCYKkuE16Q6Nrr1FN7xsr1ksu+apu6ZTc0UKCE9/qzKHoXoLj+326Vzxk JUx+7BJUAFl6xKM9xkOkC+R1ibpHI69c8QzPvicDD9KGzPMZOAdii2WBpwSwPjKm9Ozm 02HQ== X-Gm-Message-State: AOUpUlEOoOBUNMHSKClfP83SJnsT3D/63AMo6PVmBsUvZE+/c2TdPdS7 hfZVxRIaTj69lZoHyL6KrZHf9FTY/aw= X-Google-Smtp-Source: AA+uWPwDQ2yRNvCLGhrQMWT9ncYNde3yMi34khJSeewEZhDn3/YYwjGl93dwP9NOL7r5TfboJCQ8VQ== X-Received: by 2002:a62:9541:: with SMTP id p62-v6mr55330732pfd.152.1534902707954; Tue, 21 Aug 2018 18:51:47 -0700 (PDT) Received: from 2603-9001-7085-0200-4931-1d7a-ea7b-2e89.res.spectrum.com ([2603:9001:7085:200:4931:1d7a:ea7b:2e89]) by smtp.gmail.com with ESMTPSA id h24-v6sm273560pfk.113.2018.08.21.18.51.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 18:51:47 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 21 Aug 2018 21:51:42 -0400 References: To: mls@ietf.org In-Reply-To: Message-Id: <3A9E2401-3173-4932-A461-0D5599AD745A@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] VENUE CHANGE: Re: MLS Working Group Interim Meeting - registration required X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 01:51:51 -0000 > On Aug 15, 2018, at 18:23, Sean Turner wrote: >=20 > You will have seen the interim meeting request recently sent to the = list [0]. Once Ben (our AD) approves it the official announcement will = be sent to the IETF-Announce and MLS lists. In the meantime, Nick and I = need to get an accurate headcount for those who plan to attend in person = and remotely. The registration link can be found at: > https://github.com/mlswg/wg-materials/tree/master/interim-2018-09 > We will close registration at 2359UTC on 27 August 2018. >=20 > spt >=20 > [0] = https://mailarchive.ietf.org/arch/msg/mls/KYyCx1aX65RGKIpL6atykrcxGsI Please note that we have changed the meeting venue to: INRIA 2 rue Simone IFF Paris 75012 France I have update the WG materials GH repo to reflect this: = https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/README.m= d I=E2=80=99ll post some more hotel related info up tomorrow. spt= From nobody Mon Aug 27 05:52:41 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D87128BAC for ; Mon, 27 Aug 2018 05:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTHsf3uvsGMj for ; Mon, 27 Aug 2018 05:52:37 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 41163124C04 for ; Mon, 27 Aug 2018 05:52:37 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id r37-v6so17831026qtc.0 for ; Mon, 27 Aug 2018 05:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=gwSPxpflN+RkUOjSM8XlSEZUGRhW5LSOhCsapwjY8bg=; b=MaIItCHbK1wtgJqS5aih9T+MmBO1Ad3FZhch4o3n4tAbJqe9AwEMA9YvRBWRXyjE3+ E46hwKBTnDjrgKu5ZQdIqGxGouyGIs5TlPBBIifMAJakkav7nT/+GW6rXkyQ1q8C8x3T CAxi+3o4yrCwplOG5E21LqsNJwEEq0sz6XqME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=gwSPxpflN+RkUOjSM8XlSEZUGRhW5LSOhCsapwjY8bg=; b=snGAASuSdw2gR7W74eqHQzUYWqu7+70MN18RzNgfqajicVC5nzLHLpdWzX9qWZhX1/ mkkbzd9rGJcGhZaBZc9qg78+swrwbc4gE6mx8G8ZJ99OYbCXXNoRaOMUqy4MXCfY7plg 7dNdR1OSg8mtF6LNw+h8iVD5GvU/pb7hJCjkgNUAO/4wSxrnc0ih3qSMpf8HkvTG5Qyp gV/MGHMBOhJ+LWfOy36dT6pih9n4I/feglHKSh74d8qMp5dRo7FyjVBSVNQB2V0OQeil zAvO2MXDcDAkwMhej78tMUV5jPL8XIM4NWt0jDe+qxa7YS0LSDIu9hxnvv1GDSAtU+3P 9CRA== X-Gm-Message-State: APzg51CwVLTic7O/aNVSpLMMTxSN1KJ/5x4myJQwj8oKSM6ixpgqd1on 8LjKBeTaMC0gcBDfmzMTuCDAZY4i4do= X-Google-Smtp-Source: ANB0VdYu6C1/iER75EwzqxONWzr/q3CzG5LGmG1cAFrbfBiobD1F4JxTazNLwy65xjCXx7i41dvtVw== X-Received: by 2002:ac8:2dd4:: with SMTP id q20-v6mr14252284qta.178.1535374355966; Mon, 27 Aug 2018 05:52:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id m12-v6sm8957081qkl.54.2018.08.27.05.52.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 05:52:35 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 27 Aug 2018 08:52:33 -0400 References: To: mls@ietf.org In-Reply-To: Message-Id: <254AFA9A-3825-40FA-84FD-891A3A9BC306@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] REMINDER: Re: MLS Working Group Interim Meeting - registration required X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 12:52:39 -0000 > On Aug 21, 2018, at 08:39, Sean Turner wrote: >=20 >=20 >> On Aug 15, 2018, at 18:23, Sean Turner wrote: >>=20 >> You will have seen the interim meeting request recently sent to the = list [0]. Once Ben (our AD) approves it the official announcement will = be sent to the IETF-Announce and MLS lists. In the meantime, Nick and I = need to get an accurate headcount for those who plan to attend in person = and remotely. The registration link can be found at: >> https://github.com/mlswg/wg-materials/tree/master/interim-2018-09 >> We will close registration at 2359UTC on 27 August 2018. >>=20 >> spt >>=20 >> [0] = https://mailarchive.ietf.org/arch/msg/mls/KYyCx1aX65RGKIpL6atykrcxGsI >=20 > A friendly reminder to register for the September Interim. Another friendly reminder. Karthik also provided some possible hotels chains with locations near = INRIA=E2=80=99s offices. Please check out the updated wg-materials = page: = https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/README.m= d spt= From nobody Tue Aug 28 11:19:44 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30403130E15 for ; Tue, 28 Aug 2018 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 WTpElhLatWoM for ; Tue, 28 Aug 2018 11:19:40 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42C6130E14 for ; Tue, 28 Aug 2018 11:19:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.53,300,1531778400"; d="scan'208,217";a="344000517" Received: from corp-nat.fw1.untrust.mtv2.mozilla.net (HELO [10.252.25.87]) ([63.245.221.198]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 20:19:36 +0200 From: Benjamin Beurdouche Content-Type: multipart/alternative; boundary="Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <77627DC5-FEB9-4EF9-B2BA-F8786DB22C4D@inria.fr> Date: Tue, 28 Aug 2018 11:19:34 -0700 To: ML Messaging Layer Security X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] Follow-up and moving forward on Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 18:19:43 -0000 --Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Message Protection is one of the important parts of MLS that has = currently been left out of the specifications as we were focusing on the establishment = of a group secret. There are a few questions we now need to answer about message = protection: A. What does the Application Key Schedule look like. This the key point = of attention as it will influence: - Strength of the cryptographic security properties we typically get for = secrets and messages: FS and PCS; - Performance and complexity for communication/latency/storage; - Difficulty to prove the cryptographic security properties we want with = the tools that currently exist; - Difficulty to implement securely. B. Encryption algorithms and traffic analysis protection I expect these aspects to be less controversial in the sense that there = is nothing new here, modern protocols use AEAD primitives such as AES-GCM and = Chacha20Poly1305. We also have to deal with nonce-reuse protection. The idea of this email is not to debate the details now but to make = progress on what is missing in the draft. Overall, I believe that we need to move forward towards MLS being = "feature complete", which is an important step in our process. --- I have been working on some initial text [0] for message protection, = with input from Richard, Karthik and Ekr. Assumptions in that text are, in my opinion, reasonably conservative and = I believe it could be merged as an initial text. As I said at the IETF meeting, we believe multiple variants of the = Application Key Schedule are possible: 1. a per-participant chaining of the Application Secret (hash forward = the secret and derive new keys/nonce per App message) 2. a group chaining of the Application Secret (under the same epoch = secret, each sender hash forward the current group Application Secret) 3. no chaining of the Application Secret (each sender update leaf to get = a new Epoch Secret, Application Secret and AEAD keys for each message) each having a different security/async properties. The PR [0] suggest the use of the classical per-participant chaining = with as it is a reasonably well-known construct. I also didn=E2=80=99t recall any specific opposition to that = scheme from the meeting. The PR also proposes that padding the plaintext of Application messages = SHOULD be done to at least provide some minimal protection of the plaintext length against traffic = analysis; one of the two mandatory-to-implement AEAD constructions MUST be used. Signatures are the way to authenticate a participant in the existing = draft, and I didn=E2=80=99t change that as we can revisit separately. The signature is included in the plaintext for = privacy as there is an implicit weak group membership property provided by the existing design: only legitimate = members of the group can decrypt the Application message (because only they can compute the current AEAD = keys) and look at the *optionally signed* Application message plaintext. --- When we have a base design that is good enough, we can then start = looking at formal security analysis of the composition between the Group =E2=80=9CKey" Establishment = mechanism and the Message Protection proposed mechanisms. After speaking with many people offline, it feels like it would be a = good solution to merge this PR as a first step so that we can start working on sub-components separately. *In no way I feel that the choices for this PR should be the definitive = ones for MLS.* I can make sure to adjust the PR if there are strong opinions on why we = shouldn=E2=80=99t merge something. What do people think and would the mailing list be ok with proceeding = this way ? : ) Best, Benjamin [0] https://github.com/mlswg/mls-protocol/pull/54 = --Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all,

Message Protection is = one of the important parts of MLS that has currently been
left out of the specifications as we were focusing on the = establishment of a group secret.

There are a few questions we now need = to answer about message protection:

A. What does the Application Key = Schedule look like. This the key point of attention as it will = influence:
- Strength of the cryptographic security = properties we typically get for secrets and messages: FS and = PCS;
- Performance and complexity for = communication/latency/storage;
- Difficulty to = prove the cryptographic security properties we want with the tools that = currently exist;
- Difficulty to implement = securely.

B. = Encryption algorithms and traffic analysis protection
I expect these aspects to be less controversial in the sense = that there is nothing new here,
modern protocols = use AEAD primitives such as AES-GCM and Chacha20Poly1305.
We also have to deal with nonce-reuse protection.

The idea of this email = is not to debate the details now but to make progress on what is missing = in the draft.
Overall, I believe = that we need to move forward towards MLS being "feature = complete",
which is an important step in our = process.

---

I have been working on some initial text [0] = for message protection, with input from Richard, Karthik and = Ekr.
Assumptions in that text are, in my opinion, = reasonably conservative and I believe it could be
merged as an initial text.

As I said at the IETF meeting, we = believe multiple variants of the Application Key Schedule are = possible:
1. a = per-participant chaining of the Application Secret (hash forward the = secret and derive new keys/nonce per App message)
2. = a group chaining of the Application Secret (under the same epoch secret, = each sender hash forward the current group Application Secret)
3. no chaining of the Application Secret (each sender update = leaf to get a new Epoch Secret, Application Secret and AEAD keys for = each message)
each having a different = security/async properties.

The PR [0] suggest the use of the = classical per-participant chaining with as it is a reasonably = well-known
construct. I also didn=E2=80=99t recall = any specific opposition to that scheme from the meeting.

The PR also proposes = that padding the plaintext of Application messages SHOULD be done to at = least
provide some minimal protection of the = plaintext length against traffic analysis; one of the two
mandatory-to-implement AEAD constructions MUST be = used.

Signatures= are the way to authenticate a participant in the existing draft, and I = didn=E2=80=99t change that as we can
revisit = separately. The signature is included in the plaintext for privacy as = there is an implicit weak group
membership property = provided by the existing design: only legitimate members of the group = can decrypt
the Application message (because only = they can compute the current AEAD keys) and look at
the *optionally signed* Application message = plaintext.

---

When we have a base design that is good = enough, we can then start looking at formal security analysis
of the composition between the Group =E2=80=9CKey" = Establishment mechanism and the Message Protection
proposed mechanisms.

After speaking with many people = offline, it feels like it would be a good solution to merge this PR = as
a first step so that we can start working on = sub-components separately.
*In no way I feel that = the choices for this PR should be the definitive ones for = MLS.*
I can make sure to adjust the PR if there are = strong opinions on why we shouldn=E2=80=99t merge something.

What do people think and = would the mailing list be ok with proceeding this way ? : )

Best,
Benjamin

[0] https://github.com/mlswg/mls-protocol/pull/54


= --Apple-Mail=_92E68240-4AAC-490A-9C4C-EC2094C72C30-- From nobody Thu Aug 30 10:16:53 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC2130DE6 for ; Thu, 30 Aug 2018 10:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjHxH1baMhtJ for ; Thu, 30 Aug 2018 10:16:49 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA001130DE8 for ; Thu, 30 Aug 2018 10:16:49 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id d4-v6so11130531qtn.13 for ; Thu, 30 Aug 2018 10:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=692ZhBHFPHT663OQiInKn0WDRKqlDGFiMnN9b2ObJFg=; b=lW5idHAL+3PH8ftdB8h05BkMaOekgF63gc7Q6IQRGf6GqpFcv/xxMbDe9kp25O6K2I B5RNCn3CCo1dlvAj7nW5SaqOFds8NHum0pV7DkxmXhULS/F/MG5B8vfQU6WPJoEoH31x pePpTURPyrylONk/hPPQ8WK1RDxbPsLmLGV+o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=692ZhBHFPHT663OQiInKn0WDRKqlDGFiMnN9b2ObJFg=; b=OR06+7395kHvphi1L6UJbsvAhBD113bKe3fy0OBXzT5Dcm9f+XLyEst0sA3Rw16Sxg p13Xq8zsq/ldij0C+tIhdeyk793Dc3Umim8TIm7Xs3d6lPpI6TN6Uq5+4f6tb9YYEg5v U2z1iUXYMRQZ/fzaVakiwvLqOSH2Kgu+AwM2m6rNZFeu1LRYdrFl+H8mnjaWGpHU+Sxs OI3SXgNl1smQnJuT5FsDcnu9PuMjKydyLSf1E8BNbr9xnQcCyYnBMP0Z0kdQVTJJmZHV PXJ0O0C5aMnvBC8CgAhtc9XRbKZz37CuRPc9HfOjX9/2Zkl0lTn53FEGR6NHkTm0zy40 2sWg== X-Gm-Message-State: APzg51AC+5m/hbYvux+nTis0jZivo2MAaDbJqYUOiD+raYJJOGtfh00E bfZVCkLl1mI4XQXM3FL3Tl/bKX8VOUc= X-Google-Smtp-Source: ANB0VdZyM2rocBwhamtMlEqqAE0IXPUJg1/Q4+fpG7AaYxtfWQG1407u+QDfOXk9bBgUMP1ZS0BJaA== X-Received: by 2002:a37:6884:: with SMTP id d126-v6mr12259245qkc.215.1535649408645; Thu, 30 Aug 2018 10:16:48 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id i15-v6sm5101274qta.37.2018.08.30.10.16.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 10:16:47 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 30 Aug 2018 13:16:46 -0400 References: <254AFA9A-3825-40FA-84FD-891A3A9BC306@sn3rd.com> To: mls@ietf.org In-Reply-To: <254AFA9A-3825-40FA-84FD-891A3A9BC306@sn3rd.com> Message-Id: <547C25BE-9068-4D7A-8823-07F301977A57@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] REMINDER: Re: MLS Working Group Interim Meeting - registration required X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 17:16:52 -0000 > On Aug 27, 2018, at 08:52, Sean Turner wrote: >=20 >=20 >=20 >> On Aug 21, 2018, at 08:39, Sean Turner wrote: >>=20 >>=20 >>> On Aug 15, 2018, at 18:23, Sean Turner wrote: >>>=20 >>> You will have seen the interim meeting request recently sent to the = list [0]. Once Ben (our AD) approves it the official announcement will = be sent to the IETF-Announce and MLS lists. In the meantime, Nick and I = need to get an accurate headcount for those who plan to attend in person = and remotely. The registration link can be found at: >>> https://github.com/mlswg/wg-materials/tree/master/interim-2018-09 >>> We will close registration at 2359UTC on 27 August 2018. >>>=20 >>> spt >>>=20 >>> [0] = https://mailarchive.ietf.org/arch/msg/mls/KYyCx1aX65RGKIpL6atykrcxGsI >>=20 >> A friendly reminder to register for the September Interim. >=20 > Another friendly reminder. >=20 > Karthik also provided some possible hotels chains with locations near = INRIA=E2=80=99s offices. Please check out the updated wg-materials = page: >=20 > = https://github.com/mlswg/wg-materials/blob/master/interim-2018-09/README.m= d >=20 We=E2=80=99ve closed the interim registration. We=E2=80=99ve got 18 = registered for in-person and 6 for remote. spt