From nobody Thu Nov 1 19:09:51 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A20B1277C8 for ; Thu, 1 Nov 2018 19:09:50 -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 4mkcIfS8M4wL for ; Thu, 1 Nov 2018 19:09:48 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504A31271FF for ; Thu, 1 Nov 2018 19:09:48 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id n12so759511qkh.11 for ; Thu, 01 Nov 2018 19:09: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:message-id:date :to; bh=u915sbdQbeMRP444Ugpm5ANb0g5l75OBMMPtdKjoiMA=; b=JNzmhcJFtWD14iU58nT8ZeZCcOgzZST28Sy1OZ7r1i2WINcVhIDCVnORXTbdnHv8Xf 6xCePO6eydUMH1j8W2lUfpxMzrnV4g88QJoMSXtIHSVES3NbCM+cD3sqZ3KSVEN825DD y4ulVK0hTnNv41I5ogIjzMbU2hMRjaBVWj5Q4= 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=u915sbdQbeMRP444Ugpm5ANb0g5l75OBMMPtdKjoiMA=; b=eqzHpdB7Yvif81fm//ObiPftL26ZOtVnQ/D5vklxHlBdINVkJufFoTEiNnec8rve9L Q2j/dY6SaITLsOa8b3lxCqaTb7jMN4y26EqvpVKHM4fRt7DNNyETDYe7F0kmHXCCvMJC mE04PRZitwfa02jADjAx0b1a/kJpiedYa2i7pVZn8tGyHLAjBoMofeVv9YVYR2xDBqIQ AG+mXzCtoeyUEpICiXWZmSiZLv8aiLi4DnAr+netuYt1KE+nrBYMYKy8gMdHYU8MaYDj qa0mztE+J9BeWQrFrytCkNTZ2Wtq4I6wPfSmVkZVnQs1vY2+KJtUOx6m50FnYRt+Ud1o OZ0w== X-Gm-Message-State: AGRZ1gK0U5Gp/MRpyHouvOHRk5F6z3ykXagI4qCfrLQbeusLqVYl+y4/ bwPrJaSxTGYLtiBe6SvdhFeSGSBKa/0= X-Google-Smtp-Source: AJdET5fxOeRCRmhM6YhmaLPgrmTTonSb7ix5ATNsvYXeWRlzMHzu8v0n1q+uKOMaxn6WHMDGjiOHoQ== X-Received: by 2002:ac8:6049:: with SMTP id k9mr3776271qtm.243.1541124587174; Thu, 01 Nov 2018 19:09:47 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id l36-v6sm15461698qtc.80.2018.11.01.19.09.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 19:09:46 -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: <6867DCB6-4A74-47F6-BAF3-3B7F82B0FEA0@sn3rd.com> Date: Thu, 1 Nov 2018 22:09:44 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] MLS@IETF103 agenda X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 02:09:50 -0000 The agenda has been uploaded: https://datatracker.ietf.org/meeting/103/materials/agenda-103-mls-00 It can also be found in the GH repo: https://github.com/mlswg/wg-materials/tree/master/ietf103 Note that we have two session scheduled: --------------------------------------------- mls Session 1 (2:00 requested) Monday, 5 November 2018, Afternoon Session II 1610-1810 Room Name: Chitlada 2 size: 250 --------------------------------------------- mls Session 2 (1:00 requested) Thursday, 8 November 2018, Morning Session II 1120-1220 Room Name: Chitlada 1 size: 300 --------------------------------------------- Links for remote participation (meetech, jabber, audio) can be found on = this page: https://datatracker.ietf.org/meeting/agenda/ spt= From nobody Thu Nov 1 19:33:25 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 0D414128A6E for ; Thu, 1 Nov 2018 19:33:23 -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 WLuhGoOwU6oN for ; Thu, 1 Nov 2018 19:33:21 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 F2B951271FF for ; Thu, 1 Nov 2018 19:33:20 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id o89so926325qko.0 for ; Thu, 01 Nov 2018 19:33:20 -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=ejFdCgyfjahQtAIwK6UQJ7Jl3w/6gxcpMNUZC1x7Gqs=; b=WKrTvBMZ2hAJBrjsp5tp15o46ieKdSBtxWHN4cJQqIay/eTpLUCddR9gJfXSGaPgy9 31FpA33x5D/eo20PlVAVL4YDnucm1bMsPjdvyYj+QFb2GSdssucM1yxOyMKq5Wf3xSCj V8emrYzJF8As5gcFFNUKZpOaM3Bfy2akxWVfI= 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=ejFdCgyfjahQtAIwK6UQJ7Jl3w/6gxcpMNUZC1x7Gqs=; b=UqNAqbcwzBjwRsvjA4uR74VkvuCenxNtjvuGue2qD8ZXw9aOlKZy5it7XkRuH8lhAQ AkSzFMrX+7NpUVLTxpp8TrJ1XukCZ5LbMYe1nLc+8yoAf/hhCpdxDb5gTtG58XPeLZlP WfQvG/uJOLNJVzZG5avdeJI2DRaCP0s1a8lBp7KFj7GvWjiqn2z+pa8rOErtIWV2BDfm M1oaqX0+xvvIRlb6zE8HpgKldnBc45NUGL7wB5OcAWgnG1532RQtABAxUnqKbmG8iE36 BYRC73mkCHtJKnymRf9Ckz51D1kzKTL/WOlcm9VR3ljaRWNxXmdYFk0iJ4muHt8bcVhu pX4g== X-Gm-Message-State: AGRZ1gIlv3eQ4fQUirTB2Icx0BegeibmDJGTU4vg2Sne109+7jiT491f NMrh9CtORp0r6DNWUehjNkaBja4udF0= X-Google-Smtp-Source: AJdET5c0NB/PQWTF3h77wZ6YhwWq4kfQlUYdrNnb84sDV7y4vFINj7WSANSBjRJeC86k0QA7Ny6wTg== X-Received: by 2002:ac8:7543:: with SMTP id b3-v6mr9015526qtr.150.1541126000068; Thu, 01 Nov 2018 19:33:20 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id 39-v6sm24301532qto.14.2018.11.01.19.33.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 19:33:19 -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: Thu, 1 Nov 2018 22:33:18 -0400 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Raphael Robert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] IETF 103 Hackathon X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 02:33:23 -0000 If possible could we get like a 5min summary of how it went during = Monday=E2=80=99s session? spt > On Oct 22, 2018, at 12:36, Raphael Robert wrote: >=20 > Hey all, >=20 > The IETF 103 Hackathon is approaching and I'd like to invite anyone = who is interested in hacking early MLS implementations to participate! >=20 > A list of current implementations as well as some initial test vectors = can be found here: https://github.com/mlswg/mls-implementations >=20 > It would be interesting to hear who else will participate and if there = are more implementations out there. The goal I propose is to see if we = can get some interop between different implementations on the = (serialised) handshake message level. >=20 > Raphael > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Nov 2 10:13:22 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57D9128D68 for ; Fri, 2 Nov 2018 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5FEIiykCsMl for ; Fri, 2 Nov 2018 10:13:19 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2410E1252B7 for ; Fri, 2 Nov 2018 10:13:19 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id q1so2348901otk.0 for ; Fri, 02 Nov 2018 10:13:19 -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=k13qRIhTQOAXjDGM8IrZpqUjSzKpZlLPyWANaMAa18s=; b=fR/G30a2YTPC1ynugLj90VwduUGgz+wCCs4AMOyCV1mYuHKP+yCLyj+U8/l5+5EE/m +cw+GjO40xaEAKsy605VVqPkJN2G4gDvFfrbvxjhSGPrhmiMyuZoHwX2ZoYMMSrFoMW8 pduGF5oByUddbrvnykI37tCqoUTYiqpTGA/j2SKn2LSkkKaWP2fbhTASgtg01Q0rpeYt Iswvq9+H9eIbHWwMYie4q5bQfFok/01EPGhMEbJto1IITNaYY4YEFjHZwd+9Ke+Jr81W s4V2Pe9HMa0RiyPleLCqbSGrR8+vT0UmcYf7BhH/2MUXLtuqoyn0rtd0z++3mPTMlo6m mPhw== 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=k13qRIhTQOAXjDGM8IrZpqUjSzKpZlLPyWANaMAa18s=; b=iz+kyqyp9uDNmSa5yWmxHnhZaafqBMFf8/QXMv9Xj3SV0YOypltfGRDC9IkSV0TzIs DHhs947ylWmfBFH50alOqjWpxvYvw1LDUMjJmrqTc9AR9dXxj+s0SsP+AU7UR48NZxwi uJ2AZUZzau03vlqKKI/ykD110GrSAiEjX65aDnxAcw0h/axjdR+Z/Tal1+u3bq04Zh/9 ikK0iq/ckErVIg/EjoA0aikyqOQ9ZGaJlEamqNJ5R5+eeOhKQnfAl8byf/909qhAf34y ZmoCAbn9Jx8gWkMj9u1lVxADIofMwWNec51+aPg3XOpP7ifnSq7c2PQzhSK5qpZ7Vlq9 44bA== X-Gm-Message-State: AGRZ1gKPf/zLZqg8e8SLr34gWyMFMsU69UzULgbhhysK119Rbibq5SSD oV0Cv6/CJwTcUPg5TbCzfwgiul3j99eictOE8WLpww== X-Google-Smtp-Source: AJdET5fwHEMmy6Z40wO03iS5JP3jf40soivwv1tE9Jdb3PrBOf/+WxWRg6x4P/lhNRWvEQTjjIGl44IA1XbZ8B86Gg4= X-Received: by 2002:a9d:582e:: with SMTP id r46mr2818131oth.238.1541178797877; Fri, 02 Nov 2018 10:13:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 2 Nov 2018 13:13:03 -0400 Message-ID: To: Sean Turner Cc: Raphael Robert , mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000c87c730579b1a614" Archived-At: Subject: Re: [MLS] IETF 103 Hackathon X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 17:13:22 -0000 --000000000000c87c730579b1a614 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Absolutely. I hacked around a persistent bug on the plane, so fingers crossed we'll get something done. On Thu, Nov 1, 2018, 22:33 Sean Turner If possible could we get like a 5min summary of how it went during > Monday=E2=80=99s session? > > spt > > > On Oct 22, 2018, at 12:36, Raphael Robert wrote: > > > > Hey all, > > > > The IETF 103 Hackathon is approaching and I'd like to invite anyone who > is interested in hacking early MLS implementations to participate! > > > > A list of current implementations as well as some initial test vectors > can be found here: https://github.com/mlswg/mls-implementations > > > > It would be interesting to hear who else will participate and if there > are more implementations out there. The goal I propose is to see if we ca= n > get some interop between different implementations on the (serialised) > handshake message level. > > > > Raphael > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000c87c730579b1a614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Absolutely.=C2=A0 I hacked around a persistent bug on the= plane, so fingers crossed we'll get something done.

On Thu, Nov 1, 2018, 22:33 Sean Turner &= lt;sean@sn3rd.com wrote:
If possible could we get like a 5min summary of= how it went during Monday=E2=80=99s session?

spt

> On Oct 22, 2018, at 12:36, Raphael Robert <raphael@wire.com> w= rote:
>
> Hey all,
>
> The IETF 103 Hackathon is approaching and I'd like to invite anyon= e who is interested in hacking early MLS implementations to participate! >
> A list of current implementations as well as some initial test vectors= can be found here: https://github.com/mlswg/= mls-implementations
>
> It would be interesting to hear who else will participate and if there= are more implementations out there. The goal I propose is to see if we can= get some interop between different implementations on the (serialised) han= dshake message level.
>
> Raphael
> _______________________________________________
> MLS mailing list
> M= LS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000c87c730579b1a614-- From nobody Sun Nov 4 18:18: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 F16CE12D4F1 for ; Sun, 4 Nov 2018 18:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHr0Zwm2SXa1 for ; Sun, 4 Nov 2018 18:18:43 -0800 (PST) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 DB9BD1276D0 for ; Sun, 4 Nov 2018 18:18:42 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id z2-v6so3194095ybj.2 for ; Sun, 04 Nov 2018 18:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e6A9+RAR3//717WzlECq0KJPfCx7YFAzJI3XCTehoWo=; b=iPvxACJNOV5/KTjPMXgRd+SboZYTIprutF1/PXLDpTa3xcq+FfKL37seGK/CHvPQgb NhWMuau8wJRD9ABNdOsAkJeDk/ACIxwUgBazAW4krVc3BgOjMFDWCg5sA9Di2kpLIoD2 NpX65oYWLSFJdEdGl3MgK3W9kgvhFtGjxbmYi4b4Zf9JkX8H46cj9r5rR+thPK8OekZP bqoIesSFScdYBfL2ySW0MB61zzgr9mqI1WLTx15YOQ7mTq1VZk5zLappYRutvsIkTM4u qgwJLLtBgh3QYPYsO9of2f3lIYehelbotGcSCAISAfpSgMX7Ein6VudLdLsgEidTleFJ 8agQ== 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=e6A9+RAR3//717WzlECq0KJPfCx7YFAzJI3XCTehoWo=; b=WaO1i7JrrVH/N20ZVdicvwJD4j0iEPiz0Jqock9RBWuFgA+PPVR7AHgTnF40YP3BdA Vhkj38ML2mdUkWoUdnxj3fC+qM4gHFQ055ONY0KcNYxYYjrjHP8Zc5NofK2YhZVpOeIk LqdvW/P25+7gzBBsNwhfbKnz5RSjeRbeK3DVdbVTwwbyY03O01f96YWIYLV0Ij+mBlqa +albLqDjUJjy8M624Z5dinqrcYPvZaAlY/BTD2PVXqilcOmpNu4ilBrimCFNAihjvYoz KdzdhZG71bWhKcHgMN56/GZ3hFNi4F88kiiK+VSQXDaWWXyze/ovg9oPXsn5SXr4S92u B4cA== X-Gm-Message-State: AGRZ1gKH9Om1CQW+Lu5EvZAaozk9UDhSYO5CqRMM3aJNQABmk5qRqfLm 6EKv8sy/20CtDK9B+xuUuS8iCBByseNbvTs+3d+z X-Google-Smtp-Source: AJdET5dJauMHxj5p0tryvP0QdLvvmTHgkD0tGR5zW/KTnuJwNC8PXz4DRbs5A2CaPH7EJunMd3Pd+jHPdS4NwatsskA= X-Received: by 2002:a25:c5c2:: with SMTP id v185-v6mr19852805ybe.110.1541384321705; Sun, 04 Nov 2018 18:18:41 -0800 (PST) MIME-Version: 1.0 References: <154022472684.6470.15844142818621686395@ietfa.amsl.com> <87d55da3-2522-539d-b243-f10520829759@wickr.com> In-Reply-To: <87d55da3-2522-539d-b243-f10520829759@wickr.com> From: Emad Omara Date: Sun, 4 Nov 2018 18:18:30 -0800 Message-ID: To: jalwen@wickr.com Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000f596f60579e180fe" Archived-At: Subject: Re: [MLS] I-D Action: draft-ietf-mls-architecture-01.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 02:18:48 -0000 --000000000000f596f60579e180fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Joel for the detailed feedback, this is very useful. I added some responses below. Emad On Wed, Oct 24, 2018 at 4:56 AM Joel Alwen wrote: > Hi everyone, > > I've read over the architecture draft and put together some thoughts > that came to mind. Some are just small typos while others are a bit more > substantial. Feel free to incorporate, ignore or talk to me about whateve= r! > > - Jo=C3=ABl > > > ------------------------- Comments on MLS Architecture ------------------= -- > > - Abstract : "It is meant to protect against eavesdropping, tampering, > and message forgery." This omits PCS and FS which, IMO, is quite central > to what we are doing. Thus, already in the abstract, I'd add something > referring/hinting to FS and PCS (e.g. protecting against "past or future > device compromises" or something else along those lines). The same goes > for the Introduction as it currently also only talks about E2E security. > After all, for the security notions outlined in the abstract and intro > (i.e. basic E2E authentication and privacy) we could use MUCH simpler > protocols (e.g. a static group key decided upon during group setup. Even > just FS would be much easier E.g. a hash ratchet would do the trick.). > This, is why I believe much (most?) of what we are doing (on the > protocol level at least) is about getting PCS and FS on top of the usual > E2E security. Despite this, as far as I can tell the first mention of FS > and PCS are only in 2.3.5 under the heading "Membership and offline > members". > > > - It is not really clear to me why we require the Authentication Service > (AS) to issue credentials binding identities to keys. I believe this > should be optional. In particular, if users are able to ensure this > binding on their own (e.g. using an external authenticated channel to, > say, comparing key fingerprints or scan each others 2D barcodes) then it > does not seem necessary to have the AS provide these credentials. My > concern is that by not making this optional we are more restrictive than > really need be. Ultimately what the MS should do is provide *some* > mechanism for verifying the binding of identities to keys. Whether its > via certificates from an AS attesting to the binding or some other > mechanism performed by end users them selves seems less important to the > rest of the MLS protocol. > > - I'm not a fan of having the DS do key storage for initial key material > but have the AS store member (public) key material. (I also think the AS > should store client public keys along with member identity (public) > keys.) In general, to me a natural logical separation is that the AS is > in charge of public key storage and dissemination while the DS handles > of storage (buffering) and dissemination of traffic. Additionally, some > issues with the current division of labor between the AS and DS that > could then be avoided are: > - Its not clear why ordering for the storage of initial key material > should matter. > While I think in most cases DS and AS will be actually the same server or maintained by the same party, but I agree with you if we have a separate service for authentication it makes more sense to store the init key as well. What do you mean by "ordering" here? > - 3.1.5 "The DS must only persist data required for the delivery > of messages and avoid Personally Identifiable Information (PII) or other > sensitive metadata wherever possible." This sentence doesn't seem very > compatible to me with the DS also persistently maintaining initial keys; > especially together with credentials ultimately binding them to a member > (or at least client's) identity. > Good catch! we should fix this by either moving the init key storage to AS or update that paragraph. > > - At the meeting in Paris we very brief discussed that it could > eventually make sense to have "the server" maintain some of the group > state on behalf of clients (but, of course, without introducing any > trust in the server beyond the current "universal ordering" and "no-DOS" > assumptions). With that in mind it may eventually make sense to mention > this role as part of the DS's tasks. Alternatively, this could be > considered part of the AS's role or even a third service exclusive to > this purpose. > Will take about this in the IETF session. > > - 2.3.1 I'd specify that the initial *public* key material is stored > with the DS. > > - 2.3.1 I don't see why the AS should be involved in binding the Client > keys to the Member keys. It should suffice for the Client public key to > be signed by owning member's keys. As far as I can tell this doesn't > involve the AS. > > - I think a brief, 1 or 2 sentences clarifying key material names would > be helpful. Something like: a member has one pair of long term "identity > keys", a client has one pair of medium term "client keys" and many short > term "initial keys". For example, this could come right after the > concepts of Member's vs. Clients is introduced. > > - 3.1.4 "affect the group state". IMO the transcript (i.e. chat history) > is part of group state. So appending a message to the transcript is a > group state change. I guess what is meant here is the group's metadata? > Given that this metadata is also referred to in other places (e.g. > 3.1.5) would it make sense to include a sentence or two somewhere making > a bit clearer the terms "group state", "group metadata" and "group's > private content" (as used in 3.2.2 for e.g.). In any case the difference > between "state" in 3.1.4 vs. "metadata" in 3.1.5 isn't too clear to me. > Yes transcript here means the group metadata, but I agree which have a clearer definition for what is group state and what is metadata > > - 3.1.5. "A Messaging Service provider that has control over both the > AS and the DS, will not be able to correlate encrypted messages > forwarded by the DS, with the initial public keys signed by the AS." > This seems like a very strong property to shoot for. (Also, given the > discussion in Paris, deniability didn't seem to be a serious goal of > MLS.) At the very least it would require the protocol packets not to be > linkable to long term identities (OK but we must be careful with > signatures) but also that the DS authenticate clients via (pseudonymous) > identities. After all, if the DS does not identify clients at all, say, > when they request packets buffered in some queue) then, at the very > least, traffic analysis becomes too easy to perform (or alternatively > DOS attacks become too easy if the queue is emptied). So just to be > sure, is deniability with respect to compromised AS and DS really what > we mean here? > I think this is more of privacy protection than deniability, we usually use deniability for peers deniability and not server > > - 3.1.7 typo: the word "messages" is repeated. > > - 3.2.2 Message Integrity and Authentication: "and that one Client must > not be able to send a message which other Clients accept as being from > another Client." This seems weaker than what we want and get (from both > the ART and TreeKEM drafts). Instead, we want that "no coalition of > Clients can send a message which other Clients accept as being from a > Client not already part of that coalition." A similar change should be > made to the first sentence in 3.2.2.5 and 4.4. > > - 3.2.2.1 "MLS provides additional protection regarding secrecy of past > messages and future messages." I suggest changing this to "...regarding > secrecy and authenticity of past..." Especially in the PCS case > authenticity is just as much a goal as privacy. But also for past > (undelivered) messages when compromising a sender we still expect (and > get) authenticity. In particular the sending keys are already deleted so > the attacker is expected to not be able to create an alternative > ciphertext for that AEAD encryption key. In more detail, authenticity > should also be mentioned (next to privacy) in the more detailed > paragraphs on FS and PCS in that subsection. > > - 3.2.2.1 The PCS version described here is too strong. MLS really only > guarantees PCS if between time t and t' the attacker did not forge a > message on behalf of the compromised client. (Not only can a forged > message not be prevented by MLS, it also causes the compromised client's > state to come out of sync with the rest of the group.) So instead, one > solution is to say something like "MLS provides PCS security when the > attacker remains passive between times t and t'". Although this is a > somewhat stronger restriction on the adversary than we really need to > get PCS it is a clear, succinct yet still reasonable notion we do satisfy= .) > I think that makes sense. > > - 3.2.2.1 "Regardless, MLS does not allow addition or removal of group > members without informing all other members." Out of curiosity is this > really true for ART and TreeKEM? Suppose A, B and C are in a group. A is > corrupt so she sends a add-member message to B informing B that D has > joined the group. We specified that the DS shouldn't "know" about group > membership so it should permit forwarding this only to B. A priori, now > B thinks D is in the group but C doesn't right? In fact, if B sends > message to the group (not maybe an update though) its not clear to me > that C will realize B thinks D is in the group... Worse, D will actually > be able to decrypt the message. In fact, if D gets their hands on a > messages sent by C they could also decrypt them (at least before an > update occurs) since they are protected only by the group key which D > knows. Any way, it might just be me, but I'm not too clear if, or at > least, to which extent or in which sense we really get this property. > > - 3.2.2.3 "hence slightly weakening the PCS guarantees for attachments." > I'd probably phrase this as "hence potentially extending the time before > PCS guarantees take effect." rather than use the term "weaken" as its > the same security notion. (I believe that in crypto papers the terms > "stronger" and "weaker" are normally used to describe security games > that strictly imply (or are implie by) each other. But, the parameters t > and t' in PCS are not part of the definition of security game. Rather, > they are a function of the adversary and all inputs and random coins > used in the security game.) > Thinking about this more, I think PCS is the wrong term here, should be FS instead, because if the media key is compromised then the attacher will have access to that media. > > - 3.2.2.5 My take on the discussion about deniability in Paris was that > there was a general consensus that deniability is not an interesting > goal for MLS because what we could achieve is too weak to be interesting > while notions strong enough to be worth it in practice are out of our > reach... but to be sure I'd recommend at least checking the notes from > the meeting to confirm. > Deniability is still one of MLS goals, however having it required vs optional is still an open question. I will bring it up again in IETF to make it clear. > > - 4 First paragraph. Typo: "in" repeated twice. > > - 4.1. Realistically we might want to also add leaking meta-data. E.g. > who talks when to whom and how much they say as well as when updates are > performed vs messages exchanged. > > - 4.4 "It will also be able to send messages impersonating the > compromised Client until the Client updates its keying material (see > Section 3.2.2.1)." I think, at least if an update has been forged on > behalf of a compromised Client then even if the Client updates its key > material it still wont be able to send messages. In fact, in this cast > AFAIK A) forging can continue and B) the Client can no longer rejoin the > group; at least not without wiping its state completely and re-joining > from scratch. If this is true then we might consider adding a caveat to > the quoted sentence reflecting that updates only recover sending > capabilities if no update was forged in the meantime. > > > > > > On 10/23/2018 01:12 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Messaging Layer Security WG of the IET= F. > > > > Title : The Messaging Layer Security (MLS) Architectu= re > > Authors : Emad Omara > > Benjamin Beurdouche > > Eric Rescorla > > Srinivas Inguva > > Albert Kwon > > Alan Duric > > Filename : draft-ietf-mls-architecture-01.txt > > Pages : 16 > > Date : 2018-10-22 > > > > Abstract: > > This document describes the architecture and requirements for the > > Messaging Layer Security (MLS) protocol. MLS provides a security > > layer for group messaging applications with from two to a large > > number of clients. It is meant to protect against eavesdropping, > > tampering, and message forgery. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-mls-architecture-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mls-architecture-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000f596f60579e180fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Joel for the detailed feedback, this is very us= eful. I added some responses below.

Emad

<= div class=3D"gmail_quote">
On Wed, Oct 24, 2018 at 4:56 AM = Joel Alwen <jalwen@wickr.com>= wrote:
Hi everyone,

I've read over the architecture draft and put together some thoughts that came to mind. Some are just small typos while others are a bit more substantial. Feel free to incorporate, ignore or talk to me about whatever!=

- Jo=C3=ABl


------------------------- Comments on MLS Architecture --------------------=

- Abstract : "It is meant to protect against eavesdropping, tampering,=
and message forgery." This omits PCS and FS which, IMO, is quite centr= al
to what we are doing. Thus, already in the abstract, I'd add something<= br> referring/hinting to FS and PCS (e.g. protecting against "past or futu= re
device compromises" or something else along those lines). The same goe= s
for the Introduction as it currently also only talks about E2E security. After all, for the security notions outlined in the abstract and intro
(i.e. basic E2E authentication and privacy) we could use MUCH simpler
protocols (e.g. a static group key decided upon during group setup. Even just FS would be much easier E.g. a hash ratchet would do the trick.).
This, is why I believe much (most?) of what we are doing (on the
protocol level at least) is about getting PCS and FS on top of the usual E2E security. Despite this, as far as I can tell the first mention of FS and PCS are only in 2.3.5 under the heading "Membership and offline members".


- It is not really clear to me why we require the Authentication Service (AS) to issue credentials binding identities to keys. I believe this
should be optional. In particular, if users are able to ensure this
binding on their own (e.g. using an external authenticated channel to,
say, comparing key fingerprints or scan each others 2D barcodes) then it does not seem necessary to have the AS provide these credentials. My
concern is that by not making this optional we are more restrictive than really need be. Ultimately what the MS should do is provide *some*
mechanism for verifying the binding of identities to keys. Whether its
via certificates from an AS attesting to the binding or some other
mechanism performed by end users them selves seems less important to the rest of the MLS protocol.

- I'm not a fan of having the DS do key storage for initial key materia= l
but have the AS store member (public) key material. (I also think the AS should store client public keys along with member identity (public)
keys.) In general, to me a natural logical separation is that the AS is
in charge of public key storage and dissemination while the DS handles
of storage (buffering) and dissemination of traffic. Additionally, some
issues with the current division of labor between the AS and DS that
could then be avoided are:
=C2=A0=C2=A0=C2=A0 - Its not clear why ordering for the storage of initial = key material
should matter.
While I think in most cases DS and AS w= ill be actually the same server or maintained by the same party, but I agre= e with you if we have a separate service for authentication it makes more s= ense to store the init key as well.
What do you mean by "ord= ering" here?=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - 3.1.5 "The DS must only p= ersist data required for the delivery
of messages and avoid Personally Identifiable Information (PII) or other sensitive metadata wherever possible." This sentence doesn't seem = very
compatible to me with the DS also persistently maintaining initial keys; especially together with credentials ultimately binding them to a member (or at least client's) identity.
Good catch! we sh= ould fix this by either moving the init key storage to AS=C2=A0 or update t= hat paragraph.

- At the meeting in Paris we very brief discussed that it could
eventually make sense to have "the server" maintain some of the g= roup
state on behalf of clients (but, of course, without introducing any
trust in the server beyond the current "universal ordering" and &= quot;no-DOS"
assumptions). With that in mind it may eventually make sense to mention
this role as part of the DS's tasks. Alternatively, this could be
considered part of the AS's role or even a third service exclusive to this purpose.
Will take about this in the IETF session= .=C2=A0

- 2.3.1 I'd specify that the initial *public* key material is stored with the DS.

- 2.3.1 I don't see why the AS should be involved in binding the Client=
keys to the Member keys. It should suffice for the Client public key to
be signed by owning member's keys. As far as I can tell this doesn'= t
involve the AS.

- I think a brief, 1 or 2 sentences clarifying key material names would
be helpful. Something like: a member has one pair of long term "identi= ty
keys", a client has one pair of medium term "client keys" an= d many short
term "initial keys". For example, this could come right after the=
concepts of Member's vs. Clients is introduced.

- 3.1.4 "affect the group state". IMO the transcript (i.e. chat h= istory)
is part of group state. So appending a message to the transcript is a
group state change. I guess what is meant here is the group's metadata?=
Given that this metadata is also referred to in other places (e.g.
3.1.5) would it make sense to include a sentence or two somewhere making a bit clearer the terms "group state",=C2=A0 "group metadata= " and "group's
private content" (as used in 3.2.2 for e.g.). In any case the differen= ce
between "state" in 3.1.4 vs. "metadata" in 3.1.5 isn= 9;t too clear to me.
Yes transcript here means the gro= up metadata, but I agree which have a clearer definition for what is group = state and what is metadata=C2=A0

- 3.1.5.=C2=A0 "A Messaging Service provider that has control over bot= h the
AS and the DS, will not be able to correlate encrypted messages
forwarded by the DS, with the initial public keys signed by the AS." This seems like a very strong property to shoot for. (Also, given the
discussion in Paris, deniability didn't seem to be a serious goal of MLS.) At the very least it would require the protocol packets not to be
linkable to long term identities (OK but we must be careful with
signatures) but also that the DS authenticate clients via (pseudonymous) identities. After all, if the DS does not identify clients at all, say,
when they request packets buffered in some queue) then, at the very
least, traffic analysis becomes too easy to perform (or alternatively
DOS attacks become too easy if the queue is emptied). So just to be
sure, is deniability with respect to compromised AS and DS really what
we mean here?
I think this is more of privacy protecti= on than deniability, we usually use deniability for peers deniability and n= ot server=C2=A0

- 3.1.7 typo: the word "messages" is repeated.

- 3.2.2 Message Integrity and Authentication: "and that one Client mus= t
not be able to send a message which other Clients accept as being from
another Client." This seems weaker than what we want and get (from bot= h
the ART and TreeKEM drafts). Instead, we want that "no coalition of Clients can send a message which other Clients accept as being from a
Client not already part of that coalition." A similar change should be=
made to the first sentence in 3.2.2.5 and 4.4.

- 3.2.2.1 "MLS provides additional protection regarding secrecy of pas= t
messages and future messages." I suggest changing this to "...reg= arding
secrecy and authenticity of past..." Especially in the PCS case
authenticity is just as much a goal as privacy. But also for past
(undelivered) messages when compromising a sender we still expect (and
get) authenticity. In particular the sending keys are already deleted so the attacker is expected to not be able to create an alternative
ciphertext for that AEAD encryption key. In more detail, authenticity
should also be mentioned (next to privacy) in the more detailed
paragraphs on FS and PCS in that subsection.

- 3.2.2.1 The PCS version described here is too strong. MLS really only
guarantees PCS if between time t and t' the attacker did not forge a message on behalf of the compromised client. (Not only can a forged
message not be prevented by MLS, it also causes the compromised client'= s
state to come out of sync with the rest of the group.) So instead, one
solution is to say something like "MLS provides PCS security when the<= br> attacker remains passive between times t and t'". Although this is= a
somewhat stronger restriction on the adversary than we really need to
get PCS it is a clear, succinct yet still reasonable notion we do satisfy.)=
I think that makes sense.=C2=A0 =C2=A0

- 3.2.2.1 "Regardless, MLS does not allow addition or removal of group=
members without informing all other members." Out of curiosity is this=
really true for ART and TreeKEM? Suppose A, B and C are in a group. A is corrupt so she sends a add-member message to B informing B that D has
joined the group. We specified that the DS shouldn't "know" a= bout group
membership so it should permit forwarding this only to B. A priori, now
B thinks D is in the group but C doesn't right? In fact, if B sends
message to the group (not maybe an update though) its not clear to me
that C will realize B thinks D is in the group... Worse, D will actually be able to decrypt the message. In fact, if D gets their hands on a
messages sent by C they could also decrypt them (at least before an
update occurs) since they are protected only by the group key which D
knows. Any way, it might just be me, but I'm not too clear if, or at least, to which extent or in which sense we really get this property.

- 3.2.2.3 "hence slightly weakening the PCS guarantees for attachments= ."
I'd probably phrase this as "hence potentially extending the time = before
PCS guarantees take effect." rather than use the term "weaken&quo= t; as its
the same security notion. (I believe that in crypto papers the terms
"stronger" and "weaker" are normally used to describe s= ecurity games
that strictly imply (or are implie by) each other. But, the parameters t and t' in PCS are not part of the definition of security game. Rather,<= br> they are a function of the adversary and all inputs and random coins
used in the security game.)
Thinking about this more, = I think PCS is the wrong term here, should be FS instead, because if the me= dia key is compromised then the attacher will have access to that media.=C2= =A0

- 3.2.2.5 My take on the discussion about deniability in Paris was that
there was a general consensus that deniability is not an interesting
goal for MLS because what we could achieve is too weak to be interesting while notions strong enough to be worth it in practice are out of our
reach... but to be sure I'd recommend at least checking the notes from<= br> the meeting to confirm.
Deniability is still one of ML= S goals, however having it required vs optional is still an open question. = I will bring it up again in IETF to make it clear.=C2=A0

- 4 First paragraph. Typo: "in" repeated twice.

- 4.1. Realistically we might want to also add leaking meta-data. E.g.
who talks when to whom and how much they say as well as when updates are performed vs messages exchanged.

- 4.4 "It will also be able to send messages impersonating the
compromised Client until the Client updates its keying material (see
Section 3.2.2.1)." I think, at least if an update has been forged on behalf of a compromised Client then even if the Client updates its key
material it still wont be able to send messages. In fact, in this cast
AFAIK A) forging can continue and B) the Client can no longer rejoin the group; at least not without wiping its state completely and re-joining
from scratch. If this is true then we might consider adding a caveat to
the quoted sentence reflecting that updates only recover sending
capabilities if no update was forged in the meantime.





On 10/23/2018 01:12 AM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Messaging Layer Security WG of the IE= TF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: The Messaging Layer Security (MLS) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=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 =C2=A0Benjamin 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 =C2=A0Eric Rescorla
>=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 =C2=A0Srinivas Inguva
>=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 =C2=A0Albert Kwon
>=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 =C2=A0Alan Duric
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-mls-architecture-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 16
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-10-22
>
> Abstract:
>=C2=A0 =C2=A0 This document describes the architecture and requirements= for the
>=C2=A0 =C2=A0 Messaging Layer Security (MLS) protocol.=C2=A0 MLS provid= es a security
>=C2=A0 =C2=A0 layer for group messaging applications with from two to a= large
>=C2=A0 =C2=A0 number of clients.=C2=A0 It is meant to protect against e= avesdropping,
>=C2=A0 =C2=A0 tampering, and message forgery.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/d= raft-ietf-mls-architecture/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-iet= f-mls-architecture-01
> https://datatracker.ietf.or= g/doc/html/draft-ietf-mls-architecture-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-mls-architecture-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000f596f60579e180fe-- From nobody Mon Nov 5 02:49: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 9379D130F20 for ; Mon, 5 Nov 2018 02:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGrjRwrqw24D for ; Mon, 5 Nov 2018 02:48:42 -0800 (PST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D76F130DE2 for ; Mon, 5 Nov 2018 02:48:42 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id v83-v6so7019169oia.5 for ; Mon, 05 Nov 2018 02:48:42 -0800 (PST) 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 :cc; bh=42adlfFi+09h/4Gao4jzCNej5sYlammWNKOsUR3ra2o=; b=jzIRQbgyUz1zP6PYHtj1OQU2aj2ZpC7RHl4xocYG0KgSi2GwkPW5Jdm0kS+ZCJye/M pMGF2SrE/u9ckzsNYKHY+oy4srZZkHrZJxwZX5lmM6R3znMX7dxl3ZJGn7p6Js43uryZ qxXvolyaKiFeSD57X4hhOzs8JdZu6Q/q2nNSU= 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=42adlfFi+09h/4Gao4jzCNej5sYlammWNKOsUR3ra2o=; b=mmRnVe0dapPCiZvXL/dDo4jDt4wx2CZXsqMlTE1rRm7C9OPshRAJWjEfEZwCaGSJIf S4ffW/rSrerninWykwZhdEzNz/wboinnzja+CzpX9hrk7dW1Fm6EOj80ayjXNkPPNZf7 4BsnGbp9FzLRwJjs2j9nU47d0/Kj0jJP5gZhNVtePTb1CyUItuYifOmOpCCQK479KDbz OlbBEBB672oAscKLPjGnSgYieat6QiUJOaVt8re8vX9RZQsoIiRdFShm0V+HeiDm1Gn9 sOoJ0lnXsTBHWIc0DggUXp91pd8BYES1Mvgd1YgUuWI1lO3LWI9Qz8IFJHDGetrOFLMn JBUA== X-Gm-Message-State: AGRZ1gJW2P8eWqNESUz6/3PpPR+dx4NacqDKvRfX6HRysW+f7Kbv6oXi fBsPo3OrS146XJ4UKn1lkxKGBcDgahXISBXi6CPjx/4xeM1yKw== X-Google-Smtp-Source: AJdET5fbC/SR+g3oDKmAstlo8npqn3lYJN/ODZvGOBFEUf4tqv8iaLxKBLDabpe3QmJ8msuKA1xmxx1sSDZRmGgu9g0= X-Received: by 2002:aca:f00b:: with SMTP id o11-v6mr12855496oih.35.1541414921265; Mon, 05 Nov 2018 02:48:41 -0800 (PST) MIME-Version: 1.0 References: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> In-Reply-To: From: Nick Sullivan Date: Mon, 5 Nov 2018 17:48:29 +0700 Message-ID: To: Brendan McMillion Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5fdd10579e8a048" Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 10:48:52 -0000 --000000000000d5fdd10579e8a048 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brendan, Does verifying these derived keys that are deeper down the tree require knowledge of the public keys up the tree? Are these keys included in the messages (implying a log(depth) increase in message size) or can they be compressed somehow or are they distributed in some other manner? Nick On Tue, Oct 16, 2018 at 7:03 AM Brendan McMillion wrote: > > We'd need to know the number of epochs we're allowing for this MLS > session in advance. > > I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a tree= construction > that allows an unbounded number of intervals and fast setup. The root key > would sign only two children: a left child which is the root of a tree of > height 1 whose leaf(s) are used for signing data, and a right child. Once > the left child is used up, the right child signs two children in the same > way the root key did, but now the left child is the root of a tree of > height 2. Every time you have to use the right-most node, the left child > gets twice as large. Here=E2=80=99s a diagram, if the description isn=E2= =80=99t clear: > https://i.imgur.com/DosZ3Sf.png > > So the signer=E2=80=99s private key and signatures are proportional to lo= g(T), the > current epoch count. > > We're simply trying to limit the impact of device compromise. We're abl= e > to do this more easily for encryption keys, but signatures are more trick= y. > > I agree it's valuable that if participant A is offline for a long time an= d > B=E2=80=99s key is compromised at epoch n, then when A comes back online = she can > still trust everything signed by B in previous epochs. I think you can al= so > get something similar to post-compromise security with the above > construction: Once B is no longer compromised, he would continue walking > the tree and generating new keypairs where the attacker doesn=E2=80=99t k= now the > private keys. So to sign a message, the attacker would need to certify > their own keypairs. This can be prevented by all the group participants > refusing to accept more than one distinct public key per node in the tree= . > > On Fri, Oct 12, 2018 at 10:45 PM Nadim Kobeissi > wrote: > >> Dear Brendan, >> Your proposed scheme could work, too. The disadvantages it presents, it >> seems to me, aren't severe: >> >> - Your proposed scheme seems to have a larger performance overhead: >> each leaf keypair/epoch tuple would have to be generated and signed i= n >> advance. >> - We'd need to know the number of epochs we're allowing for this MLS >> session in advance. >> - We may not be able to parametrize the choice of upcoming signature >> keys based on a dynamically generated epoch identifier with the same = degree >> of freedom that HKD would give us. >> >> > Also, since I didn=E2=80=99t go to the interim, what problem do >> forward-signature signature schemes solve for MLS? >> >> We're simply trying to limit the impact of device compromise. We're able >> to do this more easily for encryption keys, but signatures are more tric= ky. >> >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software >> >> Sent from office >> >> >> On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillion >> wrote: >> >>> Hey Nadim >>> >>> I believe the typical way to build a forward-secure signature scheme is >>> with a certification tree. You=E2=80=99d: >>> >>> 1. Generate a root keypair. >>> 2. Generate N leaf keypairs. >>> 3. Sign each leaf keypair and the epoch it is meant to be used in, with >>> the root keypair. >>> 4. Delete the root private key. >>> >>> Your root public key is what=E2=80=99s distributed to everybody. A sign= ature at >>> a given epoch is the tuple: (leaf public key, sig over leaf key from ro= ot >>> key, sig over data from leaf key). >>> >>> Could you talk about why a scheme like the above is not suitable here? >>> Also, since I didn=E2=80=99t go to the interim, what problem do forward= -signature >>> signature schemes solve for MLS? >>> >>> On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi >>> wrote: >>> >>> Dear Ted, >>> Thanks for your quick read-through! >>> >>> You seem to be referring to [1], not to [2] as you wrote. In [1], the >>> concept of "hardened" keys is defined and is also ported by [2] into >>> Ed25519. >>> >>> > What I think that means is that if an attacker ever gets access to >>> both an extended public key and any extended private key, we have lost >>> forward secrecy for all the MLS communications covered by any keys deri= ved >>> from any of the epoch pairs. Is that correct? >>> >>> This is correct in the sense that it allows you to rewind the key >>> derivation chain. However, this does not apply to hardened keys. This i= s >>> precisely why I'm trying to understand how epoch identifiers are agreed >>> upon, in order to see whether we can use them to restrict the HKD logic= to >>> use only "hardened" keys in MLS. Since hardened keys in [2] cannot >>> themselves have children, it becomes important to understand whether we= can >>> select enough of them for an HKD design in MLS to have a meaningful imp= act, >>> and how this selection/potential caching of hardened keys would work. >>> >>> > [...] means that Alice must refrain from ever using the parent >>> extended public key has a signing key, but must instantiate signing key= s >>> from the n + 0 epoch. >>> >>> This could also be a solution, I suppose, but it sounds like it would >>> result in weaker "signing forward secrecy" (or whatever we're calling t= his >>> property) than focusing on hardened keys, although I'm frankly not sure= off >>> the top of my head. >>> >>> Nadim Kobeissi >>> Symbolic Software =E2=80=A2 https://symbolic.software >>> Sent from office >>> >>> >>> On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie wrote: >>> >>>> Hi Nadim, >>>> >>>> I suspect I'm missing something simple here in your proposal. >>>> According to your reference 2, one of the issues with the derivation o= f >>>> this type of hierarchical key is: >>>> >>>> that knowledge of a parent extended public key plus any non-hardened >>>>> private key descending from it is equivalent to knowing the parent ex= tended >>>>> private key (and thus every private and public key descending from it= ). >>>>> This means that extended public keys must be treated more carefully t= han >>>>> regular public keys. It is also the reason for the existence of harde= ned >>>>> keys, and why they are used for the account level in the tree. This w= ay, a >>>>> leak of account-specific (or below) private key never risks compromis= ing >>>>> the master or other accounts. >>>>> >>>> >>>> What I think that means is that if an attacker ever gets access to bot= h >>>> an extended public key and any extended private key, we have lost forw= ard >>>> secrecy for all the MLS communications covered by any keys derived fro= m any >>>> of the epoch pairs. Is that correct? >>>> >>>> This appears to make handling required of the parent extended public >>>> key roughly equivalent to the handling of a private key, so that your = step: >>>> >>>> Alice sends a public signing key to Bob during epoch n. >>>> >>>> means that Alice must refrain from ever using the parent extended >>>> public key has a signing key, but must instantiate signing keys from t= he n >>>> + 0 epoch. >>>> >>>> Is that a correct understanding? >>>> >>>> Thanks, >>>> >>>> Ted >>>> >>>> >>>> On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi < >>>> nadim@symbolic.software> wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> I've been working on adapting Hierarchical Key Derivation (HKD) in >>>>> order to obtain some kind of ephemeral signatures that may be useful = in >>>>> MLS. I've arrived at a point where I'm optimistic that this is a dire= ction >>>>> worth pursuing and might indeed be a solution to this problem. >>>>> >>>>> HKD was at some point a candidate for how signature keys are managed >>>>> per epoch in the Tor Hidden Service design [0]. HKD logic has also be= en >>>>> implemented in Bitcoin wallets for a while now [1]. HKD constructions= can >>>>> be also derived from existing popular fast signature algorithms such = as >>>>> Ed25519 with minimal changes [2], making them an easy fit for MLS. Ve= ry >>>>> simply, the functionality that HKD signature schemes bring to MLS is = the >>>>> following: >>>>> >>>>> - Alice sends a public signing key to Bob during epoch n. >>>>> - At the onset of epoch n+1, Bob is able to immediately calculate >>>>> Alice's public signing key for epoch n+1 based purely on his knowl= edge of >>>>> Alice's public signing key for epoch 0. Alice doesn't need to send= new >>>>> signing key information to Bob. >>>>> - At this point, Bob can delete Alice's public signing key for >>>>> epoch n. >>>>> - More importantly, Alice herself can delete Alice's private >>>>> signing key for epoch n, keeping only her private signing key for = epoch n+1. >>>>> >>>>> The way that this could work in MLS would be heavily based on >>>>> HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead w= ill >>>>> point out the relevant sections (which are short, well-written and wo= rth >>>>> reading:) >>>>> >>>>> - Section 2 describes the original concept as used for Bitcoin >>>>> wallet derivation. >>>>> - Section 4 describes the modifications to Ed25519 to enable HKD >>>>> constructions. >>>>> - Section 5 describes how private and public child keys are >>>>> generated (Fig. 1 is also helpful.) >>>>> >>>>> My questions: >>>>> >>>>> - How are we deriving epoch identifiers? Are they simply counters, >>>>> or each epoch identified by a nonce that's communicated confidenti= ally? If >>>>> you read [2], you'll see why this can be important. >>>>> - Performance impact seems to be negligible for Montgomery-based >>>>> signing primitives, but I'm interested in more insight on this. >>>>> - Is anyone else interested in having a standard >>>>> HDKeys-Ed25519 implementation? I've been working on one in JavaScr= ipt and >>>>> plan to eventually also write one in Go. Perhaps Richard would lik= e to help >>>>> with a C++ version? >>>>> - I'm also interested in hearing your thoughts on this generally. >>>>> >>>>> During the interim meeting (as well as before it), it was frequently >>>>> discussed how ephemeral signatures may be useful for MLS. This also a= ppears >>>>> to be slated as a discussion topic for IETF 103, so it would be great= if we >>>>> could continue the discussion there as well. >>>>> >>>>> References: >>>>> [0] >>>>> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spe= c-ng.txt#n1979 >>>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki >>>>> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf >>>>> >>>>> Nadim Kobeissi >>>>> Symbolic Software =E2=80=A2 https://symbolic.software >>>>> Sent from office >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> >>>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >>> >>> _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d5fdd10579e8a048 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brendan,

Does verifying these derived k= eys that are deeper down the tree require knowledge of the public keys up t= he tree? Are these keys included in the messages (implying a log(depth) inc= rease in message size) or can they be compressed somehow or are they distri= buted in some other manner?

Nick

On Tue, Oct 16, 2018 at 7:03 AM Br= endan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:
> We'd need to know the number of epochs we&#= 39;re allowing for this MLS session in advance.

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

So the signer=E2=80= =99s private key and signatures are proportional to log(T), the current epo= ch count.
> We're simply trying to limit the impact of device compromise. We'r= e=20 able to do this more easily for encryption keys, but signatures are more tricky.

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

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

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

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

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

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

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

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

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

On= Oct 12, 2018, at 1:22 PM, Nadim Kobeissi <nadim@symbolic.software> wrote:
Dear Ted,
Thanks for= your quick read-through!

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

> What I think that means is that if an attacker ever gets acce= ss to both an extended public key and any extended private key, we have los= t forward secrecy for all the MLS communications covered by any keys derive= d from any of the epoch pairs.=C2=A0 Is that correct?

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

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

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

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


Hi Nadim,

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

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

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

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

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

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

Is that a correct understanding?=

Thanks,

Ted


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

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

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

<= /div>
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d5fdd10579e8a048-- From nobody Mon Nov 5 10:26:23 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1141277D2 for ; Mon, 5 Nov 2018 10:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfAzvLjTwqiI for ; Mon, 5 Nov 2018 10:26:17 -0800 (PST) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 59E3F127133 for ; Mon, 5 Nov 2018 10:26:17 -0800 (PST) Received: by mail-pl1-x643.google.com with SMTP id g59-v6so4850044plb.10 for ; Mon, 05 Nov 2018 10:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cm1nT5eO8o4Xi1Xt8nQ54kLBf3v2dc6K+qiyU0SyPDU=; b=xmDQQBo3L9Cu5RzYL12gY6l83TiIJ2P1frZQQ8iCatJuKfHNEjX3E8Wp/7OhRA6Gzc /jNHTTACo0sGlwC4/oKgm4QUu7VXm+yE2Ab43PqNiDYl0O5HVc17sSIQZGS/u1YF1MCv Z0Ts6+17lUdXVcuo5zDU0rE8OSpK5Mns/jba8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cm1nT5eO8o4Xi1Xt8nQ54kLBf3v2dc6K+qiyU0SyPDU=; b=iC+yMOji8dYTnw9iIvBVjx8DVI3BBUjL9ORDQjT6gRLODC80H2+xhR4Vwy/H4JKwpc GMnrAujVutjKXSBdiEh3vAfdfpzM0OFyIcoiUGTg4sK6A/iV8vsBiz/8aJPA17zvFQkQ adgE/jb53GTC7cPpSyAWdTIpRBqxZcmq+dWWAV5iNe5cJZLWxy8nH62cxbxh9nZGeCzF +G7Twz75UNWhNrLDnLpApACeRm4jHnKB4g4etMl3Re/qN3aqVidq/XYmjPa5xl58AiRG KxW8I4ZLPomdWrSlzLZ9pE0vkmiDTLoDD/gLxog4cn5QthTdBsALklqbYd5sZO4E/G7M WC8A== X-Gm-Message-State: AGRZ1gIKfY+VwAls2w7uhxp8P4Ak13d01mV7r8JMiyXCSRsqXSG3iZR6 45vc6lKQaUIMmJS+J0QPqRpjGw== X-Google-Smtp-Source: AJdET5epw7iyLB38lvA1OYt2nmAs+lsuqTKUyylPIZ+6xZWKVS0xtmsaW0autCstLhr758A3mvmXYw== X-Received: by 2002:a17:902:4624:: with SMTP id o33-v6mr23386326pld.285.1541442376551; Mon, 05 Nov 2018 10:26:16 -0800 (PST) Received: from [172.16.15.160] (cloudflareptp.static.monkeybrains.net. [162.245.21.30]) by smtp.gmail.com with ESMTPSA id f10-v6sm42468319pgp.72.2018.11.05.10.26.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 10:26:15 -0800 (PST) From: Brendan McMillion Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A15702C2-9A2B-4694-8543-0048664F0394" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 5 Nov 2018 10:26:14 -0800 In-Reply-To: Cc: mls@ietf.org To: Nick Sullivan References: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 18:26:21 -0000 --Apple-Mail=_A15702C2-9A2B-4694-8543-0048664F0394 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is the base scheme which has the following properties: Constant-size public key, private key and signature of size approx = 2*log(T). Stateless verification. Not post-compromise secure; can handle minor state regression. You can make these modifications to it: Require verifiers to verify signatures strictly one-after-the-other and = update their understanding of the public key. Require signers to certify the signing key for epoch N with the signing = key from epoch N-1, regardless of the tree structure. to get a construction with these properties: Public key and private key of size approx 2*log(T), constant-size = signature. Stateful verification. Post-compromise secure; state regression will lock the user out. > On Nov 5, 2018, at 2:48 AM, Nick Sullivan = wrote: >=20 > Brendan, >=20 > Does verifying these derived keys that are deeper down the tree = require knowledge of the public keys up the tree? Are these keys = included in the messages (implying a log(depth) increase in message = size) or can they be compressed somehow or are they distributed in some = other manner? >=20 > Nick >=20 > On Tue, Oct 16, 2018 at 7:03 AM Brendan McMillion = > wrote: > > We'd need to know the number of epochs we're allowing for this MLS = session in advance. >=20 > I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a = tree construction that allows an unbounded number of intervals and fast = setup. The root key would sign only two children: a left child which is = the root of a tree of height 1 whose leaf(s) are used for signing data, = and a right child. Once the left child is used up, the right child signs = two children in the same way the root key did, but now the left child is = the root of a tree of height 2. Every time you have to use the = right-most node, the left child gets twice as large. Here=E2=80=99s a = diagram, if the description isn=E2=80=99t clear: = https://i.imgur.com/DosZ3Sf.png >=20 > So the signer=E2=80=99s private key and signatures are proportional to = log(T), the current epoch count. > > We're simply trying to limit the impact of device compromise. We're = able to do this more easily for encryption keys, but signatures are more = tricky. >=20 > I agree it's valuable that if participant A is offline for a long time = and B=E2=80=99s key is compromised at epoch n, then when A comes back = online she can still trust everything signed by B in previous epochs. I = think you can also get something similar to post-compromise security = with the above construction: Once B is no longer compromised, he would = continue walking the tree and generating new keypairs where the attacker = doesn=E2=80=99t know the private keys. So to sign a message, the = attacker would need to certify their own keypairs. This can be prevented = by all the group participants refusing to accept more than one distinct = public key per node in the tree. >=20 > On Fri, Oct 12, 2018 at 10:45 PM Nadim Kobeissi = wrote: > Dear Brendan, > Your proposed scheme could work, too. The disadvantages it presents, = it seems to me, aren't severe: > Your proposed scheme seems to have a larger performance overhead: each = leaf keypair/epoch tuple would have to be generated and signed in = advance. > We'd need to know the number of epochs we're allowing for this MLS = session in advance. > We may not be able to parametrize the choice of upcoming signature = keys based on a dynamically generated epoch identifier with the same = degree of freedom that HKD would give us. > > Also, since I didn=E2=80=99t go to the interim, what problem do = forward-signature signature schemes solve for MLS? >=20 > We're simply trying to limit the impact of device compromise. We're = able to do this more easily for encryption keys, but signatures are more = tricky. >=20 > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software = > Sent from office >=20 >=20 > On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillion = > wrote: > Hey Nadim >=20 > I believe the typical way to build a forward-secure signature scheme = is with a certification tree. You=E2=80=99d: >=20 > 1. Generate a root keypair. > 2. Generate N leaf keypairs. > 3. Sign each leaf keypair and the epoch it is meant to be used in, = with the root keypair. > 4. Delete the root private key. >=20 > Your root public key is what=E2=80=99s distributed to everybody. A = signature at a given epoch is the tuple: (leaf public key, sig over leaf = key from root key, sig over data from leaf key). >=20 > Could you talk about why a scheme like the above is not suitable here? = Also, since I didn=E2=80=99t go to the interim, what problem do = forward-signature signature schemes solve for MLS? >=20 >> On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi > wrote: >>=20 >> Dear Ted, >> Thanks for your quick read-through! >>=20 >> You seem to be referring to [1], not to [2] as you wrote. In [1], the = concept of "hardened" keys is defined and is also ported by [2] into = Ed25519. >>=20 >> > What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >>=20 >> This is correct in the sense that it allows you to rewind the key = derivation chain. However, this does not apply to hardened keys. This is = precisely why I'm trying to understand how epoch identifiers are agreed = upon, in order to see whether we can use them to restrict the HKD logic = to use only "hardened" keys in MLS. Since hardened keys in [2] cannot = themselves have children, it becomes important to understand whether we = can select enough of them for an HKD design in MLS to have a meaningful = impact, and how this selection/potential caching of hardened keys would = work. >>=20 >> > [...] means that Alice must refrain from ever using the parent = extended public key has a signing key, but must instantiate signing keys = from the n + 0 epoch. =20 >>=20 >> This could also be a solution, I suppose, but it sounds like it would = result in weaker "signing forward secrecy" (or whatever we're calling = this property) than focusing on hardened keys, although I'm frankly not = sure off the top of my head. >>=20 >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software = >> Sent from office >>=20 >>=20 >> On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie > wrote: >> Hi Nadim, >>=20 >> I suspect I'm missing something simple here in your proposal. = According to your reference 2, one of the issues with the derivation of = this type of hierarchical key is: >>=20 >> that knowledge of a parent extended public key plus any non-hardened = private key descending from it is equivalent to knowing the parent = extended private key (and thus every private and public key descending = from it). This means that extended public keys must be treated more = carefully than regular public keys. It is also the reason for the = existence of hardened keys, and why they are used for the account level = in the tree. This way, a leak of account-specific (or below) private key = never risks compromising the master or other accounts. >>=20 >> What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >>=20 >> This appears to make handling required of the parent extended public = key roughly equivalent to the handling of a private key, so that your = step: >>=20 >> Alice sends a public signing key to Bob during epoch n. >>=20 >> means that Alice must refrain from ever using the parent extended = public key has a signing key, but must instantiate signing keys from the = n + 0 epoch. =20 >>=20 >> Is that a correct understanding? >>=20 >> Thanks, >>=20 >> Ted >>=20 >>=20 >> On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi = > wrote: >> Hello everyone, >>=20 >> I've been working on adapting Hierarchical Key Derivation (HKD) in = order to obtain some kind of ephemeral signatures that may be useful in = MLS. I've arrived at a point where I'm optimistic that this is a = direction worth pursuing and might indeed be a solution to this problem. >>=20 >> HKD was at some point a candidate for how signature keys are managed = per epoch in the Tor Hidden Service design [0]. HKD logic has also been = implemented in Bitcoin wallets for a while now [1]. HKD constructions = can be also derived from existing popular fast signature algorithms such = as Ed25519 with minimal changes [2], making them an easy fit for MLS. = Very simply, the functionality that HKD signature schemes bring to MLS = is the following: >> Alice sends a public signing key to Bob during epoch n. >> At the onset of epoch n+1, Bob is able to immediately calculate = Alice's public signing key for epoch n+1 based purely on his knowledge = of Alice's public signing key for epoch 0. Alice doesn't need to send = new signing key information to Bob. >> At this point, Bob can delete Alice's public signing key for epoch n. >> More importantly, Alice herself can delete Alice's private signing = key for epoch n, keeping only her private signing key for epoch n+1. >> The way that this could work in MLS would be heavily based on = HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead will = point out the relevant sections (which are short, well-written and worth = reading:) >> Section 2 describes the original concept as used for Bitcoin wallet = derivation. >> Section 4 describes the modifications to Ed25519 to enable HKD = constructions. >> Section 5 describes how private and public child keys are generated = (Fig. 1 is also helpful.) >> My questions: >> How are we deriving epoch identifiers? Are they simply counters, or = each epoch identified by a nonce that's communicated confidentially? If = you read [2], you'll see why this can be important. >> Performance impact seems to be negligible for Montgomery-based = signing primitives, but I'm interested in more insight on this. >> Is anyone else interested in having a standard HDKeys-Ed25519 = implementation? I've been working on one in JavaScript and plan to = eventually also write one in Go. Perhaps Richard would like to help with = a C++ version? >> I'm also interested in hearing your thoughts on this generally. >> During the interim meeting (as well as before it), it was frequently = discussed how ephemeral signatures may be useful for MLS. This also = appears to be slated as a discussion topic for IETF 103, so it would be = great if we could continue the discussion there as well.=20 >>=20 >> References: >> [0] = https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.= txt#n1979 = >> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki = >> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf = >>=20 >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software = >> Sent from office >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_A15702C2-9A2B-4694-8543-0048664F0394 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 There= is the base scheme which has the following properties:
  • Constant-size public key, private = key and signature of size approx 2*log(T).
  • Stateless = verification.
  • Not post-compromise secure; can = handle minor state regression.

    • You can make these modifications to = it:
    • Require = verifiers to verify signatures strictly one-after-the-other and update = their understanding of the public key.
    • Require = signers to certify the signing key for epoch N with the signing key from = epoch N-1, regardless of the tree structure.
    to = get a construction with these properties:
    • Public key and private key of size = approx 2*log(T), constant-size signature.
    • Stateful = verification.
    • Post-compromise secure; state = regression will lock the user out.

    On Nov = 5, 2018, at 2:48 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

    Brendan,

    Does verifying these derived keys that are deeper down the = tree require knowledge of the public keys up the tree? Are these keys = included in the messages (implying a log(depth) increase in message = size) or can they be compressed somehow or are they distributed in some = other manner?

    Nick

    On Tue, Oct 16, 2018 = at 7:03 AM Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:
    > We'd need to know the = number of epochs we're allowing for this MLS session in advance.

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

    So the = signer=E2=80=99s private key and signatures are proportional to log(T), = the current epoch count.
    > We're simply trying to limit the impact of device compromise. We're=20 able to do this more easily for encryption keys, but signatures are more tricky.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

    Is that a correct understanding?

    Thanks,

    Ted


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

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

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

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

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

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

    = --Apple-Mail=_A15702C2-9A2B-4694-8543-0048664F0394-- From nobody Mon Nov 5 11:35: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 58B68130E10 for ; Mon, 5 Nov 2018 11:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NENXNZaiUsG for ; Mon, 5 Nov 2018 11:35:34 -0800 (PST) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 AEA9B1277D2 for ; Mon, 5 Nov 2018 11:35:34 -0800 (PST) Received: by mail-pg1-x542.google.com with SMTP id n10-v6so4663499pgv.10 for ; Mon, 05 Nov 2018 11:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=roeTAOQB+QwR1lIzLHYZGaMN1zWZGCia0MGLUuLM4+s=; b=s4a2wGqfXmy/tV/QOSBxmj3BmMmXteoFaPAFnCAuz0lyXcuwo4b4Xq08rMY10xr2LX qOSuClcrZjvs50npuyrQVjjK6woUMii6KTTQA62A0eGYH6gCsN+xuMVIKRHlTbxa6SPZ pdaGyZA/6+iPzkpWRVLCYRoDyQkHzqbzAJuBg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=roeTAOQB+QwR1lIzLHYZGaMN1zWZGCia0MGLUuLM4+s=; b=UqpnKN8weWQoxoM9kyevwCuTCfnB8XRsCzIuYSLxFO89ejyQNQZPY7ifIxRiqjQ4j5 XC1trvtn32e+++WtWfz7/YPRRqy2O6AE8AbPUDadrt3uB2BIUDgZ0CsoshC+wccwn04n 5xgFj1My9VEg46kafFTAdkACj5753CGTz6YTOEIyB2JKvKKnGu3a3K1OvxP3w+Az3ZJE rvS/2NCFaaSetniYeqJQSsBUS1xdjnUHEGdcdpyGNQyKRlrrGO+rSUFztlT6rqZCvGf2 EO6iTPJRlC0tUcyFmI53H9kzlzgsITzmlIJue1HSRF4e5HBwNTxSPrz7sb27/opupc27 8hXg== X-Gm-Message-State: AGRZ1gKmxnEUCTjjD1Ujg9RCSfZBQNSvF5ZBUUYeL3rTZuRJqB3Jiz+y bif86ZbwpvHXqeZ59TVTvCvbZw== X-Google-Smtp-Source: AJdET5f6CLn+0n9F0vSFG1FQBZ4Cu5XPe4XxgwLHNF74hjO0X5OZFK07k5OR9iTTQ0YAhmZJeW5CjQ== X-Received: by 2002:a63:4d1d:: with SMTP id a29-v6mr18574624pgb.408.1541446533853; Mon, 05 Nov 2018 11:35:33 -0800 (PST) Received: from ?IPv6:2606:4700:ff01:8200:6902:6b79:9380:d370? ([2606:4700:ff01:8200:6902:6b79:9380:d370]) by smtp.gmail.com with ESMTPSA id i26-v6sm32825247pgb.9.2018.11.05.11.35.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 11:35:33 -0800 (PST) From: Brendan McMillion Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_292A524E-534C-414B-AD1F-8FCF178F2C57" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Mon, 5 Nov 2018 11:35:32 -0800 In-Reply-To: Cc: mls@ietf.org To: Nick Sullivan References: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 19:35:40 -0000 --Apple-Mail=_292A524E-534C-414B-AD1F-8FCF178F2C57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry, I re-read your message Nick, and realized I could be clearer. > Does verifying these derived keys that are deeper down the tree = require knowledge of the public keys up the tree? The base scheme always sends the full path starting at the root public = key and ending at the signing key for the current epoch =E2=80=94 this = makes it stateless. Moving to the next epoch requires one of the parents of the current = signing key to certify a new key. If all the verifiers are stateful, = they already know all the parent nodes because the parents were signing = keys for previous epochs. So we don=E2=80=99t need to re-send the = parents, we just need to send the newly certified child. > On Nov 5, 2018, at 10:26 AM, Brendan McMillion = wrote: >=20 > There is the base scheme which has the following properties: > Constant-size public key, private key and signature of size approx = 2*log(T). > Stateless verification. > Not post-compromise secure; can handle minor state regression. >=20 > You can make these modifications to it: > Require verifiers to verify signatures strictly one-after-the-other = and update their understanding of the public key. > Require signers to certify the signing key for epoch N with the = signing key from epoch N-1, regardless of the tree structure. > to get a construction with these properties: > Public key and private key of size approx 2*log(T), constant-size = signature. > Stateful verification. > Post-compromise secure; state regression will lock the user out. >=20 >> On Nov 5, 2018, at 2:48 AM, Nick Sullivan = > wrote: >>=20 >> Brendan, >>=20 >> Does verifying these derived keys that are deeper down the tree = require knowledge of the public keys up the tree? Are these keys = included in the messages (implying a log(depth) increase in message = size) or can they be compressed somehow or are they distributed in some = other manner? >>=20 >> Nick >>=20 >> On Tue, Oct 16, 2018 at 7:03 AM Brendan McMillion = > wrote: >> > We'd need to know the number of epochs we're allowing for this MLS = session in advance. >>=20 >> I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a = tree construction that allows an unbounded number of intervals and fast = setup. The root key would sign only two children: a left child which is = the root of a tree of height 1 whose leaf(s) are used for signing data, = and a right child. Once the left child is used up, the right child signs = two children in the same way the root key did, but now the left child is = the root of a tree of height 2. Every time you have to use the = right-most node, the left child gets twice as large. Here=E2=80=99s a = diagram, if the description isn=E2=80=99t clear: = https://i.imgur.com/DosZ3Sf.png >>=20 >> So the signer=E2=80=99s private key and signatures are proportional = to log(T), the current epoch count. >> > We're simply trying to limit the impact of device compromise. We're = able to do this more easily for encryption keys, but signatures are more = tricky. >>=20 >> I agree it's valuable that if participant A is offline for a long = time and B=E2=80=99s key is compromised at epoch n, then when A comes = back online she can still trust everything signed by B in previous = epochs. I think you can also get something similar to post-compromise = security with the above construction: Once B is no longer compromised, = he would continue walking the tree and generating new keypairs where the = attacker doesn=E2=80=99t know the private keys. So to sign a message, = the attacker would need to certify their own keypairs. This can be = prevented by all the group participants refusing to accept more than one = distinct public key per node in the tree. >>=20 >> On Fri, Oct 12, 2018 at 10:45 PM Nadim Kobeissi = > wrote: >> Dear Brendan, >> Your proposed scheme could work, too. The disadvantages it presents, = it seems to me, aren't severe: >> Your proposed scheme seems to have a larger performance overhead: = each leaf keypair/epoch tuple would have to be generated and signed in = advance. >> We'd need to know the number of epochs we're allowing for this MLS = session in advance. >> We may not be able to parametrize the choice of upcoming signature = keys based on a dynamically generated epoch identifier with the same = degree of freedom that HKD would give us. >> > Also, since I didn=E2=80=99t go to the interim, what problem do = forward-signature signature schemes solve for MLS? >>=20 >> We're simply trying to limit the impact of device compromise. We're = able to do this more easily for encryption keys, but signatures are more = tricky. >>=20 >> Nadim Kobeissi >> Symbolic Software =E2=80=A2 https://symbolic.software = >> Sent from office >>=20 >>=20 >> On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillion = > wrote: >> Hey Nadim >>=20 >> I believe the typical way to build a forward-secure signature scheme = is with a certification tree. You=E2=80=99d: >>=20 >> 1. Generate a root keypair. >> 2. Generate N leaf keypairs. >> 3. Sign each leaf keypair and the epoch it is meant to be used in, = with the root keypair. >> 4. Delete the root private key. >>=20 >> Your root public key is what=E2=80=99s distributed to everybody. A = signature at a given epoch is the tuple: (leaf public key, sig over leaf = key from root key, sig over data from leaf key). >>=20 >> Could you talk about why a scheme like the above is not suitable = here? Also, since I didn=E2=80=99t go to the interim, what problem do = forward-signature signature schemes solve for MLS? >>=20 >>> On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi > wrote: >>>=20 >>> Dear Ted, >>> Thanks for your quick read-through! >>>=20 >>> You seem to be referring to [1], not to [2] as you wrote. In [1], = the concept of "hardened" keys is defined and is also ported by [2] into = Ed25519. >>>=20 >>> > What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >>>=20 >>> This is correct in the sense that it allows you to rewind the key = derivation chain. However, this does not apply to hardened keys. This is = precisely why I'm trying to understand how epoch identifiers are agreed = upon, in order to see whether we can use them to restrict the HKD logic = to use only "hardened" keys in MLS. Since hardened keys in [2] cannot = themselves have children, it becomes important to understand whether we = can select enough of them for an HKD design in MLS to have a meaningful = impact, and how this selection/potential caching of hardened keys would = work. >>>=20 >>> > [...] means that Alice must refrain from ever using the parent = extended public key has a signing key, but must instantiate signing keys = from the n + 0 epoch. =20 >>>=20 >>> This could also be a solution, I suppose, but it sounds like it = would result in weaker "signing forward secrecy" (or whatever we're = calling this property) than focusing on hardened keys, although I'm = frankly not sure off the top of my head. >>>=20 >>> Nadim Kobeissi >>> Symbolic Software =E2=80=A2 https://symbolic.software = >>> Sent from office >>>=20 >>>=20 >>> On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie > wrote: >>> Hi Nadim, >>>=20 >>> I suspect I'm missing something simple here in your proposal. = According to your reference 2, one of the issues with the derivation of = this type of hierarchical key is: >>>=20 >>> that knowledge of a parent extended public key plus any = non-hardened private key descending from it is equivalent to knowing the = parent extended private key (and thus every private and public key = descending from it). This means that extended public keys must be = treated more carefully than regular public keys. It is also the reason = for the existence of hardened keys, and why they are used for the = account level in the tree. This way, a leak of account-specific (or = below) private key never risks compromising the master or other = accounts. >>>=20 >>> What I think that means is that if an attacker ever gets access to = both an extended public key and any extended private key, we have lost = forward secrecy for all the MLS communications covered by any keys = derived from any of the epoch pairs. Is that correct? >>>=20 >>> This appears to make handling required of the parent extended public = key roughly equivalent to the handling of a private key, so that your = step: >>>=20 >>> Alice sends a public signing key to Bob during epoch n. >>>=20 >>> means that Alice must refrain from ever using the parent extended = public key has a signing key, but must instantiate signing keys from the = n + 0 epoch. =20 >>>=20 >>> Is that a correct understanding? >>>=20 >>> Thanks, >>>=20 >>> Ted >>>=20 >>>=20 >>> On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi = > wrote: >>> Hello everyone, >>>=20 >>> I've been working on adapting Hierarchical Key Derivation (HKD) in = order to obtain some kind of ephemeral signatures that may be useful in = MLS. I've arrived at a point where I'm optimistic that this is a = direction worth pursuing and might indeed be a solution to this problem. >>>=20 >>> HKD was at some point a candidate for how signature keys are managed = per epoch in the Tor Hidden Service design [0]. HKD logic has also been = implemented in Bitcoin wallets for a while now [1]. HKD constructions = can be also derived from existing popular fast signature algorithms such = as Ed25519 with minimal changes [2], making them an easy fit for MLS. = Very simply, the functionality that HKD signature schemes bring to MLS = is the following: >>> Alice sends a public signing key to Bob during epoch n. >>> At the onset of epoch n+1, Bob is able to immediately calculate = Alice's public signing key for epoch n+1 based purely on his knowledge = of Alice's public signing key for epoch 0. Alice doesn't need to send = new signing key information to Bob. >>> At this point, Bob can delete Alice's public signing key for epoch = n. >>> More importantly, Alice herself can delete Alice's private signing = key for epoch n, keeping only her private signing key for epoch n+1. >>> The way that this could work in MLS would be heavily based on = HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead will = point out the relevant sections (which are short, well-written and worth = reading:) >>> Section 2 describes the original concept as used for Bitcoin wallet = derivation. >>> Section 4 describes the modifications to Ed25519 to enable HKD = constructions. >>> Section 5 describes how private and public child keys are generated = (Fig. 1 is also helpful.) >>> My questions: >>> How are we deriving epoch identifiers? Are they simply counters, or = each epoch identified by a nonce that's communicated confidentially? If = you read [2], you'll see why this can be important. >>> Performance impact seems to be negligible for Montgomery-based = signing primitives, but I'm interested in more insight on this. >>> Is anyone else interested in having a standard HDKeys-Ed25519 = implementation? I've been working on one in JavaScript and plan to = eventually also write one in Go. Perhaps Richard would like to help with = a C++ version? >>> I'm also interested in hearing your thoughts on this generally. >>> During the interim meeting (as well as before it), it was frequently = discussed how ephemeral signatures may be useful for MLS. This also = appears to be slated as a discussion topic for IETF 103, so it would be = great if we could continue the discussion there as well.=20 >>>=20 >>> References: >>> [0] = https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.= txt#n1979 = >>> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki = >>> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf = >>>=20 >>> Nadim Kobeissi >>> Symbolic Software =E2=80=A2 https://symbolic.software = >>> Sent from office >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 --Apple-Mail=_292A524E-534C-414B-AD1F-8FCF178F2C57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry, I re-read your message Nick, and realized I could be = clearer.

    > Does verifying these derived keys that are deeper = down the tree require knowledge of the public keys up the = tree?

    The base = scheme always sends the full path starting at the root public key and = ending at the signing key for the current epoch =E2=80=94 this makes it = stateless.

    Moving to the next epoch requires one of the parents of the = current signing key to certify a new key. If all the verifiers are = stateful, they already know all the parent nodes because the parents = were signing keys for previous epochs. So we don=E2=80=99t need to = re-send the parents, we just need to send the newly certified child.

    On Nov 5, 2018, at 10:26 AM, Brendan McMillion <brendan@cloudflare.com> wrote:

    There is the base = scheme which has the following properties:
    • Constant-size public key, private = key and signature of size approx 2*log(T).
    • Stateless = verification.
    • Not post-compromise secure; can = handle minor state regression.

    You can make these modifications to = it:
    • Require = verifiers to verify signatures strictly one-after-the-other and update = their understanding of the public key.
    • Require = signers to certify the signing key for epoch N with the signing key from = epoch N-1, regardless of the tree structure.
    to = get a construction with these properties:
    • Public key and private key of size = approx 2*log(T), constant-size signature.
    • Stateful = verification.
    • Post-compromise secure; state = regression will lock the user out.

    On Nov = 5, 2018, at 2:48 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

    Brendan,

    Does verifying these derived keys that are deeper down the = tree require knowledge of the public keys up the tree? Are these keys = included in the messages (implying a log(depth) increase in message = size) or can they be compressed somehow or are they distributed in some = other manner?

    Nick

    On Tue, Oct 16, 2018 = at 7:03 AM Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:
    > We'd need to know the = number of epochs we're allowing for this MLS session in advance.

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

    So the = signer=E2=80=99s private key and signatures are proportional to log(T), = the current epoch count.
    > We're simply trying to limit the impact of device compromise. We're=20 able to do this more easily for encryption keys, but signatures are more tricky.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

    Is that a correct understanding?

    Thanks,

    Ted


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

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

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

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

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

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


    = --Apple-Mail=_292A524E-534C-414B-AD1F-8FCF178F2C57-- From nobody Mon Nov 5 21:13:00 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FBF130E84 for ; Mon, 5 Nov 2018 21:12:53 -0800 (PST) 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 nqyQZrNCq9oN for ; Mon, 5 Nov 2018 21:12:49 -0800 (PST) Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (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 CD2F9129619 for ; Mon, 5 Nov 2018 21:12:48 -0800 (PST) Received: by mail-ua1-x942.google.com with SMTP id p9so83488uaa.5 for ; Mon, 05 Nov 2018 21:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HwMtl8ivdyASmxaRZ02+szvby3N7f+XbbeBD1xu7rsU=; b=ucczYfkEhCPRaDiltKfmCEMzjUYQeRjGyApYNaYhIwCJxcBkuxFfv8IceO5cHEvOT7 2w1d/Ky+8v7AgHq5TZRiMvIPqp9+/qZhD3jpioREaFZXWW6h7CLtp4smPweDXyd6APc/ rwtxenAY255adqsyyRwap2FvMtjXhphnOkrYLPx4eJ94MjBYASV/ZMhzp0sAbPusSK4E osAK0mLfqnMLJPoDHmJkXID5aIQxy1Km7IQ7cjfUgU6etCWPoNMuUzVb3wQQdzutR4wK U8jkm9OIRAi7jiQuYgBWRqrDtqoefP6ZdNyOoxQLOy3Ti+f8VsTTVh4BHxJYCi7r/a0O HzjA== 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=HwMtl8ivdyASmxaRZ02+szvby3N7f+XbbeBD1xu7rsU=; b=Q1z4bcT6dDJCbsi3VItc99ahlRmkJ7jKe6R+bXy5q3oABr32NY7H0Xu1ECxTVA+C0Q xNza2wjQBBjKhZpD4p6rI8NJQLEP42bLrmTnvls2/txa6x0Wup89egv9KJS+i84MNGyv ORN+qQt08cvhXxglBY2YGmBjx28CksyRUo3LmQukIXIPZwYiSvbwvbluKBsaW+arVm9O 7JTOXzanYTfjWWctqGyxTN54VoAGv6lBTaafQqDiqbni4u+E1jpV4+a5pB6NXAobwkHQ 4NNDNOflcDOiIfvmOwbO9gqof31oJ3ADeAFyfViUVVPMeqOcypNDp34KHfAiIeXbMwLy myfA== X-Gm-Message-State: AGRZ1gLGUmbZyoinXYCzajfcv0dRuPi2CRL/k88uwAMYj1879J1Na9pJ Ct4nxPy0HM3C8tX8DMUWWB2XsXddmETqNTB5IKsQZIGf X-Google-Smtp-Source: AJdET5cClysKsh+DFSv0Hufc9PXvX53qTmaxAP/nb+NSXpSBE1PeKUiyHksl5nxcQW48adq2ygAi8XmO8FmYKOG7j18= X-Received: by 2002:ab0:2981:: with SMTP id u1mr11690554uap.96.1541481167704; Mon, 05 Nov 2018 21:12:47 -0800 (PST) MIME-Version: 1.0 References: <0D3E4C60-1768-4661-85D5-AFA7B188DB0C@cloudflare.com> In-Reply-To: From: Jonathan Hoyland Date: Tue, 6 Nov 2018 13:12:01 +0800 Message-ID: To: "nadim@symbolic.software" Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000006dd9c20579f80d66" Archived-At: Subject: Re: [MLS] Adapting Hierarchical Key Derivation for Ephemeral Signatures in MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 05:12:58 -0000 --0000000000006dd9c20579f80d66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nadim, I was thinking about what was said yesterday about a PFS-style guarantee for authentication and to me that sounds very much like a compound authentication property (see def. 2 on page 4 of [1]). Compound authentication describes the relationship between multiple authentications within a single compound / layered protocol. We can view MLS with hierarchical keys as a series of authentications. If we consider a situation in which each epoch has a separate authentication step (e.g. proves possession of some new key), then we can use the lens of compound authentication. Specifically, compound authentication says that as long as a single authentication step in a compound protocol was successful and has an uncompromised key, then all other apparently successful authentication attempts (past and future) were/will be authentic, even if all the keys associated with the other layers are compromised. This is obviously a very strong guarantee, and there are weaker forms that may be more applicable, such as only requiring past layers to be authentic, but as a general idea of the type of guarantee we might want from HDKs I think it has some merit. Compound authentication neatly describes the authentication goals in the case of partial compromise, i.e. compound authentication can leverage a single uncompromised credential to authenticate authentication attempts using compromised credentials. For example, if an actor, A, is running a compound protocol with B, and A has two credentials, c_1 and c_2, with associated secrets, s_1 and s_2, and c_2 is compromised (i.e. the attacker knows the associated secret, s_2), and B completes an authentication step that uses c_2, B should be able to prove that it was running the protocol with A, even though the attacker also knows s_2. The definition in [1] assumes that the keys are independent, which wouldn't be the case if the master key is compromised, but if we assume that the master key is uncompromised then the derived keys are in some way independent. Does that make any sense? Regards, Jonathan Hoyland [1] Bhargavan, K., Delignat-Lavaud, A., & Pironti, A. (2015, February). Verified Contributive Channel Bindings for Compound Authentication . In NDSS. On Tue, 6 Nov 2018 at 02:35 Brendan McMillion wrote: > Sorry, I re-read your message Nick, and realized I could be clearer. > > > Does verifying these derived keys that are deeper down the tree require > knowledge of the public keys up the tree? > > The base scheme always sends the full path starting at the root public ke= y > and ending at the signing key for the current epoch =E2=80=94 this makes = it > stateless. > > Moving to the next epoch requires one of the parents of the current > signing key to certify a new key. If all the verifiers are stateful, they > already know all the parent nodes because the parents were signing keys f= or > previous epochs. So we don=E2=80=99t need to re-send the parents, we just= need to > send the newly certified child. > > > On Nov 5, 2018, at 10:26 AM, Brendan McMillion > wrote: > > There is the base scheme which has the following properties: > > - Constant-size public key, private key and signature of size approx > 2*log(T). > - Stateless verification. > - Not post-compromise secure; can handle minor state regression. > > > You can make these modifications to it: > > - Require verifiers to verify signatures strictly one-after-the-other > and update their understanding of the public key. > - Require signers to certify the signing key for epoch N with the > signing key from epoch N-1, regardless of the tree structure. > > to get a construction with these properties: > > - Public key and private key of size approx 2*log(T), constant-size > signature. > - Stateful verification. > - Post-compromise secure; state regression will lock the user out. > > > On Nov 5, 2018, at 2:48 AM, Nick Sullivan < > nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > > Brendan, > > Does verifying these derived keys that are deeper down the tree require > knowledge of the public keys up the tree? Are these keys included in the > messages (implying a log(depth) increase in message size) or can they be > compressed somehow or are they distributed in some other manner? > > Nick > > On Tue, Oct 16, 2018 at 7:03 AM Brendan McMillion 40cloudflare.com@dmarc.ietf.org <40cloudflare.com@dmarc.ietf..org>> wrote= : > >> > We'd need to know the number of epochs we're allowing for this MLS >> session in advance. >> >> I=E2=80=99d link the paper if I could find it, but there=E2=80=99s a tre= e construction >> that allows an unbounded number of intervals and fast setup. The root ke= y >> would sign only two children: a left child which is the root of a tree o= f >> height 1 whose leaf(s) are used for signing data, and a right child. Onc= e >> the left child is used up, the right child signs two children in the sam= e >> way the root key did, but now the left child is the root of a tree of >> height 2. Every time you have to use the right-most node, the left child >> gets twice as large. Here=E2=80=99s a diagram, if the description isn=E2= =80=99t clear: >> https://i.imgur.com/DosZ3Sf.png >> >> So the signer=E2=80=99s private key and signatures are proportional to l= og(T), >> the current epoch count. >> > We're simply trying to limit the impact of device compromise. We're >> able to do this more easily for encryption keys, but signatures are more >> tricky. >> >> I agree it's valuable that if participant A is offline for a long time >> and B=E2=80=99s key is compromised at epoch n, then when A comes back on= line she >> can still trust everything signed by B in previous epochs. I think you c= an >> also get something similar to post-compromise security with the above >> construction: Once B is no longer compromised, he would continue walking >> the tree and generating new keypairs where the attacker doesn=E2=80=99t = know the >> private keys. So to sign a message, the attacker would need to certify >> their own keypairs. This can be prevented by all the group participants >> refusing to accept more than one distinct public key per node in the tre= e. >> >> On Fri, Oct 12, 2018 at 10:45 PM Nadim Kobeissi >> wrote: >> >>> Dear Brendan, >>> Your proposed scheme could work, too. The disadvantages it presents, it >>> seems to me, aren't severe: >>> >>> - Your proposed scheme seems to have a larger performance overhead: >>> each leaf keypair/epoch tuple would have to be generated and signed = in >>> advance. >>> - We'd need to know the number of epochs we're allowing for this MLS >>> session in advance. >>> - We may not be able to parametrize the choice of upcoming signature >>> keys based on a dynamically generated epoch identifier with the same= degree >>> of freedom that HKD would give us. >>> >>> > Also, since I didn=E2=80=99t go to the interim, what problem do >>> forward-signature signature schemes solve for MLS? >>> >>> We're simply trying to limit the impact of device compromise. We're abl= e >>> to do this more easily for encryption keys, but signatures are more tri= cky. >>> >>> Nadim Kobeissi >>> Symbolic Software =E2=80=A2 https://symbolic.software >>> >>> Sent from office >>> >>> >>> On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillion < >>> brendan@cloudflare.com> wrote: >>> >>>> Hey Nadim >>>> >>>> I believe the typical way to build a forward-secure signature scheme i= s >>>> with a certification tree. You=E2=80=99d: >>>> >>>> 1. Generate a root keypair. >>>> 2. Generate N leaf keypairs. >>>> 3. Sign each leaf keypair and the epoch it is meant to be used in, wit= h >>>> the root keypair. >>>> 4. Delete the root private key. >>>> >>>> Your root public key is what=E2=80=99s distributed to everybody. A sig= nature at >>>> a given epoch is the tuple: (leaf public key, sig over leaf key from r= oot >>>> key, sig over data from leaf key). >>>> >>>> Could you talk about why a scheme like the above is not suitable here? >>>> Also, since I didn=E2=80=99t go to the interim, what problem do forwar= d-signature >>>> signature schemes solve for MLS? >>>> >>>> On Oct 12, 2018, at 1:22 PM, Nadim Kobeissi >>>> wrote: >>>> >>>> Dear Ted, >>>> Thanks for your quick read-through! >>>> >>>> You seem to be referring to [1], not to [2] as you wrote. In [1], the >>>> concept of "hardened" keys is defined and is also ported by [2] into >>>> Ed25519. >>>> >>>> > What I think that means is that if an attacker ever gets access to >>>> both an extended public key and any extended private key, we have lost >>>> forward secrecy for all the MLS communications covered by any keys der= ived >>>> from any of the epoch pairs. Is that correct? >>>> >>>> This is correct in the sense that it allows you to rewind the key >>>> derivation chain. However, this does not apply to hardened keys. This = is >>>> precisely why I'm trying to understand how epoch identifiers are agree= d >>>> upon, in order to see whether we can use them to restrict the HKD logi= c to >>>> use only "hardened" keys in MLS. Since hardened keys in [2] cannot >>>> themselves have children, it becomes important to understand whether w= e can >>>> select enough of them for an HKD design in MLS to have a meaningful im= pact, >>>> and how this selection/potential caching of hardened keys would work. >>>> >>>> > [...] means that Alice must refrain from ever using the parent >>>> extended public key has a signing key, but must instantiate signing ke= ys >>>> from the n + 0 epoch. >>>> >>>> This could also be a solution, I suppose, but it sounds like it would >>>> result in weaker "signing forward secrecy" (or whatever we're calling = this >>>> property) than focusing on hardened keys, although I'm frankly not sur= e off >>>> the top of my head. >>>> >>>> Nadim Kobeissi >>>> Symbolic Software =E2=80=A2 https://symbolic.software >>>> Sent from office >>>> >>>> >>>> On Fri, Oct 12, 2018 at 10:03 PM Ted Hardie wrote= : >>>> >>>>> Hi Nadim, >>>>> >>>>> I suspect I'm missing something simple here in your proposal. >>>>> According to your reference 2, one of the issues with the derivation = of >>>>> this type of hierarchical key is: >>>>> >>>>> that knowledge of a parent extended public key plus any non-hardened >>>>>> private key descending from it is equivalent to knowing the parent e= xtended >>>>>> private key (and thus every private and public key descending from i= t). >>>>>> This means that extended public keys must be treated more carefully = than >>>>>> regular public keys. It is also the reason for the existence of hard= ened >>>>>> keys, and why they are used for the account level in the tree. This = way, a >>>>>> leak of account-specific (or below) private key never risks compromi= sing >>>>>> the master or other accounts. >>>>>> >>>>> >>>>> What I think that means is that if an attacker ever gets access to >>>>> both an extended public key and any extended private key, we have los= t >>>>> forward secrecy for all the MLS communications covered by any keys de= rived >>>>> from any of the epoch pairs. Is that correct? >>>>> >>>>> This appears to make handling required of the parent extended public >>>>> key roughly equivalent to the handling of a private key, so that your= step: >>>>> >>>>> Alice sends a public signing key to Bob during epoch n. >>>>> >>>>> means that Alice must refrain from ever using the parent extended >>>>> public key has a signing key, but must instantiate signing keys from = the n >>>>> + 0 epoch. >>>>> >>>>> Is that a correct understanding? >>>>> >>>>> Thanks, >>>>> >>>>> Ted >>>>> >>>>> >>>>> On Fri, Oct 12, 2018 at 12:47 PM Nadim Kobeissi < >>>>> nadim@symbolic.software> wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I've been working on adapting Hierarchical Key Derivation (HKD) in >>>>>> order to obtain some kind of ephemeral signatures that may be useful= in >>>>>> MLS. I've arrived at a point where I'm optimistic that this is a dir= ection >>>>>> worth pursuing and might indeed be a solution to this problem. >>>>>> >>>>>> HKD was at some point a candidate for how signature keys are managed >>>>>> per epoch in the Tor Hidden Service design [0]. HKD logic has also b= een >>>>>> implemented in Bitcoin wallets for a while now [1]. HKD construction= s can >>>>>> be also derived from existing popular fast signature algorithms such= as >>>>>> Ed25519 with minimal changes [2], making them an easy fit for MLS. V= ery >>>>>> simply, the functionality that HKD signature schemes bring to MLS is= the >>>>>> following: >>>>>> >>>>>> - Alice sends a public signing key to Bob during epoch n. >>>>>> - At the onset of epoch n+1, Bob is able to immediately calculate >>>>>> Alice's public signing key for epoch n+1 based purely on his know= ledge of >>>>>> Alice's public signing key for epoch 0. Alice doesn't need to sen= d new >>>>>> signing key information to Bob. >>>>>> - At this point, Bob can delete Alice's public signing key for >>>>>> epoch n. >>>>>> - More importantly, Alice herself can delete Alice's private >>>>>> signing key for epoch n, keeping only her private signing key for= epoch n+1. >>>>>> >>>>>> The way that this could work in MLS would be heavily based on >>>>>> HDKeys-Ed25519 [2]. I'll resist paraphrasing the paper, and instead = will >>>>>> point out the relevant sections (which are short, well-written and w= orth >>>>>> reading:) >>>>>> >>>>>> - Section 2 describes the original concept as used for Bitcoin >>>>>> wallet derivation. >>>>>> - Section 4 describes the modifications to Ed25519 to enable HKD >>>>>> constructions. >>>>>> - Section 5 describes how private and public child keys are >>>>>> generated (Fig. 1 is also helpful.) >>>>>> >>>>>> My questions: >>>>>> >>>>>> - How are we deriving epoch identifiers? Are they simply >>>>>> counters, or each epoch identified by a nonce that's communicated >>>>>> confidentially? If you read [2], you'll see why this can be impor= tant. >>>>>> - Performance impact seems to be negligible for Montgomery-based >>>>>> signing primitives, but I'm interested in more insight on this. >>>>>> - Is anyone else interested in having a standard >>>>>> HDKeys-Ed25519 implementation? I've been working on one in JavaSc= ript and >>>>>> plan to eventually also write one in Go. Perhaps Richard would li= ke to help >>>>>> with a C++ version? >>>>>> - I'm also interested in hearing your thoughts on this generally. >>>>>> >>>>>> During the interim meeting (as well as before it), it was frequently >>>>>> discussed how ephemeral signatures may be useful for MLS. This also = appears >>>>>> to be slated as a discussion topic for IETF 103, so it would be grea= t if we >>>>>> could continue the discussion there as well. >>>>>> >>>>>> References: >>>>>> [0] >>>>>> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-sp= ec-ng.txt#n1979 >>>>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki >>>>>> [2] https://cardanolaunch.com/assets/Ed25519_BIP.pdf >>>>>> >>>>>> Nadim Kobeissi >>>>>> Symbolic Software =E2=80=A2 https://symbolic.software >>>>>> Sent from office >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>> >>>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>>> >>>> _______________________________________________ >> 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 > --0000000000006dd9c20579f80d66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Nadim,=C2=A0

    I was thinki= ng about what was said yesterday about a PFS-style guarantee for authentica= tion and to me that sounds very much like a compound authentication propert= y (see def. 2 on page 4 of [1]).
    Compound authentication describe= s the relationship between multiple authentications within a single compoun= d / layered protocol.
    We can view MLS with hierarchical keys as a= series of authentications.=C2=A0

    If we consider a= situation in which each epoch has a separate authentication step (e.g. pro= ves possession of some new key), then we can use the lens of compound authe= ntication.
    Specifically, compound authentication says that as lon= g as a single authentication step in a compound protocol was successful and= has an uncompromised key, then all other apparently successful authenticat= ion attempts (past and future) were/will be authentic, even if all the keys= associated with the other layers are compromised.
    This is obviou= sly a very strong guarantee, and there are weaker forms that may be more ap= plicable, such as only requiring past layers to be authentic, but as a gene= ral idea of the type of guarantee we might want from HDKs I think it has so= me merit.=C2=A0

    Compound authentication neatly des= cribes the authentication goals in the case of partial compromise, i.e. com= pound authentication can leverage a single uncompromised credential to auth= enticate authentication attempts using compromised credentials.
    F= or example, if an actor, A, is running a compound protocol with B, and A ha= s two credentials, c_1 and c_2, with associated secrets, s_1 and s_2, =C2= =A0and c_2 is compromised (i.e. the attacker knows the associated secret, s= _2), and B completes an authentication step that uses c_2, B should be able= to prove that it was running the protocol with A, even though the attacker= also knows s_2.=C2=A0
    =C2=A0
    The definition in [1] ass= umes that the keys are independent, which wouldn't be the case if the m= aster key is compromised, but if we assume that the master key is uncomprom= ised then the derived keys are in some way independent.

    Does that make any sense?

    Regards,

    Jonathan Hoyland

    [1] Bhargavan, K.= , Delignat-Lavaud, A., & Pironti, A. (2015, February). = Verified Contributive Channel Bindings for Compound Authentication. In = NDSS.


    O= n Tue, 6 Nov 2018 at 02:35 Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> = wrote:
    Sorry, I re-read your message Nick, an= d realized I could be clearer.

    >=C2=A0Does verifying thes= e derived keys that are deeper down the tree require knowledge of the publi= c keys up the tree?

    The base scheme always sends the f= ull path starting at the root public key and ending at the signing key for = the current epoch =E2=80=94 this makes it stateless.

    Moving to the next epoch requires one of the parents of the current sign= ing key to certify a new key. If all the verifiers are stateful, they alrea= dy know all the parent nodes because the parents were signing keys for prev= ious epochs. So we don=E2=80=99t need to re-send the parents, we just need = to send the newly certified child.


    On Nov 5, 2018, at 10:26 AM, Brendan McMillion <brendan@cloudflare.com>= ; wrote:

    =
    There= is the base scheme which has the following properties:
    • Constant-size public key, private key a= nd signature of size approx 2*log(T).
    • Stateless verification.
      • <= li>Not post-compromise secure;=C2=A0can handle minor state regression.=

    You can make these modifications to it:
    =
    • Require verifiers to ver= ify signatures strictly one-after-the-other and update their understanding = of the public key.
    • Require signers to certify the signing key for e= poch N with the signing key from epoch N-1, regardless of the tree structur= e.
    to get a construction with these properties:
    • Public key and privat= e key of size approx 2*log(T), constant-size signature.
    • Stateful ve= rification.
    • Post-compromise secure; state regression will lock the = user out.

    On Nov 5, = 2018, at 2:48 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org= > wrote:

    Brendan,

    Does verifying the= se derived keys that are deeper down the tree require knowledge of the publ= ic keys up the tree? Are these keys included in the messages (implying a lo= g(depth) increase in message size) or can they be compressed somehow or are= they distributed in some other manner?

    Nick
    =

    On Tue, Oct 16, 2018 a= t 7:03 AM Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org>= ; wrote:
    > We'd need to know the number of epochs we're allowing for t= his MLS session in advance.

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

    So the signer=E2=80= =99s private key and signatures are proportional to log(T), the current epo= ch count.
    > We're simply trying to limit the impact of device compromise. We'r= e=20 able to do this more easily for encryption keys, but signatures are more tricky.

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

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

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

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


    On Sat, Oct 13, 2018 at 2:43 AM Brendan McMillio= n <brendan@c= loudflare.com> wrote:
    Hey Nadim
    I believe the typical way to build a forward-secure signatu= re scheme is with a certification tree. You=E2=80=99d:

    =
    1. Generate a root keypair.
    2. Generate N leaf keypairs.
    3. Sign each leaf keypair and the epoch it is meant to be used in, w= ith the root keypair.
    4. Delete the root private key.
    <= br>
    Your root public key is what=E2=80=99s distributed to everybo= dy. A signature at a given epoch is the tuple: (leaf public key, sig over l= eaf key from root key, sig over data from leaf key).

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

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

    Dear Ted,
    Thanks for your quick read-through!
    <= br>
    You seem to be referring to [1], not to [2] as you wrote. In = [1], the concept of "hardened" keys is defined and is also ported= by [2] into Ed25519.

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

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

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

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


    H= i Nadim,

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

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

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

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

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

    Is that a correct understanding?=

    Thanks,

    Ted


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

    I've been working on adapting Hierarchi= cal Key Derivation (HKD) in order to obtain some kind of ephemeral signatur= es that may be useful in MLS. I've arrived at a point where I'm opt= imistic that this is a direction worth pursuing and might indeed be a solut= ion to this problem.

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

    References:
    =
    [2]=C2=A0https://cardanolaunch.com/assets/Ed25519_BIP.pdf

    Nadim Kobeissi
    Symbolic So= ftware=C2=A0=E2=80=A2 <= a href=3D"https://symbolic.software/" target=3D"_blank">https://symbolic.so= ftware
    Sent from office
    _______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://www.ietf.org/mailman/listinfo/mls
    _______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://ww= w.ietf.org/mailman/listinfo/mls

    <= /div>
    _______________________________________________
    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
    --0000000000006dd9c20579f80d66-- From nobody Wed Nov 7 22:48:12 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 1E393130EE2 for ; Wed, 7 Nov 2018 22:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 VlxigeoZhQsa for ; Wed, 7 Nov 2018 22:48:04 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAB2130DEF for ; Wed, 7 Nov 2018 22:48:03 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id y10-v6so8946300edr.4 for ; Wed, 07 Nov 2018 22:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=NhFRGXaEprdr/66jAd1ysk6FtSkhABuSELuSRJp0IbE=; b=ln1pW0NF5IgVC9WEFFoVI162pmJe233rJBn2ewaMdQS2JXv+dd3qZQ8RS43Y83fYRf tn0ZhDPNnKREIAQ70HwuYeM2ZBTEvwj+PJ7EX8cwIGVPtejuG9l6WK3k+XbwoRSFUQel 4FYAsxihIzspd3setohPq+9s0SpvX+ShbgzPA= 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:cc:to; bh=NhFRGXaEprdr/66jAd1ysk6FtSkhABuSELuSRJp0IbE=; b=MK+4w8yshp4PuitjUgonQeS4XKOlZsGPymIZSKpjGIHC1gBTgtlYwpQivzVhCj3ClR B6croh/0KkmNoTB1H5Zb+Yhvc3NoPDIPnD77zS2nTEjob4D3dLgTu3Bk5aC8GfIxupoi ia6l6n5sIu/EzFmp6Yvz5qL3zM54bSNxqak5wvvd4YVTjnRJ7peWZN+fKrloM08FbGH2 xsaa/wzWsloTFPl0mwyOXdFtcGI0VCR+Vc1+tjQohSotbQMTWnCObBj6L7E2UZD667mV +NJ/Jf0F++WmNnWZ4Xk/D7XLJuIVzq0TwN81T+g8dKh614nYeOO1uO7VHNepaljjWM4B Lfnw== X-Gm-Message-State: AGRZ1gI60BZWjt3WY3QahO6GsZWsCdHUDw14WKalYsZMCRTLcNZsV0fT lL8jImCRO+3Amo6s0Ejp+MX8Nw== X-Google-Smtp-Source: AJdET5djc+Acv04FKdTY6WDElhURLTo/UMDm+eTzuNhcCDiq6oL/qZCXhA4XuB2cCrtqatsKVp/TiQ== X-Received: by 2002:a17:906:e9c4:: with SMTP id kb4-v6mr2045638ejb.97.1541659682421; Wed, 07 Nov 2018 22:48:02 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:14c2:1cc:a7a5:8f2c? ([2001:67c:370:128:14c2:1cc:a7a5:8f2c]) by smtp.gmail.com with ESMTPSA id i10-v6sm444972ejh.71.2018.11.07.22.48.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 22:48:01 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Thu, 8 Nov 2018 13:47:59 +0700 Cc: mls@ietf.org To: saag@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] MLS@IETF103 report 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, 08 Nov 2018 06:48:10 -0000 MLS met at 16:10 on Monday and 11:20 on Wednesday. Here is the summary of the two MLS sessions, and this has also been submitted as status in datatracker (https://datatracker.ietf.org/group/mls/about/status/edit/): On Monday we discussed several of the current drafts and made some progress in understanding the design options and moving the documents forward. The architecture document was presented by Emad Omara, which was mostly uncontroversial. The protocol document took most of the time at this meeting. The big problem of group members having access to the keys of multiple group members (the double-join problem) was discussed at length. Most of the issues were around efficiency and making sure that any double-join protection mechanism continues to be logarithmic instead of devolving into linear time. New ideas were introduced around group initialization and giving a special exception to the group initializer = =E2=80=94 which was a promising idea. Nadim Kobeissi presented remotely about authentication which illustrated how derived signature keys could = improve the situation where authentication keys are compromised. =20 On Thursday we reviewed the message protection draft, recapping the work that was presented at the interim about message protection. This led to a vigorous debate about forward secrecy. We also discussed a potential interim in January in San Jose, CA in order to take advantage of the presence of Real World Crypto. N&S= From nobody Thu Nov 8 08:09:57 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 EAF4B128766 for ; Thu, 8 Nov 2018 08:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s11T2yB8yOyh for ; Thu, 8 Nov 2018 08:09:53 -0800 (PST) Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B0A129619 for ; Thu, 8 Nov 2018 08:09:50 -0800 (PST) Received: (qmail 37042 invoked by uid 0); 8 Nov 2018 16:06:08 -0000 Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 8 Nov 2018 16:06:08 -0000 Date: Thu, 8 Nov 2018 14:09:36 -0200 From: Sofia To: mls@ietf.org Cc: jurre@autonomia.digital, shivankaulsahib@gmail.com Message-ID: <20181108160935.GA4116@Sofias-MBP> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [MLS] Contribute as OTRv4 to MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 16:09:57 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear contributors to MLS, During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4 specification and implementation during the PEARG session (https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4-= slides-01). During the Q/A we had some nice words from some of you (some people said th= at it will be nice if the OTRv4 team could contribute with MLS) and, so, we'd = like to contribute to MLS and see how to work together! We have been looking at = some of the material of MLS shared during IETF 103 and we will like to start contributing from it! Best, The OTRv4 team -- Sof=EDa Celi (aka cherenkov) @claucece / @cherenkov_d Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE73QaX1aS5W8U9iQ8OZJhRPidmW8FAlvkX7sACgkQOZJhRPid mW9JNw//QaapCr+hedxI13EDhmO/2sORONgn8m9WIQ0S9tS0Xv3UZVGnThNmXIs6 DXx4ECuhey0y7QZA3h+Hdj+mU3/XoyR96oM1i0xoqjvvEXs6ITUuI1I/HfO6lRMw 003KXMhCQlviZgzRNnCqYf3IbBGliqwZGK7J8LDjrNo4DE+MgHClU3a8sa9aw7oI brHERe20SRFBf7jBS87DlOr2cZdZBqUky7/LpbA1fbYbPNmGLI6cmcuw9NQGhyhk 6qtUv5Yycz/y5+Zpx7EO9/oVvy9aSUxKL+JEBv7u8j8fE1VB/aVYcCCA+p50QM/A 5gP//qcRMpLRJSI52xXdNfnKmOs2zZDjD+77OrMTmm3JguuA7Uav+5R11O7KpvB0 GiuA4P5HrEdltqozO4BG7mJLOzfxHfDgIv4c0QTHQE25UDLeYi2FqJP1+XGFMsSq iegsYuuCG11cb5o/r6wbkc0LgJ3hID5w/CWxsJ43lzLlzF+FIY/po2902stcv5xA tSEDDixzwCqHPNS6gwsCKBGIaXb/iRhnsKNywemBo8DYV4g80udsP7ezIH2bMz3E 53P8rnrFen6PxYO9EmCGy33t90jNF2bh4wEsNr2J/mXezBsood3jL6h9k02kvJ98 djAQEK8r1wcmPLrMSTLzk9cFT5XdE72o6YsfO9WHBJyxXQjH0Fk= =HiV5 -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From nobody Thu Nov 8 08:32:32 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 B459E131051 for ; Thu, 8 Nov 2018 08:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mozilla.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 EbHLkL91R9-n for ; Thu, 8 Nov 2018 08:32:26 -0800 (PST) Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 D8232131041 for ; Thu, 8 Nov 2018 08:32:25 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id d6so2437764itl.4 for ; Thu, 08 Nov 2018 08:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=om3jOU8jVhMQjpcUmjSMmooK7WHqF/yURiJbrFIXqOs=; b=A+jQxeBBPDVF1HLRSRcTtuLUr3oT4f/NV++KFExuP32Hie6azzfWxNlQJgPgMwFbsN uZthQGxIERYB50BMnnVntv42Yt8ZkRgBb3es4y2uPbF4NFUONQTCKLeUBt2P6CHtFlsM OKY9v3mHY3iAcDnj81xayz7x3TFEZJuBg4l2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=om3jOU8jVhMQjpcUmjSMmooK7WHqF/yURiJbrFIXqOs=; b=UuJ1XL3LCbXN+4ICJuRAuwpgSLzmJbfHK8S8kiNLjQ2TVLAqfnROaP4pDxmYbt5jcK CgSWZAAVN5y9vI3IAj2yBRGyw3xu9InggzPLSNtoxtnCVZMUBXh/rO8uaRkq1x8mccUG q6qKTTcg1n2TaXNO5Pb7K4PTLYQVxa6Ws/ZKBPgDWiQzanv4SSvvxgT/0kR6pCeMPYm1 zP4q/OOEas/l4FdqiClvbObdhMZx5jpR7SY4Up8drjuhnQgArN3FiPDyR24wF9JMTdJ0 RyeetL2wNJS7FzkuXtZ08YszhZYfXaJBkoH3SBZa6frdJgs4St3hX8leMwuOIKycEsJ4 cB+A== X-Gm-Message-State: AGRZ1gLke0J73lxDZ0vLf72C3MMhRiIjDnCBdfdV9NM1cQmD9I6C+CmP z0eTqjuQr4g71EVBYaCMdnD09Q== X-Google-Smtp-Source: AJdET5eBtMU5FgwYxfFeJ1h3FHJqLqEmzqKoAYroVglLcDV/4Ly/tuC349C1k1i0U/7B+aPJd4I3Bg== X-Received: by 2002:a24:e0b:: with SMTP id 11-v6mr1805200ite.60.1541694745001; Thu, 08 Nov 2018 08:32:25 -0800 (PST) Received: from dragon.local ([128.177.172.220]) by smtp.gmail.com with ESMTPSA id q24-v6sm1497405iog.61.2018.11.08.08.32.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 08:32:24 -0800 (PST) To: Sofia , mls@ietf.org Cc: shivankaulsahib@gmail.com, jurre@autonomia.digital References: <20181108160935.GA4116@Sofias-MBP> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> Date: Thu, 8 Nov 2018 09:32:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181108160935.GA4116@Sofias-MBP> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bz2PjR1PyRafpTgZRLwiA3M8qxjDOmzbZ" Archived-At: Subject: Re: [MLS] Contribute as OTRv4 to MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 16:32:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bz2PjR1PyRafpTgZRLwiA3M8qxjDOmzbZ Content-Type: multipart/mixed; boundary="1PPUs7SiB0Gbn0NYOBZpQ9y4aouoIC8bg"; protected-headers="v1" From: Peter Saint-Andre To: Sofia , mls@ietf.org Cc: shivankaulsahib@gmail.com, jurre@autonomia.digital Message-ID: <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> Subject: Re: [MLS] Contribute as OTRv4 to MLS References: <20181108160935.GA4116@Sofias-MBP> In-Reply-To: <20181108160935.GA4116@Sofias-MBP> --1PPUs7SiB0Gbn0NYOBZpQ9y4aouoIC8bg Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable That's great news! On 11/8/18 9:09 AM, Sofia wrote: > Dear contributors to MLS, >=20 > During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4 > specification and implementation during the PEARG session > (https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-ot= rv4-slides-01). > During the Q/A we had some nice words from some of you (some people sai= d that > it will be nice if the OTRv4 team could contribute with MLS) and, so, w= e'd like > to contribute to MLS and see how to work together! We have been looking= at some > of the material of MLS shared during IETF 103 and we will like to start= > contributing from it! >=20 > Best, > The OTRv4 team > -- > Sof=EDa Celi (aka cherenkov) > @claucece / @cherenkov_d > Cryptographic research and implementation at CAD: https://autonomia.dig= ital/ > EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F >=20 >=20 >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 --1PPUs7SiB0Gbn0NYOBZpQ9y4aouoIC8bg-- --bz2PjR1PyRafpTgZRLwiA3M8qxjDOmzbZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlvkZRYACgkQZWGMGH9o FKkCCRAAkbeMrO8pV5Mol8GugmYhm0sjN7iwGTuefDLk5dxLygnM1HfEO9l1IFiT R91SnRhjCYKo9ompmuHhINZgZ2Gl/ttjWkIwfXJtmeJrXcYV5KQDr8bhFtpZxPw6 FJDUekjhU/YrhOJRWWssJrMt6ItKZ1J9btQJTCVjIcQBC3haAqVXpxDYcuuJJ1IB DkAJTzc1j4eiu2pKpKPg/xEsnhwvU5SvLi8e86xRVsUEw8cuVyQb4IWg15RyGMaq Np+AvThGD/M2JYWks4NKU4TahDQZlvxAhAAxOKQ+/CJMZONZtOqeP+twMnopilh1 GrP+66pOuCruv5K2NzqxzH37PXZtr1TPa/4CwNNXyH9ThnqqEgiLAmD6DtYB6vjS 8Fez2xpg7SlwYHHwU9lHZ05wXiXZQJ9ZPmHweiEUJA582UdwQqxaIcmLOaoFQgLY q6KT6nHbMkQZAkjnRVuCi6halfOANibzi9VbkwRVXKHiaf0MLTjEIw59n1HJVFXG cEOLKJg1s9fclNwAt2GMhtaZkpRvD26k+nUqa3tAAVWsudoVdgJDv8qz5cPBjkw5 i1olrIJ3bhfRJMU1WMNJ4/3jvVtKp7W7oMXp8H00iQMJceaZpE879sOlf+lTl2QO EpYtGIBznN098zzR4DzYqSh9DjxqRtAd40GluxVlNW1HkpP3jPc= =s1TP -----END PGP SIGNATURE----- --bz2PjR1PyRafpTgZRLwiA3M8qxjDOmzbZ-- From nobody Thu Nov 8 18:06:30 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 D063C128D0C for ; Thu, 8 Nov 2018 18:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJbQwXoiJX2o for ; Thu, 8 Nov 2018 18:06:26 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 5EDC01288BD for ; Thu, 8 Nov 2018 18:06:26 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id q1so329774otk.0 for ; Thu, 08 Nov 2018 18:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eNtd4Suc4sujWHvf2MH+Xv8hWyIKNHNsVK+hNULI/4o=; b=UKS0OsoJUgeiDO9JgoaGv27TGcG1OE3vqwYqcphQoUTwLNpKzYXgXhfY47h/powgCB ROtZHQDT0Du3aSNvRsizBFxNG9/zszmXJvt2RryFI7rjzc0zEv6pY5AG5mZqvD85OOUh Acg6/70/N0n6DQ7IWJSZR6qiZbsh2BFxv78dSobjh8pk9D8kIbYh+mZ7WsPVW0gb+8tt omcHpWgCZPlUIp6+Ed2gWbzvu90R1N7X06UQdQESc+V7VwLYkXymXrKueEgQZeIMMXE/ t7xy/kCXl8nCguhW0IaXYZlILzkfFmsuviqsuAXQBwh/cUFfgpDEOvkH4k6b5fM4qAPp uiHw== 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=eNtd4Suc4sujWHvf2MH+Xv8hWyIKNHNsVK+hNULI/4o=; b=QWQL5XGR1paqtnbmfQGggOsSk5QZN5nSGb0MVIzB2yhaZl7Vh7Fy8C3q7TqEKVN9LG Km4KprKIbc1qattFHIswAgs1hk2XkG0MzTLudlEfoXmlJM0pu6bPm+D00jMzqkP7tnqs E4sCJpxop3i8Rkfn0axY5jAXh+PkJMJRMgV+wkX6TcwLWCFnF0g8ZUq6gkgMi2sUCQSx YYedecYpbgrOTYCxVLrXTE7a0YxowgefyckuKANsfrW2tDtF60DdhEp95WjIBG2eGLvd ordtdpHgHmm5M83Hc61Up6VFWcXJz9CW9F46BF2eBpRAGkSMOlnEnGfr3Ht0szAkJqUi yTmw== X-Gm-Message-State: AGRZ1gJPoN/nKJ8P6wXtcTGBOQshYjFZXwSEERRsMyhAwt23/oGUqdmF /UoMDUktOqLfSXnyM9Q2Hc5+oH+ABbv2B/EstFZIhsNQedpJlA== X-Google-Smtp-Source: AJdET5eDlDU+nBlLYhoyqYOIjDPl81vkR8y0oj4gbMy3//DV27BcH18+TLzN0jOOyS4Lsx93TGJtj7vZohF4+rT43zY= X-Received: by 2002:a9d:582e:: with SMTP id r46mr4409812oth.238.1541729185412; Thu, 08 Nov 2018 18:06:25 -0800 (PST) MIME-Version: 1.0 References: <20181108160935.GA4116@Sofias-MBP> <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> In-Reply-To: <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> From: Richard Barnes Date: Fri, 9 Nov 2018 09:06:11 +0700 Message-ID: To: Peter Saint-Andre Cc: sofia@autonomia.digital, mls@ietf.org, shivankaulsahib@gmail.com, jurre@autonomia.digital Content-Type: multipart/alternative; boundary="0000000000006fc737057a31cca2" Archived-At: Subject: Re: [MLS] Contribute as OTRv4 to MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 02:06:29 -0000 --0000000000006fc737057a31cca2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fantastic, glad to have you guys here. One productive way to get involved would be to read the draft protocol document [1] and send email to this mailing list with your thoughts. For the most part, there shouldn't be anything too surprising here. It's just standard DH ratchet + hash ratchet, but with the DH arranged in a tree. The one thing that might be surprising to you is that we do not account for deniability at all in the current draft. If deniability is something that's important to you, it would be helpful to think about how you could fit it in as an optional feature. Thanks, --Richard [1] https://tools.ietf.org/html/draft-ietf-mls-protocol On Thu, Nov 8, 2018 at 11:32 PM Peter Saint-Andre wrote: > That's great news! > > On 11/8/18 9:09 AM, Sofia wrote: > > Dear contributors to MLS, > > > > During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4 > > specification and implementation during the PEARG session > > ( > https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4= -slides-01 > ). > > During the Q/A we had some nice words from some of you (some people sai= d > that > > it will be nice if the OTRv4 team could contribute with MLS) and, so, > we'd like > > to contribute to MLS and see how to work together! We have been looking > at some > > of the material of MLS shared during IETF 103 and we will like to start > > contributing from it! > > > > Best, > > The OTRv4 team > > -- > > Sof=C3=ADa Celi (aka cherenkov) > > @claucece / @cherenkov_d > > Cryptographic research and implementation at CAD: > https://autonomia.digital/ > > EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F > > > > > > > > > > _______________________________________________ > > 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 > --0000000000006fc737057a31cca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Fantastic, glad to have you guys her= e.=C2=A0 One productive way to get involved would be to read the draft prot= ocol document [1] and send email to this mailing list with your thoughts.

    For the most part, there shouldn't be anyth= ing too surprising here.=C2=A0 It's just standard DH ratchet + hash rat= chet, but with the DH arranged in a tree.=C2=A0 The one thing that might be= surprising to you is that we do not account for deniability at all in the = current draft.=C2=A0 If deniability is something that's important to yo= u, it would be helpful to think about how you could fit it in as an optiona= l feature.

    Thanks,
    --Richard
    =




    On Thu, Nov 8, 2018 at 11:32 PM Peter Saint-Andre &= lt;stpeter@mozilla.com> wrote= :
    That's great news!

    On 11/8/18 9:09 AM, Sofia wrote:
    > Dear contributors to MLS,
    >
    > During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4 > specification and implementation during the PEARG session
    > (https://dat= atracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4-slides-01).
    > During the Q/A we had some nice words from some of you (some people sa= id that
    > it will be nice if the OTRv4 team could contribute with MLS) and, so, = we'd like
    > to contribute to MLS and see how to work together! We have been lookin= g at some
    > of the material of MLS shared during IETF 103 and we will like to star= t
    > contributing from it!
    >
    > Best,
    > The OTRv4 team
    > --
    > Sof=C3=ADa Celi (aka cherenkov)
    > @claucece / @cherenkov_d
    > Cryptographic research and implementation at CAD:     https://autonomia.d= igital/
    > EF74 1A5F 5692 E56F 14F6=C2=A0 243C 3992 6144 F89D 996F
    >
    >
    >
    >
    > _______________________________________________
    > 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
    --0000000000006fc737057a31cca2-- From nobody Thu Nov 8 18:41: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 9AECA12D7F8 for ; Thu, 8 Nov 2018 18:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-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 n7138dADIAsW for ; Thu, 8 Nov 2018 18:41:37 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 B7BE0128D0C for ; Thu, 8 Nov 2018 18:41:36 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id u6-v6so325061ljd.1 for ; Thu, 08 Nov 2018 18:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EDeVNsfPXSMrQn473kJKpe3jhcFurTmDlcSI4fPB3u4=; b=OWnZ88wKp+lcYps5XtpKgQtRoeXRo4Pz2jiEWYt3bfyhXfQ6L7LW6dpn6MlFdGfcl/ Cy4PiwxJ0kgQ59u0GTpTkaNQ1jCs3++YTdFvpxDcDdqMXssJ4DcvTstwDqOTFYe5GZSm V0pkqEvm1hSP0i0M0BqyJBApXP6V+P6AAJyjv2B11Ru3S7/AbJG92Vd2PmOG4bkFWxse sAtw6nSaIshsFR5ySa1PYiVpGWo/nkpyK1xe6RK29dR+rFThU/ogqYZeDcjFR/uVM6ag 1CKih1B4eoNm0pMiGJD8I50pGoc6m+08I8EATREwZqsdVMB1pEQRHDVIw3tq+4E9aqcx TbAw== 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=EDeVNsfPXSMrQn473kJKpe3jhcFurTmDlcSI4fPB3u4=; b=G/kanEzBpSpUwbkLzqFWJOKBFCfeRFgLpmjO+tqwWNLJkh8gzpsRhWlFfs7p7TYCZI 6m2WBeDEPGCNU2Rp+NMs7YMxbnxvkutOSy42JtcIT4J5FzCPrlC2b4rsYP46jstv2ovp 5PCW3yx4dXZq2/+SYRhEDDKM0jXMw4anB+oAAjSXLw1N5D4V0IjpaCEyFrh0g8x1f8P3 8UeRbWNAnaLzRiMrR27Lk44ij/5SWYm7xmIFD1Z4kbGBuYlC8L9Z8/HGePLdRU1HUsrt huQUIaayOK2wCF29g2cd8fV6TUt5Z6cpL6zzeOgf7el2iTQ8mIgW6eY5MrXnUTrhoJ98 WhWQ== X-Gm-Message-State: AGRZ1gINbGqvkUWAltZXiyiIiddavChU0wsv6xigCof1QKj/Z6wB5npf czmMqdYLiMW0ekQ2IoTbhXY/Ei4dbkCh3O3spb0ykzZtIBsSyA== X-Google-Smtp-Source: AJdET5fXNxZ2Yt1MO/lgSClbIMazAC54tloxtYrQzLDQRH+6M7CJDHXPgLgkLZ9onIy1cTKekPP2LLuX8KR+QbT3lrY= X-Received: by 2002:a2e:8945:: with SMTP id b5-v6mr4483214ljk.55.1541731294740; Thu, 08 Nov 2018 18:41:34 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6504:60d:0:0:0:0 with HTTP; Thu, 8 Nov 2018 18:41:34 -0800 (PST) In-Reply-To: References: <20181108160935.GA4116@Sofias-MBP> <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> From: nalini elkins Date: Fri, 9 Nov 2018 09:41:34 +0700 Message-ID: To: Richard Barnes Cc: Peter Saint-Andre , sofia@autonomia.digital, shivankaulsahib@gmail.com, mls@ietf.org, jurre@autonomia.digital Content-Type: multipart/alternative; boundary="000000000000299791057a324ac5" Archived-At: Subject: Re: [MLS] Contribute as OTRv4 to MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 02:41:40 -0000 --000000000000299791057a324ac5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > If deniability is something that's important to you, it would be helpful to think about how you could fit it in as an optional feature. Just to comment, there is a potential human rights issue (right to life) with deniability. Although extremely beneficial in a number of circumstances, it is my understanding that deniability can also be used by people such as terrorists to fight lawful subpoenas. I wonder if that is of interest to this group. Please correct me if my understanding is wrong. I very much wish to be wrong. Nalini On Fri, Nov 9, 2018 at 9:06 AM, Richard Barnes wrote: > Fantastic, glad to have you guys here. One productive way to get involve= d > would be to read the draft protocol document [1] and send email to this > mailing list with your thoughts. > > For the most part, there shouldn't be anything too surprising here. It's > just standard DH ratchet + hash ratchet, but with the DH arranged in a > tree. The one thing that might be surprising to you is that we do not > account for deniability at all in the current draft. If deniability is > something that's important to you, it would be helpful to think about how > you could fit it in as an optional feature. > > Thanks, > --Richard > > [1] https://tools.ietf.org/html/draft-ietf-mls-protocol > > > > On Thu, Nov 8, 2018 at 11:32 PM Peter Saint-Andre > wrote: > >> That's great news! >> >> On 11/8/18 9:09 AM, Sofia wrote: >> > Dear contributors to MLS, >> > >> > During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4 >> > specification and implementation during the PEARG session >> > (https://datatracker.ietf.org/meeting/103/materials/slides- >> 103-pearg-otrv4-slides-01). >> > During the Q/A we had some nice words from some of you (some people >> said that >> > it will be nice if the OTRv4 team could contribute with MLS) and, so, >> we'd like >> > to contribute to MLS and see how to work together! We have been lookin= g >> at some >> > of the material of MLS shared during IETF 103 and we will like to star= t >> > contributing from it! >> > >> > Best, >> > The OTRv4 team >> > -- >> > Sof=C3=ADa Celi (aka cherenkov) >> > @claucece / @cherenkov_d >> > Cryptographic research and implementation at CAD: >> https://autonomia.digital/ >> > EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > --=20 Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --000000000000299791057a324ac5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    > If deniability is somethin= g that's important to you, it would be helpful to think about how you c= ould fit it in as an optional feature.

    Just to comment, there is a potential human rights = issue (right to life) with deniability.=C2=A0 =C2=A0Although extremely bene= ficial in a number of circumstances, it is my understanding that deniabilit= y can also be used by people such as terrorists to fight lawful subpoenas.<= /div>

    I wonder if that is of interest to this group.=C2= =A0 =C2=A0Please correct me if my understanding is wrong.=C2=A0 I very much= wish to be wrong.

    Nalini

    On Fri, Nov 9, 2018 at 9:06 AM= , Richard Barnes <rlb@ipv.sx> wrote:
    Fantastic, glad to have you guys= here.=C2=A0 One productive way to get involved would be to read the draft = protocol document [1] and send email to this mailing list with your thought= s.

    For the most part, there shouldn't be a= nything too surprising here.=C2=A0 It's just standard DH ratchet + hash= ratchet, but with the DH arranged in a tree.=C2=A0 The one thing that migh= t be surprising to you is that we do not account for deniability at all in = the current draft.=C2=A0 If deniability is something that's important t= o you, it would be helpful to think about how you could fit it in as an opt= ional feature.

    Thanks,
    --Richard=




    On Thu, Nov 8, 2018 at 1= 1:32 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:
    That's great news!

    On 11/8/18 9:09 AM, Sofia wrote:
    > Dear contributors to MLS,
    >
    > During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4 > specification and implementation during the PEARG session
    > (https://dat= atracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4-sl= ides-01).
    > During the Q/A we had some nice words from some of you (some people sa= id that
    > it will be nice if the OTRv4 team could contribute with MLS) and, so, = we'd like
    > to contribute to MLS and see how to work together! We have been lookin= g at some
    > of the material of MLS shared during IETF 103 and we will like to star= t
    > contributing from it!
    >
    > Best,
    > The OTRv4 team
    > --
    > Sof=C3=ADa Celi (aka cherenkov)
    > @claucece / @cherenkov_d
    > Cryptographic research and implementation at CAD: https://autonomia.d= igital/
    > EF74 1A5F 5692 E56F 14F6=C2=A0 243C 3992 6144 F89D 996F
    >
    >
    >
    >
    > _______________________________________________
    > 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




    --
    =
    Thanks,
    Nalini Elkins
    = President
    Enterprise Data Center Opera= tors

    <= /div>
    --000000000000299791057a324ac5-- From nobody Thu Nov 8 19:18: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 485E01292F1 for ; Thu, 8 Nov 2018 19:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 5NgAIHqsCII7 for ; Thu, 8 Nov 2018 19:18:38 -0800 (PST) Received: from mail.paip.net (whisk.cs.uwaterloo.ca [198.96.155.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6941277BB for ; Thu, 8 Nov 2018 19:18:38 -0800 (PST) Received: from brandeis.paip.net (brandeis.paip.net [66.38.236.131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by emu (Postfix) with ESMTPSA id 657775FC0018; Thu, 8 Nov 2018 22:17:41 -0500 (EST) Received: from iang by yoink with local (Exim 4.82) (envelope-from ) id 1gKxJa-0007Kk-DH; Thu, 08 Nov 2018 22:18:34 -0500 Date: Thu, 8 Nov 2018 22:18:34 -0500 From: Ian Goldberg To: nalini elkins Cc: Richard Barnes , sofia@autonomia.digital, shivankaulsahib@gmail.com, mls@ietf.org, jurre@autonomia.digital, Peter Saint-Andre Message-ID: <20181109031834.GT5018@yoink.cs.uwaterloo.ca> References: <20181108160935.GA4116@Sofias-MBP> <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [MLS] Contribute as OTRv4 to MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 03:18:40 -0000 On Fri, Nov 09, 2018 at 09:41:34AM +0700, nalini elkins wrote: > > If deniability is something that's important to you, it would be helpful > to think about how you could fit it in as an optional feature. > > Just to comment, there is a potential human rights issue (right to life) > with deniability. Although extremely beneficial in a number of > circumstances, it is my understanding that deniability can also be used by > people such as terrorists to fight lawful subpoenas. > > I wonder if that is of interest to this group. Please correct me if my > understanding is wrong. I very much wish to be wrong. I can't figure out what you mean by that. Deniability (well, one form of it anyway) is the property that the transcript of the protocol messages does not imply the plaintext messages that were exchanged. Another form is that it does not imply the participation of any particular party. (There are other more complex forms involving online informants.) Plaintext logs are deniable in these senses, since anyone could easily forge them to say anything they like. If we're talking subpeonas, note that courts accept plaintext as evidence all the time; the role of a deniable protocol is to prevent the protocol transcript from *mathematically* implying the message contents or participation. (While at the same time the protocol strongly authenticates the participants and the message contents to those *in* the conversation.) -- Ian Goldberg Professor and University Research Chair Cheriton School of Computer Science University of Waterloo From nobody Fri Nov 9 17:28:08 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9DA129C6A for ; Fri, 9 Nov 2018 17:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 iE-rU2mrRkx0 for ; Fri, 9 Nov 2018 17:28:04 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93BC126F72 for ; Fri, 9 Nov 2018 17:28:03 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id 74-v6so3653976wrb.13 for ; Fri, 09 Nov 2018 17:28:03 -0800 (PST) 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=LNIxt32NzHgN2BNIpybIFJPZ38hIVqZpQBudFAHbmQ4=; b=hdFJj+YGjQVa/4FrB7WkEH5Q5rVHlIS1VEcROR/NjwaeuWq+vHdb5ZijlAHvQu/v1n bgjNcOklmK5aH3QpEokb52N9odPPdz3AW4+E3fyvvxRIjdI4K2+7oDz+2TAs5eXX17uy mpHJCd0jaZKyCecF2WJb/u/m/Vnj0zC9/6nmEiOZXOEXNgJLoERUy4ptOQ5Xb8NdR7B3 jz/lcur1IckTsk6UN0xgU2U27SmgOooynH7cb4wI7KWuObXf4OYWDvrliwQrI/1xh+cm N14IVyxfsAl0g4tFPbPBl4PSyUJX9NrLDV5g34XMGFsejDjAdt5sa0YqG0mSjNH66Fs1 5BTA== 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=LNIxt32NzHgN2BNIpybIFJPZ38hIVqZpQBudFAHbmQ4=; b=dayUK7PHRbgmK44yRN6ETaJq8brdFMnVxOO8Hy72rWEUNJNaMGeYgsWBBpmTpGc46P Nl7rEO1uT0heRdB1+Sad70vnOG3boson4YBG4ZoaQXqh+RQIUwdpOl6CMS0tgUWF+Swp 3/6E4riNB6x5fq+8cHdwKotG4bNjvVVs90i4nDBsNab6zoUJcq0ScYxSwGGcOwnIP+72 +OkPmuHhg/r5z2c4vjoVoE1ZUGtNNOCIYXwndPQdYtKq17Qc7SDyfSFgDV76AKamomLx naF/GZZnHsWWuYoYyXJGfyatO4ztDzg8HOpvh3Lm8adHQYtbjevShlgOjnLCw0VENoIc WJ1A== X-Gm-Message-State: AGRZ1gLOt+YA8qzeLboGHTcfmtHGRuR6siS7LCCnx51kOD1D0vELftll rbCDD6dPbq7em/9PNUmmPFaXfuEdrs56ng== X-Google-Smtp-Source: AJdET5co2F5LwSDoKxSTuvTTu/btl2cZwKX9GKUyfoxCfOxkBNXh8t8N/HgbRgBoIZDlwCTE4B9N2Q== X-Received: by 2002:a05:6000:1152:: with SMTP id d18mr9802276wrx.247.1541813281804; Fri, 09 Nov 2018 17:28:01 -0800 (PST) Received: from [192.168.178.201] (HSI-KBW-095-208-247-123.hsi5.kabel-badenwuerttemberg.de. [95.208.247.123]) by smtp.gmail.com with ESMTPSA id 64-v6sm1058970wml.22.2018.11.09.17.27.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 17:28:00 -0800 (PST) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_BF8765D8-EDB4-4A20-9910-8F1CFD170FAB" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Sat, 10 Nov 2018 08:27:53 +0700 References: <20181108160935.GA4116@Sofias-MBP> <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> To: mls@ietf.org In-Reply-To: Message-Id: <083D9985-8DF6-41BE-9859-C10BB1C1D34B@wire.com> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [MLS] Contribute as OTRv4 to MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 01:28:07 -0000 --Apple-Mail=_BF8765D8-EDB4-4A20-9910-8F1CFD170FAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is great news indeed! Sharing ideas about subjects like deniability = or other open issues sounds very promising! Raphael > On 9 Nov 2018, at 09:06, Richard Barnes wrote: >=20 > Fantastic, glad to have you guys here. One productive way to get = involved would be to read the draft protocol document [1] and send email = to this mailing list with your thoughts. >=20 > For the most part, there shouldn't be anything too surprising here. = It's just standard DH ratchet + hash ratchet, but with the DH arranged = in a tree. The one thing that might be surprising to you is that we do = not account for deniability at all in the current draft. If deniability = is something that's important to you, it would be helpful to think about = how you could fit it in as an optional feature. >=20 > Thanks, > --Richard >=20 > [1] https://tools.ietf.org/html/draft-ietf-mls-protocol = >=20 >=20 >=20 > On Thu, Nov 8, 2018 at 11:32 PM Peter Saint-Andre > wrote: > That's great news! >=20 > On 11/8/18 9:09 AM, Sofia wrote: > > Dear contributors to MLS, > >=20 > > During the last IETF 103, Sofi and Jurre gave a talk about the OTRv4 > > specification and implementation during the PEARG session > > = (https://datatracker.ietf.org/meeting/103/materials/slides-103-pearg-otrv4= -slides-01 = ). > > During the Q/A we had some nice words from some of you (some people = said that > > it will be nice if the OTRv4 team could contribute with MLS) and, = so, we'd like > > to contribute to MLS and see how to work together! We have been = looking at some > > of the material of MLS shared during IETF 103 and we will like to = start > > contributing from it! > >=20 > > Best, > > The OTRv4 team > > -- > > Sof=C3=ADa Celi (aka cherenkov) > > @claucece / @cherenkov_d > > Cryptographic research and implementation at CAD: = https://autonomia.digital/ > > EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls = > >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_BF8765D8-EDB4-4A20-9910-8F1CFD170FAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is great news indeed! Sharing ideas about subjects like deniability or = other open issues sounds very promising!


    Raphael

    On 9 Nov 2018, at 09:06, = Richard Barnes <rlb@ipv.sx> wrote:

    Fantastic, glad = to have you guys here.  One productive way to get involved would be = to read the draft protocol document [1] and send email to this mailing = list with your thoughts.

    For the most part, there shouldn't be = anything too surprising here.  It's just standard DH ratchet + hash = ratchet, but with the DH arranged in a tree.  The one thing that = might be surprising to you is that we do not account for deniability at = all in the current draft.  If deniability is something that's = important to you, it would be helpful to think about how you could fit = it in as an optional feature.

    Thanks,
    --Richard

    [1] https://tools.ietf.org/html/draft-ietf-mls-protocol



    On Thu, Nov 8, 2018 at = 11:32 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:
    That's great news!

    On 11/8/18 9:09 AM, Sofia wrote:
    > Dear contributors to MLS,
    >
    > During the last IETF 103, Sofi and Jurre gave a talk about the = OTRv4
    > specification and implementation during the PEARG session
    > (https://datatracker.ietf.org/meeting/103/materials/slides-103-p= earg-otrv4-slides-01).
    > During the Q/A we had some nice words from some of you (some people = said that
    > it will be nice if the OTRv4 team could contribute with MLS) and, = so, we'd like
    > to contribute to MLS and see how to work together! We have been = looking at some
    > of the material of MLS shared during IETF 103 and we will like to = start
    > contributing from it!
    >
    > Best,
    > The OTRv4 team
    > --
    > Sof=C3=ADa Celi (aka cherenkov)
    > @claucece / @cherenkov_d
    > Cryptographic research and implementation at CAD: https://autonomia.digital/
    > EF74 1A5F 5692 E56F 14F6  243C 3992 6144 F89D 996F
    >
    >
    >
    >
    > _______________________________________________
    > MLS mailing list
    > MLS@ietf.org
    > https://www.ietf.org/mailman/listinfo/mls
    >

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

    = --Apple-Mail=_BF8765D8-EDB4-4A20-9910-8F1CFD170FAB-- From nobody Wed Nov 21 09:33:32 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 5D0C1130DC1 for ; Wed, 21 Nov 2018 09:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9HAcy2aufjd for ; Wed, 21 Nov 2018 09:33:29 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4660D12426E for ; Wed, 21 Nov 2018 09:33:29 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id f4so5528736edq.10 for ; Wed, 21 Nov 2018 09:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=yUxnqxEk5zi+qO8R4RGzVsO7OpVxBAYN8V5mph3Aj9s=; b=RDmpAwVS75dONF16fjxzJ4znmzQ1CSD3ZzG7594rjvoKin+eFQsIq171VeQ5RRq70e gSM2kcmrs8lhFSSmz40b9GcIICkJiLcQvkXKWan7RvWh4vwmJkk6oMr1gDInVNZqKkuC o0qh2P0VBrdYc5avBd8Y1clR98kkS4rBIobLCSdfDkZoPvsJjFygbzbX/GzZzupZAhGd hehtMdmMPObCISMzd8URexGGKBpx8AWYcypHb8+v/a7we+lU1GEiR+8NyWka7OJG1uJE H/q/WdI9e8D0Pwokh7u2twu8K2YyDnYzuPFCfLmxjruOnPFEMS+hmapw0OGgK0RV56hU 9phg== 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=yUxnqxEk5zi+qO8R4RGzVsO7OpVxBAYN8V5mph3Aj9s=; b=MV4ICVGQ6ZhzUCVCwwG5LzT3qtHaqqvKkBh3bF3vwXSs8xNy7gem1C1oO2UVr8TBGu 36AateQl79d4WU4wMML5E8zul2x/+faxeaWW9YvpIM9KflKnnwkfkJkQnpX5agIMWCsy 0f+Vkt3bDsFsww4Nv7r5o8XSHTRpfFjQQer8QxavdDB3RfzAnGk7psuoghyaYtFaNJM5 GIOhlYFJQMU/t7SwO+zcrttcDx79NLfCCdl8KW3qGvPIMy91b6i1AIC+zmSSqhl9uDcd CPkU0RGEu3jVEQEFhou3zVywK0B6c5KF5zSyDXT+aNxMSvBpoOeuOw702Lf9VT4MIpUk ARgw== X-Gm-Message-State: AA+aEWbW7Nn/a8uwHcVy5vtBDIQRvR6zmVYQ4/JBHC0E7BPsskn1pToe u/QxsOOxAMPgZc515ZHHIykd3DcznsQ= X-Google-Smtp-Source: AFSGD/UhWeqZnSwg14fm1gkGR4Uh27r9T4CNWL7GoayFAQt5PixQw+8nZzf7nPh5EHDDx076DcGuig== X-Received: by 2002:a50:b667:: with SMTP id c36mr6719691ede.190.1542821606866; Wed, 21 Nov 2018 09:33:26 -0800 (PST) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id p30sm11736191eda.68.2018.11.21.09.33.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 09:33:25 -0800 (PST) From: Raphael Robert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 21 Nov 2018 18:33:24 +0100 References: <87fu0fxjhi.fsf@fifthhorseman.net> To: mls@ietf.org In-Reply-To: <87fu0fxjhi.fsf@fifthhorseman.net> Message-Id: <8A6F8888-9FAB-47E9-ADF3-FE7995F13D3B@wire.com> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages 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, 21 Nov 2018 17:33:31 -0000 At IETF 103 we discussed the possibility of encrypting handshake = messages and also the fact that this might hinder the caching of public = keys of the tree (caching would alleviate the cost of adding new = members/devices to a conversation). I was wondering if we couldn't use a proxy re-encryption scheme to = achieve both goals: - the proxy would be able to cache parts of the handshake messages, yet = still not have access to the plaintext of handshake messages - the proxy would re-encrypt that data from epoch to epoch The keys for the encryption would be derived through the key schedule = (and therefore from the group secret). This means the keys inherit the = FS and PCS guarantees of the group secret. In typical proxy re-encryption schemes, Alice wants to share data with = Bob and asks the proxy to re-encrypt the her ciphertext for Bob. In that = scenario Alice only knows Bob's public key, but not his private key. = This limitation is not applicable with handshake messages, as both = private keys can be known and this might simplify things. It would be interesting to hear from cryptographers about the = feasibility of such a scheme as well as from folks who have successfully = implemented similar schemes. Raphael > On 19 Jul 2018, at 18:45, Daniel Kahn Gillmor = wrote: >=20 > In today's session, there seemed to be an open question that wasn't > explicitly addressed, so i wanted to raise it on the list. >=20 > for lack of a better term, we're dividing MLS messages into > "application" messages and "handshake" messages. (i think we need > a better term for "handshake", but i'll use it here for consistency = with > the current discussion) >=20 > I believe we should provide encrypted cover, and a mechanism for = padding > of handshake messages, not just for application messages. >=20 > We want encrypted cover because i'd like the DS not to be able see > whether a given message is a handshake message or an application > message. >=20 > and if it is a handshake message, i want to be able to make a = handshake > message that shows up for a group of K people to look the same to an > observer as a handshake for a group of K+1 people (this motivates the > request for padding. >=20 > I recognize that some of this might come into conflict with richard > barnes' vision of a DS that stores a cache of messages from each > participant in a given group for future replay -- so i think we need > further dicsussion on it. >=20 > --dkg >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Mon Nov 26 15:39:20 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3F713106B for ; Mon, 26 Nov 2018 15:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFOFVhQD8Gkn for ; Mon, 26 Nov 2018 15:39:08 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 34AEB13107E for ; Mon, 26 Nov 2018 15:39:08 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id j21so17612479oii.8 for ; Mon, 26 Nov 2018 15:39:08 -0800 (PST) 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=ArhtZx7uq7hKebUXLDzYGiIDJ1+MnQykpL1nRjEmjms=; b=dMsEuRE4lbMqr7GG7X5CcbYzivlD4tob9UGIWWdLwBo9Fttd7HmERtytmD03Vphyp9 zd09+Or1mMk016ZN+WlPE05We8bTlySli7cHMCGJEkxpq0V5U7WciIfokZ9lWViqKyCK q+0qhQkQxzK0N2619nonz8gQPBpY3o4Tiftwc= 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=ArhtZx7uq7hKebUXLDzYGiIDJ1+MnQykpL1nRjEmjms=; b=jzXZHr83cnaiZSxX/iCKMKgoMqDbLWXpV6QZgIxxrsiaKQnuEuKGo/JQKok8+Tx2i+ UOlqQFP5yfPAn1XBx8xrcr+qBcOn8mGOTepAy8nvTfRQLHdm5+hZW6WADPp+AZwD4WJa HZDhUf1zK1kR997VbRgOqA9Wv6kVMSnTqcIrf4ZSjmMo1QFQYP02hDCr8fMf6DC/uUJB MQjTqvqgowJ6jwdile9bl+WiSWDGGKFi/PaW9ym49NVTrXLFQOrqikbUTRsCHLn/Mjk9 /0kOTLU7RomX0iHjQd8GKyRrURqcrvW0DmK3Ja6le/V4/EI0YLOilMocLGl8fv+yVJp2 jSRA== X-Gm-Message-State: AGRZ1gID4WY1Oo/GecZhG+8m/s67iFjfTS3kwoQb0OHmwBqW0Nmtd8n+ fVwU4LUwZXoYBVyAafSNgW/+wp3E8Ep42NEAH6cgMsXs1+g= X-Google-Smtp-Source: AJdET5eSX0kKRlwdVDlBqnETa/1gCNWDGLRIn92vWCvHfZS0sJAOL98l+Uc0wNOmV6948kfldsXJ4J38dL2DAjGUqPY= X-Received: by 2002:aca:4cc8:: with SMTP id z191mr17464236oia.54.1543275547062; Mon, 26 Nov 2018 15:39:07 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Mon, 26 Nov 2018 15:38:55 -0800 Message-ID: To: "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c60d20057b99d603" Archived-At: Subject: [MLS] Jan 2019 MLS Interim - Bay Area 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, 26 Nov 2018 23:39:18 -0000 --000000000000c60d20057b99d603 Content-Type: text/plain; charset="UTF-8" Hello mlswg, The chairs would like to propose the following time/date for the next MLS interim: January 14-15, 2019 SF Bay Area, California, USA Host: TBD This is the week after RWC 2019 (https://rwc.iacr.org/2019/), so we should expect some overlap in the set of participants. 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. There will be a remote participation option. Sean and Nick --000000000000c60d20057b99d603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello mlswg,

    The chairs would like to p= ropose the following time/date for the next MLS interim:
    January = 14-15, 2019
    SF Bay Area, California, USA
    Host: TBD

    This is the week after RWC 2019 (https://rwc.iacr.org/2019/), so we should expect some= overlap in the set of participants.

    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. There will= be a remote participation option.

    Sean and Ni= ck
    --000000000000c60d20057b99d603-- From nobody Mon Nov 26 15:44: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 E2D4412DF72 for ; Mon, 26 Nov 2018 15:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMqbV1TOyCrw for ; Mon, 26 Nov 2018 15:44:26 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BB8127332 for ; Mon, 26 Nov 2018 15:44:26 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id w25so18396746otm.13 for ; Mon, 26 Nov 2018 15:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cXPCRGjwhrc0Gcx03AzT0dWVJCzUxl99sHT1SNXauHU=; b=aGZJmtpvZ87bVBWVwfagSOg0kUxGwNtT0U3X7y8fJfE3oqcOUK2qFa9BhkPMvZAKOG aMxKuvNpxyx3UJTLQ7RDPNK82fFDmOfoUO/zDtQKNmk6PfRzVsfffngfrtXbtqtbVD2x LwYq/n7S5RiAbR51UShIGUn2sxWq27xGC4ZR2nXGtiF5oiCjSF1nz+nLVozjb4kEsmcS 4/KpXMNM5yVyduHFq1tcyWEdQhu8E44sLpF709oVznqQzVDmkjJSVlKTAErCvz9bmqpO DYPYnKPhva0AQDmrm5jrlAnxl83xlNPgex8LAHEsUsc2TOVC6ni+ip5BYwbrKkwuDJej 6Eug== 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=cXPCRGjwhrc0Gcx03AzT0dWVJCzUxl99sHT1SNXauHU=; b=olvVppPs8DuMq6HouAo/eKv1dmHfegQ5jBhTPFrdbQeT4ErJLq6PufDNVgAHbjEt8n vwXUD7JpnKROsKCXYTpBmUEODTfEckT6yRuthJ4/XCmmF3qSju11eGc7F5cWshgJVcL6 oGOoxsADtM5G2IvUy7SEy9xsi9sZVpeFi/aQj1415Pvl6sdORVEZOa9JgED2yZXFQ96X xABNX4cJuziulELt3FmZJiQs8yyfOi1pQBVBhzc8XSPq3xWGMKsE292t3cG6ByjSLnRm r/zruc2kfHRgNmitGGljvJWxslA4kC5Q+JOjeKHZOpidqOyVCqwYNzpxiW7TI3x7ILka zigw== X-Gm-Message-State: AA+aEWbSeyiOVi70Mt1oLxbeLwdxZT8/3nTB0IQY5faJs153ICr260Rb NDsF6s9pWi7JZx+muIiZQOFGB5igYxRCu7ziKg0MtWtMAA8= X-Google-Smtp-Source: AFSGD/Xam+fWmCczQvuaNJbZi0kBGjmZrx68nRBBgNzO+MZXBkoc5ZICJZ0OmK8B6GDDcJOUguvTnbcK8HXnySaE08s= X-Received: by 2002:a9d:1b0b:: with SMTP id l11mr12732352otl.162.1543275865164; Mon, 26 Nov 2018 15:44:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 26 Nov 2018 18:44:12 -0500 Message-ID: To: nick=40cloudflare.com@dmarc.ietf.org Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000bbe714057b99e982" Archived-At: Subject: Re: [MLS] Jan 2019 MLS Interim - Bay Area 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, 26 Nov 2018 23:44:30 -0000 --000000000000bbe714057b99e982 Content-Type: text/plain; charset="UTF-8" I'll be there. If folks are going to be around over the weekend, I might try to arrange an implement-a-thon somewhere. On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan wrote: > Hello mlswg, > > The chairs would like to propose the following time/date for the next MLS > interim: > January 14-15, 2019 > SF Bay Area, California, USA > Host: TBD > > This is the week after RWC 2019 (https://rwc.iacr.org/2019/), so we > should expect some overlap in the set of participants. > > 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. There will be a remote participation option. > > Sean and Nick > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000bbe714057b99e982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'll be there.=C2=A0 If folks are going to be around o= ver the weekend, I might try to arrange an implement-a-thon somewhere.
    <= /div>
    On Mon, Nov 26, 2018 a= t 6:39 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
    Hello mlswg,

    The= chairs would like to propose the following time/date for the next MLS inte= rim:
    January 14-15, 2019
    SF Bay Area, California, USA
    Host: TBD

    This is the week after RWC 2019= (https://rwc.iacr= .org/2019/), so we should expect some overlap in the set of participant= s.

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

    Sean and Nick
    _______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://www.ietf.org/mailman/listinfo/mls
    --000000000000bbe714057b99e982-- From nobody Mon Nov 26 15:47:12 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 59019129AB8 for ; Mon, 26 Nov 2018 15:47:10 -0800 (PST) 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=P5kXSVlo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WCi7pMFb 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 hRZ2eH_nm929 for ; Mon, 26 Nov 2018 15:47:07 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A091127332 for ; Mon, 26 Nov 2018 15:47:07 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 169F322162 for ; Mon, 26 Nov 2018 18:47:06 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 26 Nov 2018 18:47:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= v4wMzLSJdz0QVAK0U3Zs7+Ud4gMgCiRsF6BxZ7MJWUA=; b=P5kXSVlocDm4JFD9 TngMq2L3d3dfNE5sds/m8waR4ti6c+ziz3XbWAArk+NPBAy4kd6YjNtJ8eJnjJfd wWOjqmIGVEXjqMnY1vdtFJfs56X2zghz7k5JGRNPtg/Nc6T0yPbRSMb0Y4Isxzpu dEDMHtOyBNJtwvRhWOzrqK4A0Vs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=v4wMzLSJdz0QVAK0U3Zs7+Ud4gMgCiRsF6BxZ7MJW UA=; b=WCi7pMFbZ86TpevIGziTmGj5Ty3GRWapXRPjHyBja7aUGPfJjeaAwKBrO S3dJ9x4FD4BfBzivvfZk0ja1oEcnqaVnZGnFrRmUScI0jLRIvZubQXbf9NwAS3v3 VVhHljHRKY3fQT/5PE3qEZgzapQ6t2RPQ271IfFaw51YtRkd2ZiWmB+LONcRZIJd dwtadnzcccwSrpSfDcB3TutWstidIc/gIVdm03zdMyY2KVJ2FPQKTby0HpTHzDGs eQVR06+C7SU7maLzzmcET09EVSLJ7fiWdb2Snc8G/mW0VuaStTFV1xyaWQ/YBfMx ngOxM8uEEQGsebEo1zIvYN7ZIgzQA== X-ME-Sender: X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 740349E189; Mon, 26 Nov 2018 18:47:03 -0500 (EST) Message-Id: <1543276023.2089386.1589793056.695B3920@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_154327602320893862" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b In-Reply-To: References: Date: Mon, 26 Nov 2018 23:47:03 +0000 Archived-At: Subject: Re: [MLS] Jan 2019 MLS Interim - Bay Area 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, 26 Nov 2018 23:47:11 -0000 This is a multi-part message in MIME format. --_----------=_154327602320893862 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I'm in. K On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote: > I'll be there. If folks are going to be around over the weekend, I > might try to arrange an implement-a-thon somewhere.> > On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan > wrote:>> Hello mlswg, >> >> The chairs would like to propose the following time/date for the next >> MLS interim:>> January 14-15, 2019 >> SF Bay Area, California, USA >> Host: TBD >> >> This is the week after RWC 2019 (https://rwc.iacr..org/2019/[2]), so >> we should expect some overlap in the set of participants.>> >> 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. There will be a remote participation >> option.>> >> Sean and 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 Links: 1. mailto:40cloudflare.com@dmarc..ietf.org 2. https://rwc.iacr.org/2019/ --_----------=_154327602320893862 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
    I'm in.

    K

    On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote:
    I'll be there.  If folks are going to be around over the weekend, I might try to arrange an implement-a-thon somewhere.

    On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan <nick=40cloudflare.com@dmarc.ietf.org> wrote:
    Hello mlswg,

    The chairs would like to propose the following time/date for the next MLS interim:
    January 14-15, 2019
    SF Bay Area, California, USA
    Host: TBD

    This is the week after RWC 2019 (https://rwc.iacr..org/2019/), so we should expect some overlap in the set of participants.

    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. There will be a remote participation option.

    Sean and Nick
    _______________________________________________
    MLS mailing list
    _______________________________________________
    MLS mailing list

    --_----------=_154327602320893862-- From nobody Mon Nov 26 15:59:33 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 BC127130FF3 for ; Mon, 26 Nov 2018 15:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.958 X-Spam-Level: X-Spam-Status: No, score=-18.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRFwHQukIaT6 for ; Mon, 26 Nov 2018 15:59:29 -0800 (PST) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 49BF3127332 for ; Mon, 26 Nov 2018 15:59:29 -0800 (PST) Received: by mail-yw1-xc31.google.com with SMTP id i20so8370726ywc.5 for ; Mon, 26 Nov 2018 15:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IdIAPcTQQYyLoKcmy6KML7LTD1+/rZw4a57rWg0LtZs=; b=rlBC0wvXmUmh5ANkRiemh35umPr0ztHe/Jnj0GZQ7TR/PLQhUoJtnZZEQ0Ft5cEoGE lFfyKEVIXiUiSvKxwbECl5FOlchYd9cxXSau+KSleQV62Ic6NqTIzxLcmXHJ9tlTGVqR 3KobN3hG63rNu6lJTXSVzjw1shBK0bnJ37K4H9dHToffuNLuqYqkrED0EwspeY1D5fgP 0cRJ+qoUadHt537XSw8j9odAUXj9pBlkTWFGPLbcDlAGo5lFh1lF15X7dwSdbofK1lkM HZs+yeiRhXu2r5BKCDUb2VqC68+yC0qwxZdGGhOV3fn77oG1Vh2NWIWbavkaDle1/5ly zzCw== 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=IdIAPcTQQYyLoKcmy6KML7LTD1+/rZw4a57rWg0LtZs=; b=ts8kTEg3iEunWpZu2Wad2FpPGZqekSTEYKvqfpN9N25pFiGBPoU++dfmITtvWnPlKl JATnzwVUG4wRLJHNUWD4hG1v/o2/DX1QN5H0vKIooYoaScw7aJsWUB+KXylr4f/vWWp+ TgcRpT+OhyOi3Mw41zR/KXAf9qKu3EzLYVaJ5P0jm35QguIoCDl5gMphzAPOSzVhPtsA FuB9rbSPeCXYVx6qKEHceA2P1lfPZiCSC1nnPHzmvhobCYsZYnAZvZ8ebB6Hb4C+boJA gOPyxL7YNc6ELhBVm0Wz6jIitdOzv6XFT+xkHUBm47qOk+z6FDJTNbGBJmJB5kvlNKCF zLwA== X-Gm-Message-State: AGRZ1gI/FDnWOLwT0tXhyR8861BeV1C2ujgULkqw/P3Q1MCIa+Cbhzei uQJece6eJIXuUZB6CwFLGGSLD8lTcZ5BI71XVbnVKANOPQ== X-Google-Smtp-Source: AJdET5fBK/8P11/YWHU1kfIcMBTq+4z87owDjGPx/SgIBWoYIKwaEckQE/AZF0LLwKCH5g1rh41Xjaq0LHQZFnrsJSE= X-Received: by 2002:a81:b1c3:: with SMTP id p186-v6mr31843797ywh.251.1543276768070; Mon, 26 Nov 2018 15:59:28 -0800 (PST) MIME-Version: 1.0 References: <1543276023.2089386.1589793056.695B3920@webmail.messagingengine.com> In-Reply-To: <1543276023.2089386.1589793056.695B3920@webmail.messagingengine.com> From: Emad Omara Date: Mon, 26 Nov 2018 15:59:16 -0800 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000008d5e2d057b9a1f60" Archived-At: Subject: Re: [MLS] Jan 2019 MLS Interim - Bay Area 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, 26 Nov 2018 23:59:32 -0000 --0000000000008d5e2d057b9a1f60 Content-Type: text/plain; charset="UTF-8" I should be able to make it this time On Mon, Nov 26, 2018 at 3:47 PM Katriel Cohn-Gordon wrote: > I'm in. > > > K > > On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote: > > I'll be there. If folks are going to be around over the weekend, I might > try to arrange an implement-a-thon somewhere. > > On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan 40cloudflare.com@dmarc.ietf.org <40cloudflare.com@dmarc..ietf.org>> wrote: > > Hello mlswg, > > The chairs would like to propose the following time/date for the next MLS > interim: > January 14-15, 2019 > SF Bay Area, California, USA > Host: TBD > > This is the week after RWC 2019 (https://rwc.iacr..org/2019/ > ), so we should expect some overlap in the > set of participants. > > 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. There will be a remote participation option. > > Sean and 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 > --0000000000008d5e2d057b9a1f60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I should be able to make it this time=C2=A0

    On Mon, Nov 26, 201= 8 at 3:47 PM Katriel Cohn-Gordon <me= @katriel.co.uk> wrote:
    I'm in.
    <= div style=3D"font-family:georgia,serif">

    K

    On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote:
    I'll be there.=C2=A0 If folk= s are going to be around over the weekend, I might try to arrange an implem= ent-a-thon somewhere.

    On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan <nic= k=3D4= 0cloudflare.com@dmarc.ietf.org> wrote:
    Hello mlswg,

    The chairs would like to propose the following time/date for the next = MLS interim:
    January 14-15, 2019
    SF Bay Area, California, USA
    Host: TBD

    This is the week after RWC 2019 (https://rwc.iacr..org/2019/), so we should expect s= ome overlap in the set of participants.

    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. There will be a remote participation option.

    Sean and Nick
    __________________________________= _____________
    MLS mailing list
    _______________________________________________
    MLS mailing list

    _______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://www.ietf.org/mailman/listinfo/mls
    --0000000000008d5e2d057b9a1f60-- From nobody Mon Nov 26 23:50:16 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DC9130E6B for ; Mon, 26 Nov 2018 23:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_EckPCeU976 for ; Mon, 26 Nov 2018 23:50:11 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FBC127133 for ; Mon, 26 Nov 2018 23:50:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.56,286,1539640800"; d="scan'208,217";a="357508496" Received: from unknown (HELO [192.168.1.17]) ([81.249.174.203]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2018 08:50:08 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-CD230EAF-751F-4136-87A7-CAC8F91488A5 Mime-Version: 1.0 (1.0) From: Benjamin Beurdouche X-Mailer: iPhone Mail (16B92) In-Reply-To: Date: Tue, 27 Nov 2018 08:50:07 +0100 Cc: Katriel Cohn-Gordon , mls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <204B9046-FFFE-4826-9328-A14D2AF9E735@inria.fr> References: <1543276023.2089386.1589793056.695B3920@webmail.messagingengine.com> To: Emad Omara Archived-At: Subject: Re: [MLS] Jan 2019 MLS Interim - Bay Area X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 07:50:14 -0000 --Apple-Mail-CD230EAF-751F-4136-87A7-CAC8F91488A5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I=E2=80=99ll be there as well ! B. > On Nov 27, 2018, at 12:59 AM, Emad Omara wrote: >=20 > I should be able to make it this time=20 >=20 >> On Mon, Nov 26, 2018 at 3:47 PM Katriel Cohn-Gordon wr= ote: >> I'm in. >>=20 >>=20 >> K >>=20 >>> On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote: >>> I'll be there. If folks are going to be around over the weekend, I migh= t try to arrange an implement-a-thon somewhere. >>>=20 >>> On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan wrote: >>> Hello mlswg, >>>=20 >>> The chairs would like to propose the following time/date for the next ML= S interim: >>> January 14-15, 2019 >>> SF Bay Area, California, USA >>> Host: TBD >>>=20 >>> This is the week after RWC 2019 (https://rwc.iacr..org/2019/), so we sho= uld expect some overlap in the set of participants. >>>=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 respon= se. There will be a remote participation option. >>>=20 >>> Sean and 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 >>=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-CD230EAF-751F-4136-87A7-CAC8F91488A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Hel= lo,

    I=E2=80=99ll be there a= s well !
    B.

    On Nov 27, 2018,= at 12:59 AM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> wrote:

    I shou= ld be able to make it this time 

    On Mon, Nov 26, 2018 at 3:47 PM Katriel Cohn-Gordo= n <me@katriel.co.uk> wrote:
    I'm in.


    K

    On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote:
    I'll be there.  If folks are= going to be around over the weekend, I might try to arrange an implement-a-= thon somewhere.

    On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan <nick= =3D40c= loudflare.com@dmarc.ietf.org> wrote:
    Hello mlswg,

    The chairs would like to propose the following time/date for the next M= LS interim:
    January 14-15, 2019
    SF Bay Area, California, USA
    Host: TBD

    This is the week after RWC 2019 (https://rwc.iacr..org/2019/), so we should expect som= e overlap in the set of participants.

    Please indicate if you would plan on attending an interim on these date= s. 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 respo= nse. There will be a remote participation option.

    Sean and Nick
    ___________________________________= ____________
    MLS mailing list
    _______________________________________________
    MLS mailing list

    _______________________________________________
    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-CD230EAF-751F-4136-87A7-CAC8F91488A5-- From nobody Mon Nov 26 23:58:48 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 3DCDE12008A for ; Mon, 26 Nov 2018 23:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIMWL_WL_MED=-1.459, 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=pmi8K7BS; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=C+Ug3jM1 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 ose1qalWi-ip for ; Mon, 26 Nov 2018 23:58:45 -0800 (PST) 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 76935127133 for ; Mon, 26 Nov 2018 23:58:45 -0800 (PST) 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 wAR7s1Z3008767; Mon, 26 Nov 2018 23:58:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=PnNiNGivKtXBpbLa3NhqhfihDSviR9AdamSwpWsF0wo=; b=pmi8K7BS3Xu7+cjdsA+OIq1g+E+Nu7EvV2vGPv49dEOwK+IYwJEYsqUZ6rEkiqJ8vmKQ V6tkWWhWg3ojojAhi0aNR5lkgpfNahwWmhx4phdTzdimNsc77kGM+ZOIVS8Nj/rdLDiZ usAe5x+SpwF/cYMsFqsVWS016ReePxx4edQ= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2p10d1g789-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 26 Nov 2018 23:58:44 -0800 Received: from frc-hub04.TheFacebook.com (2620:10d:c021:18::174) by frc-hub03.TheFacebook.com (2620:10d:c021:18::173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 26 Nov 2018 23:58:42 -0800 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Mon, 26 Nov 2018 23:58:42 -0800 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=PnNiNGivKtXBpbLa3NhqhfihDSviR9AdamSwpWsF0wo=; b=C+Ug3jM1Cwk5XZA8y3fjzRQTo3Y9qw285dlv5Tekadthj6YWX0ODyNJt7poZUHa5k5hFYBJdksCZdWk6Ov/wbfK2CnKD+iX3k+6vFzonVHQYjgyqnWcmSmdqPGVB3zw3GUlFRTFMGCbGy0w4ReVmOqs1OngO3DR+n804Bc2N//0= Received: from MWHPR15MB1295.namprd15.prod.outlook.com (10.175.3.21) by MWHPR15MB1869.namprd15.prod.outlook.com (10.174.100.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.15; Tue, 27 Nov 2018 07:58:41 +0000 Received: from MWHPR15MB1295.namprd15.prod.outlook.com ([fe80::65be:71a4:c4a:2972]) by MWHPR15MB1295.namprd15.prod.outlook.com ([fe80::65be:71a4:c4a:2972%2]) with mapi id 15.20.1361.019; Tue, 27 Nov 2018 07:58:40 +0000 From: Jon Millican To: Benjamin Beurdouche CC: Emad Omara , Katriel Cohn-Gordon , "mls@ietf.org" Thread-Topic: [MLS] Jan 2019 MLS Interim - Bay Area Thread-Index: AQHUheFrWS0T8JdoKUeS1dIX0SCUU6ViuBoAgAAAzICAAANqAIAAg46AgAACYzw= Date: Tue, 27 Nov 2018 07:58:40 +0000 Message-ID: <8637151C-286D-4F04-B80B-58F7D358B0EC@fb.com> References: <1543276023.2089386.1589793056.695B3920@webmail.messagingengine.com> , <204B9046-FFFE-4826-9328-A14D2AF9E735@inria.fr> In-Reply-To: <204B9046-FFFE-4826-9328-A14D2AF9E735@inria.fr> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.255.236.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1869; 20:IM0iQrZnM/+1/H2i3NFzRStHsZbg12K9vtYQARZzLHdJECJbu9DmPdO2pNwIWTKf6K2YLuitAKNkLP+kG1wQPE/uwLDmc9eVFU7nJGrC1n7udJgV+/d8STZeNAEMlXVPJ4C44M+pjcZ99GI1kEmKsX3GnMLr8wIrvmldUg8d+7Y= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 87574b9b-8f48-4c95-19bc-08d6543e2530 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1869; x-ms-traffictypediagnostic: MWHPR15MB1869: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231443)(11241501185)(944501410)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:MWHPR15MB1869; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1869; x-forefront-prvs: 086943A159 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(39860400002)(366004)(189003)(199004)(606006)(478600001)(14454004)(6436002)(36756003)(446003)(93886005)(966005)(229853002)(66066001)(97736004)(486006)(25786009)(102836004)(81156014)(11346002)(53546011)(186003)(476003)(2616005)(26005)(9886003)(8676002)(8936002)(68736007)(76176011)(81166006)(6506007)(6306002)(6512007)(53936002)(4326008)(575784001)(236005)(71190400001)(82746002)(54896002)(6246003)(83716004)(99286004)(7736002)(3846002)(6116002)(71200400001)(256004)(6916009)(54906003)(6486002)(33656002)(106356001)(105586002)(316002)(5660300001)(86362001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1869; H:MWHPR15MB1295.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: Pd3PWZ3GID1Sgpg9C+lyHGJ/xzcxOkdTPBQO2eq2lxy3XI3NJkEBwSjk4jm2qSzunbii5wdc4/S9JkUB6D2NDB6WiXCMom/she7ARCBxtPoPOxMnDc+f/nBR7S+lbzrVlHwiqtiFaeZWkqMS+SfKbi4tPlLVW5qoSsHbNlDNx1yFFYDuV86YhmDe9xcywDNlsKqxUHBdhPnGWXWIzzJDfdslR9zheiQUGcpjBT+B7wliEXxaRKC2SqzDd5wQldM73eI/QwjtbIihLn5gPWzmQqIbfnwwaLBLNAWWRuZkhCUCN3mA7Jr8nWcHZebcA7/xjUWEceb1Og2OLV2iD3O8v0wE+gQR/tK4fjBrURJsdOs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8637151C286D4F04B80B58F7D358B0ECfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 87574b9b-8f48-4c95-19bc-08d6543e2530 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2018 07:58:40.5306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1869 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-27_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Jan 2019 MLS Interim - Bay Area X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 07:58:47 -0000 --_000_8637151C286D4F04B80B58F7D358B0ECfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzaG91bGQgYmUgYWJsZSB0byBtYWtlIHRoaXMuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0K T24gMjcgTm92IDIwMTgsIGF0IDA4OjUwLCBCZW5qYW1pbiBCZXVyZG91Y2hlIDxiZW5qYW1pbi5i ZXVyZG91Y2hlQGlucmlhLmZyPG1haWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPj4g d3JvdGU6DQoNCkhlbGxvLA0KDQpJ4oCZbGwgYmUgdGhlcmUgYXMgd2VsbCAhDQpCLg0KDQpPbiBO b3YgMjcsIDIwMTgsIGF0IDEyOjU5IEFNLCBFbWFkIE9tYXJhIDxlbWFkb21hcmE9NDBnb29nbGUu Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzplbWFkb21hcmE9NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnPj4gd3JvdGU6DQoNCkkgc2hvdWxkIGJlIGFibGUgdG8gbWFrZSBpdCB0aGlzIHRpbWUN Cg0KT24gTW9uLCBOb3YgMjYsIDIwMTggYXQgMzo0NyBQTSBLYXRyaWVsIENvaG4tR29yZG9uIDxt ZUBrYXRyaWVsLmNvLnVrPG1haWx0bzptZUBrYXRyaWVsLmNvLnVrPj4gd3JvdGU6DQpJJ20gaW4u DQoNCg0KSw0KDQpPbiBNb24sIDI2IE5vdiAyMDE4LCBhdCAxMTo0NCBQTSwgUmljaGFyZCBCYXJu ZXMgd3JvdGU6DQpJJ2xsIGJlIHRoZXJlLiAgSWYgZm9sa3MgYXJlIGdvaW5nIHRvIGJlIGFyb3Vu ZCBvdmVyIHRoZSB3ZWVrZW5kLCBJIG1pZ2h0IHRyeSB0byBhcnJhbmdlIGFuIGltcGxlbWVudC1h LXRob24gc29tZXdoZXJlLg0KDQpPbiBNb24sIE5vdiAyNiwgMjAxOCBhdCA2OjM5IFBNIE5pY2sg U3VsbGl2YW4gPG5pY2s9NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBj bG91ZGZsYXJlLmNvbUBkbWFyYy4uaWV0Zi5vcmc+PiB3cm90ZToNCkhlbGxvIG1sc3dnLA0KDQpU aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIHRpbWUvZGF0ZSBm b3IgdGhlIG5leHQgTUxTIGludGVyaW06DQpKYW51YXJ5IDE0LTE1LCAyMDE5DQpTRiBCYXkgQXJl YSwgQ2FsaWZvcm5pYSwgVVNBDQpIb3N0OiBUQkQNCg0KVGhpcyBpcyB0aGUgd2VlayBhZnRlciBS V0MgMjAxOSAoaHR0cHM6Ly9yd2MuaWFjci4ub3JnLzIwMTkvPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcndjLmlhY3Iub3JnXzIwMTlfJmQ9RHdN RmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT11 ODkySEtfSWRRR3NuUnZMc0hWY3ZTaFVtSmNPcnU4TGRpdDQ2QU1VY3RrJnM9empPTlZ5QW9yWnNC VzlnOHJqWGFtRHltbjd5cUxFcW1YT3NsTm1LOHNZcyZlPT4pLCBzbyB3ZSBzaG91bGQgZXhwZWN0 IHNvbWUgb3ZlcmxhcCBpbiB0aGUgc2V0IG9mIHBhcnRpY2lwYW50cy4NCg0KUGxlYXNlIGluZGlj YXRlIGlmIHlvdSB3b3VsZCBwbGFuIG9uIGF0dGVuZGluZyBhbiBpbnRlcmltIG9uIHRoZXNlIGRh dGVzLiBJZiB0aGlzIGRhdGUgYW5kIGxvY2F0aW9uIGFyZSBub3Qgc3VpdGFibGUgYW5kIHlvdSBw bGFubmVkIHRvIGNvbWUsIHBsZWFzZSBpbmRpY2F0ZSB5b3VyIGV4cGVjdGVkIGxldmVsIG9mIHBh cnRpY2lwYXRpb24gaW4gdGhlIGludGVyaW0gaW4geW91ciByZXNwb25zZS4gVGhlcmUgd2lsbCBi ZSBhIHJlbW90ZSBwYXJ0aWNpcGF0aW9uIG9wdGlvbi4NCg0KU2VhbiBhbmQgTmljaw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxp c3QNCk1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmZD1E d01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZt PXU4OTJIS19JZFFHc25SdkxzSFZjdlNoVW1KY09ydThMZGl0NDZBTVVjdGsmcz1wTTAyZmVLbm4x a0VWZUVZbnphaTR2ZXRPY21UcC16V2RqZGRfWjhZTU1NJmU9Pg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxpc3QNCk1MU0BpZXRm Lm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmZD1Ed01GYVEmYz01VkQw UlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXU4OTJIS19JZFFH c25SdkxzSFZjdlNoVW1KY09ydThMZGl0NDZBTVVjdGsmcz1wTTAyZmVLbm4xa0VWZUVZbnphaTR2 ZXRPY21UcC16V2RqZGRfWjhZTU1NJmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0 bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21s czxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3lj ZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09dTg5MkhLX0lkUUdzblJ2THNIVmN2 U2hVbUpjT3J1OExkaXQ0NkFNVWN0ayZzPXBNMDJmZUtubjFrRVZlRVluemFpNHZldE9jbVRwLXpX ZGpkZF9aOFlNTU0mZT0+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX21scyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1N MENWRUp5ZEJWVVhfYnZFcU1hODRRJm09dTg5MkhLX0lkUUdzblJ2THNIVmN2U2hVbUpjT3J1OExk aXQ0NkFNVWN0ayZzPXBNMDJmZUtubjFrRVZlRVluemFpNHZldE9jbVRwLXpXZGpkZF9aOFlNTU0m ZT0+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxT IG1haWxpbmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX21scyZkPUR3SUNBZyZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcm cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09dTg5MkhLX0lkUUdzblJ2THNIVmN2U2hVbUpjT3J1 OExkaXQ0NkFNVWN0ayZzPXBNMDJmZUtubjFrRVZlRVluemFpNHZldE9jbVRwLXpXZGpkZF9aOFlN TU0mZT0NCg== --_000_8637151C286D4F04B80B58F7D358B0ECfbcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpJ IHNob3VsZCBiZSBhYmxlIHRvIG1ha2UgdGhpcy48YnI+DQo8YnI+DQo8ZGl2IGRpcj0ibHRyIiBp ZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2IGRp cj0ibHRyIj48YnI+DQpPbiAyNyBOb3YgMjAxOCwgYXQgMDg6NTAsIEJlbmphbWluIEJldXJkb3Vj aGUgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyIj5iZW5q YW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0 ciI+PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5IZWxsbyw8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SeKAmWxsIGJlIHRoZXJlIGFzIHdlbGwgITwvZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+Qi48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCk9uIE5vdiAy NywgMjAxOCwgYXQgMTI6NTkgQU0sIEVtYWQgT21hcmEgJmx0OzxhIGhyZWY9Im1haWx0bzplbWFk b21hcmE9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIj5lbWFkb21hcmE9NDBnb29nbGUuY29t QGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXYgZGlyPSJhdXRv Ij5JIHNob3VsZCBiZSBhYmxlIHRvIG1ha2UgaXQgdGhpcyB0aW1lJm5ic3A7PC9kaXY+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciI+ T24gTW9uLCBOb3YgMjYsIDIwMTggYXQgMzo0NyBQTSBLYXRyaWVsIENvaG4tR29yZG9uICZsdDs8 YSBocmVmPSJtYWlsdG86bWVAa2F0cmllbC5jby51ayI+bWVAa2F0cmllbC5jby51azwvYT4mZ3Q7 IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQo8dT48L3U+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vvcmdp YSxzZXJpZiI+SSdtIGluLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Z2VvcmdpYSxzZXJpZiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpnZW9yZ2lhLHNlcmlmIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdl b3JnaWEsc2VyaWYiPks8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uIE1v biwgMjYgTm92IDIwMTgsIGF0IDExOjQ0IFBNLCBSaWNoYXJkIEJhcm5lcyB3cm90ZTo8YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+SSdsbCBiZSB0 aGVyZS4mbmJzcDsgSWYgZm9sa3MgYXJlIGdvaW5nIHRvIGJlIGFyb3VuZCBvdmVyIHRoZSB3ZWVr ZW5kLCBJIG1pZ2h0IHRyeSB0byBhcnJhbmdlIGFuIGltcGxlbWVudC1hLXRob24gc29tZXdoZXJl Ljxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+PGJy Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+T24gTW9uLCBOb3YgMjYsIDIwMTggYXQg NjozOSBQTSBOaWNrIFN1bGxpdmFuICZsdDtuaWNrPTxhIGhyZWY9Im1haWx0bzo0MGNsb3VkZmxh cmUuY29tQGRtYXJjLi5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwY2xvdWRmbGFyZS5jb21A ZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tcmlnaHQ6MHB4O21hcmdpbi1ib3R0b206MHB4O21h cmdpbi1sZWZ0OjAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHlsZTpz b2xpZDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgi Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlm Ij5IZWxsbyBtbHN3Zyw8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBj aGFpcnMgd291bGQgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGltZS9kYXRlIGZvciB0 aGUgbmV4dCBNTFMgaW50ZXJpbTo8YnI+DQo8L2Rpdj4NCjxkaXY+SmFudWFyeSAxNC0xNSwgMjAx OTxicj4NCjwvZGl2Pg0KPGRpdj5TRiBCYXkgQXJlYSwgQ2FsaWZvcm5pYSwgVVNBPGJyPg0KPC9k aXY+DQo8ZGl2Pkhvc3Q6IFRCRDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ VGhpcyBpcyB0aGUgd2VlayBhZnRlciBSV0MgMjAxOSAoPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19yd2MuaWFjci5vcmdfMjAxOV8m YW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TTBDVkVKeWRC VlVYX2J2RXFNYTg0USZhbXA7bT11ODkySEtfSWRRR3NuUnZMc0hWY3ZTaFVtSmNPcnU4TGRpdDQ2 QU1VY3RrJmFtcDtzPXpqT05WeUFvclpzQlc5ZzhyalhhbUR5bW43eXFMRXFtWE9zbE5tSzhzWXMm YW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9yd2MuaWFjci4ub3JnLzIwMTkvPC9hPiks DQogc28gd2Ugc2hvdWxkIGV4cGVjdCBzb21lIG92ZXJsYXAgaW4gdGhlIHNldCBvZiBwYXJ0aWNp cGFudHMuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2UgaW5kaWNh dGUgaWYgeW91IHdvdWxkIHBsYW4gb24gYXR0ZW5kaW5nIGFuIGludGVyaW0gb24gdGhlc2UgZGF0 ZXMuIElmIHRoaXMgZGF0ZSBhbmQgbG9jYXRpb24gYXJlIG5vdCBzdWl0YWJsZSBhbmQgeW91IHBs YW5uZWQgdG8gY29tZSwgcGxlYXNlIGluZGljYXRlIHlvdXIgZXhwZWN0ZWQgbGV2ZWwgb2YgcGFy dGljaXBhdGlvbiBpbiB0aGUgaW50ZXJpbSBpbiB5b3VyIHJlc3BvbnNlLiBUaGVyZSB3aWxsIGJl IGEgcmVtb3RlIHBhcnRpY2lwYXRpb24NCiBvcHRpb24uPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5TZWFuIGFuZCBOaWNrPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpnZW9yZ2lhLHNlcmlmIj5NTFMgbWFpbGluZyBsaXN0PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj48YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+TUxTQGlldGYub3JnPC9hPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1w O3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7bT11ODkySEtfSWRRR3NuUnZMc0hWY3ZTaFVt SmNPcnU4TGRpdDQ2QU1VY3RrJmFtcDtzPXBNMDJmZUtubjFrRVZlRVluemFpNHZldE9jbVRwLXpX ZGpkZF9aOFlNTU0mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbHM8L2E+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxkaXY+PHU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3U+PGJyPg0KPC9kaXY+DQo8ZGl2Pk1MUyBtYWlsaW5nIGxpc3Q8YnI+DQo8L2Rpdj4NCjxk aXY+PGEgaHJlZj0ibWFpbHRvOk1MU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1MU0BpZXRm Lm9yZzwvYT48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9 TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7bT11ODkySEtfSWRRR3NuUnZMc0hWY3ZTaFVtSmNP cnU4TGRpdDQ2QU1VY3RrJmFtcDtzPXBNMDJmZUtubjFrRVZlRVluemFpNHZldE9jbVRwLXpXZGpk ZF9aOFlNTU0mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbHM8L2E+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpNTFMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk1MU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX21scyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1N MENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXU4OTJIS19JZFFHc25SdkxzSFZjdlNoVW1KY09y dThMZGl0NDZBTVVjdGsmYW1wO3M9cE0wMmZlS25uMWtFVmVFWW56YWk0dmV0T2NtVHAteldkamRk X1o4WU1NTSZhbXA7ZT0iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9hPjxicj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+TUxTIG1haWxpbmcgbGlzdDwv c3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIj5NTFNAaWV0Zi5v cmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fbWxzJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPU0w Q1ZFSnlkQlZVWF9idkVxTWE4NFEmYW1wO209dTg5MkhLX0lkUUdzblJ2THNIVmN2U2hVbUpjT3J1 OExkaXQ0NkFNVWN0ayZhbXA7cz1wTTAyZmVLbm4xa0VWZUVZbnphaTR2ZXRPY21UcC16V2RqZGRf WjhZTU1NJmFtcDtlPSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8 L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPjxzcGFuPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxz cGFuPk1MUyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOk1M U0BpZXRmLm9yZyI+TUxTQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZhbXA7ZD1Ed0lDQWcmYW1wO2M9NVZEMFJUdE5s VGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXU4OTJIS19J ZFFHc25SdkxzSFZjdlNoVW1KY09ydThMZGl0NDZBTVVjdGsmYW1wO3M9cE0wMmZlS25uMWtFVmVF WW56YWk0dmV0T2NtVHAteldkamRkX1o4WU1NTSZhbXA7ZT0iPmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fbWxzJmFtcDtkPUR3SUNBZyZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDty PU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmYW1wO209dTg5MkhLX0lkUUdzblJ2THNIVmN2U2hVbUpj T3J1OExkaXQ0NkFNVWN0ayZhbXA7cz1wTTAyZmVLbm4xa0VWZUVZbnphaTR2ZXRPY21UcC16V2Rq ZGRfWjhZTU1NJmFtcDtlPTwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_8637151C286D4F04B80B58F7D358B0ECfbcom_-- From nobody Tue Nov 27 05:24:47 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA186130DFF for ; Tue, 27 Nov 2018 05:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPtSC38PjRPh for ; Tue, 27 Nov 2018 05:24:42 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 A6F01130DF9 for ; Tue, 27 Nov 2018 05:24:41 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id l9so22653655wrt.13 for ; Tue, 27 Nov 2018 05:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=L9HSqjb9Wq1YzLheLpieNyMyucIrj+jWaJ526TQw8q8=; b=UJn/xk1NiGwZFKSautGtCx37GY4jnxXUjFFIimU8RiSCyHXxijlrlP7Xy/DOf274Au Tx/qdrn8H3EToXLwzzBnVgKed0/EDPK/FVAlXe47/0qXjdaOJin9+VR/aiBQllkutlY4 /2iPgwSSqbSUCALzsO89LgLbBcyCL4npDJJxCTFeZYJt84rTMcCILukJ3kzSPzkwycKn FH1HrPi7wHeCNi5XHWeQfXx1nOMOGvqFf2EvQpGBrxdWDIauOoESlKCBpK2hNT31MOUS t0CFxI6dhhubRbx7ezioI5DoXcIo2HliF8Gi445SPAAeB4X10SZ3rfLLJHrDBVjt2Tuf 859g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=L9HSqjb9Wq1YzLheLpieNyMyucIrj+jWaJ526TQw8q8=; b=UpnragNcTIXW9pRYkYY/0/F+CRCRibufen+ErBew/+SxiKKUbEBniET6v7b1UidJGL MFowS3NStRjxC38OsxaHMdJTO1kT6uquOidmCodxS8oQt+ua9gfE8NOXxXpqdgabiLuQ bFTzZD4KNnPZ5OfITZDQSBRp+jG+6VYFN6naPc3xk2adTKm2RKTJAUfkLRGTFNARHHv6 kY0uEbKb0P4N1/0wH8kUTqoCl/pQotwsYhvYbULlmNJOjF8G7AuhngBAU525Fa5PzJJM yWT4ivkYmY8xj9JCFxU3HZoIeASLSghN7WbWuBKs+xs3/RTlG092Rm+AxX7z/T0aSREx f9qA== X-Gm-Message-State: AA+aEWYPfSpNHBySuXvGXiRHkqFcBDc73arynOowM4I8yWmFUOyQfyFp 1KO1vevg2079RAcbH2D6lqY= X-Google-Smtp-Source: AFSGD/VqHll/YsIc9xq57alk3B0lYk9owEbxh1W4ajeF4J1QHo9tjwQGVMjbxecVzn9wR4hmqUuz/A== X-Received: by 2002:a5d:410e:: with SMTP id l14mr27357380wrp.61.1543325080032; Tue, 27 Nov 2018 05:24:40 -0800 (PST) Received: from [172.20.87.192] (nat-5725.dyn.hrz.tu-darmstadt.de. [130.83.222.93]) by smtp.gmail.com with ESMTPSA id b18sm2594300wrw.83.2018.11.27.05.24.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 05:24:38 -0800 (PST) From: Karthikeyan Bhargavan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_96572DC4-1785-4C8C-B8DB-CF094A70F54E" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 27 Nov 2018 14:24:38 +0100 In-Reply-To: <8637151C-286D-4F04-B80B-58F7D358B0EC@fb.com> Cc: Benjamin Beurdouche , Emad Omara , Katriel Cohn-Gordon , "mls@ietf.org" To: Jon Millican References: <1543276023.2089386.1589793056.695B3920@webmail.messagingengine.com> <204B9046-FFFE-4826-9328-A14D2AF9E735@inria.fr> <8637151C-286D-4F04-B80B-58F7D358B0EC@fb.com> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [MLS] Jan 2019 MLS Interim - Bay Area X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 13:24:45 -0000 --Apple-Mail=_96572DC4-1785-4C8C-B8DB-CF094A70F54E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I will try to be there. > On 27 Nov 2018, at 08:58, Jon Millican wrote: >=20 > I should be able to make this. >=20 > Sent from my iPhone >=20 > On 27 Nov 2018, at 08:50, Benjamin Beurdouche = > = wrote: >=20 >> Hello, >>=20 >> I=E2=80=99ll be there as well ! >> B. >>=20 >> On Nov 27, 2018, at 12:59 AM, Emad Omara = > wrote: >>=20 >>> I should be able to make it this time=20 >>>=20 >>> On Mon, Nov 26, 2018 at 3:47 PM Katriel Cohn-Gordon = > wrote: >>> I'm in. >>>=20 >>>=20 >>> K >>>=20 >>> On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote: >>>> I'll be there. If folks are going to be around over the weekend, I = might try to arrange an implement-a-thon somewhere. >>>>=20 >>>> On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan = > wrote: >>>> Hello mlswg, >>>>=20 >>>> The chairs would like to propose the following time/date for the = next MLS interim: >>>> January 14-15, 2019 >>>> SF Bay Area, California, USA >>>> Host: TBD >>>>=20 >>>> This is the week after RWC 2019 (https://rwc.iacr..org/2019/ = ), so we should expect some overlap in the set of = participants. >>>>=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. There will be a remote participation option. >>>>=20 >>>> Sean and 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 = >>>=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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvEq= Ma84Q&m=3Du892HK_IdQGsnRvLsHVcvShUmJcOru8Ldit46AMUctk&s=3DpM02feKnn1kEVeEY= nzai4vetOcmTp-zWdjdd_Z8YMMM&e=3D = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_96572DC4-1785-4C8C-B8DB-CF094A70F54E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = will try to be there.

    On 27 Nov 2018, at 08:58, Jon = Millican <jmillican@fb.com> wrote:

    I should be able to make this.

    Sent from my iPhone

    On 27 Nov 2018, at 08:50, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:

    Hello,

    I=E2=80=99ll be there as well !
    B.

    On Nov 27, 2018, at 12:59 AM, Emad Omara <emadomara=3D40google.com@dmarc.ietf.org> wrote:

    I should be able to make it this = time 

    On Mon, Nov 26, 2018 at 3:47 PM Katriel = Cohn-Gordon <me@katriel.co.uk> wrote:
    I'm in.


    K

    On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes = wrote:
    I'll be there.  If folks are going to = be around over the weekend, I might try to arrange an implement-a-thon = somewhere.

    On Mon, Nov 26, 2018 at 6:39 PM Nick = Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:
    Hello mlswg,

    The chairs would like to propose the following time/date = for the next MLS interim:
    January 14-15, 2019
    SF Bay Area, California, USA
    Host: TBD

    This is the week after RWC 2019 (https://rwc.iacr..org/2019/), so we should expect some overlap in the set of participants.

    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. There will be a remote = participation option.

    Sean and 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
    _______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://www.ietf.org/mailman/listinfo/mls
    _______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&am= p;r=3DM0CVEJydBVUX_bvEqMa84Q&m=3Du892HK_IdQGsnRvLsHVcvShUmJcOru8Ldit46= AMUctk&s=3DpM02feKnn1kEVeEYnzai4vetOcmTp-zWdjdd_Z8YMMM&e=3D
    _______________________________________________
    MLS = mailing list
    MLS@ietf.org
    https://www.ietf.org/mailman/listinfo/mls

    = --Apple-Mail=_96572DC4-1785-4C8C-B8DB-CF094A70F54E-- From nobody Tue Nov 27 07:16: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 235231293FB for ; Tue, 27 Nov 2018 07:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symbolic.software Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2OsnJmIlXPl for ; Tue, 27 Nov 2018 07:16:42 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF381277C8 for ; Tue, 27 Nov 2018 07:16:42 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id l3so229235wme.0 for ; Tue, 27 Nov 2018 07:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DaTVE6HW5VPK1pOudM/ojEn60YdKVWZDLX1NKs0bejg=; b=g8Uxw6tjIf2FcTuuICuL/CtV3FsC+d1jEwfVLLdyQHqWHIY8RkuflUguDZWBgKc6Qp 7M5ocsJysiI9wgJGmLqiCqEp/cwDQ2hJt+8SD7hAntcWupyJriZXosaQr0yNAkwUIwF6 lXWbl9TeoCUh4kVc7oxegJhNA0R3i/Z4oj68U= 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=DaTVE6HW5VPK1pOudM/ojEn60YdKVWZDLX1NKs0bejg=; b=i6c2P7xIcAXni46OORDY0IMibvOGfjccIs48tP8vpAZX+16AQYk51w1yNvHk/v6X1K Fk0MpgophI0uxp4RCb5GV8bZ4AZDkplCC+ozW+tHW9Pn81MZKPzJtLkxmkP1F9n4LNiR T1Z0nYIXybL0+zrfwg0RsmesRFsAF7uDZ3TOUU93zmsiOcuw7enTpWxLJDVKek7nbLjK 08IWB9qPsj1vxocY0q5DS9DCvqCUn9q6yXmzxU9FDXICdMQPdioMJZEtO9kZ95ZYwL6+ tIJlioR56xoKZzdeLVpzi7pr9MD3/adJ8bvBIYwFIwcd1UiYf1oTtHlXHMs4rjWqApVQ 8Fvg== X-Gm-Message-State: AA+aEWZ/wUQOG8q7PuaxuzxfYr7ZlxxQvr7FoqPmul9a0wH1uWkcp9za Tjq/pHlpyUBPV8qwnOGPAX+EHwLRDvT484I0TzONlntLTlo= X-Google-Smtp-Source: AFSGD/UDzfu0vIzTT5YFMmTeUEviyMhzqNtaH8BqEzf3yhyX9vu0MjB0RXDf3ts3dotEO0NYmdHcbN3VN04d+ixrqQI= X-Received: by 2002:a1c:9513:: with SMTP id x19mr9424476wmd.112.1543331800162; Tue, 27 Nov 2018 07:16:40 -0800 (PST) MIME-Version: 1.0 References: <1543276023.2089386.1589793056.695B3920@webmail.messagingengine.com> <204B9046-FFFE-4826-9328-A14D2AF9E735@inria.fr> <8637151C-286D-4F04-B80B-58F7D358B0EC@fb.com> In-Reply-To: From: Nadim Kobeissi Date: Tue, 27 Nov 2018 16:16:29 +0100 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000b85616057ba6ef6a" Archived-At: Subject: Re: [MLS] Jan 2019 MLS Interim - Bay Area X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 15:16:45 -0000 --000000000000b85616057ba6ef6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, I'll be able to attend but only on the first day. See you soon. Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office On Tue, Nov 27, 2018 at 2:25 PM Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > I will try to be there. > > On 27 Nov 2018, at 08:58, Jon Millican wrote: > > I should be able to make this. > > Sent from my iPhone > > On 27 Nov 2018, at 08:50, Benjamin Beurdouche < > benjamin.beurdouche@inria.fr> wrote: > > Hello, > > I=E2=80=99ll be there as well ! > B. > > On Nov 27, 2018, at 12:59 AM, Emad Omara < > emadomara=3D40google.com@dmarc.ietf.org> wrote: > > I should be able to make it this time > > On Mon, Nov 26, 2018 at 3:47 PM Katriel Cohn-Gordon > wrote: > >> I'm in. >> >> >> K >> >> On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote: >> >> I'll be there. If folks are going to be around over the weekend, I migh= t >> try to arrange an implement-a-thon somewhere. >> >> On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan > 40cloudflare.com@dmarc.ietf.org <40cloudflare.com@dmarc..ietf.org>> >> wrote: >> >> Hello mlswg, >> >> The chairs would like to propose the following time/date for the next ML= S >> interim: >> January 14-15, 2019 >> SF Bay Area, California, USA >> Host: TBD >> >> This is the week after RWC 2019 (https://rwc.iacr..org/2019/ >> ), >> so we should expect some overlap in the set of participants. >> >> 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. There will be a remote participation option. >> >> Sean and 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 >> >> > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf..org_mail= man_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvE= qMa84Q&m=3Du892HK_IdQGsnRvLsHVcvShUmJcOru8Ldit46AMUctk&s=3DpM02feKnn1kEVeEY= nzai4vetOcmTp-zWdjdd_Z8YMMM&e=3D > > > _______________________________________________ > 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 > --000000000000b85616057ba6ef6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi everyone,
    I'll be able to attend but only on th= e first day. See you soon.
    <= div dir=3D"ltr">

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


    On = Tue, Nov 27, 2018 at 2:25 PM Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
    I will try to be there.
    =

    I should be able to make this.

    Sent from my iPhone
    Hello,

    I=E2=80=99ll be there as well !
    B.

    On Nov 27, 2018, at 12:59 AM, Emad Omara <emadomara=3D40google.com@dma= rc.ietf.org> wrote:

    I should be able to make it this time=C2=A0

    On Mon, Nov 26, 2018 at 3:47 PM Katriel Cohn-Gordon <me@katriel.co.uk>= ; wrote:
    I'm in.


    K

    On Mon, 26 Nov 2018, at 11:44 PM, Richard Barnes wrote:
    I'll be there.=C2=A0 If folks are going to be around o= ver the weekend, I might try to arrange an implement-a-thon somewhere.

    On Mon, Nov 26, 2018 at 6:39 PM Nick Sullivan <nick=3D<= a href=3D"mailto:40cloudflare.com@dmarc..ietf.org" target=3D"_blank">40clou= dflare.com@dmarc.ietf.org> wrote:
    Hello mlswg,

    The chairs would like to propose the following time/date for the next = MLS interim:
    January 14-15, 2019
    SF Bay Area, California, USA
    Host: TBD

    This is the week after RWC 2019 (https://rwc.iacr..org/2019/), so we should expect some overlap in the set of participants.

    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. There will be a remote participation option.

    Sean and Nick
    __________________________________= _____________
    MLS mailing list
    _______________________________________________
    MLS mailing list

    _______________________________________________
    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://ww= w.ietf.org/mailman/listinfo/mls

    _= ______________________________________________
    MLS mailing list
    MLS@ietf.org
    https://www.ietf.org/mailman/listinfo/mls
    --000000000000b85616057ba6ef6a-- From nobody Tue Nov 27 14:26:37 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 A0E31130DD0 for ; Tue, 27 Nov 2018 14:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXuf98CEPobo for ; Tue, 27 Nov 2018 14:26:31 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 69533130DCC for ; Tue, 27 Nov 2018 14:26:31 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id v23so16281328otk.9 for ; Tue, 27 Nov 2018 14:26:31 -0800 (PST) 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=Ch7KeqcBbCSjGSP6D0kSvSoazqUY/R50ciz6lShIiHw=; b=JJjTAxO/mO2urwdJDio94PrJRxbHddhoqGAjoRd7xaXN9dREuoUovU+X/ZfPolAK4w Cguwv++WIkBjkDBEhDYoRHsem2Fqx4X/H5EmLJKlBVXN5qnlZEZeSo7U1npLNcflxjKB rrMqBw452iRpUpX4bJ5ncvHq/6LrV3WIpAsdQ= 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=Ch7KeqcBbCSjGSP6D0kSvSoazqUY/R50ciz6lShIiHw=; b=GYRGQJ3rkxquS8Z/W7cISCx3IcSQZstI0XWdlQHUcgSriTdYkfZPufrzWa/5dnIKWE RPLBy0Z/ggm0W8rI3yuLntTBXNm2mDAm0TsDaqC5eYGiLPixt0eINTsVZFCA3RtiTy9N ApNusBQKYrCIvXE7eyfuDbX9Zj+vkOdcSwV7Jkgw97D25aQ95MgJ82JPTvvg1z6ICLN6 9UyT/0dcVv/h6NpFRm93ZabK5NmmrMPXYS1ploQcCN5Cy1kapcLupuHDKQN1qPy8ZoBm 2Eo32nPGXguq0YFMyZza4SOvGkLf+t9DL7eKK4lEM6xli+Bu2AsJzArRbwqwOcRpygZ6 +dYA== X-Gm-Message-State: AA+aEWbxagObi5wt1QcNrMOJIRRYLCJ7anVG4/i88fSOs13BmkcGFIaK Y8Hx3eou2r2S03S0tZ3BqPEyqIIBnChm2yYeLOLVc6/37z0= X-Google-Smtp-Source: AFSGD/XO7A2dKSBeaeY1oeR/p2Hdbh5gNlBMGFF+CI20Mn7kkJCXcXEm8mgMCzXpVv9ilfZVBS1fQhJ6bTMHCgBg6Tg= X-Received: by 2002:a9d:3f7:: with SMTP id f110mr16562623otf.171.1543357590165; Tue, 27 Nov 2018 14:26:30 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Tue, 27 Nov 2018 14:26:19 -0800 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000ec872a057bacf0b0" Archived-At: Subject: [MLS] IETF 103 Draft Minutes X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 22:26:36 -0000 --000000000000ec872a057bacf0b0 Content-Type: text/plain; charset="UTF-8" All, I have posted the draft minutes from IETF 103 on Github: https://github.com/mlswg/wg-materials/blob/master/ietf103/minutes.md. Thanks to Chris Wood and Joe Salowey for volunteering to take the minutes. If there are corrections, please post them to the list or create a PR. We'll be posting the minutes to the Datatracker after any corrections. Sean & Nick --000000000000ec872a057bacf0b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    --000000000000ec872a057bacf0b0-- From nobody Fri Nov 30 09:39:06 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 AAA03130E8D; Fri, 30 Nov 2018 09:39:03 -0800 (PST) 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.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154359954366.27518.9423179282423486369.idtracker@ietfa.amsl.com> Date: Fri, 30 Nov 2018 09:39:03 -0800 Archived-At: Subject: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 17:39:04 -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-2019-mls-01 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner City: San Francisco Country: US Session 1: Date: 2019-01-14 Start Time: 09:00 America/Los_Angeles Duration: 08:00 Remote Participation Information: Remote participation information will be obtained at the time of approval Agenda Note: Session 2: Date: 2019-01-15 Start Time: 09:00 America/Los_Angeles Duration: 08:00 Remote Participation Information: Remote participation information will be obtained at the time of approval Agenda Note: --------------------------------------------------------- From nobody Fri Nov 30 09:41: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 7B699130E94 for ; Fri, 30 Nov 2018 09:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 dOgmqH8ifv1Z for ; Fri, 30 Nov 2018 09:41:36 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 29C44130E8D for ; Fri, 30 Nov 2018 09:41:36 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id o89so3654748qko.0 for ; Fri, 30 Nov 2018 09:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=JcgLbjhZCGpQVDYPDl82As4PZRJz3+8sWmXzKFS0Akw=; b=WbsUE64xqw9gPifr0I2jllX0QVIRkMVH+zwMTdYYAO0xCe2+KzVXLjgUkwFK0eiGJG dvsXocN6p3ReTfVBassWVzLL/abhvrfU9AHVuIOJ6xJfhTXsth55PcfKhWoWG+UO/lV5 H0FcpsetbC1LHaCRWwXnkWQ/JEKNDNK+TJACw= 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=JcgLbjhZCGpQVDYPDl82As4PZRJz3+8sWmXzKFS0Akw=; b=VWAhafWGah7T94YT98ZqX6CalTESgncrVa0IO6iKRhvOC/Bu7Wy3lbbqhPN+I8QBPU tDNhSIsLcfHWbtMVLNM1JTSnVPJtTCNUoqLwONsRNgMPok4bHA9dp0no1aQNUO8oQbz1 sg3/WZc/g7zswHn0hxl0JXvxTTHz5FQIDSAh/DXpJtsINkkpVwqqgdDW+0/P9Qi66LUK l/Ub2Q97kzjuo71tpBKq3DypuheO+9EdtXguL9AXGwlnzRINBMF+JHd2bbxx9xD/j6uF NBqXlvL2kvLVU2ypccgi0BlAf/y4gEGntXFgysBj26DQwkn6cyU3kgeILxY3Wa2bX2xG fZMg== X-Gm-Message-State: AA+aEWakIg8NHJKmnxOtQa/SWSEB6bMMoJgGCgvYSf5uM0PxF4C2XLmQ BQPWiDs+WZ4eqYZYh935iE+a8iRgPoE= X-Google-Smtp-Source: AFSGD/XTqZaf3x73mmbzfeOCb0Dt1XxqkV0Ors7BN37UJDsUOHIpXWRgdKsroINn4Xl3W5Uh/B2+Jw== X-Received: by 2002:a37:ea0a:: with SMTP id t10mr5956949qkj.273.1543599695138; Fri, 30 Nov 2018 09:41:35 -0800 (PST) Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id x5sm3598073qtc.43.2018.11.30.09.41.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 09:41:34 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Fri, 30 Nov 2018 12:41:33 -0500 References: <154359954366.27518.9423179282423486369.idtracker@ietfa.amsl.com> To: mls@ietf.org In-Reply-To: <154359954366.27518.9423179282423486369.idtracker@ietfa.amsl.com> Message-Id: <2D72B93C-CB72-4ADE-B8F0-938BE04D1172@sn3rd.com> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 17:41:39 -0000 As we get closer, the README and agenda in the repo will be updated: https://github.com/mlswg/wg-materials/blob/master/interim-2019-01/ spt > On Nov 30, 2018, at 12:39, IETF Meeting Session Request Tool = wrote: >=20 >=20 > A new interim meeting request has just been submitted by Sean Turner. >=20 > This request requires approval by the Area Director of the Security = Area >=20 > The meeting can be approved here:=20 > = https://datatracker.ietf.org/meeting/interim/request/interim-2019-mls-01 >=20 >=20 >=20 > --------------------------------------------------------- > Working Group Name: Messaging Layer Security > Area Name: Security Area > Session Requester: Sean Turner >=20 > City: San Francisco > Country: US >=20 >=20 > Session 1: >=20 > Date: 2019-01-14 > Start Time: 09:00 America/Los_Angeles > Duration: 08:00 > Remote Participation Information: Remote participation information = will be obtained at the time of approval > Agenda Note:=20 > Session 2: >=20 > Date: 2019-01-15 > Start Time: 09:00 America/Los_Angeles > Duration: 08:00 > Remote Participation Information: Remote participation information = will be obtained at the time of approval > Agenda Note:=20 >=20 > --------------------------------------------------------- >=20 From nobody Fri Nov 30 10:54:50 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 33822130F33; Fri, 30 Nov 2018 10:54:42 -0800 (PST) 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.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154360408214.27594.14053178874343011278@ietfa.amsl.com> Date: Fri, 30 Nov 2018 10:54:42 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting: 2019-01-14 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 18:54:43 -0000 The Messaging Layer Security (mls) Working Group will hold a multi-day interim meeting. Session 1: 2019-01-14 09:00 to 17:00 America/Los_Angeles Session 2: 2019-01-15 09:00 to 17:00 America/Los_Angeles Meeting Location: San Francisco, US Agenda: See https://github.com/mlswg/wg-materials/blob/master/interim-2019-01/agenda.md Information about remote participation: Remote participation information will be obtained at the time of approval