From nobody Sun Jul 1 01:53: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 40689130E06 for ; Sun, 1 Jul 2018 01:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2pDioFxY5kkj for ; Sun, 1 Jul 2018 01:53:16 -0700 (PDT) Received: from VirgilSecurity.com (mail.virgilsecurity.com [199.58.211.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820A0127AC2 for ; Sun, 1 Jul 2018 01:53:16 -0700 (PDT) Received: from BIGONE (unknown [176.226.241.68]) by VirgilSecurity.com (Postfix) with ESMTPSA id A3722105AE9918; Sun, 1 Jul 2018 04:53:14 -0400 (EDT) From: "Alexey Ermishkin" To: "'Martin Thomson'" Cc: "'Katriel Cohn-Gordon'" , References: <11392542-5C22-4033-99F6-009F066F48DD@vigilsec.com> <640CFF9E-5231-4188-888A-CAB4376393F6@vigilsec.com> <1530198719.3129780.1423592624.575CB8EA@webmail.messagingengine.com> <01e701d40f7c$430f3b20$c92db160$@virgilsecurity.com> In-Reply-To: Date: Sun, 1 Jul 2018 13:53:11 +0500 Message-ID: <023e01d41118$f30d2800$d9277800$@virgilsecurity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLM+wAwts1qVAaFZnL+MDvDWV6A7AFj57CLAgaUFXIB7TBkbAEN949wAmCsBOYB+p50lwIpOgLsoiDonaA= Content-Language: ru Archived-At: Subject: Re: [MLS] Message Protection X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 08:53:19 -0000 You a right. Even though Double Ratchet spec allows fixing nonce to a constant, nobody seem to use it. So, I made amends, fixed typo and did a PR https://github.com/ekr/mls-protocol/pull/50 -----Original Message----- From: MLS On Behalf Of Martin Thomson Sent: Friday, June 29, 2018 12:57 PM To: scratch@virgilsecurity.com Cc: Katriel Cohn-Gordon ; mls@ietf.org Subject: Re: [MLS] Message Protection On Fri, Jun 29, 2018 at 5:39 PM Alexey Ermishkin wrote: > I'm not sure if nonce should be also derived as keys will be unique > and used only once. It does not seem to affect security in either way. > Signal is also using zero nonces for one time keys. In TLS we chose to derive nonces so that it would become less feasible to do precomputation attacks. Messages are often predictable, and if you can calculate a table for common responses, it might be possible to have enough values stored to compromise confidentiality. (That was the argument; not sure how much weight it carries relative to just using a stronger primitive, but there you have it.) _______________________________________________ MLS mailing list MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls From nobody Mon Jul 2 15:38: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 76E1C130E60 for ; Mon, 2 Jul 2018 15:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N2pxs8X7gm0 for ; Mon, 2 Jul 2018 15:38:41 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C1A13143B for ; Mon, 2 Jul 2018 15:38:23 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id k12-v6so1661oiw.8 for ; Mon, 02 Jul 2018 15:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E8qnYIMrQNA35+K7+o9Vj+1HeD5gUEwWO4+lS/dckgE=; b=Xd7V0u94dMCDVOdTZ6iGQykFtYUkoTTKlkvJ28QgIwPcRbzYCtsaxcyY/mebMLmcVx ZLlqI+ikNAsw0TuGQYGl8ACiAACb+POqGax0CqQeR1U3cW9STzMFFPp2ljvleumTEVkr UnIqAg5IwJqIXo5qtBozM22b61K+S7Rwcp4n+W5K4yGpaElfNCx2OqX4Ox1+Qvb6vjD4 2QAJY6/heyjVhuENDnwR34KPcnQRoaB+A6ccVUBa1DUA0BGHv5zQVcR/pD6DFc8aPeUV zqoL6hLgk4OhvmcMQZBv66ITnQcOaUqTSdvqakH/SeEw0kcZcZ0f8jvB1Fall91ONlFI lGng== 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=E8qnYIMrQNA35+K7+o9Vj+1HeD5gUEwWO4+lS/dckgE=; b=RR2/4h4UkhfWs/Lp6NK7N7i/RCLnhy/L4KAVZUZeOc6Donwab0ZavUWOaerPH+zmNY sxjELs56WTdtJaRieAkJqpaZXbgzl4IAEigZekkAHVI82IbQuMBAen7Bh+zZ5vRaW+67 ccwZek3PR8S4+MTQBFnD03p4zgHaGTCIVI0wOGswBPNscHXvaXGP0iSCEaOQ069UGVwa LbRP4CciZRTEK3TZmK+Dlngz4w2SWSnwoowb0+Bfypb3/UDMq8brDMFzNY65oFt6fjrd qeWGu4NIT2GLb3aOQHyNR9QYa2x0y11b6O/pquvKHrEVo7ATMw2sXmMyurLwIWxNmwIJ Yj6g== X-Gm-Message-State: APt69E2hrz/MLp/XSIXWfm/ugsaPkUR4wf4oFEva6TxpdaWPm0abql6O BNHsdGK5i3KEDrA6he14qIf+c2Zw7gE78IjBbuvchcUW X-Google-Smtp-Source: AAOMgpfkEMN2GKV1Y9NMy1boxUJr/oPWto2IaTmthgpcXgMTra2neNOkvipjPNpa1axAA+qE/A3JgLdtmIQ4CL6WFkA= X-Received: by 2002:aca:6ccd:: with SMTP id h196-v6mr18282441oic.298.1530571102192; Mon, 02 Jul 2018 15:38:22 -0700 (PDT) MIME-Version: 1.0 References: <153057094620.16135.5248722706886528918.idtracker@ietfa.amsl.com> In-Reply-To: <153057094620.16135.5248722706886528918.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Mon, 2 Jul 2018 22:38:06 +0000 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d9998f05700bda47" Archived-At: Subject: [MLS] Fwd: New Version Notification for draft-barnes-mls-protocol-01.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 22:38:44 -0000 --000000000000d9998f05700bda47 Content-Type: text/plain; charset="UTF-8" Hey all, I've just posted an updated draft of the MLS protocol in time for the IETF 102 deadline. Now includes TreeKEM as an option! --Richard ---------- Forwarded message --------- From: Date: Mon, Jul 2, 2018 at 10:35 PM Subject: New Version Notification for draft-barnes-mls-protocol-01.txt To: Emad Omara , Raphael Robert , Richard Barnes , Katriel Cohn-Gordon , Jon Millican A new version of I-D, draft-barnes-mls-protocol-01.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-mls-protocol Revision: 01 Title: The Messaging Layer Security (MLS) Protocol Document date: 2018-07-02 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-barnes-mls-protocol-01.txt Status: https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ Htmlized: https://tools.ietf.org/html/draft-barnes-mls-protocol-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-mls-protocol Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-mls-protocol-01 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. 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. The IETF Secretariat --000000000000d9998f05700bda47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I've just poste= d an updated draft of the MLS protocol in time for the IETF 102 deadline.= =C2=A0 Now includes TreeKEM as an option!

--Ri= chard





A new version of I-D, draft-barnes-mls-protocol-01.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-barnes-mls-protocol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Messaging Layer Security (MLS)= Protocol
Document date:=C2=A0 2018-07-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 37
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-barnes-mls-protoc= ol-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-barnes-mls-protocol-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-barnes-mls-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-mls-protocol-0= 1

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




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

The IETF Secretariat

--000000000000d9998f05700bda47-- From nobody Tue Jul 3 09:03:40 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 654F9130F96; Tue, 3 Jul 2018 09:00:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: mls@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361840.4893.17639309808885008589.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:18 -0700 Archived-At: Subject: [MLS] mls - Requested session has been scheduled for IETF 102 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.26 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:27 -0000 Dear Nick Sullivan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mls Session 1 (2:30 requested) Thursday, 19 July 2018, Morning Session I 0930-1200 Room Name: Viger size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/mls.ics Request Information: --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Nick Sullivan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 125 Conflicts to Avoid: First Priority: acme artarea cfrg dispatch iasa2 httpbis perc quic rtcweb saag secdispatch tls Second Priority: curdle dprive lamps sidr sidrops stir suit teep People who must be present: Eric Rescorla Sean Turner Cullen Jennings Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 19 09:05:15 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 AE2AF130DF9; Thu, 19 Jul 2018 09:05:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153201631267.5412.168203048859964879.idtracker@ietfa.amsl.com> Date: Thu, 19 Jul 2018 09:05:12 -0700 Archived-At: Subject: [MLS] The MLS WG has placed draft-omara-mls-architecture in state "Candidate for WG Adoption" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 16:05:13 -0000 The MLS WG has placed draft-omara-mls-architecture in state Candidate for WG Adoption (entered by Nick Sullivan) The document is available at https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ From nobody Thu Jul 19 09:06:21 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 5E88C130FD9; Thu, 19 Jul 2018 09:06:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153201637138.5449.9433216336993914525.idtracker@ietfa.amsl.com> Date: Thu, 19 Jul 2018 09:06:11 -0700 Archived-At: Subject: [MLS] The MLS WG has placed draft-barnes-mls-protocol in state "Candidate for WG Adoption" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 16:06:17 -0000 The MLS WG has placed draft-barnes-mls-protocol in state Candidate for WG Adoption (entered by Nick Sullivan) The document is available at https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ From nobody Thu Jul 19 09:45: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 E7CE51310F3 for ; Thu, 19 Jul 2018 09:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] 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 mKarDgvXsCf3 for ; Thu, 19 Jul 2018 09:45:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25F41310C2 for ; Thu, 19 Jul 2018 09:45:19 -0700 (PDT) Received: from fifthhorseman.net (unknown [IPv6:2001:67c:1232:144:93d0:9674:49b5:185e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 24A94F99A for ; Thu, 19 Jul 2018 12:45:17 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 771DA203FF; Thu, 19 Jul 2018 12:45:13 -0400 (EDT) From: Daniel Kahn Gillmor To: mls@ietf.org Date: Thu, 19 Jul 2018 12:45:13 -0400 Message-ID: <87fu0fxjhi.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 16:45:28 -0000 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. 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) I believe we should provide encrypted cover, and a mechanism for padding of handshake messages, not just for application messages. 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. 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. 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. --dkg From nobody Thu Jul 19 10:31:53 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5585C130EAF for ; Thu, 19 Jul 2018 10:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWSmtAu-Wt_R for ; Thu, 19 Jul 2018 10:31:50 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 C8266130EC6 for ; Thu, 19 Jul 2018 10:31:50 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id v13-v6so4377341pgr.10 for ; Thu, 19 Jul 2018 10:31:50 -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=WdHEqm+kIa8f6mrDegARlzcXyZIKcw+vXIGeCu4pVKA=; b=j2M653BF2U4IWmNZvYBffQ94tMZoQgDYxHCh6l5wxDZ1gFTaZ+JKuaSlf7zgB5aegP wFtLWLs9pYwdTfqqTWPAUe0MIsz2emPerQnQmDGQtb23CTtdUN+K2KgM3cEd9cscXi+F 5CtM03FG5ZQ9o4lyuRlUeISPZQfWN5qmzv2CQ= 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=WdHEqm+kIa8f6mrDegARlzcXyZIKcw+vXIGeCu4pVKA=; b=N9erP6neoTynpfxuYre0JCiEFqfEIfJ3aPFadKs/17+QgC2L1WLjWPYIGxq1kkURiO pp0BgHipu7l3vyzl3vEA+6B5OvQ/gUZ8TVeu5Fqx+QEboU+PNaJxjX+8/NCJzFrWbNkH UKDvUntfj+j4Lis6s5qdsH/jnOD8s5iaCoXOMGrZe3RBR46cj3d9Zajw9V7u1kp0jG9i E/ulJmB0qFNWYuUF7x7iVeUXsMVxJxR5YIGqyWiacsxhifVdf4anhrrQ/A0//n+EHzZI l/HZnfMhVZPK+uv2f/QfHs9+c75+boSeMnBUTF9d6Zh/GHk04eAZj0LAZ5tLdRMxhtIL rY/A== X-Gm-Message-State: AOUpUlE2IQbzOKIU9v9luBCeVYBkZQvo29Tkjy7C+m7oz78piuFvpTUr 0g/KJ4LNbsgDCxB/AuMHqs/Ef7gyc998+A== X-Google-Smtp-Source: AAOMgpcghBrmfORMllg7LXghTLgTNF273m9Kd6AW8dTqRlRDoFj6A8JdBBPn9TUY/0AX0McHgNhc9Q== X-Received: by 2002:a62:f909:: with SMTP id o9-v6mr10514113pfh.141.1532021510200; Thu, 19 Jul 2018 10:31:50 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:d8c0:959b:1398:4e02? ([2001:67c:370:1998:d8c0:959b:1398:4e02]) by smtp.gmail.com with ESMTPSA id 5-v6sm16537152pgc.86.2018.07.19.10.31.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 10:31:49 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <123BC218-B22B-4959-B8D5-C82AF3A09983@sn3rd.com> Date: Thu, 19 Jul 2018 13:31:45 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] WG secretary X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:31:52 -0000 We are please to announce that Katriel has agreed to be the MLS WG = secretary. He=E2=80=99s been working on the MLS GH pages before the WG = was formed. spt= From nobody Thu Jul 19 10:39: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 52E6D131129 for ; Thu, 19 Jul 2018 10:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 8j22NYhON-zb for ; Thu, 19 Jul 2018 10:39:29 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 3CB63130FD6 for ; Thu, 19 Jul 2018 10:39:29 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id w7-v6so5731579uan.9 for ; Thu, 19 Jul 2018 10:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qRM8f1DGKzWG1mKLtm/FqrYa+CxMMxoSb/ntnbgcN1s=; b=Xdya6GP34wcIw7/mjwm1ht7uMTGno4Fwp6nXmL02fKW0KfB0Qtu+zhesg8Nfh6TI8U AGuWfM4UTY2CBpGm8stro+inPPaB+vPOTMmq4CqHnKYCiqrBr72DKNeNgWzoA1fp+Lq1 f54T95milST7W513tf6oy2CVRqRnbDCZxY/wE= 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=qRM8f1DGKzWG1mKLtm/FqrYa+CxMMxoSb/ntnbgcN1s=; b=Scn+Oc/FSJRNU036cfHFKu9ssMiuf1GEi369upai1TzBC+SRk4/JhUkfX/LkgucDPQ 0JR0ofVTjrh8CMuc813N491tcOlTCiKKb6uSEt5RTIcb4l3oewd9RBVzyAtOamiA7fr0 SE+F2eOdv9CD6C7R8bt+vTygezHS4i5LK3U0b+BNXt63QbZO8fr9teOOwa9B5U1sbCqx tkIBocSiDXWrUMVdvE2vHRnkUeoDl+zH6wevUQrrGNtUPuEkavRLfnNRmowfF8E7mXAO Nmd/qyr6P3GTdL8WIK6RFQq7LJuMJcArdUfy3d2lW5hrs1y6M0fqikShda9cPo/s24XL CVgw== X-Gm-Message-State: AOUpUlG7PC99ANFYepmdUDsVViLIFrxs2YxGZN+7buetNF5TUr5CYD2n p8J2cj3/Xkk5wbJC8Halh6kNE2O8LkjpoY5ltjhc0tlr140= X-Google-Smtp-Source: AAOMgpeiWVlKpoRTfHv/5YPGICWS6E7KAvbuKogSmP1PK0AHc12sH/NTh48KYtAkITxQNLclTOW1HS/V7TwZbH2QFBs= X-Received: by 2002:ab0:4b17:: with SMTP id h23-v6mr7410763uaf.84.1532021968066; Thu, 19 Jul 2018 10:39:28 -0700 (PDT) MIME-Version: 1.0 References: <87fu0fxjhi.fsf@fifthhorseman.net> In-Reply-To: <87fu0fxjhi.fsf@fifthhorseman.net> From: Joseph Lorenzo Hall Date: Thu, 19 Jul 2018 13:39:16 -0400 Message-ID: To: Daniel Kahn Gillmor Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 17:39:39 -0000 On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor wrote: > > 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. > > 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) What about "content" and "keying" messages as new names? From nobody Thu Jul 19 15:18:36 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 06AA6130E14 for ; Thu, 19 Jul 2018 15:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] 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 WM9pwTT9QIxS for ; Thu, 19 Jul 2018 15:18:33 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59965130E13 for ; Thu, 19 Jul 2018 15:18:33 -0700 (PDT) Received: from fifthhorseman.net (dhcp-97d4.meeting.ietf.org [31.133.151.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 91733F99A for ; Thu, 19 Jul 2018 18:18:32 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1816320338; Thu, 19 Jul 2018 18:18:30 -0400 (EDT) From: Daniel Kahn Gillmor To: mls@ietf.org Date: Thu, 19 Jul 2018 18:18:29 -0400 Message-ID: <87va9ax422.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [MLS] key update guidance X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:18:35 -0000 At the discussion today, it sounded to me like there was a general agreement that we want to document some sort of guidance for the frequency of key updates. This might end up being more complex than just "update your own key once per day" -- as Jon pointed out, for a large group that could result in a storm of key update messages. One thing we did not discuss is how key update frequency guidance might be either communicated or enforced. (a) should peers in a conversation have a way to communicate explicit expectations about key rotation frequency? Establishing a shared expectation of key rotation can make enforcement more straightforward and comprehensible (both for the user who gets kicked, and for the people remaining in the conversation when a member gets kicked). (b) if there is an expectation of key rotation frequency, does MLS contemplate any enforcement mechanism? if there is enforcement, who should enforce: participants in the group, or the server? My gut feeling is that (a) we should be able to communicate rotation expectations to the group, and (b) participants, not the server, should be responsible for enforcement. I don't have a specific protocol proposal for how to do either step, though. --dkg From nobody Thu Jul 19 15:43: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 4F34F131069 for ; Thu, 19 Jul 2018 15:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=M8pJ7EPN; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ONod7Sk2 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 J-IoVyubhQ4W for ; Thu, 19 Jul 2018 15:43:18 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BF413103C for ; Thu, 19 Jul 2018 15:43:18 -0700 (PDT) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6JMeUmk013796; Thu, 19 Jul 2018 15:43:16 -0700 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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=utLs40cYQdkRgEaAV0xve++l/qo+zcRU30+gu3a9W38=; b=M8pJ7EPN83VHDekSLcyzsGfPQhoB/KbwnqEKFZde2mT9Xb/S9T7SGsOVS2xiTKmiF/pg EZRAW++06PU2rTEJ7NX4+Q4Ogl9aHzSzdwzNGzLXECUL88NGojwJOLolZoJZfyoVd4W7 o1m5faHflTZ+IqU1XUdvBUQjUvOeic0hTEc= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2kb1wsr9j2-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 15:43:16 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 19 Jul 2018 15:43:14 -0700 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=utLs40cYQdkRgEaAV0xve++l/qo+zcRU30+gu3a9W38=; b=ONod7Sk2u4UuuH0KLm28WOUzEjkLuH0mkBgef13A8B3QnLOcUbYtpRket4hhHNczI9T+UXXnLh260ZWhSHDookK2ENLNXTBSHdBoAszOyGrj3OfRO3xX7CQwT0FRdJ7tV5jym3So4CNzu4cojxLO2HYcTDlLoDmSQTeDo8H1l4k= Received: from SN6PR15MB2205.namprd15.prod.outlook.com (52.135.64.145) by SN6PR15MB2383.namprd15.prod.outlook.com (52.135.65.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Thu, 19 Jul 2018 22:43:12 +0000 Received: from SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b]) by SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b%3]) with mapi id 15.20.0973.016; Thu, 19 Jul 2018 22:43:12 +0000 From: Jon Millican To: "jeff.hodges@kingsmountain.com" , "Daniel Kahn Gillmor" CC: "mls@ietf.org" , Raphael Robert , "Suhas Nandakumar" , Nadim Kobeissi Thread-Topic: [MLS] MLS: the WG name should include "group" Thread-Index: AQHTw2NOh1i9TiA6Lk6ldNKeXbExraPfXXAAgAAIAt2AAAYngIAAFj8AgAABzgCAAdXwAIADO1wAgAAjqQCAsuFLgA== Date: Thu, 19 Jul 2018 22:43:12 +0000 Message-ID: <396D9379-92F6-47F1-97D0-B50400E92816@fb.com> References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> In-Reply-To: <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.252.136.137] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR15MB2383; 7:nLYWZTHvGJkH1DpmuekpI9g0rDs12yPlXhWRvWG+IqxkNknsJRjV+ijfoP44Iag2ugzVQsHB8+fybGx9ut8ORrqPdcVv1uJh271bvbAYrur2JHvhXvUArbztoqfucz63V6auEtCW1HBJH45TbUQcRcCtC1xIMDFDBvym9Wksw2XiU10XWQdeQps3EB0QVieF2ljPgAr2+jei8SMP44byIr212lkqnz7GUOVFBWOczydRut96rbOK4Q1vpAOIRwp+; 20:JMZ6nt0mYnSaxQ2nl7aCZyAitQUzPwC0huUpxoC7O2ZRPFvy8+YNPO+Jmx1eaq7oJmWOa8gSe2XxRKKOJT0/77Ln9cX5TDozE/fWXu6cTw5GOeypqqrGzmZkNBrt4MMRu7XVPhZgBwaXxI8veWoKXtc2QMaRC5SnEEWpfnTAM8Y= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4109e348-784d-4893-8ba4-08d5edc90285 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:SN6PR15MB2383; x-ms-traffictypediagnostic: SN6PR15MB2383: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(11241501184)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:SN6PR15MB2383; BCL:0; PCL:0; RULEID:; SRVR:SN6PR15MB2383; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(39860400002)(376002)(346002)(199004)(189003)(7736002)(66066001)(486006)(575784001)(6116002)(6486002)(82746002)(305945005)(2900100001)(4326008)(5250100002)(39060400002)(316002)(2906002)(83716003)(6306002)(2501003)(86362001)(33656002)(68736007)(14454004)(36756003)(478600001)(966005)(25786009)(476003)(6436002)(8676002)(186003)(53936002)(93886005)(26005)(8936002)(81166006)(97736004)(105586002)(81156014)(102836004)(110136005)(6246003)(229853002)(5660300001)(2616005)(11346002)(446003)(3846002)(76176011)(54906003)(256004)(6512007)(99286004)(6506007)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR15MB2383; H:SN6PR15MB2205.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5QiQ4DNjRHJXOaCauOK5IghtsYah3l+dgfhWB8oig5NofvZLxShlVnoINdEXY4mHtl1rRMx7is+rzOtPhKQShPtA8AHd4+I7ax2f0b8sD3HhnDrfczpSognttsTixHCw+hxomWK++Ejrv3lP7uikS5ymYky1UNZeESc6HFc0H8P0FuNftLEMLcntq9EcomMXTNe8impPJ/ezrlajtQ8Xtf7sbT1Z6rJrk/P04tpm6kt8ev3LP4AwvYj7untJHnxoSmLW1K9JEkoVET2hZai3VTUtQcJIOabJkfd7Wm+Cbel+R/zxrODINj0dX2I14vYaq8nu9xW+1dFYOMVrdhWSAbE5VYPByGtxKNh6jUXNQUg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4109e348-784d-4893-8ba4-08d5edc90285 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 22:43:12.8059 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2383 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:43:22 -0000 VGhpcyBkaXNjdXNzaW9uIGNhbWUgdXAgYWdhaW4gYXQgdGhlIGhhY2thdGhvbiwgYW5kIEkgdGhp bmsgdGhlcmUgd2FzIGEgZmFpciBiaXQgb2Ygc3ltcGF0aHkgZm9yIHRoZSBpZGVhIG9mIGF0IGxl YXN0IGNoYW5naW5nIHRoZSBwcm90b2NvbCBuYW1lIHRvIE1TRzsgZm9yIHRoZSByZWFzb25zIGRl c2NyaWJlZCBpbiB0aGlzIHRocmVhZC4NCg0KUGVyc29uYWxseSBJJ2QgYmUga2VlbiB0byBoYXZl IHNvbWV0aGluZyBzbGlnaHRseSBtb3JlIHVuaXF1ZWx5IEdvb2dsZWFibGUgdGhhbiBNU0csIGJ1 dCBJIGRvbid0IHRoaW5rIHRoYXQgTUxTIGlzIGFueSBiZXR0ZXIgaW4gdGhpcyByZWdhcmQuDQoN Cu+7v09uIDI3LzAzLzIwMTgsIDE5OjAzLCAiTUxTIG9uIGJlaGFsZiBvZiBqZWZmLmhvZGdlc0Br aW5nc21vdW50YWluLmNvbSIgPG1scy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqZWZm LmhvZGdlc0BraW5nc21vdW50YWluLmNvbT4gd3JvdGU6DQoNCiAgICArMQ0KICAgIA0KICAgIFF1 b3RpbmcgRGFuaWVsIEthaG4gR2lsbG1vciA8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PjoNCiAgICA+ IE9uIFN1biAyMDE4LTAzLTI1IDIxOjMzOjQyICswMjAwLCBOYWRpbSBLb2JlaXNzaSB3cm90ZToN CiAgICA+PiBJIGRvIG5vdCBiZWxpZXZlIHRoZSBuYW1lIHNob3VsZCBiZSBjaGFuZ2VkOg0KICAg ID4+DQogICAgPj4gMS4gTUxTIGlzIGEgcHJvdG9jb2wgdGhhdCBpcyBlcXVhbGx5IHN1aXRlZCBm b3IgcGFpcndpc2UgbWVzc2FnaW5nICANCiAgICA+PiBhcyBpdCBpcyBmb3IgZ3JvdXAgbWVzc2Fn aW5nDQogICAgPj4gMi4gVGhlIE1MUyBuYW1lIGlzIGVsZWdhbnQgYW5kIG1pcnJvcnMgVExTLg0K ICAgID4NCiAgICA+ICJNaXJyb3JpbmcgVExTIiBpcyBleGFjdGx5IHdoYXQgaSdtIGFmcmFpZCBv Zi4gIFRoaXMgaXMgYSByYWRpY2FsbHkNCiAgICA+IGRpZmZlcmVudCBwcm90b2NvbCwgcGVyZm9y bWluZyBkZW1vbnN0cmFibHkgZGlmZmVyZW50IHdvcmsgYXQgYQ0KICAgID4gZGlmZmVyZW50IHBv c2l0aW9uIHdpdGhpbiB0aGUgc3RhY2ssIHdpdGggYSBkaWZmZXJlbnQgdmlldyBvbiB3aGF0DQog ICAgPiBpbnRlcm9wZXJhYmlsaXR5IGV2ZW4gbWVhbnMuDQogICAgPg0KICAgID4gTGV0J3MgbWFr ZSBpdCB2ZXJ5IGNsZWFyIHRoYXQgdGhpcyAqaXMgbm90KiBUTFMsIGFuZCB0aGF0IGl0IGlzIG5v dCBhDQogICAgPiBzdWJzdGl0dXRlIGZvciBUTFMuDQogICAgPg0KICAgID4gVGhlIHByb3RvY29s IGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnRzIGlzICpub3QqIGVxdWFsbHktc3VpdGVkIGZvcg0K ICAgID4gcGFpcndpc2UgbWVzc2FnaW5nIC0tIGl0IGhhcyBhIG51bWJlciBvZiBzdWJ0bGUgZmVh dHVyZXMgdGhhdCBhcmUNCiAgICA+IGluY2x1ZGVkIHNvbGVseSBiZWNhdXNlIGl0IGlzIGludGVu ZGVkIHRvIGhhbmRsZSBncm91cCBtZXNzYWdpbmcuICBBcw0KICAgID4gb3RoZXIgcGVvcGxlIGhh dmUgd3JpdHRlbiB1cHRocmVhZCwgdGhlIHByb3RvY29sIHRoaXMgbmFzY2VudCBXRyBhaW1zIHRv DQogICAgPiBkZXNjcmliZSB3aWxsIGhhbmRsZSBwYWlyd2lzZSBtZXNzYWdpbmcgYXMgYSBzcGVj aWFsIGNhc2Ugb2YgZ3JvdXANCiAgICA+IG1lc3NhZ2luZy4gIEl0IGlzIG5vdCBkZXNpZ25lZCBp bnRlbnRpb25hbGx5IGZvciBwYWlyd2lzZSBtZXNzYWdpbmcgYW5kDQogICAgPiBpZiBpdCB3ZXJl LCBpdCB3b3VsZCBoYXZlIGEgZGlmZmVyZW50IGRlc2lnbi4NCiAgICA+DQogICAgPiAgICAgICAg ICAgLS1ka2cNCiAgICANCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIE1MUyBtYWlsaW5nIGxpc3QNCiAgICBNTFNAaWV0 Zi5vcmcNCiAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZkPUR3SUNBZyZjPTVWRDBS VHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09cmZoU3VLOHZwY3BG TGNWUThPTWVaTHdwcG04Tzl1VmIxWFoyN3dYbGY2MCZzPUJRRzMtcjdxQ0JRbGhyclBHVk5WSmo2 aGVTWmNzTml2UjhqZkUxWm1xelkmZT0NCiAgICANCg0K From nobody Thu Jul 19 15:51:07 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BACC130F16 for ; Thu, 19 Jul 2018 15:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 5t_GIWrQ0lmW for ; Thu, 19 Jul 2018 15:50:52 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 8E857130E5B for ; Thu, 19 Jul 2018 15:50:52 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id o82-v6so3369343vko.8 for ; Thu, 19 Jul 2018 15:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=treqjlSAzCT8IGVI1CPWTsoqRIDG6eXU3oM5Umecf6g=; b=TBevkspFGLvvGKfJqG1Y2bftVAKdhiNXNhp1HGsmQy/+ddOZ6hpl7UdmnZS6qDzeww K1o71bzy8+OEq1wWFPsWvuKgWjyQxILensuks8nKkM3x9rp2S4aM/CeLkoC2YAMQMVEI /z7MVtHpjYQCEddSMrn8OI0MERxGTiow67v7Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=treqjlSAzCT8IGVI1CPWTsoqRIDG6eXU3oM5Umecf6g=; b=F9aHtXc45GsdsGBotRFgL64wCcVBKJd9OZ3iOJ9l/DYQl6jDTavx6jgzbbMg0+oVrD virPHjMVKwsPho5e1OeEupFRVHk6it+FVIdmZ/Z5uCIYXwzasrgBzgwakhayH0TSEjPS XRUFImKRenhFT0gFCpmhEW+PladWC4Fjd10ensNPOuLI77ALZM4RnREBRCYrRtr3u3yk M62u3i8ilWVrHE0v/+nuBByAE2JeatpJZl4JPia9veYOOx7U3ob8lD50+kK5xNUWxh9g ODwnXp9kTExKbmmOcAIlSyNUuO7MNHzQ3TKgjqjUl/Q5gjIzWnkmtDRDcz46Ehk5J6gC 9+SQ== X-Gm-Message-State: AOUpUlFy/uNu1KbUVQYupioA7xtc4p0pxQR9yh+G7UoxCB/5WDK+449u mOCwZcSkEIqa2WumKmyLY9FiFUuAeJEgapTQskH++sm5RWU= X-Google-Smtp-Source: AAOMgped8P+0orLWIQkrN3PEtG0WAS134cViKTvytT7++nZGAkocyTqaY35HBF2PIiQDERj3fF6b5Kl7C3IjbT6zInw= X-Received: by 2002:a1f:88ce:: with SMTP id k197-v6mr7093610vkd.85.1532040651201; Thu, 19 Jul 2018 15:50:51 -0700 (PDT) MIME-Version: 1.0 References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> <396D9379-92F6-47F1-97D0-B50400E92816@fb.com> In-Reply-To: <396D9379-92F6-47F1-97D0-B50400E92816@fb.com> From: Joseph Lorenzo Hall Date: Thu, 19 Jul 2018 18:50:39 -0400 Message-ID: To: jmillican@fb.com Cc: "=JeffH" , Daniel Kahn Gillmor , mls@ietf.org, raphael@wire.com, suhasietf@gmail.com, nadim@symbolic.software Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:51:04 -0000 +1 On Thu, Jul 19, 2018 at 6:43 PM Jon Millican wrote: > > This discussion came up again at the hackathon, and I think there was a f= air bit of sympathy for the idea of at least changing the protocol name to = MSG; for the reasons described in this thread. > > Personally I'd be keen to have something slightly more uniquely Googleabl= e than MSG, but I don't think that MLS is any better in this regard. > > =EF=BB=BFOn 27/03/2018, 19:03, "MLS on behalf of jeff.hodges@kingsmountai= n.com" wr= ote: > > +1 > > Quoting Daniel Kahn Gillmor : > > On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote: > >> I do not believe the name should be changed: > >> > >> 1. MLS is a protocol that is equally suited for pairwise messaging > >> as it is for group messaging > >> 2. The MLS name is elegant and mirrors TLS. > > > > "Mirroring TLS" is exactly what i'm afraid of. This is a radically > > different protocol, performing demonstrably different work at a > > different position within the stack, with a different view on what > > interoperability even means. > > > > Let's make it very clear that this *is not* TLS, and that it is not= a > > substitute for TLS. > > > > The protocol described in the documents is *not* equally-suited for > > pairwise messaging -- it has a number of subtle features that are > > included solely because it is intended to handle group messaging. = As > > other people have written upthread, the protocol this nascent WG ai= ms to > > describe will handle pairwise messaging as a special case of group > > messaging. It is not designed intentionally for pairwise messaging= and > > if it were, it would have a different design. > > > > --dkg > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_= bvEqMa84Q&m=3DrfhSuK8vpcpFLcVQ8OMeZLwppm8O9uVb1XZ27wXlf60&s=3DBQG3-r7qCBQlh= rrPGVNVJj6heSZcsNivR8jfE1ZmqzY&e=3D > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Thu Jul 19 16:08: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 1853E130E59 for ; Thu, 19 Jul 2018 16:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BZh5XtVcan1 for ; Thu, 19 Jul 2018 16:08:32 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F2A130DD2 for ; Thu, 19 Jul 2018 16:08:32 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id l10-v6so18076394oii.0 for ; Thu, 19 Jul 2018 16:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=jI48/ZqMhTJIi/3yAPpKLD7HgU7cHMjiTvsZHWhKpPs=; b=KtaBYzHPEtfe867YtTh1TI0iRDCMpgxZDnBGArI5vno2KgnoDLNHCkrYiAhqksl/oK ORi5Jqr/y2xOjTjKpo79M9mqRzPax82wB/vb5wq/13Pot/Ow3IVm3C9i1EhnWryuLCLB q8yIVwgPBqF/WcjUnkHNtL/Bwfc4LfbiCkyd+8M8mehCeVRxgksxwJgNfvhTeIxusoq9 XZ8zMhMyRx/+olvDWYNdEZ+bhvG7Knuf2eIAgctRU9EHA4s79lqkFVR0UdZ7tOYEp18Z 6DHsA+D7Yrp2l2ISZjV2GTUWs/MItZ9VStoEflFiZCzC9NQhe1NR+WoezVAhYS6Re0hy e8Lw== 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=jI48/ZqMhTJIi/3yAPpKLD7HgU7cHMjiTvsZHWhKpPs=; b=aVo8UWpyX5lnShA00c6vPrtudGF9MNzPvL+8L5VA6F1bAoz+j+5yFcBtkgs41AS8/c CVNzIVIo+5kg5dTDC96/EvbJO7HTDKM3RmrFjL/ptDv2Dg59iQcCnoABrKaZo+robDRz p+Bm60jb9kXOwZjPaY+Ol8Pl5cOseOT6oj+vNmgcoqaQORDi6RQD/aS0DEy/qhJrHYGi Sw5k6Za5cv04NSL66mT8MxYpDgq8x72k5sRWWO2VttEGAObprBBmcA3smw879nIg3/G3 SHyOmJ/ilRHO+y/YVEWZ3MPjo+e1Ab9rw3QyG2Ay5aiGPoMMZrcBLHwt/4sanqRG2j6i ys3g== X-Gm-Message-State: AOUpUlHehMXqXujfe9D41kacRFw1/IvfKEM3Ar8Rus4ylIpR0ZGt36er LAHQJ//uD8gEttxUazreOJypss++hDhpUu9wsiHglmuus69K+Z1W X-Google-Smtp-Source: AAOMgpcnAS3b9lVi+rjaPr+zLbqw0wHISU8bIjmLHtrUpnA6Z9c3hA6gfrhu0gXAmrlRQxdkw7wadM04YVM4ehCfUQ4= X-Received: by 2002:aca:f383:: with SMTP id r125-v6mr38084oih.6.1532041711723; Thu, 19 Jul 2018 16:08:31 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 19 Jul 2018 19:08:20 -0400 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000000237d4057162426f" Archived-At: Subject: [MLS] Test framework X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:08:35 -0000 --0000000000000237d4057162426f Content-Type: text/plain; charset="UTF-8" In our overrun A.O.B. section today we had a topic, "interop test framework". Since we didn't get to it in the meeting, here are some thoughts in writing: The idea of interop testing is a little challenging for MLS, since we're only defining a part of the system -- we don't have a specified transport, for instance. Instead, we just have message formats. Given that focus, I'd propose we agree on a standard "API" for MLS implementation to implement, focused mainly on producing and consuming messages in the standard formats. This would allow us to build some standard tooling that can pull messages from one implementation and feed it into another implementation. I don't think this needs to be an I-D / RFC, but it should probably be something we can all collaborate on. As a start, I've dropped an initial API into GitHub gist (we can make a repo laster), based on the common API implemented by my JS ART and TreeKEM code: https://gist.github.com/bifurcation/1a0765bb589383e42b473b7b21b2928a Folks who are considering implementing, does this look roughly sensible? Are there things that are missing? It probably needs an encrypt/decrypt for message protection, and some more accessors. --Richard --0000000000000237d4057162426f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In our overrun A.O.B. section today we had a topic, &= quot;interop test framework".=C2=A0 Since we didn't get to it in t= he meeting, here are some thoughts in writing:

The= idea of interop testing is a little challenging for MLS, since we're o= nly defining a part of the system -- we don't have a specified transpor= t, for instance.=C2=A0 Instead, we just have message formats.=C2=A0 Given t= hat focus, I'd propose we agree on a standard "API" for MLS i= mplementation to implement, focused mainly on producing and consuming messa= ges in the standard formats.=C2=A0 This would allow us to build some standa= rd tooling that can pull messages from one implementation and feed it into = another implementation.=C2=A0=C2=A0

I don't th= ink this needs to be an I-D / RFC, but it should probably be something we c= an all collaborate on.=C2=A0 As a start, I've dropped an initial API in= to GitHub gist (we can make a repo laster), based on the common API impleme= nted by my JS ART and TreeKEM code:

<= div>
Folks who are considering implementing, does this look r= oughly sensible?=C2=A0 Are there things that are missing?=C2=A0 It probably= needs an encrypt/decrypt for message protection, and some more accessors.<= br>

--Richard
--0000000000000237d4057162426f-- From nobody Thu Jul 19 16:11: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 AB06B130E46 for ; Thu, 19 Jul 2018 16:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVidgt7ucumr for ; Thu, 19 Jul 2018 16:11:18 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F55130E03 for ; Thu, 19 Jul 2018 16:11:18 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id k81-v6so18065496oib.4 for ; Thu, 19 Jul 2018 16:11:18 -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=waIKumSMcWTc3ez4B+PDb4FpiCBjrRyenO+78NKtnqE=; b=zvB2UBtwETdLl+THBrERA7XAHdfkCWo4eNw07dcD7wzgroUDjkVSpXcYSDfAKKhC2J lSWXP37duxXe39XkYbd1lS0OZuE7ZUTuJ+efVu0JIRVw7ojjYBuDwjFwFhFKbwdgNfYk saBYvxAQfSGSGxlZfixcvspuOgbPfndtVnCzg2GUco2Ai4y+xVEtZ7R86CplelTVw87g EEVPwRDczhcPgKgYcpH0FO4gLZaIbRGZabfolPOz3xZCGugAAXCJoKeg23uAlN1VmVjp MGtt/Uoudj2ULy/2ZQr9ln1yD5KCszWnOmP1m+bt+Mcf1JUuiZzJw2y1jfuSI8xI0fTh j4ZA== 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=waIKumSMcWTc3ez4B+PDb4FpiCBjrRyenO+78NKtnqE=; b=tEIxmH3vstIrkcpaM5V/H+owOyTLPGlqLakyClSrFauNLvAV6zl1d+/E8M4tPqe2Uq DjJl07TaHD66/Le+AyZfN4fel9oLE/PHPmTvEuaj1fMlGfTuMd6ztiArOOJzJvRLY6Rr rTwkEMrXmnVMGcIKE6bydyI9JDUbLEZ8IhhvJ586Lo9xyV9pKIcuOhyYZKvl9YvT9Ch/ sUV+1xJsbXvDuIAp2TPGGF/17a+xBORs5BuV393Vt/3zdn/2cg+NHcsclsS0GM28z1SF bQR7zWjE+ol8HmdsY3kwUO70xH/QJfPi4yZEEjhJMT53YTSk9wvgl/4B1shQeV2Pc52V ILPQ== X-Gm-Message-State: AOUpUlE8n0W8v2DNqDzvttGrhdjAree3Iug+kykXljIkOsdAb8MTVwK+ 0vX0Q9Z1C9AtyNBE0AcXartfWYokhYoUWIwavkGoP1cyr65uBA== X-Google-Smtp-Source: AAOMgpepq8NX0ifN+8mST65g3QFqge7GxNkUh9VuRoBtX/WmsBirBHr9pbj+as/BeFWNYiqg4pOA2qG2zxNTAAXCAs8= X-Received: by 2002:aca:4994:: with SMTP id w142-v6mr38493oia.114.1532041878079; Thu, 19 Jul 2018 16:11:18 -0700 (PDT) MIME-Version: 1.0 References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> <396D9379-92F6-47F1-97D0-B50400E92816@fb.com> In-Reply-To: From: Richard Barnes Date: Thu, 19 Jul 2018 19:11:06 -0400 Message-ID: To: Joseph Lorenzo Hall Cc: Jon Millican , Nadim Kobeissi , Suhas Nandakumar , Raphael Robert , "=JeffH" , mls@ietf.org, Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary="000000000000eca1c50571624b4b" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:11:22 -0000 --000000000000eca1c50571624b4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't have strong feelings here. I'm not wedded to MLS, but I don't want to move from that to something lame :) MLS has the benefit of getting some "trustiness" from the resonance with TLS, and we already have the top Google hits for "MLS protocol". I'm not sure MSG is enough better to motivate a change. On Thu, Jul 19, 2018 at 6:51 PM Joseph Lorenzo Hall wrote: > +1 > On Thu, Jul 19, 2018 at 6:43 PM Jon Millican wrote: > > > > This discussion came up again at the hackathon, and I think there was a > fair bit of sympathy for the idea of at least changing the protocol name = to > MSG; for the reasons described in this thread. > > > > Personally I'd be keen to have something slightly more uniquely > Googleable than MSG, but I don't think that MLS is any better in this > regard. > > > > =EF=BB=BFOn 27/03/2018, 19:03, "MLS on behalf of jeff.hodges@kingsmount= ain.com" > wrote: > > > > +1 > > > > Quoting Daniel Kahn Gillmor : > > > On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote: > > >> I do not believe the name should be changed: > > >> > > >> 1. MLS is a protocol that is equally suited for pairwise messagi= ng > > >> as it is for group messaging > > >> 2. The MLS name is elegant and mirrors TLS. > > > > > > "Mirroring TLS" is exactly what i'm afraid of. This is a radical= ly > > > different protocol, performing demonstrably different work at a > > > different position within the stack, with a different view on wha= t > > > interoperability even means. > > > > > > Let's make it very clear that this *is not* TLS, and that it is > not a > > > substitute for TLS. > > > > > > The protocol described in the documents is *not* equally-suited f= or > > > pairwise messaging -- it has a number of subtle features that are > > > included solely because it is intended to handle group messaging. > As > > > other people have written upthread, the protocol this nascent WG > aims to > > > describe will handle pairwise messaging as a special case of grou= p > > > messaging. It is not designed intentionally for pairwise > messaging and > > > if it were, it would have a different design. > > > > > > --dkg > > > > > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvEq= Ma84Q&m=3DrfhSuK8vpcpFLcVQ8OMeZLwppm8O9uVb1XZ27wXlf60&s=3DBQG3-r7qCBQlhrrPG= VNVJj6heSZcsNivR8jfE1ZmqzY&e=3D > > > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > > > -- > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology [https://www.cdt.or= g > ] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000eca1c50571624b4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't have strong feelings here.=C2=A0 I'm not w= edded to MLS, but I don't want to move from that to something lame :)= =C2=A0 MLS has the benefit of getting some "trustiness" from the = resonance with TLS, and we already have the top Google hits for "MLS p= rotocol".=C2=A0 I'm not sure MSG is enough better to motivate a ch= ange.

On Thu, Jul = 19, 2018 at 6:51 PM Joseph Lorenzo Hall <= joe@cdt.org> wrote:
+1
On Thu, Jul 19, 2018 at 6:43 PM Jon Millican <jmillican@fb.com> wrote:
>
> This discussion came up again at the hackathon, and I think there was = a fair bit of sympathy for the idea of at least changing the protocol name = to MSG; for the reasons described in this thread.
>
> Personally I'd be keen to have something slightly more uniquely Go= ogleable than MSG, but I don't think that MLS is any better in this reg= ard.
>
> =EF=BB=BFOn 27/03/2018, 19:03, "MLS on behalf of jeff.hodges@kingsmountai= n.com" <mls-bounces@ietf.org on behalf of jeff.hodges@kingsmountain.com> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0+1
>
>=C2=A0 =C2=A0 =C2=A0Quoting Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
>=C2=A0 =C2=A0 =C2=A0> On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeis= si wrote:
>=C2=A0 =C2=A0 =C2=A0>> I do not believe the name should be change= d:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> 1. MLS is a protocol that is equally suite= d for pairwise messaging
>=C2=A0 =C2=A0 =C2=A0>> as it is for group messaging
>=C2=A0 =C2=A0 =C2=A0>> 2. The MLS name is elegant and mirrors TLS= .
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> "Mirroring TLS" is exactly what i= 9;m afraid of.=C2=A0 This is a radically
>=C2=A0 =C2=A0 =C2=A0> different protocol, performing demonstrably di= fferent work at a
>=C2=A0 =C2=A0 =C2=A0> different position within the stack, with a di= fferent view on what
>=C2=A0 =C2=A0 =C2=A0> interoperability even means.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Let's make it very clear that this *is not= * TLS, and that it is not a
>=C2=A0 =C2=A0 =C2=A0> substitute for TLS.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The protocol described in the documents is *no= t* equally-suited for
>=C2=A0 =C2=A0 =C2=A0> pairwise messaging -- it has a number of subtl= e features that are
>=C2=A0 =C2=A0 =C2=A0> included solely because it is intended to hand= le group messaging.=C2=A0 As
>=C2=A0 =C2=A0 =C2=A0> other people have written upthread, the protoc= ol this nascent WG aims to
>=C2=A0 =C2=A0 =C2=A0> describe will handle pairwise messaging as a s= pecial case of group
>=C2=A0 =C2=A0 =C2=A0> messaging.=C2=A0 It is not designed intentiona= lly for pairwise messaging and
>=C2=A0 =C2=A0 =C2=A0> if it were, it would have a different design.<= br> >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg<= br> >
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0MLS mailing list
>=C2=A0 =C2=A0 =C2=A0M= LS@ietf.org
>=C2=A0 =C2=A0 =C2=A0https://urldefense.proo= fpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_mls&d=3DD= wICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvEqMa84Q&m= =3DrfhSuK8vpcpFLcVQ8OMeZLwppm8O9uVb1XZ27wXlf60&s=3DBQG3-r7qCBQlhrrPGVNV= Jj6heSZcsNivR8jfE1ZmqzY&e=3D
>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls



--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202= .407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000eca1c50571624b4b-- From nobody Thu Jul 19 16:15:56 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 9F5A9130F96 for ; Thu, 19 Jul 2018 16:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 mySUSh6D3ZRj for ; Thu, 19 Jul 2018 16:15:44 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A67130EA5 for ; Thu, 19 Jul 2018 16:15:44 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id w16-v6so12259863ita.0 for ; Thu, 19 Jul 2018 16:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=T/wPqSFt4too9Qke1O2ZYV9xh5tt4RQgUsRHsRew36c=; b=GBhETyqA4a3oGyUhZWqdNmXuVG96VzwOwY1BtwucgqVpFArw7upg5xjuu4oFdnDt/8 BfLF2vsjEEBrHXcKJSp24K0CaIqquscSYvU2Cy58c4d5h9RC1fEgegXDEcjrEvfY+Iv2 miBHPPwiPgWK2oHJD7BWFHtcEKgxdwf6IQZdU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=T/wPqSFt4too9Qke1O2ZYV9xh5tt4RQgUsRHsRew36c=; b=sMrAym7Mbk9BiH8GuRohk7YG8ZcDbcbvnZgA1FOHk6LNxCIuqEqEMGFt/0czdYq7vs /riMUPOzL+6IBEeCXF1GRTrRzE6QmEYao2ZntqVE65eA+ZJyuv3kryj+R2WdKOa/CLtQ jUs6QCmvEwrcpyjLv5MV2lToQ4U14nExir9gix2P8uVB5Q5kNraBE6xnmuCbStDqrWpt y3JUid2glnzGBjXRaPLC/o/RlSR+6SQ6z5Wur/XP/bk2jOioeKtNRLHPs10qEzB09Ilc RcAj5KlNtpu0xwgtym4IA2t6KzhpQ9FPwMuWbLD7/3vzXRqkzrZa9WIs2KX085yxhng1 7b+Q== X-Gm-Message-State: AOUpUlEoOktaC+Vd+bmblFBLAxuwAWKRbEhUQdGu5T8PfPb4vH+gV3fm eOoH+ENIajafmzxK2gX4FDqB4viAgzk= X-Google-Smtp-Source: AAOMgpfyHXFmXzBPZLMlEuvkVGVqTlwu099aejRlwAe+ZLuwEqDUOjeLzIivfWfq1za1NicEM1KR4A== X-Received: by 2002:a24:c2c2:: with SMTP id i185-v6mr62102itg.76.1532042144011; Thu, 19 Jul 2018 16:15:44 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id x94-v6sm115221ita.18.2018.07.19.16.15.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 16:15:43 -0700 (PDT) To: mls@ietf.org References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> <396D9379-92F6-47F1-97D0-B50400E92816@fb.com> 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: <1fda2fa0-026e-2897-dc95-4441ffd3826b@mozilla.com> Date: Thu, 19 Jul 2018 17:15:40 -0600 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0jcf1XUyLpe7JiDUk12uY5XRnzvSx37zl" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:15:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0jcf1XUyLpe7JiDUk12uY5XRnzvSx37zl Content-Type: multipart/mixed; boundary="ikR3LjR69YOjh9aQTc7uXVw0RizcW4i3v"; protected-headers="v1" From: Peter Saint-Andre To: mls@ietf.org Message-ID: <1fda2fa0-026e-2897-dc95-4441ffd3826b@mozilla.com> Subject: Re: [MLS] MLS: the WG name should include "group" References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> <396D9379-92F6-47F1-97D0-B50400E92816@fb.com> In-Reply-To: --ikR3LjR69YOjh9aQTc7uXVw0RizcW4i3v Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Many people have allergic reactions to MSG. ;-) On 7/19/18 5:11 PM, Richard Barnes wrote: > I don't have strong feelings here.=C2=A0 I'm not wedded to MLS, but I d= on't > want to move from that to something lame :)=C2=A0 MLS has the benefit o= f > getting some "trustiness" from the resonance with TLS, and we already > have the top Google hits for "MLS protocol".=C2=A0 I'm not sure MSG is = enough > better to motivate a change. >=20 > On Thu, Jul 19, 2018 at 6:51 PM Joseph Lorenzo Hall > wrote: >=20 > +1 > On Thu, Jul 19, 2018 at 6:43 PM Jon Millican > wrote: > > > > This discussion came up again at the hackathon, and I think there= > was a fair bit of sympathy for the idea of at least changing the > protocol name to MSG; for the reasons described in this thread. > > > > Personally I'd be keen to have something slightly more uniquely > Googleable than MSG, but I don't think that MLS is any better in > this regard. > > > > =EF=BB=BFOn 27/03/2018, 19:03, "MLS on behalf of > jeff.hodges@kingsmountain.com > " on behalf of > jeff.hodges@kingsmountain.com > > wrote: > > > >=C2=A0 =C2=A0 =C2=A0+1 > > > >=C2=A0 =C2=A0 =C2=A0Quoting Daniel Kahn Gillmor >: > >=C2=A0 =C2=A0 =C2=A0> On Sun 2018-03-25 21:33:42 +0200, Nadim Kobe= issi wrote: > >=C2=A0 =C2=A0 =C2=A0>> I do not believe the name should be changed= : > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>> 1. MLS is a protocol that is equally suited= for pairwise > messaging > >=C2=A0 =C2=A0 =C2=A0>> as it is for group messaging > >=C2=A0 =C2=A0 =C2=A0>> 2. The MLS name is elegant and mirrors TLS.= =2E > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> "Mirroring TLS" is exactly what i'm afraid o= f.=C2=A0 This is a > radically > >=C2=A0 =C2=A0 =C2=A0> different protocol, performing demonstrably = different work at a > >=C2=A0 =C2=A0 =C2=A0> different position within the stack, with a = different view > on what > >=C2=A0 =C2=A0 =C2=A0> interoperability even means. > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> Let's make it very clear that this *is not* = TLS, and that it > is not a > >=C2=A0 =C2=A0 =C2=A0> substitute for TLS. > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> The protocol described in the documents is *= not* > equally-suited for > >=C2=A0 =C2=A0 =C2=A0> pairwise messaging -- it has a number of sub= tle features > that are > >=C2=A0 =C2=A0 =C2=A0> included solely because it is intended to ha= ndle group > messaging.=C2=A0 As > >=C2=A0 =C2=A0 =C2=A0> other people have written upthread, the prot= ocol this > nascent WG aims to > >=C2=A0 =C2=A0 =C2=A0> describe will handle pairwise messaging as a= special case of > group > >=C2=A0 =C2=A0 =C2=A0> messaging.=C2=A0 It is not designed intentio= nally for pairwise > messaging and > >=C2=A0 =C2=A0 =C2=A0> if it were, it would have a different design= =2E > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--dk= g > > > > > > > >=C2=A0 =C2=A0 =C2=A0______________________________________________= _ > >=C2=A0 =C2=A0 =C2=A0MLS mailing list > >=C2=A0 =C2=A0 =C2=A0MLS@ietf.org > >=C2=A0 =C2=A0 > =C2=A0https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ie= tf.org_mailman_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0C= VEJydBVUX_bvEqMa84Q&m=3DrfhSuK8vpcpFLcVQ8OMeZLwppm8O9uVb1XZ27wXlf60&s=3DB= QG3-r7qCBQlhrrPGVNVJj6heSZcsNivR8jfE1ZmqzY&e=3D > > > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls >=20 >=20 >=20 > --=20 > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology > [https://www.cdt.org] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org , p: 202..407.8825, pgp: > https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A87= 1 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 --ikR3LjR69YOjh9aQTc7uXVw0RizcW4i3v-- --0jcf1XUyLpe7JiDUk12uY5XRnzvSx37zl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltRG5wACgkQZWGMGH9o FKmwVhAAkYVjdCmZ+tesC1qAPEMvUT5eUTS6oFSeHRubibZz9L3/9kUqsquRZrTL /H+156EWgICOdEzL+xkrK5OajCFsAkC8sdP06iVAjHV/ZABSA2oioDfx71oA1f6J lugnyNyx9dGSfnTzv4E1wSIVYgYAFIU7hGln7e0c/GEhKVHR3HKaJtzFePyxwy/8 DxF4oBkM2sw5cK9VLouqfGi88d7nyODnSxnPoKJ1mi80tu4lS4Sre0V1q50DhhH8 tQEAvbI/+UA7JdcQcDYv5Qs+wyLevrL9OEkrxcvyT9Xyd91/XUFfl4Y70UcCQ0Xh DELaVzMXWNnW2tSesS2FOZojStZjFP1yQyZPKb88Vsc3cTYEVNP0qii5QIqpWj/2 MP0gb2rDuFkh3RWUKyxsH3KVeKLMFZi8ZX1og0xAZx4pG1mIgTphSnjDTJwwEEML 90w1vmrAGFcfrhewaO+34NyGiOBQOucT4sl3Bko7tuZqNhOar9mI45LQB0AhCr23 tgckbVpEsZG5oatcZgU1CG2sHQUSQ8POUbYCyQupyHQsUVeQB7lfsBQLDy0S7ehC ztBc4fSjUBFWAHt6kzo6t4sxgXcT1LJk0ipLD3lheWXNDO8bwG+LuPEKJL/LbFBB OuyF9SSuE7YS8TKbDjJPlhRIffeM1ROcQV+tngEZUBz0t0tSsAQ= =dkpw -----END PGP SIGNATURE----- --0jcf1XUyLpe7JiDUk12uY5XRnzvSx37zl-- From nobody Thu Jul 19 17:22:11 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7F4130E62 for ; Thu, 19 Jul 2018 17:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1J9gkVdTxFx for ; Thu, 19 Jul 2018 17:22:02 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 550EB130E2C for ; Thu, 19 Jul 2018 17:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8538662143; Thu, 19 Jul 2018 20:21:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LVO5TUWFiPHd; Thu, 19 Jul 2018 20:21:48 -0400 (EDT) Received: from lx121e.htt-consult.com (dhcp-960a.meeting.ietf.org [31.133.150.10]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 251B562135; Thu, 19 Jul 2018 20:21:46 -0400 (EDT) To: Richard Barnes , Joseph Lorenzo Hall Cc: Jon Millican , Nadim Kobeissi , Suhas Nandakumar , Raphael Robert , =JeffH , mls@ietf.org, Daniel Kahn Gillmor References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> <396D9379-92F6-47F1-97D0-B50400E92816@fb.com> From: Robert Moskowitz Message-ID: Date: Thu, 19 Jul 2018 20:21:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6FEE247C832832146F18E651" Content-Language: en-US Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 00:22:09 -0000 This is a multi-part message in MIME format. --------------6FEE247C832832146F18E651 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit If I would make a change it would be to MLK or MLSK. This effort is (per the charter) about installing and managing Message Level **KEYING** Message Level Security includes how the messages are protected (securely enveloped) over the communication channel.  That is out of scope of this effort.  (see my SSE draft if you want a general session level secure envelope). And is it just message level or multicast message level (MMLK).  :) Bob On 07/19/2018 07:11 PM, Richard Barnes wrote: > I don't have strong feelings here.  I'm not wedded to MLS, but I don't > want to move from that to something lame :) MLS has the benefit of > getting some "trustiness" from the resonance with TLS, and we already > have the top Google hits for "MLS protocol".  I'm not sure MSG is > enough better to motivate a change. > > On Thu, Jul 19, 2018 at 6:51 PM Joseph Lorenzo Hall > wrote: > > +1 > On Thu, Jul 19, 2018 at 6:43 PM Jon Millican > wrote: > > > > This discussion came up again at the hackathon, and I think > there was a fair bit of sympathy for the idea of at least changing > the protocol name to MSG; for the reasons described in this thread. > > > > Personally I'd be keen to have something slightly more uniquely > Googleable than MSG, but I don't think that MLS is any better in > this regard. > > > > On 27/03/2018, 19:03, "MLS on behalf of > jeff.hodges@kingsmountain.com > " on behalf of > jeff.hodges@kingsmountain.com > > wrote: > > > >     +1 > > > >     Quoting Daniel Kahn Gillmor >: > >     > On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote: > >     >> I do not believe the name should be changed: > >     >> > >     >> 1. MLS is a protocol that is equally suited for pairwise > messaging > >     >> as it is for group messaging > >     >> 2. The MLS name is elegant and mirrors TLS.. > >     > > >     > "Mirroring TLS" is exactly what i'm afraid of. This is a > radically > >     > different protocol, performing demonstrably different work > at a > >     > different position within the stack, with a different view > on what > >     > interoperability even means. > >     > > >     > Let's make it very clear that this *is not* TLS, and that > it is not a > >     > substitute for TLS. > >     > > >     > The protocol described in the documents is *not* > equally-suited for > >     > pairwise messaging -- it has a number of subtle features > that are > >     > included solely because it is intended to handle group > messaging.  As > >     > other people have written upthread, the protocol this > nascent WG aims to > >     > describe will handle pairwise messaging as a special case > of group > >     > messaging.  It is not designed intentionally for pairwise > messaging and > >     > if it were, it would have a different design. > >     > > >     >           --dkg > > > > > > > >     _______________________________________________ > >     MLS mailing list > > MLS@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=rfhSuK8vpcpFLcVQ8OMeZLwppm8O9uVb1XZ27wXlf60&s=BQG3-r7qCBQlhrrPGVNVJj6heSZcsNivR8jfE1ZmqzY&e= > > > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > > > -- > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology > [https://www.cdt.org] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org , p: 202..407.8825, pgp: > https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871 > > _______________________________________________ > 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 --------------6FEE247C832832146F18E651 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit If I would make a change it would be to MLK or MLSK.

This effort is (per the charter) about installing and managing Message Level **KEYING**

Message Level Security includes how the messages are protected (securely enveloped) over the communication channel.  That is out of scope of this effort.  (see my SSE draft if you want a general session level secure envelope).

And is it just message level or multicast message level (MMLK).  :)

Bob


On 07/19/2018 07:11 PM, Richard Barnes wrote:
I don't have strong feelings here.  I'm not wedded to MLS, but I don't want to move from that to something lame :)  MLS has the benefit of getting some "trustiness" from the resonance with TLS, and we already have the top Google hits for "MLS protocol".  I'm not sure MSG is enough better to motivate a change.

On Thu, Jul 19, 2018 at 6:51 PM Joseph Lorenzo Hall <joe@cdt.org> wrote:
+1
On Thu, Jul 19, 2018 at 6:43 PM Jon Millican <jmillican@fb.com> wrote:
>
> This discussion came up again at the hackathon, and I think there was a fair bit of sympathy for the idea of at least changing the protocol name to MSG; for the reasons described in this thread.
>
> Personally I'd be keen to have something slightly more uniquely Googleable than MSG, but I don't think that MLS is any better in this regard.
>
> On 27/03/2018, 19:03, "MLS on behalf of jeff.hodges@kingsmountain.com" <mls-bounces@ietf.org on behalf of jeff.hodges@kingsmountain.com> wrote:
>
>     +1
>
>     Quoting Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
>     > On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote:
>     >> I do not believe the name should be changed:
>     >>
>     >> 1. MLS is a protocol that is equally suited for pairwise messaging
>     >> as it is for group messaging
>     >> 2. The MLS name is elegant and mirrors TLS..
>     >
>     > "Mirroring TLS" is exactly what i'm afraid of.  This is a radically
>     > different protocol, performing demonstrably different work at a
>     > different position within the stack, with a different view on what
>     > interoperability even means.
>     >
>     > Let's make it very clear that this *is not* TLS, and that it is not a
>     > substitute for TLS.
>     >
>     > The protocol described in the documents is *not* equally-suited for
>     > pairwise messaging -- it has a number of subtle features that are
>     > included solely because it is intended to handle group messaging.  As
>     > other people have written upthread, the protocol this nascent WG aims to
>     > describe will handle pairwise messaging as a special case of group
>     > messaging.  It is not designed intentionally for pairwise messaging and
>     > if it were, it would have a different design.
>     >
>     >           --dkg
>
>
>
>     _______________________________________________
>     MLS mailing list
>     MLS@ietf.org
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=rfhSuK8vpcpFLcVQ8OMeZLwppm8O9uVb1XZ27wXlf60&s=BQG3-r7qCBQlhrrPGVNVJj6heSZcsNivR8jfE1ZmqzY&e=
>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls



--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202..407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

_______________________________________________
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

--------------6FEE247C832832146F18E651-- From nobody Thu Jul 19 18:02:58 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD0C130E62 for ; Thu, 19 Jul 2018 18:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbHzm612ciXi for ; Thu, 19 Jul 2018 18:02:54 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 06C8E130E60 for ; Thu, 19 Jul 2018 18:02:54 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id d22-v6so5373566qkc.8 for ; Thu, 19 Jul 2018 18:02:53 -0700 (PDT) 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=QgLx46lEJr84RWPcQs/qQSXOCPVbxwYuRyKkBfI2BzE=; b=Jm4HkbcAHAywQwMAYoBNgdBy15GMei5CX44SnbpbRdid9MbjCMoawqARshE4fFijlO hof0YLJIkK1ZYvxungfKc8U8fUxPtVDVtkjDSTusGXeLeFD4ns2PN2e6UW5oemMA5hJk YhixFP2R35U39jI5W/4Es8i9bZZFfxb411ZT2JvpiJn/dxIQkz3RQoY4NCSgKqfugsB9 YkPhNWALGOm9Djsnl+tpMyRh1RUnpfTX/2O4jzv2VGijo4yFcDkmwpQAsX+9RDD4YZhu Lsf7uNBDNxr0/RknoCTZfkU2E3jv7FSXYWgelDN/9VPkT0+xjW1SLxOAZY4d6sUvrsU3 khSg== 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=QgLx46lEJr84RWPcQs/qQSXOCPVbxwYuRyKkBfI2BzE=; b=KzIFKT2GHG8BpcThvMGKxwNPDoW8iNhS2E0zhVXK3BAb4ELWdw8WYxknoPQ7aFIdkz cXfiCyi9tNxEtDhIdEdsNghAJ97y347jutxAVJ45rJ10aj2E9dnAj6RuNmm89/TGCdEM zKm9TkcYNd76bVzPyswd1u0LCzGEbIVHKX7yvcZsIISG37zqyJbYpYunsL3asbEteO/D ioheQ9bcYmbfylIUpuNNu/WJECBTlAPX2ZPIVxwxt2uj7F6D3CaeWDKGzpEX4o1GvoTn DRtCf0mCg28hVFe1g0j231HpjlOqtabikQ1URsizFoNnMmGZ+vMewdT8ZcJVMn4Br0iF 5osg== X-Gm-Message-State: AOUpUlHDMEWfEf6fugjC5qD6vWJPhlLwd3o/705IpstwTAMtau0nl92H R4kgghC8v8weVyT/rSVUw5w= X-Google-Smtp-Source: AAOMgpeYEF4HDu85ckZKrQSGKQTCUgR6KMEOQXHGRnLCX0fbeRgoytyUTWmhfchdfa9RsnfX2852ZQ== X-Received: by 2002:a37:c204:: with SMTP id i4-v6mr11047278qkm.438.1532048573003; Thu, 19 Jul 2018 18:02:53 -0700 (PDT) Received: from [192.168.0.100] (pool-71-161-192-40.burl.east.myfairpoint.net. [71.161.192.40]) by smtp.gmail.com with ESMTPSA id t28-v6sm395206qki.82.2018.07.19.18.02.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 18:02:52 -0700 (PDT) From: Karthikeyan Bhargavan Message-Id: <2C6B2E08-F739-4297-97DD-4DEC0B1C33FA@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_56099BF6-FE26-4C80-A186-B05603F38144" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 19 Jul 2018 21:02:50 -0400 In-Reply-To: Cc: mls@ietf.org To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Test framework X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 01:02:57 -0000 --Apple-Mail=_56099BF6-FE26-4C80-A186-B05603F38144 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The parallel with the TLS 1.3 handshake maybe useful. Although it was designed to be used only with TLS and its applications, = it has not become useful to design a Handshake API that can be used by = QUIC as well. We should similarly define an API for MLS that can be used within = messaging applications and publish test-vectors for this API. -Karthik > On 19 juil. 2018, at 19:08, Richard Barnes wrote: >=20 > In our overrun A.O.B. section today we had a topic, "interop test = framework". Since we didn't get to it in the meeting, here are some = thoughts in writing: >=20 > The idea of interop testing is a little challenging for MLS, since = we're only defining a part of the system -- we don't have a specified = transport, for instance. Instead, we just have message formats. Given = that focus, I'd propose we agree on a standard "API" for MLS = implementation to implement, focused mainly on producing and consuming = messages in the standard formats. This would allow us to build some = standard tooling that can pull messages from one implementation and feed = it into another implementation. =20 >=20 > I don't think this needs to be an I-D / RFC, but it should probably be = something we can all collaborate on. As a start, I've dropped an = initial API into GitHub gist (we can make a repo laster), based on the = common API implemented by my JS ART and TreeKEM code: >=20 > https://gist.github.com/bifurcation/1a0765bb589383e42b473b7b21b2928a = >=20 > Folks who are considering implementing, does this look roughly = sensible? Are there things that are missing? It probably needs an = encrypt/decrypt for message protection, and some more accessors. >=20 > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_56099BF6-FE26-4C80-A186-B05603F38144 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = parallel with the TLS 1.3 handshake maybe useful.
Although = it was designed to be used only with TLS and its applications, it has = not become useful to design a Handshake API that can be used by QUIC as = well.
We should similarly define an API for MLS = that can be used within messaging applications and publish test-vectors = for this API.

-Karthik


On 19 = juil. 2018, at 19:08, Richard Barnes <rlb@ipv.sx> wrote:

In our overrun A.O.B. section today we had a = topic, "interop test framework".  Since we didn't get to it in the = meeting, here are some thoughts in writing:

The idea of interop testing is a little = challenging for MLS, since we're only defining a part of the system -- = we don't have a specified transport, for instance.  Instead, we = just have message formats.  Given that focus, I'd propose we agree = on a standard "API" for MLS implementation to implement, focused mainly = on producing and consuming messages in the standard formats.  This = would allow us to build some standard tooling that can pull messages = from one implementation and feed it into another = implementation.  

I don't think this needs to be an I-D / RFC, but it should = probably be something we can all collaborate on.  As a start, I've = dropped an initial API into GitHub gist (we can make a repo laster), = based on the common API implemented by my JS ART and TreeKEM = code:

https://gist.github.com/bifurcation/1a0765bb589383e42b473b7b21b= 2928a

Folks who are considering implementing, does this look = roughly sensible?  Are there things that are missing?  It = probably needs an encrypt/decrypt for message protection, and some more = accessors.

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

= --Apple-Mail=_56099BF6-FE26-4C80-A186-B05603F38144-- From nobody Fri Jul 20 01:20:26 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 79A431310D8 for ; Fri, 20 Jul 2018 01:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.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 QeESEhD9aZiz for ; Fri, 20 Jul 2018 01:20:23 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1821310BB for ; Fri, 20 Jul 2018 01:20:22 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id o22-v6so8235462ioh.6 for ; Fri, 20 Jul 2018 01:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=FUpMPXY/9INlwSoJMBsspPJFjgXx90JbC/xVd76cvZE=; b=UaURv0SifpsYQgxgZhHRbR1oXcr6TeCvOJsAQYvWQRdUqMyHmxzhc+f9GWLgvznx4L VWud6Lmp6VJhhTYXA8W4huYesLkqRRmGxp/kuHfzWEeKTSFPO2psiCYs/+bU0XGMSMfK 0sUO5zjVtJJuVW7Yeaw6YXMepEZVkCK7GrpT4= 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=FUpMPXY/9INlwSoJMBsspPJFjgXx90JbC/xVd76cvZE=; b=JYsntAb6t4MOUxmuwz5J226tzmZMj4GOoj2T8pA8nkcc1XRWJknH1KIB0M//Df+PWn jxf+IgTUUMFaf3nL/ka0FojuG0Ztiuk/LT5djw08N0/83ViQUDqmIV5ZKNmCdY6OEVak LxuWEsImbTR2GgOn5qibZuoB4GX6Nfuh1FmgpqA66gdGqStQjl49zAVBtKfwB7XTd1Io UMO9O52K18EM7JBNEmDUDDEBmMgkVmYHCnY3crCD3fAjc6n8yD6Re961YlrjtIFhsXKY ZIM+gNcUXlslL4UQNhx87yhmMHdKQT83iSbzSmPByMRRzOmi3dcWjZfrFwp2grvngzP0 fQ7A== X-Gm-Message-State: AOUpUlFNJRyXBGuWHFOMytvwItEqdyiOw+nrSK3RY09hO2GEo+rPTiri 4I1IhRauYN86vIBOTG2s0wZXsyYd7QcZYuqsYwll93DXJN0= X-Google-Smtp-Source: AAOMgpdGCEaUA+kNBZflmhJi4YbPAad53CKaraTj+OjgBLWj42zzqcvfPmGTLMPt7yRPwWN2XtWYmzcoyOUwJgmqduE= X-Received: by 2002:a6b:bd43:: with SMTP id n64-v6mr832104iof.254.1532074821914; Fri, 20 Jul 2018 01:20:21 -0700 (PDT) MIME-Version: 1.0 From: Shivan Sahib Date: Fri, 20 Jul 2018 04:20:11 -0400 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000087d2a8057169f79a" Archived-At: Subject: [MLS] Enumeration of failure modes in protocol draft X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 08:20:25 -0000 --00000000000087d2a8057169f79a Content-Type: text/plain; charset="UTF-8" There was some talk at the hackathon on whether we should have a section in the protocol draft about things that are currently 'undefined'. For example, what happens in the GroupAdd case where we're adding C to a group containing A and B, if A and B call state.add(C) but state.init() fails for C. It would be worthwhile to consider general ways in which things could go wrong and mention recovery mechanisms in the draft. --00000000000087d2a8057169f79a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There was some talk at the hackathon on whether we should = have a section in the protocol draft about things that are currently 'u= ndefined'. For example, what happens in the GroupAdd case where=C2=A0we= 're adding C to a group containing A and B, if A and B call state.add(C= ) but state.init() fails for C.

It would be worthwhile t= o consider general ways in which things could go wrong and mention recovery= mechanisms in the draft.
--00000000000087d2a8057169f79a-- From nobody Fri Jul 20 02:11:15 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC641310F2 for ; Fri, 20 Jul 2018 02:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, 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=rub.de 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 5SMo1AI0dts8 for ; Fri, 20 Jul 2018 02:11:11 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2ae5]) (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 CD24A1277BB for ; Fri, 20 Jul 2018 02:11:10 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 41X4qw51Tzz4yPv for ; Fri, 20 Jul 2018 11:11:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1532077868; bh=s1qYhc8HTZckQ9QAEXCCl2BBhChD+aIVBCXSxtAT+Js=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LwjHQaUt0Tkidc2BqKQozMvx74ONuMw45C76R3l8aS66gqIoKyONjyia6D0nejZwL cuUvYl7kF39gyDhPEMJQdAcPUn6CR4Wysr7m/ESDyDQwYrufUuiZ6OkeW5Xl6g9Mjw yYfH2T3hV/pTIluejKOJhS0R2ephyxzqQEcJNuA0= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 41X4qw3kZ3z4yM9 for ; Fri, 20 Jul 2018 11:11:08 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 41X4qv2clGz4yPW for ; Fri, 20 Jul 2018 11:11:07 +0200 (CEST) Received: from [134.147.40.8] (freedom.nds.ruhr-uni-bochum.de [134.147.40.8]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41X4qC1KB9zys3 for ; Fri, 20 Jul 2018 11:10:31 +0200 (CEST) To: mls@ietf.org References: From: =?UTF-8?Q?Paul_R=c3=b6sler?= Openpgp: preference=signencrypt Autocrypt: addr=paul.roesler@rub.de; prefer-encrypt=mutual; keydata= xsJuBFMPNo4RCACsEL23jO1k25wZhdphKuPdmEnxvjbtZavn1ZkALMxWJ4bYHPxNkpZWCT9h v0ZizDoosjlIvh0lK0nZgK0MLwjG/swrG/qUoZPIxStbXSVZPPwSdTaa+nzN0HD2y30zDExP 9WtchiEnGPB8WLCjkx5qscrBZV+PzI5akdK2CGBDthVvYzu4oLMZ89akJfM82ap9fGf0pfMh 4Qj4zIH6Vt6PIDn/r3d1GNW00RlEaq+MerAp3WkO+BwZ/2yCM+WJFG4w8tI3p+CjUlZehU2o WBxAmaLLHK3HOrCxiyGWZtIXy5plSfBjDomrlnlIiaDiC0N+MleHF8+IqxAo0XKySXn3AQDm UVBV0DpdIxm8dk2BCT5pMdnZFxzoBbSt57Tv9htwcwgAqpCy5Fhfcm5fVdhkeuaX86izCPfn 1k6FDt/3VUZ7lwcLJL9qYp1treUptfrUJ/DOeZN5LAyULj2Aijjy2Tni3RrDR9+1NvLTla4v bJpndEWI0nof1l8za+sfeQn8YnSylZLFt/Blx3MAe0MnNi9ZbGk50fdKjNsBwCwcZP/1Gyen s05rk2aaL07n5guCz/0bmlQFANCyi3lH+EcHJ0I4wYriBA4xJ3wDJmrCtjhsAtHNnc6pqvgE S2h2J7gAGa7A+ktFJhAxmVSx02GzakjNenx/SWMT2zlIZ/tu1T3wdX3SghUvX62p37FXPObF EbaEJZc9j4jUqnaJHbj/q717Gwf/S3mVyiMaIVzfbxmngGVfaf89vHRh7sWvkt9+TarR7Xen M2Bwi9wKgJ6pshkAnIe6VCGx4+JNH5SUiaxVr6TyrK9GcDkfCEwcVGwDBmeKdtv5Psb2Ho6t tTIWPwj/eQAJn283X18izF1xYYDFSct835R3hG6baP1FJZmMSm+CxV8C+uZXB/Yom/p4NblJ ujLJPGVampAZYs3ZVLrQBuxrXhGrDimFY9TLgO3ZN4gN4gQ3OvvBzmagwGMJdszTaRNE3JGE /qzvlvIs3KTLpQzybxZWwl7SO8b7A+i6+Yp9uN6thrpX7/TdnKcvnMezNYMRjuXvRGmaZ7c2 thgDF83fY80jUGF1bCBSw7ZzbGVyIDxtYWlsQHJvZXNsZXItcGF1bC5kZT7CfgQTEQgAJgIb IwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheABQJTDzbTAhkBAAoJEBbS1xKcazdGVrAA/3lK QI/T1aM6i6KysCui1/fluId0YmRRqypKMA+XAz2gAP4tLC5YbgGw9O9nMTivNqqPiLthcl/j SqJFkN9wvZOvIs7BTQRTDzaOEAgAlESVhuAL+WnQd/2DG4VxkkozWwDayzdpvP6L3agcf6bx ftRHlYPFGh6Ks5kwjTlo3+W9dX0PzM6rAaeTh1hJs1z793p/SKI6C184G/ReGSxZf4/sX1OL jpsrqyiCsWxth8wv8ha9hNLNInF3jA6fpJna7VVh4pE05Elc5BIkX+gXyGd4LtMUd+r3oEje b6hfHxdM0aOwv/ekJqY5o0MZdNjQ6bJ8o7YrKfp1mLG6dYXGa9z3nEmjbXJ/74YgZSpTtGg1 Do+uaOCU4AvD3uBvB85PWyIhasCoOniNh762HBhDDGu9GyRGXnQBIz/+gQNjuXTzUvACZ2Ah QscDlZ2qnwADBwgAhgobq3ALUCG7DeLpEK9uwZJMt9rGJfRwlj5YafXb66kCRuLOOgKzSjy+ 7f5OYQei+byxYc0+/JKTxhaIReLDP/iafm/E2b6n0kKrznrdCu/EwJ+q5MtyrLlUHeY7NEVj VZhYw9zaL6J5Ed4EJfbOYMzovQPkJ3rDLCqs/phYpg1Yd1+qGo1ODjLXC8ThBfvoSL/pLhvf HxLyPQATpuT4rVhNa3RsMceQ4jNVKL5SvJwuomrWgFUyteRQLt12M6DjmaUeTXHSntfqjQVy 8+1rC/k1UhV35yuGUMbDmPL5dcGWYvYXRqTBKC39NMXtICM8zTBTTlGhMp2Zcz+lka7LR8Jh BBgRCAAJBQJTDzaOAhsMAAoJEBbS1xKcazdGw7MBANgKvPttJHvY4OgwW4ieVk30QFrIMtKh DPr0iJcobzajAP9BuJfwsGAR/zE0lByRtCvJymNYhst5Hf9FitY4nBJ2Rg== Message-ID: <15295b63-0d33-2412-1e85-cbfef9571efd@rub.de> Date: Fri, 20 Jul 2018 11:10:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VedCR9OUvWNWvJYNyZylRqL3kVIUqZduM" X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 09:11:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VedCR9OUvWNWvJYNyZylRqL3kVIUqZduM Content-Type: multipart/mixed; boundary="eRQC6OErY1ioLaHgzOYfZkpBwcF7OvFy8"; protected-headers="v1" From: =?UTF-8?Q?Paul_R=c3=b6sler?= To: mls@ietf.org Message-ID: <15295b63-0d33-2412-1e85-cbfef9571efd@rub.de> Subject: Re: [MLS] protections for MLS "handshake" messages References: In-Reply-To: --eRQC6OErY1ioLaHgzOYfZkpBwcF7OvFy8 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 19.07.2018 21:00, mls-request@ietf.org wrote: > Date: Thu, 19 Jul 2018 12:45:13 -0400 > From: Daniel Kahn Gillmor > To: mls@ietf.org > Subject: [MLS] protections for MLS "handshake" messages > Message-ID: <87fu0fxjhi.fsf@fifthhorseman.net> > Content-Type: text/plain >=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 wit= h > the current discussion) >=20 > I believe we should provide encrypted cover, and a mechanism for paddin= g > 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. Why and how is this possible for long application messages (i.e., how long should a sensible padding be?)? > 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. Why? A network observer will see anyways to whom this message is routed. I do not see a reasonable (i.e., practical) attacker model in which this is a requirement that can be achieved with reasonable efficiency loss. (E.g., a tree of depth 3 will always result in shorter path update messages than a tree of depth 8; so where is the limit for the padding?) Cheers, Paul > 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 --eRQC6OErY1ioLaHgzOYfZkpBwcF7OvFy8-- --VedCR9OUvWNWvJYNyZylRqL3kVIUqZduM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAltRpwYACgkQFtLXEpxrN0Z5HQD8CJxY3oKZH4vpMStivgYp1O8Q tqol+6lfVQCeZ5yNiz4BAKEpX+XQDLEBPdkCOSdsZSQocXEHA667YGq3OkxDqpUo =6IjF -----END PGP SIGNATURE----- --VedCR9OUvWNWvJYNyZylRqL3kVIUqZduM-- From nobody Fri Jul 20 02:30:54 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41E2131132 for ; Fri, 20 Jul 2018 02:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=R+PQFTbV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=apwsl1LU 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 TqXCRKXvtaou for ; Fri, 20 Jul 2018 02:30:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E67131129 for ; Fri, 20 Jul 2018 02:30:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 368ED21CE1 for ; Fri, 20 Jul 2018 05:30:50 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 20 Jul 2018 05:30:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=dHjoVq2HxDmZmGTMXUA0/1E8rt Yra6zf5w8VBgOvoS4=; b=R+PQFTbVP8nxiLsfVA68OJ7mM1j0USFyisdzWVJD0q lOdh0JBs+4FquLuWZpf2q315xHNwhPRSBkZYQ3bSSYwo025Iu5PdnwXkoIRovRkL NCOuLaCCd6DnVeBigEMFGhl8NHgM0wTdZZ2Pg/8+6rTsaC0YOzwpOBSb2Kc7r20H Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=dHjoVq 2HxDmZmGTMXUA0/1E8rtYra6zf5w8VBgOvoS4=; b=apwsl1LUkVWBjPOXf3Dod5 0JWBOAKjqBCEkFaAy+p9rFOHx2os26w7M8jvN6hKy7RLw4U/yjCGi6Hgu77F7xIE OHVGQnqFP09docnksSOw6S8B9Z30TtkhYZkgM7MPrViCL6M2hXBnUs1Cp4u/BHkZ rV/ifwn/hVULnAEdZLDMrcZCRzL0m2jgZMvUu7AqxoqHqBwZCAT7ro/RbqFhcg0G 5KjvkZYQJHDEsYXfok/rguQysN491JaP8E9lWT6MqCDfHH4byahnkEBqPfqVjLgO RSeUXDNcQydwVoda9JOfp/KbiwP4WZjbgMcGcwdaq8bBYmhC6e56j+q4SKtAD+GA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id CD003BA4CF; Fri, 20 Jul 2018 05:30:49 -0400 (EDT) Message-Id: <1532079049.396316.1447106472.39418D41@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e References: <15295b63-0d33-2412-1e85-cbfef9571efd@rub.de> Date: Fri, 20 Jul 2018 10:30:49 +0100 In-Reply-To: <15295b63-0d33-2412-1e85-cbfef9571efd@rub.de> Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 09:30:53 -0000 I certainly support adding fields for applications to pad however they like; that seems uncontroversial to me. In particular, if the application wants to pad out all messages to e.g. those of a 32k group, there should certainly be a field in the MLS packets for it. > I believe we should provide encrypted cover, and a mechanism for padding > of handshake messages, not just for application messages. As above, having a field for padding handshake messages seems uncontroversial; applications could use it however they choose. Encrypted cover for the initial handshake seems circular: something has to go in plaintext first. Encrypted cover for subsequent GroupAdd/Remove/KeyUpdate messages I'm not sure about: I guess it could be done by wrapping them into a message under the current group key, but it seems like some data might have to be on the outside in order for clients to figure out how to decrypt them. How much data needs to be hidden---would exposing a couple of sequence numbers and a group ID be ok? (This seems analogous to Signal's header encryption variant, which basically derives another key chain to encrypt packet headers.) k From nobody Fri Jul 20 04:02: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 963A8130F0A for ; Fri, 20 Jul 2018 04:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=xCKrDjDj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WvxP/3Mm 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 QIKq0LGjHX6h for ; Fri, 20 Jul 2018 04:02:20 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A6C130DD6 for ; Fri, 20 Jul 2018 04:02:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6D01121CCA for ; Fri, 20 Jul 2018 07:02:19 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 20 Jul 2018 07:02:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=QOZaXI2XBMfDOob3Hs4xE6SrrU 9f2XamKZni7f3Qxh4=; b=xCKrDjDjdQWJKjHa/sonZg6ZSWPyWOxJubSV7qvyRM 3RZc+x1FqfY3chFI/SSgL9TN4loIB7u4dP2qoBTCeGayPOGs6TsE8vBwESWdpiwv 0HRa+7utCB2PxR78caPQb/KImaxAixSSVyIx9NcJHJunobG9gCshkBrO6Z71h7pJ 4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=QOZaXI 2XBMfDOob3Hs4xE6SrrU9f2XamKZni7f3Qxh4=; b=WvxP/3MmR+/mKwXfKWlFBM iunvzIz6qi4cErri6Up0O9KI1jxyR5ApFya3PLJFVclfVvudI4G4Ny6kKdbE0FI8 LBtAfh9RyZBJrwEVT82QMcau5BR/p/UaXhZyf5xlOj292mirQS2pMh5Vz+P5gofe kdN3vcEIrdu4tE5Wvx5OCpppS+sUCTBO+Z7iKpHIDRyRevLF3TuHW16rYk3K+CnO AajjaRRum1FQXgnDIL0jCtSaLI8OfB2J+7J8Id5vDoeVLVdxF0+wkK01ZJio4eNM 5cXrMKIYViKaiMOlUCe91f/n/+2Yub15V4aQCcM44PTF60Dmk4R2fKwzSM9McGQQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1042BBA4CF; Fri, 20 Jul 2018 07:02:18 -0400 (EDT) Message-Id: <1532084538.425728.1447174816.79181C11@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Fri, 20 Jul 2018 12:02:18 +0100 References: <87va9ax422.fsf@fifthhorseman.net> In-Reply-To: <87va9ax422.fsf@fifthhorseman.net> Archived-At: Subject: Re: [MLS] key update guidance X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 11:02:23 -0000 > (a) should peers in a conversation have a way to communicate explicit > expectations about key rotation frequency? Establishing a shared > expectation of key rotation can make enforcement more > straightforward and comprehensible (both for the user who gets > kicked, and for the people remaining in the conversation when a > member gets kicked). +1 this could perhaps be one of the group parameters that gets agreed on setup. Is there likely to be a need to change this for an existing group? I'm inclined to say no. > (b) if there is an expectation of key rotation frequency, does MLS > contemplate any enforcement mechanism? if there is enforcement, > who should enforce: participants in the group, or the server? +1 clients know when they got a key from someone else, so they could unilaterally decide not to accept messages under a too-old key. This could lead to confusing transcripts if one client accepts a message (say it has clock skew) and another doesn't, but I think this is no worse than a network adversary which drops a message. Ideally the expiry time is well above the actual update frequency, so clients under normal operation should rarely hit it. k From nobody Fri Jul 20 05:30:15 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF794127AC2 for ; Fri, 20 Jul 2018 05:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ZpVPG6mO; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=A7rumkOB 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 4iUTKIDuh3N6 for ; Fri, 20 Jul 2018 05:30:11 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 D230D130E20 for ; Fri, 20 Jul 2018 05:30:10 -0700 (PDT) Received: from pps.filterd (m0148460.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6KCNucX031745; Fri, 20 Jul 2018 05:30:09 -0700 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 : content-transfer-encoding : mime-version; s=facebook; bh=MF2aWsr2ib0pwAM6wWVolFIRaRRgcCnmLMj3cQ9KuE8=; b=ZpVPG6mOQB8RtpCJO3htLLrFMQWaPRocGX5QWzjK1gyDNEd6B+n1AkX9L318A41AObYu lBvBDfRv/4xOyQN8c9VE+A36wsQMTU8F5/GSLFHJF3jlRDDCNi96rnjfLfjqmv0yItV/ 9Bf4rIMP3JPUjE7v2Yk4EZim7M88RQX+W4A= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2kbbxhgeuu-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 20 Jul 2018 05:30:09 -0700 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.17) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 20 Jul 2018 05:30:08 -0700 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=MF2aWsr2ib0pwAM6wWVolFIRaRRgcCnmLMj3cQ9KuE8=; b=A7rumkOBlHh2qyhrM+bL7gmSVqBHoWzgad9EqdxAp1OAcr5GniRN+8nwhqiAjFEWkzRQW4i14z3KdGibooQ4KNGIJqQrA7AId4LM/dpnarXoXnLYV6uVrkeAhj394wO2Hokq9AOdPJqo9H/jo30FjcqonGVVn1HVWAKrAM+4eXM= Received: from SN6PR15MB2205.namprd15.prod.outlook.com (52.135.64.145) by SN6PR15MB2382.namprd15.prod.outlook.com (52.135.65.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.20; Fri, 20 Jul 2018 12:30:07 +0000 Received: from SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b]) by SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b%3]) with mapi id 15.20.0973.018; Fri, 20 Jul 2018 12:30:07 +0000 From: Jon Millican To: Katriel Cohn-Gordon CC: "mls@ietf.org" Thread-Topic: [MLS] key update guidance Thread-Index: AQHUH67HWD8rczf/F06K3l2bHkHBLaSX8uIAgAAYiQ8= Date: Fri, 20 Jul 2018 12:30:07 +0000 Message-ID: <5C3272FE-22C9-44E2-AAAA-8F96206293F9@fb.com> References: <87va9ax422.fsf@fifthhorseman.net>, <1532084538.425728.1447174816.79181C11@webmail.messagingengine.com> In-Reply-To: <1532084538.425728.1447174816.79181C11@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.132.231.52] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR15MB2382; 7:k8c1PgVANwk8urV58rJZoGtxWSRQviycztQHl+qILiPJmPi42fls/Sppc3zi9Om+4+5NGpyfMPN6tA4N6EsQTJ0KBqyOQXq92Jtuvj45evYNiQ4uqkzEmqSYGCJoSCivrzlAd0cjeKTkY5AE2sVN3jLRur82MX/xosM5nVZe4u3Bq7vVM/A6Doxa8ODHBn3ijGRzhs5+NN5w3lkHm+zQ49z1WWZTUb5l6yimDmJaW8VJze6baw0pYCDRIccACH8h; 20:ZK8DHfHnE/0nc73SUOdvVOamJbWCliiWvOE5jaNEg33qDrhfysWws6S+OqOc10nJt71h/JucADY+4HedywqEMjBMnZk9UOyo6g2OMbWMfaneVkNoKFuv3O1NPPhnkbIf/As4tmYFV1wzA75h5zjSsKQMD7dlkuuF2o3IJlJbZMk= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fd487ff3-4ad0-4d3f-36a6-08d5ee3c86e4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:SN6PR15MB2382; x-ms-traffictypediagnostic: SN6PR15MB2382: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(11241501184)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:SN6PR15MB2382; BCL:0; PCL:0; RULEID:; SRVR:SN6PR15MB2382; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(366004)(346002)(376002)(189003)(199004)(105586002)(106356001)(97736004)(33656002)(446003)(316002)(36756003)(82746002)(5250100002)(11346002)(68736007)(2900100001)(102836004)(99286004)(6506007)(53546011)(186003)(6486002)(26005)(6436002)(76176011)(229853002)(486006)(6512007)(3846002)(476003)(2616005)(6116002)(53936002)(83716003)(6246003)(66066001)(6916009)(14444005)(256004)(5660300001)(305945005)(7736002)(25786009)(14454004)(15650500001)(8676002)(81156014)(478600001)(8936002)(81166006)(2906002)(86362001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR15MB2382; H:SN6PR15MB2205.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ejtqpm6BdalkjCG7VvGIs8JbwUtG4Cp+Azvyv5YMKfrtrxhMBN6hIk4ugGQZJj5bLIhH2BPxDykdxxglzfxXNFjdK+ARWpdFMbY747rTELp1ogdUlrfDU7ujXXqU+8IJyplMxLe+HEaVl9bRqGkR3caDk395M+hJLZYCAiEBe5XjkgqN7kIVvUKbF/gAdt1RnhHjjES5HUhiokr1tukPYxmiy0WAWrJ4h3qSUjSx93Xs5/m/kRVAMrbHFhrHxMMv8DUzHUAx4/fjUELTXMNwgGECjwoYtwCPP5x6Nr+CkJSRdAEKChrgkCyxzz+n8c5IAUcRWYXrKSwfqPbqJE62lRR2EazakNC8t7bhab4xVu8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fd487ff3-4ad0-4d3f-36a6-08d5ee3c86e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 12:30:07.0407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2382 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-20_03:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] key update guidance X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 12:30:14 -0000 > On 20 Jul 2018, at 12:03, Katriel Cohn-Gordon wrote: >=20 > This could lead to confusing transcripts if one client accepts a message = (say it has clock skew) and another doesn't, but I think this is no worse t= han a network adversary which drops a message. This could perhaps be server assisted? I.e. the server should be cooperativ= e and force updates at appropriate times, but clients will ultimately enfor= ce it if the server fails to do so. Intuitively I don't think we're relying= on the server for a security property here, and as it will likely always b= e capable of corrupting the conversation, I don't think it will make this s= ignificantly worse either.= From nobody Fri Jul 20 19:58: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 770E2130E62 for ; Fri, 20 Jul 2018 19:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] 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 Kmw1mxa1ujdE for ; Fri, 20 Jul 2018 19:58:37 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21D7130DC5 for ; Fri, 20 Jul 2018 19:58:37 -0700 (PDT) Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:d8a1:1dff:fef1:ec8e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 70245F99A; Fri, 20 Jul 2018 22:58:35 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2575320867; Fri, 20 Jul 2018 22:58:26 -0400 (EDT) From: Daniel Kahn Gillmor To: Joseph Lorenzo Hall Cc: mls@ietf.org In-Reply-To: References: <87fu0fxjhi.fsf@fifthhorseman.net> Date: Fri, 20 Jul 2018 22:58:26 -0400 Message-ID: <87d0vhwazx.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 02:58:40 -0000 On Thu 2018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote: > On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor > wrote: >> >> 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. >> >> 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) > > What about "content" and "keying" messages as new names? I'm maybe a little reluctant to use "content", because it seems too generic, and too allusive to the elusive "content/metadata" boundary. But i'd be fine with "application" and "keying" as the nomenclature. But I'm more interested in what people think about protecting these messages (or even the distinction between the two categories of message) from the DS itself. Is there a reason that we need to expose to the DS that keying updates are happening? --dkg From nobody Fri Jul 20 20:02:44 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C3130E92 for ; Fri, 20 Jul 2018 20:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiyF0dYIaWu1 for ; Fri, 20 Jul 2018 20:02:40 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 56EED130E83 for ; Fri, 20 Jul 2018 20:02:40 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id y200-v6so3007354lfd.7 for ; Fri, 20 Jul 2018 20:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v9WgRL53xR3ZO53AZ0+9nij/amn5VDA84Cz/aMc8GBw=; b=k0HzvWpS8tSKinh2JKPUpJ0m2DfkLvmEn1YGPfxIWY5lnpG7NghCUysPMa+H7wVDo9 ARpuHTwa5a4wnmXIXX0QXymLp/06ljcn9g18gIEpHx49vyVPLmF4Oqt72udggtDb7OPe dK/SKf2Qb6VCW3zCpRTDrbQM2ywrcaWi4+d5pjTTKgFz8LNzo1vAexlr2yn2+otpZfmN DM0Y+awz9CM1QNciILnecxxpASTv/lyaVzkbcOeC/FlF2I1PPJXhncOaqkan4w8QGgZv vBQjtlJZ+6/Crym3+YOdk9Ra3vY5xKH1am/K6QX/8zPUqL8L/A7qUqBCDXXt0NwdMlYC dmwg== 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=v9WgRL53xR3ZO53AZ0+9nij/amn5VDA84Cz/aMc8GBw=; b=NmeZH8hpboJikgFxMiN6IzcrCkGVZIJYHg6Hkhpv64d+hKZhR02th8HETAdVZB+bWO areGxs/5m/Lrm3s/3x9Ysc+gGuawlKTa54bswhDfTli4G9w8mcZZp9riXkAffWXfd2bG 4J2vNfrNO5INP7Ty/CP5hhhc0xjk8vrsVRZFel6wRNFH5FKuX9TxQ0KoR4dpG9nPdQ7+ qbA7G3QVDE8MRCFi+y40plWn7ovJD//SxcSBiEuG4krNTVn45rxuucc8uHK0LRY+P1K3 p0DnLGxaH/0y913TQRpbK9gf+t2IGlRu1UmwrS3bH1q58xUvZs8YVxzoeeq/Veo9QY0+ nx8g== X-Gm-Message-State: AOUpUlHZVsYNWXxCwu7MOgzdwoSr+k/6nkUaS3Fb4dPsg4XR74M9lhvy 4UogvEW0kjN5U02eOHsbj5FX/5u5JN6ddulhj6zYNQ== X-Google-Smtp-Source: AAOMgpfzxlBQlwSaGR8ozJawWVQM/XbeAtrHBAKu76DhXJXKoNVAedGxqhpAN6EjjdUe0Ig08bPRDFqXrbTlV8OAZEk= X-Received: by 2002:a19:c403:: with SMTP id u3-v6mr2541686lff.87.1532142158501; Fri, 20 Jul 2018 20:02:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 20:01:57 -0700 (PDT) In-Reply-To: <87d0vhwazx.fsf@fifthhorseman.net> References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> From: Eric Rescorla Date: Fri, 20 Jul 2018 20:01:57 -0700 Message-ID: To: Daniel Kahn Gillmor Cc: Joseph Lorenzo Hall , mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a73fd057179a577" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 03:02:43 -0000 --0000000000001a73fd057179a577 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor wrote: > On Thu 2018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote: > > On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor > > wrote: > >> > >> 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. > >> > >> 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) > > > > What about "content" and "keying" messages as new names? > > I'm maybe a little reluctant to use "content", because it seems too > generic, and too allusive to the elusive "content/metadata" boundary. > But i'd be fine with "application" and "keying" as the nomenclature. > > But I'm more interested in what people think about protecting these > messages (or even the distinction between the two categories of message) > from the DS itself. Is there a reason that we need to expose to the DS > that keying updates are happening? > I think it would be better if generally we did not. -Ekr > --dkg > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000001a73fd057179a577 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor = <dkg@fifthhor= seman.net> wrote:
On Thu 2018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote:
> On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor
> <dkg@fifthhorseman.net= > wrote:
>>
>> In today's session, there seemed to be an open question that w= asn't
>> explicitly addressed, so i wanted to raise it on the list.
>>
>> for lack of a better term, we're dividing MLS messages into >> "application" messages and "handshake" message= s.=C2=A0 (i think we need
>> a better term for "handshake", but i'll use it here = for consistency with
>> the current discussion)
>
> What about "content" and "keying" messages as new = names?

I'm maybe a little reluctant to use "content", because= it seems too
generic, and too allusive to the elusive "content/metadata" bound= ary.
But i'd be fine with "application" and "keying" as = the nomenclature.

But I'm more interested in what people think about protecting these
messages (or even the distinction between the two categories of message) from the DS itself.=C2=A0 Is there a reason that we need to expose to the D= S
that keying updates are happening?

I th= ink it would be better if generally we did not.

-E= kr


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

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

--0000000000001a73fd057179a577-- From nobody Fri Jul 20 20:25:04 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 00DEA130EBF for ; Fri, 20 Jul 2018 20:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] 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 WVbagR3J6eBz for ; Fri, 20 Jul 2018 20:25:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722D3130E1E for ; Fri, 20 Jul 2018 20:25:01 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 599B5F99A; Fri, 20 Jul 2018 23:25:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0B1C8202B0; Fri, 20 Jul 2018 23:15:22 -0400 (EDT) From: Daniel Kahn Gillmor To: Jon Millican , Katriel Cohn-Gordon Cc: "mls\@ietf.org" In-Reply-To: <5C3272FE-22C9-44E2-AAAA-8F96206293F9@fb.com> References: <87va9ax422.fsf@fifthhorseman.net> <1532084538.425728.1447174816.79181C11@webmail.messagingengine.com> <5C3272FE-22C9-44E2-AAAA-8F96206293F9@fb.com> Date: Fri, 20 Jul 2018 23:15:22 -0400 Message-ID: <87a7qlwa7p.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [MLS] key update guidance X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 03:25:03 -0000 On Fri 2018-07-20 12:30:07 +0000, Jon Millican wrote: >> On 20 Jul 2018, at 12:03, Katriel Cohn-Gordon wrote: >> >> This could lead to confusing transcripts if one client accepts a >> message (say it has clock skew) and another doesn't, but I think this >> is no worse than a network adversary which drops a message. > > This could perhaps be server assisted? I.e. the server should be > cooperative and force updates at appropriate times, but clients will > ultimately enforce it if the server fails to do so. That would oblige us to expose the fact of keying updates (and possibly the keying material itself) to the DS, right? what advantage would that have? --dkg From nobody Sun Jul 22 04:30:05 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 33EC8130EED for ; Sun, 22 Jul 2018 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8Kq5dnwUkUwc for ; Sun, 22 Jul 2018 04:30:01 -0700 (PDT) Received: from VirgilSecurity.com (mail.virgilsecurity.com [199.58.211.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7246130EE5 for ; Sun, 22 Jul 2018 04:30:01 -0700 (PDT) Received: from BIGONE (unknown [176.226.241.68]) by VirgilSecurity.com (Postfix) with ESMTPSA id B31E7105CB15D0; Sun, 22 Jul 2018 07:29:58 -0400 (EDT) From: "Alexey Ermishkin" To: "'Daniel Kahn Gillmor'" , References: <87va9ax422.fsf@fifthhorseman.net> In-Reply-To: <87va9ax422.fsf@fifthhorseman.net> Date: Sun, 22 Jul 2018 16:29:55 +0500 Message-ID: <000601d421af$526d3870$f747a950$@virgilsecurity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHTXyqXvcXP/ZdxUo4LILbBHqNUAaScmTrg Content-Language: ru Archived-At: Subject: Re: [MLS] key update guidance X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 11:30:04 -0000 Is there a need for key rotation for a member who does not send messages? Probably there is. On the one hand, "advertising" new keys in actual message's header (like Signal does) simplifies message processing logic. On the other, Sending "rekey" messages could provide better overall key rotation flow. As for the enforcement, I think the possible solution could be ordered rotation. Example: - The group implicitly agrees on the order members rotate their keys (sorts members by ID). - Each member sends the new key in his turn or after timeout in case someone's offline. - This can be done by either assigning each member a time slot or allowing next member to send key after a certain amount of time after previous one to prevent flooding. Pros: Each member gets his key updated, no message tsunami Cons: Skipped members should wait for the next key rotation round -----Original Message----- From: MLS On Behalf Of Daniel Kahn Gillmor Sent: Friday, July 20, 2018 3:18 AM To: mls@ietf.org Subject: [MLS] key update guidance At the discussion today, it sounded to me like there was a general agreement that we want to document some sort of guidance for the frequency of key updates. This might end up being more complex than just "update your own key once per day" -- as Jon pointed out, for a large group that could result in a storm of key update messages. One thing we did not discuss is how key update frequency guidance might be either communicated or enforced. (a) should peers in a conversation have a way to communicate explicit expectations about key rotation frequency? Establishing a shared expectation of key rotation can make enforcement more straightforward and comprehensible (both for the user who gets kicked, and for the people remaining in the conversation when a member gets kicked). (b) if there is an expectation of key rotation frequency, does MLS contemplate any enforcement mechanism? if there is enforcement, who should enforce: participants in the group, or the server? My gut feeling is that (a) we should be able to communicate rotation expectations to the group, and (b) participants, not the server, should be responsible for enforcement. I don't have a specific protocol proposal for how to do either step, though. --dkg _______________________________________________ MLS mailing list MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls From nobody Sun Jul 22 16:35:11 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008EA13106E for ; Sun, 22 Jul 2018 16:35:10 -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 AY7BxFZpWpeK for ; Sun, 22 Jul 2018 16:35:07 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 B255D12785F for ; Sun, 22 Jul 2018 16:35:07 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id t5-v6so14978622qtn.3 for ; Sun, 22 Jul 2018 16:35:07 -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=TSpy+ztIvWAte7Rq1ZMZpX+xDffnRnGoH757iCQCw6M=; b=CoPZ1urNxuCWi6vYbUWEMM0yc6BgA2A2Ybxglohsd5eph+7W5R+6K0btY3/hMAjIbr 6ke9G2ClWAQskXJnxPk84Dbrd5KmySIC202Y5d7b0K42mtnggK8nMWNX9nDJuRlSS0qY oPS32OA25WkIU+yc0O0kklcLHLWhNQgFvwb2c= 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=TSpy+ztIvWAte7Rq1ZMZpX+xDffnRnGoH757iCQCw6M=; b=CVYDVzzN4fPtC2O5g8PIE/rFa/pLwy4kQNWZZLd8YcHkDmj33mbm4tlqnI1ua81aAe ySUkdAEWYkdQ5EfhG89Tx/Obd/r/vKJsDNW4udw1URf1GSmk4L0WjIDrs49XOyGEbOYL eotPW+JK0p8q5s3DHVMxJPl+dRSs/yzz4qG8b7b3zbFIgyAgH1erO6HL2hX83xjqcRWm h5RkyPRvycV+tZGqoU66FbYI/tGjrLOc9oRFbIo/xpEfrGon3MD6nlKpD3Mu2XJS4zLA hOZbzrZhOjzqVQBYXNyAbxRmIMDVr3ibSQ0P/ZRU77Xen8M2eQq/joMEwU8RCgvW981l 1Yrg== X-Gm-Message-State: AOUpUlHdLJ0sxz6+6CWwVPch3CNlwygL1o147xlYiU2RHYzw9JHfyena pmHVMnvz0JDyQIaAmOWiwnPS+qtexzo= X-Google-Smtp-Source: AAOMgpfDUBnArf/ctWzFzSD0CHJliV2bkK53r9NoyCO9LXoVx652oSa/kSqNYrr8n22L9Z0oRzdIyg== X-Received: by 2002:ac8:3692:: with SMTP id a18-v6mr10387813qtc.406.1532302506686; Sun, 22 Jul 2018 16:35:06 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id c10-v6sm4650739qtn.90.2018.07.22.16.35.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 16:35:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Sun, 22 Jul 2018 19:35:04 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [MLS] wg-materials GH repo X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 23:35:10 -0000 All, Katriel was nice enough to make a wg-materials GH repo here: https://github.com/mlswg/wg-materials I have uploaded the ietf101 materials for posterity sake. I have also uploaded the ietf102 materials minus the minutes; Matt = Miller sent them to Nick and I, but we need to review them first before = posting (should be done next week). spt= From nobody Sun Jul 22 16:48: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 60F5513106F for ; Sun, 22 Jul 2018 16:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 NE1PJ29K_aST for ; Sun, 22 Jul 2018 16:48:42 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 C2F5B12785F for ; Sun, 22 Jul 2018 16:48:42 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id z20-v6so14147071iol.0 for ; Sun, 22 Jul 2018 16:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DL48cBysO0RbJLYwsPpiTDlmDULk1WVC14NKPndkzfk=; b=oRsN/EItRrZrJMkHrOzI7KFhicdnhqBrcin9kD/mwjtLdCf+7LGRs5LhUksj2f/ufR NRugOJptYXnpEUNYM9NliC+X9lZPQth2k4GjbubqdNOSRaj3rtyVIyit0wtQluKDWvHz JFco05llS8KoUaDGmRslKE+iCztU8WXCnS8ts9zNniQgW5nKp4oyain+TQ1H03KVm6oW 0ZyPlKnPyMNv+AFBy1tqHVfs2hmVXtxdKa02FXM9BJFk9ef5pTsKUVDBNfIJA6irnyt/ s6ue0RNt7PoaBsc6jkHS87pb41/S48W2M3N5XNM/wiGzczdT7pBf3DMPWo6o3xf5nItW 5FRg== 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=DL48cBysO0RbJLYwsPpiTDlmDULk1WVC14NKPndkzfk=; b=AUyQYXG+LfiKYZZ7OLdIuVCozAmQ1FElGjhfs0jW414uOshBxOmMszaTMteOKmbmA5 dGnxgxCVhM3L2kERk+6l2pNkLyVJmZt3r8YLQSnoWTyHD8BIBMoUzav2HQe1SNvuxpmI XCa7fKEhkl9H+ZFNnN47nmCBj4+eOQ2ph6xFVzVX16rnTkd9nWpARNuov0MrSouJ+a/q +LDb1jQXLd5Cwu3QqYTBZ61qDTqoUWaZQzDlcNGE9V7PZ3fxVGEQg4N3o+gQK5RybwMj 0gdpVO4f7acOTHF2UP7Nz3r4pxrKybndP7iB32zKdXpELP77atkrCH3AJ3P3YIwHR8Xd 9ruQ== X-Gm-Message-State: AOUpUlGgPRUFHCg14Z1wYmGSGG5fba4+/JNVACG+uzTdhM7iIlB9PVAY gLciXTdcrUcetVu/vrAJ57gmgwklikwwGscPGrMm X-Google-Smtp-Source: AAOMgpeGFnCLW3ys/646NwPCUNULVxMfP4CBu85pNY6kY9ApNw2agW9VxXsllT2NmWaMV+WuvsqN/zD9hAV1Gcv29aI= X-Received: by 2002:a6b:d90d:: with SMTP id r13-v6mr8752055ioc.247.1532303321731; Sun, 22 Jul 2018 16:48:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:35c8:0:0:0:0:0 with HTTP; Sun, 22 Jul 2018 16:48:21 -0700 (PDT) In-Reply-To: References: From: Emad Omara Date: Sun, 22 Jul 2018 16:48:21 -0700 Message-ID: To: Sean Turner Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000002ec9ac05719f2b5a" Archived-At: Subject: Re: [MLS] wg-materials GH repo X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 23:48:46 -0000 --0000000000002ec9ac05719f2b5a Content-Type: text/plain; charset="UTF-8" Great! Thanks Katriel and Sean On Sun, Jul 22, 2018 at 4:35 PM, Sean Turner wrote: > All, > > Katriel was nice enough to make a wg-materials GH repo here: > https://github.com/mlswg/wg-materials > > I have uploaded the ietf101 materials for posterity sake. > > I have also uploaded the ietf102 materials minus the minutes; Matt Miller > sent them to Nick and I, but we need to review them first before posting > (should be done next week). > > spt > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000002ec9ac05719f2b5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great! Thanks Katriel and Sean

On Sun, Jul 22, 2018 at 4:35 PM, Se= an Turner <sean@sn3rd.com> wrote:
All,

Katriel was nice enough to make a wg-materials GH repo here:
https://github.com/mlswg/wg-materials

I have uploaded the ietf101 materials for posterity sake.

I have also uploaded the ietf102 materials minus the minutes; Matt Miller s= ent them to Nick and I, but we need to review them first before posting (sh= ould be done next week).

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

--0000000000002ec9ac05719f2b5a-- From nobody Mon Jul 23 07:14:42 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 5556D130DDD for ; Mon, 23 Jul 2018 07:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdhrZqPb2c5k for ; Mon, 23 Jul 2018 07:14:33 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A72B130F01 for ; Mon, 23 Jul 2018 07:14:33 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id i12-v6so1385094oik.2 for ; Mon, 23 Jul 2018 07:14:33 -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=ttsr4JfWVUg35CkBIxRRzUWBya8JYRK3M67asU5u9CM=; b=Gxbp4YElXIVYXDWEeuMyaH9PPzlXV0ybPKjKyF4IDt4A7da1pzHxd7Tkxl5yC2pP1I osA6NKTsx0lRbg3RlticVM8usxEZ5wJj6hdUUzOu8ONw1Dl3GjIn155CfhHPeKiTErGW ru+iutlWyY+qJMQQJwkbjvcXQpprsHiaF37XBp/sgfsLbW3EKKK7GxxnuBLV0tWcAaHA V0TWD6u2LRzdE2LK86yp/fFsJzX8hSjh0AB1UaphzJu6xEvA4n+bdjCt7qMDcXqKz0dS ZzlcznXf1AtVsav0uwXsD36cWq4fnZq7QzOfo57WRXFniAV30TrPgtayGaiAv98JgFuQ 3XFw== 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=ttsr4JfWVUg35CkBIxRRzUWBya8JYRK3M67asU5u9CM=; b=s42Rn5wpUPh3O9/cMOpGasdxwrpni23/zB/jb1YG7+MzVQBdEzf0Y9QJZe/WR+XF1o 1EedH1FPdaCa+nHgZc0838GD4znkblNn+KcMdJ0pvuIXl9M6ArP442hS857csmk3flZi 0AOgUVZ4fyBWu4kTsx5NzDL9OcDbgfIiojhnn19Ie1ZflhL73TtkrJdmqaVWnGPP1vkT /Pk7cM4cdW7uvBJJBb/8GWGmQTxTU+hBDUanII1xifo1kuHCGuEx/kCWWeJFR3NOG97I OU65u9q/9C2Axz3zN7tFWqiE8Ow9rMGAn3oPrZrI815wStAZxSidzGSpkk3KPFKdclOY 2k6w== X-Gm-Message-State: AOUpUlEHFlV8kUs7sQ54QHJSBHQlWiY8CuW6LJifF3LaQym9398KdU0H fAWTUzLpdaJeh5TgeoUMTyN8Y08NVQx+oizYgveNbw== X-Google-Smtp-Source: AAOMgpf4w6T7CrNy3tOdD6Cu1FBJQ47LU8ijusIO6V5Jh88hoaa2WZiibff+9b/4aeaq8Lk+ldoC8kGtei2W2jDUnD4= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr8173430oib.155.1532355272718; Mon, 23 Jul 2018 07:14:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 23 Jul 2018 10:14:21 -0400 Message-ID: To: emadomara=40google.com@dmarc.ietf.org Cc: Sean Turner , mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000b346c60571ab43f1" Archived-At: Subject: Re: [MLS] wg-materials GH repo X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 14:14:40 -0000 --000000000000b346c60571ab43f1 Content-Type: text/plain; charset="UTF-8" Sean: Is the idea for the documents to go in repos under that org once they're adopted? On Sun, Jul 22, 2018 at 7:48 PM Emad Omara wrote: > Great! Thanks Katriel and Sean > > On Sun, Jul 22, 2018 at 4:35 PM, Sean Turner wrote: > >> All, >> >> Katriel was nice enough to make a wg-materials GH repo here: >> https://github.com/mlswg/wg-materials >> >> I have uploaded the ietf101 materials for posterity sake. >> >> I have also uploaded the ietf102 materials minus the minutes; Matt Miller >> sent them to Nick and I, but we need to review them first before posting >> (should be done next week). >> >> spt >> _______________________________________________ >> 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 > --000000000000b346c60571ab43f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sean: Is the idea for the documents to go in repos un= der that org once they're adopted?

On Sun, Jul 22, 2018 at 7:48 PM Emad Omara <= emadomara=3D40google.com@dma= rc.ietf.org> wrote:
Great! Thanks Katriel and Sean

On Sun, Jul 22, 2018 at 4:35 PM, Sean Turne= r <sean@sn3rd.com> wrote:
All= ,

Katriel was nice enough to make a wg-materials GH repo here:
https://github.com/mlswg/wg-materials

I have uploaded the ietf101 materials for posterity sake.

I have also uploaded the ietf102 materials minus the minutes; Matt Miller s= ent them to Nick and I, but we need to review them first before posting (sh= ould be done next week).

spt
_______________________________________________
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
--000000000000b346c60571ab43f1-- From nobody Mon Jul 23 07:34: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 5BDBE130EA1 for ; Mon, 23 Jul 2018 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70I7-qfGpd4x for ; Mon, 23 Jul 2018 07:34:11 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6C5130DC0 for ; Mon, 23 Jul 2018 07:34:11 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id k81-v6so1492154oib.4 for ; Mon, 23 Jul 2018 07:34:11 -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=LJPTqaZlfM6e/6PSvq1UfZjQWP9KjhoQSWDdybmDjU4=; b=omI/HuTVCzhA1Vk8Zp7CLmaOTSpAYsYC5WzWNpwgODZLtsoRHbBlsJ6rqx0o8HKdMq PmazIWhukVVgm1+w0api5q0U4uK/lVye21fFQT2T0Vhty0ICxM8RHwUr7e0uyqe7IjnU +UMKZOkv8zZWngI/Ud08dweRiuoykHhlsK2nNeDJSvO3SN+y46i2fjWyC+4CaD2FAjCh TzqxMGMy62GU2ByMh7N3eSXBFRGIWbCKocKUq4Z+L+7TR1aXnNshwUdpJx3kscW3HjoZ r3E81VkDqRgFYLdIR1UMnc/YXpFV1SgK7bTC+iYTsMWWTCf/3i5wXHEc8xeWnRyEcgUm jT6g== 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=LJPTqaZlfM6e/6PSvq1UfZjQWP9KjhoQSWDdybmDjU4=; b=trUMLGdjbI4432g23FzIBGpcARm7uksE0XKlX36optchg+M4RzRFMaq8u53Bl990Ai L6APgzYbVHTpM4+piWpwspANdo+Cfn1Sb4iJziRR+cn14tLQ9LhwuJdboVms0763AiN0 avTqVX7hV4sB6ynWcNvI0qvJ9xrwSTH588Z5tOuaFh7Ozhn6coy9T+mRYq3jo3WWN5U2 +zLUbtilyUTx9SOb3N8YGq3ulbhEH02oeduxiDknltbv0ueorulYtQvwO6ShdnU1m/Q+ WKZy5GriNxFsPGS1CJ4kAQEpFZccTfsk5I7GbCF6ZMCw0zogBgfRPLhnD29246R51PtE 385Q== X-Gm-Message-State: AOUpUlEKnRbPoxinURQPEuHbXoGak2/RAvSmBP6atEohhOhj3vsJ12By AQmvhvzqj/oWFoMaaWHvL+Zja//BQEqBMU9ASJ4KMA== X-Google-Smtp-Source: AAOMgpfPN754EU7RbiMVqtbEkV/hGDh6Tv99PJa+tU01KKmGSCKVDYJKelZoadghk76KgPlmtcr7RiieFTiUpw7ktUQ= X-Received: by 2002:aca:fc94:: with SMTP id a142-v6mr8117002oii.29.1532356450901; Mon, 23 Jul 2018 07:34:10 -0700 (PDT) MIME-Version: 1.0 References: <87va9ax422.fsf@fifthhorseman.net> <1532084538.425728.1447174816.79181C11@webmail.messagingengine.com> <5C3272FE-22C9-44E2-AAAA-8F96206293F9@fb.com> <87a7qlwa7p.fsf@fifthhorseman.net> In-Reply-To: <87a7qlwa7p.fsf@fifthhorseman.net> From: Richard Barnes Date: Mon, 23 Jul 2018 10:33:59 -0400 Message-ID: To: Daniel Kahn Gillmor Cc: Jon Millican , Katriel Cohn-Gordon , mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000ecf3220571ab89b1" Archived-At: Subject: Re: [MLS] key update guidance X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 14:34:15 -0000 --000000000000ecf3220571ab89b1 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 20, 2018 at 11:25 PM Daniel Kahn Gillmor wrote: > On Fri 2018-07-20 12:30:07 +0000, Jon Millican wrote: > >> On 20 Jul 2018, at 12:03, Katriel Cohn-Gordon wrote: > >> > >> This could lead to confusing transcripts if one client accepts a > >> message (say it has clock skew) and another doesn't, but I think this > >> is no worse than a network adversary which drops a message. > > > > This could perhaps be server assisted? I.e. the server should be > > cooperative and force updates at appropriate times, but clients will > > ultimately enforce it if the server fails to do so. > > That would oblige us to expose the fact of keying updates (and possibly > the keying material itself) to the DS, right? what advantage would that > have? > I don't think necessarily requires exposing the fact that an update has happened to the DS. The DS could simply tell the group, "Here is a window for X to update", without being able to know whether X actually did update, inside or outside that window. This would only become an issue if the *only* way you could update was if the DS opened a window for you. Returning to the original question: I'm going to push back on the notion that this protocol needs to enable endpoints to communicate their expectations about update frequency. That seems like metadata that could be negotiated at a different layer. By way of analogy, TLS peers don't negotiate when to send KeyUpdate (which is not quite the same, but still). The space of things that are specifically germane to MLS is fairly bounded, something like: * Update provides the PCS boundaries w.r.t. the sender * It is thus important for all nodes to regularly send Update messages, even they are not otherwise transmitting * However, receiving Update messages imposes a computational burden on receivers, especially in large groups * Applications using MLS MUST ensure that members of a group regularly send Update messages, independent of other transmission schedules * Each endpoint SHOULD send an Update no less frequently than once per day * Updates SHOULD be limited to a level that maintains an acceptable burden on receivers * If Updates need to be limited, applications SHOULD prioritize updates from members that have updated least recently That is, the precise update schedule needs to be decided by the application (possibly involving some negotiation), but we can (1) mandate that an update schedule exists and (2) recommend some bounds on what the schedule looks like. --Richard > > --dkg > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000ecf3220571ab89b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Jul 20, 2018 at 11:25 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Fri 2018-07-20 12:30:07 +0000, Jon Millican wrote: >> On 20 Jul 2018, at 12:03, Katriel Cohn-Gordon <me@katriel.co.uk> wrote:
>>
>> This could lead to confusing transcripts if one client accepts a >> message (say it has clock skew) and another doesn't, but I thi= nk this
>> is no worse than a network adversary which drops a message.
>
> This could perhaps be server assisted? I.e. the server should be
> cooperative and force updates at appropriate times, but clients will > ultimately enforce it if the server fails to do so.

That would oblige us to expose the fact of keying updates (and possibly
the keying material itself) to the DS, right?=C2=A0 what advantage would th= at
have?

I don't think necessarily req= uires exposing the fact that an update has happened to the DS.=C2=A0 The DS= could simply tell the group, "Here is a window for X to update",= without being able to know whether X actually did update, inside or outsid= e that window.=C2=A0 This would only become an issue if the *only* way you = could update was if the DS opened a window for you.

Returning to the original question: I'm going to push back on the not= ion that this protocol needs to enable endpoints to communicate their expec= tations about update frequency.=C2=A0 That seems like metadata that could b= e negotiated at a different layer.=C2=A0 By way of analogy, TLS peers don&#= 39;t negotiate when to send KeyUpdate (which is not quite the same, but sti= ll).

The space of things that are specifically ger= mane to MLS is fairly bounded, something like:

* U= pdate provides the PCS boundaries w.r.t. the sender
=C2=A0 * It i= s thus important for all nodes to regularly send Update messages, even they= are not otherwise transmitting
=C2=A0 * However, receiving Updat= e messages imposes a computational burden on receivers, especially in large= groups
* Applications using MLS MUST ensure that members of = a group regularly send Update messages, independent of other transmission s= chedules
=C2=A0 * Each endpoint SHOULD send an Update no less fre= quently than once per day
=C2=A0 * Updates SHOULD be limited to a= level that maintains an acceptable burden on receivers
=C2= =A0 * If Updates need to be limited, applications SHOULD prioritize updates= from members that have updated least recently

That is, the precise update schedule needs to be decided by the applicatio= n (possibly involving some negotiation), but we can (1) mandate that an upd= ate schedule exists and (2) recommend some bounds on what the schedule look= s like.

--Richard

=C2= =A0

=C2=A0 =C2=A0 --dkg

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000ecf3220571ab89b1-- From nobody Mon Jul 23 08:40: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 EF8CD130EDF for ; Mon, 23 Jul 2018 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irksan9CwriM for ; Mon, 23 Jul 2018 08:40:42 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A253E130EC6 for ; Mon, 23 Jul 2018 08:40:42 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id q11-v6so1882607oic.12 for ; Mon, 23 Jul 2018 08:40:42 -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=0yB7SfHJEYDt8uPPSnp6KpsphHgNb0lMnPRuuKAbsjg=; b=1nIBAwrs33iWpac0zMUOK3EO6va6YTdReGq27MO5H0gEIoYlYtHCet1HmLvGa4DYlL lkBi1//z9kybCvHVKG6d0E9pVqeCl6KjE2Xw66r7VdwbFXQ3P/fRufm+saO7tmCGxEoS w550wD8zEqmFKiRXMvEwEsIgCt8m3YE3IQuKKTYUJ/kfvBEplTT33vxVegMMB1vXQjpQ BzzNAni/NyUEwavCgGQju3uJMkYZV26cPYam/dMa0eMCBFsc1nbRl/A7zg6L/7M+6r6L CfKt6YhzO1hFbZZxC4BMkfvSxdI0FWDhWHQPi4a2lSv0Ta43zVniq2ZS3ucjpDxsAvrK RYIA== 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=0yB7SfHJEYDt8uPPSnp6KpsphHgNb0lMnPRuuKAbsjg=; b=eA/tV47xlXrTc6cs00hsx2LLlKzQZRZsY9X0XCWP6oX3cqJ6svvFAQter8Ai3HfjuO 4i2jLqKU+qvCioSAtTloVMMjx4qk9j7qOg06epkYVNYpKDdPz6LuZHzKet3hw+QRRy7Y vvdU7O6FtHx4IVRyUElZ9VVN1gUVpyoMEiJlQs7kY9G1AuiSUmDkKocZu3IU7CFDjpV6 FrfELJZwuFx+pM+FcyYK6UmkrmlroypjaOeDlTctP7azAQ7O+CqBQ/CNVn7deyvtg3SB UES3jkIrV3kGVoI2HFQiBbEvzQ+gypYpiPUTW+uOkV4p5PNnGht/l1e1ArM5MkpW5bxZ ITFQ== X-Gm-Message-State: AOUpUlFHBwCKesi01rw5sFyLwfKCvjGH5NxpAWl/zdQWMgu7HL0zKJVC 1Nb9uDtVQebLflpVVO3yZJ8WlMOTB2h+E/GUllJD1ngsWQQ= X-Google-Smtp-Source: AAOMgpfPJI9M5JtfODOV4LzPMhSiCsp0LRpMeazvKgf8lctX1Yq9/S0sUcN5CcPvMV0dtaXWGD+HjfNiIuKc2RTAvJs= X-Received: by 2002:aca:ebcc:: with SMTP id j195-v6mr9238219oih.298.1532360441563; Mon, 23 Jul 2018 08:40:41 -0700 (PDT) MIME-Version: 1.0 References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> In-Reply-To: From: Richard Barnes Date: Mon, 23 Jul 2018 11:40:29 -0400 Message-ID: To: Eric Rescorla Cc: Daniel Kahn Gillmor , mls@ietf.org, Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary="000000000000c9a1880571ac77ed" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 15:40:45 -0000 --000000000000c9a1880571ac77ed Content-Type: text/plain; charset="UTF-8" On Fri, Jul 20, 2018 at 11:02 PM Eric Rescorla wrote: > > > On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor < > dkg@fifthhorseman.net> wrote: > >> On Thu 2018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote: >> > On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor >> > wrote: >> >> >> >> 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. >> >> >> >> 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) >> > >> > What about "content" and "keying" messages as new names? >> >> I'm maybe a little reluctant to use "content", because it seems too >> generic, and too allusive to the elusive "content/metadata" boundary. >> But i'd be fine with "application" and "keying" as the nomenclature. >> >> But I'm more interested in what people think about protecting these >> messages (or even the distinction between the two categories of message) >> from the DS itself. Is there a reason that we need to expose to the DS >> that keying updates are happening? >> > > I think it would be better if generally we did not. > I agree with the inclination here, but I think it's going to be difficult given some other requirements, especially around UserAdd / new devices joining without invitation. For example: 1. MLS needs to operate asynchronously, e.g., allowing a UserAdd / new device when all other members are offline 2. A new joiner is going to be able to authenticate the membership of the group before it transmits If we're going to enable both of those, then we're going to need whatever information is used for authentication to be cached somewhere that is reliably online. And that information can't be encrypted, since you don't know anything a priori about what new device might show up. (Note TLS is in a different posture here, since it is (1) online and (2) two-party.) Contrapositively, if we're going to have a handshake that the DS can't read, we're going to need to relax one of the two above requirements (possibly others; not claiming to be comprehensive). For example: A. If you disallow UserAdd and thus require all members of the group to be added via GroupAdd, then you can encrypt handshake messages just fine. Even if you need to access them for authentication, you could arrange some scheme of passing encryption keys to new members. B. Even with UserAdd, you can make a key-passing scheme work as long as you're willing to say that new participants can't authenticate the roster until someone wakes up and sends them the handshake decryption key. That would offer new devices the choice of either transmitting without knowing the roster or waiting to transmit. I don't really see how you make a reasonable "new device" experience without UserAdd, so if we're going to make a change here, it will probably have to be in the vein of (B). To brief notes to close: - In case it's not obvious to people, there's no point to padding handshake messages unless they're encrypted. - What's with the hate over "handshake" and "application"? It's the same distinction that TLS makes. --Richard > > -Ekr > > >> --dkg >> >> _______________________________________________ >> 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 > --000000000000c9a1880571ac77ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , Jul 20, 2018 at 11:02 PM Eric Rescorla <ekr@rtfm.com> wrote:


O= n Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor <<= a href=3D"mailto:dkg@fifthhorseman.net" target=3D"_blank">dkg@fifthhorseman= .net> wrote:
On Thu 2= 018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote:
> On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor
> <dkg@fif= thhorseman.net> wrote:
>>
>> In today's session, there seemed to be an open question that w= asn't
>> explicitly addressed, so i wanted to raise it on the list.
>>
>> for lack of a better term, we're dividing MLS messages into >> "application" messages and "handshake" message= s.=C2=A0 (i think we need
>> a better term for "handshake", but i'll use it here = for consistency with
>> the current discussion)
>
> What about "content" and "keying" messages as new = names?

I'm maybe a little reluctant to use "content", because= it seems too
generic, and too allusive to the elusive "content/metadata" bound= ary.
But i'd be fine with "application" and "keying" as = the nomenclature.

But I'm more interested in what people think about protecting these
messages (or even the distinction between the two categories of message) from the DS itself.=C2=A0 Is there a reason that we need to expose to the D= S
that keying updates are happening?

I th= ink it would be better if generally we did not.

I agree with the inclination here, but I think= it's going to be difficult given some other requirements, especially a= round UserAdd / new devices joining without invitation.=C2=A0 For example:<= /div>

1. MLS needs to operate asynchronously, e.g., allo= wing a UserAdd / new device when all other members are offline
2.= A new joiner is going to be able to authenticate the membership of the gro= up before it transmits

If we're going to enabl= e both of those, then we're going to need whatever information is used = for authentication to be cached somewhere that is reliably online.=C2=A0 An= d that information can't be encrypted, since you don't know anythin= g a priori about what new device might show up.

(N= ote TLS is in a different posture here, since it is (1) online and (2) two-= party.)

Contrapositively, if we're going to ha= ve a handshake that the DS can't read, we're going to need to relax= one of the two above requirements (possibly others; not claiming to be com= prehensive).=C2=A0 For example:

A. If you disallow= UserAdd and thus require all members of the group to be added via GroupAdd= , then you can encrypt handshake messages just fine.=C2=A0 Even if you need= to access them for authentication, you could arrange some scheme of passin= g encryption keys to new members.

B. Even with Use= rAdd, you can make a key-passing scheme work as long as you're willing = to say that new participants can't authenticate the roster until someon= e wakes up and sends them the handshake decryption key.=C2=A0 That would of= fer new devices the choice of either transmitting without knowing the roste= r or waiting to transmit.

I don't really see h= ow you make a reasonable "new device" experience without UserAdd,= so if we're going to make a change here, it will probably have to be i= n the vein of (B).

To brief notes to close:

- In case it's not obvious to people, there'= s no point to padding handshake messages unless they're encrypted.
<= /div>

- What's with the hate over "handshake&qu= ot; and "application"?=C2=A0 It's the same distinction that T= LS makes.

--Richard
=C2=A0
=
=

-Ekr


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

_______________________________________________
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
--000000000000c9a1880571ac77ed-- From nobody Mon Jul 23 08:43:04 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 1E5A8130F03 for ; Mon, 23 Jul 2018 08:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5PSOwNgPnsa for ; Mon, 23 Jul 2018 08:43:01 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 E5B89130DF5 for ; Mon, 23 Jul 2018 08:43:00 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id v8-v6so1924757oie.5 for ; Mon, 23 Jul 2018 08:43:00 -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=jlJ0L64cpQqJN8WEz6j2l01drSmb/jvLuQD48/Hp2SY=; b=RTbSkGA9oHRutAhdmEHgHh5c2O5ptXenXpywXaixlNkh+qPbkHNqDxaEfHVjeqBYHt UTxTSgyoe67gO3E/Dr3aW06sOO6rZxqg3eF7OB016qVlcSUmhuSjD0LW+1M/Mo7Y+7Cb 1VE+zYip3Jj85jdXpDqHxgWQ33TQOEu5sCOlDT1xVZsiHfICI0BEl8fFdwft+Zm++6RM Vols+bDFjEBfKk4HcmAFHBlF0cfX925PGSLjFbqBJ5fmQ0HwTYhRv8tf0NTXQRSibIzm wgB51ioFHAv6rWbCD2zeWIiqvQobDHPT2nCS3AvbRLCDt/noAUOQv8jZeTT4+nOekmVe uFmg== 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=jlJ0L64cpQqJN8WEz6j2l01drSmb/jvLuQD48/Hp2SY=; b=QCiZh5t8zSpAKv0Np+IGyd6nGaY9R/GhW7kGCNLZMtRtK13Hwf7R3XAAwZcGryczU0 9zmtTy4d4QBc7yjUxKBFz+qT1wa363XHxvmCa5NlugcuKzyQqJokK70yFsHjAK5VKUpW glO3Z87rS8uExmJAvB/cuNHfYI4d3Ev5O5HSFVzvn9bvO1lgWedHBsjuD5b6Ob70XLwR P+rWk0yaMrrbY/Y15HjqoNj3o3UYQOFQuzOnNenLFQB+m/0Kg7U1hZQ8W+4OBG18WMgy mGh+iza56q4TaTo41ofQSo8U0hbTRi9SgllfxVhs8A+5Ld029W5kG9F01VpY7hxNoO+E FW7A== X-Gm-Message-State: AOUpUlEY7RWQjK6vXCCw5WuY050V7TPHIEFuksYzVSofo678dMgZwNoU U5MOilOArro08p+AkWCLkFngkLlDD52YKQWgxdr5rw== X-Google-Smtp-Source: AAOMgpcK6OVTTTmqZhQyhtXq0UHFKxg2URny2tIHMizK0Lic0ksPxlZdV/+s7hTcwbFDi4Pwsftqf1tH4WcWl4DjPG4= X-Received: by 2002:aca:4994:: with SMTP id w142-v6mr8485064oia.114.1532360580184; Mon, 23 Jul 2018 08:43:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 23 Jul 2018 11:42:49 -0400 Message-ID: To: ssahib@salesforce.com Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000000cd1d50571ac80ba" Archived-At: Subject: Re: [MLS] Enumeration of failure modes in protocol draft X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 15:43:03 -0000 --0000000000000cd1d50571ac80ba Content-Type: text/plain; charset="UTF-8" This is a good think to keep an eye on, but we'll probably be more effective at addressing it once we have the protocol and its flows more nailed down. I expect these sorts of cases will also come up during interop testing. On Fri, Jul 20, 2018 at 4:20 AM Shivan Sahib wrote: > There was some talk at the hackathon on whether we should have a section > in the protocol draft about things that are currently 'undefined'. For > example, what happens in the GroupAdd case where we're adding C to a group > containing A and B, if A and B call state.add(C) but state.init() fails for > C. > > It would be worthwhile to consider general ways in which things could go > wrong and mention recovery mechanisms in the draft. > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000000cd1d50571ac80ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a good think to keep an eye on, but we'll prob= ably be more effective at addressing it once we have the protocol and its f= lows more nailed down.=C2=A0 I expect these sorts of cases will also come u= p during interop testing.

On Fri, Jul 20, 2018 at 4:20 AM Shivan Sahib <ssahib@salesforce.com> wrote:
There was some talk at the hacka= thon on whether we should have a section in the protocol draft about things= that are currently 'undefined'. For example, what happens in the G= roupAdd case where=C2=A0we're adding C to a group containing A and B, i= f A and B call state.add(C) but state.init() fails for C.

It would be worthwhile to consider general ways in which things could go = wrong and mention recovery mechanisms in the draft.
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000000cd1d50571ac80ba-- From nobody Mon Jul 23 08:49: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 83613130F08 for ; Mon, 23 Jul 2018 08:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVI-Xprwsjg2 for ; Mon, 23 Jul 2018 08:49:44 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10486130EDB for ; Mon, 23 Jul 2018 08:49:44 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id q5-v6so952554ljh.12 for ; Mon, 23 Jul 2018 08:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7X6jLf0rODW3B7MawcjoZvKbnOq9CWC8U+evzlG5lRE=; b=nYKkz4lEnpsqKf/pDW9yl+RkAV9M5LgD/75Hygl4305t9egH0zHf3NPWH33RArPAjX 9uiHt0uV2PoPGkPvnlygHNN/3ID51+FJyWGxpuHob7UXc1giv2HNvdh8FdavHUqZwxWP sC0WmPHAM4c7ZYBjEQ37IKthe+CVv9EldUL0bnzs1opEEo8L1GDLTfyvkeTh/9LrCvTa W4c95poZOGMh8SByrCZwEOUZ5QZ1daO67VZ1o07K+dyb44MB2pW/KL0AI9sNDHytpJ/4 qghsAGUArSM3Z8xI1XxCqrwST8FY+OSBcx9lP02IjcaOAjJLC6V2KTlDToxaP8wUpiPc IE0w== 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=7X6jLf0rODW3B7MawcjoZvKbnOq9CWC8U+evzlG5lRE=; b=DSRxCauoNP53xCzefyhdxfGSqxLtmWr5/moMRlebQppuJLccy7XTbqSRgE/VBvUuYp +hKVToM/tyKk+HGAnJYfvRmxX8AbHAb0giQebcjxVV91eck8oCHBqnvo0dXtxDrvCVML NTpXW8ICVzv2UAJKc7p5UMb3SO4aOqbN5E0R+x1FKAXWeKAEuoF80+I2O2AcaRe4D1BT STKaucWjOLy2mBnbiGS2pvJMyAeMu6nFkyGz/o2Ql5205yYvSku+bQD6HkKhAiDDLyPZ KiLxAKz7TJEwgDnAjAO6BBZU1YLC5nJ5r8f0ytFhAfHEn8vYO4AslLQJ8V7f0PZaYSxM 2/gw== X-Gm-Message-State: AOUpUlH3NTGp4mJp027hkwRVldAyQzx2mncqlx7ro/xHd2haZ0NMARQB odgebfzwGYwa6PnSQ+OESuaGnffcvLpYi/MNP1nvADMc X-Google-Smtp-Source: AAOMgpdltdeh5xOQTn5Ua5cyeOko6Eh2WcEOqhv67NaulilziX8mutU7H24xxIsb1LpjcD+MqkUUyhiOI2eEw+FMh/M= X-Received: by 2002:a2e:9c82:: with SMTP id x2-v6mr9769345lji.131.1532360982357; Mon, 23 Jul 2018 08:49:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 08:49:01 -0700 (PDT) In-Reply-To: References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> From: Eric Rescorla Date: Mon, 23 Jul 2018 08:49:01 -0700 Message-ID: To: Richard Barnes Cc: Daniel Kahn Gillmor , mls@ietf.org, Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary="0000000000000579aa0571ac98fe" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 15:49:47 -0000 --0000000000000579aa0571ac98fe Content-Type: text/plain; charset="UTF-8" On Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes wrote: > > > On Fri, Jul 20, 2018 at 11:02 PM Eric Rescorla wrote: > >> >> >> On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor < >> dkg@fifthhorseman.net> wrote: >> >>> On Thu 2018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote: >>> > On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor >>> > wrote: >>> >> >>> >> 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. >>> >> >>> >> 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) >>> > >>> > What about "content" and "keying" messages as new names? >>> >>> I'm maybe a little reluctant to use "content", because it seems too >>> generic, and too allusive to the elusive "content/metadata" boundary. >>> But i'd be fine with "application" and "keying" as the nomenclature. >>> >>> But I'm more interested in what people think about protecting these >>> messages (or even the distinction between the two categories of message) >>> from the DS itself. Is there a reason that we need to expose to the DS >>> that keying updates are happening? >>> >> >> I think it would be better if generally we did not. >> > > I agree with the inclination here, but I think it's going to be difficult > given some other requirements, especially around UserAdd / new devices > joining without invitation. For example: > > 1. MLS needs to operate asynchronously, e.g., allowing a UserAdd / new > device when all other members are offline > 2. A new joiner is going to be able to authenticate the membership of the > group before it transmits > > If we're going to enable both of those, then we're going to need whatever > information is used for authentication to be cached somewhere that is > reliably online. And that information can't be encrypted, since you don't > know anything a priori about what new device might show up. > I think this is too nihilistic on too fronts: 1.Just because some group operations can't be hidden doesn't mean that none of them can. 2. I'm not sure why you are assuming that MLS needs to operate asynchronously. Lots of systems operate on an "invite" model where one group member invites others. Clearly that member can send the invite information to the other member (though of course there are race conditions. - In case it's not obvious to people, there's no point to padding handshake messages unless they're encrypted. - What's with the hate over "handshake" and "application"? It's the same distinction that TLS makes. Don't look at me. -Ekr --0000000000000579aa0571ac98fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wr= ote:


On Fri, Jul 20, 2018 at = 11:02 PM Eric Rescorla <ekr@rtfm.com> wrote:


O= n Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor <<= a href=3D"mailto:dkg@fifthhorseman.net" target=3D"_blank">dkg@fifthhorseman= .net> wrote:
On Thu 2= 018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote:
> On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor
> <dkg@fif= thhorseman.net> wrote:
>>
>> In today's session, there seemed to be an open question that w= asn't
>> explicitly addressed, so i wanted to raise it on the list.
>>
>> for lack of a better term, we're dividing MLS messages into >> "application" messages and "handshake" message= s.=C2=A0 (i think we need
>> a better term for "handshake", but i'll use it here = for consistency with
>> the current discussion)
>
> What about "content" and "keying" messages as new = names?

I'm maybe a little reluctant to use "content", because= it seems too
generic, and too allusive to the elusive "content/metadata" bound= ary.
But i'd be fine with "application" and "keying" as = the nomenclature.

But I'm more interested in what people think about protecting these
messages (or even the distinction between the two categories of message) from the DS itself.=C2=A0 Is there a reason that we need to expose to the D= S
that keying updates are happening?

I th= ink it would be better if generally we did not.

I agree with the inclination here, but = I think it's going to be difficult given some other requirements, espec= ially around UserAdd / new devices joining without invitation.=C2=A0 For ex= ample:

1. MLS needs to operate asynchronously, e.g= ., allowing a UserAdd / new device when all other members are offline
=
2. A new joiner is going to be able to authenticate the membership of = the group before it transmits

If we're going t= o enable both of those, then we're going to need whatever information i= s used for authentication to be cached somewhere that is reliably online.= =C2=A0 And that information can't be encrypted, since you don't kno= w anything a priori about what new device might show up.
<= /blockquote>

I think this is too nihilistic on too front= s:

1.Just because some group operations can't = be hidden doesn't mean that none of them can.
2. I'm not sure why you are assuming that MLS needs to operate a= synchronously. Lots of systems operate on an "invite" model where= one group member invites others. Clearly that member can send the invite i= nformation to the other member (though of course there are race conditions.=


<= div>
- In case it's not obvious to people, there's no= point to padding handshake messages unless they're encrypted.

- What's with the hate over "handshake" = and "application"?=C2=A0 It's the same distinction that TLS m= akes.

Don't look at me.=
-E= kr
<= br>
--0000000000000579aa0571ac98fe-- From nobody Mon Jul 23 08:57: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 BE617126CC7 for ; Mon, 23 Jul 2018 08:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 06yLBvgyFDE1 for ; Mon, 23 Jul 2018 08:57:48 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 E80B6124D68 for ; Mon, 23 Jul 2018 08:57:47 -0700 (PDT) X-AuditID: 12074424-391ff700000035d9-eb-5b55fafae8b4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2B.3E.13785.AFAF55B5; Mon, 23 Jul 2018 11:57:46 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w6NFvjrg031743; Mon, 23 Jul 2018 11:57:46 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6NFvexu001548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Jul 2018 11:57:42 -0400 Date: Mon, 23 Jul 2018 10:57:40 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: Richard Barnes , mls@ietf.org, Joseph Lorenzo Hall , Daniel Kahn Gillmor Message-ID: <20180723155739.GU92448@kduck.kaduk.org> References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nrvvrV2i0wY6nlhat3Z+ZLFa8Psdu 8fbxIyaL7Qc2MltM7bN1YPWYs+g2o8fZ7nZWjyVLfjJ5TN44i8Vj8uM25gDWKC6blNSczLLU In27BK6MSYc/Mxbs5qro+vqApYFxCUcXIyeHhICJxP3Vs5i6GLk4hAQWM0kc3HaFHcLZyChx ZuU3dpAqIYGrTBIP1saC2CwCqhKrHr5gA7HZBFQkGrovM4PYIgIKEr/+nGABaWYW6GeUuL3o B1hCWMBaYv6zv2A2L9C6ey9es0FseM8ksXh/D1RCUOLkzCcsIDazgJbEjX8vgW7iALKlJZb/ AzuVUyBQ4sj200wgtqiAssTevkPsExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJusXJ iXl5qUW65nq5mSV6qSmlmxjBIe6isoOxu8f7EKMAB6MSD++Fb6HRQqyJZcWVuYcYJTmYlER5 X50CCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhvcQGlONNSaysSi3Kh0lJc7AoifPmLmKMFhJI TyxJzU5NLUgtgsnKcHAoSfD+/gnUKFiUmp5akZaZU4KQZuLgBBnOAzR8B0gNb3FBYm5xZjpE /hSjMce7o1MnMXP8eQ8khVjy8vNSpcR5s0FKBUBKM0rz4KaB0pRE9v6aV4ziQM8J8/IAk5YQ DzDFwc17BbSKCWiVaDLYqpJEhJRUA6PL2btNjiaTgs6ebuJ4UOb1L8NUj9fEx+/znEVL3Y7O yg4yXHv7/FKT6zvUFH+tTjzz5UuqS9g2wwjR7KM1VzY13PWNXhG/rr7b746kzPv1KscSqhaZ fV9dpJOyttgh0F4/88m7GZ+3J5voM0lPqHs9tadN+8nNzDcT585ayX5zzUkRFs4Ii0QlluKM REMt5qLiRAC/gnGALgMAAA== Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 15:57:50 -0000 On Mon, Jul 23, 2018 at 08:49:01AM -0700, Eric Rescorla wrote: > On Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes wrote: > > > 1. MLS needs to operate asynchronously, e.g., allowing a UserAdd / new > > device when all other members are offline > > 2. A new joiner is going to be able to authenticate the membership of the > > group before it transmits > > > > If we're going to enable both of those, then we're going to need whatever > > information is used for authentication to be cached somewhere that is > > reliably online. And that information can't be encrypted, since you don't > > know anything a priori about what new device might show up. > > > > I think this is too nihilistic on too fronts: > > 1.Just because some group operations can't be hidden doesn't mean that none > of them can. > 2. I'm not sure why you are assuming that MLS needs to operate > asynchronously. Lots of systems operate on an "invite" model where one > group member invites others. Clearly that member can send the invite > information to the other member (though of course there are race conditions. We're chartered to develop key establishment and message protocols with properties including: o Asynchronicity - Keys can be established without any two participants being online at the same time -Ben From nobody Mon Jul 23 09:00:34 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408F7130F15 for ; Mon, 23 Jul 2018 09:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFvBDMBiRGrD for ; Mon, 23 Jul 2018 09:00:30 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 1D5FD130E42 for ; Mon, 23 Jul 2018 09:00:30 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id p10-v6so999288ljg.2 for ; Mon, 23 Jul 2018 09:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d/LU/GN/vModTp7u3QFDiGl+mGy32TnUEp984XupQ9s=; b=IYRLM47KOUXsYYl7VKFLlF89e4qPtg5i6cv04dBlZeJ3yQiY9m7JW9tHts41zegbEi sYfMmvahfYHbBI0AE8eB74jWqmPQvPgqo5SC7ElUZ18Lmk4jiHoWL2WOfSFgWPs+MxoH rxHbtMXci4wL5WiRyDeKGygBjKK6iF/h06x33gL3WAYZ0dw6InC/95FwuZOOV9QZYB/y BNch/tLlKP6sXqHALGUqL5wXrVls/IVZhRABWLvJPioApqeJYkBIByuW3JsWKymPfvUS UoSVdaCmvAmTL8Ar0HTQKOS0GdfcMIgdHj2xVytYYTdUvcLN5FnSMLWozjwImmZXI2c7 pLQg== 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=d/LU/GN/vModTp7u3QFDiGl+mGy32TnUEp984XupQ9s=; b=GBpah25ZEH+k4mevgsSC4SCvhyJDeR5gav67SYgeKYEf8mrCJkq9jxAapSRQseYEQw X89cVk8ppNUqHIUmUSXv37416pcj+6zr31DCkLog+l8cRsPExQyQe5EOFdFDyjp3E5b+ 2xZGwvSMMkJhVWlJK1EBLoh45jers+FjIk3g6tV3TQ/riq4jZdFMOXcaigezQob2FDCO JkkS2yb1cemaH9zKLKhShO3JN+p4Q8bDvl7DxXt/ttv9VHv1BZCXnb6mht5fUwEDcTRX 0dLfvQKGGwNUq4yvzHxOkJ2mtTbaW/hv3Dex05dyLqO5RihP2M/yqhyFpUlaRoSKIzhb iBJg== X-Gm-Message-State: AOUpUlE5emV+jsvY0NMTxb8U5RWaNdLKT5jS/UqLc9lV3VCDnnmvBqhJ kfCE7ejhtPUeG9g0Gx5Pphe+uB8hO9OrRsp0SNrXnA== X-Google-Smtp-Source: AAOMgpddDspFzSRNeTKP5GOGoXqzmjfdqo62wf49LCbQ0pa2MnJxnh0PAzWimDWmiNkqNfJCKmoBSXoRDuOLtnsO29s= X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr8995866lja.151.1532361628407; Mon, 23 Jul 2018 09:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 08:59:47 -0700 (PDT) In-Reply-To: <20180723155739.GU92448@kduck.kaduk.org> References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> <20180723155739.GU92448@kduck.kaduk.org> From: Eric Rescorla Date: Mon, 23 Jul 2018 08:59:47 -0700 Message-ID: To: Benjamin Kaduk Cc: Richard Barnes , mls@ietf.org, Joseph Lorenzo Hall , Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary="000000000000876c450571acbef4" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:00:32 -0000 --000000000000876c450571acbef4 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 23, 2018 at 8:57 AM, Benjamin Kaduk wrote: > On Mon, Jul 23, 2018 at 08:49:01AM -0700, Eric Rescorla wrote: > > On Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes wrote: > > > > > 1. MLS needs to operate asynchronously, e.g., allowing a UserAdd / new > > > device when all other members are offline > > > 2. A new joiner is going to be able to authenticate the membership of > the > > > group before it transmits > > > > > > If we're going to enable both of those, then we're going to need > whatever > > > information is used for authentication to be cached somewhere that is > > > reliably online. And that information can't be encrypted, since you > don't > > > know anything a priori about what new device might show up. > > > > > > > I think this is too nihilistic on too fronts: > > > > 1.Just because some group operations can't be hidden doesn't mean that > none > > of them can. > > 2. I'm not sure why you are assuming that MLS needs to operate > > asynchronously. Lots of systems operate on an "invite" model where one > > group member invites others. Clearly that member can send the invite > > information to the other member (though of course there are race > conditions. > > We're chartered to develop key establishment and message protocols with > properties including: > > o Asynchronicity - Keys can be established without any > two participants being online at the same time > I should have said "user add". See above for how many protocols work. -Ekr > > -Ben > --000000000000876c450571acbef4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 23, 2018 at 8:57 AM, Benjamin Kaduk <<= a href=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu> wrote:
On Mon, Jul 2= 3, 2018 at 08:49:01AM -0700, Eric Rescorla wrote:
> On Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes <rlb@ipv.sx> wro= te:
>
> > 1. MLS needs to operate asynchronously, e= .g., allowing a UserAdd / new
> > device when all other members are offline
> > 2. A new joiner is going to be able to authenticate the membershi= p of the
> > group before it transmits
> >
> > If we're going to enable both of those, then we're going = to need whatever
> > information is used for authentication to be cached somewhere tha= t is
> > reliably online.=C2=A0 And that information can't be encrypte= d, since you don't
> > know anything a priori about what new device might show up.
> >
>
> I think this is too nihilistic on too fronts:
>
> 1.Just because some group operations can't be hidden doesn't m= ean that none
> of them can.
> 2. I'm not sure why you are assuming that MLS needs to operate
> asynchronously. Lots of systems operate on an "invite" model= where one
> group member invites others. Clearly that member can send the invite > information to the other member (though of course there are race condi= tions.

We're chartered to develop key establishment and message protoco= ls with
properties including:

o Asynchronicity - Keys can be established without any
two participants being online at the same time

I should have said "user add". See above for how many pro= tocols work.

-Ekr



-Ben

--000000000000876c450571acbef4-- From nobody Mon Jul 23 09:37:58 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4796129619 for ; Mon, 23 Jul 2018 09:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo7BeCKzHG9i for ; Mon, 23 Jul 2018 09:37:53 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5177129385 for ; Mon, 23 Jul 2018 09:37:52 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id d189-v6so2266663oib.6 for ; Mon, 23 Jul 2018 09:37:52 -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=CCjZUTYXB6VlIy1B+6PNBg53mBTnyaxbIHGEcJ4ppkQ=; b=JyOIWcX3i79zN2pDSokDMZ9O1kMVFOkp0EFUCCsQpoT7hz60DsAcgLPMPsZnRmqZjO rvbUZP8EI2Jkee6odRYAd0Z1wawKUjRwEEID941loZw+QImjtLKvxfZyucKpN3U7K3YF dHaSd3ISXGY2N+a8xMZiu/TvXg5dBcpvFWo5ELTmX3jSgGsqWcDyq5VCMo5xhWFQzLzj 97y5ydirgOgkVmqloX6BkomNrytfPJBdyedbOi1I5Sd3TntDbnQ8TDDBY2RoggNcVvxC QgfjTsyEUg3HlR2vOxhpQe7fu3EQ/SKIfzg2IHcTbu86l10qVXIuPCfKpLZ1Z9HS68lP 4xXg== 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=CCjZUTYXB6VlIy1B+6PNBg53mBTnyaxbIHGEcJ4ppkQ=; b=iBnpgsezZK5D1fJw+FqNB9CIv5QJJvHMqulRfUf9MKPqvRudAdzLNNGFwzMaCs1ZQc RzIfb6EPxF3fuTWtW1oiOhxplK6PeyPYYfiZZjZh4SxH9NaaTz/TqM5D/LrOkWHYqmal Q7d6cmTRo7OQdF97+K8yUfUPM7+r0B5dJQJsW9FomT05Gl8zPaLycCkYFcF2pkJhZHqA sqZjK7YGWiSDbwtzL57D1uCDP0bGa3I9XshYaa2iMQdIjjls3pOIeC+OhbDgu3ArHRlO oiOH0td8voStJTPyqzbICuHZ8WDLICU4evYwELqT7fko/GJSFP9Yj1P6iKU+eOSfHjl3 2rHA== X-Gm-Message-State: AOUpUlFS7+9gUoKdGOuesM082kR2WGDxc7+FX/Y38eHGZi4DqlN5fxDZ lwzsk+ItUqZcxeiy0EDU2ua6som1gZbkuGL4WCw7UaXWAZb90A== X-Google-Smtp-Source: AAOMgpcc1jmsYL6Ax9gir9bJrqPRsJrBBglKKxAewCX+9+XypiMxBtxk4mrixtGaj8mhKVwUux+PHtyUrKk4TkL4tpk= X-Received: by 2002:aca:f383:: with SMTP id r125-v6mr8813219oih.6.1532363872010; Mon, 23 Jul 2018 09:37:52 -0700 (PDT) MIME-Version: 1.0 References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> In-Reply-To: From: Richard Barnes Date: Mon, 23 Jul 2018 12:37:40 -0400 Message-ID: To: Eric Rescorla Cc: Daniel Kahn Gillmor , mls@ietf.org, Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary="0000000000004224b20571ad44e0" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:37:56 -0000 --0000000000004224b20571ad44e0 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 23, 2018 at 11:49 AM Eric Rescorla wrote: > > > On Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes wrote: > >> >> >> On Fri, Jul 20, 2018 at 11:02 PM Eric Rescorla wrote: >> >>> >>> >>> On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor < >>> dkg@fifthhorseman.net> wrote: >>> >>>> On Thu 2018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote: >>>> > On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor >>>> > wrote: >>>> >> >>>> >> 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. >>>> >> >>>> >> 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) >>>> > >>>> > What about "content" and "keying" messages as new names? >>>> >>>> I'm maybe a little reluctant to use "content", because it seems too >>>> generic, and too allusive to the elusive "content/metadata" boundary. >>>> But i'd be fine with "application" and "keying" as the nomenclature. >>>> >>>> But I'm more interested in what people think about protecting these >>>> messages (or even the distinction between the two categories of message) >>>> from the DS itself. Is there a reason that we need to expose to the DS >>>> that keying updates are happening? >>>> >>> >>> I think it would be better if generally we did not. >>> >> >> I agree with the inclination here, but I think it's going to be difficult >> given some other requirements, especially around UserAdd / new devices >> joining without invitation. For example: >> >> 1. MLS needs to operate asynchronously, e.g., allowing a UserAdd / new >> device when all other members are offline >> 2. A new joiner is going to be able to authenticate the membership of the >> group before it transmits >> >> If we're going to enable both of those, then we're going to need whatever >> information is used for authentication to be cached somewhere that is >> reliably online. And that information can't be encrypted, since you don't >> know anything a priori about what new device might show up. >> > > I think this is too nihilistic on too fronts: > > 1.Just because some group operations can't be hidden doesn't mean that > none of them can. > Every group operation is going to change the leaf key associated with an identity, so it's going to change the authentication information that a new joiner will need. At which point we're back in the soup. > 2. I'm not sure why you are assuming that MLS needs to operate > asynchronously. Lots of systems operate on an "invite" model where one > group member invites others. Clearly that member can send the invite > information to the other member (though of course there are race conditions. > The invite model is common, but not ubiquitous. With XMPP MUCs, for example, users can just show up uninvited. Maybe we don't want to support those cases, or we're OK making them not-async, but we should be deliberate about it. There are also use case that the invite model can't cover, namely where it's not possible for one of a user's devices (one member in your phrasing) to pass the necessary information to a new member. Old phone's dead / dropped in the ocean / on a different continent / etc. If you want to address that use case without UserAdd, you effectively need for the application to provide a "sync across user's devices" service. And it's not totally clear to me that that would be sufficient. For example, you might need to also require that the handshake encryption key be constant, so that a cached copy wouldn't go stale. --Richard > > > - In case it's not obvious to people, there's no point to padding > handshake messages unless they're encrypted. > > - What's with the hate over "handshake" and "application"? It's the same > distinction that TLS makes. > > Don't look at me. > > -Ekr > > --0000000000004224b20571ad44e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Jul 23, 2018 at 11:49 AM Eric Rescorla <ekr@rtfm.com> wrote:


O= n Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes <rlb@ipv.sx> wrote:<= br>


On Fri, Jul 20, 2018 at 11:02 PM Eric Res= corla <ekr@rtfm.com> wrote:

<= div class=3D"gmail_extra">
On Fri, Jul 20, 20= 18 at 7:58 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Thu 2018-07-19 13:39:1= 6 -0400, Joseph Lorenzo Hall wrote:
> On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor
> <dkg@fif= thhorseman.net> wrote:
>>
>> In today's session, there seemed to be an open question that w= asn't
>> explicitly addressed, so i wanted to raise it on the list.
>>
>> for lack of a better term, we're dividing MLS messages into >> "application" messages and "handshake" message= s.=C2=A0 (i think we need
>> a better term for "handshake", but i'll use it here = for consistency with
>> the current discussion)
>
> What about "content" and "keying" messages as new = names?

I'm maybe a little reluctant to use "content", because= it seems too
generic, and too allusive to the elusive "content/metadata" bound= ary.
But i'd be fine with "application" and "keying" as = the nomenclature.

But I'm more interested in what people think about protecting these
messages (or even the distinction between the two categories of message) from the DS itself.=C2=A0 Is there a reason that we need to expose to the D= S
that keying updates are happening?

I th= ink it would be better if generally we did not.

I agree with the inclination here, but = I think it's going to be difficult given some other requirements, espec= ially around UserAdd / new devices joining without invitation.=C2=A0 For ex= ample:

1. MLS needs to operate asynchronously, e.g= ., allowing a UserAdd / new device when all other members are offline
=
2. A new joiner is going to be able to authenticate the membership of = the group before it transmits

If we're going t= o enable both of those, then we're going to need whatever information i= s used for authentication to be cached somewhere that is reliably online.= =C2=A0 And that information can't be encrypted, since you don't kno= w anything a priori about what new device might show up.
<= /blockquote>

I think this is too nihilistic on too front= s:

1.Just because some group operations can't = be hidden doesn't mean that none of them can.

Every group operation is going to change the= leaf key associated with an identity, so it's going to change the auth= entication information that a new joiner will need.=C2=A0 At which point we= 're back in the soup.

=C2=A0
2. I'm not sure why you are= assuming that MLS needs to operate asynchronously. Lots of systems operate= on an "invite" model where one group member invites others. Clea= rly that member can send the invite information to the other member (though= of course there are race conditions.
<= div>
The invite model is common, but not ubiquitous.=C2=A0 Wi= th XMPP MUCs, for example, users can just show up uninvited.=C2=A0 Maybe we= don't want to support those cases, or we're OK making them not-asy= nc, but we should be deliberate about it.

Ther= e are also use case that the invite model can't cover, namely where it&= #39;s not possible for one of a user's devices (one member in your phra= sing) to pass the necessary information to a new member.=C2=A0 Old phone= 9;s dead / dropped in the ocean / on a different continent / etc.
=

If you want to address that use case without UserAdd, y= ou effectively need for the application to provide a "sync across user= 's devices" service.=C2=A0 And it's not totally clear to me th= at that would be sufficient.=C2=A0 For example, you might need to also requ= ire that the handshake encryption key be constant, so that a cached copy wo= uldn't go stale.

--Richard
= =C2=A0

=



- In cas= e it's not obvious to people, there's no point to padding handshake= messages unless they're encrypted.

- What= 's with the hate over "handshake" and "application"= ?=C2=A0 It's the same distinction that TLS makes.
=
Don't look at me.

-Ekr
<= font color=3D"#888888">
--0000000000004224b20571ad44e0-- From nobody Mon Jul 23 12:25: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 1F173130E8F for ; Mon, 23 Jul 2018 12:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] 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 5PfLecM5X5Xs for ; Mon, 23 Jul 2018 12:24:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7436912F1A6 for ; Mon, 23 Jul 2018 12:24:57 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7B6FFF99A; Mon, 23 Jul 2018 15:24:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EA35E205E2; Mon, 23 Jul 2018 15:24:52 -0400 (EDT) From: Daniel Kahn Gillmor To: Eric Rescorla , Richard Barnes Cc: mls@ietf.org, Joseph Lorenzo Hall In-Reply-To: <87sh49vk1r.fsf@fifthhorseman.net> References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> <87sh49vk1r.fsf@fifthhorseman.net> Date: Mon, 23 Jul 2018 15:24:52 -0400 Message-ID: <87pnzdvjp7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 19:24:59 -0000 On Mon 2018-07-23 15:17:20 -0400, Daniel Kahn Gillmor wrote: > On Mon 2018-07-23 08:49:01 -0700, Eric Rescorla wrote: >> - What's with the hate over "handshake" and "application"? It's the same >> distinction that TLS makes. apologies, i guess this should have been attributed to Richard Barnes, not to ekr. I blame confusion based on ekr's quoting style, but my response remains the same regardless of the origin of the question. --dkg From nobody Mon Jul 23 12:25:06 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 4651A12F1A6 for ; Mon, 23 Jul 2018 12:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] 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 qx3HEhJnzrgg for ; Mon, 23 Jul 2018 12:24:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751BA130DD9 for ; Mon, 23 Jul 2018 12:24:57 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 8724AF99B; Mon, 23 Jul 2018 15:24:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 551662036C; Mon, 23 Jul 2018 15:17:20 -0400 (EDT) From: Daniel Kahn Gillmor To: Eric Rescorla , Richard Barnes Cc: mls@ietf.org, Joseph Lorenzo Hall In-Reply-To: References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> Date: Mon, 23 Jul 2018 15:17:20 -0400 Message-ID: <87sh49vk1r.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 19:25:01 -0000 On Mon 2018-07-23 08:49:01 -0700, Eric Rescorla wrote: > - What's with the hate over "handshake" and "application"? It's the same > distinction that TLS makes. "handshake" is something that implies a meeting or a conversational setup. here, we're talking about ongoing key updates as well as membership changes. "handshake" also implies two parties (if there are three-party handshake protocols in the real world, i'm unaware of them). So for both those reasons, i think it's inappropriate for the MLS context. I've also argued already on this list that MLS should be *distancing* itself from TLS, not trying to mimic it. (I don't even think the name MLS is appropriate, and i think we should change it to something that doesn't sound like TLS) People that want a secure two-party protocol with well-understood security guarantees *should* use TLS, not whatever MLS turns out to be. I definitely want us to *discourage* people from using MLS where TLS would suit their use case better. Let's not try to make these protocols too analogous, lest we confuse people and encourage people to turn TLS into a multi-party scheme. --dkg From nobody Mon Jul 23 13:45:52 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D5C130DF0 for ; Mon, 23 Jul 2018 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lu399h0B3Rg for ; Mon, 23 Jul 2018 13:45:49 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 26797130E25 for ; Mon, 23 Jul 2018 13:45:49 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id j8-v6so1440541lfb.4 for ; Mon, 23 Jul 2018 13:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=osq00O7dAkax7ep6VYeTCaFHzc3SZB04290/FJIyEKA=; b=q49EPVoCuPshWqnqUKl9HnGE9KvioECcG80DzVqUtz7vrKLeAhAowWxP6hVMaQ7S2C cG2/IdahBCAuR1P0LM6Kjtipf+bi1DYxFxes7iFUz819xF1to35SPpqPakrHliR6KSsS uY7a4deu/PWN+7nUJqqJezKv1s7mDivt8X5WkP5dlQP0zRj2/T9zJzLfaQaKvDM+3xVR I0n+35hjNIWAd1Nx3dCu2D07u3rBCcuARJRGJEyNvCrBVqmFiR5/z1aI3m1S/tKoUFZ4 Qr9Lu56cbLyELJtfUnVyVhwhXN3R1GE7rMxUpThB2YX/0WxUJLghhGJQ0/7Ba5np1TOU a0gg== 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=osq00O7dAkax7ep6VYeTCaFHzc3SZB04290/FJIyEKA=; b=RyB5KJ9wKxB3ctY5MBZrB0VdOyZdXc3FglT/enHECVCzj5N+Hsv+m3HVFG/Jj30GBK nTao1hqihUGPRfg4SaHzipmR8JWOV6ob9THPoWDs3XudjjiekfzqEb83+7rBnW35SVjx qkSorqKOaFblOBCwmGdwoV6dcr5Bq6ibDsKR6wdhHtVWnFay1GB/NeGJ4+Ggo1S8g4Z9 zX5IT7yhW2tS4BeDPL/fgCSG/fPUUyezL+70CoxFANqsubCraS9Boe4pmP3APXaq/Ldm d5GSM83V1G+1rgp6dKTBXApjM/cAVt8VwynP/Rc3GmJDQXuniODMZn1YSlPZCQXIlcx5 V10w== X-Gm-Message-State: AOUpUlFdid2YksYQtVgnco91tbDDr4vR3Iq5/nmbWrL9x7oQ5gN1/TfE ZhmR9mMtBP8ppMZISIyrkiyLSUWUamhbQbOGOBjMEIoK X-Google-Smtp-Source: AAOMgpcP/uKSg9GUisBxFE7ysVnynkv7GVdl2nk78L6FAV4bKLTLpHKwJ311xPuGbjHWSyzCGIOBTJ8OeUbokFzBwYc= X-Received: by 2002:a19:db44:: with SMTP id s65-v6mr7936456lfg.109.1532378747408; Mon, 23 Jul 2018 13:45:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 13:45:06 -0700 (PDT) In-Reply-To: <87sh49vk1r.fsf@fifthhorseman.net> References: <87fu0fxjhi.fsf@fifthhorseman.net> <87d0vhwazx.fsf@fifthhorseman.net> <87sh49vk1r.fsf@fifthhorseman.net> From: Eric Rescorla Date: Mon, 23 Jul 2018 13:45:06 -0700 Message-ID: To: Daniel Kahn Gillmor Cc: Richard Barnes , mls@ietf.org, Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary="000000000000e6a5f50571b0bac0" Archived-At: Subject: Re: [MLS] protections for MLS "handshake" messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 20:45:51 -0000 --000000000000e6a5f50571b0bac0 Content-Type: text/plain; charset="UTF-8" n Mon, Jul 23, 2018 at 12:17 PM, Daniel Kahn Gillmor wrote: > On Mon 2018-07-23 08:49:01 -0700, Eric Rescorla wrote: > > - What's with the hate over "handshake" and "application"? It's the same > > distinction that TLS makes. > Hi DKG, You're quoting Barnes here, not me. -Ekr "handshake" is something that implies a meeting or a conversational > setup. here, we're talking about ongoing key updates as well as > membership changes. "handshake" also implies two parties (if there are > three-party handshake protocols in the real world, i'm unaware of them). > So for both those reasons, i think it's inappropriate for the MLS > context. > > I've also argued already on this list that MLS should be *distancing* > itself from TLS, not trying to mimic it. (I don't even think the name > MLS is appropriate, and i think we should change it to something that > doesn't sound like TLS) > > People that want a secure two-party protocol with well-understood > security guarantees *should* use TLS, not whatever MLS turns out to be. > I definitely want us to *discourage* people from using MLS where TLS > would suit their use case better. > > Let's not try to make these protocols too analogous, lest we confuse > people and encourage people to turn TLS into a multi-party scheme. > > --dkg > --000000000000e6a5f50571b0bac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
n Mon, Jul 23, 2018 at 12:= 17 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote= :
On Mon 2018-07-23 08:49:01 -0700, Eric Rescorla wrote:
> - What's with the hate over "handshake" and "applic= ation"?=C2=A0 It's the same
> distinction that TLS makes.

Hi DKG,

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

-Ekr

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

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

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

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

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

--000000000000e6a5f50571b0bac0-- From nobody Mon Jul 23 18:49:39 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 5C3DA130F5F for ; Mon, 23 Jul 2018 18:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 sWUqee7t72Ei for ; Mon, 23 Jul 2018 18:49:35 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C756130F5E for ; Mon, 23 Jul 2018 18:49:35 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k81-v6so4702650oib.4 for ; Mon, 23 Jul 2018 18:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lWRYCG7g+u5kLBnFLlN1E05bFAV0Ar8NGRuhV7hk+Qg=; b=TQo+uYuihWcE9oTIZJojY1VJC2DsreWs80SySxSu42LXaNb1XXfD3Y+3mhy1t3nt9l IPMTeZtY0oAvWHbQqEF2qt3p4+/FpohCLxHN6+CJbOKTpIeuooDmIES+OyHRZ96EMuG1 b39c3SCyL2V25qUw/mMXZV3XifldCqIyI1bJ8B727vpsYQHIcHwhANFVzVGeTld6hw9T qdSE/0Vwi/DxtQdICHMyGRKTGTd036lJRYyvknG8sh8ewgASPZBulAfwbQOoTmP1/vKJ tqlaM3WZd9ZkxRVWzwVvPgIC/yQFUEopda3vIMe312eTB3OVHJ78OiPcI1FU0tuL8HHq 5nfg== 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=lWRYCG7g+u5kLBnFLlN1E05bFAV0Ar8NGRuhV7hk+Qg=; b=bIJRnd/LUhNkDngSMGGZGuCHE4/NYXJcAUfWtc+VJwaRgkzhxdJ9iOaS5OiP/aJW4q jcQv9f5GXOM1k+rNarstdapIAWzRASA3Q1V3Fbg06wdRT6NYxeJcekVm2OJTUh6xT6im BOrKMQHJ4ypCX06joTD650t8JfhtJcBeHjCPOvXtN2wmkjFZ5mFQlNYbfDzqBc4XZ1ly OeXk8EAlruOdGovD+T/PuZR/rDUMZk9TbnmRp626HV6hbWxCDVyYIyDIvsH77Lc6GZ2b 6308+BmYwDgBheyGqS8QpXh14jTJmnTX5BOKL/QGK8+u7FPcf9gVtxjxmKX1PR9QAu7x bMvw== X-Gm-Message-State: AOUpUlHlGUnKjKcuFXSxJZ2uSWslVVZDeTvHelL481deNCt8eEKpYG0r Un9kyONHxoqh7L8o2Uz8SUliQM35RhWgzJwKB0A= X-Google-Smtp-Source: AAOMgpfuLXt+TCz2wHSAcQc/niA9X3apd1b4+xPEXDapv1cLDnEm2T6P1RIfNjLVQFYmhZqpXLHV51vFzkrp/nfvHys= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr1332974oiq.110.1532396974737; Mon, 23 Jul 2018 18:49:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Tue, 24 Jul 2018 11:49:25 +1000 Message-ID: To: Richard Barnes Cc: emadomara=40google.com@dmarc.ietf.org, mls@ietf.org, Sean Turner Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] wg-materials GH repo X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 01:49:37 -0000 On Tue, Jul 24, 2018 at 12:14 AM Richard Barnes wrote: > Sean: Is the idea for the documents to go in repos under that org once they're adopted? At the chairs lunch it was suggested that a working group could allow repos to be created in the "official" organization prior to adoption. That seems like a good plan to me, if only because it allows them to remain at a stable location. From nobody Mon Jul 23 18:54: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 358C5130F65 for ; Mon, 23 Jul 2018 18:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEos2uMtdZDI for ; Mon, 23 Jul 2018 18:54:27 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C83130F63 for ; Mon, 23 Jul 2018 18:54:27 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id l10-v6so4743775oii.0 for ; Mon, 23 Jul 2018 18:54:27 -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=P5waNP8NhxhLHFo1+55H3G4HzzbEXbDySw2LyLwxWRE=; b=jawRmfy2WheL6k2xOYDmXnYwQUFQ41E6t4kyBsIvfDTpBvR6MYPZQHK9sxiMQkJc2f dr6KOGfOSz9ZR1sPF+RXOgE7abh3qX69Rhmbr2vMlw4LFH+6ZmjpUYzp28vs5h+MY+wE Sd8txZtbpoQ5mLNtEV3c9FN3mYmdxHtTvA3OZRN3J2CCF3809dAo0yvnhg30xsqGPuVd d6P4FM3Jq9p+kS6+NHJZ2qGDCIbPJO/emLKD1ZFKCBMUG7GMHDdYvsf2Y8u4iCAzr8rc dfvNiwrPS6tScjxHUs3Ht2JSjCa8DmBSQlbaCJuZrlp3RN5vzpNWtk0chfym8jMdYALO xzwQ== 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=P5waNP8NhxhLHFo1+55H3G4HzzbEXbDySw2LyLwxWRE=; b=N7aX1yKA7dL/z07/O4oLFMBeB9vjz0mzgAtBNgl1hy8ceqcSa8r0oMzy2VNFM0NE4B r6BRtczHYwm0+D155MZ9OJ0lCTgQcKZD+tottnpPfSq10QP9CjoiNcqPPiKjKJuaXctH YBviSSW4hfZmAlQDA3iyi4D31sSjaxtoa58I/bzXGb2gZFJwQUNTFTcXrkWKgpYBvK3V RvQ0/TqCveVeybecL8WPBI/0slk5mrcEo2nVmLspexM+qDN9uaeYqwhSdsaUkofH8yeh X0qDnYqkGTeTA0zngPHLSLERK6Vw4YfU/H++ijULO3/N4GYWMf3zG8s4Yos1frzOOPY6 JENw== X-Gm-Message-State: AOUpUlGMjO/Fc0jebvELduPzNoYKYpcGe5119ILtb8dlEw5dO9dKzXTD nrdoCjJlVJUZmbBt5bTTC8bGyoNJXXlzd0pQpV3SqQ== X-Google-Smtp-Source: AAOMgpc8zvp7duHMtPd5IQIWAv5TQ6NCZrdnUNDg5F/cDEQbjfxBBAM00yEIRxpwnu323o7C+v5qzzsex3b6teveIeY= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr1149028oib.155.1532397267137; Mon, 23 Jul 2018 18:54:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 23 Jul 2018 21:54:16 -0400 Message-ID: To: Martin Thomson Cc: emadomara=40google.com@dmarc.ietf.org, mls@ietf.org, Sean Turner Content-Type: multipart/alternative; boundary="000000000000c349360571b50aa8" Archived-At: Subject: Re: [MLS] wg-materials GH repo X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 01:54:30 -0000 --000000000000c349360571b50aa8 Content-Type: text/plain; charset="UTF-8" Not super relevant here, since the drafts are already elsewhere. Maybe for future items. On Mon, Jul 23, 2018, 21:49 Martin Thomson wrote: > On Tue, Jul 24, 2018 at 12:14 AM Richard Barnes wrote: > > Sean: Is the idea for the documents to go in repos under that org once > they're adopted? > > At the chairs lunch it was suggested that a working group could allow > repos to be created in the "official" organization prior to adoption. > That seems like a good plan to me, if only because it allows them to > remain at a stable location. > --000000000000c349360571b50aa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not super relevant here, since the drafts are alread= y elsewhere.=C2=A0 Maybe for future items.

On Mon, Jul 23, 2018, 21:49 Martin Thomson <martin.thomson@gmail.com> wrote= :
On Tue, Jul 24, 2018 at 12:14 AM = Richard Barnes <rlb@ipv.sx> wrote:
> Sean: Is the idea for the documents to go in repos under that org once= they're adopted?

At the chairs lunch it was suggested that a working group could allow
repos to be created in the "official" organization prior to adopt= ion.
That seems like a good plan to me, if only because it allows them to
remain at a stable location.
--000000000000c349360571b50aa8-- From nobody Tue Jul 24 10:44: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 A7FDA131173 for ; Tue, 24 Jul 2018 10:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvJ7lSWsJZYn for ; Tue, 24 Jul 2018 10:44:42 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6513130E80 for ; Tue, 24 Jul 2018 10:44:42 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id k81-v6so9013590oib.4 for ; Tue, 24 Jul 2018 10:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=la+QytRgZHeLKL7B3m7tdRGRD09K1vxgFWh4bYbmx7Y=; b=i/Dt6e9et2IGPy51lGasIjzNRcA4Ay/by0bJyqMhB2bxrXXmEcXn22b/3BzZMjKO9e d0BooN/79s5A3ruvAft+HnlFTJKXUniKiRbMrhgI5+i7v2KI+BMEb+QyNKFylNWGfi56 F9ltJfIs4CwGfrPY4IOvH94TjsRet4a1tmsyo= 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=la+QytRgZHeLKL7B3m7tdRGRD09K1vxgFWh4bYbmx7Y=; b=niEe6VoVcWt8+lIfYxEOKTqkJcfhQxBn5wHQCPbFoBrkVRPNCcTkPdoLbo3XpwW1k/ lqrrP+MHHi00e3nwfsrdJnoibdZZsQuTjE3fKCXeeEzghf+T+5Ew43jLY31V8d19ebXx ZbvKOAvSabhtmBwYk8Ovev7W8yu3KMnZAENNZFeLDV4PBzxWz1fIbL4amb0B1m2hOXSY tIp/L8rbEY9k5uWIKh6EwEU6T8JuXzE4KHriklOsGf7DeLV4W7Xj+7AcukSI7L2daPzF fbA8qOsIGVjH7J1sjqBUcs9AQBfjleFI2mL2wmW/ASEZjrDByy1ZbhETkjSjrXQBjQKI wh7Q== X-Gm-Message-State: AOUpUlEnfWDFe551G7CmjQv+8YjS38ueEsFrQplMLEpAIMPZwXBZWZGj c2k7PCkUUSqRTExWlr8e8hObUbucJLplPlV4aV9/6udaQyqH8g== X-Google-Smtp-Source: AAOMgpdx2QQXe3b8ap1TaOC1/WC+OBcZzY2kAB/b+2x1CWtPXXP/VxMEBAR10TN1sR+x/yeAyK7nVsL0xrLoK3jQuO0= X-Received: by 2002:aca:fdd5:: with SMTP id b204-v6mr4393916oii.30.1532454281617; Tue, 24 Jul 2018 10:44:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:315c:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 10:44:21 -0700 (PDT) From: Nick Sullivan Date: Tue, 24 Jul 2018 10:44:21 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000176e300571c251c5" Archived-At: Subject: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:44:45 -0000 --000000000000176e300571c251c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, The sense of the MLS@IETF102 room was the WG should adopt https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ as a WG item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D in the da= tatracker, but now it=E2=80=99s time to officially do the WG call for adoption. So, if= you would like for this draft to become a WG document and you are willing to review various versions as it moves through the process, then please let the list know by 2359UTC 2018.08.03. If you are opposed to this being a WG document, please say so (and say why). Cheers, Nick and Sean --000000000000176e300571c251c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The sense of the MLS@IETF102 room was=C2=A0th= e WG=C2=A0should adopt https://datatracker.ietf.org/doc/draft-barnes-mls= -protocol/ as a WG item. We have marked the draft as a "Can= didate for WG Adoption=E2=80=9D in the=C2=A0datatracker, but now it=E2=80=99s time to officially do the WG call for adoption. S= o, if you would like for this draft to become a WG document and you are wil= ling to review various versions as it moves through the process, then pleas= e let the list know by 2359UTC 2018.08.03. If you are opposed to this being= a WG document, please say so (and say why).

Cheers,

Nic= k and Sean

--000000000000176e300571c251c5-- From nobody Tue Jul 24 10:44:53 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB12130E80 for ; Tue, 24 Jul 2018 10:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 zsYEQg2CAnp7 for ; Tue, 24 Jul 2018 10:44:43 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BFD131154 for ; Tue, 24 Jul 2018 10:44:43 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k81-v6so9013677oib.4 for ; Tue, 24 Jul 2018 10:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=v6dHiU+zjOA1Vp5LQmTNEZGshlwJ+58ldFNze5W6TMA=; b=Sjqv3JUqDhhH7JsgbTRP3Hy5fh6+9R40hARD5HydTP2LH3wXrp/nPkhtPicR8/r2m5 lBZF4HAIX2DSlk0uUXS7dIeGaeY3h7H0L9bTLXSbF/Jc11SdHk0Hq1qjRcbKMocOYnNq N0A9ROhO78od6Y9xMO9s/MjwUS7Y8+6rABk+U= 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=v6dHiU+zjOA1Vp5LQmTNEZGshlwJ+58ldFNze5W6TMA=; b=LMTf2Wv1zAS8NXo8LGfJTFbeWxcWUzHezBuqLPwsHtaLfX0u0iZdkJwDSDZjQ+7KCT iTwOfziKyGOhSSqeRne8N+ylEUOBbuE+O1s4VBDvJcJxGSUnXdbxX/8L2uYDT/7B5buq 8IGuRSeC75NB1RG2uRT+DaWumS+Zt+b2sEoEV3dybj1Tmasxzr0IFEtqJPdYZ0BsRHTY prDUi7kbO7mFQE52y0bFrdcKQp+CQXTylJrSF8FM/UGquqUqOw6CUcHO4KvUJmNE4ZZK 4jHU5sEWccJ9mx3d1HdZYJfdAfsUuZ5yCItQ0768zLYPQiVAdMlJf43vyI/r2Yic2lz8 1Gxw== X-Gm-Message-State: AOUpUlGLAwBRDEX+Qtv5KYaeXRV8dt3BUZPMPDp1d7LqqL/ByTk1AUIa yXQH1upMPNJjd/CNhvui7e4bZVJD9dOzJc8r7eVkAKo0b6vcRw== X-Google-Smtp-Source: AAOMgpdbH2CTcEjzXmms0Kq8ptTdwHdqf439zuZxOlikBfAfmF4gll0HUeL5UTD6nGbei5T1D/S7a3p4sLW1h+ojOk8= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr3924037oib.155.1532454282629; Tue, 24 Jul 2018 10:44:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:315c:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 10:44:22 -0700 (PDT) From: Nick Sullivan Date: Tue, 24 Jul 2018 10:44:22 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000026abee0571c2516f" Archived-At: Subject: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:44:45 -0000 --00000000000026abee0571c2516f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, The sense of the MLS@IETF102 room was the WG should adopt https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ as a WG item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D in = the datatracker, but now it=E2=80=99s time to officially do the WG call for ado= ption. So, if you would like for this draft to become a WG document and you are willing to review various versions as it moves through the process, then please let the list know by 2359UTC 2018.08.03. If you are opposed to this being a WG document, please say so (and say why). Cheers, Nick and Sean --00000000000026abee0571c2516f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The sense of the MLS@IE= TF102 room was the WG should adopt https://datatracker.ietf.org/doc/draft-o= mara-mls-architecture/ as a WG item. We have marked the draft as a &quo= t;Candidate for WG Adoption=E2=80=9D in the datatracker, but now it=E2=80= =99s time to officially do the WG call for adoption. So, if you would like = for this draft to become a WG document and you are willing to review variou= s versions as it moves through the process, then please let the list know b= y 2359UTC 2018.08.03. If you are opposed to this being a WG document, pleas= e say so (and say why).

Cheers,

Nick and Sean
--00000000000026abee0571c2516f-- From nobody Tue Jul 24 10:54:28 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F306130E80 for ; Tue, 24 Jul 2018 10:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1CsbItaj2c3 for ; Tue, 24 Jul 2018 10:54:24 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DED130F1C for ; Tue, 24 Jul 2018 10:54:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,398,1526335200"; d="asc'?scan'208,217";a="273977582" Received: from corp-nat.fw1.untrust.mtv2.mozilla.net (HELO [10.252.25.87]) ([63.245.221.198]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2018 19:54:19 +0200 From: Benjamin Beurdouche Message-Id: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> Content-Type: multipart/signed; boundary="Apple-Mail=_67B03678-6A01-4D3A-B330-64512E06B86C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 24 Jul 2018 10:54:14 -0700 In-Reply-To: Cc: ML Messaging Layer Security To: Nick Sullivan References: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:54:27 -0000 --Apple-Mail=_67B03678-6A01-4D3A-B330-64512E06B86C Content-Type: multipart/alternative; boundary="Apple-Mail=_DBB771B3-A165-4973-B84A-35A20BB30C98" --Apple-Mail=_DBB771B3-A165-4973-B84A-35A20BB30C98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I agree with this draft becoming a WG document. Best, Benjamin > On Jul 24, 2018, at 10:44 AM, Nick Sullivan = wrote: >=20 > All, >=20 > The sense of the MLS@IETF102 room was the WG should adopt = https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ = as a WG = item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D = in the datatracker, but now it=E2=80=99s time to officially do the WG = call for adoption. So, if you would like for this draft to become a WG = document and you are willing to review various versions as it moves = through the process, then please let the list know by 2359UTC = 2018.08.03. If you are opposed to this being a WG document, please say = so (and say why). >=20 > Cheers, >=20 > Nick and Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_DBB771B3-A165-4973-B84A-35A20BB30C98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

I agree = with this draft becoming a WG document.

Best,
Benjamin

On Jul 24, 2018, at 10:44 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

All,

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

Cheers,

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

= --Apple-Mail=_DBB771B3-A165-4973-B84A-35A20BB30C98-- --Apple-Mail=_67B03678-6A01-4D3A-B330-64512E06B86C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEuBxqANrVSPVBPOUAfmABPaR1P1QFAltXZ8YACgkQfmABPaR1 P1SdDw/8DmsVZ7amB0qlKnHnnkR1rE/S8tGyNXaMEPkZdd80+2eERTiYjc0R9vRN 4uIXeArOkkwgvOrcQezlPulxy3tGV2SrEtOQyKU34OHbNsXNNhY0bsTDen/+xrmf yQ56nk6J66Yn/dkil8VgV4EqtayftpQWC1dovrsNeVyaBpvU6IkXc7eSV0yM3Qhw 5IcZs9/sa/Rb2Sd59OlKDn9N2A+C8TGEl1DcS0H7jgNGAWCG9qp3/dYecqusMSUG FXRtJbez9VgxSZdfRFgWFQLqBJ8qHZI3iKq7OJdfN0oo8V37/mNYtn4sPlhuez8K RZh6deIz/yiuTR8KqfWaPGzdFccgoOYoUo4HbZ8fYQ/Fhdle7kLZPZLmGfQ9kvFT 3lsIa1vvGJJZEUQGErkBhdtI1ZidCkh6vuZaLu21WA7T8gWTzBTiHKYqJjOeozgA SH0L1P6WJSq4ajceXBQj3RcG5EnxOolqOj0yxXLjlShX1JEmwHUbArwVc0hDf4XB w5r/mmXXVxzomzrRgF2JdNq5Poka2E1NV1PMlUST9OBSAo2xABiwFlmETmiukUFN 9BOxHqMJtDIhW5lMmiPr6wHh7XZ9W/MGiBHZBqEWDfVyIjCE3k3M42oZQiovcWtr b/0tsFnYt/P4GqF1O6W+4rx1cOM5LO2SHLW+9t/8j3AEU3ybq3E= =Zbeq -----END PGP SIGNATURE----- --Apple-Mail=_67B03678-6A01-4D3A-B330-64512E06B86C-- From nobody Tue Jul 24 10:55: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 17492131173 for ; Tue, 24 Jul 2018 10:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.888 X-Spam-Level: X-Spam-Status: No, score=-6.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0KbEbwZADgoI for ; Tue, 24 Jul 2018 10:55:36 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F41130E80 for ; Tue, 24 Jul 2018 10:55:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.51,398,1526335200"; d="asc'?scan'208,217";a="273977605" Received: from corp-nat.fw1.untrust.mtv2.mozilla.net (HELO [10.252.25.87]) ([63.245.221.198]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2018 19:54:33 +0200 From: Benjamin Beurdouche Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_22A027F6-80CF-4312-A466-891DFCD9818F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 24 Jul 2018 10:54:33 -0700 In-Reply-To: Cc: ML Messaging Layer Security To: Nick Sullivan References: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:55:39 -0000 --Apple-Mail=_22A027F6-80CF-4312-A466-891DFCD9818F Content-Type: multipart/alternative; boundary="Apple-Mail=_334586F2-DDB5-4CC7-A727-CE772B285CB4" --Apple-Mail=_334586F2-DDB5-4CC7-A727-CE772B285CB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I agree with this draft becoming a WG document. Best, Benjamin > On Jul 24, 2018, at 10:44 AM, Nick Sullivan = wrote: >=20 > All, >=20 > The sense of the MLS@IETF102 room was the WG should adopt = https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ = as a WG = item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D = in the datatracker, but now it=E2=80=99s time to officially do the WG = call for adoption. So, if you would like for this draft to become a WG = document and you are willing to review various versions as it moves = through the process, then please let the list know by 2359UTC = 2018.08.03. If you are opposed to this being a WG document, please say = so (and say why). >=20 > Cheers, >=20 > Nick and Sean >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_334586F2-DDB5-4CC7-A727-CE772B285CB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

I agree = with this draft becoming a WG document.

Best,
Benjamin

On Jul 24, 2018, at 10:44 AM, Nick Sullivan = <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

All,

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

Cheers,

Nick and Sean

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

= --Apple-Mail=_334586F2-DDB5-4CC7-A727-CE772B285CB4-- --Apple-Mail=_22A027F6-80CF-4312-A466-891DFCD9818F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEuBxqANrVSPVBPOUAfmABPaR1P1QFAltXZ9kACgkQfmABPaR1 P1SojhAAvYOjicy5DvV6YLQWk85YfGJ330LZrbrFcXuqrlXvAmB53oq/pGgkXa51 ecU6YYsjCqER0IZZMKKELfOD4ZNwtA6RltuCkHzXvSLPkI+cRlUJhVrppIAmchjl +/AenrLzERVtT9zcNTVWcXP9yBjfrf8Q5HuoGZkilrHD815AFB3oEU0J+RXqOuHl ah3mzCZtpZyHzUPQt5TJoaeIr2GOKpJ9xevp9EOkNZiQRFFl6dlJUw59vV/ZZxbC eC6MwUcpWI65sWlCJuf+idNsUi003r7Fye0iI2F7SoWknFfAcOAgJF/A3QG5w4J/ uG4q2nfqxcmh6aQDsoE9N5ktO8d5OCgA2F/Jo+Fg2aNTgSq0wyvCsZrF4h1+okmh 0Fb4dt5yQafzumVXrsNf3dwn8ilHdTacAibqr+Nf+Cw2gEvqT7OTa8c4jj3OC2gV Cmz7WT/ACTT8NdqimA1p3V7INEDZPtLYFlcN/2XbKdMtpPZUCyDhXFLidocVtmfc MRtla6gjxGKxRdxxTgULRS7P0IW3IwZhe4TApf7j/IoW2kbn/HU8XepeXeq/UVLx 0kqsET2EQgB1Lt2n63qn7WiGR6acYsLP2RCtDMz+AP8MN5Nbs1pfcxJL+fGHq1jy phUjZuSJAWgaRKFht+kNwYnygmntVaJqypuaMyxfKXtqcEdJnd8= =pB4n -----END PGP SIGNATURE----- --Apple-Mail=_22A027F6-80CF-4312-A466-891DFCD9818F-- From nobody Tue Jul 24 10:57: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 044A913117B for ; Tue, 24 Jul 2018 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 MpfzzahrRTcG for ; Tue, 24 Jul 2018 10:56:54 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DFB130F1C for ; Tue, 24 Jul 2018 10:56:53 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id y9-v6so2487031vky.3 for ; Tue, 24 Jul 2018 10:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o2V8YP6/dSgieUUqfhkaMdFYKz1mT6bkT7MtB0+qLYE=; b=lWngzFBjczUIpcVjHH/n63VKguNvJYPs3CTA+bFlJ8W3O1XHjAWPo7oanOgl9oFx44 dwiceAuoJd+POuIrBs5EwlvjWvXCavj9MNEACkRGoFpNq8eXRQZw8B12YKEobrrjbXd+ trYfWhUMYSavZ2BVfgzmcKk+/yMNVpgg0lX/h0utJU44n/3wU9HKB0SfBZ2yUCUMsvaN sXShaFQGyULZFDNMVkzVU88M5ITBpmg0MOlKBYgMePxwNJ0RaV15sJgK4MNNLjQadMbL yxt1+a4qd6nXMD3I/MgiPN9l6ym9h4uFqd88qreVc/Ri8caxrsFiip0+hVnrJS3yDic2 Uodw== 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=o2V8YP6/dSgieUUqfhkaMdFYKz1mT6bkT7MtB0+qLYE=; b=mwWeQpKdUX9oQt+mRjm4L4j6DO5RZHpFpBIb/TVZlkAVka14RNC5Xzh97JWj8jH+7Q Q7yj+VzWuR1xhXawDtpT5WU6TKzUk11AUsSQQpGOZJ1Jm2nYC9WL2BN1zDJAJNLpSYeA 6NRwaVQ43ECqi2qjbHlhieFM+XaHGvFw2nfa2y2kGC5u81b1BcbqRu56vag/dDhgBbx1 3qjiwBq5ls5LyEWU353gSQB+Qcx37yYceRzfajDxPKsb/5bYtj9mpRFIiipv1PoZ1JJN AneYtQqp8Ut8CAWYzYgtUbzu5IeL6280BsyyYKZpGLKWqDZPBs4XKU0aH4B01Hrswm6D iXIQ== X-Gm-Message-State: AOUpUlET4rhePuXZXfs0sWUbRCKmdP7WsTNcu91JGXGP06jFcVCPGBoB hQWPgAwCuEH18snxXPdo/nhjraoFugEtaUCRhSc= X-Google-Smtp-Source: AAOMgpds2iQkD+y8Pk/fR55C9OI2aDCt+vDqMIw/I/gqBSTqICmQzzegRFuicASYQyBmOTqAcT8efrZIcj5oVDkzeXo= X-Received: by 2002:a1f:3653:: with SMTP id d80-v6mr11035641vka.79.1532455012897; Tue, 24 Jul 2018 10:56:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suhas Nandakumar Date: Tue, 24 Jul 2018 10:56:42 -0700 Message-ID: To: Benjamin Beurdouche Cc: ML Messaging Layer Security , Nick Sullivan Content-Type: multipart/alternative; boundary="000000000000ad972f0571c27c58" Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:56:58 -0000 --000000000000ad972f0571c27c58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support the adoption On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche < benjamin.beurdouche@inria.fr> wrote: > Hi all, > > I agree with this draft becoming a WG document. > > Best, > Benjamin > > On Jul 24, 2018, at 10:44 AM, Nick Sullivan < > nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > > All, > > The sense of the MLS@IETF102 room was the WG should adopt > https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ as a WG item. > We have marked the draft as a "Candidate for WG Adoption=E2=80=9D in the > datatracker, but now it=E2=80=99s time to officially do the WG call for a= doption. > So, if you would like for this draft to become a WG document and you are > willing to review various versions as it moves through the process, then > please let the list know by 2359UTC 2018.08.03. If you are opposed to thi= s > being a WG document, please say so (and say why). > > Cheers, > > Nick and Sean > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000ad972f0571c27c58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption=C2=A0

On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche <= benjamin.beurdouche@inria.f= r> wrote:
Hi all,

<= /div>I agree with this draft becoming a WG document.

Bes= t,
Benjamin

On Jul 24, 2= 018, at 10:44 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org= > wrote:

All,

The sense of the MLS@IETF102 room was=C2=A0the WG= =C2=A0should adopt https://datatracker.ietf.org/doc/dr= aft-barnes-mls-protocol/ as a WG item. We have marked the draft = as a "Candidate for WG Adoption=E2=80=9D in the=C2=A0datatr= acker, but now it=E2=80=99s time to officially do the WG call for ad= option. So, if you would like for this draft to become a WG document and yo= u are willing to review various versions as it moves through the process, t= hen please let the list know by 2359UTC 2018.08.03. If you are opposed to t= his being a WG document, please say so (and say why).
=
Cheers,

Nick and Sean

_______________________________________________
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
--000000000000ad972f0571c27c58-- From nobody Tue Jul 24 10:58:13 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7F6130F15 for ; Tue, 24 Jul 2018 10:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daOEVz1gALay for ; Tue, 24 Jul 2018 10:58:07 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69175130E2F for ; Tue, 24 Jul 2018 10:58:07 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id r18-v6so3327816ual.13 for ; Tue, 24 Jul 2018 10:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kr9aaW2Qw16o5QaGUuG28JXzjCK1kivnB6ML0XFF7lc=; b=h+FROUlL7AdnOYjvMPfG8+tk1VTqOramjK98C0HJCrPUryOCSOi8lq92RQ/oHRGhiU mdXskfp9OTq1vxAEkshtF6p9wtks+nAGnOKL06dUJ06dojd0WZybxbtE2x599H2OPA+j fTfvkyQi3KnC3/9AVu2AFtvSGx5gRhJuXJwZ0AcWS9/NAQEeFfc/yecrLMADg8XSiliI M7E4RV5JkB5VcppHUioCLxqEu0Inao+0slxEwDyqtJ0NKyEw0GDuFaZkApW91eOY0uWK wwtiv3VqJrq33wP9/BMlvab26fo78OeztbDR73d2YT6UIOuACRvyoZO2/SWMql/KNd38 FV7g== 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=kr9aaW2Qw16o5QaGUuG28JXzjCK1kivnB6ML0XFF7lc=; b=SI7tZEg7wshDjcJnNxQQlC2VrlwRkW3OvkA8cZg+oW+3BOePt+JCJP5PuTmBOQmzn8 SBenrsEH1+FpvFJEVPDygmXE077eq4fySC4ZKs4ac/NfdvF/FxOwtUIveI/cp2vgnBDd HKQrU7K7zIKO4R/XWolHgfwmt+aPThE9nsPxP6ZDqSgDpBO0TOa4+1r+ihouUmj61tgB S6wqyGg4YcaMJzETUckYKvSWmk2P6EA6foLfM/GGAeFiYW1ev7Td3LFMu0kc7Dn9G+FA TaUWk83LsHE1u4d9JK1DaBIkOjZoaQo1UYvDC66NiLKkkx21uxlI3XcgACO6U/B1sd88 o3+g== X-Gm-Message-State: AOUpUlFgO7JxQhPswA8Ih+3F68pDkxQrIX33RW3NTXqvfW3L5pe3woCa g6LxoBco1+jL9xZXKhy807NnzOjpjKStfLuOSAU= X-Google-Smtp-Source: AAOMgpeczxRRHodUDlmJLilbieFdsEks8IyuIYov9EP3DGtv7zQ7gM8eamHC3r8peTVMBDvxsr6/xq5V9mKZuQ04ONY= X-Received: by 2002:a9f:28a4:: with SMTP id d33-v6mr12311832uad.11.1532455086435; Tue, 24 Jul 2018 10:58:06 -0700 (PDT) MIME-Version: 1.0 References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> In-Reply-To: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> From: Suhas Nandakumar Date: Tue, 24 Jul 2018 10:57:56 -0700 Message-ID: To: Benjamin Beurdouche Cc: ML Messaging Layer Security , Nick Sullivan Content-Type: multipart/alternative; boundary="0000000000000fb3a80571c281d6" Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:58:12 -0000 --0000000000000fb3a80571c281d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am following this work closely and support it=E2=80=99s adoption Thanks ./s On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche < benjamin.beurdouche@inria.fr> wrote: > Hi all, > > I agree with this draft becoming a WG document. > > Best, > Benjamin > > > On Jul 24, 2018, at 10:44 AM, Nick Sullivan < > nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > > All, > > The sense of the MLS@IETF102 room was the WG should adopt > https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ as a WG > item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D i= n the > datatracker, but now it=E2=80=99s time to officially do the WG call for a= doption. > So, if you would like for this draft to become a WG document and you are > willing to review various versions as it moves through the process, then > please let the list know by 2359UTC 2018.08.03. If you are opposed to thi= s > being a WG document, please say so (and say why). > > Cheers, > > Nick and Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000000fb3a80571c281d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am following this work closely and support it=E2= =80=99s adoption=C2=A0

T= hanks
./s

O= n Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
Hi all,

I agree with t= his draft becoming a WG document.

Best,
Benjam= in


On Jul 24, 2018, at 10= :44 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> w= rote:

All,

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

Cheers,
Nick and Sean
_______________________________________________
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
--0000000000000fb3a80571c281d6-- From nobody Tue Jul 24 10:58: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 F3550130E2F for ; Tue, 24 Jul 2018 10:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=lN5D10r7; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=BP1M7bbG 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 65X6RZWBqfIb for ; Tue, 24 Jul 2018 10:58:33 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 5BE88130F15 for ; Tue, 24 Jul 2018 10:58:25 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6OHrivd022133; Tue, 24 Jul 2018 10:58:21 -0700 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=tOwd+hLKx9o/+VQK5qpNG2c7seoO2kT24tXsFdwgLSo=; b=lN5D10r7WlUmaKf8C11JKjBA+KGUiJP7muENlGZpAemxYAD9MLq1z1dg8uuOeQHsp84K WtygGLB4aBC9thL+4iKJH7681re2gJLOmI5sEmosxS4CnY/PkMcyrTKRGs7hbDlAUpUi Yh6v6WwIivO0R4mVy8JI9+DX5nrTL0bskUA= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2ke7pv8aaq-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jul 2018 10:58:21 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.30) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Jul 2018 13:58:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tOwd+hLKx9o/+VQK5qpNG2c7seoO2kT24tXsFdwgLSo=; b=BP1M7bbG+C3Js+5yCfdfvaXm7WtH5eXgC1QHdRVCghJfirmKqpESDGbdPalop5lRWW7orxa1sIMbyKikdO0nsbkkNxDJ7j/PeJPiHhSzUs3IVp0IFFu6E6HIkSeve/KKnhKJY82Op1pcy9z4aVzeX/sl+Ka4ZDHVVI963d2Iuy0= Received: from SN6PR15MB2205.namprd15.prod.outlook.com (52.135.64.145) by SN6PR15MB2240.namprd15.prod.outlook.com (52.135.64.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Tue, 24 Jul 2018 17:58:18 +0000 Received: from SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b]) by SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b%4]) with mapi id 15.20.0995.014; Tue, 24 Jul 2018 17:58:18 +0000 From: Jon Millican To: Suhas Nandakumar , Benjamin Beurdouche CC: ML Messaging Layer Security , Nick Sullivan Thread-Topic: [MLS] Call for adoption: draft-barnes-mls-protocol Thread-Index: AQHUI3YWjlAxHoOl1ECoYzHFdhXJn6Sep9WAgAAAmQCAABE2AA== Date: Tue, 24 Jul 2018 17:58:18 +0000 Message-ID: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:200::1:5390] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR15MB2240; 20:5Ddpuvvtd0HZeI+I1G5+dkXnqphZbexhCp5AMcp1+MtLBhbMlGm7MqXTEJvHcXpr2snqx+H/KThXxwOhb7a3JywPp87iIqYlIUt+o+zdGKJ+8H/xGdtNBUSyEfR3pTwu2HGSO3dCJpsKPYTDokfci2Nvs8o3YYu+ZAsbkS3sBec= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: de73c880-0e0f-43fe-a9e6-08d5f18f09b5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(2017052603328)(7153060)(7193020); SRVR:SN6PR15MB2240; x-ms-traffictypediagnostic: SN6PR15MB2240: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(120809045254105)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(11241501184)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:SN6PR15MB2240; BCL:0; PCL:0; RULEID:; SRVR:SN6PR15MB2240; x-forefront-prvs: 0743E8D0A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39860400002)(396003)(136003)(199004)(189003)(53754006)(186003)(53936002)(25786009)(5660300001)(6486002)(99286004)(82746002)(39060400002)(6306002)(316002)(6512007)(54896002)(6436002)(102836004)(6246003)(4326008)(236005)(54906003)(229853002)(486006)(83716003)(110136005)(105586002)(106356001)(8936002)(7736002)(6506007)(68736007)(33656002)(8676002)(2906002)(81156014)(478600001)(76176011)(14454004)(966005)(53546011)(6116002)(97736004)(5070765005)(81166006)(11346002)(46003)(36756003)(2616005)(446003)(2900100001)(5250100002)(606006)(476003)(86362001)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR15MB2240; H:SN6PR15MB2205.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DoZ4CpcbXVuo3SmUGzEmRR8g0QgcvfPmffrcNu7H4XJRptx6nr0JF6dZ3Z7eci4QTPIoz9HWCG+oRkrKBwRG3wrqdLewtKy9m1HBIuhCApn1sL3ZmmyPqFcO9xm8f9B+Vn71DbZP6hMjM8MkTp48iTe36jhsyXfzPFhdhZ7GlJmmr57dmt6THeD17cFP+Xb0ZV4dNX8leSShCRoAR0qlE9SXfpwKq3q4hGzgnhBXrAUSDtEd+Rhf2FMWxlmuS++IgwNsvjJ4AnJflf1TFfs7QKXyx1Nm9lJsybDxrw6jwdno/53b97soHs7kfb7pcKIfrhK1aKZWvjIdgENcCL4+wungJ/Ey27AN1LzNaUbs3vM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_372F3FA7FAAB4C3BB3391E055E7339A2fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: de73c880-0e0f-43fe-a9e6-08d5f18f09b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2018 17:58:18.7890 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2240 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-24_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 17:58:42 -0000 --_000_372F3FA7FAAB4C3BB3391E055E7339A2fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIHN1cHBvcnQgYWRvcHRpb24uDQoNCk9uIDI0LzA3LzIwMTgsIDE4OjU3LCAiTUxTIG9u IGJlaGFsZiBvZiBTdWhhcyBOYW5kYWt1bWFyIiA8bWxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Om1scy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Ygc3VoYXNpZXRmQGdtYWlsLmNvbTxt YWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0 aW9uDQoNCk9uIFR1ZSwgSnVsIDI0LCAyMDE4IGF0IDEwOjU1IEFNIEJlbmphbWluIEJldXJkb3Vj aGUgPGJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI8bWFpbHRvOmJlbmphbWluLmJldXJkb3Vj aGVAaW5yaWEuZnI+PiB3cm90ZToNCkhpIGFsbCwNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgZHJhZnQg YmVjb21pbmcgYSBXRyBkb2N1bWVudC4NCg0KQmVzdCwNCkJlbmphbWluDQoNCg0KT24gSnVsIDI0 LCAyMDE4LCBhdCAxMDo0NCBBTSwgTmljayBTdWxsaXZhbiA8bmljaz00MGNsb3VkZmxhcmUuY29t QGRtYXJjLmlldGYub3JnPG1haWx0bzpuaWNrPTQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5v cmc+PiB3cm90ZToNCg0KQWxsLA0KDQpUaGUgc2Vuc2Ugb2YgdGhlIE1MU0BJRVRGMTAyIHJvb20g d2FzIHRoZSBXRyBzaG91bGQgYWRvcHQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYmFybmVzLW1scy1wcm90b2NvbC88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRi YXJuZXMtMkRtbHMtMkRwcm90b2NvbF8mZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3 JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPUI2LW1qWVc1dXlWSTJxdy1NYVZiVWlPVUF4RDg0 VU9Kby1BYzlKaHh3amMmcz1sM2daMEMxeTZyVERjNzVuam0ySzNHMjlmRGJjOWthY3RrdWVzYnd5 aFhZJmU9PiBhcyBhIFdHIGl0ZW0uIFdlIGhhdmUgbWFya2VkIHRoZSBkcmFmdCBhcyBhICJDYW5k aWRhdGUgZm9yIFdHIEFkb3B0aW9u4oCdIGluIHRoZSBkYXRhdHJhY2tlciwgYnV0IG5vdyBpdOKA mXMgdGltZSB0byBvZmZpY2lhbGx5IGRvIHRoZSBXRyBjYWxsIGZvciBhZG9wdGlvbi4gU28sIGlm IHlvdSB3b3VsZCBsaWtlIGZvciB0aGlzIGRyYWZ0IHRvIGJlY29tZSBhIFdHIGRvY3VtZW50IGFu ZCB5b3UgYXJlIHdpbGxpbmcgdG8gcmV2aWV3IHZhcmlvdXMgdmVyc2lvbnMgYXMgaXQgbW92ZXMg dGhyb3VnaCB0aGUgcHJvY2VzcywgdGhlbiBwbGVhc2UgbGV0IHRoZSBsaXN0IGtub3cgYnkgMjM1 OVVUQyAyMDE4LjA4LjAzLiBJZiB5b3UgYXJlIG9wcG9zZWQgdG8gdGhpcyBiZWluZyBhIFdHIGRv Y3VtZW50LCBwbGVhc2Ugc2F5IHNvIChhbmQgc2F5IHdoeSkuDQoNCkNoZWVycywNCg0KTmljayBh bmQgU2Vhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KTUxTIG1haWxpbmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczxodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX21scyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5 ZEJWVVhfYnZFcU1hODRRJm09QjYtbWpZVzV1eVZJMnF3LU1hVmJVaU9VQXhEODRVT0pvLUFjOUpo eHdqYyZzPXhKN3JVbHkyQ3N4blFaa0lPdGh4V2M0OFBtakNJb3NkX1gtaF8xT1djdFkmZT0+DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNTFMgbWFp bGluZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFpbHRvOk1MU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f bWxzJmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVx TWE4NFEmbT1CNi1tallXNXV5VkkycXctTWFWYlVpT1VBeEQ4NFVPSm8tQWM5Smh4d2pjJnM9eEo3 clVseTJDc3huUVprSU90aHhXYzQ4UG1qQ0lvc2RfWC1oXzFPV2N0WSZlPT4NCg== --_000_372F3FA7FAAB4C3BB3391E055E7339A2fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0E8B6AF4C22F324483A8429712365917@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5t LTg2MTg5NzY2Nzg3OTcyOTY2NjBnbWFpbC1nci1hbGVydA0KCXttc28tc3R5bGUtbmFtZTptXy04 NjE4OTc2Njc4Nzk3Mjk2NjYwZ21haWwtZ3ItYWxlcnQ7fQ0Kc3Bhbi5tLTg2MTg5NzY2Nzg3OTcy OTY2NjBnbWFpbC1pbnMtZGVsDQoJe21zby1zdHlsZS1uYW1lOm1fLTg2MTg5NzY2Nzg3OTcyOTY2 NjBnbWFpbC1pbnMtZGVsO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUu M3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIHN1cHBvcnQg YWRvcHRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+T24gMjQvMDcvMjAxOCwgMTg6NTcsICZxdW90O01MUyBvbiBiZWhh bGYgb2YgU3VoYXMgTmFuZGFrdW1hciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1scy1ib3Vu Y2VzQGlldGYub3JnIj5tbHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBo cmVmPSJtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbSI+c3VoYXNpZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBUdWUsIEp1bCAyNCwgMjAxOCBh dCAxMDo1NSBBTSBCZW5qYW1pbiBCZXVyZG91Y2hlICZsdDs8YSBocmVmPSJtYWlsdG86YmVuamFt aW4uYmV1cmRvdWNoZUBpbnJpYS5mciI+YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mcjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBh bGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBhZ3JlZSB3 aXRoIHRoaXMgZHJhZnQgYmVjb21pbmcgYSBXRyBkb2N1bWVudC4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkJl bmphbWluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPk9uIEp1bCAyNCwgMjAxOCwgYXQgMTA6NDQgQU0sIE5pY2sgU3VsbGl2 YW4gJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrPTQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5uaWNrPTQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5BbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGUgc2Vuc2Ugb2YgdGhlIE1MU0BJRVRGMTAyIHJv b20gd2FzJm5ic3A7PHNwYW4gY2xhc3M9Im0tODYxODk3NjY3ODc5NzI5NjY2MGdtYWlsLWdyLWFs ZXJ0Ij50aGUgV0c8L3NwYW4+Jm5ic3A7c2hvdWxkIGFkb3B0DQo8c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRiYXJuZXMt MkRtbHMtMkRwcm90b2NvbF8mYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNN VXcmYW1wO3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7bT1CNi1tallXNXV5VkkycXctTWFW YlVpT1VBeEQ4NFVPSm8tQWM5Smh4d2pjJmFtcDtzPWwzZ1owQzF5NnJURGM3NW5qbTJLM0cyOWZE YmM5a2FjdGt1ZXNid3loWFkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmFybmVzLW1scy1wcm90b2NvbC88L2E+PC9zcGFuPg0K IGFzIGEgV0cgaXRlbS4gV2UgaGF2ZSBtYXJrZWQgdGhlIGRyYWZ0IGFzIGEgJnF1b3Q7Q2FuZGlk YXRlIGZvciBXRyBBZG9wdGlvbuKAnSBpbiB0aGUmbmJzcDs8c3BhbiBjbGFzcz0ibS04NjE4OTc2 Njc4Nzk3Mjk2NjYwZ21haWwtaW5zLWRlbCI+ZGF0YXRyYWNrZXI8L3NwYW4+LCBidXQgbm93IGl0 4oCZcyB0aW1lIHRvIG9mZmljaWFsbHkgZG8gdGhlIFdHIGNhbGwgZm9yIGFkb3B0aW9uLiBTbywg aWYgeW91IHdvdWxkIGxpa2UgZm9yIHRoaXMgZHJhZnQgdG8gYmVjb21lDQogYSBXRyBkb2N1bWVu dCBhbmQgeW91IGFyZSB3aWxsaW5nIHRvIHJldmlldyB2YXJpb3VzIHZlcnNpb25zIGFzIGl0IG1v dmVzIHRocm91Z2ggdGhlIHByb2Nlc3MsIHRoZW4gcGxlYXNlIGxldCB0aGUgbGlzdCBrbm93IGJ5 IDIzNTlVVEMgMjAxOC4wOC4wMy4gSWYgeW91IGFyZSBvcHBvc2VkIHRvIHRoaXMgYmVpbmcgYSBX RyBkb2N1bWVudCwgcGxlYXNlIHNheSBzbyAoYW5kIHNheSB3aHkpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Q2hl ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+TmljayBhbmQgU2VhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpNTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk1MU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZhbXA7ZD1Ed01GYVEmYW1wO2M9 NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDtt PUI2LW1qWVc1dXlWSTJxdy1NYVZiVWlPVUF4RDg0VU9Kby1BYzlKaHh3amMmYW1wO3M9eEo3clVs eTJDc3huUVprSU90aHhXYzQ4UG1qQ0lvc2RfWC1oXzFPV2N0WSZhbXA7ZT0iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpNTFMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk1MU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX21scyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1N MENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPUI2LW1qWVc1dXlWSTJxdy1NYVZiVWlPVUF4RDg0 VU9Kby1BYzlKaHh3amMmYW1wO3M9eEo3clVseTJDc3huUVprSU90aHhXYzQ4UG1qQ0lvc2RfWC1o XzFPV2N0WSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21sczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_372F3FA7FAAB4C3BB3391E055E7339A2fbcom_-- From nobody Tue Jul 24 11:18:14 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70527130ED6 for ; Tue, 24 Jul 2018 11:18:11 -0700 (PDT) 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 6tUNz0dia7Ge for ; Tue, 24 Jul 2018 11:18:08 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 437F2130E22 for ; Tue, 24 Jul 2018 11:18:07 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id t14-v6so3362816uao.8 for ; Tue, 24 Jul 2018 11:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wdo1znpLzcmK6xtVbeI55LsTbW0duMkk8nPmPRdbMts=; b=mftmtelGcwdTvAvmGJFI67arEVq8uExLS9hujR9wLJqr3qgIGav/FJatMyeTC60O6J Uhw10Do6kpLhP6Bc4Ng8yZvOpNL7uWLa1IrYPvqmu/w9EjkLOlVQMC2KIXNLRrmteR5Q hSd9fTqYYgkbwVzygGOHCZszicUlSGjnrLwV0= 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=wdo1znpLzcmK6xtVbeI55LsTbW0duMkk8nPmPRdbMts=; b=gaQ2IVJ7VACo9F80Y4NJ8Jalea6TZSgvrP4YHy5eG6I3IDxb0C9qFi8J2crFKt5NSx rs6sz8T9pZRcVSGT9X6AjOTTB3cCAYMiLfo35wuKfr8KwVyQxIxD9YDMXN84hS0kYFIo diJZPmnl0MhVxy6wAE5AhYPMWIK1cighyXI9rZS/cT3YyvaNkQ2wneV/GAB+GkTr9FwU naURht2lik5iH1pvqAxVPukWogPS+bvsJU2QT6PatkUZTWXtbYpuQ7FL7sm4mOC79T6D E3L1EhzyRuhwuW+b6o/Dv3jLogVJV2gZ8lMEpwe5UygtT8W2kNWEaPBHRkIhuq7hVIQK EoUg== X-Gm-Message-State: AOUpUlFFsbFxVzG+v2j9FY1VpdQ2ANaiSfQ0f58fTFrQsqkwR40S5Eka p+nkVfU8FgwPkR9eLRxk/2mCtm6sqbRMndBMXsYz/A== X-Google-Smtp-Source: AAOMgpdMe703+/csgIQcsICpm8BFLqAJsiWhUEABMyKhSLK7QCCfFLSVQf/rzVT2FbxC9s0/nSfuzkztQYPD+NsnuKE= X-Received: by 2002:ab0:6352:: with SMTP id f18-v6mr11585112uap.76.1532456286100; Tue, 24 Jul 2018 11:18:06 -0700 (PDT) MIME-Version: 1.0 References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> In-Reply-To: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> From: Joseph Lorenzo Hall Date: Tue, 24 Jul 2018 14:17:54 -0400 Message-ID: To: jmillican@fb.com Cc: Suhas Nandakumar , benjamin.beurdouche@inria.fr, mls@ietf.org, nick=40cloudflare.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="0000000000009136530571c2c8cc" Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:18:12 -0000 --0000000000009136530571c2c8cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption On Tue, Jul 24, 2018 at 1:58 PM Jon Millican wrote: > I also support adoption. > > > > On 24/07/2018, 18:57, "MLS on behalf of Suhas Nandakumar" < > mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote: > > > > I support the adoption > > > > On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche < > benjamin.beurdouche@inria.fr> wrote: > > Hi all, > > > > I agree with this draft becoming a WG document. > > > > Best, > > Benjamin > > > > On Jul 24, 2018, at 10:44 AM, Nick Sullivan < > nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > > > > All, > > > > The sense of the MLS@IETF102 room was the WG should adopt > https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ > > as a WG item. We have marked the draft as a "Candidate for WG Adoption=E2= =80=9D in > the datatracker, but now it=E2=80=99s time to officially do the WG call f= or > adoption. So, if you would like for this draft to become a WG document an= d > you are willing to review various versions as it moves through the proces= s, > then please let the list know by 2359UTC 2018.08.03. If you are opposed t= o > this being a WG document, please say so (and say why). > > > > Cheers, > > > > Nick and Sean > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --0000000000009136530571c2c8cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption

On Tue, Jul 24, 2018 at 1:58 PM Jon Millican <jmillican@fb.com> wrote:

I also support adoption.

=C2=A0

On 24/07/2018, 18:57, &= quot;MLS on behalf of Suhas Nandakumar" <mls-bounces@ietf.org on behalf of suhasietf@gmail.co= m> wrote:

=C2=A0

I support the adoption= =C2=A0

=C2=A0

On Tue, Jul 24, 2018 at= 10:55 AM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:=

Hi all,

=C2=A0

I agree with this draft= becoming a WG document.

=C2=A0

Best,

Benjamin<= /p>



On Jul 24, 2018, at 10:= 44 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wr= ote:

=C2=A0

All,

=C2=A0

The sense of the MLS@IETF102 room was=C2=A0the WG=C2=A0shou= ld adopt https://d= atatracker.ietf.org/doc/draft-barnes-mls-protocol/ as a WG item. We have marked the draft as a "Candidate for WG Adoptio= n=E2=80=9D in the=C2=A0datatracker, but now it=E2=80=99s time to offic= ially do the WG call for adoption. So, if you would like for this draft to = become a WG document and you are willing to review various versions as it moves t= hrough the process, then please let the list know by 2359UTC 2018.08.03. If= you are opposed to this being a WG document, please say so (and say why).<= u>

=C2=A0

Cheers,

=C2=A0

Nick and Sean

=C2=A0

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

=C2=A0

_______________________= ________________________
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


--
Jo= seph Lorenzo Hall
Chief Technologist, Center for Democracy & Technol= ogy [https://www.cdt.org<= /a>]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: <= a href=3D"https://josephhall.org/gpg-key" target=3D"_blank">https://josephh= all.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F8= 6 6987 40A9 A871

--0000000000009136530571c2c8cc-- From nobody Tue Jul 24 11:18:38 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2965131189 for ; Tue, 24 Jul 2018 11:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 sYUneEM2zSsj for ; Tue, 24 Jul 2018 11:18:21 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD327130ED6 for ; Tue, 24 Jul 2018 11:18:20 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id k8-v6so3367301uaq.12 for ; Tue, 24 Jul 2018 11:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3U7jLUPkMeehaTJvvTdFclllx5NsA8LDNx72nJRQRFg=; b=sQBrsk/P6ShO6uNfyBEJ8KRCmIzud/6zpO96NTEomUs7zcFi4ZK/5HqrhwVLkgpPoT Qd46ozKp/UelGbWzCIsdJ4XXZGXZ2C6ALshrbBFVWrcjkDJvBrt1JKXR4qB5TlQbxUqV wruKbahLgqVr3+UWrfS2lxpgekbRLUaxnfAoo= 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=3U7jLUPkMeehaTJvvTdFclllx5NsA8LDNx72nJRQRFg=; b=eXHLZL8NBixvJw7TXPrfKApCuNihHFu51N+qbzPdjcjPG2cUrOk+HJBUwLoTD62txB vK5ClclgUVgVQ0wPwlPlyj8O5Qd93g1ba5MoV1l4X2he1Lhl3SXCdBQjy2t5EyKJ8Rux z5Zz2S+xpimn5Z2t5dqHHEpLpv8JLZKlRcqgLfM75XMTiTlqHBN9c9jvBNa7Oy71GEwQ 1+BAZJKHyiWC/Q4v38n3sZDPvAo6neQAUwetQz5wqOBK83IE6Vt4q4kZfILhO0LNqeU5 y4lXv78a41WO4RBHPkC74V1DEvt06jjVYjVxC+jYcIH16/nU8cmGcYP1G3FcGzDNxiPd T61A== X-Gm-Message-State: AOUpUlGfyvBEZ5sgTpqqjfObXG7xDTMal362uHGD4EG5+A8OV0WCnhGL GQI0++Q4GxPP6VsA5aYarO38+VODb/EbZLe8ABU+bNfIj10= X-Google-Smtp-Source: AAOMgpdNAlU5NAChutCgvuMdiqUdZmDIFwD5PqPLaNgsk2GoDra6kpc55uDzwG0m8A+El6Gd2l9zo0q0AgeuB2plbuQ= X-Received: by 2002:ab0:50cd:: with SMTP id d13-v6mr12613966uaa.45.1532456299730; Tue, 24 Jul 2018 11:18:19 -0700 (PDT) MIME-Version: 1.0 References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> In-Reply-To: From: Joseph Lorenzo Hall Date: Tue, 24 Jul 2018 14:18:08 -0400 Message-ID: To: Suhas Nandakumar Cc: benjamin.beurdouche@inria.fr, mls@ietf.org, nick=40cloudflare.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="0000000000006199850571c2c92b" Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:18:35 -0000 --0000000000006199850571c2c92b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Tue, Jul 24, 2018 at 1:58 PM Suhas Nandakumar wrote: > I am following this work closely and support it=E2=80=99s adoption > > Thanks > ./s > > On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche < > benjamin.beurdouche@inria.fr> wrote: > >> Hi all, >> >> I agree with this draft becoming a WG document. >> >> Best, >> Benjamin >> >> >> On Jul 24, 2018, at 10:44 AM, Nick Sullivan < >> nick=3D40cloudflare.com@dmarc.ietf.org> wrote: >> >> All, >> >> The sense of the MLS@IETF102 room was the WG should adopt >> https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ as a WG >> item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D = in the >> datatracker, but now it=E2=80=99s time to officially do the WG call for = adoption. >> So, if you would like for this draft to become a WG document and you are >> willing to review various versions as it moves through the process, then >> please let the list know by 2359UTC 2018.08.03. If you are opposed to th= is >> being a WG document, please say so (and say why). >> >> Cheers, >> >> Nick and Sean >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --0000000000006199850571c2c92b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Tue, Jul 24, 2018 at 1:58 PM Suhas Nandakumar <suhasietf@gmail.com> wrote:
I am following this work closely = and support it=E2=80=99s adoption=C2=A0

Thanks
./s

On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche <benjamin.be= urdouche@inria.fr> wrote:
Hi all,=

I agree with this draft becoming a WG document.
Best,
Benjamin


On Jul 24, 2018, at 10:44 AM, Nick Sullivan <nick=3D40cl= oudflare.com@dmarc.ietf.org> wrote:

All,<= /div>

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

Cheers,

Nick= and Sean
_______________________________________________
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


--
Jo= seph Lorenzo Hall
Chief Technologist, Center for Democracy & Technol= ogy [https://www.cdt.org<= /a>]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: <= a href=3D"https://josephhall.org/gpg-key" target=3D"_blank">https://josephh= all.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F8= 6 6987 40A9 A871

--0000000000006199850571c2c92b-- From nobody Tue Jul 24 11:33:42 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 4D922130E2F for ; Tue, 24 Jul 2018 11:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=bLjBvFMS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fnM0SCdw 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 b8U6EEfzJ1-C for ; Tue, 24 Jul 2018 11:33:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76ABD130DC4 for ; Tue, 24 Jul 2018 11:33:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CD9F921D28 for ; Tue, 24 Jul 2018 14:33:37 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 24 Jul 2018 14:33:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=IgBV2w+u+npwWRAie4nIBBVNx9 1euyZ3fQB+I1MrpF4=; b=bLjBvFMS5iplWdMjIsPY0M5p01ynpnyM/UTAAjWRz3 pNmku4oHkhmfCVOwwMEXuOJt1qqSZnHXOKvoNuC5ZPQQ4pzyUL6I55ZtnX16aMbU E9+/focd4NX0y9J3r6yGxSGUeKOYGeZVdYzL7hKGcOti3+Km6q12DezQdN2+UAwJ Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=IgBV2w +u+npwWRAie4nIBBVNx91euyZ3fQB+I1MrpF4=; b=fnM0SCdw7vLdan6vdNizm8 hqms2jFyNfLu+JK5lFYKfR1QDSAP2oHLHEzL/gRIuxCp+x38bDX5BLThi5wjs7DX tSO4L3jwF99k476AgBHtr+JnCF904XJFwPU9tJG/0UJq2nTYds1kI8etQ/mJP+eI z014zW2baLbktF8qkKQekWGCFkRQXvauipyuweNnELcSri3/FgWkVXMSjPs0kDId bLqNXK90t2cOKJu1vbHLo+dbyTMGw1zmt1yIG1jGfoJeBrzZLo98BuZjPZzx8/+I 1exwHpKxFRaKcnqOxkWOpP/caxqFgiuMVyIo/bNSeDWL+qWhH4Qr9W0shau22j3w == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 543F09E498; Tue, 24 Jul 2018 14:33:37 -0400 (EDT) Message-Id: <1532457217.553852.1451537168.6900AD72@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15324572175538520" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> Date: Tue, 24 Jul 2018 19:33:37 +0100 In-Reply-To: Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:33:42 -0000 This is a multi-part message in MIME format. --_----------=_15324572175538520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +1 On Tue, 24 Jul 2018, at 7:18 PM, Joseph Lorenzo Hall wrote: > +1 >=20 > On Tue, Jul 24, 2018 at 1:58 PM Suhas Nandakumar > wrote:>> I am following this work closely and suppo= rt it=E2=80=99s adoption=20 >>=20 >> Thanks >> ./s >>=20 >> On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche >> wrote:>>> Hi all, >>>=20 >>> I agree with this draft becoming a WG document. >>>=20 >>> Best, >>> Benjamin >>>=20 >>>=20 >>>> On Jul 24, 2018, at 10:44 AM, Nick Sullivan >>>> wrote:>>>>=20 >>>> All, >>>>=20 >>>> The sense of the MLS@IETF102 room was the WG should adopt >>>> https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ as a >>>> WG item. We have marked the draft as a "Candidate for WG Adoption=E2= =80=9D >>>> in the datatracker, but now it=E2=80=99s time to officially do the WG = call >>>> for adoption. So, if you would like for this draft to become a WG >>>> document and you are willing to review various versions as it moves >>>> through the process, then please let the list know by 2359UTC >>>> 2018.08.03. If you are opposed to this being a WG document, please >>>> say so (and say why).>>>>=20 >>>> Cheers, >>>>=20 >>>> Nick and Sean >>>> _______________________________________________ >>>> 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 >=20 >=20 > --=20 > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology [ > https://www.cdt.org]> 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --_----------=_15324572175538520 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
+1


On Tue, 24 Jul 2018, at 7:18 PM, Joseph Lorenzo Hall wrote:
+1

On Tue, Jul 24, 2018 a= t 1:58 PM Suhas Nandakumar <suhas= ietf@gmail.com> wrote:
I am following this work closely and support it=E2=80=99s adoption&n= bsp;

Thanks
./s

On Tue, Jul 24, 2018 at 10:54 AM B= enjamin Beurdouche <benj= amin.beurdouche@inria.fr> wrote:
Hi all,=

I agree with this draft becoming= a WG document.

Best,
Benjamin


On Jul 24, 2018, at 10:44 AM, Nick Sullivan = <nick=3D40clou= dflare.com@dmarc.ietf.org> wrote:

All,

The sense of the MLS@IETF102 room was the WG should adopt https://data= tracker.ietf.org/doc/draft-omara-mls-architecture/ as a WG item. We hav= e marked the draft as a "Candidate for WG Adoption=E2=80=9D in the datatrac= ker, but now it=E2=80=99s time to officially do the WG call for adoption. S= o, if you would like for this draft to become a WG document and you are wil= ling to review various versions as it moves through the process, then pleas= e let the list know by 2359UTC 2018.08.03. If you are opposed to this being= a WG document, please say so (and say why).

Cheers,

Nick and Sean
________________________________= _______________
MLS mailing list

________________________________= _______________
MLS mailing list
________________________________= _______________
MLS mailing list


--
Joseph Lorenzo Hall
Chief Technologist, Center for D= emocracy & Technology [https://www.cdt.= org]
1401 K ST NW STE 200, Washington= DC 20005-3497
Fingerprint: 3CA2 8D7B 9F6D DBD3= 4B10  1607 5F86 6987 40A9 A871
_______________________________________________
MLS mailing list

--_----------=_15324572175538520-- From nobody Tue Jul 24 11:33:58 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B429130E2F for ; Tue, 24 Jul 2018 11:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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=al6GAzPn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i0smD/F2 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 vXgwq1RtkOGK for ; Tue, 24 Jul 2018 11:33:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBAA8130DC4 for ; Tue, 24 Jul 2018 11:33:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5412721DB7 for ; Tue, 24 Jul 2018 14:33:51 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 24 Jul 2018 14:33:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=ey4xv5J9Pe1UXI0qpAyZiTo4oq 0eGYGBrkBAxMbrVB4=; b=al6GAzPnS4YCUfKGKEyPNeDWCK/YUEa//Cm0wWlbtY 7E+TMv0DcGdsQrD9E4YoUpQj2+KlYYIdeoSrYzJsPSdNbm06iSF5mgv2iJRbeDXK DVV0E3tzkX5QVz/lIx4i0DNZo4N66buqNE5vAQDoa69SUewA14no8bAkbgHMswAQ o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ey4xv5 J9Pe1UXI0qpAyZiTo4oq0eGYGBrkBAxMbrVB4=; b=i0smD/F2BG4hIukNhhD1uu WhZy77zoFckxfEc6nf9Po0YqkzHCbo+2EhT68L7JJTYxUckcxyYSASBCN+EzKfVo brV/4V4LTHtCzw4avpfo7IyZfDJo4O3e4T+OMPOkPprZj53xx5oZb1tq1FVoxa4D DFcsYv0QPYXczs6UdkTVk2CqhOByRrBt9nRH1rJGQtbYxiJjuQgMjyI/+eFo0uh0 eAhNbpC275nhsw4A9u9W3t17C4U0YFte/CwCuI7gmXRfA/GBFyU2Aq3H1YYqnOSR 8/kwBhkIvmDUN9f9M0Xg+El5GTiYf3+NGCtCm6ZwXmzrwUjwh1kJqBEtnLJwy3rQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1711B9E498; Tue, 24 Jul 2018 14:33:51 -0400 (EDT) Message-Id: <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15324572315538512" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> In-Reply-To: Date: Tue, 24 Jul 2018 19:33:50 +0100 Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:33:56 -0000 This is a multi-part message in MIME format. --_----------=_15324572315538512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +1 On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote: > I support adoption >=20 > On Tue, Jul 24, 2018 at 1:58 PM Jon Millican wrote:>> = I also support adoption.____ >> __ __ >> On 24/07/2018, 18:57, "MLS on behalf of Suhas Nandakumar" > bounces@ietf.org on behalf of suhasietf@gmail.com> wrote:____>> __ __ >> I support the adoption ____ >> __ __ >> On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche >> wrote:____>>> Hi all,____ >>> __ __ >>> I agree with this draft becoming a WG document. ____ >>> __ __ >>> Best,____ >>> Benjamin____ >>>=20 >>> ____ >>>> On Jul 24, 2018, at 10:44 AM, Nick Sullivan >>>> wrote:____>>>> __ __ >>>> All,____ >>>> __ __ >>>> The sense of the MLS@IETF102 room was the WG should adopt >>>> https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/[1] as a >>>> WG item. We have marked the draft as a "Candidate for WG Adoption=E2= =80=9D >>>> in the datatracker, but now it=E2=80=99s time to officially do the WG = call >>>> for adoption. So, if you would like for this draft to become a WG >>>> document and you are willing to review various versions as it moves >>>> through the process, then please let the list know by 2359UTC >>>> 2018.08.03. If you are opposed to this being a WG document, please >>>> say so (and say why).____>>>> __ __ >>>> Cheers,____ >>>> __ __ >>>> Nick and Sean____ >>>> __ __ >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls[2]____ >>> __ __ >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls[3]____ >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 >=20 > --=20 > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology [ > https://www.cdt.org]> 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls Links: 1. https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet= f.org_doc_draft-2Dbarnes-2Dmls-2Dprotocol_&d=3DDwMFaQ&c=3D5VD0RTtNlTh3ycd41= b3MUw&r=3DM0CVEJydBVUX_bvEqMa84Q&m=3DB6-mjYW5uyVI2qw-MaVbUiOUAxD84UOJo-Ac9J= hxwjc&s=3Dl3gZ0C1y6rTDc75njm2K3G29fDbc9kactkuesbwyhXY&e=3D 2. https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_mls&d=3DDwMFaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_b= vEqMa84Q&m=3DB6-mjYW5uyVI2qw-MaVbUiOUAxD84UOJo-Ac9Jhxwjc&s=3DxJ7rUly2CsxnQZ= kIOthxWc48PmjCIosd_X-h_1OWctY&e=3D 3. https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_mls&d=3DDwMFaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_b= vEqMa84Q&m=3DB6-mjYW5uyVI2qw-MaVbUiOUAxD84UOJo-Ac9Jhxwjc&s=3DxJ7rUly2CsxnQZ= kIOthxWc48PmjCIosd_X-h_1OWctY&e=3D --_----------=_15324572315538512 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
+1


On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote:
I support adoption

On Tue, Jul 24, 2018 a= t 1:58 PM Jon Millican <jmillican@fb= .com> wrote:

I also support adoption.

<= u> 

On 24/0= 7/2018, 18:57, "MLS on behalf of Suhas Nandakumar" <mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote:
<= /p>

 

I support the adoption 

 

On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouc= he <benjamin.beurdouche@= inria.fr> wrote:

Hi all,

 

I agree with this draft becoming a WG docume= nt.

 =

Best,

Benjamin



On Jul 24, 2018, at 10:44 AM, Nick Sullivan <nick=3D40cloudflare.c= om@dmarc.ietf.org> wrote:

 

<= p style=3D"margin-left:36pt;">All,

 

The sense of the MLS@IETF102 room was the WG = should adopt https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/= as a WG item. We have marked the draft as a "Candidate for WG Adopt= ion=E2=80=9D in the datatracker, but now it=E2=80=99s tim= e to officially do the WG call for adoption. So, if you would like for this= draft to become a WG document and you are willing to review various versions as it moves t= hrough the process, then please let the list know by 2359UTC 2018.08.03. If= you are opposed to this being a WG document, please say so (and say why).<= u>

 

Cheers,

 

Nick and Sean

 

_= ______________________________________________
MLS mailing list

 

_= ______________________________________________
MLS mailing list

________________________________= _______________
MLS mailing list


--
Joseph Lorenzo Hall
Chief Technologist, Center for D= emocracy & Technology [https://www.cdt.= org]
1401 K ST NW STE 200, Washington= DC 20005-3497
Fingerprint: 3CA2 8D7B 9F6D DBD3= 4B10  1607 5F86 6987 40A9 A871
_______________________________________________
MLS mailing list
--_----------=_15324572315538512-- From nobody Tue Jul 24 11:34:35 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 C4054130E2F for ; Tue, 24 Jul 2018 11:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=kajCa60o; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Of0EjXpo 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 4tCkt9Qck0GH for ; Tue, 24 Jul 2018 11:34:32 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 05A65130DC4 for ; Tue, 24 Jul 2018 11:34:31 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w6OHv82L009295; Tue, 24 Jul 2018 10:59:56 -0700 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=AhEPp5qBLOmpiE8BLKIjTP34TdbEXL2KuV9+XTz9ctk=; b=kajCa60ol/Sg6lZH/bTg6RYxXt7etygMBXX/b0Xn9hzAz0bk2bgR+EPtwFZ93mHbaOvH ADOwarvheNTtyC/jgRY0/Vswe8vY2O8C1BQaOY5SLtPB7pvjhO8OpHbrZIxQtXIIRXNC G2Z7jR90oeLYkSwYfLaP7mSLSPdN6F5fQZQ= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2ke7mxgawh-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jul 2018 10:59:56 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.24) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Jul 2018 10:59:53 -0700 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=AhEPp5qBLOmpiE8BLKIjTP34TdbEXL2KuV9+XTz9ctk=; b=Of0EjXpol7P8Rp3hzTIzjpdidlhVApaMh7S7BSMbe7Zuyp0EeUtfJDu/Qj2XwkK1CDuAFMY2nmb/3CJWAAZkSyh06m5WyhOctmdVF+BADN3A81ApDtTO6Rq+QFsDDESniy71hhVWKy7bYpGJglE4WnzDno7SqvioM/c/u/CBrYY= Received: from SN6PR15MB2205.namprd15.prod.outlook.com (52.135.64.145) by SN6PR15MB2365.namprd15.prod.outlook.com (52.135.65.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Tue, 24 Jul 2018 17:59:52 +0000 Received: from SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b]) by SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b%4]) with mapi id 15.20.0995.014; Tue, 24 Jul 2018 17:59:52 +0000 From: Jon Millican To: Suhas Nandakumar , Benjamin Beurdouche CC: ML Messaging Layer Security , Nick Sullivan Thread-Topic: [MLS] Call for adoption: draft-omara-mls-architecture Thread-Index: AQHUI3YlJJdVoMPu0kCAbwrp/6wR3aSep74AgAABCACAABFNgA== Date: Tue, 24 Jul 2018 17:59:52 +0000 Message-ID: References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:200::1:5390] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR15MB2365; 20:Ed/oUKVEtS9tDAdYmDcbgP6wHy0WAIFEVOEtMlrKuZbSursPOLebvflUrdRn1p5GJ289wLzPwl5bZlmGBYTTAtq55R7wNqtCaVjw5FemVTsQZlFVrbHRfDeFhwV6H6fPmr8IcVEnxhCaEIwujV82FOfG+phmWD0O45M5zT4qxfA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b3ad7992-bec5-4bfe-969d-08d5f18f4185 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:SN6PR15MB2365; x-ms-traffictypediagnostic: SN6PR15MB2365: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(120809045254105)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231311)(11241501184)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN6PR15MB2365; BCL:0; PCL:0; RULEID:; SRVR:SN6PR15MB2365; x-forefront-prvs: 0743E8D0A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(346002)(136003)(396003)(199004)(189003)(53754006)(25786009)(478600001)(102836004)(6506007)(53546011)(2900100001)(966005)(14454004)(4326008)(99286004)(6246003)(82746002)(39060400002)(81166006)(8676002)(8936002)(83716003)(486006)(476003)(81156014)(2616005)(186003)(97736004)(46003)(76176011)(105586002)(5660300001)(53936002)(446003)(106356001)(6116002)(316002)(110136005)(229853002)(2906002)(11346002)(7736002)(256004)(606006)(54896002)(6306002)(36756003)(5250100002)(86362001)(68736007)(6512007)(33656002)(6486002)(236005)(6436002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR15MB2365; H:SN6PR15MB2205.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 31BvTpe8hdFRi2lJTFrJFeiWBnmTTJNL+C8htuscOXw4N0Bjx5c8zPKkOHOIALJgk2IHN60T/8EHl9AyUNb94IYxFs8YmTc9eoM/jDl7eW/SBg4uGKEsX/U3kGQUdqhC6Y6PbTBwjrlofrzPPNvse470sYYn9fqEu/bDW+O0Gwe9mO56tRKN+FoA/BOttqYcrts49KvtNA5ltONaE8ZPD6IBa2UvddTRDDlAmD2JtYFSkpv15vKxn2a+/0k0i3WYcOke8Sce14cyzv0QTyRiiQ1HV80Di+JX090hHWjHNCaWN4AbfA1vPBU8FwZYW0qNOYCVe8YdnvWVcXuz1De8Fs7XamPRFyIq7cz7Ca6z3V0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ABD66C917E7B4D10BC57F438D5DEA9FAfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b3ad7992-bec5-4bfe-969d-08d5f18f4185 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2018 17:59:52.3623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2365 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-24_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:34:34 -0000 --_000_ABD66C917E7B4D10BC57F438D5DEA9FAfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQoNCkpvbg0KDQpPbiAyNC8wNy8yMDE4 LCAxODo1OCwgIk1MUyBvbiBiZWhhbGYgb2YgU3VoYXMgTmFuZGFrdW1hciIgPG1scy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHN1aGFz aWV0ZkBnbWFpbC5jb208bWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSSBh bSBmb2xsb3dpbmcgdGhpcyB3b3JrIGNsb3NlbHkgYW5kIHN1cHBvcnQgaXTigJlzIGFkb3B0aW9u DQoNClRoYW5rcw0KLi9zDQoNCk9uIFR1ZSwgSnVsIDI0LCAyMDE4IGF0IDEwOjU0IEFNIEJlbmph bWluIEJldXJkb3VjaGUgPGJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI8bWFpbHRvOmJlbmph bWluLmJldXJkb3VjaGVAaW5yaWEuZnI+PiB3cm90ZToNCkhpIGFsbCwNCg0KSSBhZ3JlZSB3aXRo IHRoaXMgZHJhZnQgYmVjb21pbmcgYSBXRyBkb2N1bWVudC4NCg0KQmVzdCwNCkJlbmphbWluDQoN Cg0KDQpPbiBKdWwgMjQsIDIwMTgsIGF0IDEwOjQ0IEFNLCBOaWNrIFN1bGxpdmFuIDxuaWNrPTQw Y2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOm5pY2s9NDBjbG91ZGZsYXJlLmNv bUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpBbGwsDQoNClRoZSBzZW5zZSBvZiB0aGUgTUxT QElFVEYxMDIgcm9vbSB3YXMgdGhlIFdHIHNob3VsZCBhZG9wdCBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1vbWFyYS1tbHMtYXJjaGl0ZWN0dXJlLzxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYu b3JnX2RvY19kcmFmdC0yRG9tYXJhLTJEbWxzLTJEYXJjaGl0ZWN0dXJlXyZkPUR3TUZhUSZjPTVW RDBSVHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09dWhtVFBOWmM1 SjM0bW1OLTRRTk1lSTZPUUk3ckFVTjFPcmV5UTlVWl92NCZzPVNrVzZuT01WQ3R0VXJSbVlfYU1p MktHak1fX3JsSUtkd0ZwNHNHcWtEcVUmZT0+IGFzIGEgV0cgaXRlbS4gV2UgaGF2ZSBtYXJrZWQg dGhlIGRyYWZ0IGFzIGEgIkNhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb27igJ0gaW4gdGhlIGRhdGF0 cmFja2VyLCBidXQgbm93IGl04oCZcyB0aW1lIHRvIG9mZmljaWFsbHkgZG8gdGhlIFdHIGNhbGwg Zm9yIGFkb3B0aW9uLiBTbywgaWYgeW91IHdvdWxkIGxpa2UgZm9yIHRoaXMgZHJhZnQgdG8gYmVj b21lIGEgV0cgZG9jdW1lbnQgYW5kIHlvdSBhcmUgd2lsbGluZyB0byByZXZpZXcgdmFyaW91cyB2 ZXJzaW9ucyBhcyBpdCBtb3ZlcyB0aHJvdWdoIHRoZSBwcm9jZXNzLCB0aGVuIHBsZWFzZSBsZXQg dGhlIGxpc3Qga25vdyBieSAyMzU5VVRDIDIwMTguMDguMDMuIElmIHlvdSBhcmUgb3Bwb3NlZCB0 byB0aGlzIGJlaW5nIGEgV0cgZG9jdW1lbnQsIHBsZWFzZSBzYXkgc28gKGFuZCBzYXkgd2h5KS4N Cg0KQ2hlZXJzLA0KDQpOaWNrIGFuZCBTZWFuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0 bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21s czxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3lj ZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09dWhtVFBOWmM1SjM0bW1OLTRRTk1l STZPUUk3ckFVTjFPcmV5UTlVWl92NCZzPXhDbnBYNzlwVjVJdDZ0cVNGbmlqdkV6dnB3eHZ1TXVy eEc0WU02QXF6dWMmZT0+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpNTFMgbWFpbGluZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFpbHRvOk1MU0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fbWxzJmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZy PU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT11aG1UUE5aYzVKMzRtbU4tNFFOTWVJNk9RSTdyQVVO MU9yZXlROVVaX3Y0JnM9eENucFg3OXBWNUl0NnRxU0ZuaWp2RXp2cHd4dnVNdXJ4RzRZTTZBcXp1 YyZlPT4NCg== --_000_ABD66C917E7B4D10BC57F438D5DEA9FAfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Sm9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjQvMDcvMjAxOCwgMTg6NTgsICZxdW90 O01MUyBvbiBiZWhhbGYgb2YgU3VoYXMgTmFuZGFrdW1hciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1scy1ib3VuY2VzQGlldGYub3JnIj5tbHMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVo YWxmIG9mDQo8YSBocmVmPSJtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbSI+c3VoYXNpZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JIGFtIGZvbGxvd2luZyB0aGlzIHdvcmsg Y2xvc2VseSBhbmQgc3VwcG9ydCBpdOKAmXMgYWRvcHRpb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmtzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4uL3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9u IFR1ZSwgSnVsIDI0LCAyMDE4IGF0IDEwOjU0IEFNIEJlbmphbWluIEJldXJkb3VjaGUgJmx0Ozxh IGhyZWY9Im1haWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyIj5iZW5qYW1pbi5iZXVy ZG91Y2hlQGlucmlhLmZyPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5JIGFncmVlIHdpdGggdGhpcyBkcmFmdCBiZWNvbWluZyBhIFdHIGRvY3VtZW50 Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CZXN0LDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+QmVuamFtaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ T24gSnVsIDI0LCAyMDE4LCBhdCAxMDo0NCBBTSwgTmljayBTdWxsaXZhbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5pY2s9NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm5pY2s9NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFsbCw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIHNlbnNl IG9mIHRoZSBNTFNASUVURjEwMiByb29tIHdhcyB0aGUgV0cgc2hvdWxkIGFkb3B0DQo8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2Rh dGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRG9tYXJhLTJEbWxzLTJEYXJjaGl0ZWN0dXJl XyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5 ZEJWVVhfYnZFcU1hODRRJmFtcDttPXVobVRQTlpjNUozNG1tTi00UU5NZUk2T1FJN3JBVU4xT3Jl eVE5VVpfdjQmYW1wO3M9U2tXNm5PTVZDdHRVclJtWV9hTWkyS0dqTV9fcmxJS2R3RnA0c0dxa0Rx VSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LW9tYXJhLW1scy1hcmNoaXRlY3R1cmUvPC9hPiBhcyBhIFdHIGl0ZW0uIFdlIGhh dmUgbWFya2VkIHRoZSBkcmFmdCBhcyBhICZxdW90O0NhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb27i gJ0gaW4gdGhlIGRhdGF0cmFja2VyLCBidXQgbm93IGl04oCZcyB0aW1lIHRvIG9mZmljaWFsbHkg ZG8gdGhlIFdHIGNhbGwgZm9yIGFkb3B0aW9uLiBTbywgaWYgeW91IHdvdWxkIGxpa2UgZm9yIHRo aXMgZHJhZnQNCiB0byBiZWNvbWUgYSBXRyBkb2N1bWVudCBhbmQgeW91IGFyZSB3aWxsaW5nIHRv IHJldmlldyB2YXJpb3VzIHZlcnNpb25zIGFzIGl0IG1vdmVzIHRocm91Z2ggdGhlIHByb2Nlc3Ms IHRoZW4gcGxlYXNlIGxldCB0aGUgbGlzdCBrbm93IGJ5IDIzNTlVVEMgMjAxOC4wOC4wMy4gSWYg eW91IGFyZSBvcHBvc2VkIHRvIHRoaXMgYmVpbmcgYSBXRyBkb2N1bWVudCwgcGxlYXNlIHNheSBz byAoYW5kIHNheSB3aHkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPk5pY2sgYW5kIFNlYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk1MUyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ TUxTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f bWxzJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPU0wQ1ZF SnlkQlZVWF9idkVxTWE4NFEmYW1wO209dWhtVFBOWmM1SjM0bW1OLTRRTk1lSTZPUUk3ckFVTjFP cmV5UTlVWl92NCZhbXA7cz14Q25wWDc5cFY1SXQ2dHFTRm5panZFenZwd3h2dU11cnhHNFlNNkFx enVjJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KTUxTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpNTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5NTFNAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFtcDtj PTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7 bT11aG1UUE5aYzVKMzRtbU4tNFFOTWVJNk9RSTdyQVVOMU9yZXlROVVaX3Y0JmFtcDtzPXhDbnBY NzlwVjVJdDZ0cVNGbmlqdkV6dnB3eHZ1TXVyeEc0WU02QXF6dWMmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_ABD66C917E7B4D10BC57F438D5DEA9FAfbcom_-- From nobody Tue Jul 24 11:36: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 5D2821311CF for ; Tue, 24 Jul 2018 11:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 XX7v3MF4BYP2 for ; Tue, 24 Jul 2018 11:36:19 -0700 (PDT) Received: from VirgilSecurity.com (mail.virgilsecurity.com [199.58.211.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B1B1311B2 for ; Tue, 24 Jul 2018 11:36:19 -0700 (PDT) Received: from BIGONE (unknown [176.226.241.68]) by VirgilSecurity.com (Postfix) with ESMTPSA id 54B4B105CF15CE; Tue, 24 Jul 2018 14:36:17 -0400 (EDT) From: "Alexey Ermishkin" To: "'Jon Millican'" , "'Suhas Nandakumar'" , "'Benjamin Beurdouche'" Cc: "'ML Messaging Layer Security'" , "'Nick Sullivan'" References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> In-Reply-To: Date: Tue, 24 Jul 2018 23:36:14 +0500 Message-ID: <00d401d4237d$362e86d0$a28b9470$@virgilsecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01D423A7.1F0BBAC0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJqLrDy9MgAugkDKWWKgdS/qyUtjAGPcVAiAUA0c2UBUCfz46NRnpTA Content-Language: ru Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:36:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D5_01D423A7.1F0BBAC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 =20 From: MLS On Behalf Of Jon Millican Sent: Tuesday, July 24, 2018 11:00 PM To: Suhas Nandakumar ; Benjamin Beurdouche = Cc: ML Messaging Layer Security ; Nick Sullivan = Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture =20 I support adoption of this draft. =20 Jon =20 On 24/07/2018, 18:58, "MLS on behalf of Suhas Nandakumar" = on behalf of = suhasietf@gmail.com > wrote: =20 I am following this work closely and support it=E2=80=99s adoption=20 =20 Thanks ./s =20 On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche = > = wrote: Hi all, =20 I agree with this draft becoming a WG document.=20 =20 Best, Benjamin =20 =20 On Jul 24, 2018, at 10:44 AM, Nick Sullivan = > wrote: =20 All, =20 The sense of the MLS@IETF102 room was the WG should adopt = https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ = as a = WG item. We have marked the draft as a "Candidate for WG = Adoption=E2=80=9D in the datatracker, but now it=E2=80=99s time to = officially do the WG call for adoption. So, if you would like for this = draft to become a WG document and you are willing to review various = versions as it moves through the process, then please let the list know = by 2359UTC 2018.08.03. If you are opposed to this being a WG document, = please say so (and say why). =20 Cheers, =20 Nick and Sean _______________________________________________ MLS mailing list MLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/mls = =20 =20 _______________________________________________ MLS mailing list MLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/mls = =20 ------=_NextPart_000_00D5_01D423A7.1F0BBAC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1

 

From: MLS = <mls-bounces@ietf.org> On Behalf Of Jon = Millican
Sent: Tuesday, July 24, 2018 11:00 PM
To: = Suhas Nandakumar <suhasietf@gmail.com>; Benjamin Beurdouche = <benjamin.beurdouche@inria.fr>
Cc: ML Messaging Layer = Security <mls@ietf.org>; Nick Sullivan = <nick=3D40cloudflare.com@dmarc.ietf.org>
Subject: Re: = [MLS] Call for adoption: = draft-omara-mls-architecture

 

I support adoption of this draft.

 

Jon

 

On 24/07/2018, 18:58, = "MLS on behalf of Suhas Nandakumar" <mls-bounces@ietf.org on behalf = of suhasietf@gmail.com> = wrote:

 

I am = following this work closely and support it=E2=80=99s = adoption 

 

Thanks

./s

 

On Tue, Jul 24, 2018 at = 10:54 AM Benjamin Beurdouche <benjamin.beurdouche@inria.fr= > wrote:

Hi all,

 

I agree with this draft = becoming a WG document.

 

Best,

Benjamin

 

 

On Jul 24, 2018, at = 10:44 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

 

All,

 

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

 

Cheers,

 

Nick and = Sean

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

 

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

------=_NextPart_000_00D5_01D423A7.1F0BBAC0-- From nobody Tue Jul 24 11:40:04 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 4E0711311A5 for ; Tue, 24 Jul 2018 11:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.57 X-Spam-Level: X-Spam-Status: No, score=0.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9-2kNbOjb9kl for ; Tue, 24 Jul 2018 11:39:59 -0700 (PDT) Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com [209.85.217.179]) (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 0E22713119E for ; Tue, 24 Jul 2018 11:39:59 -0700 (PDT) Received: by mail-ua0-f179.google.com with SMTP id x24-v6so3419207ual.10 for ; Tue, 24 Jul 2018 11:39:58 -0700 (PDT) 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=Uk7HvmHXU87XEDwudjC5Y1ptWHKbQOvk23O8kKmFpR0=; b=AL+ChhUqy9l6+ygu/o1X2PVmKctnoITzd5WCjr/G4ihsKxZ4TF0N/o7XzUhqsqLisV iR5CE8oXP6lM7mKeQImWFtwO6i5CBDSHO8ziMvMKE8wtdFTpeCMklKneh6Bx1ARZCeay Dzv5K4s2wiNUtZ3LQb1C4o/pcp/l4Mc2hUkBchVyF5M/1m7SRuk74rDjiBcX0j76flh4 TLHAwIYcHjCQflYwhCu3Fct1UQr4wlM1RcJP7Pdmxlj48NFJ91vMUviSinQ5bTW3npEC kNlJI1FLi1zXl/fuQEu6opeXpZ0WYpCpfWCxlcMRTSFv9db+GaCEiarOA948+5VFGgim 7bIQ== X-Gm-Message-State: AOUpUlG4BseBxYoOEaFPjMOCbLHP9XsWQ5VBZW332NzXAE43CiWpYh5f 9O6nmK0ISiPJrc4oo6Hi5cUYPlZalI4futJEGYA= X-Google-Smtp-Source: AAOMgpe8tVjRQfvdAz6HjCjE/t663OIOg3ZTDSbaKXfETxv4vCWeFeKccGOQpaa0OIKmN/Mjrj6yiADEJ/lB0BE3dnA= X-Received: by 2002:ab0:5097:: with SMTP id c23-v6mr12249656uaa.43.1532457597914; Tue, 24 Jul 2018 11:39:57 -0700 (PDT) MIME-Version: 1.0 References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> In-Reply-To: From: Cas Cremers Date: Tue, 24 Jul 2018 20:39:17 +0200 Message-ID: To: Jon Millican Cc: Benjamin Beurdouche , ML Messaging Layer Security , Nick Sullivan , Suhas Nandakumar Content-Type: multipart/alternative; boundary="000000000000c1d5330571c316da" Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:40:01 -0000 --000000000000c1d5330571c316da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Tue, 24 Jul 2018, 20:34 Jon Millican, wrote: > I support adoption of this draft. > > > > Jon > > > > On 24/07/2018, 18:58, "MLS on behalf of Suhas Nandakumar" < > mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote: > > > > I am following this work closely and support it=E2=80=99s adoption > > > > Thanks > > ./s > > > > On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche < > benjamin.beurdouche@inria.fr> wrote: > > Hi all, > > > > I agree with this draft becoming a WG document. > > > > Best, > > Benjamin > > > > > > On Jul 24, 2018, at 10:44 AM, Nick Sullivan < > nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > > > > All, > > > > The sense of the MLS@IETF102 room was the WG should adopt > https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ > > as a WG item. We have marked the draft as a "Candidate for WG Adoption=E2= =80=9D in > the datatracker, but now it=E2=80=99s time to officially do the WG call f= or > adoption. So, if you would like for this draft to become a WG document an= d > you are willing to review various versions as it moves through the proces= s, > then please let the list know by 2359UTC 2018.08.03. If you are opposed t= o > this being a WG document, please say so (and say why). > > > > Cheers, > > > > Nick and Sean > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000c1d5330571c316da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1

On Tue, 24 Jul 2018, = 20:34 Jon Millican, <jmillican@fb.co= m> wrote:

I support adoption of this draft.

<= /div>

=C2=A0

Jon

=C2=A0

On 24/07/2018, 18:58, &= quot;MLS on behalf of Suhas Nandakumar" <mls-bounces@ietf.org on behalf of suhasietf@gmail.co= m> wrote:

=C2=A0

I am following this wor= k closely and support it=E2=80=99s adoption=C2=A0

=C2=A0

Thanks

./s

=C2=A0

On Tue, Jul 24, 2018 at= 10:54 AM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:=

Hi all,

=C2=A0

I agree with this draft= becoming a WG document.

=C2=A0

Best,

Benjamin<= /p>

=C2=A0



On Jul 24, 2018, at 10:= 44 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wr= ote:

=C2=A0

All,

=C2=A0

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

=C2=A0

Cheers,

=C2=A0

Nick and Sean=

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

=C2=A0

_______________________= ________________________
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
--000000000000c1d5330571c316da-- From nobody Tue Jul 24 11:40: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 07D121311A5 for ; Tue, 24 Jul 2018 11:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4VqHjVd5yu2v for ; Tue, 24 Jul 2018 11:40:02 -0700 (PDT) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) (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 5F50D130DC4 for ; Tue, 24 Jul 2018 11:40:00 -0700 (PDT) Received: by mail-ua0-f169.google.com with SMTP id y10-v6so3422144uao.4 for ; Tue, 24 Jul 2018 11:40:00 -0700 (PDT) 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=pJlvfi9KukODEbgSxM9vIPED0eL10MpUd/Jyw+aDBrg=; b=XMXFzIcWICAboC8laRlHMAbuZd28qnsQlUf167pFK7JYbrpDghcDpyLU2ViLpTA22G Z/Tdg83jDNBLaQc03R0Kgk9T9TO/4vdvvT1Rw3DY7qYl/2R7hAsHlcwi0CIzHgzWcxzC JujH6iLkqf/KGxMwMfZCjgj7QHlikjhovz8hKtYOLIvr8ODOt0P83nhCLxg7tYkDOSfM FteEiQzemYRSQNTGnfL/sdGAd92pqf5MLanFwy2udXDhTQYXKrH9F3HQ6FRtNIFzwOF7 +2YFqibhiGOUvIHferbSmQBe7Scv0eGZvpPcHlPcxHMjvo9mVn7x/HbRh/W1hywpnyaH PS3A== X-Gm-Message-State: AOUpUlGmN3K9GPhlhCwzPyPxvUIBLn8f816NnXoOhOetrGmZz1D+bEMQ 9lcQbt/Z3oQYpVKR0WiMSAw+TCHeRTZWwQxcHOKzyk88 X-Google-Smtp-Source: AAOMgpdYVjNq1F4EuBtE8sqZjvFQwObXP92sUR5+oEaTl2Q+R5tqjMgdBu+bSJCA8PlGpWEzYVyenQHDshyKvJkVlfY= X-Received: by 2002:ab0:1724:: with SMTP id j36-v6mr12635201uaf.0.1532457599214; Tue, 24 Jul 2018 11:39:59 -0700 (PDT) MIME-Version: 1.0 References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> In-Reply-To: <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> From: Cas Cremers Date: Tue, 24 Jul 2018 20:39:44 +0200 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5a8290571c31664" Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:40:04 -0000 --000000000000d5a8290571c31664 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 On Tue, 24 Jul 2018, 20:34 Katriel Cohn-Gordon, wrote: > +1 > > > On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote: > > I support adoption > > > On Tue, Jul 24, 2018 at 1:58 PM Jon Millican > wrote: > > I also support adoption. > > > > On 24/07/2018, 18:57, "MLS on behalf of Suhas Nandakumar" < > mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote: > > > > I support the adoption > > > > On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche < > benjamin.beurdouche@inria.fr> wrote: > > Hi all, > > > > I agree with this draft becoming a WG document. > > > > Best, > > Benjamin > > > > On Jul 24, 2018, at 10:44 AM, Nick Sullivan < > nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > > > > All, > > > > The sense of the MLS@IETF102 room was the WG should adopt > https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ > > as a WG item. We have marked the draft as a "Candidate for WG Adoption=E2= =80=9D in > the datatracker, but now it=E2=80=99s time to officially do the WG call f= or > adoption. So, if you would like for this draft to become a WG document an= d > you are willing to review various versions as it moves through the proces= s, > then please let the list know by 2359UTC 2018.08.03. If you are opposed t= o > this being a WG document, please say so (and say why). > > > > Cheers, > > > > Nick and Sean > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > > -- > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology [https://www.cdt.or= g > ] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > *_______________________________________________* > 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 > --000000000000d5a8290571c31664 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1

On Tue, 24 Jul 2018, = 20:34 Katriel Cohn-Gordon, <me@katri= el.co.uk> wrote:
+1


On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote:
I support adoption

On Tue, Jul 24, 2018 at 1:58 PM Jon Millican <jmillican@fb..com>= wrote:

I also su= pport adoption.

=C2=A0

On 24/07/2018, 18:57, "MLS on behalf = of Suhas Nandakumar" <mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote:<= u>

=C2=A0

I support the adoption=C2=A0=

=C2=A0

On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche= <benj= amin.beurdouche@inria.fr> wrote:

<= p style=3D"margin-left:36pt">Hi all,

=C2=A0

I agree with this draft becoming a WG documen= t.

=C2=A0

Best,

Benjamin



On Jul 24, 2018, at 10:44 AM, Nick Sullivan <nick= =3D40cloudflare.com@dmarc.ietf.org> wrote:

=C2=A0

All,

=C2=A0

The sense of the MLS@IETF102 room was=C2=A0the WG=C2=A0should adopt http= s://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ as a WG = item. We have marked the draft as a "Candidate for WG Adoption=E2=80= =9D in the=C2=A0datatracker, but now it=E2=80=99s time to offi= cially do the WG call for adoption. So, if you would like for this draft to= become a WG document and you are willing to review various versions as it moves t= hrough the process, then please let the list know by 2359UTC 2018.08.03. If= you are opposed to this being a WG document, please say so (and say why).<= u>

=C2=A0

Cheers,

=C2=A0

Nick and Sean

=C2=A0

= _______________________________________________
MLS mailing list

=C2=A0

= _______________________________________________
MLS mailing list

__________________________________= _____________
MLS mailing list


--
Joseph Lorenzo Hall
Chief Technologist, Center for Dem= ocracy & Technology [= https://www.cdt.org]
1401 K ST NW STE 200, Washington D= C 20005-3497
Fingerprint: 3CA2 8D7B 9F6D DBD3 4= B10 =C2=A01607 5F86 6987 40A9 A871
_______________________________________________
MLS mailing list
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d5a8290571c31664-- From nobody Tue Jul 24 11:43:17 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF36913119E for ; Tue, 24 Jul 2018 11:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, 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 EUPL5VmB1Otd for ; Tue, 24 Jul 2018 11:43:12 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 A6913130DEC for ; Tue, 24 Jul 2018 11:43:12 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id e139-v6so2559783vkf.6 for ; Tue, 24 Jul 2018 11:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FHlngh8TYPx93yG0zzKv+bQtu5MY88xCSoIhIE5nm1A=; b=V/ECYxHU4/5athhv0swzqVI9S2tMtkF8jTbnBW3ZW7+rqZ84ghf7KfJBdcWsfPgyat iUAQnMj1ywEvU58JJXKUcxvYSMU3EF70XA5BlSNIBXvl1nRa6o1oHY6BF1NbKGH92guQ lxoSAbK7gRDwj+weANBWB6KTIlapk+zF/OaA6lOfbgM0QPbEyyv726qfIZSvJjH9Rfkd CX74RPWTSMqDDyLCMAtj+Rin2kiPSXlzlDykHy14WtfJWjpzUOu9UFsN64UBX2IZFRxI YcgopaZj46tjUkSRtG0i3K0z1NODHL1JFwKNjB6pWT/nOe8f9PiPIOoFfepK8SuGepZ/ 8bGw== 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=FHlngh8TYPx93yG0zzKv+bQtu5MY88xCSoIhIE5nm1A=; b=Sjxlijlf8sZPwLhoVsFLM6zDzn4d/IoVxMPs5zroyddv/hzO3hzkFRjCdAMqwPucUM WrW7JDh7Benb/thuv/ko0skIltPLvGPnssmYzozxenDqeURXPPouVDS0PBwCPf61yQyC 4yTihg2FoyluHCbQ7gmYWivK1tIz7qFHj8JWEBVzed7xWsBgKFP9PccvxygW0UGqqAyB glyKVDes1Z7pYerOmw73kW1iFAlT1Qu0P95fa2P9KGQ0TCU21snuJUDISh64qol2Cc0w 6snqImwZJHQvBdqs/9IjnlKCq3ZbR0rv9t3LgXrF5tecQ/LYS5xpjByq0OuUFvFw2N4H Y+EA== X-Gm-Message-State: AOUpUlH3oPfuBjo2OVgyYoSlfLqSNJZTfZpdYOaZDM+EgZtRnKGZAGKE PjdpgU08SeLtkRLTwalqweQMdhha6+Wj3Y27C8ZA4w== X-Google-Smtp-Source: AAOMgpeAf5fNM1ZdEg32frdT2vzjjbYBarjzKuoE7Kk/NKP40ms1isdBjfQKHtVD38cY3Y4PAfKWi9pO7MMwP0pBYj4= X-Received: by 2002:a1f:97d4:: with SMTP id z203-v6mr6794627vkd.133.1532457791689; Tue, 24 Jul 2018 11:43:11 -0700 (PDT) MIME-Version: 1.0 References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Tue, 24 Jul 2018 21:43:00 +0300 Message-ID: To: Cas Cremers Cc: Benjamin Beurdouche , Jon Millican , ML Messaging Layer Security , Nick Sullivan , Suhas Nandakumar Content-Type: multipart/alternative; boundary="0000000000004e97a40571c32238" Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:43:16 -0000 --0000000000004e97a40571c32238 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption. =D0=B2=D1=82, 24 =D0=B8=D1=8E=D0=BB=D1=8F 2018 =D0=B3. =D0=B2 21:40, Cas Cr= emers : > +1 > > On Tue, 24 Jul 2018, 20:34 Jon Millican, wrote: > >> I support adoption of this draft. >> >> >> >> Jon >> > >> >> On 24/07/2018, 18:58, "MLS on behalf of Suhas Nandakumar" < >> mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote: >> >> >> > I am following this work closely and support it=E2=80=99s adoption >> >> >> >> Thanks >> >> ./s >> >> >> > On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche < >> benjamin.beurdouche@inria.fr> wrote: >> > Hi all, >> >> >> >> I agree with this draft becoming a WG document. >> >> >> >> Best, >> >> Benjamin >> >> On Jul 24, 2018, at 10:44 AM, Nick Sullivan < >> nick=3D40cloudflare.com@dmarc.ietf.org> wrote: >> >> >> >> All, >> >> >> >> The sense of the MLS@IETF102 room was the WG should adopt >> https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ >> >> as a WG item. We have marked the draft as a "Candidate for WG Adoption= =E2=80=9D in >> the datatracker, but now it=E2=80=99s time to officially do the WG call = for >> adoption. So, if you would like for this draft to become a WG document a= nd >> you are willing to review various versions as it moves through the proce= ss, >> then please let the list know by 2359UTC 2018..08.03. If you are opposed= to >> this being a WG document, please say so (and say why). >> >> >> >> Cheers, >> >> >> >> Nick and Sean >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> _______________________________________________ >> 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 > --0000000000004e97a40571c32238 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption.=C2=A0

=D0=B2=D1=82, 24 =D0=B8=D1=8E=D0=BB= =D1=8F 2018 =D0=B3. =D0=B2 21:40, Cas Cremers <cas.cremers@cs.ox.ac.uk>:
+1

On Tue, 24 Jul 2018, 20:34 Jon Millican, <jmillican@fb.com>= ; wrote:

I support adoption of this draft.

<= /div>

=C2=A0

Jon

=

=C2=A0

On 24/07/2018, 18:58, &= quot;MLS on behalf of Suhas Nandakumar" <mls-bounces@ietf.org on behalf of suhasietf@gmail.co= m> wrote:

=C2=A0

I am following this wor= k closely and support it=E2=80=99s adoption=C2=A0

=C2=A0

Thanks

./s

=C2=A0

On Tue, Jul 24, 2018 at= 10:54 AM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:=

Hi all,

=C2=A0

I agree with this draft= becoming a WG document.

=C2=A0

Best,

Benjamin<= /p>

On Jul 24, 2018, at 10:= 44 AM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wr= ote:

=C2=A0

All,

=C2=A0

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

=C2=A0

Cheers,

=C2=A0

Nick and Sean=

<= /div>

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

<= /blockquote>

_______________________= ________________________
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
--0000000000004e97a40571c32238-- From nobody Tue Jul 24 11:44:21 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BC213119E for ; Tue, 24 Jul 2018 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, 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 7gbQTZjDvngu for ; Tue, 24 Jul 2018 11:44:16 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB501311A8 for ; Tue, 24 Jul 2018 11:44:15 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id k25-v6so3415448uao.11 for ; Tue, 24 Jul 2018 11:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rMG3zeo0D3mc40ZIZ0MD9yEW3sHJDUH57DdTWfmV0Tw=; b=kDrxZjarYN9Lq3Oaq6D657jR2VcGqrRDlyxAZL5KtyKU/MaCza/wh6vGA5u1V/9gR9 +ZSDkx1ln58CwkjGzRdw43wi5p7cs5Ad/4mCbeJlpHCh2kozu6WopDSfMnwGeN3qG9ZJ +0KPWVrUXS/HAEP8faraa9QdO/v+8xSg8biADuYklvpBOnQJA1h8quPGALReqc99ouDw Ke+4taZ0VCR3aGrEt/8yA2c9yczBR1G1QhT+HQ1bwmUl65kSo7kiau3ZVYwVpChUP8cV ihnHtbpVJGfMWe1lOuc3G/+46e6lkGtq9mZJWgB055osu143jFr4JDN9SM1N7caU32nV 0jmA== 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=rMG3zeo0D3mc40ZIZ0MD9yEW3sHJDUH57DdTWfmV0Tw=; b=aq4Bxhkxgx0OzcCnWoF+iPyIjdpGuPuqCVYg7mOUUvO8jcjjNh1ipZDzv6JCD2EGAO pp93feQGRYnq3fMRMNGVqnWek33KEnDL9zxwTgjv01S4jyCWdr7zeJLLgd9f85p9TayE 9aobAizTrgqHnTAsGvEj8szL6ytIVRpwkrz0H9WhgvUKWf4IzRR8u86Seivj4tsPyIN4 /bCgfZTDo7U31xBf1tAfsFjXRRcJ79qqbySJ2oPFBbmDp2AL+NGDx09EewIdLAlehQeJ mWkoDJ9b5YlM10Yzt4jKREc/aazmJH7KDfCpFMkXoQvJJdDo0ArJtPuGsCz/yewoQo6a Sxgw== X-Gm-Message-State: AOUpUlHKJJyxJLEvOlFwFyRDlVDKvlaYNimuc105zFVDCGm1VsYplkia bYO/Btrk3EZUPz8qydKkIdVgqTcyyFPIB+c2Zj8= X-Google-Smtp-Source: AAOMgpc4PAR9eGPuWHgtIdXJyGCX1ftGmSYQ7scVYgsU+eG5LNcNJyUoPGuLwkMl5nwzuQyvrdqPCDNWF7x6yy6pyQw= X-Received: by 2002:ab0:10cc:: with SMTP id x12-v6mr12479069uab.55.1532457854780; Tue, 24 Jul 2018 11:44:14 -0700 (PDT) MIME-Version: 1.0 References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Tue, 24 Jul 2018 21:44:04 +0300 Message-ID: To: Cas Cremers Cc: Katriel Cohn-Gordon , mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000001148d00571c326a5" Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 18:44:19 -0000 --0000000000001148d00571c326a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption. =D0=B2=D1=82, 24 =D0=B8=D1=8E=D0=BB=D1=8F 2018 =D0=B3. =D0=B2 21:40, Cas Cr= emers : > +1 > > On Tue, 24 Jul 2018, 20:34 Katriel Cohn-Gordon, wrote: > >> +1 >> >> >> On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote: >> >> I support adoption >> >> >> On Tue, Jul 24, 2018 at 1:58 PM Jon Millican > > wrote: >> >> I also support adoption. >> >> >> >> On 24/07/2018, 18:57, "MLS on behalf of Suhas Nandakumar" < >> mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote: >> >> >> >> I support the adoption >> >> >> >> On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche < >> benjamin.beurdouche@inria.fr> wrote: >> >> Hi all, >> >> >> >> I agree with this draft becoming a WG document. >> >> >> >> Best, >> >> Benjamin >> >> >> >> On Jul 24, 2018, at 10:44 AM, Nick Sullivan < >> nick=3D40cloudflare.com@dmarc.ietf.org> wrote: >> >> >> >> All, >> >> >> >> The sense of the MLS@IETF102 room was the WG should adopt >> https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ >> >> as a WG item. We have marked the draft as a "Candidate for WG Adoption= =E2=80=9D in >> the datatracker, but now it=E2=80=99s time to officially do the WG call = for >> adoption. So, if you would like for this draft to become a WG document a= nd >> you are willing to review various versions as it moves through the proce= ss, >> then please let the list know by 2359UTC 2018.08.03. If you are opposed = to >> this being a WG document, please say so (and say why). >> >> >> >> Cheers, >> >> >> >> Nick and Sean >> >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> >> -- >> Joseph Lorenzo Hall >> Chief Technologist, Center for Democracy & Technology [ >> https://www.cdt.org] >> 1401 K ST NW STE 200, Washington DC 20005-3497 >> e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key >> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >> *_______________________________________________* >> 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 > --0000000000001148d00571c326a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption.=C2=A0

=D0=B2=D1=82, 24 =D0=B8=D1=8E=D0=BB= =D1=8F 2018 =D0=B3. =D0=B2 21:40, Cas Cremers <cas.cremers@cs.ox.ac.uk>:
+1

On Tu= e, 24 Jul 2018, 20:34 Katriel Cohn-Gordon, <me@katriel.co.uk> wrote:
+1


On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote:
I support adoption

On Tue, Jul 24, 2018 at 1:58 PM Jon Millican <jmillican@fb..com>= wrote:

I also su= pport adoption.

=C2=A0

On 24/07/2018, 18:57, "MLS on behalf = of Suhas Nandakumar" <mls-bounces@ietf.org on behalf of suhasietf@gmail.com> wrote:<= u>

=C2=A0

I support the adoption=C2=A0=

=C2=A0

On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche= <benj= amin.beurdouche@inria.fr> wrote:

<= p style=3D"margin-left:36pt">Hi all,

=C2=A0

I agree with this draft becoming a WG documen= t.

=C2=A0

Best,

Benjamin



On Jul 24, 2018, at 10:44 AM, Nick Sullivan <nick= =3D40cloudflare.com@dmarc.ietf.org> wrote:

=C2=A0

All,

=C2=A0

The sense of the MLS@IETF10= 2 room was=C2=A0the WG=C2=A0should adopt https://datatracker.ietf.org/doc/dra= ft-barnes-mls-protocol/ as a WG item. We have marked the draft a= s a "Candidate for WG Adoption=E2=80=9D in the=C2=A0datatracker<= /span>, but now it=E2=80=99s time to officially do the WG call for adoption= . So, if you would like for this draft to become a WG document and you are willing to review various versions as it moves t= hrough the process, then please let the list know by 2359UTC 2018.08.03. If= you are opposed to this being a WG document, please say so (and say why).<= u>

=C2=A0=

Cheers,

=C2=A0=

Nick and Sean=

=C2=A0

= _______________________________________________
MLS mailing list

=C2=A0

= _______________________________________________
MLS mailing list

__________________________________= _____________
MLS mailing list


--
Joseph Lorenzo Hall
Chief Technologist, Center for Dem= ocracy & Technology [= https://www.cdt.org]
1401 K ST NW STE 200, Washington D= C 20005-3497
Fingerprint: 3CA2 8D7B 9F6D DBD3 4= B10 =C2=A01607 5F86 6987 40A9 A871
_______________________________________________
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
--0000000000001148d00571c326a5-- From nobody Tue Jul 24 13:16:29 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B773D1311D0 for ; Tue, 24 Jul 2018 13:16:26 -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=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 k3Z0JgFQ5dWB for ; Tue, 24 Jul 2018 13:16:24 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 091491311CE for ; Tue, 24 Jul 2018 13:16:24 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id l14-v6so4478962iob.7 for ; Tue, 24 Jul 2018 13:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=h6qK9urv4pfz8k7ILqKwQ80s4SGh2n9fYIvFGbgoRrw=; b=U14ckks0uLrmsZq75Aqlw8DxMKYoFksegJwy4Ku1V3hBm++3yFZHO6T/ze2Dx7RRlf Wb1vuB6mlOKr/jJAXrJYBqOAXqt39fZlVtmpELiDr7jzEoP9ENh8xrNNbZDlwYY3AQt7 hNE0bg2Y9QUS1SmbIs0tew+RLA1g2OmqgVqxE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=h6qK9urv4pfz8k7ILqKwQ80s4SGh2n9fYIvFGbgoRrw=; b=bHaknIArIZiau72ImxJVlzTr8TxSwh/APhUvXZIk3MII2dPf1RrIUYmOicNAhCy2sY Xg0AN8ElYPxY+MFkIzovn+utFC0D+zswienpv9G/0mtNAlzphzm9eesii2yy2FMTv66E Zpnx9BaqEN0KcICNzGUPlb7RnSjsdw5W8Je+pS3Ahew6SO9IYTfrBZ7VJshsF1Nj9q2a n6fHAWRFz3wgn8HJ9qo1ncpWHK71xSJGZSgITrHignnLFgMvJdbhUdErxSX1AP+A8e6d aGcC+Nh4BXB3/7Sdbe4WQJtQF2vInPEon0o0VJNFZ9Wu3g85bhjsKry0WFAsVJwDjTH0 xrmg== X-Gm-Message-State: AOUpUlHK234d3oW6K7/PlFr+UHquP8vwZ3xKXszXvtK3/uQKmuNHLX3Q 9V7iiUAM99OyYMFeX9NUFA0Atar4BtE= X-Google-Smtp-Source: AAOMgpcHmmM6rGmsr/4ehLfdKlAiT1brjLB9AkradeyMl2oOITlah1xUoF7hj+itW3ysO8ZOHdtilg== X-Received: by 2002:a6b:fc14:: with SMTP id r20-v6mr13602581ioh.270.1532463383337; Tue, 24 Jul 2018 13:16:23 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id d10-v6sm3881647iob.4.2018.07.24.13.16.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 13:16:22 -0700 (PDT) To: mls@ietf.org References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> <1532457217.553852.1451537168.6900AD72@webmail.messagingengine.com> 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: <8cc84616-0497-18ec-afca-cfbf02644848@mozilla.com> Date: Tue, 24 Jul 2018 14:16:21 -0600 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: <1532457217.553852.1451537168.6900AD72@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pfth3yh8hhKjvJcCOOQCyNRyO45ObZ22J" Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:16:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pfth3yh8hhKjvJcCOOQCyNRyO45ObZ22J Content-Type: multipart/mixed; boundary="DHa0cwu1sTCLjTkOZngACiPYVhtYN7HRz"; protected-headers="v1" From: Peter Saint-Andre To: mls@ietf.org Message-ID: <8cc84616-0497-18ec-afca-cfbf02644848@mozilla.com> Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> <1532457217.553852.1451537168.6900AD72@webmail.messagingengine.com> In-Reply-To: <1532457217.553852.1451537168.6900AD72@webmail.messagingengine.com> --DHa0cwu1sTCLjTkOZngACiPYVhtYN7HRz Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I support adoption and I'm willing to provide reviews. On 7/24/18 12:33 PM, Katriel Cohn-Gordon wrote: > +1 >=20 >=20 > On Tue, 24 Jul 2018, at 7:18 PM, Joseph Lorenzo Hall wrote: >> +1 >> >> On Tue, Jul 24, 2018 at 1:58 PM Suhas Nandakumar > > wrote: >> >> I am following this work closely and support it=E2=80=99s adoption= =C2=A0 >> >> Thanks >> ./s >> >> On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche >> > > wrote: >> >> Hi all, >> >> I agree with this draft becoming a WG document. >> >> Best, >> Benjamin >> >> >>> On Jul 24, 2018, at 10:44 AM, Nick Sullivan >>> >> > wrote: >>> >>> All, >>> >>> The sense of the MLS@IETF102 room was the WG should adopt >>> https://datatracker.ietf.org/doc/draft-omara-mls-architecture= / as >>> a WG item. We have marked the draft as a "Candidate for WG >>> Adoption=E2=80=9D in the datatracker, but now it=E2=80=99s ti= me to officially >>> do the WG call for adoption. So, if you would like for this >>> draft to become a WG document and you are willing to review >>> various versions as it moves through the process, then please= >>> let the list know by 2359UTC 2018.08.03. If you are opposed >>> to this being a WG document, please say so (and say why). >>> >>> Cheers, >>> >>> Nick and Sean >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> >> --=20 >> Joseph Lorenzo Hall >> Chief Technologist, Center for Democracy & Technology >> [https://www.cdt.org] >> 1401 K ST NW STE 200, Washington DC 20005-3497 >> e: joe@cdt.org , p: 202.407.8825, pgp: >> https://josephhall.org/gpg-key >> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871 >> _________________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf..org/mailman/listinfo/mls >> >=20 >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 --DHa0cwu1sTCLjTkOZngACiPYVhtYN7HRz-- --pfth3yh8hhKjvJcCOOQCyNRyO45ObZ22J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltXiRUACgkQZWGMGH9o FKlP/A/+OTJF4MPskf30xj3XsFBtnSacGxBOyvYfXs+ab2/Q82tvWOwSveMeD6xu NjLeJkbmC9R0w8oXBusAYnam3rKgIvLtZPgohTNCy41v5YsvtnyfM70vR+86y+5A 35pEbNwIda5/TF05l3uwjykbqa5y5efyh5aEldi9XZsREUYt9lzc04ClydMvIYbC kxGuzFsGhl9O6cm9fwTluftp7K0jJLzWRAPvhOEXx2aJqAqmfIpvyloC5V9j6Dju 3sX8nLxiwtcqyyI3OR9PCYG8KTyOmSnUZUcdNVjAC5nmK/XzXplzZf7swK5n/V8l bQ4eJ7tSYljx14SWv59yxfNssxOnXF+O5HhPwL2l0foMnq3h9r14q093yOtV/JpX slmpzLZYIpBvlJePipEUbltX68xSBQyIhNmfccUggQw6jiC61JLwCwde4E6ldt8T d2eJ++goKQEvBdKv9k7Mc+MegszJKahwPvwqU8LtfI22KMDJRUvcmfi05kiP13rM ezaDsd5NlxUhslgFuOjQkIO/vrvwTYueEYGMLOdkJQ8uOdrdi+3xqDNhImw31uhH 0eYpKB6fQ9GbYb1fkL8SXLeBmKqAgFenOLY4Y7wxj4cO0PRJav3AC2O3oh1/G8GE yYhsUmVg0x3YXu1naVC0b0LPrGMk46fzhQdU8ZGn7yhTBuPF3pQ= =5e6A -----END PGP SIGNATURE----- --pfth3yh8hhKjvJcCOOQCyNRyO45ObZ22J-- From nobody Tue Jul 24 13:19: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 D9928130E8F for ; Tue, 24 Jul 2018 13:19:28 -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=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 acNvdWEW18IB for ; Tue, 24 Jul 2018 13:19:24 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B415E130DE4 for ; Tue, 24 Jul 2018 13:19:24 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 72-v6so5574694itw.3 for ; Tue, 24 Jul 2018 13:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=6aWOaUzBH0XX20WVTzT4ljF533fjsXcUVT+Eh1voaLc=; b=BOyRlC4fdi19qfsxVI7xZ8M8El01eR7K/P7xPPAwnFDWjL9Xn7tojWFxvLcggUgq67 gpvk+BFS3SkITV46aGQPSDRQt3zG74FTzVTVjQHxy442wWiFi2JasS7PtqPLgE5Hph5l UauJwklrVzpLI5SrjJEqV4V22RZaTHp8E/HdI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=6aWOaUzBH0XX20WVTzT4ljF533fjsXcUVT+Eh1voaLc=; b=gezo+z66KsQz0loF7leKifkUDGowEpTisyqNS0Tre3XUMrJS1PsnIZgOdYb+Tbao+t ebdZVSjgfhEcdQj51etiH5uwonaf/mc9ODJvsK4Gab0CP4bOqWNoMpezT2zCYqkR44/g LH8RlK+g8XkoIiPmUO6jpE8CD5+WjUhpeto6bN9dTD1INp0eLmShGOmbDjHUrhu0IVnW jUBCUcWUW/h66+VbIyWeAuG8gpmvo4YLr//YquLtV74KHyBtlH+nHk9TJ8Uu/+/CGyto QELtUaWFgY5uz80kJwtRPEOuf7FS4a9zWFrxdTL/S7uwTlqOKKYqdZCzKPpqkJybS/ie mfhQ== X-Gm-Message-State: AOUpUlGSwXdzRNS/rrGEwWc07SVeCziz9HmXm2kE65Tosi84p17Oc3qA sMrWc+AVt9WfOmw4feNp1/OHeQ== X-Google-Smtp-Source: AAOMgpe3J1mRXHHNEU4f6XKh8lgiS24B1ZWALl3OrkG37nTXYbwigv3qe7bue0ZL2bCRreJcdT0mPw== X-Received: by 2002:a24:2c49:: with SMTP id i70-v6mr4083790iti.135.1532463563887; Tue, 24 Jul 2018 13:19:23 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id e2-v6sm3371690ioa.33.2018.07.24.13.19.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 13:19:23 -0700 (PDT) To: mls@ietf.org References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> 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: Date: Tue, 24 Jul 2018 14:19:21 -0600 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A3luFA2EmPwIdlJtozTKX214OaeVfkZbQ" Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:19:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A3luFA2EmPwIdlJtozTKX214OaeVfkZbQ Content-Type: multipart/mixed; boundary="hZGnxvwBbiVB9tS6vSp4sStwgzhM8oFog"; protected-headers="v1" From: Peter Saint-Andre To: mls@ietf.org Message-ID: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> In-Reply-To: --hZGnxvwBbiVB9tS6vSp4sStwgzhM8oFog Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I support adoption and I'm willing to provide reviews. On 7/24/18 12:44 PM, Stanislav V. Smyshlyaev wrote: > I support adoption.=C2=A0 >=20 > =D0=B2=D1=82, 24 =D0=B8=D1=8E=D0=BB=D1=8F 2018 =D0=B3. =D0=B2 21:40, Ca= s Cremers >: >=20 > +1 >=20 > On Tue, 24 Jul 2018, 20:34 Katriel Cohn-Gordon, > wrote: >=20 > __ > +1 >=20 >=20 > On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote: >> I support adoption >> >> On Tue, Jul 24, 2018 at 1:58 PM Jon Millican >> > wrote: >> >> I also support adoption.____ >> >> __=C2=A0__ >> >> On 24/07/2018, 18:57, "MLS on behalf of Suhas Nandakumar" >> on >> behalf of suhasietf@gmail.com >> > wrote:____ >> >> __=C2=A0__ >> >> I support the adoption=C2=A0____ >> >> __=C2=A0__ >> >> On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche >> > > wrote:____ >> >> Hi all,____ >> >> __=C2=A0__ >> >> I agree with this draft becoming a WG document. ____ >> >> __=C2=A0__ >> >> Best,____ >> >> Benjamin____ >> >> >> ____ >> >> On Jul 24, 2018, at 10:44 AM, Nick Sullivan >> > > >> wrote:____ >> >> __=C2=A0__ >> >> All,____ >> >> __=C2=A0__ >> >> The sense of the MLS@IETF102 room was=C2=A0the >> WG=C2=A0should adopt >> https://datatracker.ietf.org/doc/draft-barnes-mls-= protocol/ >> >> as a WG item. We have marked the draft as a >> "Candidate for WG Adoption=E2=80=9D in the=C2=A0da= tatracker, >> but now it=E2=80=99s time to officially do the WG = call for >> adoption.. So, if you would like for this draft to= >> become a WG document and you are willing to review= >> various versions as it moves through the process, >> then please let the list know by 2359UTC >> 2018.08.03. If you are opposed to this being a WG >> document, please say so (and say why).____ >> >> __=C2=A0__ >> >> Cheers,____ >> >> __=C2=A0__ >> >> Nick and Sean____ >> >> __=C2=A0__ >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> ____ >> >> __=C2=A0__ >> >> _______________________________________________ >> 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 >> Joseph Lorenzo Hall >> Chief Technologist, Center for Democracy & Technology >> [https://www.cdt.org] >> 1401 K ST NW STE 200, Washington DC 20005-3497 >> e: joe@cdt.org , p: 202.407.8825, pgp: >> https://josephhall.org/gpg-key >> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A= 9 A871 >> _________________________________________________ >> 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 >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 --hZGnxvwBbiVB9tS6vSp4sStwgzhM8oFog-- --A3luFA2EmPwIdlJtozTKX214OaeVfkZbQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltXickACgkQZWGMGH9o FKk6/xAAouArtkNrMkKZD0fjc2GrVBrBMO5lFjMH/S2+sUKr6csrjf3rc7KBYcbB 7aRK+GTEIGUWT3eQbue1khofEScKhmiZDL2faIvAsPG12/4wO9WXTCH7GIFsqTFr /7zMTYaY4oVbWpoIy3ZpY1t9gvc9IHOG72fqo2EHV+IzDX935OceSDiZ15yMbgCl OcRR3s+ezxxO5OIDDxreEFC42vYxXeGxj0nG5QwKPvI7NPyHQOEt40gFNurmEGTW NoQ4PQOdTCR3hmqtKuUEJt8dNJE2eN5tFLH/TyMVrCADqGFVFEf9PJmAwVBCFs14 HTxLeoTWccPOvblVl6p2TVvcTn/enTz1s1AKWhnA8h/NWRnA/5iNm2lwU3AluwQG Zm50qXwqP9w3Sx9C9z8CYRUKqUxHsmqgB520sE48yJY80jA59lBz03yPSRaF7NKv lgLZrZWDFh60ZMfyOLHjwe1v/s0bONGiNWQukEqXeCda/r2bkVNh7fL5IWYhy5s0 XhD71+vbkDzVQevxcs1KLpA/CuwlpBvuFy154nYXlER5o2ZbUOadzFAAtmkhLUiG 60zH3pklg5o2sPF6csavbBOuGILoZZa5QDjvNfknvgnmYsiU1vqTuR4UyMCLpJrv dsNluOZr/4YLhmHkAxV3ChGv50VEFmWqDDEcB2fvMo/QjNK/kpw= =pooW -----END PGP SIGNATURE----- --A3luFA2EmPwIdlJtozTKX214OaeVfkZbQ-- From nobody Tue Jul 24 13:20:42 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 C94B91311D5 for ; Tue, 24 Jul 2018 13:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 dIppJIBiAx9l for ; Tue, 24 Jul 2018 13:20:36 -0700 (PDT) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (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 D4EF9130DE4 for ; Tue, 24 Jul 2018 13:20:35 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id w126-v6so9871325oie.7 for ; Tue, 24 Jul 2018 13:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=Y1RO3EMV+ufWX2xP1WTDOI/4wkRkqVJJDiuz1iarSE8=; b=Cf/2HOsY0Ig3RPG68DwzmLnKGLFbTLSNuFHwuLD566byJt5cvBDHbhZNn3ot8CU+T1 FpWv+w9EyN2oiYGdSJbSx0s3l2gPqrY5/E2DEAqxwXIIs2DxPIIkiZ/grRMahnflLSSD 9AHB8u4hpTK7kDijtX7RhYAKVPn0QEX4kv40SFNfOBNcVtJFyk6cQ6duk2kNHmVseKtn /AD8YMAo6o0vld93HMu245otSWIdIAKP0cNQTaUFzYufUvBzJEfdKkMnIW2TjVgxaHx9 kKkmiDCR9ONt4Us7oY1WDMqB2s56/5zBCkobI25SKLczXwxSdb/f0BucHbOGOcWHPMqo k+0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to; bh=Y1RO3EMV+ufWX2xP1WTDOI/4wkRkqVJJDiuz1iarSE8=; b=VJXHiQzyjYZD1all1HMz92ipWxVD+DU2ivwggDjvIXSAyxaZ52CcCqbTwwGZxNmFuG GSbF1lQbND6ljIJIMDoS16ENRn339BrY4wFkzhwt4iupLwwfU5u2/+RcHicBxdJdrwNP cPg6w9dDCbo/SGxdudXDYPktDlAOG7Es3oqSoi8n1fDIIyHqbxnfYHBhAX0vNilHfshV MX5h9KypDO7F/huelq3EA/1KPV54wIQsZJuDtMjFhjd4tBuVuWt0uChEESmpIzsSbCK5 JsIy844RppFEd+oatdS6OTI2QlG3i0bNbqaBvk/aEspPn9+Deuad1v5hcHEs2mBF5s5V JsSQ== X-Gm-Message-State: AOUpUlEFjJLDw2BI1Mmur3et6YPTeWLF8XDnI06VAR4XhSuxPIiyP6zA elb+0u+xfx1ty+ftI6jwBd5VwfwYZsA= X-Google-Smtp-Source: AAOMgpfW4wkxGcI7W5ZsDAJGXK8Yi1nBcFvQPSTD/KzpqYx1oaguzTH4x53vnQnU3JVdpU0xA+M2Dw== X-Received: by 2002:aca:6087:: with SMTP id u129-v6mr348836oib.99.1532463634915; Tue, 24 Jul 2018 13:20:34 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id t131-v6sm11122707oie.34.2018.07.24.13.20.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 13:20:34 -0700 (PDT) Sender: Matthew Miller To: mls@ietf.org References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> <1532457217.553852.1451537168.6900AD72@webmail.messagingengine.com> <8cc84616-0497-18ec-afca-cfbf02644848@mozilla.com> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: <82ca120c-ceaa-1eff-6d31-defa959eeef7@outer-planes.net> Date: Tue, 24 Jul 2018 14:20:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <8cc84616-0497-18ec-afca-cfbf02644848@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uUe1g4PQrKqTW4ULtaGZjPcX0EV5DYOvp" Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:20:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uUe1g4PQrKqTW4ULtaGZjPcX0EV5DYOvp Content-Type: multipart/mixed; boundary="qCkPMbdADJ8xhIcK1sCWXjeyp5lmZd6ii"; protected-headers="v1" From: "Matthew A. Miller" To: mls@ietf.org Message-ID: <82ca120c-ceaa-1eff-6d31-defa959eeef7@outer-planes.net> Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture References: <59527200-5D92-4C44-BDF5-C3B96BC1304A@inria.fr> <1532457217.553852.1451537168.6900AD72@webmail.messagingengine.com> <8cc84616-0497-18ec-afca-cfbf02644848@mozilla.com> In-Reply-To: <8cc84616-0497-18ec-afca-cfbf02644848@mozilla.com> --qCkPMbdADJ8xhIcK1sCWXjeyp5lmZd6ii Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I support adoption. - m&m Matthew A. Miller On 18/07/24 14:16, Peter Saint-Andre wrote: > I support adoption and I'm willing to provide reviews. >=20 > On 7/24/18 12:33 PM, Katriel Cohn-Gordon wrote: >> +1 >> >> >> On Tue, 24 Jul 2018, at 7:18 PM, Joseph Lorenzo Hall wrote: >>> +1 >>> >>> On Tue, Jul 24, 2018 at 1:58 PM Suhas Nandakumar >> > wrote: >>> >>> I am following this work closely and support it=E2=80=99s adoptio= n=C2=A0 >>> >>> Thanks >>> ./s >>> >>> On Tue, Jul 24, 2018 at 10:54 AM Benjamin Beurdouche >>> >> > wrote: >>> >>> Hi all, >>> >>> I agree with this draft becoming a WG document. >>> >>> Best, >>> Benjamin >>> >>> >>>> On Jul 24, 2018, at 10:44 AM, Nick Sullivan >>>> >>> > wrote: >>>> >>>> All, >>>> >>>> The sense of the MLS@IETF102 room was the WG should adopt >>>> https://datatracker.ietf.org/doc/draft-omara-mls-architectur= e/ as >>>> a WG item. We have marked the draft as a "Candidate for WG >>>> Adoption=E2=80=9D in the datatracker, but now it=E2=80=99s t= ime to officially >>>> do the WG call for adoption. So, if you would like for this >>>> draft to become a WG document and you are willing to review >>>> various versions as it moves through the process, then pleas= e >>>> let the list know by 2359UTC 2018.08.03. If you are opposed >>>> to this being a WG document, please say so (and say why). >>>> >>>> Cheers, >>>> >>>> Nick and Sean >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >>> >>> >>> --=20 >>> Joseph Lorenzo Hall >>> Chief Technologist, Center for Democracy & Technology >>> [https://www.cdt.org] >>> 1401 K ST NW STE 200, Washington DC 20005-3497 >>> e: joe@cdt.org , p: 202.407.8825, pgp: >>> https://josephhall.org/gpg-key >>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871 >>> _________________________________________________ >>> 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 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 --qCkPMbdADJ8xhIcK1sCWXjeyp5lmZd6ii-- --uUe1g4PQrKqTW4ULtaGZjPcX0EV5DYOvp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAltXihEACgkQ7PRyThCe BbtGsAf/Ty6vzeiUyvSbzc16KJy3nm5AFib2dcO9Spno5mRRDrEQ1S8zVD4/fBbj bEhaTK3iO8NkB6qO5P1lms9KToR7YiNaoV+na7jNNSz2a+dn7MsqjdBVduUHGtzH EwLGMLMd54l9vCG9EuBb+N6EWAopjUpssOtS1rWfTtpvkrGLfk2CQPOqEXV7OfGm w0V6HFtfv85cBhTC7KXW4tJKRD1/Mb15OLuOnfDvHqi+2h8KGzqa3eP55TPrM6QL OxTA2YKeVDArDRSRZmePogdeYtma5NrPgYYvKqqv6iG7sSwTdhLdf7qXOwoJsi1q HrpaISDLn6iu3Fokpe9TtynADquOfQ== =HrqK -----END PGP SIGNATURE----- --uUe1g4PQrKqTW4ULtaGZjPcX0EV5DYOvp-- From nobody Tue Jul 24 13:20: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 1A142130F28 for ; Tue, 24 Jul 2018 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 O1AqdSejjX_o for ; Tue, 24 Jul 2018 13:20:46 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E91130E8F for ; Tue, 24 Jul 2018 13:20:46 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id q11-v6so9834398oic.12 for ; Tue, 24 Jul 2018 13:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=7dnGUT2lrtUMtmUjTigryO7bw/1YG0tp6Z2KNlDoAJk=; b=Gcorasqkgy5ETUkvDlLmtFyuhofztr9uRTpC0R4V3FQnxH1HAt/1bSLBmyY9U0UFg/ TLdrVlApWrwbAyign/YoVvScXbmsWqiO5sId9jRd2hQGnPneDIjeWALLbuQZmnA1NSiA QyI0KBaMygREW12IjoWwgvprLDIgvW6WCL2O0gVlKVmH9dLkmmukrQ1z/O0LbRcynRls N8fK8SrhEBcS2X6dHeWH8TbPrOht0QC/YbXHWwarB8aoFXafcPdg6r50o2MASSP6ny9a i36OkFBU2fCuq6AkpxXmOnlNBU2NLiFJLweGQcJqG9IMdTWleJ8Cwub2d7jMvTgLY4Pf nI9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to; bh=7dnGUT2lrtUMtmUjTigryO7bw/1YG0tp6Z2KNlDoAJk=; b=Y/wMTOz0ybmUPlgjIsmVMLaNPqY4p2fHHxNbmVBgaFjKHVTPre8CSKjfqK7vDbe80L 7P6MTBCDcEoabbyd0ly2XsMdjWnkjrVYaCm5atrghSQc+Fe5/MbeyxlmqMolQoqjt3Uq USpUyY6CYBjr1iv0Ik9iM61E2/VRP8D5iR9MpfofBOD01CYbdhAPc3eV946hznRE4ATb lPKTT5IdKe4vtH885NGtej2xpkjXGuQ3PieEgSpm4DQWCSkSzyGUF4CC5ZNwE9yHue4I Do2WPEBzZruJeL9aDoPEsLBf1W75Yq+HU0rxd0xjLaFTaDb5HOb/YeoyUt7wDPsOnxZY PpRw== X-Gm-Message-State: AOUpUlFLDTee7/zCEI56LoSiIS8vfNlsWTVo8EdsyVQKXMqQ0wKE63Zo /JStQFwahEEKBPWhB9POEgQMtT3zBR4= X-Google-Smtp-Source: AAOMgpdkwsF8x+5UOii2rl+boAEqt3FkIWckCqqfBUMDAVgIqlgokZn5OghY6yxdoAnjlX8xYlCHrA== X-Received: by 2002:aca:698c:: with SMTP id e134-v6mr414132oic.302.1532463645485; Tue, 24 Jul 2018 13:20:45 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id l204-v6sm8707100oia.45.2018.07.24.13.20.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 13:20:45 -0700 (PDT) Sender: Matthew Miller To: mls@ietf.org References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: <3b895219-d8d6-bf5c-b6dd-f435d582052b@outer-planes.net> Date: Tue, 24 Jul 2018 14:20:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WfO1dBRTQ925ed9SLsJmqdlxR5eXpSUfg" Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:20:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WfO1dBRTQ925ed9SLsJmqdlxR5eXpSUfg Content-Type: multipart/mixed; boundary="0uQx4cEJJUegWfLQAK5szJHtF89Ca5xqE"; protected-headers="v1" From: "Matthew A. Miller" To: mls@ietf.org Message-ID: <3b895219-d8d6-bf5c-b6dd-f435d582052b@outer-planes.net> Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol References: <372F3FA7-FAAB-4C3B-B339-1E055E7339A2@fb.com> <1532457230.553851.1451537360.3F06D9D2@webmail.messagingengine.com> In-Reply-To: --0uQx4cEJJUegWfLQAK5szJHtF89Ca5xqE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I support adoption. - m&m Matthew A. Miller On 18/07/24 14:19, Peter Saint-Andre wrote: > I support adoption and I'm willing to provide reviews. >=20 > On 7/24/18 12:44 PM, Stanislav V. Smyshlyaev wrote: >> I support adoption.=C2=A0 >> >> =D0=B2=D1=82, 24 =D0=B8=D1=8E=D0=BB=D1=8F 2018 =D0=B3. =D0=B2 21:40, C= as Cremers > >: >> >> +1 >> >> On Tue, 24 Jul 2018, 20:34 Katriel Cohn-Gordon, > > wrote: >> >> __ >> +1 >> >> >> On Tue, 24 Jul 2018, at 7:17 PM, Joseph Lorenzo Hall wrote: >>> I support adoption >>> >>> On Tue, Jul 24, 2018 at 1:58 PM Jon Millican >>> > wrote: >>> >>> I also support adoption.____ >>> >>> __=C2=A0__ >>> >>> On 24/07/2018, 18:57, "MLS on behalf of Suhas Nandakumar"= >>> on >>> behalf of suhasietf@gmail.com >>> > wrote:____ >>> >>> __=C2=A0__ >>> >>> I support the adoption=C2=A0____ >>> >>> __=C2=A0__ >>> >>> On Tue, Jul 24, 2018 at 10:55 AM Benjamin Beurdouche >>> >> > wrote:____ >>> >>> Hi all,____ >>> >>> __=C2=A0__ >>> >>> I agree with this draft becoming a WG document. ____ >>> >>> __=C2=A0__ >>> >>> Best,____ >>> >>> Benjamin____ >>> >>> >>> ____ >>> >>> On Jul 24, 2018, at 10:44 AM, Nick Sullivan >>> >> > >>> wrote:____ >>> >>> __=C2=A0__ >>> >>> All,____ >>> >>> __=C2=A0__ >>> >>> The sense of the MLS@IETF102 room was=C2=A0the >>> WG=C2=A0should adopt >>> https://datatracker.ietf.org/doc/draft-barnes-mls= -protocol/ >>> >>> as a WG item. We have marked the draft as a >>> "Candidate for WG Adoption=E2=80=9D in the=C2=A0d= atatracker, >>> but now it=E2=80=99s time to officially do the WG= call for >>> adoption.. So, if you would like for this draft t= o >>> become a WG document and you are willing to revie= w >>> various versions as it moves through the process,= >>> then please let the list know by 2359UTC >>> 2018.08.03. If you are opposed to this being a WG= >>> document, please say so (and say why).____ >>> >>> __=C2=A0__ >>> >>> Cheers,____ >>> >>> __=C2=A0__ >>> >>> Nick and Sean____ >>> >>> __=C2=A0__ >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> ____ >>> >>> __=C2=A0__ >>> >>> _______________________________________________ >>> 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 >>> Joseph Lorenzo Hall >>> Chief Technologist, Center for Democracy & Technology >>> [https://www.cdt.org] >>> 1401 K ST NW STE 200, Washington DC 20005-3497 >>> e: joe@cdt.org , p: 202.407.8825, pgp: >>> https://josephhall.org/gpg-key >>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40= A9 A871 >>> _________________________________________________ >>> 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 >> >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 --0uQx4cEJJUegWfLQAK5szJHtF89Ca5xqE-- --WfO1dBRTQ925ed9SLsJmqdlxR5eXpSUfg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAltXihwACgkQ7PRyThCe Bbs+GggAwvoi+qcFHnzPne2cc4ejaVaLee/V6AdWK3Rq8OzDuExqfbtx58zE4V6G GV1eo7/UtfI8n97x1H+oxiKFBUA00WzyIpwk4ASwbMO6QSnW5O6cqMt9p/XeTIr1 BU5neTEy42f3ipM0OPKsfLdbauG0ZrnDN1OhHwtTk0HTIXCS+TYznxm1873N7wn6 KTQ9rBns2PPNdocBSuLS/v3rZ8x8Pel00qWSCTGh0iEUFjFzO1Fs9lPTYilrWkaQ uOjh3sF+m91vTOuFw6jOP7hs+vtKRbqZeEcc8s9LUacM3dVstteqcryZy0e7jeQ1 kcyXK2UAOePLms/xGqLTYTbe3JdO9w== =+/n+ -----END PGP SIGNATURE----- --WfO1dBRTQ925ed9SLsJmqdlxR5eXpSUfg-- From nobody Tue Jul 24 13:25: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 3CB42130F28 for ; Tue, 24 Jul 2018 13:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, 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 qDWSWmk1sV_f for ; Tue, 24 Jul 2018 13:25:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615881311DA for ; Tue, 24 Jul 2018 13:25:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 45FCE300A46 for ; Tue, 24 Jul 2018 16:25:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LAhqj1LwQnnX for ; Tue, 24 Jul 2018 16:25:15 -0400 (EDT) Received: from new-host-6.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 531F63002C6 for ; Tue, 24 Jul 2018 16:25:15 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C59F1E6D-ACD1-4362-8CC5-1B048659588C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 24 Jul 2018 16:25:16 -0400 References: To: mls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:25:22 -0000 --Apple-Mail=_C59F1E6D-ACD1-4362-8CC5-1B048659588C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support adoption, and I am willing to review. Russ > On Jul 24, 2018, at 1:44 PM, Nick Sullivan = wrote: >=20 > All, >=20 > The sense of the MLS@IETF102 room was the WG should adopt = https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ = as a WG = item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D = in the datatracker, but now it=E2=80=99s time to officially do the WG = call for adoption. So, if you would like for this draft to become a WG = document and you are willing to review various versions as it moves = through the process, then please let the list know by 2359UTC = 2018.08.03. If you are opposed to this being a WG document, please say = so (and say why). >=20 > Cheers, >=20 > Nick and Sean --Apple-Mail=_C59F1E6D-ACD1-4362-8CC5-1B048659588C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = support adoption, and I am willing to review.

Russ


On Jul 24, 2018, at 1:44 PM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

All,

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

Cheers,

Nick and = Sean

= --Apple-Mail=_C59F1E6D-ACD1-4362-8CC5-1B048659588C-- From nobody Tue Jul 24 13:25:58 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358F130DD9 for ; Tue, 24 Jul 2018 13:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr43-kbVJOPt for ; Tue, 24 Jul 2018 13:25:55 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B70130DE4 for ; Tue, 24 Jul 2018 13:25:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EA4C0300A46 for ; Tue, 24 Jul 2018 16:25:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Bx1odrt8kYFC for ; Tue, 24 Jul 2018 16:25:51 -0400 (EDT) Received: from new-host-6.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id B43C03002C6 for ; Tue, 24 Jul 2018 16:25:51 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_FEADB629-69DB-45D1-8038-F88B3A5C0422" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 24 Jul 2018 16:25:52 -0400 References: To: mls@ietf.org In-Reply-To: Message-Id: <64DEE150-B702-4069-AA8E-442008CBB633@vigilsec.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:25:57 -0000 --Apple-Mail=_FEADB629-69DB-45D1-8038-F88B3A5C0422 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support adoption, and I am willing to review. Russ > On Jul 24, 2018, at 1:44 PM, Nick Sullivan = wrote: >=20 > All, >=20 > The sense of the MLS@IETF102 room was the WG should adopt = https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ = as a WG = item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D = in the datatracker, but now it=E2=80=99s time to officially do the WG = call for adoption. So, if you would like for this draft to become a WG = document and you are willing to review various versions as it moves = through the process, then please let the list know by 2359UTC = 2018.08.03. If you are opposed to this being a WG document, please say = so (and say why). >=20 > Cheers, >=20 > Nick and Sean --Apple-Mail=_FEADB629-69DB-45D1-8038-F88B3A5C0422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = support adoption, and I am willing to review.

Russ


= --Apple-Mail=_FEADB629-69DB-45D1-8038-F88B3A5C0422-- From nobody Tue Jul 24 13:55:03 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839D1311E3 for ; Tue, 24 Jul 2018 13:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UYQyB4OKf11V for ; Tue, 24 Jul 2018 13:54:51 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADBD1311F9 for ; Tue, 24 Jul 2018 13:54:51 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id b10-v6so5259876eds.4 for ; Tue, 24 Jul 2018 13:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=MNiL2587Prq5/mYqObxhNjm4eETqw+HImEY38LW/ZkA=; b=xK09dFakrsIMSJvngJBaBSQDWr7nezNK1rwgkBn4QYj826q3PKn7odDz2Grm74f8hw 1Zu39wzqW2wWnyg312KWokf62ji3DeIHSZYye6GHe8qyZSACu28QK5hnmIAese8hBXZd ER+wmy5OFz7gxeUd8gDMLVPGHem/kGaj0d/xHL5UMtCYXvWPguk122C+O08aPYgEHtPA OA70bwQRGnhzhg6j6hDzR87jJWo4nm/c/RCdfHsMV3Ii0Bq6roL9aKvKEzipSVVC5ELd f2YdZRIcagCwH0xJnQfbGTgo9TDfVQ1TYC8u1Bct+uqsfCaojsAhYNer0cmqnZ46ewEJ 3XNw== 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=MNiL2587Prq5/mYqObxhNjm4eETqw+HImEY38LW/ZkA=; b=DkP4htOzgw5p1UMO6/oQQvOiAtwafpZrHawRNe8loImAmdOSpb/UO/ZkEeZ6KrXgri JbTMoxgO8C8HMoKOYtHFaxhMC3G3LjL6m596Y0DXBMgaiv1BxrSdW0kfekO0iG+BpXFx F0vJMKdjAZT4PLMU8+oRpyZvKSpOzm8e5AnetI6X9FQkc3RBqNZlqregjglLXBtyB6Le Fgh/Ac6b5PclaGE3gZEJReHHenLDzBV/1t5Tfkke3nNN+TXo1z3B6vKxTIom2C9tG6YM iHEjeA9mjG8AHG/dte7re58s7fAuMiEBtHFpwNUQ0sycmICn0nB7n9d/gSwNF7H73Dgu CsRw== X-Gm-Message-State: AOUpUlG2nVazTyLzJyQYfSIkfKRmmsXHsYrJVm3PkkjRjm+8CvR/TMIU ACMimPZ6h4ujxZDVl09zlKTeL3Vfl9zJLg== X-Google-Smtp-Source: AAOMgpelvWmZfO6WuCBKfWBP1b21aPopzxrV5MUCzScn3+G7RPzMcNhp0eF1AmXN9VRJMdRWlbalHw== X-Received: by 2002:a50:c2d1:: with SMTP id u17-v6mr20436549edf.119.1532465689748; Tue, 24 Jul 2018 13:54:49 -0700 (PDT) Received: from [10.144.153.6] ([46.189.28.41]) by smtp.gmail.com with ESMTPSA id q26-v6sm3894540eda.35.2018.07.24.13.54.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 13:54:49 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_32024C47-EA8D-4FF6-8B3B-5366E2A35FDD" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 24 Jul 2018 22:54:46 +0200 References: To: mls@ietf.org In-Reply-To: Message-Id: <88EC8310-83D9-483C-9514-B0C184245824@wire.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Call for adoption: draft-omara-mls-architecture X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:55:02 -0000 --Apple-Mail=_32024C47-EA8D-4FF6-8B3B-5366E2A35FDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support the adoption. > On 24 Jul 2018, at 19:44, Nick Sullivan = wrote: >=20 > All, >=20 > The sense of the MLS@IETF102 room was the WG should adopt = https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ = as a WG = item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D = in the datatracker, but now it=E2=80=99s time to officially do the WG = call for adoption. So, if you would like for this draft to become a WG = document and you are willing to review various versions as it moves = through the process, then please let the list know by 2359UTC = 2018.08.03. If you are opposed to this being a WG document, please say = so (and say why). >=20 > Cheers, >=20 > Nick and Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_32024C47-EA8D-4FF6-8B3B-5366E2A35FDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = support the adoption.

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

All,

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

Cheers,

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

= --Apple-Mail=_32024C47-EA8D-4FF6-8B3B-5366E2A35FDD-- From nobody Tue Jul 24 13:55:38 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFC1311E7 for ; Tue, 24 Jul 2018 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jnG63qbLM-oT for ; Tue, 24 Jul 2018 13:55:33 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CBD1311D8 for ; Tue, 24 Jul 2018 13:55:33 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id t2-v6so5265980edr.5 for ; Tue, 24 Jul 2018 13:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=8Cqlwi3CEosvwrfmvr8iCoVoG0VXop6VC8T98j8PIwM=; b=nhnx6nJ+iarxMbltP9Y73cm17nLVbLO5CTev3FqPwwnK8GkhFbPPDTi+wwi6droQZG tlD1qPiT5+5K8YvaKlj4BJfsOn+yhCyR5mda7CWZ/lz+/dy2DTKnuyGrEh8c7O4FeW5n w24Om9M2TAXHGHF87mcrSogad9bOYa2PED+9ApbvyyE7nR6h695jsxnrPvIJgjBHfUzN ybz5Cw/a9zGRtiB5kedtBd9flSvnu2Uhozdjjn6GJ5GTtBUpM9i8KatuxvD6Lvg3uZQw mk3daH8Mxc6LCmx5vptN6UUOff1JpPA6C3r/sY4e2TDv++0TAWxolfF3HMST6pUUwGxm MzqQ== 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=8Cqlwi3CEosvwrfmvr8iCoVoG0VXop6VC8T98j8PIwM=; b=M0/TsA+/UqQKe13OGjrMakDQPnnXjfAfGODDR1pEo1bLgqVPTr4VMFpqnE8rwSxl8D bsttIGl9IUPqWUUEVHcZbyYseP/6KvA4qaLEN8t7RKU/hzh7G2zYG19JX32+jXkE0GQ5 jwkkDuCbyr2annxTWVuf7qgMSg0HBp1iIoQc1B6ltX+2krR4EPf3EgUv/zLuyuxlIlwm CMm8aIR9vPutRoU1MVfHdZisREQrNbl4fmXfk+TuoEA8YyzoskrYOQiTGjAolGNPwMWg UK2E6wVlTAsLoC5RniX5TsY5kDwF2/lwmJVacu2H1XMg0SETRgtW/9+zmhyC62Padsmz KY9Q== X-Gm-Message-State: AOUpUlEXGOLskVyq6nxEU/QG41hYJu2Yl6qVm3r2a+Udxrg4AWUfO/V+ AelheKznX/cHnS5LK2YHatLVW1UguDE29g== X-Google-Smtp-Source: AAOMgpdG/8TLu+zbc5CW3FLNLRC/mHaq7UGN8d4TPs9ENy/6W7crw8WLYjQ1AMWbDm5FaU2CQp78IA== X-Received: by 2002:a50:91da:: with SMTP id h26-v6mr19363562eda.87.1532465731795; Tue, 24 Jul 2018 13:55:31 -0700 (PDT) Received: from [10.144.153.6] ([46.189.28.41]) by smtp.gmail.com with ESMTPSA id q26-v6sm3894540eda.35.2018.07.24.13.55.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 13:55:31 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_A78D6709-6947-4727-B1FB-8E1C818DFAF7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 24 Jul 2018 22:55:29 +0200 References: To: mls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] Call for adoption: draft-barnes-mls-protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:55:37 -0000 --Apple-Mail=_A78D6709-6947-4727-B1FB-8E1C818DFAF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I support the adoption. > On 24 Jul 2018, at 19:44, Nick Sullivan = wrote: >=20 > All, >=20 > The sense of the MLS@IETF102 room was the WG should adopt = https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ = as a WG = item. We have marked the draft as a "Candidate for WG Adoption=E2=80=9D = in the datatracker, but now it=E2=80=99s time to officially do the WG = call for adoption. So, if you would like for this draft to become a WG = document and you are willing to review various versions as it moves = through the process, then please let the list know by 2359UTC = 2018.08.03. If you are opposed to this being a WG document, please say = so (and say why). >=20 > Cheers, >=20 > Nick and Sean >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_A78D6709-6947-4727-B1FB-8E1C818DFAF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I support the adoption.

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

All,

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

Cheers,

Nick and Sean

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

= --Apple-Mail=_A78D6709-6947-4727-B1FB-8E1C818DFAF7-- From nobody Wed Jul 25 04:01:19 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6B5130DDF for ; Wed, 25 Jul 2018 04:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=UNlj5gFb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ukSuRGCz 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 dNJcHWGHa1PW for ; Wed, 25 Jul 2018 04:01:11 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7005F12DD85 for ; Wed, 25 Jul 2018 04:01:11 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9873E305 for ; Wed, 25 Jul 2018 07:01:10 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Wed, 25 Jul 2018 07:01:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=rL0zEem/VVeO9uJ6ixbwxDiyAs4h2hjWEQ1JyR8jFvg=; b=UNlj5 gFbayx1lh1DaFLd2/6SVTkykZRw83a41cioER1M2oxsIDgrkbBIU0UcCR4Dn+Nwe 0IC08WkqMcbw8fyGQmwM6zgoWsovGMdBSP6y1qai7lqYkWCurV+qeQ4TwYur6jDG vP0l1rza+HuUfGydC/1rSWffKBvAuSeBO7hUuo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=rL0zEem/VVeO9uJ6ixbwxDiyAs4h2 hjWEQ1JyR8jFvg=; b=ukSuRGCza2roX0/s9cZV/2Y4PQ9An6EQocdMTHX2wS0U0 5cBwWyHsMkyEzfwAgRWvGuXcsIXReVYaSHQwQ94w8Mop/mWGoYiP/EoQ9KaE/8Vz Offr8irOY0P7jZwhgNZdXHfi48AeqCMHyRf6pkzuOOJX2UHoR92SC3DUsd0/t1AX g9aI0rLVvLSxdNtuZ2heZurgmYEMaCGBBvEdc9RVw3dN7nxgxpe3Y/2+9xLhmECA Qt1ypk8a5r4Zdz6o5l+PPP9pz8L/Ex4D3NZheGLez0ht1TP2100SJlVFZT1lJys9 y1Gkx3AIfQZkOEXMlIA1ehHvcNiY+F1pe8NNmmd5g== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A8201BA4CF; Wed, 25 Jul 2018 07:01:09 -0400 (EDT) Message-Id: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153251646935706860" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Wed, 25 Jul 2018 12:01:09 +0100 Archived-At: Subject: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 11:01:18 -0000 This is a multi-part message in MIME format. --_----------=_153251646935706860 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi all, Here'a s case we might want to think about: what should happen if a *current member* of a group asks to join, with the same long-term key that they're already joined with? The simple answer is to forbid such joins, but this might happen if a device forgets its group state but remembers its identity key. (Perhaps it writes the group state to a local database and the write got corrupted.) Alternatively I see a handful of different ways we could support these joins, if we wanted to. Perhaps the simplest is to allow the device to double-join but require it to immediately delete the old copy of itself. best, k --_----------=_153251646935706860 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi all,

Here'a s case we might want to think about: what should happen if a current member of a group asks to join, with the same long-term key that they're already joined with?

The simple answer is to forbid such joins, but this might happen if a device forgets its group state but remembers its identity key. (Perhaps it writes the group state to a local database and the write got corrupted.)

Alternatively I see a handful of different ways we could support these joins, if we wanted to. Perhaps the simplest is to allow the device to double-join but require it to immediately delete the old copy of itself.

best,
k

--_----------=_153251646935706860-- From nobody Wed Jul 25 04:05:17 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BFD130E1E for ; Wed, 25 Jul 2018 04:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Mq1MoYHZ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=V1b4BCtc 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 JvWN64fJ8VG3 for ; Wed, 25 Jul 2018 04:05:13 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 14FBF130DDF for ; Wed, 25 Jul 2018 04:05:12 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6PB1cvg000316; Wed, 25 Jul 2018 04:05:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=HXX9NDSesL+CaUgOWVtVaKDrbViWw/SiGcsbbIz73d0=; b=Mq1MoYHZT/H1ny/MTfLTJaA7/LRtxHKPEN2syfQPUTX2uXgOAn0WyuKKUcP/UC9CUWPb 8VgeTLFtc1rRmiKuNyCsm1yjSOdD3lZh6vqU6RObnRPVOZYvXKZzqy3mp3lMDZECs/mb tCSxjcZovn2XqaPDcwWOINRqr82rm9cjtpw= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0b-00082601.pphosted.com with ESMTP id 2keqpa017r-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jul 2018 04:05:12 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.29) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Jul 2018 07:05:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HXX9NDSesL+CaUgOWVtVaKDrbViWw/SiGcsbbIz73d0=; b=V1b4BCtcey2UphFx9oLbxks8ZOhe/TWzd9ceY6HrA89N9XFx1J+Kx9tUDDPP7d4YdpZVO2QlyvkZgw6nwLe3TRFPcSx7Pec+RIADOZa7GRvihEWJo9A1ez5tpKpnIqJjdxDo3tG5OHD9vYCsnfdD+Qpw7ltOG3KVOYuPVmYy/DA= Received: from SN6PR15MB2205.namprd15.prod.outlook.com (52.135.64.145) by SN6PR15MB2334.namprd15.prod.outlook.com (52.135.65.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Wed, 25 Jul 2018 11:05:09 +0000 Received: from SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b]) by SN6PR15MB2205.namprd15.prod.outlook.com ([fe80::543d:ab65:689f:8f6b%4]) with mapi id 15.20.0995.014; Wed, 25 Jul 2018 11:05:09 +0000 From: Jon Millican To: Katriel Cohn-Gordon , "mls@ietf.org" Thread-Topic: [MLS] *re*joining a group with the same identity key Thread-Index: AQHUJAbi8+8/pJnc+E+jbg98l9wWk6Sf12gA Date: Wed, 25 Jul 2018 11:05:09 +0000 Message-ID: <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> In-Reply-To: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:200::1:c79a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR15MB2334; 20:zX/ajcM83rIfSL+3AJ+S3hqR6rKzGWo4eNDM48Q8prZgCjov9uLP6voThluBZFQ+IL/xKe4gosLSYy9J/KfmunyBrGnWuxk6DI7JQbUBSgKu7GeMuNDjxIaweDpd7XyJvDvVhy3AmRwPpEdmgevTs6wSYJ8tlGW9DKb7he4pWSI= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b68d1efd-5845-4cb9-ffdb-08d5f21e7c70 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:SN6PR15MB2334; x-ms-traffictypediagnostic: SN6PR15MB2334: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(11241501184)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:SN6PR15MB2334; BCL:0; PCL:0; RULEID:; SRVR:SN6PR15MB2334; x-forefront-prvs: 0744CFB5E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(346002)(376002)(39860400002)(199004)(53754006)(189003)(2616005)(36756003)(186003)(6306002)(6486002)(102836004)(99286004)(76176011)(486006)(476003)(229853002)(7736002)(2501003)(6506007)(5250100002)(53546011)(478600001)(46003)(8676002)(81156014)(8936002)(6116002)(14454004)(316002)(110136005)(11346002)(83716003)(81166006)(446003)(25786009)(6246003)(53936002)(5660300001)(256004)(86362001)(97736004)(106356001)(6436002)(2900100001)(236005)(6512007)(2906002)(105586002)(54896002)(82746002)(33656002)(68736007)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR15MB2334; H:SN6PR15MB2205.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7AosQA5u7lr6b4aRaMJfPicuRY8uKG91mEajlN4ZFmUGmN6QQthd/4PHA4Ks3vQmqA7gVEH/iyHY+/B4AiYxwDiCquyRVC3S1xqptc4rb5cfZk6rtVhatDUGetHs3I5KDEbkZu++CLadyQwKDgq3XAZBX0WAcVIRrZHQDWICRCfgw40Rpg5CqhiTNnSs7q4rfSPBzE/pnFlcguHrLNZM5iIhrMn5+pOQMBkqIdrrIGFu4YXOE3y970JTXF3hed++kjmcMG2ntSH1kLb8JrH/JMemoOp/76pnfWdYfEUVpase2YekUcIq5nCPGpZpn/mED/aMXKyDkiMdmc+iyG4uxZtcWidMaCR6SfAS0sOwTSE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2046EE4E2F254E8988440EDAAABA2A38fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b68d1efd-5845-4cb9-ffdb-08d5f21e7c70 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2018 11:05:09.3153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2334 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-25_03:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 11:05:17 -0000 --_000_2046EE4E2F254E8988440EDAAABA2A38fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHBvdGVudGlhbCBvcHRpb24gdGhhdCBjb21lcyB0byBtaW5kIGlzIGZvciB0aGUgc2VydmVy IHRvIGhlbHAgaXQgcmVpbnNlcnQgaXRzZWxmIGluIHRoZSBjb3JyZWN0IHBsYWNlLiBUaGlzIHdv dWxkIGVzc2VudGlhbGx5IGFtb3VudCB0byBhIGpvaW4sIGJ1dCBzZXJ2aW5nIGl0cyBvd24gY29w YXRoIGluc3RlYWQgb2YgdGhlIGdyb3Vw4oCZcyBmcm9udGllci4gV2UgY291bGQgdGhlbiByZWpl Y3Qgc29tZWJvZHkgZG91YmxlLWpvaW5pbmcgdGhlaXIgb3duIGlkZW50aXR5IGtleTsgdW5kZXIg dGhlIGFzc3VtcHRpb24gdGhhdCB0aGlzIGNvdWxkIG9ubHkgaGFwcGVuIHdpdGggYSBtYWxpY2lv dXMgc2VydmVyIGFueXdheS4NCg0KSSBkb27igJl0IGhhdmUgc3Ryb25nIGZlZWxpbmdzIGFib3V0 IHRoaXMgdnMgeW91ciBwcm9wb3NlZCBzb2x1dGlvbiB0aG91Z2guIFRoZSBtYWluIGJlbmVmaXQg d291bGQgcHJvYmFibHkgYmUganVzdCBpbiB0ZXJtcyBvZiBrZWVwaW5nIHRoZSB0cmVlIGNsZWFu ZXIgYW5kIG1pbmltaXNpbmcgcmVtb3ZlIG9wZXJhdGlvbnMgdGhhdCBuZWVkIHRvIGJlIGRvbmUu DQoNCkpvbg0KDQpPbiAyNS8wNy8yMDE4LCAxMjowMSwgIk1MUyBvbiBiZWhhbGYgb2YgS2F0cmll bCBDb2huLUdvcmRvbiIgPG1scy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbHMtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1lQGthdHJpZWwuY28udWs8bWFpbHRvOm1lQGthdHJpZWwu Y28udWs+PiB3cm90ZToNCg0KSGkgYWxsLA0KDQpIZXJlJ2EgcyBjYXNlIHdlIG1pZ2h0IHdhbnQg dG8gdGhpbmsgYWJvdXQ6IHdoYXQgc2hvdWxkIGhhcHBlbiBpZiBhIGN1cnJlbnQgbWVtYmVyIG9m IGEgZ3JvdXAgYXNrcyB0byBqb2luLCB3aXRoIHRoZSBzYW1lIGxvbmctdGVybSBrZXkgdGhhdCB0 aGV5J3JlIGFscmVhZHkgam9pbmVkIHdpdGg/DQoNClRoZSBzaW1wbGUgYW5zd2VyIGlzIHRvIGZv cmJpZCBzdWNoIGpvaW5zLCBidXQgdGhpcyBtaWdodCBoYXBwZW4gaWYgYSBkZXZpY2UgZm9yZ2V0 cyBpdHMgZ3JvdXAgc3RhdGUgYnV0IHJlbWVtYmVycyBpdHMgaWRlbnRpdHkga2V5LiAoUGVyaGFw cyBpdCB3cml0ZXMgdGhlIGdyb3VwIHN0YXRlIHRvIGEgbG9jYWwgZGF0YWJhc2UgYW5kIHRoZSB3 cml0ZSBnb3QgY29ycnVwdGVkLikNCg0KQWx0ZXJuYXRpdmVseSBJIHNlZSBhIGhhbmRmdWwgb2Yg ZGlmZmVyZW50IHdheXMgd2UgY291bGQgc3VwcG9ydCB0aGVzZSBqb2lucywgaWYgd2Ugd2FudGVk IHRvLiBQZXJoYXBzIHRoZSBzaW1wbGVzdCBpcyB0byBhbGxvdyB0aGUgZGV2aWNlIHRvIGRvdWJs ZS1qb2luIGJ1dCByZXF1aXJlIGl0IHRvIGltbWVkaWF0ZWx5IGRlbGV0ZSB0aGUgb2xkIGNvcHkg b2YgaXRzZWxmLg0KDQpiZXN0LA0Kaw0KDQo= --_000_2046EE4E2F254E8988440EDAAABA2A38fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <699AF091DABC174F9043AD1E90D3A018@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Omdlb3JnaWE7 DQoJcGFub3NlLTE6MiA0IDUgMiA1IDQgNSAyIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTm9TcGFjaW5nLCBsaS5Nc29Ob1NwYWNpbmcsIGRpdi5Nc29Ob1NwYWNpbmcN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjE7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIHBvdGVudGlhbCBvcHRpb24gdGhhdCBj b21lcyB0byBtaW5kIGlzIGZvciB0aGUgc2VydmVyIHRvIGhlbHAgaXQgcmVpbnNlcnQgaXRzZWxm IGluIHRoZSBjb3JyZWN0IHBsYWNlLiBUaGlzIHdvdWxkIGVzc2VudGlhbGx5IGFtb3VudCB0byBh IGpvaW4sIGJ1dCBzZXJ2aW5nIGl0cyBvd24gY29wYXRoIGluc3RlYWQgb2YgdGhlIGdyb3Vw4oCZ cyBmcm9udGllci4gV2UgY291bGQgdGhlbiByZWplY3Qgc29tZWJvZHkNCiBkb3VibGUtam9pbmlu ZyB0aGVpciBvd24gaWRlbnRpdHkga2V5OyB1bmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoaXMg Y291bGQgb25seSBoYXBwZW4gd2l0aCBhIG1hbGljaW91cyBzZXJ2ZXIgYW55d2F5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQgaGF2ZSBzdHJvbmcgZmVlbGluZ3MgYWJvdXQgdGhp cyB2cyB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uIHRob3VnaC4gVGhlIG1haW4gYmVuZWZpdCB3b3Vs ZCBwcm9iYWJseSBiZSBqdXN0IGluIHRlcm1zIG9mIGtlZXBpbmcgdGhlIHRyZWUgY2xlYW5lciBh bmQgbWluaW1pc2luZyByZW1vdmUgb3BlcmF0aW9ucyB0aGF0IG5lZWQgdG8gYmUgZG9uZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjUvMDcvMjAxOCwgMTI6MDEsICZx dW90O01MUyBvbiBiZWhhbGYgb2YgS2F0cmllbCBDb2huLUdvcmRvbiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1scy1ib3VuY2VzQGlldGYub3JnIj5tbHMtYm91bmNlc0BpZXRmLm9yZzwvYT4g b24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86bWVAa2F0cmllbC5jby51ayI+bWVAa2F0cmll bC5jby51azwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtn ZW9yZ2lhJnF1b3Q7LHNlcmlmIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5IZXJlJ2EgcyBjYXNlIHdlIG1pZ2h0IHdhbnQgdG8g dGhpbmsgYWJvdXQ6IHdoYXQgc2hvdWxkIGhhcHBlbiBpZiBhJm5ic3A7PGk+Y3VycmVudCBtZW1i ZXI8L2k+IG9mIGEgZ3JvdXAgYXNrcyB0byBqb2luLCB3aXRoIHRoZSBzYW1lIGxvbmctdGVybSBr ZXkgdGhhdCB0aGV5J3JlIGFscmVhZHkgam9pbmVkDQogd2l0aD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90Oyxz ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPlRoZSBzaW1wbGUgYW5zd2VyIGlz IHRvIGZvcmJpZCBzdWNoIGpvaW5zLCBidXQgdGhpcyBtaWdodCBoYXBwZW4gaWYgYSBkZXZpY2Ug Zm9yZ2V0cyBpdHMgZ3JvdXAgc3RhdGUgYnV0IHJlbWVtYmVycyBpdHMgaWRlbnRpdHkga2V5LiAo UGVyaGFwcyBpdCB3cml0ZXMgdGhlIGdyb3VwIHN0YXRlDQogdG8gYSBsb2NhbCBkYXRhYmFzZSBh bmQgdGhlIHdyaXRlIGdvdCBjb3JydXB0ZWQuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+QWx0ZXJuYXRpdmVseSBJIHNlZSBhIGhhbmRmdWwg b2YgZGlmZmVyZW50IHdheXMgd2UgY291bGQgc3VwcG9ydCB0aGVzZSBqb2lucywgaWYgd2Ugd2Fu dGVkIHRvLiBQZXJoYXBzIHRoZSBzaW1wbGVzdCBpcyB0byBhbGxvdyB0aGUgZGV2aWNlIHRvIGRv dWJsZS1qb2luIGJ1dCByZXF1aXJlIGl0DQogdG8gaW1tZWRpYXRlbHkgZGVsZXRlIHRoZSBvbGQg Y29weSBvZiBpdHNlbGYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtnZW9yZ2lh JnF1b3Q7LHNlcmlmIj5iZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5rPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEm cXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2046EE4E2F254E8988440EDAAABA2A38fbcom_-- From nobody Wed Jul 25 04:58:54 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7226F131008 for ; Wed, 25 Jul 2018 04:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RuEa4BNgb_us for ; Wed, 25 Jul 2018 04:58:49 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) (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 B8CD0130FF4 for ; Wed, 25 Jul 2018 04:58:40 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fiIRA-0000ez-mj for mls@ietf.org; Wed, 25 Jul 2018 12:58:38 +0100 Received: from visitor-nat.cs.ox.ac.uk ([163.1.88.1] helo=T-200) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fiIR9-00063u-Fi for mls@ietf.org; Wed, 25 Jul 2018 12:58:35 +0100 Date: Wed, 25 Jul 2018 12:58:30 +0100 From: Dennis Jackson To: mls@ietf.org Message-ID: <20180725125830.6af30662@T-200> In-Reply-To: <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/qhc.5z+FI2HxYb3Cek_uemT"; protocol="application/pgp-signature" X-Oxford-Username: exet4027 X-Oxmail-Spam-Status: score=0.0 tests=none X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 11:58:53 -0000 --Sig_/qhc.5z+FI2HxYb3Cek_uemT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable me@katriel.co.uk wrote: > The simple answer is to forbid such joins, but this might happen if a > device forgets its group state but remembers its identity key. Depending on how MLS specifies update operations, this could also happen if there was a network partition and some group members see a different order of key updates. Even if we assume the existence of a delivery service which can provide a linear order for key update messages, the attacker will be allowed to compromise the server and violate this property. Consequently, some participants will have differing views of the group key and need to converge. In both cases we have a long term key, already in the group, with bad local state. I think we need a recovery mechanism for this other than just starting a new group or allowing a rejoin since that would allow an attacker with only knowledge of a long term key to join a previously secure group.=20 We could mitigate this by proving knowledge of some recent state: a device which knew the group key five minutes ago is more trustworthy than one which doesn=E2=80=99t know any group state. It=E2=80=99s an applic= ation-layer decision to actually figure out what to do in this case, but we could expose a way to prove state knowledge (e.g. by deriving a =E2=80=9Crecovery= =E2=80=9D key after every update). Best, Dennis On Wed, 25 Jul 2018 11:05:09 +0000 Jon Millican wrote: > One potential option that comes to mind is for the server to help it > reinsert itself in the correct place. This would essentially amount > to a join, but serving its own copath instead of the group=E2=80=99s > frontier. We could then reject somebody double-joining their own > identity key; under the assumption that this could only happen with a > malicious server anyway. >=20 > I don=E2=80=99t have strong feelings about this vs your proposed solution > though. The main benefit would probably be just in terms of keeping > the tree cleaner and minimising remove operations that need to be > done. >=20 > Jon >=20 > On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon" > on behalf of > me@katriel.co.uk> wrote: >=20 > Hi all, >=20 > Here'a s case we might want to think about: what should happen if a > current member of a group asks to join, with the same long-term key > that they're already joined with? >=20 > The simple answer is to forbid such joins, but this might happen if a > device forgets its group state but remembers its identity key. > (Perhaps it writes the group state to a local database and the write > got corrupted.) >=20 > Alternatively I see a handful of different ways we could support > these joins, if we wanted to. Perhaps the simplest is to allow the > device to double-join but require it to immediately delete the old > copy of itself. >=20 > best, > k >=20 --=20 PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC --Sig_/qhc.5z+FI2HxYb3Cek_uemT Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJbWGXnAAoJEGEFp3WM0kas548P/iHNndlus1HqNDTViu68yu/X nN5qZD9F+Czb292y4CarJ9apBZflrmX+4XhhXi8KCdkk+aJOLnCaSBdu1GJrbCIa 10/kY0DHoGZNU6keea12XfyKfMMLZdZaoU1tuOIUUQolnj2JrRXPDJe3npiuhXaC NVtdRR3JF1kuuNKuLRKFZd6uyWZ/81NMqQHxRn6llukp20AxrGWBvsgrLLWvD0PK /nZBJcCVO9Ujphm47z7aqLow67FHzxTJJ4ChgrcxuXycskpfXqnudzuv4TREt1mo fj8BYNDWRvydqN193l7HfvPuBAeGum6eXAiHGb5E7kBUVxdjcCOOKQuMpSHVzoe5 TP4lcgxDZN7rtkWRMDULl7PO4hAQuEyh7uWv6IpD6ei7bfJcyUd8ryKlTa/jhnv2 JK4NugmEYd0RMNWL0BQNxCIjgAqOFMT+wu9SDk7By3EIBQorq1BViY+wxkpggCHo Kvqy7bONeFKtz7sO0TgOxPPjAPBdLhGhmq2cqNGP5fSjUajK/Vd6HBYcKV/7uC/g 7Sncc2LNV15FYBlT/gmeLdbDjIYprfIBRmh8vmYH5+FNiCNUeNiq8wSHf7kR1qj/ XxTMoGs+nxq7yBiedZvuTC7QyrlTkDMO8x3xpiUTaqN4OWYDMR/GPtgm4JaKz7fu L3aAKAF0jZSMlMGDpu1u =ddsp -----END PGP SIGNATURE----- --Sig_/qhc.5z+FI2HxYb3Cek_uemT-- From nobody Thu Jul 26 08:42:28 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F52131157 for ; Thu, 26 Jul 2018 08:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoX2G6qoouPq for ; Thu, 26 Jul 2018 08:42:24 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716CA130EA5 for ; Thu, 26 Jul 2018 08:42:24 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id q11-v6so3723233oic.12 for ; Thu, 26 Jul 2018 08:42:24 -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=HM+2zfboEOKLN/knBJvKZraJBlAIb0A9qOq0+CyNmDg=; b=dUhUbYgPifuMaKZF+tWw4jkxZ3zn8OUXisCn3gF34N++2+kOMkAO4kTyJOQzSN0P/t hsFvaZzGObky250w5rGrGcqbrrjjc5alvOL7ja84/RHKHIT84A6Sx+/WQhATktTLn3Hq +EG6WLoFqHVSksD/60eETY7jB5fJ4CW0tN+5xu+PJZzIxafDc34eu0MwSCMOehPywLbu lUATrTD+SrFVlvXOyVOpYvbN8UVJfmED062Hvo9wkx1cjXznfDTlz5kBtSc8oSl1tg+e lPoUavwOnLwdX2T3/GIrzX4ODCs/sitXaFoxo3kGO3PmiJxPOxuFlZvE1k7/6bxn4dEP wqxA== 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=HM+2zfboEOKLN/knBJvKZraJBlAIb0A9qOq0+CyNmDg=; b=rjkTk+eO2fTw7KgnYfs0VRpLve3GOhx95cDmdsGZ2Pt0f7FbyUj9cLjeaC7xP2S8Nm QbCdWy3SwDd3KjQfq8VjbJrG8VFtELj9VvHH223Dzn2EVjJa8Ryciqg993CgvfMqO+QQ 0mAiA9aY5zgotqlq4cvcKxYuOT9ZU604q5F8KyMkBL/x/tQtN3mTEbym1gJIqCtOjTOw 2UQ2D85ZHY7jLpWbiiyhRwOT3LojjSr9dPKLNDiXNu3ai6IeJWvIPEG75V/1g0WLZb8U TuTx+ROemawfgNBaYnEu0BCne3NhVgT1qNnByLvD439bhVcrEuAPL6AzslBPfZ1qiaf0 6pVQ== X-Gm-Message-State: AOUpUlEV8YsXMqbEwWDN07mK+Xlpsu4M4P7HY6/EnS0r1EVIkXD/Uj5i U+pX8GcMRgV31rHHmpZzp4SjpgCbPxEjyCc567AvBA75G8E= X-Google-Smtp-Source: AAOMgpd+r2dM0G3bhNpbDg4LUuScudaWfeS5KSd6spzeAdmLvGe0gtNyIXrd995x1gmrHLGnOm57ZiFG5zALrY1OcJA= X-Received: by 2002:aca:ce51:: with SMTP id e78-v6mr2362637oig.225.1532619743631; Thu, 26 Jul 2018 08:42:23 -0700 (PDT) MIME-Version: 1.0 References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> In-Reply-To: <20180725125830.6af30662@T-200> From: Richard Barnes Date: Thu, 26 Jul 2018 11:42:11 -0400 Message-ID: To: dennis.jackson@cs.ox.ac.uk Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000006535ea0571e8d7e6" Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 15:42:27 -0000 --0000000000006535ea0571e8d7e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I actually expect this to be a not-uncommon case. Two use cases immediately come to mind: 1. New devices in an application where identity keys are sync'ed among devices 2. Participants who have lost state and need to re-sync. On account of (1), I had been thinking that the mapping between members / leaves in the tree and identity keys would not be one-to-one, but many-to-one. Are folks thinking that there would be technical problems / ambiguities in such a case? None are coming to my mind. It does seem worth thinking about the re-sync case (2), i.e., the case where a participant has most of his state. If he's forgotten everything besides his identity private key (or including the identity private key), I don't think there's much you can do but treat him like a new participant. If he remembers his position in the tree, it seems like you could do a "re-sync" transaction that's like an add, but for that position in the tree -- it's the same logic as an add, except instead of the frontier, you send the copath for that position; for other nodes, it just looks like an Update at that position. (Aside: This reinforces that we really only have 1.2 operations here: Update + handle-update-at-edge + encrypt-leaf-secret) It also seems like if we can solve the "re-sync a member with lost state" problem, then we can probably also solve the "heal a network partition" problem that Dennis raises. Assuming we can choose a winning partition and appoint someone to do the merge, the person doing the merge can just re-initialize the losing members to their point in the tree, as if they had lost their state. --Richard On Wed, Jul 25, 2018 at 7:59 AM Dennis Jackson wrote: > me@katriel.co.uk wrote: > > > The simple answer is to forbid such joins, but this might happen if a > > device forgets its group state but remembers its identity key. > > Depending on how MLS specifies update operations, this could also > happen if there was a network partition and some group members see a > different order of key updates. Even if we assume the existence of a > delivery service which can provide a linear order for key update > messages, the attacker will be allowed to compromise the server and > violate this property. Consequently, some participants will have > differing views of the group key and need to converge. > > In both cases we have a long term key, already in the group, with bad > local state. I think we need a recovery mechanism for this other than > just starting a new group or allowing a rejoin since that would allow > an attacker with only knowledge of a long term key to join a previously > secure group. > > We could mitigate this by proving knowledge of some recent state: a > device which knew the group key five minutes ago is more trustworthy > than one which doesn=E2=80=99t know any group state. It=E2=80=99s an appl= ication-layer > decision to actually figure out what to do in this case, but we could > expose a way to prove state knowledge (e.g. by deriving a =E2=80=9Crecove= ry=E2=80=9D > key after every update). > > Best, > Dennis > > On Wed, 25 Jul 2018 11:05:09 +0000 > Jon Millican wrote: > > > One potential option that comes to mind is for the server to help it > > reinsert itself in the correct place. This would essentially amount > > to a join, but serving its own copath instead of the group=E2=80=99s > > frontier. We could then reject somebody double-joining their own > > identity key; under the assumption that this could only happen with a > > malicious server anyway. > > > > I don=E2=80=99t have strong feelings about this vs your proposed soluti= on > > though. The main benefit would probably be just in terms of keeping > > the tree cleaner and minimising remove operations that need to be > > done. > > > > Jon > > > > On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon" > > on behalf of > > me@katriel.co.uk> wrote: > > > > Hi all, > > > > Here'a s case we might want to think about: what should happen if a > > current member of a group asks to join, with the same long-term key > > that they're already joined with? > > > > The simple answer is to forbid such joins, but this might happen if a > > device forgets its group state but remembers its identity key. > > (Perhaps it writes the group state to a local database and the write > > got corrupted.) > > > > Alternatively I see a handful of different ways we could support > > these joins, if we wanted to. Perhaps the simplest is to allow the > > device to double-join but require it to immediately delete the old > > copy of itself. > > > > best, > > k > > > > > > -- > PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000006535ea0571e8d7e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I actually expect this to be a not-uncommon case.=C2= =A0 Two use cases immediately come to mind:

1. New= devices in an application where identity keys are sync'ed among device= s
2. Participants who have lost state and need to re-sync.
<= div>
On account of (1), I had been thinking that the mapping = between members / leaves in the tree and identity keys would not be one-to-= one, but many-to-one.=C2=A0 Are folks thinking that there would be technica= l problems / ambiguities in such a case?=C2=A0 None are coming to my mind.<= /div>

It does seem worth thinking about the re-sync case= (2), i.e., the case where a participant has most of his state.=C2=A0 If he= 's forgotten everything besides his identity private key (or including = the identity private key), I don't think there's much you can do bu= t treat him like a new participant.=C2=A0 If he remembers his position in t= he tree, it seems like you could do a "re-sync" transaction that&= #39;s like an add, but for that position in the tree -- it's the same l= ogic as an add, except instead of the frontier, you send the copath for tha= t position; for other nodes, it just looks like an Update at that position.=

(Aside: This reinforces that we really only have = 1.2 operations here: Update=C2=A0+ handle-update-at-edge + encrypt-leaf-sec= ret)

It also seems like if we can solve the &q= uot;re-sync a member with lost state" problem, then we can probably al= so solve the "heal a network partition" problem that Dennis raise= s.=C2=A0 Assuming we can choose a winning partition and appoint someone to = do the merge, the person doing the merge can just re-initialize the losing = members to their point in the tree, as if they had lost their state.
<= div>
--Richard


On Wed, Jul 25, 2018 at 7:59 AM Dennis Ja= ckson <dennis.jackson@cs.o= x.ac.uk> wrote:
me@katriel.co.uk<mailto:me@katriel.co.uk>= ; wrote:

> The simple answer is to forbid such joins, but this might happen if a<= br> > device forgets its group state but remembers its identity key.

Depending on how MLS specifies update operations, this could also
happen if there was a network partition and some group members see a
different order of key updates. Even if we assume the existence of a
delivery service which can provide a linear order for key update
messages, the attacker will be allowed to compromise the server and
violate this property. Consequently, some participants will have
differing views of the group key and need to converge.

In both cases we have a long term key, already in the group, with bad
local state. I think we need a recovery mechanism for this other than
just starting a new group or allowing a rejoin since that would allow
an attacker with only knowledge of a long term key to join a previously
secure group.

We could mitigate this by proving knowledge of some recent state: a
device which knew the group key five minutes ago is more trustworthy
than one which doesn=E2=80=99t know any group state. It=E2=80=99s an applic= ation-layer
decision to actually figure out what to do in this case, but we could
expose a way to prove state knowledge (e.g. by deriving a =E2=80=9Crecovery= =E2=80=9D
key after every update).

Best,
Dennis

On Wed, 25 Jul 2018 11:05:09 +0000
Jon Millican <jmil= lican@fb.com> wrote:

> One potential option that comes to mind is for the server to help it > reinsert itself in the correct place. This would essentially amount > to a join, but serving its own copath instead of the group=E2=80=99s > frontier. We could then reject somebody double-joining their own
> identity key; under the assumption that this could only happen with a<= br> > malicious server anyway.
>
> I don=E2=80=99t have strong feelings about this vs your proposed solut= ion
> though. The main benefit would probably be just in terms of keeping > the tree cleaner and minimising remove operations that need to be
> done.
>
> Jon
>
> On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon"=
> <mls-boun= ces@ietf.org<mailto:mls-bounces@ietf.org> on behalf of
> me@katriel.co.uk= <mailto:me@kat= riel.co.uk>> wrote:
>
> Hi all,
>
> Here'a s case we might want to think about: what should happen if = a
> current member of a group asks to join, with the same long-term key > that they're already joined with?
>
> The simple answer is to forbid such joins, but this might happen if a<= br> > device forgets its group state but remembers its identity key.
> (Perhaps it writes the group state to a local database and the write > got corrupted.)
>
> Alternatively I see a handful of different ways we could support
> these joins, if we wanted to. Perhaps the simplest is to allow the
> device to double-join but require it to immediately delete the old
> copy of itself.
>
> best,
> k
>



--
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000006535ea0571e8d7e6-- From nobody Thu Jul 26 09:33: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 E4A0B130F9F for ; Thu, 26 Jul 2018 09:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 YJrtV4uHWuwr for ; Thu, 26 Jul 2018 09:32:50 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5FD131209 for ; Thu, 26 Jul 2018 09:32:50 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id d9-v6so3376885itf.2 for ; Thu, 26 Jul 2018 09:32:50 -0700 (PDT) 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=+z129sp1zG1W86GPEgdDySkjm+//TfSi0N53q59KXUg=; b=Tb9wbpw76gxqS2LjW7t5KMH33f61ZYtuDy5U1iJGNnHdW5qgMK23SGkoMl665HHEQY 6Zcp9E2RENnDrZqrA6aYllqh+ygvqKhue5uqaNzTk8XzwM2RTo96fK6VSsDoJUg5TRf+ 1ZnQ41tP0NQEzQXO2ZsBeuRiqCuF9TVrwm1Uw= 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=+z129sp1zG1W86GPEgdDySkjm+//TfSi0N53q59KXUg=; b=aK4FSL70TbLPFCDKugYN9isqZPAQLJaxCq98aWRDwuB/d4/Q0lrbr6fEwJpFJS9OOC F4Po+nBzlztZ+JTPBZcUycUPkH7aQI9kA5/PdDPz9gSVAK+mrwBVWnLsWYwWaNiif8gR 9P7f5U9hNIkj/fiqD6Oi8xvR9PzmQw2SZ/RILPDNbQsxGGhiTx1ThF8bIpSx7InUCswW cV6ywEj2j7PBi9jFhWiGUajG3hIOpfsbSkwjTUNhfRylZNu68qzuRQ0oBE4pAXKThvAw Dr1SsYqWSDObj0t57EVZ0rW431cAjroFK4Z0D7OhAEQw5zF/EAYBs+FL65hHO83f1wBy 95KQ== X-Gm-Message-State: AOUpUlG2CwetmeBGr+lvCrkOHEFi5Xi9vdq6tsWF8c6OU71yREPthe+7 ICoJHiDMvx6HezrHgTGYkVslAw== X-Google-Smtp-Source: AAOMgpcpfUc66VhkBxx4L9H/6Gx8b9JowJCrhh4Xb/4JJXwYi5wKhQJVx/k2vjKKo9EOYTNwHv6oEw== X-Received: by 2002:a24:c2c2:: with SMTP id i185-v6mr2649240itg.76.1532622769802; Thu, 26 Jul 2018 09:32:49 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id e2-v6sm517755ioa.33.2018.07.26.09.32.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 09:32:48 -0700 (PDT) To: Richard Barnes , dennis.jackson@cs.ox.ac.uk Cc: mls@ietf.org References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> 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: Date: Thu, 26 Jul 2018 10:32:47 -0600 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mblWZcnPa1IWZWQkx7L1SDrhYjqeemFz5" Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 16:32:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mblWZcnPa1IWZWQkx7L1SDrhYjqeemFz5 Content-Type: multipart/mixed; boundary="Ibem9pxydG330apEPdCOYAcbN5Tqip9PZ"; protected-headers="v1" From: Peter Saint-Andre To: Richard Barnes , dennis.jackson@cs.ox.ac.uk Cc: mls@ietf.org Message-ID: Subject: Re: [MLS] *re*joining a group with the same identity key References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> In-Reply-To: --Ibem9pxydG330apEPdCOYAcbN5Tqip9PZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/26/18 9:42 AM, Richard Barnes wrote: > I actually expect this to be a not-uncommon case.=C2=A0 Two use cases > immediately come to mind: >=20 > 1. New devices in an application where identity keys are sync'ed among > devices > 2. Participants who have lost state and need to re-sync. >=20 > On account of (1), I had been thinking that the mapping between members= > / leaves in the tree and identity keys would not be one-to-one, but > many-to-one.=C2=A0 Are folks thinking that there would be technical pro= blems > / ambiguities in such a case?=C2=A0 None are coming to my mind. This sounds similar to something we did in XMPP, allowing multiple in-room sessions for the same JabberID (although, naturally, the MLS context is more advanced cryptographically): https://xmpp.org/extensions/xep-0045.html#enter-conflict Peter --Ibem9pxydG330apEPdCOYAcbN5Tqip9PZ-- --mblWZcnPa1IWZWQkx7L1SDrhYjqeemFz5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltZ968ACgkQZWGMGH9o FKkwNg/+OFN/YhbDsJ3IDiaZR638Pk3KoLYxGgbPZq6plv+6MtaPkWiwPlaa0b7n 38MvymBc/fYeSHbxJM5Aum6zPKc7pxhsGFsYqMdjE6OtAIwUj4E6CuHKkeB8pFM8 ne65B1NVoQPFb14+zbb2GnLBpTobKYLzdhGti4m8YDed2Mk6PZhnULPnWqZt4Zby 3WF5VWZwmOVqjQuBQWPE80vVIRGEPaMvN7lHNW4DD6j3yZrK7Jc4JiTlJw19QGr4 eUm5sN2VCPjUqa711UESdLMeTBSC7/jdZROPZe4c5XQf9ZYIfjTLLeNliL/EkWiI dWc4R5mLWikGKXEB1ZExof1fK0IZS06wcEkwVMVsI+28XGsgLaONVCjVPHgVeYZX hCvq9yvuyDnEtyXvHEjLjd8FTa0DH+V+C0quDkxDYUjFDXPe0EAYFW2vRhDLUPcA km7f3wGUlv+bnVZCwCsA2o6nkv0Itc8xY6MnXnrlw8hvIc498I0VLubWzJ1Y7B2p HBZ0a1XWa+1OtE32Xte6+DEmPoTEi+0ILWniV9VZaUx+7f2F+0Ny5XHbJVPbXTlC EBMZH1GgeCidWqu+Q2vhILgOVRUorEIapA91U2LCuTZE18z+ahd+TptugxCzQJCP PqhTPhfCZVu8xpmXQUyFbDvOoyk/POYoRV2dmoaFTCr7zvT3cWY= =Gygb -----END PGP SIGNATURE----- --mblWZcnPa1IWZWQkx7L1SDrhYjqeemFz5-- From nobody Thu Jul 26 09:44: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 15B4713123D for ; Thu, 26 Jul 2018 09:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDCsaM144zWW for ; Thu, 26 Jul 2018 09:43:47 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 04FEB131261 for ; Thu, 26 Jul 2018 09:43:47 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id k81-v6so4106112oib.4 for ; Thu, 26 Jul 2018 09:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k2kExsA2c7HBH2SudWDqSRxVGTmOCiQfTDVqMeesAeA=; b=i1H5wFXKhaenlQp7UPo9PMMxMQfCDc9xuuw4rX7ZHNSv+TtlxSZksfkpQACK1I5RVE h/rT0qAbu+38biMDc8O4TWSlikxEo7bAxUOweXpP1HCicrOmryswpcIPwRvHWOHGcl66 0DKoVJo35ChTGV8BmAqtV4TZ03t2yNIQZ3sF3d6wXzl4ChBS962OJcsjWDAbSqHFWEwl k9lNe/9hyTG9mFDoyCRUQ7PUGzFFyQ0t0WgyZekv/4/vdERdgGLM3YYJXkPBz+wV5CwR SgQcV0u2VBFWoCkpg5WUT4YZJB42WLwZuyJ3zkMd8mSA1OVEDWU+9MpI+HE+L8TtEZmJ NoMQ== 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=k2kExsA2c7HBH2SudWDqSRxVGTmOCiQfTDVqMeesAeA=; b=iKUNo/ZoWmdRuKHy8q3XvkyjPjmPRLZteKT5rhKMhvoevyY8y49W5oVFRfQYhO02Ts ghNkEV5WWf1xMQ6LLjkbwnK2Sp9ZB+0K6qKhdg9n/8jKL890IJaFooMlxufGo99RYea7 WmgpE84yoRN/FUQqUSg8lrY8S+aswAeTUZ55le4ZjPHlVk1RygDHO1YkZqDsue/p6HfM MdSPVzdGIVeReMpXIsicuYqWKEaM7Z8Q5RIxonXV3K/XdzZvVXi8m1qQH6TYQEhWeUPN E4qprRVl14Vk7dJ34nJ2nbCbkliTOVZPGDBNT749KhGoxlZx5s7erQ1G9j+qzw+vfuyd BXNA== X-Gm-Message-State: AOUpUlENUNnVNcg3csGH+1FjjIKu4LrIFOBtREwN6kzJRubvrxQuzaGb YNsSjx67idXhupkA49cWOklA1sk0RhKBbMGsPaY= X-Google-Smtp-Source: AAOMgpdcBc1plTElgR6ehMIfZrQ7vnkAN6UftEg7zB6Q0nyuKSW8xpdrPt98XMz4+gYOeG/slsygQZQbqatgp3Qdt/g= X-Received: by 2002:aca:190d:: with SMTP id l13-v6mr2931864oii.216.1532623426031; Thu, 26 Jul 2018 09:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 09:43:15 -0700 (PDT) In-Reply-To: References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> From: Ted Hardie Date: Thu, 26 Jul 2018 09:43:15 -0700 Message-ID: To: Richard Barnes Cc: dennis.jackson@cs.ox.ac.uk, mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000e214f00571e9b284" Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 16:44:00 -0000 --000000000000e214f00571e9b284 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes wrote: > I actually expect this to be a not-uncommon case. Two use cases > immediately come to mind: > > 1. New devices in an application where identity keys are sync'ed among > devices > 2. Participants who have lost state and need to re-sync. > > On account of (1), I had been thinking that the mapping between members / > leaves in the tree and identity keys would not be one-to-one, but > many-to-one. Are folks thinking that there would be technical problems / > ambiguities in such a case? None are coming to my mind. > > I think there is an ambiguity, but it is fairly easy to resolve. There are cases where a participant attempting to add themselves with the same identity to an existing group is implicitly replacing their previous connection. Katriel called that out as: "Perhaps the simplest is to allow the device to double-join but require it to immediately delete the old copy of itself." There are others where this is a true add-a new device that should also receive communication. I think the fix here is to replace "require it to immediately delete" with "allow it to immediately delete"; that seems to support both use cases and make the decision about which is in use explicit and in the user's control. Ted > It does seem worth thinking about the re-sync case (2), i.e., the case > where a participant has most of his state. If he's forgotten everything > besides his identity private key (or including the identity private key),= I > don't think there's much you can do but treat him like a new participant. > If he remembers his position in the tree, it seems like you could do a > "re-sync" transaction that's like an add, but for that position in the tr= ee > -- it's the same logic as an add, except instead of the frontier, you sen= d > the copath for that position; for other nodes, it just looks like an Upda= te > at that position. > > (Aside: This reinforces that we really only have 1.2 operations here: > Update + handle-update-at-edge + encrypt-leaf-secret) > > It also seems like if we can solve the "re-sync a member with lost state" > problem, then we can probably also solve the "heal a network partition" > problem that Dennis raises. Assuming we can choose a winning partition a= nd > appoint someone to do the merge, the person doing the merge can just > re-initialize the losing members to their point in the tree, as if they h= ad > lost their state. > > --Richard > > > On Wed, Jul 25, 2018 at 7:59 AM Dennis Jackson > wrote: > >> me@katriel.co.uk wrote: >> >> > The simple answer is to forbid such joins, but this might happen if a >> > device forgets its group state but remembers its identity key. >> >> Depending on how MLS specifies update operations, this could also >> happen if there was a network partition and some group members see a >> different order of key updates. Even if we assume the existence of a >> delivery service which can provide a linear order for key update >> messages, the attacker will be allowed to compromise the server and >> violate this property. Consequently, some participants will have >> differing views of the group key and need to converge. >> >> In both cases we have a long term key, already in the group, with bad >> local state. I think we need a recovery mechanism for this other than >> just starting a new group or allowing a rejoin since that would allow >> an attacker with only knowledge of a long term key to join a previously >> secure group. >> >> We could mitigate this by proving knowledge of some recent state: a >> device which knew the group key five minutes ago is more trustworthy >> than one which doesn=E2=80=99t know any group state. It=E2=80=99s an app= lication-layer >> decision to actually figure out what to do in this case, but we could >> expose a way to prove state knowledge (e.g. by deriving a =E2=80=9Crecov= ery=E2=80=9D >> key after every update). >> >> Best, >> Dennis >> >> On Wed, 25 Jul 2018 11:05:09 +0000 >> Jon Millican wrote: >> >> > One potential option that comes to mind is for the server to help it >> > reinsert itself in the correct place. This would essentially amount >> > to a join, but serving its own copath instead of the group=E2=80=99s >> > frontier. We could then reject somebody double-joining their own >> > identity key; under the assumption that this could only happen with a >> > malicious server anyway. >> > >> > I don=E2=80=99t have strong feelings about this vs your proposed solut= ion >> > though. The main benefit would probably be just in terms of keeping >> > the tree cleaner and minimising remove operations that need to be >> > done. >> > >> > Jon >> > >> > On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon" >> > on behalf of >> > me@katriel.co.uk> wrote: >> > >> > Hi all, >> > >> > Here'a s case we might want to think about: what should happen if a >> > current member of a group asks to join, with the same long-term key >> > that they're already joined with? >> > >> > The simple answer is to forbid such joins, but this might happen if a >> > device forgets its group state but remembers its identity key. >> > (Perhaps it writes the group state to a local database and the write >> > got corrupted.) >> > >> > Alternatively I see a handful of different ways we could support >> > these joins, if we wanted to. Perhaps the simplest is to allow the >> > device to double-join but require it to immediately delete the old >> > copy of itself. >> > >> > best, >> > k >> > >> >> >> >> -- >> PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC >> _______________________________________________ >> 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 > > --000000000000e214f00571e9b284 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes <rlb@ipv.sx= > wrote:
I actually expect thi= s to be a not-uncommon case.=C2=A0 Two use cases immediately come to mind:<= /div>

1. New devices in an application where identity ke= ys are sync'ed among devices
2. Participants who have lost st= ate and need to re-sync.

On account of (1), I had = been thinking that the mapping between members / leaves in the tree and ide= ntity keys would not be one-to-one, but many-to-one.=C2=A0 Are folks thinki= ng that there would be technical problems / ambiguities in such a case?=C2= =A0 None are coming to my mind.


I think there is an ambiguity, but it is fairly easy to res= olve.=C2=A0 There are cases where a participant attempting to add themselve= s with the same identity to an existing group is implicitly replacing their= previous connection.=C2=A0 Katriel called that out as:=C2=A0 "Perhaps= =20 the simplest is to allow the device to double-join but require it to=20 immediately delete the old copy of itself."=C2=A0 There are others whe= re this is a true add-a new device that should also receive communication.= =C2=A0 I think the fix here is to replace "require it to immediately d= elete" with "allow it to immediately delete"; that seems to = support both use cases and make the decision about which is in use explicit= and in the user's control.

Ted


=C2=A0
It does = seem worth thinking about the re-sync case (2), i.e., the case where a part= icipant has most of his state.=C2=A0 If he's forgotten everything besid= es his identity private key (or including the identity private key), I don&= #39;t think there's much you can do but treat him like a new participan= t.=C2=A0 If he remembers his position in the tree, it seems like you could = do a "re-sync" transaction that's like an add, but for that p= osition in the tree -- it's the same logic as an add, except instead of= the frontier, you send the copath for that position; for other nodes, it j= ust looks like an Update at that position.

(Aside:= This reinforces that we really only have 1.2 operations here: Update=C2=A0= + handle-update-at-edge + encrypt-leaf-secret)

It also seems like if we can solve the "re-sync a member with lost st= ate" problem, then we can probably also solve the "heal a network= partition" problem that Dennis raises.=C2=A0 Assuming we can choose a= winning partition and appoint someone to do the merge, the person doing th= e merge can just re-initialize the losing members to their point in the tre= e, as if they had lost their state.

--Richard
<= /div>


On Wed, Jul 25, 2018 at 7:59 AM Dennis Jackson <dennis.jackso= n@cs.ox.ac.uk> wrote:
me@katriel.co.uk<mailto:me@katriel.co.uk> wrote:

> The simple answer is to forbid such joins, but this might happen if a<= br> > device forgets its group state but remembers its identity key.

Depending on how MLS specifies update operations, this could also
happen if there was a network partition and some group members see a
different order of key updates. Even if we assume the existence of a
delivery service which can provide a linear order for key update
messages, the attacker will be allowed to compromise the server and
violate this property. Consequently, some participants will have
differing views of the group key and need to converge.

In both cases we have a long term key, already in the group, with bad
local state. I think we need a recovery mechanism for this other than
just starting a new group or allowing a rejoin since that would allow
an attacker with only knowledge of a long term key to join a previously
secure group.

We could mitigate this by proving knowledge of some recent state: a
device which knew the group key five minutes ago is more trustworthy
than one which doesn=E2=80=99t know any group state. It=E2=80=99s an applic= ation-layer
decision to actually figure out what to do in this case, but we could
expose a way to prove state knowledge (e.g. by deriving a =E2=80=9Crecovery= =E2=80=9D
key after every update).

Best,
Dennis

On Wed, 25 Jul 2018 11:05:09 +0000
Jon Millican <jmil= lican@fb.com> wrote:

> One potential option that comes to mind is for the server to help it > reinsert itself in the correct place. This would essentially amount > to a join, but serving its own copath instead of the group=E2=80=99s > frontier. We could then reject somebody double-joining their own
> identity key; under the assumption that this could only happen with a<= br> > malicious server anyway.
>
> I don=E2=80=99t have strong feelings about this vs your proposed solut= ion
> though. The main benefit would probably be just in terms of keeping > the tree cleaner and minimising remove operations that need to be
> done.
>
> Jon
>
> On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon"=
> <mls-boun= ces@ietf.org<mailto:mls-bounces@ietf.org> on behalf of
> me@katriel.co.uk= <mailto:me@katriel.co.uk>> wrote:
>
> Hi all,
>
> Here'a s case we might want to think about: what should happen if = a
> current member of a group asks to join, with the same long-term key > that they're already joined with?
>
> The simple answer is to forbid such joins, but this might happen if a<= br> > device forgets its group state but remembers its identity key.
> (Perhaps it writes the group state to a local database and the write > got corrupted.)
>
> Alternatively I see a handful of different ways we could support
> these joins, if we wanted to. Perhaps the simplest is to allow the
> device to double-join but require it to immediately delete the old
> copy of itself.
>
> best,
> k
>



--
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC
_______________________________________________
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


--000000000000e214f00571e9b284-- From nobody Thu Jul 26 10:11:22 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 261E2131222; Thu, 26 Jul 2018 10:11:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153262508008.25848.14042840847471214429.idtracker@ietfa.amsl.com> Date: Thu, 26 Jul 2018 10:11:20 -0700 Archived-At: Subject: [MLS] The MLS WG has placed draft-barnes-mls-protocol in state "Call For Adoption By WG Issued" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 17:11:20 -0000 The MLS WG has placed draft-barnes-mls-protocol in state Call For Adoption By WG Issued (entered by Sean Turner) The document was previously in state Candidate for WG Adoption The document is available at https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ From nobody Thu Jul 26 10:11:46 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 D5003131222; Thu, 26 Jul 2018 10:11:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153262510486.25905.2317042282660961756.idtracker@ietfa.amsl.com> Date: Thu, 26 Jul 2018 10:11:44 -0700 Archived-At: Subject: [MLS] The MLS WG has placed draft-omara-mls-architecture in state "Call For Adoption By WG Issued" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 17:11:45 -0000 The MLS WG has placed draft-omara-mls-architecture in state Call For Adoption By WG Issued (entered by Sean Turner) The document was previously in state Candidate for WG Adoption The document is available at https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ From nobody Thu Jul 26 10:18:21 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB8C130EDC for ; Thu, 26 Jul 2018 10:18:20 -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 QbS5yqcOIAdO for ; Thu, 26 Jul 2018 10:18:18 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 2CB9B130EA2 for ; Thu, 26 Jul 2018 10:18:18 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id z74-v6so1493511qkb.10 for ; Thu, 26 Jul 2018 10:18:18 -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=yehUpUtYUBI6gDHciWe9gCENOXNJaZHTH1WefTln394=; b=C1IEpmuwRmI4SofIBFz9IRvfK7rVpG8VYw51z1gFprkvSmKt7c+Oh1XyLAqgvr0ssA fam2Gln8kUcjW5tx5/yUm/+uGOBDH53ms+teSIcets2HIkt8kz1EmY57jfd1Dl/IEfPH 2Y+gmjJYMf94hVz61a3GNCdM/ejCe8XNu2Sj4= 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=yehUpUtYUBI6gDHciWe9gCENOXNJaZHTH1WefTln394=; b=Orc58VwcAA0bRvdUgJVbt0byRAgYXsRPiKqISSvbz6IJHxck8fF+cGPRWOJJXUBgsv jinwTiiCudyFhTkaswDc3ywENf3ESF+dzDPAU42z0a+y+CXcj6kkZhO8rU9oy8NYqTGs EDl3UqxKX2AWwyuEoihvi6/bv1ae+H7unHhmPWLcR17gGOym+Y+kmhDlvq8b7jpIMfSk vXCil2mwgVSYnn1nzOD8+30IggER+yubVn8v0znLVsiE7h3tVkyzMibnY5lJt2Ui87Xa 0AmnZS+FVVLbzAG2p4O3JIU8cuV5xUuljj3gnENChIwAWjjyZ2IIf6phhbHcf27QkhWw qi+w== X-Gm-Message-State: AOUpUlFUz4yL7yHcFivarOdaipp/b1yywFMggva4hZcGEckao/EPCTCO +FBlgo/tqocLV2b5L0rYgWwRhPG8Hp8= X-Google-Smtp-Source: AAOMgpfULVBRyO1rAH0tB2dZwaXpyFnWooj8IeUaMVi5b7LjpmW4zZcWaDGY8sVQP4p2DBit8sf32Q== X-Received: by 2002:a37:30d5:: with SMTP id w204-v6mr2654066qkw.317.1532625497374; Thu, 26 Jul 2018 10:18:17 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id 140-v6sm953470qkm.18.2018.07.26.10.18.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 10:18:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 26 Jul 2018 13:18:15 -0400 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] wg-materials GH repo X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 17:18:21 -0000 Yes. spt > On Jul 23, 2018, at 10:14, Richard Barnes wrote: >=20 > Sean: Is the idea for the documents to go in repos under that org once = they're adopted?=20 >=20 > On Sun, Jul 22, 2018 at 7:48 PM Emad Omara = wrote: > Great! Thanks Katriel and Sean >=20 > On Sun, Jul 22, 2018 at 4:35 PM, Sean Turner wrote: > All, >=20 > Katriel was nice enough to make a wg-materials GH repo here: > https://github.com/mlswg/wg-materials >=20 > I have uploaded the ietf101 materials for posterity sake. >=20 > I have also uploaded the ietf102 materials minus the minutes; Matt = Miller sent them to Nick and I, but we need to review them first before = posting (should be done next week). >=20 > spt > _______________________________________________ > 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 From nobody Fri Jul 27 03:35:13 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9D2130F09 for ; Fri, 27 Jul 2018 03:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=PjD4nB12; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gv3Oapp2 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 YWatAQaaJTAh for ; Fri, 27 Jul 2018 03:35:06 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3010130F1F for ; Fri, 27 Jul 2018 03:35:05 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 482A021EC1 for ; Fri, 27 Jul 2018 06:35:05 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 27 Jul 2018 06:35:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=KKJUhi9xBSvKvr44G+0cG2bo9B AZxmWjQ0X6M8x/NzM=; b=PjD4nB12XkcWlL+uVxf5Wu6k2LW8s2aJETG2/5AVPB /867oEikE33Sl0Ull7SnGmu+mbVjgHCCLzCu/YX14n2AH+jjnEhVIttLIXo2Gg83 1fdj8j89ZxJOmKvYHzVOt74PSb58dpBOGhCK6katJcnvIDWfOAfPEnw14OXc+8mi I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=KKJUhi 9xBSvKvr44G+0cG2bo9BAZxmWjQ0X6M8x/NzM=; b=gv3Oapp2uPTAruYMWW6ji9 0sZEOwa1UA9yAyeSnYL4Z7M6oW4aNT0PMwVmI8EoMyMuRDwSTfMq+4maivHx4NQY BUsZO5a/ru6n7GM/x5HXSiEFDENxCRmDZ4xqfEn8K8XBNnn/w+VGOCGbBdD7WRAZ ZyQAWjQYjoF/BH946ffVBCplbmOHR/qioNPlR/Eo8bYvRQzGBCzrf1P2zo2fGVqp PS25BUPrU3tLNVSz5+aNFISeKW1tJ4lw1SQjxN8Znj9tYAILrwkYpFlee2TF/qqu Fc/0X48gSt7sgN/Ls5X35WUb3cz/0+52t7B5Jxgr1nMx/uOtOoLrV+ZxT2bVKObA == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C0A2EBA50C; Fri, 27 Jul 2018 06:35:04 -0400 (EDT) Message-Id: <1532687704.3670264.1454705888.2DC75109@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_153268770436702640" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0843ff3e Date: Fri, 27 Jul 2018 11:35:04 +0100 References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> In-Reply-To: Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 10:35:11 -0000 This is a multi-part message in MIME format. --_----------=_153268770436702640 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" One thing to be clear about: all of these "rejoin"-style operations break post-compromise security in some way, because they allow an actor who knows long-term keys but not the current state to become a full- fledged group member. That's not to say we shouldn't support them, of course (it's no good building a secure protocol that doesn't work), just that we should be careful about when they can happen. I think it's also important to make sure they're clearly differentiated from normal operations, so that applications can disallow them or show warnings. k On Thu, 26 Jul 2018, at 5:43 PM, Ted Hardie wrote: > On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes wrote: >> I actually expect this to be a not-uncommon case. Two use cases >> immediately come to mind:>>=20 >> 1. New devices in an application where identity keys are sync'ed >> among devices>> 2. Participants who have lost state and need to re-sy= nc. >>=20 >> On account of (1), I had been thinking that the mapping between >> members / leaves in the tree and identity keys would not be one-to- >> one, but many-to-one. Are folks thinking that there would be >> technical problems / ambiguities in such a case? None are coming to >> my mind.>>=20 >=20 > I think there is an ambiguity, but it is fairly easy to resolve. > There are cases where a participant attempting to add themselves with > the same identity to an existing group is implicitly replacing their > previous connection. Katriel called that out as: "Perhaps the > simplest is to allow the device to double-join but require it to > immediately delete the old copy of itself." There are others where > this is a true add-a new device that should also receive > communication. I think the fix here is to replace "require it to > immediately delete" with "allow it to immediately delete"; that seems > to support both use cases and make the decision about which is in use > explicit and in the user's control.>=20 > Ted >=20 >=20=20 >>=20 >> It does seem worth thinking about the re-sync case (2), i.e., the >> case where a participant has most of his state. If he's forgotten >> everything besides his identity private key (or including the >> identity private key), I don't think there's much you can do but >> treat him like a new participant. If he remembers his position in >> the tree, it seems like you could do a "re-sync" transaction that's >> like an add, but for that position in the tree -- it's the same logic >> as an add, except instead of the frontier, you send the copath for >> that position; for other nodes, it just looks like an Update at that >> position.>>=20 >> (Aside: This reinforces that we really only have 1.2 operations here: >> Update + handle-update-at-edge + encrypt-leaf-secret)>>=20 >> It also seems like if we can solve the "re-sync a member with lost >> state" problem, then we can probably also solve the "heal a network >> partition" problem that Dennis raises. Assuming we can choose a >> winning partition and appoint someone to do the merge, the person >> doing the merge can just re-initialize the losing members to their >> point in the tree, as if they had lost their state.>>=20 >> --Richard >>=20 >>=20 >> On Wed, Jul 25, 2018 at 7:59 AM Dennis Jackson >> wrote:>>> me@katriel.co.uk wrote: >>>=20 >>> > The simple answer is to forbid such joins, but this might happen >>> > if a>>> > device forgets its group state but remembers its identity= key. >>>=20 >>> Depending on how MLS specifies update operations, this could also >>> happen if there was a network partition and some group members >>> see a>>> different order of key updates. Even if we assume the >>> existence of a>>> delivery service which can provide a linear order f= or key update >>> messages, the attacker will be allowed to compromise the server and>>>= violate this property. Consequently, some participants will have >>> differing views of the group key and need to converge. >>>=20 >>> In both cases we have a long term key, already in the group, >>> with bad>>> local state. I think we need a recovery mechanism for this >>> other than>>> just starting a new group or allowing a rejoin since th= at would >>> allow>>> an attacker with only knowledge of a long term key to join a >>> previously>>> secure group.=20 >>>=20 >>> We could mitigate this by proving knowledge of some recent state: a>>>= device which knew the group key five minutes ago is more >>> trustworthy>>> than one which doesn=E2=80=99t know any group state. I= t=E2=80=99s an application- >>> layer>>> decision to actually figure out what to do in this case, but= we >>> could>>> expose a way to prove state knowledge (e.g. by deriving a >>> =E2=80=9Crecovery=E2=80=9D>>> key after every update). >>>=20 >>> Best, >>> Dennis >>>=20 >>> On Wed, 25 Jul 2018 11:05:09 +0000 >>> Jon Millican wrote: >>>=20 >>> > One potential option that comes to mind is for the server to >>> > help it>>> > reinsert itself in the correct place. This would essen= tially >>> > amount>>> > to a join, but serving its own copath instead of the gr= oup=E2=80=99s >>> > frontier. We could then reject somebody double-joining their own>>> = > identity key; under the assumption that this could only happen >>> > with a>>> > malicious server anyway. >>> >=20 >>> > I don=E2=80=99t have strong feelings about this vs your proposed sol= ution>>> > though. The main benefit would probably be just in terms of >>> > keeping>>> > the tree cleaner and minimising remove operations that= need to be>>> > done. >>> >=20 >>> > Jon >>> >=20 >>> > On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon" >>> > on behalf of >>> > me@katriel.co.uk> wrote: >>> >=20 >>> > Hi all, >>> >=20 >>> > Here'a s case we might want to think about: what should happen >>> > if a>>> > current member of a group asks to join, with the same lon= g-term >>> > key>>> > that they're already joined with? >>> >=20 >>> > The simple answer is to forbid such joins, but this might happen >>> > if a>>> > device forgets its group state but remembers its identity= key. >>> > (Perhaps it writes the group state to a local database and the >>> > write>>> > got corrupted.) >>> >=20 >>> > Alternatively I see a handful of different ways we could support>>> = > these joins, if we wanted to. Perhaps the simplest is to allow >>> > the>>> > device to double-join but require it to immediately delete= the >>> > old>>> > copy of itself. >>> >=20 >>> > best, >>> > k >>> >=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC>>> = _______________________________________________ >>> 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 > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --_----------=_153268770436702640 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
One thing to be clear abou= t: all of these "rejoin"-style operations break post-compromise security in= some way, because they allow an actor who knows long-term keys but not the= current state to become a full-fledged group member.

That's not to say we shouldn't s= upport them, of course (it's n= o good building a secure protocol that doesn't work), just that we sho= uld be careful about when they can happen. I think it's also important to m= ake sure they're clearly differentiated from normal operations, so that app= lications can disallow them or show warnings.

k

On Thu, 26 Jul 2018, at 5:43 PM, Ted Hardie wrote:
On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes <rlb@ipv.sx> wrote:
I actually expe= ct this to be a not-uncommon case.  Two use cases immediately come to = mind:

1. New devices in an application where identity keys are sync'ed among= devices
2. Participants who have lost state and need to re-sync.

On account of (1), I had been thinking that the mapping between member= s / leaves in the tree and identity keys would not be one-to-one, but many-= to-one.  Are folks thinking that there would be technical problems / a= mbiguities in such a case?  None are coming to my mind.


I think there is an ambiguity, but it is fairly easy to resolve. = There are cases where a participant attempting to add themselves with the = same identity to an existing group is implicitly replacing their previous c= onnection.  Katriel called that out as:  "Perhaps=20 the simplest is to allow the device to double-join but require it to=20 immediately delete the old copy of itself."  There are others where th= is is a true add-a new device that should also receive communication. = I think the fix here is to replace "require it to immediately delete" with= "allow it to immediately delete"; that seems to support both use cases and= make the decision about which is in use explicit and in the user's control= .

Ted

 

It does seem worth thinking about the re-sync case (2), i.e., the case= where a participant has most of his state.  If he's forgotten everyth= ing besides his identity private key (or including the identity private key= ), I don't think there's much you can do but treat him like a new participa= nt.  If he remembers his position in the tree, it seems like you could= do a "re-sync" transaction that's like an add, but for that position in th= e tree -- it's the same logic as an add, except instead of the frontier, yo= u send the copath for that position; for other nodes, it just looks like an= Update at that position.

(Aside: This reinforces that we really only have 1.2 operations here: = Update + handle-update-at-edge + encrypt-leaf-secret)

It also seems like if we can solve the "re-sync a member with lost sta= te" problem, then we can probably also solve the "heal a network partition"= problem that Dennis raises.  Assuming we can choose a winning partiti= on and appoint someone to do the merge, the person doing the merge can just= re-initialize the losing members to their point in the tree, as if they ha= d lost their state.

--Richard


On Wed, Jul = 25, 2018 at 7:59 AM Dennis Jackson <dennis.jackson@cs.ox.ac.uk> wrote:

> The simple answer is to fo= rbid such joins, but this might happen if a
> device forgets its group s= tate but remembers its identity key.

Depending on how MLS specifies = update operations, this could also
happen if there was a network p= artition and some group members see a
different order of key updates.= Even if we assume the existence of a
delivery service which can prov= ide a linear order for key update
messages, the attacker will be = allowed to compromise the server and
violate this property. Conseque= ntly, some participants will have
differing views of the group ke= y and need to converge.

In both cases we have a long te= rm key, already in the group, with bad
local state. I think we need a = recovery mechanism for this other than
just starting a new group or al= lowing a rejoin since that would allow
an attacker with only knowledge= of a long term key to join a previously
secure group.

We could mitigate this by provi= ng knowledge of some recent state: a
device which knew the group key= five minutes ago is more trustworthy
than one which doesn=E2=80=99t = know any group state. It=E2=80=99s an application-layer
decision to actually figure out= what to do in this case, but we could
expose a way to prove state kno= wledge (e.g. by deriving a =E2=80=9Crecovery=E2=80=9D
key after every update).

Best,
Dennis

On Wed, 25 Jul 2018 11:05:09 +0= 000
Jon Millican <jmillican@fb.com> wrote:

> One potential option that = comes to mind is for the server to help it
> reinsert itself in the cor= rect place. This would essentially amount
> to a join, but serving its= own copath instead of the group=E2=80=99s
> frontier. We could then re= ject somebody double-joining their own
> identity key; under the as= sumption that this could only happen with a
> malicious server anyway.
>
> I don=E2=80=99t have stron= g feelings about this vs your proposed solution
> though. The main benefit w= ould probably be just in terms of keeping
> the tree cleaner and minim= ising remove operations that need to be
> done.
>
> Jon
>
> On 25/07/2018, 12:01, "MLS= on behalf of Katriel Cohn-Gordon"
>
> Hi all,
>
> Here'a s case we might wan= t to think about: what should happen if a
> current member of a group = asks to join, with the same long-term key
> that they're already joine= d with?
>
> The simple answer is to fo= rbid such joins, but this might happen if a
> device forgets its group s= tate but remembers its identity key.
> (Perhaps it writes the gro= up state to a local database and the write
> got corrupted.)
>
> Alternatively I see a hand= ful of different ways we could support
> these joins, if we wanted = to. Perhaps the simplest is to allow the
> device to double-join but = require it to immediately delete the old
> copy of itself.
>
> best,
> k
>



--
PGP Fingerprint: 5B93 F0B9 D6A8= 9BC1 546B C98C 6105 A775 8CD2 46AC
_______________________________________________
MLS mailing list

_______________________________________________
MLS mailing list

_______________________________________________
MLS mailing list

--_----------=_153268770436702640-- From nobody Fri Jul 27 08:24: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 07B0E130F75 for ; Fri, 27 Jul 2018 08:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6fnld1c2dxV for ; Fri, 27 Jul 2018 08:24:13 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 837BF130EBD for ; Fri, 27 Jul 2018 08:24:13 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id k81-v6so9702971oib.4 for ; Fri, 27 Jul 2018 08:24:13 -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=AzNfjX4wVG5Mttl3e/sguIac6srkSfFyCa5XtwrEJvc=; b=QgOqcggds58bwyYnciK4riyFecrWJo/OWsAQT0SwMUaoQ+Qt137LisTB+lgDDzNwVy Zzr6Gnrxu15vhaX1iCJ7psnNfCfdRwexblY+IjrczgbUBoO11u6IgiIaboEZjsHoSaqt AfDMrDf0DdFA5cylGeGcve8J9aaRqSvyRXvVAEfcNuouF+sJJ+VXADAMcyYFwBQvwAxU o3/sPJqGjeuxe+KJf/MqqoVIdYJ0GKkoM4T2eJ11FTaao/bk9e3FEqyFgZytLqxDRPMl XHTYbrjfwMqByuvW6rDm7M1EcPZOAunG4CmiItpPUt4chMzD5VzVwdFJzsHMwN7mQSYq w/ig== 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=AzNfjX4wVG5Mttl3e/sguIac6srkSfFyCa5XtwrEJvc=; b=oMjOyxzLEzVxSzD/OtSukCZPihtXbX6iopP8bhINF0nRYTcRP5a7cPb+D/jOuwEEou ZxTp3nZySbPqdgtUm3Gy3XiXzvtLfKpicgUkftCxEhkoMl8QLCM2WxlbalLp3rgqINlh L0Zuhlcf0bVc0zbuRp4VaRGd9Q9AxZ5E1qwNE40wxhfswKRavATUvuekY0MI1POfUpAo l56p7tE1jgR0+4MIM/29g29P635OhxwKY0VQpQGTKWOwcdrlkbMtSYniWiVgBuZvAqf1 JkhDe1GEzaXRM69k2iAKiQ7UeU71D3mCniRfnnnSYsXRtnVyQOTsBOiw+OStsoEDbcy/ gQkA== X-Gm-Message-State: AOUpUlEpNMwxW1uV8aWhWuD/bQ6BEDP27etABs7N2/W96qMtlHER4y+N MUAm1UYsJOXENj+tUu5L4LdIDYUg9vtqySwh2ErQgjwh X-Google-Smtp-Source: AAOMgpeHddDUNVkxhZm4I2iwSlBU1O7ZztPg3gKR6qDFj0UR6WidHsFls6DN3NKhbCIsp79q/dGRH2h5PGEUDGKr07c= X-Received: by 2002:aca:fc94:: with SMTP id a142-v6mr6530345oii.29.1532705052659; Fri, 27 Jul 2018 08:24:12 -0700 (PDT) MIME-Version: 1.0 References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> <1532687704.3670264.1454705888.2DC75109@webmail.messagingengine.com> In-Reply-To: <1532687704.3670264.1454705888.2DC75109@webmail.messagingengine.com> From: Richard Barnes Date: Fri, 27 Jul 2018 11:23:59 -0400 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000035a6360571fcb432" Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:24:18 -0000 --00000000000035a6360571fcb432 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to confirm, the PCS risk you're thinking of is something like: - Attacker finds an identity key lying on a street corner - Attacker shows up at the group and say "hey guys, i lost all my other state, can you let me back in"? IIRC, we touched on this in the IETF meeting discussions, this idea that we might adopt a different PCS posture w.r.t. long-term identity keys than confidentiality keys. There's an underlying tension here between the desire for persistent identities and the ephemerality / rotation that PCS requires. Even assuming maximal rotation of all the key material, if you have a policy that says "$IDENTITY is a member of this group" and someone shows up with a valid credential for $IDENTITY, are you going to let them in? Given that, I'm kind of tempted to argue that PCS isn't even a meaningful concept with regard to identity keys. At least not in the same way as for confidentiality keys. Or at least that it needs to be framed in quite a different way. --Richard On Fri, Jul 27, 2018 at 6:35 AM Katriel Cohn-Gordon wrote: > One thing to be clear about: all of these "rejoin"-style operations break > post-compromise security in some way, because they allow an actor who kno= ws > long-term keys but not the current state to become a full-fledged group > member. > > That's not to say we shouldn't support them, of course (it's no good > building a secure protocol that doesn't work), just that we should be > careful about when they can happen. I think it's also important to make > sure they're clearly differentiated from normal operations, so that > applications can disallow them or show warnings. > > k > > On Thu, 26 Jul 2018, at 5:43 PM, Ted Hardie wrote: > > On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes wrote: > > I actually expect this to be a not-uncommon case. Two use cases > immediately come to mind: > > 1. New devices in an application where identity keys are sync'ed among > devices > 2. Participants who have lost state and need to re-sync. > > On account of (1), I had been thinking that the mapping between members / > leaves in the tree and identity keys would not be one-to-one, but > many-to-one. Are folks thinking that there would be technical problems / > ambiguities in such a case? None are coming to my mind. > > > I think there is an ambiguity, but it is fairly easy to resolve. There > are cases where a participant attempting to add themselves with the same > identity to an existing group is implicitly replacing their previous > connection. Katriel called that out as: "Perhaps the simplest is to all= ow > the device to double-join but require it to immediately delete the old co= py > of itself." There are others where this is a true add-a new device that > should also receive communication. I think the fix here is to replace > "require it to immediately delete" with "allow it to immediately delete"; > that seems to support both use cases and make the decision about which is > in use explicit and in the user's control.. > > Ted > > > > > It does seem worth thinking about the re-sync case (2), i.e., the case > where a participant has most of his state. If he's forgotten everything > besides his identity private key (or including the identity private key),= I > don't think there's much you can do but treat him like a new participant. > If he remembers his position in the tree, it seems like you could do a > "re-sync" transaction that's like an add, but for that position in the tr= ee > -- it's the same logic as an add, except instead of the frontier, you sen= d > the copath for that position; for other nodes, it just looks like an Upda= te > at that position. > > (Aside: This reinforces that we really only have 1.2 operations here: > Update + handle-update-at-edge + encrypt-leaf-secret) > > It also seems like if we can solve the "re-sync a member with lost state" > problem, then we can probably also solve the "heal a network partition" > problem that Dennis raises. Assuming we can choose a winning partition a= nd > appoint someone to do the merge, the person doing the merge can just > re-initialize the losing members to their point in the tree, as if they h= ad > lost their state. > > --Richard > > > On Wed, Jul 25, 2018 at 7:59 AM Dennis Jackson > wrote: > > me@katriel.co.uk wrote: > > > The simple answer is to forbid such joins, but this might happen if a > > device forgets its group state but remembers its identity key. > > Depending on how MLS specifies update operations, this could also > happen if there was a network partition and some group members see a > different order of key updates. Even if we assume the existence of a > delivery service which can provide a linear order for key update > messages, the attacker will be allowed to compromise the server and > violate this property. Consequently, some participants will have > differing views of the group key and need to converge. > > In both cases we have a long term key, already in the group, with bad > local state. I think we need a recovery mechanism for this other than > just starting a new group or allowing a rejoin since that would allow > an attacker with only knowledge of a long term key to join a previously > secure group. > > We could mitigate this by proving knowledge of some recent state: a > device which knew the group key five minutes ago is more trustworthy > than one which doesn=E2=80=99t know any group state. It=E2=80=99s an appl= ication-layer > decision to actually figure out what to do in this case, but we could > expose a way to prove state knowledge (e.g. by deriving a =E2=80=9Crecove= ry=E2=80=9D > key after every update). > > Best, > Dennis > > On Wed, 25 Jul 2018 11:05:09 +0000 > Jon Millican wrote: > > > One potential option that comes to mind is for the server to help it > > reinsert itself in the correct place. This would essentially amount > > to a join, but serving its own copath instead of the group=E2=80=99s > > frontier. We could then reject somebody double-joining their own > > identity key; under the assumption that this could only happen with a > > malicious server anyway. > > > > I don=E2=80=99t have strong feelings about this vs your proposed soluti= on > > though. The main benefit would probably be just in terms of keeping > > the tree cleaner and minimising remove operations that need to be > > done. > > > > Jon > > > > On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon" > > on behalf of > > me@katriel.co.uk> wrote: > > > > Hi all, > > > > Here'a s case we might want to think about: what should happen if a > > current member of a group asks to join, with the same long-term key > > that they're already joined with? > > > > The simple answer is to forbid such joins, but this might happen if a > > device forgets its group state but remembers its identity key. > > (Perhaps it writes the group state to a local database and the write > > got corrupted.) > > > > Alternatively I see a handful of different ways we could support > > these joins, if we wanted to. Perhaps the simplest is to allow the > > device to double-join but require it to immediately delete the old > > copy of itself. > > > > best, > > k > > > > > > -- > PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC > _______________________________________________ > 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 > --00000000000035a6360571fcb432 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to confirm, the PCS risk you're thinking of = is something like:
- Attacker finds an identity key lying on= a street corner
- Attacker shows up at the group and say "h= ey guys, i lost all my other state, can you let me back in"?

IIRC, we touched on this in the IETF meeting discussions, t= his idea that we might adopt a different PCS posture w.r.t. long-term ident= ity keys than confidentiality keys.

There's an= underlying tension here between the desire for persistent identities and t= he ephemerality / rotation that PCS requires.=C2=A0 Even assuming maximal r= otation of all the key material, if you have a policy that says "$IDEN= TITY is a member of this group" and someone shows up with a valid cred= ential for $IDENTITY, are you going to let them in?

Given that, I'm kind of tempted to argue that PCS isn't even = a meaningful concept with regard to identity keys.=C2=A0 At least not in th= e same way as for confidentiality keys.=C2=A0 Or at least that it needs to = be framed in quite a different way.

--Richard
<= /div>


On= Fri, Jul 27, 2018 at 6:35 AM Katriel Cohn-Gordon <me@katriel.co.uk> wrote:
One thing to be clear about: = all of these "rejoin"-style operations break post-compromise secu= rity in some way, because they allow an actor who knows long-term keys but = not the current state to become a full-fledged group member.

That's not to say we shouldn&#= 39;t support them, of course=C2=A0(it= 's no good building a secure protocol that doesn't work),=C2=A0just= that we should be careful about when they can happen. I think it's als= o important to make sure they're clearly differentiated from normal ope= rations, so that applications can disallow them or show warnings.

k

On Thu, 26 Jul 2018, at 5:43 PM, Ted Hardie wrote:
On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes = <rlb@ipv.sx> wrote:
I act= ually expect this to be a not-uncommon case.=C2=A0 Two use cases immediatel= y come to mind:

1. New devices in an application where identity keys are sync'ed a= mong devices
2. Participants who have lost state and need to re-sync.

On account of (1), I had been thinking that the mapping between member= s / leaves in the tree and identity keys would not be one-to-one, but many-= to-one.=C2=A0 Are folks thinking that there would be technical problems / a= mbiguities in such a case?=C2=A0 None are coming to my mind.


I think there is an ambiguity, but it is fairly easy to resolve.=C2=A0= There are cases where a participant attempting to add themselves with the = same identity to an existing group is implicitly replacing their previous c= onnection.=C2=A0 Katriel called that out as:=C2=A0 "Perhaps=20 the simplest is to allow the device to double-join but require it to=20 immediately delete the old copy of itself."=C2=A0 There are others whe= re this is a true add-a new device that should also receive communication.= =C2=A0 I think the fix here is to replace "require it to immediately d= elete" with "allow it to immediately delete"; that seems to = support both use cases and make the decision about which is in use explicit= and in the user's control..

Ted

=C2=A0

It does seem worth thinking about the re-sync case (2), i.e., the case= where a participant has most of his state.=C2=A0 If he's forgotten eve= rything besides his identity private key (or including the identity private= key), I don't think there's much you can do but treat him like a n= ew participant.=C2=A0 If he remembers his position in the tree, it seems li= ke you could do a "re-sync" transaction that's like an add, b= ut for that position in the tree -- it's the same logic as an add, exce= pt instead of the frontier, you send the copath for that position; for othe= r nodes, it just looks like an Update at that position.

(Aside: This reinforces that we really only have 1.2 operations here: = Update=C2=A0+ handle-update-at-edge + encrypt-leaf-secret)

It also seems like if we can solve the "re-sync a member with los= t state" problem, then we can probably also solve the "heal a net= work partition" problem that Dennis raises.=C2=A0 Assuming we can choo= se a winning partition and appoint someone to do the merge, the person doin= g the merge can just re-initialize the losing members to their point in the= tree, as if they had lost their state.

--Richard


On Wed, Jul 25, 2018 at 7:59 AM Dennis Jack= son <den= nis.jackson@cs.ox.ac.uk> wrote:

> The simple answer is to forb= id such joins, but this might happen if a
> device forgets its group sta= te but remembers its identity key.

Depending on how MLS specifies up= date operations, this could also
happen if there was a network par= tition and some group members see a
different order of key updates. E= ven if we assume the existence of a
delivery service which can provid= e a linear order for key update
messages, the attacker will be al= lowed to compromise the server and
violate this property. Consequent= ly, some participants will have
differing views of the group key = and need to converge.

In both cases we have a long term= key, already in the group, with bad
local state. I think we need a re= covery mechanism for this other than
just starting a new group or allo= wing a rejoin since that would allow
an attacker with only knowledge o= f a long term key to join a previously
secure group.

We could mitigate this by proving= knowledge of some recent state: a
device which knew the group key f= ive minutes ago is more trustworthy
than one which doesn=E2=80=99t kn= ow any group state. It=E2=80=99s an application-layer
decision to actually figure out w= hat to do in this case, but we could
expose a way to prove state knowl= edge (e.g. by deriving a =E2=80=9Crecovery=E2=80=9D
key after every update).

Best,
Dennis

On Wed, 25 Jul 2018 11:05:09 +000= 0
Jon Millican <jmillican@fb.com> wrote:

> One potential option that co= mes to mind is for the server to help it
> reinsert itself in the corre= ct place. This would essentially amount
> to a join, but serving its o= wn copath instead of the group=E2=80=99s
> frontier. We could then reje= ct somebody double-joining their own
> identity key; under the assu= mption that this could only happen with a
> malicious server anyway.
=
>
> I don=E2=80=99t have strong = feelings about this vs your proposed solution
> though. The main benefit wou= ld probably be just in terms of keeping
> the tree cleaner and minimis= ing remove operations that need to be
> done.
>
> Jon
>
> On 25/07/2018, 12:01, "= MLS on behalf of Katriel Cohn-Gordon"
>
> Hi all,
>
> Here'a s case we might w= ant to think about: what should happen if a
> current member of a group as= ks to join, with the same long-term key
> that they're already joi= ned with?
>
> The simple answer is to forb= id such joins, but this might happen if a
> device forgets its group sta= te but remembers its identity key.
> (Perhaps it writes the group= state to a local database and the write
> got corrupted.)
>
> Alternatively I see a handfu= l of different ways we could support
> these joins, if we wanted to= . Perhaps the simplest is to allow the
> device to double-join but re= quire it to immediately delete the old
> copy of itself.
>
> best,
> k
>



--
PGP Fingerprint: 5B93 F0B9 D6A8 9= BC1 546B C98C 6105 A775 8CD2 46AC
__________________________________= _____________
MLS mailing list

__________________________________= _____________
MLS mailing list

_______________________________________________
MLS mailing list

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000035a6360571fcb432-- From nobody Fri Jul 27 08:47:53 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F607130F8D for ; Fri, 27 Jul 2018 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7fnDIcaBNTwH for ; Fri, 27 Jul 2018 08:47:46 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) (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 381BD130EFF for ; Fri, 27 Jul 2018 08:47:46 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay11.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fj4xz-0001Q2-c5 for mls@ietf.org; Fri, 27 Jul 2018 16:47:44 +0100 Received: from client-8-79.eduroam.oxuni.org.uk ([192.76.8.79] helo=T-200) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1fj4xz-000AnP-LN for mls@ietf.org; Fri, 27 Jul 2018 16:47:43 +0100 Date: Fri, 27 Jul 2018 16:47:38 +0100 From: Dennis Jackson To: mls@ietf.org Message-ID: <20180727164738.5603ab05@T-200> In-Reply-To: References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> <1532687704.3670264.1454705888.2DC75109@webmail.messagingengine.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/s9xDK6S8GaDPZY5oO3cChZZ"; protocol="application/pgp-signature" X-Oxford-Username: exet4027 X-Oxmail-Spam-Status: score=0.0 tests=none X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:47:51 -0000 --Sig_/s9xDK6S8GaDPZY5oO3cChZZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Richard Barnes wrote: > if you have a policy that says "$IDENTITY is a member of this > group" and someone shows up with a valid credential for $IDENTITY, > are you going to let them in? But the point here is that they have lost a valid credential for the group (the group key). Maybe we are going to readmit them, but we should certainly warn the user in same way Signal and WhatsApp currently do ("Participants safety code has changed").=20 I think we can do better than this though, as I alluded to in my earlier message. Losing all of your local state except your identity key is actually a pretty rare case. If a user gets a new device then they should/must generate a new key. If a user has a bad key update, they will still know information about previous group states.=20 By providing a way to prove knowledge of recent group state, without revealing or storing old group keys, we can differentiate between the attacker attempting to join with just the identity key, or a user rejoining after a brief hiccup.=20 All the best, Dennis=20 On Fri, 27 Jul 2018 11:23:59 -0400 Richard Barnes wrote: > Just to confirm, the PCS risk you're thinking of is something like: > - Attacker finds an identity key lying on a street corner > - Attacker shows up at the group and say "hey guys, i lost all my > other state, can you let me back in"? >=20 > IIRC, we touched on this in the IETF meeting discussions, this idea > that we might adopt a different PCS posture w.r.t. long-term identity > keys than confidentiality keys. >=20 > There's an underlying tension here between the desire for persistent > identities and the ephemerality / rotation that PCS requires. Even > assuming maximal rotation of all the key material, if you have a > policy that says "$IDENTITY is a member of this group" and someone > shows up with a valid credential for $IDENTITY, are you going to let > them in? >=20 > Given that, I'm kind of tempted to argue that PCS isn't even a > meaningful concept with regard to identity keys. At least not in the > same way as for confidentiality keys. Or at least that it needs to > be framed in quite a different way. >=20 > --Richard >=20 >=20 > On Fri, Jul 27, 2018 at 6:35 AM Katriel Cohn-Gordon > wrote: >=20 > > One thing to be clear about: all of these "rejoin"-style operations > > break post-compromise security in some way, because they allow an > > actor who knows long-term keys but not the current state to become > > a full-fledged group member. > > > > That's not to say we shouldn't support them, of course (it's no good > > building a secure protocol that doesn't work), just that we should > > be careful about when they can happen. I think it's also important > > to make sure they're clearly differentiated from normal operations, > > so that applications can disallow them or show warnings. > > > > k > > > > On Thu, 26 Jul 2018, at 5:43 PM, Ted Hardie wrote: > > > > On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes wrote: > > > > I actually expect this to be a not-uncommon case. Two use cases > > immediately come to mind: > > > > 1. New devices in an application where identity keys are sync'ed > > among devices > > 2. Participants who have lost state and need to re-sync. > > > > On account of (1), I had been thinking that the mapping between > > members / leaves in the tree and identity keys would not be > > one-to-one, but many-to-one. Are folks thinking that there would > > be technical problems / ambiguities in such a case? None are > > coming to my mind. > > > > > > I think there is an ambiguity, but it is fairly easy to resolve. > > There are cases where a participant attempting to add themselves > > with the same identity to an existing group is implicitly replacing > > their previous connection. Katriel called that out as: "Perhaps > > the simplest is to allow the device to double-join but require it > > to immediately delete the old copy of itself." There are others > > where this is a true add-a new device that should also receive > > communication. I think the fix here is to replace "require it to > > immediately delete" with "allow it to immediately delete"; that > > seems to support both use cases and make the decision about which > > is in use explicit and in the user's control.. > > > > Ted > > > > > > > > > > It does seem worth thinking about the re-sync case (2), i.e., the > > case where a participant has most of his state. If he's forgotten > > everything besides his identity private key (or including the > > identity private key), I don't think there's much you can do but > > treat him like a new participant. If he remembers his position in > > the tree, it seems like you could do a "re-sync" transaction that's > > like an add, but for that position in the tree -- it's the same > > logic as an add, except instead of the frontier, you send the > > copath for that position; for other nodes, it just looks like an > > Update at that position. > > > > (Aside: This reinforces that we really only have 1.2 operations > > here: Update + handle-update-at-edge + encrypt-leaf-secret) > > > > It also seems like if we can solve the "re-sync a member with lost > > state" problem, then we can probably also solve the "heal a network > > partition" problem that Dennis raises. Assuming we can choose a > > winning partition and appoint someone to do the merge, the person > > doing the merge can just re-initialize the losing members to their > > point in the tree, as if they had lost their state. > > > > --Richard > > > > > > On Wed, Jul 25, 2018 at 7:59 AM Dennis Jackson > > wrote: > > > > me@katriel.co.uk wrote: > > > > > The simple answer is to forbid such joins, but this might happen > > > if a device forgets its group state but remembers its identity > > > key. > > > > Depending on how MLS specifies update operations, this could also > > happen if there was a network partition and some group members see a > > different order of key updates. Even if we assume the existence of a > > delivery service which can provide a linear order for key update > > messages, the attacker will be allowed to compromise the server and > > violate this property. Consequently, some participants will have > > differing views of the group key and need to converge. > > > > In both cases we have a long term key, already in the group, with > > bad local state. I think we need a recovery mechanism for this > > other than just starting a new group or allowing a rejoin since > > that would allow an attacker with only knowledge of a long term key > > to join a previously secure group. > > > > We could mitigate this by proving knowledge of some recent state: a > > device which knew the group key five minutes ago is more trustworthy > > than one which doesn=E2=80=99t know any group state. It=E2=80=99s an > > application-layer decision to actually figure out what to do in > > this case, but we could expose a way to prove state knowledge (e.g. > > by deriving a =E2=80=9Crecovery=E2=80=9D key after every update). > > > > Best, > > Dennis > > > > On Wed, 25 Jul 2018 11:05:09 +0000 > > Jon Millican wrote: > > > > > One potential option that comes to mind is for the server to help > > > it reinsert itself in the correct place. This would essentially > > > amount to a join, but serving its own copath instead of the > > > group=E2=80=99s frontier. We could then reject somebody double-joining > > > their own identity key; under the assumption that this could only > > > happen with a malicious server anyway. > > > > > > I don=E2=80=99t have strong feelings about this vs your proposed solu= tion > > > though. The main benefit would probably be just in terms of > > > keeping the tree cleaner and minimising remove operations that > > > need to be done. > > > > > > Jon > > > > > > On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon" > > > on behalf of > > > me@katriel.co.uk> wrote: > > > > > > Hi all, > > > > > > Here'a s case we might want to think about: what should happen if > > > a current member of a group asks to join, with the same long-term > > > key that they're already joined with? > > > > > > The simple answer is to forbid such joins, but this might happen > > > if a device forgets its group state but remembers its identity > > > key. (Perhaps it writes the group state to a local database and > > > the write got corrupted.) > > > > > > Alternatively I see a handful of different ways we could support > > > these joins, if we wanted to. Perhaps the simplest is to allow the > > > device to double-join but require it to immediately delete the old > > > copy of itself. > > > > > > best, > > > k > > > > > > > > > > > -- > > PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC > > _______________________________________________ > > 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 > > --=20 PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC --Sig_/s9xDK6S8GaDPZY5oO3cChZZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBCAAGBQJbWz6bAAoJEGEFp3WM0kaswQMP+JANdgBZYR8IEG+aTpFFYgcu zekLVGfe4i7g4eC5XpHvJgE1MOtJegyozJrboWOXsD1vJPiK1U9xab7SNzBrUj63 xlscUdUoMp2sihcRON/Cwez+hz4xkuBZhY9RcNf7ohff4yOy8vqC7Ix85IvSFhD0 Wa0b2S4JhgDi9aJZEQbvIO1S+r1H4v/xHNe3bTMEvlgwRbhsdCp3Iaq6awwPuQRt loj9mwgugLKBdCTlhP/02nX2PSc63scLeN2b59rfmY7Xmlh9X88uBhcK83muHnkV ddZDQZA5bhI6x6Z/SNh8/3WXHiuZ0p29gDv4TT98T7BOlKv2o9kBiyWSdGfU2USZ Vw/ikQWKfxcCElvc17KwoCl0gG2uAJ8+hNlDAxZPBZz8H4LED2Xi6vTmAG6obwXW cUFtWJRLUshJhpg/iFyWe7MEFiNJ+/JRtDpg1CEKhOumm4NImxfuPoLQmNtSOHt2 TJUeDP8dCcUzvBVaNVSqGf5ccslpYYWhhfp/inWCZELf4o9wQcDK3bWwVrzj62xn LdmMugym591Gfo3E37NjHl8Y89KzGGA8A7KEjpc0NT5+tO+gy99NvM4anlZIkL0T TpC0pxXjX+sJDkakjUmuuvNWl2zavSiFK2o8eXzh0yE2844FeMVsISsJSTTRntdZ 7k3gQ/n6ljJ+DKhIfYo= =/DNL -----END PGP SIGNATURE----- --Sig_/s9xDK6S8GaDPZY5oO3cChZZ--