From nobody Tue Nov 5 10:56:58 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27D812099F for ; Tue, 5 Nov 2019 10:56:56 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 lYnldRz0hggC for ; Tue, 5 Nov 2019 10:56:52 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3783B120986 for ; Tue, 5 Nov 2019 10:56:39 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id y10so23965701qto.3 for ; Tue, 05 Nov 2019 10:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ep5MGiFPDYHTSc3hIQcQHrGh+Ay7G+T+AzeABdlKToU=; b=JLmHM+ll9iIQyD0TCKmp8G69MsZQizLOdqCretZKp2mOqrC3UgEJzAwT6txcEeEPuY EXydej5D7nceV9qKgHMrwVLcH0xYAvccbdHhCUdJcBB5Hqar9juK3UKqHrJpMYzEeI36 l1dujFVDb7NSfYRcDnDo7KGlFZReVVzteet8w= 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=ep5MGiFPDYHTSc3hIQcQHrGh+Ay7G+T+AzeABdlKToU=; b=qzewVpIWZ/KemMoRsFI80/hFTOJY7rzmclzGDtlGqm2bJUN5wjZHeMove/bJukcCdZ Om1ZF3qjME3QDghLJMIpu1kyxoaiVwN8P/g3QXROgMJG1Asjfpu+qMl3Z/uCIgUw1ypy EykHOl4DPZmwAvKmqtl1xqMjnZXD1BbB/88P3GDvl9/TV0LfvlVoM9ZNOlas8XGxLN0Q Hr6W8PSiXIDJL6fCjIodJjTxAnPhxexUWXzkl3rV8og+IO635lU8VbmTGARnsWI7pwS8 LZMyigPSQUBC4Jp0J6KOpm6EyAVehwnanKKF09eC2v3fIFfNLvT+EQ2Ie513QJAlTx8L FQPg== X-Gm-Message-State: APjAAAVcinRmGl8dqJl/pf6oWb1NlAXcciNGCJu6eQedB9Rtkq7svk3j K0xkPkJSDnLSzlwnE/lkODbVG6A2jpo= X-Google-Smtp-Source: APXvYqwUwpW55FXkVbWq6uDmQB0YUrCgArk83I6E7tmHg9o6LwfdycgxXve7jEOVnZYqumuH7Jburw== X-Received: by 2002:a0c:fa50:: with SMTP id k16mr5680139qvo.172.1572980198072; Tue, 05 Nov 2019 10:56:38 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id z66sm4995381qka.132.2019.11.05.10.56.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 10:56:37 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 5 Nov 2019 13:56:37 -0500 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] MLS@IETF106: Agenda Topics X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 18:56:57 -0000 The MLS WG will be meeting @ IETF 106 in Singapore on Friday November = 22, 2019 from 1000-1200 (GMT+08). To help the chairs get a better = handle on how much time we will need for our session, please send in = your agenda requests to mls-chairs@ietf.org. Along with your request = please provide an estimate for how much time you will need. Cheers, Nick and Sean= From nobody Fri Nov 15 18:42:56 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84090120091 for ; Fri, 15 Nov 2019 18:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZYuAKSvczG8 for ; Fri, 15 Nov 2019 18:42:52 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 BA26C120058 for ; Fri, 15 Nov 2019 18:42:52 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id m6so7639694vsn.13 for ; Fri, 15 Nov 2019 18:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=sGwDMjmQVk9L44R68gk924k7KTTdz2uOZKj4CSMTYb4=; b=geSUzyWGP6OGkkQ6B5yPRHziC+pdG8hweWpgL7lWbGh+Fz54r9KtivInlj1OWG7xOw 6bOkxsMU3xLA0la2Nr9E0xTHFZm/vznZmkZm8Y+y0iwgyIR212D+CxTdF6mJPVrT1/0j +uOLVXAvadUS+XyLflqwwGXcuQRV37Hrn8tHc= 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=sGwDMjmQVk9L44R68gk924k7KTTdz2uOZKj4CSMTYb4=; b=UzxMmt8nGQwVP2lsNIhzX4TNAKEkFXjS77qnKWIp1QxuXy6g8l7HSNXDR4gYBbHzuL ZK8UvSMKSuZJGCg/tQXcy6UKkil2qZNMxd8cCmyMBMA+6NP+WmGRu6jtFyKkRmQ4YnpA Ei/EZKX4WUC9Au5VJe8VleFR7oDGKi6ix3GzozYRA6o9quoDo6XgAXof7+jAbZIukP92 5rCulJu6ifIdzOdPdCOUpZAY3sbycdgCqKfBYGOXZ99UTjNuds3OybkDcinlnZgxnApW qxsyAZEE66UuHPZ9aZ/43KBSU7tHW3DcyxN6DZCL2svpa6DI54WxNrcKVxN8RsLNKg4o DJDw== X-Gm-Message-State: APjAAAXTIls2K5OJGYuEXIjocjpLiMgYgqx3DInwCJfuS1TW1PKQPkb0 NBOLHj09eSHWtResEwp0wUSPpG32UFt8r/JmZy7XXgYE7KDfKxi2 X-Google-Smtp-Source: APXvYqyRcQKgs9vtRwMhlFghI4KSb49ATLrdEsoD/965kxi1/rPO3L+BomiUbbvfNKxWLSE9qLe2ORF7LkxmeZabEyk= X-Received: by 2002:a67:5d02:: with SMTP id r2mr11511465vsb.212.1573872171377; Fri, 15 Nov 2019 18:42:51 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Sat, 16 Nov 2019 10:42:34 +0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000b2a00405976dabb0" Archived-At: Subject: [MLS] Poll: January 2020 Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 02:42:55 -0000 --000000000000b2a00405976dabb0 Content-Type: text/plain; charset="UTF-8" MLSWG, In order to take advantage of the proximity of the Real World Crypto conference, we have two proposed options for the next interim meeting. Please fill out the poll to indicate which one you prefer if you plan to attend. Saturday January 11, Sunday January 12 - New York City Monday January 13, Tuesday January 14 - Washington, DC https://doodle.com/poll/ne492iv8pva3vbnh Nick & Sean --000000000000b2a00405976dabb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
MLSWG,

In order to take advantage of th= e proximity of the Real World Crypto conference, we have two proposed optio= ns for the next interim meeting. Please fill out the poll to indicate which= one you prefer if you plan=C2=A0to attend.

Saturd= ay January 11, Sunday January 12 - New York City
Monday January 13, Tues= day January 14 - Washington, DC


Nick & Sean
--000000000000b2a00405976dabb0-- From nobody Fri Nov 15 19:07:27 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7251200A4 for ; Fri, 15 Nov 2019 19:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKoQy5Nv0csA for ; Fri, 15 Nov 2019 19:07:23 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DD9120024 for ; Fri, 15 Nov 2019 19:07:23 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id d5so9764535otp.4 for ; Fri, 15 Nov 2019 19:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UzPQ2QWDnnQSBW/SqBa/MhjgXhD/iHF0Nl74S/GfdDY=; b=LDI3NWDeU9IoD6E2/gNhmtznW9Z6bS1EKjkiwuy6RhuCvbPj5bTHknNFdNBg/7peMg 33+x+qtj4lfUFdN9AXjHJC/On6RvMnEXXc6op3mRRknjv6NNWqiIoIHTREeZ0rBKMGBF 1Zsqi3k19jJtkMBr8oo3Ja274MXNijFfhPsWuZ+Dg/guuShg7FhRMgPQMKyTO2tLz1Rn No3w1sOWL4QwyEnkUOVhlme/bSunB8G/gB4elEcqivbdSDOMAmJJF4a5mAwjcw4Gp+YY CZrizsD/waTzBmrqsZUU/npZYE+Lg+57FnymQa8AdCP8MmbB1o57M4zWfHi21Mht80SX yTxA== 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=UzPQ2QWDnnQSBW/SqBa/MhjgXhD/iHF0Nl74S/GfdDY=; b=DVWQA4ZLyJlRSfMiAmOrohV3MWOxrLADqd7OJzyqj+Sl7FiJstBICvC6QfjZtYfOqS hKlEcVsoFGW05sl8e1Rw1mLHU0reFna3dBmu0UbYBxyTCyRYFnyBRrd5lJv5/6XTz1dP Lp0uMNfkWCtHBDfhnPnfMNYJXev5dvjwjrZFSqGFf1DaPsygTBNqq26YjH4DpztAkaz8 wjla+Wb+fYDghf/w6ZuLLT1ac7G3njfQS3ME6toPMd1mB63f6PAubCztiMKrC3Z/JEJf USH0xYD5NCUpiiQ1o1Hrf0iAa48MbciiD1STS6rxugz452nlcehIvNNBq4pPLiMEtLGZ bhmA== X-Gm-Message-State: APjAAAU84hGYeLpyj1BljEFl6b8RP83XAosdMBwaL2HffEV8G2IJlBIR vVxg74YXxn/HwLxij87BVwsL4T8P9wmB8WlYDcqQRJGfub8= X-Google-Smtp-Source: APXvYqwfWnQYQU598KE1KNHKf2UVy2cvL9TwDBxiOwxm/zoD60WkdsQvcQk9VBu5Z6HB2+ZqWBP0RcpKMapEGOwbCzU= X-Received: by 2002:a05:6830:2335:: with SMTP id q21mr13065377otg.237.1573873642739; Fri, 15 Nov 2019 19:07:22 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Fri, 15 Nov 2019 19:06:48 -0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000066215205976e0327" Archived-At: Subject: [MLS] draft-08 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 03:07:25 -0000 --00000000000066215205976e0327 Content-Type: text/plain; charset="UTF-8" Hi folks, The MLS protocol authors have been busy the last few days getting some PRs landed. We are working on formally publishing draft-08, but in the meantime, I would encourage people to check out the mirrored version on GitHub in preparation for discussion on Friday: https://github.com/mlswg/mls-protocol/blob/draft-ietf-mls-protocol-08/draft-ietf-mls-protocol.md For the Friday meeting, we'll provide an overview of the recent changes just to confirm everyone's OK, but it would be good if people had taken a look through the document in advance. Thanks, --Richard --00000000000066215205976e0327 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

The MLS protocol a= uthors have been busy the last few days getting some PRs landed.=C2=A0 We a= re working on formally publishing draft-08, but in the meantime, I would en= courage people to check out the mirrored version on GitHub in preparation f= or discussion on Friday:


For the Friday = meeting, we'll provide an overview of the recent changes just to confir= m everyone's OK, but it would be good if people had taken a look throug= h the document in advance.

Thanks,
--Ric= hard
--00000000000066215205976e0327-- From nobody Fri Nov 15 21:01:42 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4312D1200B6 for ; Fri, 15 Nov 2019 21:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.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 Omnctukn2QhM for ; Fri, 15 Nov 2019 21:01:37 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770045.outbound.protection.outlook.com [40.107.77.45]) (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 70E3712007C for ; Fri, 15 Nov 2019 21:01:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PSpcx0k5SZoF4I40tKKUlbtXyivCRDrg3JasA/VcyrhYam5K/gmsi6TIMmMUzwp63NNTRRtMeezyiJAFZtQRZRNAlUU+gnmktuoGdB7M+HdUbFX/noVWWJWGa0Bku8MqaBmO/RNm5phPkju5uz4pHNPrZt6xIVaNvG5mFUmuw7E3mLAT++Ts0mwkN4WkzENe32WFinDwPo0W7qGEPqDQ5T8cYZp3awczt9Xzq894oScQS+BHABTG4BSDPmM4aPHq5qs/wmBhmtexYTvS35MFN06JZpUwA6FK/xT9rfzZF7Jr2q7DDMg9jcITK3KdBU++AvgOzdljEs/MxRe+Nzft/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a8KPns1nXpC2Q4fye0kkpKGUfmPVBoP3Eilk8JV7JJQ=; b=X3h6007aSCrcihMKuzJEmVkrkx3ec9JWk6teg+PdBgfo8hRPYjpLHCuiWeeb9M623NkUKNZVy5ZzMHjeYIkGsXaWVMNZPYt6XIXELwFfsE172LiMCAfoTtUNYXvqYxm7G46SGZhr8a7SA0UiZjZiNPVOoL0GfMfUW9/JIkS0p7xnLEsBx8mKnL7Wm7HNqrdOzH44b+bjxtAevW5JSljapwlLBp5gedPBjsIPZNmbt4FZaQIGxipVUrETD+1gGrXMvxWm+gDZMUMFHsBRTmKpKtNOIJcIj/saqrZg/jegxmLKkotX2RHwB6Q5wogHI9Z9atvOB20epB5pcqt9DIRXlw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a8KPns1nXpC2Q4fye0kkpKGUfmPVBoP3Eilk8JV7JJQ=; b=lFm1Qi+F+kLqOc8qRIGd73uWLX4kqWm77q2bOiPYFUgTaAxR17Ug/UXonMXlXPYY67Mo3/f11zgoBJbvJ85RrWzLvjuDXAD3sGx6KyiEHN2sqJpq9SZxjQYJUMwIxMbZ2YiPSE7LZhYW7myUVRJRb/jsrYxY5PLq+Jv0MexxVy8= Received: from CH2PR06MB6743.namprd06.prod.outlook.com (20.180.9.24) by CH2PR06MB6552.namprd06.prod.outlook.com (20.180.12.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Sat, 16 Nov 2019 05:01:35 +0000 Received: from CH2PR06MB6743.namprd06.prod.outlook.com ([fe80::b4e1:d7cf:a544:2bd5]) by CH2PR06MB6743.namprd06.prod.outlook.com ([fe80::b4e1:d7cf:a544:2bd5%7]) with mapi id 15.20.2451.029; Sat, 16 Nov 2019 05:01:35 +0000 From: Joseph Lorenzo Hall To: Richard Barnes , Messaging Layer Security WG Thread-Topic: [MLS] draft-08 Thread-Index: AQHVnCr89UuBBpgLQEuLdN2QEVYZiKeNPUfx Date: Sat, 16 Nov 2019 05:01:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hall@isoc.org; x-originating-ip: [167.99.120.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 94c25633-c7b6-4fd1-a137-08d76a520e48 x-ms-traffictypediagnostic: CH2PR06MB6552: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02234DBFF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(366004)(396003)(39850400004)(189003)(199004)(55674003)(110136005)(14454004)(66476007)(55016002)(66574012)(476003)(99286004)(102836004)(5660300002)(316002)(66066001)(86362001)(25786009)(14444005)(52536014)(81166006)(11346002)(26005)(74316002)(486006)(8676002)(81156014)(6246003)(6306002)(54896002)(3846002)(6116002)(236005)(53546011)(6506007)(478600001)(9686003)(76116006)(66446008)(256004)(8936002)(446003)(7736002)(33656002)(966005)(66556008)(64756008)(76176011)(606006)(71190400001)(71200400001)(186003)(66946007)(229853002)(2906002)(7696005)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:CH2PR06MB6552; H:CH2PR06MB6743.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aqUd4N96vt0d31dgzljxpaK+bhbrPJZTdhAKUF42/yueEmxfg4/xm2Yv7lZD+irijQWAt6tbZAUjZcqpELQoVtZj696rRR9+vsxQ0uBwcC6FGq9Ljq7GqPkmZEV73Aghb4PWZcXOBde5mrBFj4WuwBqy4UnxlTytPVp6y4GFV63lPn0vifTeB3n4HKLmsUSXwDpAKPoUgVP49BAAfjG43iEW6KBjL5CSAs46nKKfy9VfejcOd95bnIvevXwo38551rOjyzenzDjfg8p35rCOX+MFZzJqSDlMysnFN8cTEwFzw4ZoV+Orv+pCPs5RWOsbhRFPSiDemUmhVEAkCALDqgXlcZX1QaJZkPPweEjBd+bLVRmiupnuP2L8PO936KzXt531DMz1ycOIHUewytW72eXv8912+Y1QYtcg0cGbnjtB6SfmsLKDjY3Q1Sm09YoN x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR06MB6743E9C20B3E32292EC7367CB1730CH2PR06MB6743namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 94c25633-c7b6-4fd1-a137-08d76a520e48 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2019 05:01:35.4762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P9TyfgKi9btzyI2OEaJUCFesLiQ0yWsi0eSnaxhyFSpHhk0XRWV6Hrv9cPD4d4G2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR06MB6552 Archived-At: Subject: Re: [MLS] draft-08 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 05:01:40 -0000 --_000_CH2PR06MB6743E9C20B3E32292EC7367CB1730CH2PR06MB6743namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not sure why, but the anchor here seems to be github..com, the real deal: https://github.com/mlswg/mls-protocol/blob/draft-ietf-mls-protocol-08/draft= -ietf-mls-protocol.md -- Joseph Lorenzo Hall; SVP, Strong Internet Internet Society; https://isoc.org/ ________________________________ From: MLS on behalf of Richard Barnes Sent: Saturday, November 16, 2019 7:06:48 AM To: Messaging Layer Security WG Subject: [MLS] draft-08 Hi folks, The MLS protocol authors have been busy the last few days getting some PRs = landed. We are working on formally publishing draft-08, but in the meantim= e, I would encourage people to check out the mirrored version on GitHub in = preparation for discussion on Friday: https://github.com/mlswg/mls-protocol/blob/draft-ietf-mls-protocol-08/draft= -ietf-mls-protocol.md For the Friday meeting, we'll provide an overview of the recent changes jus= t to confirm everyone's OK, but it would be good if people had taken a look= through the document in advance. Thanks, --Richard --_000_CH2PR06MB6743E9C20B3E32292EC7367CB1730CH2PR06MB6743namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not sure why, but the anchor here seems to be github..com, the real deal:

https://github.com/mlswg/mls-protocol/blob/draft-ietf-mls-protocol-08/draft= -ietf-mls-protocol.md

--
Joseph Lorenzo Hall; SVP, Strong Internet
Internet Society; https://isoc.org/
From: MLS <mls-bounces@i= etf.org> on behalf of Richard Barnes <rlb@ipv.sx>
Sent: Saturday, November 16, 2019 7:06:48 AM
To: Messaging Layer Security WG <mls@ietf.org>
Subject: [MLS] draft-08
 
Hi folks,

The MLS protocol authors have been busy the last few days getting some= PRs landed.  We are working on formally publishing draft-08, but in t= he meantime, I would encourage people to check out the mirrored version on = GitHub in preparation for discussion on Friday:


For the Friday meeting, we'll provide an overview of the recent change= s just to confirm everyone's OK, but it would be good if people had taken a= look through the document in advance.

Thanks,
--Richard
--_000_CH2PR06MB6743E9C20B3E32292EC7367CB1730CH2PR06MB6743namp_-- From nobody Sun Nov 17 19:46:43 2019 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B784C120827; Sun, 17 Nov 2019 19:46:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <157404879669.24354.4495657958235068720@ietfa.amsl.com> Date: Sun, 17 Nov 2019 19:46:36 -0800 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-08.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 03:46:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Benjamin Beurdouche Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-08.txt Pages : 62 Date : 2019-11-17 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-protocol-08 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 00:36:18 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35104120A8D for ; Wed, 20 Nov 2019 00:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UMipQh8W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=O4X6sAJ+ 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 PfJzTiT3Eeux for ; Wed, 20 Nov 2019 00:36:13 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646AC120A88 for ; Wed, 20 Nov 2019 00:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9187; q=dns/txt; s=iport; t=1574238972; x=1575448572; h=from:to:subject:date:message-id:mime-version; bh=mq0EjkgBWIemlP8t+fkwX6QCcrDwAF17+csfMcpo/pQ=; b=UMipQh8W9jk+TjNTtmil/Zp/YVv+vevPnNt+0cWvIMpTBfY8Ub2aKd0o gbd5kE2kE3Y07Jwwh9LW2qvtECP9DJ9F0dU/gP+Thllksfm9QAL8jcqB6 qkTCK22Irgo24E1j9O73fA7V4eZceLrKMavn6CthobWk6OBlthzTfwkGk E=; IronPort-PHdr: =?us-ascii?q?9a23=3AG2hybhM8UdFXmZ2bqg0l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj8IuTrYigSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEEQBJ+tRd/4sNJK1cCR0BAQEJARE?= =?us-ascii?q?FBQGBfoEcLyQsBWxYIAQLKodwA4pzTpUuhGKCUgNUCQEBAQwBASMKAgEBhEA?= =?us-ascii?q?CgiYkOBMCAw0BAQQBAQECAQUEbYU3AQuFahsTAQE4EQGBAB8HAQQbGoMBgXl?= =?us-ascii?q?NAy4BAgylGwKBOIhggieCfgEBBYE4AoNUGIIXAwaBNowVGIFAP4ERRoVsAQE?= =?us-ascii?q?DgTQsK4MVgiyVWphTCoIrhxqOUII+l1OOSIFBhneRUAIEAgQFAg4BAQWBaSK?= =?us-ascii?q?BWHAVgydQERSRGoNzhRSFP3SBKI4RAQE?= X-IronPort-AV: E=Sophos;i="5.69,221,1571702400"; d="scan'208,217";a="376521238" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Nov 2019 08:36:11 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xAK8aBeS020105 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Nov 2019 08:36:11 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 02:36:10 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 02:36:10 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Nov 2019 03:36:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cVFAl673c8T4a0fddAaUPqPRRkL8Ii8k8ThwywKyGAPSv4rSlKjbp4K98W1QJKzxol6w9unsBKcTAcDbo0KKqfgCRXhRZNqF82GQfN47Jsrg7zNHhpWCmUL5kkOiRvO45vHcKUtTyc33PMfJJP1oHl8xYZeob0+VJuBTpuqEUVI+7eAm6x+4xS3CShm0ruKh+eMFDTXkyaFTWOnWh9WrYqOsS1qIh+qf7MDYwfHu/1UFfeo6DUoz/vCv6ANNKxTRQ397nPZjyNFnPyuTV2JdjJm4oS5KzeBVjB+23bnN9pgg7OSuEDjCZ2g2nXNnUkrThneoP/R3l7zUYfmdC/MjfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=85QyPOBdUwrkANBD3gwANobmr7eETvzE0WnQSu3boSo=; b=oO7Tn4M/Liia2onZ9PQZ3e8N5kBgnJGIf0OTYGbCAmmi38OeBzAUvsEyRtZ0NPq9FeDuL3b93J3OOVnJTcVAUskW+X0WtsP26a90sfiI/A7VyCjnjoevWwwuu6rfVl5JGa2sCgb/5m1UzZ8DpyL8iDlHSR8DEoS0lqJYpfevm68Kvb8AEpg+xAoWOucX8Q7IceV2wEh94aKfDSLoiDf2oY/khEdLBAOzu4dxMlY2MQl9I4FbCAqxZ2FFTCiCHV3avFZ08PBdrcweXqONmpjiajB+42OaO8+X1xB3zyiTnoc7aI5e9qcRuSSfSFemubSfdxSgDYIKXLzQS6Mv614yTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=85QyPOBdUwrkANBD3gwANobmr7eETvzE0WnQSu3boSo=; b=O4X6sAJ+fYSAA0eHFfcHpRCMooPxX8gs8AY+BR2yc9fUG2veFiwe43pEcmxNpihDVomYjRNlKyTFE7ni9AXFrBjZOfnE5r9nNjybE5RKIuXQ5A6FDFk4wy9IdN+P4nOmBSGhzmaj+SpFkrcL6IQfiIaPF4m7ymqPTqetRxthbJw= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4478.namprd11.prod.outlook.com (52.135.36.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Wed, 20 Nov 2019 08:36:09 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 08:36:09 +0000 From: "Owen Friel (ofriel)" To: "mls@ietf.org" Thread-Topic: long term identity key rotation suggestion Thread-Index: AdWfaFzfcHmkK9WtQtuHC238EKTEkA== Date: Wed, 20 Nov 2019 08:36:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:c0c8:1001::f0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4cbefbc1-d520-4dc5-12bc-08d76d94b174 x-ms-traffictypediagnostic: MN2PR11MB4478: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(39860400002)(136003)(346002)(366004)(199004)(189003)(102836004)(186003)(316002)(71190400001)(81166006)(25786009)(14454004)(2906002)(8676002)(71200400001)(7736002)(81156014)(966005)(8936002)(1730700003)(478600001)(606006)(76116006)(74316002)(256004)(14444005)(33656002)(561944003)(5660300002)(66946007)(790700001)(6116002)(66556008)(64756008)(66446008)(66476007)(46003)(52536014)(86362001)(2501003)(476003)(5640700003)(486006)(99286004)(2351001)(7696005)(236005)(9686003)(54896002)(6306002)(55016002)(6436002)(6506007)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4478; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: blCptFJ+5HzuLHAKxe/ZeadNyjrJR0g4L1c4WWUBMyVjJft09curcJfoOTbjngQYKS+s1eturG+EOOg6nVSmr/6YKpWTxUfX6tVPegQVFn2LGRwYsIFIACtBN1i2v7h897j5X3S1wBRYBvI1SDHku2x3Xihbao+NCAEDrgeL9+e6voSiGuWDOuW/pU2qIiCBuY34qI0dfNA/hevGkgScfIXL/+4XTtdJP+UZ03iRHEYdMPB9Os/1pkKR4xSTeZLJBbcTOI/B0xxZL5lfwSn/3oKCIrWSPrl0sPd7Roy5sbG2P9lj+R8uaZrInOa2UGqHJVdQX9Ltrxj8zBMUiY+BeZS04Yls6w3yJC3NaB713oaOe2cLfrZKMPm6gr+yXMorxawM3LYxFp0ZWOBmFPO0WjOuMsNbnsGB6TMiqlV7rB8E1yvyvGShiS5khW83TVrlmO9lO6U9uFyhG40oARs4x81r/95+Bmz8llxgZsLGcw4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3901A192266B08604772B91BDB4F0MN2PR11MB3901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4cbefbc1-d520-4dc5-12bc-08d76d94b174 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 08:36:09.5156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JS/23RXDrSaYBqlN4DgDzSHhLmYb6G7Hprt4M/SV8TTrFD/TSTdDsp6hb1DHAR80mSEWufyRmn4xlmsX+VtR9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4478 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: [MLS] long term identity key rotation suggestion X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 08:36:16 -0000 --_000_MN2PR11MB3901A192266B08604772B91BDB4F0MN2PR11MB3901namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is currently no mechanism defined in https://tools.ietf.org/html/draf= t-ietf-mls-protocol-08 for long term identity key rotation. Richard and I h= ave been thinking about how we could address this and here is a suggestion = that could work. The genesis of the idea is that as client can Add and Remove other parties = from a group, a client with both an existing long term identity key (LTIK) = that is in a group, and a new LTIK that is not in the group, could Add the = new LTIK to the group, and then the client uses the new LTIK to Remove the = old LTIK from the group. Working through that, it quickly collapses into a = single Update message. It ends up looking something like this (where CIK =3D ClientInitKey): Client starts with: LTIK-0 CIK-0 signed by LTIK-0 LTIK-0 and CIK-0 public key are in a group LeafNodeInfo. Client then: Generates new LTIK-1 and interacts with AS to get new LTIK-1 attested/signe= d. Generates CIK-1 and signs it using LTIK-1 Interacts with DS to get LTIK-1/CIK-1 public keys published. Then the client: Sends Update Proposal message, signed by LTIK-0, which includes CIK-1, as o= pposed to just an HPKEPublicKey. Updates DirectPath Sends Commit message, signed by LTIK-0, which includes new DirectPath Receiving clients need to: Check that the Update is signed by LTIK-0 and that LTIK-0 is trusted Check that CIK-1 is signed by the embedded LTIK-1 Check that LTIK-1 is trusted Update the sender's LeafNodeInfo with LTIK-1 and CIK-1 public key Subsequent messages sent by the client are signed using LTIK-1. Thoughts? Owen --_000_MN2PR11MB3901A192266B08604772B91BDB4F0MN2PR11MB3901namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is currently no mechanism defined in https://tools.ietf.org/html/draft-ietf-mls-protocol-08 for long term id= entity key rotation. Richard and I have been thinking about how we could ad= dress this and here is a suggestion that could work.

 

The genesis of the idea is that as client can Add an= d Remove other parties from a group, a client with both an existing long te= rm identity key (LTIK) that is in a group, and a new LTIK that is not in th= e group, could Add the new LTIK to the group, and then the client uses the new LTIK to Remove the old LTIK fr= om the group. Working through that, it quickly collapses into a single Upda= te message.

 

It ends up looking something like this (where CIK = =3D ClientInitKey):

 

Client starts with:

 

LTIK-0

CIK-0 signed by LTIK-0

LTIK-0 and CIK-0 public key are in a group LeafNodeI= nfo.

 

Client then:

 

Generates new LTIK-1 and interacts with AS to get ne= w LTIK-1 attested/signed.

Generates CIK-1 and signs it using LTIK-1=

Interacts with DS to get LTIK-1/CIK-1 public keys pu= blished.

 

Then the client:

 

Sends Update Proposal message, signed by LTIK-0, whi= ch includes CIK-1, as opposed to just an HPKEPublicKey.

Updates DirectPath

Sends Commit message, signed by LTIK-0, which includ= es new DirectPath

 

Receiving clients need to:

 

Check that the Update is signed by LTIK-0 and that L= TIK-0 is trusted

Check that CIK-1 is signed by the embedded LTIK-1

Check that LTIK-1 is trusted

Update the sender’s LeafNodeInfo with LTIK-1 a= nd CIK-1 public key

 

Subsequent messages sent by the client are signed us= ing LTIK-1.

 

Thoughts?

Owen

--_000_MN2PR11MB3901A192266B08604772B91BDB4F0MN2PR11MB3901namp_-- From nobody Wed Nov 20 01:00:41 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AEA1208E3 for ; Wed, 20 Nov 2019 01:00:39 -0800 (PST) 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, SPF_HELO_NONE=0.001, 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 AebeIMTLrwTP for ; Wed, 20 Nov 2019 01:00:37 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0535B1208BC for ; Wed, 20 Nov 2019 01:00:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.69,221,1571695200"; d="scan'208,217";a="327342408" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.20]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2019 10:00:21 +0100 From: Benjamin Beurdouche Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F6AF20C7-1560-412B-A893-522B8E123D3D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 20 Nov 2019 10:00:19 +0100 In-Reply-To: Cc: ML Messaging Layer Security To: "Owen Friel (ofriel)" References: X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [MLS] long term identity key rotation suggestion X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 09:00:40 -0000 --Apple-Mail=_F6AF20C7-1560-412B-A893-522B8E123D3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Owen, We=E2=80=99ve had this mechanism in mind for a while now and a few PRs = are in the works to achieve that. The idea is very similar, we are replacing the leaves of = the Tree by having the full ClientInitKeys and are introducing a =E2=80=9CIdentity=E2=80=9D = group operation which will replace the entire ClientInitKey in the leaf, this message being =E2=80=9Cblessed=E2=80= =9D by the current signature key. Aditionally to that, I=E2=80=99ll propose (probably earlier) that we = split the term identity key from the signature key in such a way that the signature used in the protocol = are group-specific and not reused accross groups. Because authentication is extremely critical and affects basically = everything in the protocol, we want minimal security proof before pushing this PR and we=E2=80=99ll = try to discuss it at the interim in January to see if we can get consensus. : ) Best, Benjamin > On Nov 20, 2019, at 9:36 AM, Owen Friel (ofriel) = wrote: >=20 > There is currently no mechanism defined in = https://tools.ietf.org/html/draft-ietf-mls-protocol-08 = for long term = identity key rotation. Richard and I have been thinking about how we = could address this and here is a suggestion that could work. > =20 > The genesis of the idea is that as client can Add and Remove other = parties from a group, a client with both an existing long term identity = key (LTIK) that is in a group, and a new LTIK that is not in the group, = could Add the new LTIK to the group, and then the client uses the new = LTIK to Remove the old LTIK from the group. Working through that, it = quickly collapses into a single Update message. > =20 > It ends up looking something like this (where CIK =3D ClientInitKey): > =20 > Client starts with: > =20 > LTIK-0 > CIK-0 signed by LTIK-0 > LTIK-0 and CIK-0 public key are in a group LeafNodeInfo. > =20 > Client then: > =20 > Generates new LTIK-1 and interacts with AS to get new LTIK-1 = attested/signed. > Generates CIK-1 and signs it using LTIK-1 > Interacts with DS to get LTIK-1/CIK-1 public keys published. > =20 > Then the client: > =20 > Sends Update Proposal message, signed by LTIK-0, which includes CIK-1, = as opposed to just an HPKEPublicKey. > Updates DirectPath > Sends Commit message, signed by LTIK-0, which includes new DirectPath > =20 > Receiving clients need to: > =20 > Check that the Update is signed by LTIK-0 and that LTIK-0 is trusted > Check that CIK-1 is signed by the embedded LTIK-1 > Check that LTIK-1 is trusted > Update the sender=E2=80=99s LeafNodeInfo with LTIK-1 and CIK-1 public = key > =20 > Subsequent messages sent by the client are signed using LTIK-1. > =20 > Thoughts? > Owen > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_F6AF20C7-1560-412B-A893-522B8E123D3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Owen,

We=E2=80=99ve had this mechanism in mind for a while now and = a few PRs are in the works to
achieve that. The = idea is very similar, we are replacing the leaves of the Tree by = having
the full ClientInitKeys and are introducing = a =E2=80=9CIdentity=E2=80=9D group operation which will replace = the
entire ClientInitKey in the leaf, this message = being =E2=80=9Cblessed=E2=80=9D by the current signature key.

Aditionally to that, = I=E2=80=99ll propose (probably earlier) that we split the term identity = key from
the signature key in such a way that the = signature used in the protocol are group-specific
and= not reused accross groups.

Because authentication is extremely critical and affects = basically everything in the protocol,
we want = minimal security proof before pushing this PR and we=E2=80=99ll try to = discuss it at the interim
in January to see if we = can get consensus. : )

Best,
Benjamin


On Nov 20, 2019, at 9:36 AM, Owen Friel = (ofriel) <ofriel@cisco.com> wrote:

There is = currently no mechanism defined in https://tools.ietf.org/html/draft-ietf-mls-protocol-08 for long term identity key = rotation. Richard and I have been thinking about how we could address = this and here is a suggestion that could work.
 
The = genesis of the idea is that as client can Add and Remove other parties = from a group, a client with both an existing long term identity key = (LTIK) that is in a group, and a new LTIK that is not in the group, = could Add the new LTIK to the group, and then the client uses the new = LTIK to Remove the old LTIK from the group. Working through that, it = quickly collapses into a single Update message.
 
It ends = up looking something like this (where CIK =3D ClientInitKey):
 
Client = starts with:
 
LTIK-0
CIK-0 signed by LTIK-0
LTIK-0 and CIK-0 public key are in a = group LeafNodeInfo.
 
Client then:
 
Generates new LTIK-1 and interacts with AS to get new LTIK-1 = attested/signed.
Generates CIK-1 and signs it using LTIK-1
Interacts = with DS to get LTIK-1/CIK-1 public keys published.
 
Then the = client:
 
Sends Update Proposal message, signed by LTIK-0, which = includes CIK-1, as opposed to just an HPKEPublicKey.
Updates = DirectPath
Sends Commit message, signed by LTIK-0, which includes new = DirectPath
 
Receiving clients need to:
 
Check that the Update is signed by = LTIK-0 and that LTIK-0 is trusted
Check that CIK-1 is signed by the = embedded LTIK-1
Check that LTIK-1 is trusted
Update the sender=E2=80=99s = LeafNodeInfo with LTIK-1 and CIK-1 public key
 
Subsequent = messages sent by the client are signed using LTIK-1.
 
Thoughts?
Owen
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_F6AF20C7-1560-412B-A893-522B8E123D3D-- From nobody Thu Nov 21 08:51:32 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F221200C4 for ; Thu, 21 Nov 2019 08:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=snap.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 5w6-04557jQS for ; Thu, 21 Nov 2019 08:51:30 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 77FCC120125 for ; Thu, 21 Nov 2019 08:51:30 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id u24so2506525iob.5 for ; Thu, 21 Nov 2019 08:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snap.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=DrUNw0zJQeBNAc+RyaBtjQWaHUk4GIkb7+NaKRa9DiY=; b=PM3vXTzkQOAMnorIcmGTts6cxv1M1h6r7LRjAwTNVKbjDxt6OSXzT6m1W3CixpGAn5 zi2HPY361m15AFmH2NrzuuIhau6dO3craezsmQ436BL5L2a00wF1zyo7vD/6nV7c9DFj PRhVVulNJgvKCJRrkahL0Vv5GxzPtzYhQmmiU= 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=DrUNw0zJQeBNAc+RyaBtjQWaHUk4GIkb7+NaKRa9DiY=; b=EWzuTGcU8riAMbwAAdV+F2oFAQmdoe05Hp0GhvlKevZX8EyrX7LgbyTTMUAWwJVcbp pWISTGJZCF3Itf/E2onrAed5jVDpuAf5OkXpSH+MekFJWsVOkPUxHrzx+TadoQplSN9x /cQJ2YQcMD6b4n6/4B5167ybywMU0r6ZAcShINXF70ttmx+VtiMA1h+9PlHEfnQGzsp6 CS0OVUvCi0GRWbpCgbhOsSEuhkNZTHKyXPpRl4lJx7cySod8M0gtIZeRAR9xYsx+ZbSM lZN3FbYvzuOBp/ts32IFj7/d+qo4L06SEpI3QMtbDTDqLm4X9imgq8lwPu1tgIdHQ9X0 Ncqg== X-Gm-Message-State: APjAAAXHUqtEK6kD6c1y1OAdlaTPgeJgYG1annEBezPBB9XWRUXv++Yc v8OSXvQUqcPEHZJd+3lDAVMO1rQd2gGgRFtxJtSrq2hDmFQQJg== X-Google-Smtp-Source: APXvYqxmL/WxfV6zeT2cnECBrYSMyhIqjSHjVwxAwYHNA2wra5ZEqu8072PLCJfatTWsBni+wDgyAPvevnlAhRmR2Ac= X-Received: by 2002:a6b:b9d5:: with SMTP id j204mr8258775iof.129.1574355089483; Thu, 21 Nov 2019 08:51:29 -0800 (PST) MIME-Version: 1.0 From: Pascal Junod Date: Thu, 21 Nov 2019 17:51:18 +0100 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000dc178d0597de1b47" Archived-At: Subject: [MLS] [Delivery Service] X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 16:51:32 -0000 --000000000000dc178d0597de1b47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi ! In the architecture document, one expects the Delivery Service "*to route messages between clients and to act as a message broadcaster, taking in one message and forwarding it to multiple clients (also known as =E2=80=9Cserve= r side fanout=E2=80=9D).*" (cf. =C2=A72.3) At the same time, a bit further, one can read that "*Group membership is itself sensitive information and MLS is designed so that neither the DS nor the AS need have static knowledge of which clients are in which group.*" In particular, the ClientInitKey and Welcome messages do not have any notion about group or node identities, they only have the client_init_key_i= d field in common, which means that the DS has no means (through the current protocol format) to route messages in a proper way. How is it possible to solve this apparent contradiction ? Many thanks in advance, Pascal --000000000000dc178d0597de1b47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi !

In the architecture document, = one expects the Delivery Service "to route messages between clients= and to act as a message broadcaster, taking in one message and forwarding = it to multiple clients (also known as =E2=80=9Cserver side fanout=E2=80=9D)= ." (cf. =C2=A72.3)

At the same time, a bi= t further, one can read that=C2=A0"Group membership is itself sensi= tive information and MLS is designed so that neither the DS nor the AS need= have static knowledge of which clients are in which group."
=

In particular, the ClientInitK= ey and Welcome messages do not have = any notion about group or node identities, they only have the client_init_key_id field in common, which means that the= DS has no means (through the current protocol format) to route messages in= a proper way.=C2=A0

How is it possible to solve= =C2=A0this apparent contradiction ?

Many thanks in= =C2=A0advance,=C2=A0

Pascal
--000000000000dc178d0597de1b47-- From nobody Thu Nov 21 10:34:09 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C99120108 for ; Thu, 21 Nov 2019 10:34:07 -0800 (PST) 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, SPF_HELO_NONE=0.001, 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 Q7YhrDw7Vy-W for ; Thu, 21 Nov 2019 10:34:05 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B0D1200FA for ; Thu, 21 Nov 2019 10:34:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.69,226,1571695200"; d="scan'208,217";a="412925697" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.20]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2019 19:34:03 +0100 From: Benjamin Beurdouche Message-Id: <75433909-13FF-4D0E-B6E5-9300DEFBC041@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_D4B55078-44FD-47F1-8C17-2E4EFDEDEED5" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Thu, 21 Nov 2019 19:34:02 +0100 In-Reply-To: Cc: ML Messaging Layer Security To: Pascal Junod References: X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [MLS] [Delivery Service] X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 18:34:07 -0000 --Apple-Mail=_D4B55078-44FD-47F1-8C17-2E4EFDEDEED5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Pascal ! Let me try to explain as best as I can the intended meaning and some of = the MLS goals... > On Nov 21, 2019, at 5:51 PM, Pascal Junod = wrote: >=20 > Hi ! >=20 > In the architecture document, one expects the Delivery Service "to = route messages between clients and to act as a message broadcaster, = taking in one message and forwarding it to multiple clients (also known = as =E2=80=9Cserver side fanout=E2=80=9D).." (cf. =C2=A72.3) >=20 > At the same time, a bit further, one can read that "Group membership = is itself sensitive information and MLS is designed so that neither the = DS nor the AS need have static knowledge of which clients are in which = group." >=20 > In particular, the ClientInitKey and Welcome messages do not have any = notion about group or node identities, they only have the = client_init_key_id field in common, which means that the DS has no means = (through the current protocol format) to route messages in a proper way.=20= >=20 > How is it possible to solve this apparent contradiction ? The CIK cannot have a notion of group obviously, but the encrypted = GroupInfo of the Welcome message does contain the GroupID, so on receipt, as a newcomer, you know for = which group this new state is. Now, from the architecture perspective=E2=80=A6 In terms of privacy, one of the good scenarios in modern architectures = is a DS which does not locally maintain (=E2=80=9Chas static knowledge=E2=80=9D) the group memberships=E2=80=A6 = In that case, either: 1. the protocol has to expose the receipient(s) in the message and the = DS can just look at the message itself 2. the application adds metadata containing a list of recipients which = allows the DS to store a copy of the message in the correct storage location, notify the users and = then can =E2=80=9Cforget=E2=80=9D who the recipients where. There are many alternatives which are left to the provider regarding = privacy but MLS is trying to allow case 2. for providers that want to achieve it. We definitely have = more work to do on that side, especially because of the GID itself, but inherently Privacy will rely = on the honesty of the AS and DS, while Confidentiality and Authentication can rely only on the AS only. Hope that helps... : ) B.= --Apple-Mail=_D4B55078-44FD-47F1-8C17-2E4EFDEDEED5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Pascal !

Let me try to = explain as best as I can the intended meaning and some of the MLS = goals...

On Nov 21, 2019, at 5:51 PM, Pascal Junod = <pascalj=3D40snap.com@dmarc.ietf.org> wrote:

Hi !

In the architecture document, one expects the Delivery = Service "to route messages between clients and to act as a = message broadcaster, taking in one message and forwarding it to multiple = clients (also known as =E2=80=9Cserver side fanout=E2=80=9D).." (cf. = =C2=A72.3)

At = the same time, a bit further, one can read that "Group = membership is itself sensitive information and MLS is designed so that = neither the DS nor the AS need have static knowledge of which clients = are in which group."

In particular, the ClientInitKey and Welcome messages do not have any notion about group or = node identities, they only have the client_init_key_id field in common, which means that = the DS has no means (through the current protocol format) to route = messages in a proper way. 

How is it possible to solve this = apparent contradiction ?

The CIK cannot have a notion of group obviously, = but the encrypted GroupInfo of the Welcome message
does = contain the GroupID, so on receipt, as a newcomer, you know for which = group this new state is.

Now, from = the architecture perspective=E2=80=A6
In terms of = privacy, one of the good scenarios in modern architectures is a DS which = does not locally maintain
(=E2=80=9Chas static knowledge=E2=80=9D= ) the group memberships=E2=80=A6 In that case, either:
1. the = protocol has to expose the receipient(s) in the message and the DS can = just look at the message itself
2. the application adds = metadata containing a list of recipients which allows the DS to store a = copy
of the message in the correct storage location, notify = the users and then can =E2=80=9Cforget=E2=80=9D who the recipients = where.

There are many alternatives = which are left to the provider regarding privacy but MLS is trying = to
allow case 2. for providers that want to achieve it. We = definitely have more work to do on that side,
especially = because of the GID itself, but inherently Privacy will rely on the = honesty of the AS and DS,
while Confidentiality and = Authentication can rely only on the AS only.

Hope that helps... : = )
B.
= --Apple-Mail=_D4B55078-44FD-47F1-8C17-2E4EFDEDEED5-- From nobody Thu Nov 21 20:47:45 2019 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CB912002F; Thu, 21 Nov 2019 20:47:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mls-chairs@ietf.org, mls@ietf.org, kaduk@mit.edu, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157439806388.32336.17229875127106476126.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2019 20:47:43 -0800 Archived-At: Subject: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 04:47:44 -0000 A new interim meeting request has just been submitted by Sean Turner. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-01 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner City: New York Country: US Session 1: Date: 2020-01-11 Start Time: 09:00 America/New_York Duration: 08:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=maf3f7d72670a243b5f34bcb13954d876 Agenda Note: Meeting No.: 640 425 093 Password: HuMtwuWZ Session 2: Date: 2020-01-12 Start Time: 09:00 America/New_York Duration: 08:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m803940aa758e35a4c300e955efd89d35 Agenda Note: Meeting No.: 646 828 913 Password: 4vFyPvAk --------------------------------------------------------- From nobody Thu Nov 21 20:56:44 2019 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 350A212002F; Thu, 21 Nov 2019 20:56:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157439859865.32312.12639906827628149688@ietfa.amsl.com> Date: Thu, 21 Nov 2019 20:56:39 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting: 2020-01-11 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 04:56:39 -0000 The Messaging Layer Security (mls) Working Group will hold a multi-day interim meeting. Session 1: 2020-01-11 09:00 to 17:00 America/New_York Session 2: 2020-01-12 09:00 to 17:00 America/New_York Meeting Location: New York, US Agenda: TBD Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=maf3f7d72670a243b5f34bcb13954d876 Meeting No.: 640 425 093 Password: HuMtwuWZ From nobody Fri Nov 22 05:55:24 2019 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E347C120147 for ; Fri, 22 Nov 2019 05:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=snap.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 089lWCyQhmTI for ; Fri, 22 Nov 2019 05:55:21 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 D1A951200B9 for ; Fri, 22 Nov 2019 05:55:21 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id x21so8095414ior.2 for ; Fri, 22 Nov 2019 05:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snap.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XHkEFCaUYNnk+ZHESNo0HOFzw+vZ87KUoF/zQzCp/Lg=; b=MiocPm3OUwrbHF56KIgvH+oH5SGIlj8AFDO3S6SnDrZd4Dy+BcMWCsUbFBW4KujvvN UZcibeRg8oplcPqShJwG/W0xOOe4b6Y8aW9qMGnFBq58rsNlbvjrOUmwQKOt59tZckZZ CHD3UEiLtTuDcMYp2NShJTfkbQ4OZXWuh7kLo= 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=XHkEFCaUYNnk+ZHESNo0HOFzw+vZ87KUoF/zQzCp/Lg=; b=gczUX+Qd52V5qHa39kJRUa9qtVdV82bUhTMieGh3f1s2VNbH1RSNqqgFSN09AZc3GF MJIsl0nPHqHPWZ6ztVKqHWT7m44Z7Sikwl+MX5S876+lkq2ucPqXwPLmARywe9FvtGmM x0UTw3UwfVDv12cHJ18j7ddEQN+GDP8iFZyao9DOKMgBW8KfkPAKIW4b86fNMGmuyG10 R/s1d1MpMAqxPOJQIp/J6ITUIzKs3S7yBAFXmI131SFAmUp0TZSBksi+K5l2GEt01J56 Ub/R3Zq8llqhKrKjrZyn6XoJ9PQ+s4K7ap9WyhJOS12oFWk/Kj4vYAGpJCZ7ZcIkgkEQ DzhQ== X-Gm-Message-State: APjAAAXIOC3zTmDnaH7Eeu36+V/KVI76TelCzcmJ5uppF4xVPKY5e3k+ ViTGBM+lGDhh/meVhQDy7faqEvF//z943nkCowwAPf1Rxrg= X-Google-Smtp-Source: APXvYqyCwN0IOj5Wel1UZjcJSQsgmWNUWols26DFh5S0AbLuhMoKoc+Z2/a3sl4VS3HiswEAQb5tFVAYg0UmGB71nJE= X-Received: by 2002:a02:234b:: with SMTP id u72mr14157874jau.44.1574430920987; Fri, 22 Nov 2019 05:55:20 -0800 (PST) MIME-Version: 1.0 References: <75433909-13FF-4D0E-B6E5-9300DEFBC041@inria.fr> In-Reply-To: <75433909-13FF-4D0E-B6E5-9300DEFBC041@inria.fr> From: Pascal Junod Date: Fri, 22 Nov 2019 14:55:10 +0100 Message-ID: To: Benjamin Beurdouche Cc: ML Messaging Layer Security Content-Type: multipart/alternative; boundary="000000000000c52f7c0597efc3c1" Archived-At: Subject: Re: [MLS] [Delivery Service] X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 13:55:23 -0000 --000000000000c52f7c0597efc3c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, it helps, thank you Benjamin ! On Thu, Nov 21, 2019 at 7:34 PM Benjamin Beurdouche < benjamin.beurdouche@inria.fr> wrote: > Hi Pascal ! > > Let me try to explain as best as I can the intended meaning and some of > the MLS goals... > > On Nov 21, 2019, at 5:51 PM, Pascal Junod < > pascalj=3D40snap.com@dmarc.ietf.org> wrote: > > Hi ! > > In the architecture document, one expects the Delivery Service "*to route > messages between clients and to act as a message broadcaster, taking in o= ne > message and forwarding it to multiple clients (also known as =E2=80=9Cser= ver side > fanout=E2=80=9D)..*" (cf. =C2=A72.3) > > At the same time, a bit further, one can read that "*Group membership is > itself sensitive information and MLS is designed so that neither the DS n= or > the AS need have static knowledge of which clients are in which group.*" > > In particular, the ClientInitKey and Welcome messages do not have any > notion about group or node identities, they only have the > client_init_key_id field in common, which means that the DS has no means > (through the current protocol format) to route messages in a proper way. > > How is it possible to solve this apparent contradiction ? > > > The CIK cannot have a notion of group obviously, but the encrypted > GroupInfo of the Welcome message > does contain the GroupID, so on receipt, as a newcomer, you know for whic= h > group this new state is. > > Now, from the architecture perspective=E2=80=A6 > In terms of privacy, one of the good scenarios in modern architectures is > a DS which does not locally maintain > (=E2=80=9Chas static knowledge=E2=80=9D) the group memberships=E2=80=A6 I= n that case, either: > 1. the protocol has to expose the receipient(s) in the message and the DS > can just look at the message itself > 2. the application adds metadata containing a list of recipients which > allows the DS to store a copy > of the message in the correct storage location, notify the users and then > can =E2=80=9Cforget=E2=80=9D who the recipients where. > > There are many alternatives which are left to the provider regarding > privacy but MLS is trying to > allow case 2. for providers that want to achieve it. We definitely have > more work to do on that side, > especially because of the GID itself, but inherently Privacy will rely on > the honesty of the AS and DS, > while Confidentiality and Authentication can rely only on the AS only. > > Hope that helps... : ) > B. > --000000000000c52f7c0597efc3c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, it helps, thank you Benjamin !

On Thu= , Nov 21, 2019 at 7:34 PM Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
Hi Pascal !

Let me try to explain = as best as I can the intended meaning and some of the MLS goals...

On Nov 21, 2019, at 5:51 PM, Pascal Ju= nod <pascalj=3D40snap.com@dmarc.ietf.org> wrote:

Hi !

In the architecture document, one = expects the Delivery Service "to route messages between clients and= to act as a message broadcaster, taking in one message and forwarding it t= o multiple clients (also known as =E2=80=9Cserver side fanout=E2=80=9D).." (cf. =C2=A72.3)

At the same time, a bit f= urther, one can read that=C2=A0"Group membership is itself sensitiv= e information and MLS is designed so that neither the DS nor the AS need ha= ve static knowledge of which clients are in which group."

In particular, the ClientInitKey<= /font> and Welcome messages do not have any= notion about group or node identities, they only have the client_init_key_id field in common, which means that the DS= has no means (through the current protocol format) to route messages in a = proper way.=C2=A0

How is it possible to solve=C2= =A0this apparent contradiction ?

The CIK cannot have a notion of group obviously, but the encrypted GroupI= nfo of the Welcome message
does contain the GroupID, so on receip= t, as a newcomer, you know for which group this new state is.
Now, from the architecture perspective=E2=80=A6
= In terms of privacy, one of the good scenarios in modern architectures is a= DS which does not locally maintain
(=E2=80=9Chas static knowledg= e=E2=80=9D) the group memberships=E2=80=A6 In that case, either:
= 1. the protocol has to expose the receipient(s) in the message and the DS c= an just look at the message itself
2. the application adds = metadata containing a list of recipients which allows the DS to store a cop= y
of the message in the correct storage location, notify the user= s and then can =E2=80=9Cforget=E2=80=9D who the recipients where.

There are many alternatives which are left to the provider = regarding privacy but MLS is trying to
allow case 2. for provider= s that want to achieve it. We definitely have more work to do on that side,=
especially because of the GID itself, but inherently Privacy wil= l rely on the honesty of the AS and DS,
while Confidentiality and= Authentication can rely only on the AS only.

Hope= that helps... : )
B.
<= /div> --000000000000c52f7c0597efc3c1--