From nobody Mon Jul 1 15:12:45 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7F3120180 for ; Mon, 1 Jul 2019 15:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 CmQruRlIUTwZ for ; Mon, 1 Jul 2019 15:12:38 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406C91200E7 for ; Mon, 1 Jul 2019 15:12:38 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id j19so15131903otq.2 for ; Mon, 01 Jul 2019 15:12:38 -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=UAPWFWaLJluuAsT/oyEdKMusBfFszTpWqZfm4VapgcQ=; b=M/MHkRvqLIVy1i6tdsG+FWxQ9c68sEpBvloS2UW+OHwabAqwNCeItGEZ8v1F00DT7M lL4yHkcqZHut0tXxUSjNzCkeE6k1ySmUoYpeCCuAt+FlHTAL8QM1JkLdF+loMAUsBepc 09C24vzY2WcgT9AE+rVWununKIOqfqznuMp492m7HnfcoBW6FDpQw+sRXqgMvZq/kPRq RApRn3Z9qMtZM+Gyl/3239Xy0+lBybfXEOv9ETSoL9RySXLwkiAGu1kvhv2UswYRV5Yl U0J2mm4Ow7cnLtbc/Asjw4R5nCz5p0w4xij6Wnx7FIvOXBNN+7bZMH068F3AN/h6HK67 eUjg== 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=UAPWFWaLJluuAsT/oyEdKMusBfFszTpWqZfm4VapgcQ=; b=e8jrrMe8mW2j01zbOg8MBvoQxZ+E7EffpHbAcLIhneoN8jYAhzGUZCSDpGtZC8SAIa rC/L0evLfu0DEyhi+384yDJFiMRXCrhAfgFk3F0Z8s8vu96mmuCdOqKai0ohMFhM8LlX JHsjHKNYxFV29DNnmexudctmu2jS5W4ex+GijdWrbv9067qz8DjRJk58KBB0uDJfI6J4 XTUz7fuHttQPSU9BMFSZn/NtjL+e2UiwrEavLNLx7UkhkFihKnx/rYtv9YL3o9J/8NLP dGsi9G3xz2JKXXzmBRTUrNJSFVeKu8dMbVEPY6A8Ov3Zr/yqLeNaFSmnlLZ7fBYz+5tu VccQ== X-Gm-Message-State: APjAAAWne4nJqUsmKvxp58PjhtOdpCqVtzgcmTG6u+LTZNMwxMDFMFrN uj7ppTCXjwxasBKQFtjQyoIA0uVnyT1RYW0jAX0UPpLTqtykeg== X-Google-Smtp-Source: APXvYqwsAnjzywhj+8jgj/Yb3/0VTKt9FKODnjXJdaURUC/cfr6+hJLQYM9uLIEn9AkZiF4su64Vpsf7szt77bXm9fY= X-Received: by 2002:a05:6830:1542:: with SMTP id l2mr1773084otp.241.1562019157517; Mon, 01 Jul 2019 15:12:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 1 Jul 2019 18:12:22 -0400 Message-ID: To: Joel Alwen Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000043dba058ca5ed6c" Archived-At: Subject: Re: [MLS] New Tree-based Application Key Schedule X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 22:12:43 -0000 --000000000000043dba058ca5ed6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Joel, Just reviewed your PR (https://github.com/mlswg/mls-protocol/pull/146). Sorry for the long delay; the impending Internet-Draft deadline in a week has spurred the authors back into action. Overall, this seems pretty much right. My major concern is that the mechanism seems a bit heavy-weight, in that it pulls in a bunch of context in the key derivations. It seems like we could get away with a much simpler scheme (as I've outlined in the review comments), but if you think there are reasons we need the extra context, I'm listening. Cheers, --Richard On Fri, Apr 12, 2019 at 2:31 PM Joel Alwen wrote: > Hey Richard, > > Thanks for your response! For the deletion schedule I think there's no > problem with out-of-order messaging. Basically if a secret is consumed th= en > just before deleting it derive any (unconsumed) children values that may > still be needed. > > E.g. if in a ratchet msg j arrives before j' key/nonce for deleteing secret j'. The same goes for any other (now > consumed) secrets between j and j' in that ratchet. That way if any of > those msgs arrive one can still decrypt them. But if there's a state > leakage nothing useful for decrypting the j-th msg is leaked since keys & > nonces are dead ends in the derivation hierarchy. > > Similarly in the AS Tree if a node's secret is marked as consumed then > just before deleting it derive and store the secrets of its unconsumed > child. > > - Jo=C3=ABl > > > On Fri, 12 Apr 2019, 20:14 Richard Barnes, wrote: > >> Hey Jo=C3=ABl, >> >> Thanks a lot for putting this together. I'll review the PR shortly. In >> case other folks need it, here's the link for the PR: >> >> https://github.com/mlswg/mls-protocol/pull/146 >> >> Overall, I think this is a sane idea. The thing that really sells it to >> me is your observation that the AS tree has the same structure as the >> ratchet tree, which points to a very elegant implementation approach: >> >> - Add a field to each ratchet tree node to store an app secret or nil >> - On epoch update, clear out all the app secrets in the tree, and set th= e >> root node's app secret to the epoch app secret >> - When you need an app secret for a leaf (to encrypt or decrypt) >> - Search toward the root until you find a node with an app secret set >> - Work back out to the leaf, deriving the two app secrets for the >> children and deleting the parent app secret >> >> On the "deletion schedule" idea: I might be wrong, but I don't think >> we're going to be able to be super tight here. Applications are going t= o >> want to be able to tolerate out-of-order messages, in which case you're >> going to want to keep around a parent secret after one or more of its >> descendants have been consumed. I like the "consumed" idea and >> terminology, we just might have to apply it with a bit of flexibility. >> >> On the "context" question: I don't really feel strongly here. The >> current scheme doesn't really fold in any group context at all, which is >> consistent with what TLS does [1]. Given that that's simpler, I might b= e >> tempted to keep things that way until we find that there's some deficien= cy. >> >> --Richard >> >> [1] https://tools.ietf.org/html/rfc8446#section-7.2 >> >> >> On Fri, Apr 12, 2019 at 10:07 AM Joel Alwen wrote: >> >>> Hey everyone, >>> >>> I've submitted a PR implementing a tree-based application key schedule >>> based on the ideas proposed by Benjamin Beurdouche, Sandro Corretti, >>> Yevgeniy Dodis and myself. >>> >>> On the one hand it allows for easy handling of concurrent / out of orde= r >>> message delivery within an epoch (as each group member has their own >>> independent symmetric ratchet). On the other hand it avoids having to d= o >>> linear amounts of hashing and key/nonce storage as soon the moment the >>> first message in an epoch is sent (as would be the case if we >>> immediately seed all sender ratchets directly from application_secret a= s >>> in the 03 draft). >>> >>> Basic idea: >>> - The Application Key Schedule consists of a left balanced binary tree >>> of secrets (the "AS Tree") and one symmetric ratchet per group member. >>> The AS Tree has the same node/edge structure as the ratchet tree for >>> that epoch. Members are assigned the same leaves. >>> - Each node in the AS Tree is assigned a secret. The root's secret =3D >>> application_secret. The secrets of children are derived from that of >>> their parent. >>> - The secret of a leaf is the initial secret of a symmetric hash >>> ratchet. The ratchet generates the key/nonce sequence used by the leaf'= s >>> group member to encrypt messages during that epoch. >>> >>> Other comments: >>> - I included a "Deletion Schedule": keys, nonces are 'consumed' if they >>> are used to encrypt or successfully decrypt a message. Secrets are >>> 'consumed' if a value derived from them are consumed. Any consumed valu= e >>> must be immediately deleted (for reasons of forward secrecy). >>> - Maybe the most contentious issue: I was very generous with contexts >>> for all calls to HKDF. E.g. I included Hash(GroupState_[n]) in the >>> context of every call. I doubt its needed to prove security against mor= e >>> coarse adversarial models (e.g. ones that only do all-or-nothing state >>> leakage). Still, as a matter of the "defense in depth" principle I thin= k >>> including as much relevant context as possible during all key/secret >>> derivation is a good idea. Albeit only as long as the price (in >>> computation, complexity, etc) is not too high. To that end, I used >>> Hash(GroupState_[n]) instead of GroupState_[n] directly in the context >>> as it is much short, needs only to be computed once at the start of the >>> epoch and can then be used to very cheaply to construct any context >>> needed for the rest of the new schedule. >>> >>> Curious what you all think! >>> - Jo=C3=ABl >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> --000000000000043dba058ca5ed6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Joel,

Just reviewed your= PR (https://git= hub.com/mlswg/mls-protocol/pull/146).=C2=A0 Sorry for the long delay; t= he impending Internet-Draft deadline in a week has spurred the authors back= into action.

Overall, this seems pretty much = right.=C2=A0 My major concern is that the mechanism seems a bit heavy-weigh= t, in that it pulls in a bunch of context in the key derivations.=C2=A0 It = seems like we could get away with a much simpler scheme (as I've outlin= ed in the review comments), but if you think there are reasons we need the = extra context, I'm listening.

Cheers,
--Richard



On Fri, Apr 12, 2019 at = 2:31 PM Joel Alwen <jalwen@wickr.com= > wrote:
=
Hey Richard,

Thanks for your response! For the deletion schedule I think there'= ;s no problem with out-of-order messaging. Basically if a secret is consume= d then just before deleting it derive any (unconsumed) children values that= may still be needed.=C2=A0

E.g. if in a ratchet msg j arrives before j'<j then first derive= the j'-th key/nonce for deleteing secret j'. The same goes for any= other (now consumed) secrets between j and j' in that ratchet. That wa= y if any of those msgs arrive one can still decrypt them. But if there'= s a state leakage nothing useful for decrypting the j-th msg is leaked sinc= e keys & nonces are dead ends in the derivation hierarchy.=C2=A0
<= div dir=3D"auto">
Similarly in the AS Tree if a = node's secret is marked as consumed then just before deleting it derive= and store the secrets of its unconsumed child.

=
-=C2=A0Jo=C3= =ABl


On Fri, 12 Apr 2019, 20:14 Richard Barnes, <rlb@ipv.sx&g= t; wrote:
Hey Jo=C3=ABl,
=
Thanks a lot for putting this together.=C2=A0 I'll revie= w the PR shortly.=C2=A0 In case other folks need it, here's the link fo= r the PR:


Overall, I think t= his is a sane idea.=C2=A0 The thing that really sells it to me is your obse= rvation that the AS tree has the same structure as the ratchet tree, which = points to a very elegant implementation approach:

= - Add a field to each ratchet tree node to store an app secret or nil
- On epoch update, clear out all the app secrets in the tree, and = set the root node's app secret to the epoch app secret
- When= you need an app secret for a leaf (to encrypt or decrypt)
=C2=A0= - Search toward the root until you find a node with an app secret set
=C2=A0 - Work back out to the leaf, deriving the two app secrets for = the children and deleting the parent app secret

On= the "deletion schedule" idea: I might be wrong, but I don't = think we're going to be able to be super tight here.=C2=A0 Applications= are going to want to be able to tolerate out-of-order messages, in which c= ase you're going to want to keep around a parent secret after one or mo= re of its descendants have been consumed.=C2=A0 I like the "consumed&q= uot; idea and terminology, we just might have to apply it with a bit of fle= xibility.

On the "context" question: I d= on't really feel strongly here.=C2=A0 The current scheme doesn't re= ally fold in any group context at all, which is consistent with what TLS do= es [1].=C2=A0 Given that that's simpler, I might be tempted to keep thi= ngs that way until we find that there's some deficiency.

=
--Richard



On F= ri, Apr 12, 2019 at 10:07 AM Joel Alwen <jalwen@wickr.com> wrote:
Hey everyone,

I've submitted a PR implementing a tree-based application key schedule<= br> based on the ideas proposed by Benjamin Beurdouche, Sandro Corretti,
Yevgeniy Dodis and myself.

On the one hand it allows for easy handling of concurrent / out of order message delivery within an epoch (as each group member has their own
independent symmetric ratchet). On the other hand it avoids having to do linear amounts of hashing and key/nonce storage as soon the moment the
first message in an epoch is sent (as would be the case if we
immediately seed all sender ratchets directly from application_secret as in the 03 draft).

Basic idea:
- The Application Key Schedule consists of a left balanced binary tree
of secrets (the "AS Tree") and one symmetric ratchet per group me= mber.
The AS Tree has the same node/edge structure as the ratchet tree for
that epoch. Members are assigned the same leaves.
- Each node in the AS Tree is assigned a secret. The root's secret =3D<= br> application_secret. The secrets of children are derived from that of
their parent.
- The secret of a leaf is the initial secret of a symmetric hash
ratchet. The ratchet generates the key/nonce sequence used by the leaf'= s
group member to encrypt messages during that epoch.

Other comments:
- I included a "Deletion Schedule": keys, nonces are 'consume= d' if they
are used to encrypt or successfully decrypt a message. Secrets are
'consumed' if a value derived from them are consumed. Any consumed = value
must be immediately deleted (for reasons of forward secrecy).
- Maybe the most contentious issue: I was very generous with contexts
for all calls to HKDF. E.g. I included Hash(GroupState_[n]) in the
context of every call. I doubt its needed to prove security against more coarse adversarial models (e.g. ones that only do all-or-nothing state
leakage). Still, as a matter of the "defense in depth" principle = I think
including as much relevant context as possible during all key/secret
derivation is a good idea. Albeit only as long as the price (in
computation, complexity, etc) is not too high. To that end, I used
Hash(GroupState_[n]) instead of GroupState_[n] directly in the context
as it is much short, needs only to be computed once at the start of the
epoch and can then be used to very cheaply to construct any context
needed for the rest of the new schedule.

Curious what you all think!
- Jo=C3=ABl

_______________________________________________
MLS mailing list
MLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000043dba058ca5ed6c-- From nobody Mon Jul 8 14:15:19 2019 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 D65EA1201D0; Mon, 8 Jul 2019 14:14:58 -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.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <156262049880.865.6318837346726262883@ietfa.amsl.com> Date: Mon, 08 Jul 2019 14:14:58 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-07.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 21:15:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Benjamin Beurdouche Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-07.txt Pages : 56 Date : 2019-07-08 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-protocol-07 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 14:28:24 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C541200F9 for ; Mon, 8 Jul 2019 14:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EypHcrHXFXNz for ; Mon, 8 Jul 2019 14:28:07 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2721202F5 for ; Mon, 8 Jul 2019 14:28:07 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id r21so2269181otq.6 for ; Mon, 08 Jul 2019 14:28:07 -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=ejxlEXg0Db89/jw4qRabO4VcpQKGxFtMLWDqedpBnf8=; b=S81Fwk1qm2KfuSidb6/gNldgbTma4CoT2VNgr5TNI1cq4cdfyfFQS/YJtmcTYU9Z32 sv85ZnseGyHz+zuD6Z5xAYaC5RH9+E+1FfF5BGoprdYbd7qJTojNUTF92AQiLKM2S6Cx E57P/wSoAC0Wy+j6zgqpduCk2/VhTQL7LA9F5uX0F2q/m+VAchQaqeyxuWTCLJq7j3ha ZSWBi3c/1hsbHRUKMTG5Cr/SPGw4BeAsHK9riKcG5N/MyKmxwxUKXGr3A3HBgbVUACp/ FprUzqKnsrfSrlviuiPO5PPhC9WBIa4riTGVMamOYuRDs4s6z9jKaPGfD2ZAXitvsqah z/Pw== 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=ejxlEXg0Db89/jw4qRabO4VcpQKGxFtMLWDqedpBnf8=; b=I73Cu9VzzQvkVXceWEaHAoYgOa5WtBJA94M+x2vC6p/Ns8fxNHUXwu2XhP9thhS7pE E4JmGvU8YYHFoe56i8TcYwOAIIHrx8jS3VVAmQLmJoJ9rSd9wncipvCcqdBq9LQk5EWu zmxzb+yP9Tq7oQM00GV8ZYaLe5TQhYPVdwlaPaqVxnB2a3oEtqKH3q3A0LeA7+vFnBxD kTyuGC7LprWKcVLe368HgdfeKyOHw1/EzolrFWy+U97Rk5vqDLCc1n450uoWfbJsLqRo sIm1I2+M8zvz2jpUFZnP/j/ZZ02c1ufMs5nQqGYueiCly+QZYigKIj3O3irCZnO49WIZ zOOg== X-Gm-Message-State: APjAAAUK4oAAIEUy52kL8H4zT4W0dDOsn87j1w5r9gttF5uNSpP8N+ut eZaYkC8tEHLKgp4hYyVPcwDeySJXfcf7+48s0PUm9pjHh5A= X-Google-Smtp-Source: APXvYqyFE9ziYriLQeHa9Ihwwc4E+bm/YG9BWv8zlaSIIxFf1d7LwZXLy/oeEqQiZXlRTPyk4eNFzVh4Izyj6g2pweE= X-Received: by 2002:a05:6830:1542:: with SMTP id l2mr16826490otp.241.1562621286277; Mon, 08 Jul 2019 14:28:06 -0700 (PDT) MIME-Version: 1.0 References: <156262049880.865.6318837346726262883@ietfa.amsl.com> In-Reply-To: <156262049880.865.6318837346726262883@ietfa.amsl.com> From: Richard Barnes Date: Mon, 8 Jul 2019 17:27:46 -0400 Message-ID: To: Messaging Layer Security WG Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="000000000000aff7c8058d321e7b" Archived-At: Subject: Re: [MLS] I-D Action: draft-ietf-mls-protocol-07.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 21:28:16 -0000 --000000000000aff7c8058d321e7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, New official version. Changes are in the changelog. They're mainly bugfixes and cleanup. The cool new thing is the tree-based app key schedule that Jo=C3=ABl designed, and the secret consumption rules. --Richard On Mon, Jul 8, 2019 at 5:17 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Messaging Layer Security WG of the IETF. > > Title : The Messaging Layer Security (MLS) Protocol > Authors : Richard Barnes > Benjamin Beurdouche > Jon Millican > Emad Omara > Katriel Cohn-Gordon > Raphael Robert > Filename : draft-ietf-mls-protocol-07.txt > Pages : 56 > Date : 2019-07-08 > > Abstract: > Messaging applications are increasingly making use of end-to-end > security mechanisms to ensure that messages are only accessible to > the communicating endpoints, and not to any servers involved in > delivering messages. Establishing keys to provide such protections > is challenging for group chat settings, in which more than two > clients need to agree on a key but may not be online at the same > time. In this document, we specify a key establishment protocol that > provides efficient asynchronous group key establishment with forward > secrecy and post-compromise security for groups in size ranging from > two to thousands. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mls-protocol-07 > https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mls-protocol-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000aff7c8058d321e7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

New official versio= n.=C2=A0 Changes are in the changelog.=C2=A0 They're mainly bugfixes an= d cleanup.=C2=A0 The cool new thing is the tree-based app key schedule that= Jo=C3=ABl designed, and the secret consumption rules.

=
--Richard

On Mon, Jul 8, 2019 at 5:17 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Messaging Layer Security WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The Messaging Layer Security (MLS) Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rich= ard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Benjamin Beurdouche
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jon Millican
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Emad Omara
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Katriel Cohn-Gordon
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Raphael Robert
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mls-protocol-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 56
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-07-08

Abstract:
=C2=A0 =C2=A0Messaging applications are increasingly making use of end-to-e= nd
=C2=A0 =C2=A0security mechanisms to ensure that messages are only accessibl= e to
=C2=A0 =C2=A0the communicating endpoints, and not to any servers involved i= n
=C2=A0 =C2=A0delivering messages.=C2=A0 Establishing keys to provide such p= rotections
=C2=A0 =C2=A0is challenging for group chat settings, in which more than two=
=C2=A0 =C2=A0clients need to agree on a key but may not be online at the sa= me
=C2=A0 =C2=A0time.=C2=A0 In this document, we specify a key establishment p= rotocol that
=C2=A0 =C2=A0provides efficient asynchronous group key establishment with f= orward
=C2=A0 =C2=A0secrecy and post-compromise security for groups in size rangin= g from
=C2=A0 =C2=A0two to thousands.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-mls-protocol/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mls-pro= tocol-07
https://datatracker.ietf.org/doc/htm= l/draft-ietf-mls-protocol-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-mls-protocol-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000aff7c8058d321e7b-- From nobody Thu Jul 11 06:31:40 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683691200FB for ; Thu, 11 Jul 2019 06:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qC4BRK_MR7q6 for ; Thu, 11 Jul 2019 06:31:37 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 F16A61200A3 for ; Thu, 11 Jul 2019 06:31:36 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id k9so4107212vso.5 for ; Thu, 11 Jul 2019 06:31:36 -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=hsBjknIn6Kby2V5G1fv9zgrWTcznqq4AY6xmSmBfSjc=; b=AkIliN+zRSCQxzX+Gc9SFplusgdCTec+xNlvJ+ucJ0tL7nob+jZT1fkHQGZI6Uj9nc HtXdN88GGfUTK3+n48mpe1s1WzhURDGpQvy1nmxObw1RfKpgkYBa9QQwEw1drSx0oYhx v4UT5TEcX/N1oOEnwMHOHbTEzRZ4em5TC28vU= 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=hsBjknIn6Kby2V5G1fv9zgrWTcznqq4AY6xmSmBfSjc=; b=qk5O0AtS3EYZj81EdBTLo6xXJUdRPlC7vjTUTAEBJeJCmDv4F5VXC+Isp8jJvQirOI k4c0gE6lRdyqAarBq60W4u4XxnnOV65qkuG3N7EnclSLUj+NYKdpsktSA5L54wBr38zC 9WgcUhuEBMMMVDRzI9/Btb4XPCfLybULkSlzv5pCaBka91FrvlebQy2g19pa/JH8WAzN 0HnRm21nkmKoP62w02ViBcBD7GS/KA0c5vWOb/w56A7ij8InydScuVNRgXlBxhGin4DW JLiL6lk/XVKHlxYYhnLrgKEpbq9z4NUnVh0RFPKWgrB1iIurh+6Aigs38u1wT9gugwPa cNBg== X-Gm-Message-State: APjAAAWAP/lVsah0C2me1N6D9OcsNQGv94C/enuthYywQjNI1bZJoG7u IL9r76utX9edq8kI4jsT4LuqhXRu X-Google-Smtp-Source: APXvYqyQNPmnqskOzLYz58Ba65yFy4fTmI/DuZ70eTbVe42pFLNkuktQtmUPAj+3FXEOIkHjc2lo0g== X-Received: by 2002:a67:eb93:: with SMTP id e19mr4362733vso.208.1562851895911; Thu, 11 Jul 2019 06:31:35 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id s13sm1373792uaj.6.2019.07.11.06.31.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 06:31:35 -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 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 09:31:34 -0400 References: <324D5227-F4BB-4D87-8426-336856F5ED02@sn3rd.com> To: mls@ietf.org In-Reply-To: <324D5227-F4BB-4D87-8426-336856F5ED02@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] MLS@IETF105: Agenda Topics X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:31:38 -0000 A gentle reminder if you have topics you would like to present please = send them into mls-chairs@ietf.org. Cheers, spt > On Jun 6, 2019, at 15:32, Sean Turner wrote: >=20 > The MLS WG will be meeting @ IETF 105 in Montreal. To help the chairs = get a better handle on how much time we will need for our session, = please send in your agenda requests to mls-chairs@ietf.org. Along with = your request please provide an estimate for how much time you will need. >=20 > Cheers, > Nick and Sean From nobody Wed Jul 24 07:55:01 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177C11200F4 for ; Wed, 24 Jul 2019 07:54:59 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEyyfR3F95NI for ; Wed, 24 Jul 2019 07:54:57 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 3A652120122 for ; Wed, 24 Jul 2019 07:54:57 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id u3so31511737vsh.6 for ; Wed, 24 Jul 2019 07:54:57 -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=ezwISaFwKqx9ZF3B1/2xxe1q2AT+A4MddEeRJotq4GM=; b=l7jFkJPqR5WdFd2fB2Ii5s1hciUS6R/10x7spwPpWhcaY7nxHfuBV6WLMPZOrpEENN 1ry93GAeojri+aHtJo7Jf2xSszJSc8eStJgxdLqRAXRVHHC03y4BQ3F3GwuYnGs8iQ72 joFquoUvDAW3IzV/VDnAvaEaghO3AL/dwmicg= 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=ezwISaFwKqx9ZF3B1/2xxe1q2AT+A4MddEeRJotq4GM=; b=K/GsybBhTXVI/kDLy956zMBMkZz2iIm1LtQXt/9TtitAseQnhKT52T50MuJDbFLL/9 Y9E91KXdb+IA5aGUCWyUf63YJ9+iOttpWIVQ8YX9IYT95rWZvL6ZzwFWZU2Rbo/PlOjD /znmo735IFu4lZVzBjkW0XUhkO05Hw5JNZuUTPfag98D2Y2f8e5nfWuJ+NxKb39W+bDS 7Wv7QKTd24lS989ShCeHB3AIfpCr1GTGH0gu8ZIaB7DdAHqPhjk4kN/KCW6KQQbVcevb O1NXoIiaMdqneOoIkYdzomM/I4/A5O9lu2mfF8ieSCpSONxMKdSAd+qiiNACs63pgP3E 6F6A== X-Gm-Message-State: APjAAAUUuRbu3oGKrluIUiklW3FYyYPZBWuU4kfAc6F2uHPvjHMjRvNw rTEuif25lDiTIJ5TTxqqAKiX5nFeXcFcGcm6LPwUihEag/wpPQ== X-Google-Smtp-Source: APXvYqxJRn5QWUl5Y4wrt5JPkUEsCChUIgUe1Y/sYyqbiUU23R0WXxlRBkJQGDNaM9kJR1zHKWq0pkEaZP+4+8yn0tM= X-Received: by 2002:a67:8e0a:: with SMTP id q10mr29416780vsd.215.1563980095815; Wed, 24 Jul 2019 07:54:55 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Wed, 24 Jul 2019 10:54:38 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000000c3b38058e6e7e13" Archived-At: Subject: [MLS] MLS meeting schedule update for IETF 105 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 14:54:59 -0000 --0000000000000c3b38058e6e7e13 Content-Type: text/plain; charset="UTF-8" Dear WG, The chairs were over-ambitious about the amount of time we requested at IETF 105 considering some of the key draft contributors were unable to attend the meeting in person this time around. There is enough work to discuss in person for at least one of our two sessions, but likely not both. We are considering canceling one of the two sessions. As a reminder, they are Thursday 17:40-19:10 and Friday 10:00-12:00 In order to accommodate our remote participants in Europe, our proposal is to keeping only the Friday session and canceling Thursday's session. Please let the chairs know if there are any strong objections to this proposal. Nick & Sean --0000000000000c3b38058e6e7e13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG,

The chairs were over-ambitious= about=C2=A0the amount of time we requested at IETF 105 considering some of= the key draft contributors were unable to attend the meeting in person thi= s time around. There is enough work to discuss in person for at least one o= f our two sessions, but likely not both.

We are co= nsidering canceling one of the two sessions. As a reminder, they are
<= div>Thursday=C2=A017:40-19:10 and
Friday 10:00-12:00

In order to accommodate our remote participants in Europe,= our proposal is to keeping only the Friday session and canceling Thursday&= #39;s session. Please let the chairs know if there are any strong objection= s to this proposal.

Nick & Sean
--0000000000000c3b38058e6e7e13-- From nobody Wed Jul 24 14:04:41 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C5812060C for ; Wed, 24 Jul 2019 14:04:32 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AyZI9FAo_KwF for ; Wed, 24 Jul 2019 14:04:30 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 2A8EB12066E for ; Wed, 24 Jul 2019 14:04:30 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id r3so32261550vsr.13 for ; Wed, 24 Jul 2019 14:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=g2kwhnoIyAvShyGMb96Y4LPPI+eNi2SdOz1NxSBUS1o=; b=xT+U5LJPpMS1qPyh6Lqv46sJmBtPxDhFhAaKZlWfSBeAHxqzH4krLTfP2qySFu/jNg fm5roQ8JuwuH5u4jqpKsaRyxEuo3Y6p8ucuDk5/jW50zgBhUOOFZ6YMu9CTe4e0gaHUs AOH2aTO5Ns13iGlwLd3wT3vjj21XB4DW9RdHE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=g2kwhnoIyAvShyGMb96Y4LPPI+eNi2SdOz1NxSBUS1o=; b=W5NFGawVr6Cv98GQo+A2EAT76gnm/zRR0RThpjHzuLyVTPtXOQ9B6hIoo80GKDdek8 TKSsz+D+BgLZo1RsxC3lXT2StT2gFoe4jmFzOYAuztBM739nlaK6YY1SdFvrbnpPn5Kv WTyGNaMidz7O1NlSIyMgwI6poKRha8G40LZN8Zcg7H6/qZQ6jxhN4e9dZrHpPV68wwCw FxwMhFMGlzOKNfZkRDzDuN2YB5eSIQGzF+xJEAP8OeNl45IGJdwBX48/99fAqANgfutx 3CKyN+uG/n82jF4Ub1ixQIkUQd+MvdeBMsKJ1snF3ZVcJrPT6LKOAEOYzYoqkkWuh/tb d0aQ== X-Gm-Message-State: APjAAAUBJzRwWIDCXcPDSU8+158mpgR3kyBSoWSWVANc0DNteEZYJzid yYYTp0f15KLaRGYH2hE3DV51CxrI1CeycP5DZqr1MBydcvBZDg== X-Google-Smtp-Source: APXvYqwciSVAIArMV1vkcC6hWTBcVGWJsU/ZUYnXVf4ErppyiV5qVpGrD4c/tr9NP314gYsngugGaA8Y+C8yAJlRZX0= X-Received: by 2002:a67:d39e:: with SMTP id b30mr53187318vsj.212.1564002268753; Wed, 24 Jul 2019 14:04:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Wed, 24 Jul 2019 17:04:17 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000a859a6058e73a739" Archived-At: Subject: Re: [MLS] MLS meeting schedule update for IETF 105 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 21:04:39 -0000 --000000000000a859a6058e73a739 Content-Type: text/plain; charset="UTF-8" Friday it is, see you all there! Nick & Sean On Wed, Jul 24, 2019 at 10:54 AM Nick Sullivan wrote: > Dear WG, > > The chairs were over-ambitious about the amount of time we requested at > IETF 105 considering some of the key draft contributors were unable to > attend the meeting in person this time around. There is enough work to > discuss in person for at least one of our two sessions, but likely not both. > > We are considering canceling one of the two sessions. As a reminder, they > are > Thursday 17:40-19:10 and > Friday 10:00-12:00 > > In order to accommodate our remote participants in Europe, our proposal is > to keeping only the Friday session and canceling Thursday's session. Please > let the chairs know if there are any strong objections to this proposal. > > Nick & Sean > --000000000000a859a6058e73a739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Friday it is, see you all there!

Nick & Sean

On Wed, Jul 24, 2= 019 at 10:54 AM Nick Sullivan <ni= ck@cloudflare.com> wrote:
Dear WG,

The chairs were over-ambitious a= bout=C2=A0the amount of time we requested at IETF 105 considering some of t= he key draft contributors were unable to attend the meeting in person this = time around. There is enough work to discuss in person for at least one of = our two sessions, but likely not both.

We are cons= idering canceling one of the two sessions. As a reminder, they are
Thursday=C2=A017:40-19:10 and
Friday 10:00-12:00
=
In order to accommodate our remote participants in Europe, o= ur proposal is to keeping only the Friday session and canceling Thursday= 9;s session. Please let the chairs know if there are any strong objections = to this proposal.

Nick & Sean
--000000000000a859a6058e73a739--