From nobody Mon Jun 1 17:33:37 2020 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 AF6683A00B0 for ; Mon, 1 Jun 2020 17:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 gnkYupP0QUrg for ; Mon, 1 Jun 2020 17:33:34 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 236A93A00AD for ; Mon, 1 Jun 2020 17:33:34 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id f89so976312qva.3 for ; Mon, 01 Jun 2020 17:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=0DHlh3JETwQ4PYKD6XwSltxX5hREEPdacMwmWoRVcII=; b=Ej9xiUFKpJwc6fRIYdzbz6LMn0RT/LjfeWcTcgrJ2SPSmXg8mVQdAsujUv3kiWRA9j WGUNvQk4p4yhbg9zdi54GB+UlcM5N6pXvwWC9R+sAnxnKWZIbRAZgEWUpw55/IF1qQkE j3tBGgiR0xryQB4T9iuOlApV8OMtWwicCxZRc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=0DHlh3JETwQ4PYKD6XwSltxX5hREEPdacMwmWoRVcII=; b=feCjPPSxbQCV9K/IATRBNsP+p/jG5EaQ1OfWlmN1FIX0UTq+wz9zVT+0rEZGhm2rkm 7v2Cw6HjCxhXgbMCG5OexWH4T8WytggaFuXmm8XWwwDS6PXji4bW16jnPTcjwL5U/n5o a1yZhe4NP2c/AR1VmZ/Q3WS4lZtdVftrnAwXT87QOlcM6h2HoKFFlznbuKWQvAVoNrVG Qu97wpmLZvy4mq+M9mLJRyqYmQOJt9uHRmogZVGUzQ1pvHaiCTO7QH5P84mCiimPO6qx AhmLNj4R4hWzaR8KIzu+ONaeN8gWeIFOpa/iXSxz/Cmh/HhqDBguxnM5X7bDO3uZxt1U 3Q4w== X-Gm-Message-State: AOAM531kdr+IrmvEWqd3qRjPtoSGuzdhPlIghWH5bUvcgogv2+Z9BHkJ OfxeZbdOdVXkdIMGaROLsHvq7ZnFHUs= X-Google-Smtp-Source: ABdhPJyNs2GvHIfEoQrJrAOE0j+DH9lPFmS5TgI1xpzGZRWkbdnYJ2IE5BWr6kA8y04acLAC0WVTIw== X-Received: by 2002:a0c:b259:: with SMTP id k25mr22650039qve.111.1591058011297; Mon, 01 Jun 2020 17:33:31 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id x66sm858402qkb.33.2020.06.01.17.33.30 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 17:33:30 -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 13.4 \(3608.80.23.2.2\)) Date: Mon, 1 Jun 2020 20:33:29 -0400 References: <158803574083.19043.1196953972603957712@ietfa.amsl.com> To: MLS List In-Reply-To: Message-Id: <9A5C42D2-95E3-4AA3-91F1-6AE9216CE77C@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 00:33:36 -0000 > On May 4, 2020, at 12:23, Sean Turner wrote: >=20 >=20 >=20 >> On Apr 27, 2020, at 21:35, Sean Turner wrote: >>=20 >>=20 >>> On Apr 27, 2020, at 21:02, IETF Meeting Session Request Tool = wrote: >>>=20 >>>=20 >>> A new interim meeting series request has just been submitted by Sean = Turner. >>>=20 >>> This request requires approval by the Area Director of the Security = Area >>>=20 >>> The meetings can be approved here:=20 >>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-12 >>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-13 >>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-14 >>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-15 >>>=20 >>>=20 >>> Meeting: 1 >>> --------------------------------------------------------- >>> Working Group Name: Messaging Layer Security >>> Area Name: Security Area >>> Session Requester: Sean Turner >>>=20 >>> Meeting Type: Virtual Meeting >>>=20 >>> Session 1: >>>=20 >>> Date: 2020-05-05 >>> Start Time: 12:00 America/New_York >>> Duration: 01:00 >>> Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm7822117cbe3d654736b2dbaf0078e353= >>> Agenda Note:=20 >>=20 >> Please note that the first of these interim meeting (the one above) = will be dedicated to key schedule related issues/PRs. >>=20 >> spt >=20 > Just another reminder about our interim tomorrow. We will be focusing = on key schedule related issues/PRs. >=20 > spt Just a reminder that we have another interim tomorrow. spt= From nobody Sun Jun 7 00:51:52 2020 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 32B043A0B44 for ; Sun, 7 Jun 2020 00:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=mnot.net header.b=HqVq0BqJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WdNM3dnO 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 oz-reIqJpyx0 for ; Sun, 7 Jun 2020 00:51:48 -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 6DA263A0B49 for ; Sun, 7 Jun 2020 00:51:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5000A5C007C for ; Sun, 7 Jun 2020 03:32:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 07 Jun 2020 03:32:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=b11VxYWK0o/5lwxX3bj9NW+QpDId0DO4lcWHvsXAhzM=; b=HqVq0BqJ n55Q2twdOCirptgNbrCXkFH0GV36SsXgLzsM77TImHWzMmQ3Xm/8EU3qiE6UTjqk okX51vKyYqiClNohBUk1bYQqEq+t3D36WOc/fIbYpnI8OlXrMmPzNKrIe36mqmAu 4wYnmFD6iB+3j6fCHxkWe9Iii2T2NxNiaAPtLiAmB9jqWOBC59as6QDFuSLttubQ Dt3pDRUY9UPUzZcrDtnEDgRW1geM/10hFPuNNDcPrwycFoXZ8eAYs4haqF6Ctu1r vnyHCD44YoxPREIQjW+QwGyNd/frdHodKSh9vDaVb//ZwKY3E2s8avwrQKPp/Trs eZZmN+gcj+vTEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=b11VxYWK0o/5lwxX3bj9NW+QpDId0 DO4lcWHvsXAhzM=; b=WdNM3dnOc/6sHCq7iVA84rMH1bTK6H5iAqKI11dMqWuNi AKEZ1iy9wmE6J0dhjtVqv+FWjKPjwluXt9j+LQD9oUG0JlV1SqWAObwGj94NnKyN qHtHcYl9KfUZMB/dlHZK5s8dUchm3cwkwZSm+NH+cuMO5SBSRoFwypa0ACLv/DTs AYp7iRdht0UB4U7Y6qx6/EhkAiRiMWYeOVzHW9t19RihQWdBdoWdFn1uaiilL3O6 6pYlyp8i5yxGluZuth/Zf/yP55/hx0G90pr5poiXMwVoWWVG4LPxs9KVPJd6SBGr lEqZZsME9c5BJfBDI01cYQoIzuX47aPx19tpYSQHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegkedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepgedtrdeihedruddufedrud efvdenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [40.65.113.132]) by mail.messagingengine.com (Postfix) with ESMTPA id F2FB930614FA for ; Sun, 7 Jun 2020 03:32:41 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3234092189958691659==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200607073241.F2FB930614FA@mailuser.nyi.internal> Date: Sun, 7 Jun 2020 03:32:41 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) 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: Sun, 07 Jun 2020 07:51:50 -0000 --===============3234092189958691659== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-1/=F0=9F=92=AC2) 1 issues created: - Tree in GroupInfo not optional (by raphaelrobert) https://github.com/mlswg/mls-protocol/issues/344 [functionality] [perfo= rmance]=20 1 issues received 2 new comments: - #298 Varints (2 by Bren2010, bifurcation) https://github.com/mlswg/mls-protocol/issues/298 [enhancement] [perform= ance]=20 1 issues closed: - Redundant information in MLSPlaintextCommitContent https://github.com/m= lswg/mls-protocol/issues/272 [discussion] [performance]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============3234092189958691659== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday June 07, 2020

Issues

mlswg/mls-protocol (+1/-1/=F0=9F=92=AC2)

1 issues created:

1 issues received 2 new comments:

  • #298 Var= ints (2 by Bren2010, bifurcation) enhancement performance <= /li>

1 issues closed:

Repositories tracked by this digest:

--===============3234092189958691659==-- From nobody Tue Jun 9 10:31:54 2020 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 4F0323A0B8A for ; Tue, 9 Jun 2020 10:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (2048-bit key) header.d=aalto.fi 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 Qj0LuFh24xKb for ; Tue, 9 Jun 2020 10:31:50 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (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 A38013A0B67 for ; Tue, 9 Jun 2020 10:31:48 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id F2FDC1155E6_EDFC77FB for ; Tue, 9 Jun 2020 17:31:43 +0000 (GMT) Received: from exng2.org.aalto.fi (exng2.org.aalto.fi [130.233.223.21]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng2.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id 955FE1154A1_EDFC77FF for ; Tue, 9 Jun 2020 17:31:43 +0000 (GMT) Received: from exng7.org.aalto.fi (130.233.223.26) by exng2.org.aalto.fi (130.233.223.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Tue, 9 Jun 2020 20:31:43 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng7.org.aalto.fi (130.233.223.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Tue, 9 Jun 2020 20:31:43 +0300 To: From: Chris Brzuska Message-ID: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> Date: Tue, 9 Jun 2020 20:31:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6DE6494CDDCE855E0C3E470D" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng5.org.aalto.fi (130.233.223.24) To exng7.org.aalto.fi (130.233.223.26) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=to:from:subject:message-id:date:mime-version:content-type; s=its18; bh=DMH1T9FSQtU2+Lpp+FORnty7+S+XWc+eMo20e6r1BXk=; b=Z+PNS7W/hOSnWERANUV+QQ5+65BWYUicyqAWf/qIFPwdzRJhxztYjD6g6HF3Ci5sHROsnNzXYFpPiADJY2Y58BCKwF3luhh6ALUduSgmbWxgL6MQm5pv7avo0OBo7ek3pMPqH9Sj3bGs2H59XSqIMPsdjfzgNEzrOX9mPgCG0mQrc7DYsCZFrYJl7tELsYjarDjKimHOREOSOKPNHcF43NEcejgw78LgY5KSpVPzdQQMP+F40uJcMeKHUypxr7iLUZ742ZN6mucp5fLmoIpxhjitZ3LVDPc7GzMPYzQG6NJTxBlVGeXH5qCaqDK3jKzH1XBmEcK+r1OD9YK6Od5vGA== Archived-At: Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 09 Jun 2020 17:31:52 -0000 --------------6DE6494CDDCE855E0C3E470D Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi all, I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call. The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract. You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail. Please comment/share your opinion. Thanks! Chris (*) commit_secret, PSK and init_secret [1] Pull Request:https://github.com/mlswg/mls-protocol/pull/337 [2] Paper: http://chrisbrzuska.de/2020-NPRF.html *-------------------------------------------------------------------------------------------------------------------- * *Summary of main points:* The current key schedule - uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function - applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value - iterates Extract-then-Expand sequentially to combine more than 2 keys The pull request suggests to - replace the ad-hoc assumption that Extract is a dual pseudorandom function - remove Extract steps when applied after Expand - use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor. Efficiency: - The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1. Assumptions: - HMAC is a standard PRF. - Relies on a unique value, the group_context was suggested. Construction: (1) Use unique value to expand each key and xor the result (2) expand resulting key, including unique value into the context again Security argument: - Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor. - Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent. Variants: - It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats. Questions/Comments that came up: - Barnes, MacMillion suggested group_context as unique value - MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand. - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. --------------6DE6494CDDCE855E0C3E470D Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too.

--------------6DE6494CDDCE855E0C3E470D-- From nobody Thu Jun 11 17:13:59 2020 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 A8C433A0C8B; Thu, 11 Jun 2020 17:13:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mls-chairs@ietf.org, mls@ietf.org, kaduk@mit.edu, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159192083656.6733.8031841527969224889@ietfa.amsl.com> Date: Thu, 11 Jun 2020 17:13:56 -0700 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 108 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, 12 Jun 2020 00:13:57 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack privacypass Key Participant Conflict: acme artarea dispatch perc People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 11 17:15:42 2020 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 88D103A0C8E for ; Thu, 11 Jun 2020 17:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 6PrEF63LJkdm for ; Thu, 11 Jun 2020 17:15:39 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 AABB53A0C8B for ; Thu, 11 Jun 2020 17:15:39 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id d27so5942356qtg.4 for ; Thu, 11 Jun 2020 17:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=QetMFrvFheVHwfMKv3whjvVnwI+tO2K5HniUcaxYMYY=; b=nM7oStkN1vxqJdyUw2zH/liNr+9FFIJXE3KlwiYZlu8sooHQKYB/KAoeNpV6WJpaw7 YZZxTkinrn539cMEllLvV2Ogoz1jLL81gYJcnGn6/wFZPueBhR7VfL0BuG637AgyiThF mkIaEQ6F4kebbBsddgy4sA05/NfV1wemujqiY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=QetMFrvFheVHwfMKv3whjvVnwI+tO2K5HniUcaxYMYY=; b=MH65gzMtEhxCaasKuXO7ldVdl3cNFPt85ms0xl++H68YzdslETGLIdRvmyS7kCI4SI Mra0XoGceOiPn1Edng6Z/UDKYPOe6P+Sa8rFL4PUrBTQ6KTv9oxLMZI+fS3wNbrl4nOT jLxuT/4mi0WE/7u0IZVjz4Guc3ESYs50lezz46d/CtSrnKiosxhCOXv8xBuo3Ze2Qjai waSsFuCt+7zeUQkdqi7NbkzeudqfKxh4qAXV8KZX1mYMGlN+PrGe+pMc5mUC1fxx9eNd T+6qhA7LZBZHoeZCh5yvKcYNGQFak2pmCSH393Ng5C17DQVf05Eyr8w4yb0yL/qTT4D/ 06LQ== X-Gm-Message-State: AOAM5321XOtAkHYl4YqK1SC+sv+6a0gnsGm9Rdh7XlP7JVCXsa6KCXm0 lhqxIl8XajfJSBjGPLyRg/kFvUk/z6k= X-Google-Smtp-Source: ABdhPJzypTBH3zTbg3C6qafigImokHCB7pHo5GXTNjvPn1T5zSQq6qz6PM1deN5y8sgF/SetZux6oA== X-Received: by 2002:aed:3789:: with SMTP id j9mr553531qtb.91.1591920938496; Thu, 11 Jun 2020 17:15:38 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id x66sm3252093qkb.33.2020.06.11.17.15.37 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 17:15:37 -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 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Jun 2020 20:15:37 -0400 References: <159192083656.6733.8031841527969224889@ietfa.amsl.com> To: MLS List In-Reply-To: <159192083656.6733.8031841527969224889@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] mls - New Meeting Session Request for IETF 108 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, 12 Jun 2020 00:15:42 -0000 Hi!=20 I went ahead and requested a session the virtual IETF 108. If we end up = deciding not to use it we can always cancel it if we decide to not use = it. spt > On Jun 11, 2020, at 20:13, IETF Meeting Session Request Tool = wrote: >=20 >=20 >=20 > A new meeting session request has just been submitted by Sean Turner, = a Chair of the mls working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Messaging Layer Security > Area Name: Security Area > Session Requester: Sean Turner >=20 >=20 > Number of Sessions: 1 > Length of Session(s): 50 Minutes > Number of Attendees:=20 > Conflicts to Avoid:=20 > Chair Conflict: cfrg pearg tls quic wpack privacypass >=20 > Key Participant Conflict: acme artarea dispatch perc >=20 >=20 >=20 >=20 >=20 > People who must be present: > Sean Turner > Richard Barnes > Benjamin Kaduk > Nick Sullivan >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 >=20 From nobody Sun Jun 14 00:41:32 2020 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 2213A3A0C8A for ; Sun, 14 Jun 2020 00:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=mnot.net header.b=zY/n21CQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g5xcdETn 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 co1KsSw8QdiQ for ; Sun, 14 Jun 2020 00:41:28 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A333A0A04 for ; Sun, 14 Jun 2020 00:41:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2CE3E42B for ; Sun, 14 Jun 2020 03:33:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 14 Jun 2020 03:33:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=B5Tw2fgn6hTCMeeEIj31K6m8JdQqlUu8Z5RpzPpSFXU=; b=zY/n21CQ +Xc+92uMwZraYrNvu0NOclFTARlqiBQCSjCrstHsNVEYW5je54YuUYFsj8XXwP4L xQjckJy75fP4lg5DDK1vEOxCawbBHQ9KDwHNA+O7CYo05PAf07E99jagJ2Yqg8+T e8KPrV8VZyZ97GfnLHANC9HWnDCI2pu+vKjsBzXH8wOuLR7asjmsfd5wEFk1Mpag hPygG6KSsEXzPjKDtXxzIiwO83tlLC7CyAWZ9Ge9YTZVlejrSnkx3fuWpZkO4N3t abdK06WADbmBVZ7LgFmmwbmM+IZCzriYBJSoeU2j3Xb9hl4keREIO5foN5yDg3kZ AzUdjmAVweaGGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=B5Tw2fgn6hTCMeeEIj31K6m8JdQql Uu8Z5RpzPpSFXU=; b=g5xcdETnq1diMCX9O5hTluuDGVEM5TRaaQcakNbVytIqT GcqgxDInTuWkeun31BSdD1qXXqnDTpvx7D/edeByAQcSRxSo7QSe5n4QGIikBu0Z vchZLxQmXQ84asZtEC0yeS+VO1SLIj8fNnlqJzC3D4uvJ32yEUs3ouAfVoJV8WQO MpaONXJS/9MSLj7SOL8O7NnqELGRm/R3vIW97BgxvQpwy5Bfur89tc5aDUU5gAKP qKG/aJcvnz8q9uwmWQDMrv+99TsSuVlRUFPLGVgMfuUs18UDwFCfKnWcMfOKpOVD 1zIUABJscPVjJLXUGZu9qOKtqsxlRYSrFWMOVDrhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeihedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddukeekrdduiedurd dutdenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az151.internal.cloudapp.net (unknown [52.188.161.10]) by mail.messagingengine.com (Postfix) with ESMTPA id 95AA23060FE7 for ; Sun, 14 Jun 2020 03:33:01 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============1732298086406683049==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200614073301.95AA23060FE7@mailuser.nyi.internal> Date: Sun, 14 Jun 2020 03:33:01 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) 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: Sun, 14 Jun 2020 07:41:30 -0000 --===============1732298086406683049== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC2) 1 issues created: - Ratcheting of External PSKs (by br-hale) https://github.com/mlswg/mls-protocol/issues/346=20 2 issues received 2 new comments: - #346 Ratcheting of External PSKs (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/346=20 - #289 Make Editor's Copy and WG draft compare work properly (1 by bifurc= ation) https://github.com/mlswg/mls-protocol/issues/289 [build]=20 Pull requests ------------- * mlswg/mls-protocol (+3/-2/=F0=9F=92=AC7) 3 pull requests submitted: - Make the tree in the Welcome optional (by bifurcation) https://github.com/mlswg/mls-protocol/pull/348=20 - Explicitly specify which nodes are targeted (by bifurcation) https://github.com/mlswg/mls-protocol/pull/347=20 - no need extra layer of optional in GroupInfo.tree (by yihuang) https://github.com/mlswg/mls-protocol/pull/345=20 3 pull requests received 7 new comments: - #345 no need extra layer of optional in GroupInfo.tree (4 by bifurcatio= n, raphaelrobert, yihuang) https://github.com/mlswg/mls-protocol/pull/345=20 - #337 Replace DKDF by n-PRF in key schedule; minor fix (1 by chris-wood) https://github.com/mlswg/mls-protocol/pull/337 [discussion] [key schedu= le] [security] [work in progress]=20 - #327 Fix bugs in tree math and cleanup docs. (2 by Bren2010, yihuang) https://github.com/mlswg/mls-protocol/pull/327 [editorial] [enhancement= ]=20 2 pull requests merged: - Upper bound for Commit https://github.com/mlswg/mls-protocol/pull/343=20 - Rely More on HPKE https://github.com/mlswg/mls-protocol/pull/338=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============1732298086406683049== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday June 14, 2020

Issues

mlswg/mls-protocol (+1/-0/=F0=9F=92=AC2)

1 issues created:

2 issues received 2 new comments:

Pull requests

mlswg/mls-protocol (+3/-2/=F0=9F=92=AC7)

3 pull requests submitted:

3 pull requests received 7 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============1732298086406683049==-- From nobody Tue Jun 16 07:31:56 2020 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 F0EE53A15BE for ; Tue, 16 Jun 2020 07:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 dpAWGWlnnNYJ for ; Tue, 16 Jun 2020 07:31:53 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1EC3A15B9 for ; Tue, 16 Jun 2020 07:31:52 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id l17so19278026qki.9 for ; Tue, 16 Jun 2020 07:31:52 -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=6CuWf+iUMoRiaCRAjKZYM8dsjeUlc5DnCciCRzMa5j4=; b=VUCFmlkz/MH6lVCZu1fLlMsi7Sfp6QO1fkxFFmWzvg+OlHhnHSwXgjXqZEgfhtpua4 f+6uqNgJzwFBnQKQJ21dvZgbuArr8KbkuBphwFTeYwA8MicYJSgnoVBpIwtwp4HBbqCT ghiOtpvjGKQ9lplhs/TumimtnOGW5ney+T43E28jIH90/vlx2W8mBPZJ3kJxstiVVXhO VGhCzqpoG2iBKUo31lYtuGP/e1AorBPiWRgY5VrM5rEkUHJARFeYn881QL9UH8KzGUZt BtDOObiEF+d5y3TpVKrbNLKCvy/3kbqq4O/a5HZ+pI3rttY3LZBTrBkIyDUXkjMovqxj lGcQ== 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=6CuWf+iUMoRiaCRAjKZYM8dsjeUlc5DnCciCRzMa5j4=; b=MdfGkehIeLVNwgLIs6l8bQL1S58e6weYPSmugGDSqQ/4hyBxgTXoXEz7ELrT0c7Gwc 6EhrN7e+GZX6e1Wtk6joytsD1RueJV/ZVtZGQE+xHenTDtR/t83NSRNI1v5rcZVZRqX8 HUCgdw8cX0gC36HLohNua9cUEjf/sCMVyfyHofoD+UWGc5kEDa+Xwu7GPUf2m9gfUozd JinG3rB6adNukLgxnqNVmFwS9L625gBjNgo+M/7rtg02/dlU6bqdpkymEdYZ0RYZUI9d VKyuZiGVJikKbw8gE6RSwzXv0stYChp8K8Tef/diXe9wm0zMlTr+XqJQZ195kqjetjmu +X7w== X-Gm-Message-State: AOAM533k+4ql2jFEMYr6ZK4FpBAUgQrf0KpdRY77fmZjf0aDEMAmiN7q TcaE82rma/8uagP4Og2BX5gQQQD9y5956UpxLfR+gdyYnGyW7w== X-Google-Smtp-Source: ABdhPJwuYWrwo6KXUUsrAS8uP55thcCU55cJb30fRsPrNFE43Rf9Zr3kXjI0XPGfOBI6h/nxioA7w6zpXnzRDJUv/IM= X-Received: by 2002:a37:79c6:: with SMTP id u189mr20989571qkc.490.1592317906224; Tue, 16 Jun 2020 07:31:46 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Tue, 16 Jun 2020 10:31:30 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000002b9be905a83467c4" Archived-At: Subject: [MLS] Closing some issues 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, 16 Jun 2020 14:31:55 -0000 --0000000000002b9be905a83467c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, Benjamin, Raphael, and I met today to try to triage the MLS protocol issue list, as a step toward burning it down and getting to WGLC. Our main result was to agree to close a bunch of issues :) I=E2=80=99ve summarized = our thinking below. If you disagree, please object on this list in the next couple of days; I=E2=80=99ll probably review feedback and start closing thi= ngs on Friday. In a similar vein, if you have issues you think need to be addressed, get 'em filed, because the WGLC is building steam! Thanks, =E2=80=94Richard #91 User-Initiated Add #271 Create and send to sub-groups #301 Targeted message This has only been partially solved, by the feature that allows new joiners to propose that they be added. The missing part is a =E2=80=9Csend to grou= p from outside=E2=80=9D function. With that, you would have a full, =E2=80=9Cadd = yourself to group=E2=80=9D user experience; as it is, you have to be admitted by someon= e in the group. But we thought that =E2=80=9Csend to group from outside=E2=80=9D wa= s a separate enough piece of work that it could be handled as an add-on spec to the base protocol. Likewise for subgroups / targeted messaging. #118 Discuss DH cofactor issues and Update DH and Elliptic Curve parameters text. This is an issue for HPKE, not for MLS. #222 Performance measurements We tried and failed. #264 Fix inconsistent definitions of Derive-Secret Duplicate of #324 #270 Expiration on "last resort key" must not be omitted This has been fixed, since the lifetime extension is mandatory. #289 Make Editor's Copy and WG draft compare work properly build Katriel has until EOW to fix this, then we=E2=80=99re closing the issue and= giving up. #298 Varints As discussed on the last call, this isn=E2=80=99t enough of a benefit to wo= rry about. Richard might file a PR to uniformize lengths. #299 Allow indirection of credentials This can be done with a new credential type, doesn=E2=80=99t need to be in = the base spec. #346 Ratcheting of External PSKs This is not the job of the base protocol. TLS, for example, has done just fine having PSK considerations in follow-on documents. --0000000000002b9be905a83467c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

Benjamin, Raphael, and I met today to try = to triage the MLS protocol issue list, as a step toward burning it down and= getting to WGLC.=C2=A0 Our main result was to agree to close a bunch of is= sues :) =C2=A0I=E2=80=99ve summarized our thinking below.=C2=A0 If you disa= gree, please object on this list in the next couple of days; I=E2=80=99ll p= robably review feedback and start closing things on Friday.

In a similar vein, if you have issues you think need to be addresse= d, get 'em filed, because the WGLC is building steam!
Thanks,
=E2=80=94Richard

#91 User-Initiated Add
#271 Cr= eate and send to sub-groups
#301 Targeted message
This has only been = partially solved, by the feature that allows new joiners to propose that th= ey be added.=C2=A0 The missing part is a =E2=80=9Csend to group from outsid= e=E2=80=9D function.=C2=A0 With that, you would have a full, =E2=80=9Cadd y= ourself to group=E2=80=9D user experience; as it is, you have to be admitte= d by someone in the group.=C2=A0 But we thought that =E2=80=9Csend to group= from outside=E2=80=9D was a separate enough piece of work that it could be= handled as an add-on spec to the base protocol.=C2=A0 Likewise for subgrou= ps / targeted messaging.

#118 Discuss DH cofactor issues and Update = DH and Elliptic Curve parameters text.
This is an issue for HPKE, not fo= r MLS.

#222 Performance measurements
We tried and failed.

= #264 Fix inconsistent definitions of Derive-Secret
Duplicate of #324
=
#270 Expiration on "last resort key" must not be omitted
T= his has been fixed, since the lifetime extension is mandatory.

#289 = Make Editor's Copy and WG draft compare work properly build
Katriel = has until EOW to fix this, then we=E2=80=99re closing the issue and giving = up.

#298 Varints
As discussed on the last call, this isn=E2=80=99= t enough of a benefit to worry about. =C2=A0 Richard might file a PR to uni= formize lengths.

#299 Allow indirection of credentials
This can b= e done with a new credential type, doesn=E2=80=99t need to be in the base s= pec.

#346 Ratcheting of External PSKs
This is not the job of the = base protocol.=C2=A0 TLS, for example, has done just fine having PSK consid= erations in follow-on documents.
--0000000000002b9be905a83467c4-- From nobody Tue Jun 16 07:47:07 2020 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 79A283A0D89 for ; Tue, 16 Jun 2020 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 SU7bhihD0ucQ for ; Tue, 16 Jun 2020 07:47:05 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A98A3A07DE for ; Tue, 16 Jun 2020 07:47:04 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id b27so19321112qka.4 for ; Tue, 16 Jun 2020 07:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=sJG3p6qMe1RpT6sFeErTp2esMUyMlyIttOG1ne/Xpjw=; b=SkZx9a4epQlyLZC0DXzriRq4m5vvXp3OQ2+myEv9yuILDXZmuDXd+Qgc+jlc/vqmyQ Uou8kzfs7rID/aerB2MME/+RBh9qlxxEFydSBqhQgyK15p1bmhP0i0PaH1GvEsjwMNhh aASjUcsYx9prlmiYL36WZO8YdGMlOO0/aXHQk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=sJG3p6qMe1RpT6sFeErTp2esMUyMlyIttOG1ne/Xpjw=; b=LCgLwz7jbLNVC/1uLkHJ55Ib+wimC6/dFiVETTt/uK5qTuGqm0YAss/z60K3jmAOPe QwxBsM59ToFssmdij6RtYvf7JHgQPnTF1DUl7m8YiaaZiJ/DKicUojYg/n2QdrPs4h+G JVxdTlor/S/MhkS7KNgxPyFRrB1vcDc1k+x4HMnh487EZtkqpTkG/AUuh2SFo+MMrPH3 1VYRYKrqx4YTwGs7yKza+ZaIkT9bzkOWg+1H4CqNr3XsOr2VhvxnPQIu5JPjf0wd07OP rXYNturciFDwdLv72Pc8wYTAQMXpupstthICKzkzEHh1Tjt+DWmJ6qifg11nK0TDOsGj GaSA== X-Gm-Message-State: AOAM5312WJI2Rx0U1sLoXGlWbugiC92gKVpvIf/HQqin5WC233zgnl96 gf0f5fHj3Z1YuVqYYiGWVFz09o8ye1g= X-Google-Smtp-Source: ABdhPJzkGoxJaJ3g0UnOGGkcwmHvsyZRoG3IiUzfdq6o0tcX4x0BZDZV5LqVe6vvexMg/gRyweG96w== X-Received: by 2002:a37:9581:: with SMTP id x123mr20062947qkd.163.1592318823785; Tue, 16 Jun 2020 07:47:03 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id j142sm14421743qke.21.2020.06.16.07.47.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 07:47:03 -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 13.4 \(3608.80.23.2.2\)) Date: Tue, 16 Jun 2020 10:47:02 -0400 References: <158803574083.19043.1196953972603957712@ietfa.amsl.com> <9A5C42D2-95E3-4AA3-91F1-6AE9216CE77C@sn3rd.com> To: MLS List In-Reply-To: <9A5C42D2-95E3-4AA3-91F1-6AE9216CE77C@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 14:47:06 -0000 Just a reminder that there is another interim meeting today in about an = hour. spt > On Jun 1, 2020, at 20:33, Sean Turner wrote: >=20 >=20 >> On May 4, 2020, at 12:23, Sean Turner wrote: >>=20 >>=20 >>=20 >>> On Apr 27, 2020, at 21:35, Sean Turner wrote: >>>=20 >>>=20 >>>> On Apr 27, 2020, at 21:02, IETF Meeting Session Request Tool = wrote: >>>>=20 >>>>=20 >>>> A new interim meeting series request has just been submitted by = Sean Turner. >>>>=20 >>>> This request requires approval by the Area Director of the Security = Area >>>>=20 >>>> The meetings can be approved here:=20 >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-12 >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-13 >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-14 >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-15 >>>>=20 >>>>=20 >>>> Meeting: 1 >>>> --------------------------------------------------------- >>>> Working Group Name: Messaging Layer Security >>>> Area Name: Security Area >>>> Session Requester: Sean Turner >>>>=20 >>>> Meeting Type: Virtual Meeting >>>>=20 >>>> Session 1: >>>>=20 >>>> Date: 2020-05-05 >>>> Start Time: 12:00 America/New_York >>>> Duration: 01:00 >>>> Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm7822117cbe3d654736b2dbaf0078e353= >>>> Agenda Note:=20 >>>=20 >>> Please note that the first of these interim meeting (the one above) = will be dedicated to key schedule related issues/PRs. >>>=20 >>> spt >>=20 >> Just another reminder about our interim tomorrow. We will be focusing = on key schedule related issues/PRs. >>=20 >> spt >=20 > Just a reminder that we have another interim tomorrow. >=20 > spt From nobody Tue Jun 16 08:58:17 2020 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 D66CB3A1716 for ; Tue, 16 Jun 2020 08:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 KYP8ECKWgsBZ for ; Tue, 16 Jun 2020 08:58:14 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 CDD753A1846 for ; Tue, 16 Jun 2020 08:57:33 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id p15so9714701qvr.9 for ; Tue, 16 Jun 2020 08:57: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=R5fX8RrN6I4eG7aFK5ZFrDmjCU1KFlDjzVfXtlzZ/NQ=; b=fnIoyeQ0tTw66p10p+ZTU2ATu8La2hHYyTmQkOC4ATwGV9igYJWUDJ/XtBW4/uaDOl hCo584iqvJpR/RQ3kLSUP6scUzgIkuQiUg7NJP8Z2Rt4gnFkGwYxv40juPc8Tb4JxYPZ LfSJicpObd0wk8iZCS8aj+edB1d21i+60JJffqmk64/efrngfbOh1NeXZd0yVP0P8AM2 sw1twNG3lJ6/alBQwuhs/mgI5qvhbvuNhnnAHdBS/xv/T2zQ8b76tjhzeTnB2WgK5sIl fyemYAJxBO4BreW1tFVhN6OOqNTz8NQ1Vc86uFjfUUIMyJ2Giq6ZEOu74dZJ4OZB4b3m gGpQ== 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=R5fX8RrN6I4eG7aFK5ZFrDmjCU1KFlDjzVfXtlzZ/NQ=; b=OE1IEXrxfX5Nc839RGj6R1uhvm1FjBParAX2NAwk+QjQimb55Z3ow3PL8hETRdP/a4 c48JlwbVZ/JNtGZAB/jxs34b0dwBXWhKsyznwciLiRlt2YdU3SdcIP4oQAUj1kz0wZui R18VNBb6DpcqSqaGS98Uj/UXeHnlTcOLvVwRrIy9JVrH4zZZ/YXGzXqOje64T+2ndlPL c5ayi9il62JqOYNGU7OSFCy85p+wWmzib55e0+BWEgINvkKibFzXKxz5IWhPKxStbVE1 CT2K0Uz04Pn/4fON/+X4CgYvJNhNkiqXXponEwCumQxfK/oQJTxtvpUl0IDY1zh6K4je 5qSA== X-Gm-Message-State: AOAM533eyQTu4egOj4TqTinJF0eTtaDr4myE55as1EVJRHsXzfWZtvC2 hUDwLKQsP8QmuAgOvI7OmK9VqBN6aq+3+RBo4+qwnWxqMq0= X-Google-Smtp-Source: ABdhPJwLec5xKz2S+rET4PAFJWUu/RFd9Mu87sdi8a49TQpoo1gupJXp5aRGsfRLBCZvYgKObbNhAZ26XFP5QNgnOJY= X-Received: by 2002:a0c:8145:: with SMTP id 63mr2856208qvc.60.1592323052504; Tue, 16 Jun 2020 08:57:32 -0700 (PDT) MIME-Version: 1.0 References: <158803574083.19043.1196953972603957712@ietfa.amsl.com> <9A5C42D2-95E3-4AA3-91F1-6AE9216CE77C@sn3rd.com> In-Reply-To: From: Richard Barnes Date: Tue, 16 Jun 2020 11:57:16 -0400 Message-ID: To: Sean Turner Cc: MLS List Content-Type: multipart/alternative; boundary="000000000000e99e5b05a83599a6" Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 15:58:16 -0000 --000000000000e99e5b05a83599a6 Content-Type: text/plain; charset="UTF-8" Sean: Are we going to do another round of these? I think it would probably be useful. On Tue, Jun 16, 2020 at 10:47 AM Sean Turner wrote: > Just a reminder that there is another interim meeting today in about an > hour. > > spt > > > On Jun 1, 2020, at 20:33, Sean Turner wrote: > > > > > >> On May 4, 2020, at 12:23, Sean Turner wrote: > >> > >> > >> > >>> On Apr 27, 2020, at 21:35, Sean Turner wrote: > >>> > >>> > >>>> On Apr 27, 2020, at 21:02, IETF Meeting Session Request Tool < > session-request@ietf.org> wrote: > >>>> > >>>> > >>>> A new interim meeting series request has just been submitted by Sean > Turner. > >>>> > >>>> This request requires approval by the Area Director of the Security > Area > >>>> > >>>> The meetings can be approved here: > >>>> > https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-12 > >>>> > https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-13 > >>>> > https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-14 > >>>> > https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-15 > >>>> > >>>> > >>>> Meeting: 1 > >>>> --------------------------------------------------------- > >>>> Working Group Name: Messaging Layer Security > >>>> Area Name: Security Area > >>>> Session Requester: Sean Turner > >>>> > >>>> Meeting Type: Virtual Meeting > >>>> > >>>> Session 1: > >>>> > >>>> Date: 2020-05-05 > >>>> Start Time: 12:00 America/New_York > >>>> Duration: 01:00 > >>>> Remote Participation Information: > https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 > >>>> Agenda Note: > >>> > >>> Please note that the first of these interim meeting (the one above) > will be dedicated to key schedule related issues/PRs. > >>> > >>> spt > >> > >> Just another reminder about our interim tomorrow. We will be focusing > on key schedule related issues/PRs. > >> > >> spt > > > > Just a reminder that we have another interim tomorrow. > > > > spt > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000e99e5b05a83599a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sean: Are we going to do another round of these?=C2=A0 I t= hink it would probably be useful.

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 16, 2020 at 10:47 AM Sean = Turner <sean@sn3rd.com> wrote:<= br>
Just a reminder = that there is another interim meeting today in about an hour.

spt

> On Jun 1, 2020, at 20:33, Sean Turner <sean@sn3rd.com> wrote:
>
>
>> On May 4, 2020, at 12:23, Sean Turner <sean@sn3rd.com> wrote:
>>
>>
>>
>>> On Apr 27, 2020, at 21:35, Sean Turner <sean@sn3rd.com> wrote:
>>>
>>>
>>>> On Apr 27, 2020, at 21:02, IETF Meeting Session Request To= ol <sessio= n-request@ietf.org> wrote:
>>>>
>>>>
>>>> A new interim meeting series request has just been submitt= ed by Sean Turner.
>>>>
>>>> This request requires approval by the Area Director of the= Security Area
>>>>
>>>> The meetings can be approved here:
>>>> https://dat= atracker.ietf.org/meeting/interim/request/interim-2020-mls-12
>>>> https://dat= atracker.ietf.org/meeting/interim/request/interim-2020-mls-13
>>>> https://dat= atracker.ietf.org/meeting/interim/request/interim-2020-mls-14
>>>> https://dat= atracker.ietf.org/meeting/interim/request/interim-2020-mls-15
>>>>
>>>>
>>>> Meeting: 1
>>>> ---------------------------------------------------------<= br> >>>> Working Group Name: Messaging Layer Security
>>>> Area Name: Security Area
>>>> Session Requester: Sean Turner
>>>>
>>>> Meeting Type: Virtual Meeting
>>>>
>>>> Session 1:
>>>>
>>>> Date: 2020-05-05
>>>> Start Time: 12:00 America/New_York
>>>> Duration: 01:00
>>>> Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=3Dm7822117c= be3d654736b2dbaf0078e353
>>>> Agenda Note:
>>>
>>> Please note that the first of these interim meeting (the one a= bove) will be dedicated to key schedule related issues/PRs.
>>>
>>> spt
>>
>> Just another reminder about our interim tomorrow. We will be focus= ing on key schedule related issues/PRs.
>>
>> spt
>
> Just a reminder that we have another interim tomorrow.
>
> spt

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000e99e5b05a83599a6-- From nobody Tue Jun 16 09:02:00 2020 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 E57553A180D for ; Tue, 16 Jun 2020 09:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 79pnOPe7smtR for ; Tue, 16 Jun 2020 09:01:57 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310FD3A17EE for ; Tue, 16 Jun 2020 09:01:56 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 205so19635110qkg.3 for ; Tue, 16 Jun 2020 09:01:56 -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=fzR5sSEc3luNZR4wpyhIS+fF8Eniuj0jgx0BWayL7dI=; b=N2m7mYdeM66yLFBYczFLYg3zuWTxpnN5/eDGOmeUNdJykR3Rb22sA63XtGkb8nVjUL J9+p3zZzf8OGZuMzIiqpmh0KvNh2IVNYtA/GXSg7uuMBSJDu6NzGtBDzQ+fHDaVnP4Pw UZoYY/WG7pKZ+o7pznL9FVTbuHDGfZKtFNhyk= 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=fzR5sSEc3luNZR4wpyhIS+fF8Eniuj0jgx0BWayL7dI=; b=TLx97Se2xQy1x5uKHVnFUnALcu1eeW6jsikQKi3zWBnlUh8cOQWlj/KqjT2QjLvbIy A+BCbNvUcqwGFlr/6dmvSx0GhJPEwAtnLkF+R3x4/6MSsTWOmDCCQWtFleTKF0MTsfks 1/9d84vOjWJOZvyrktsG4JQ34wkXPVHE2IOWQxH46FwC0V5CbRYyPnPQN4UGMmp1VHKx PQQ5zU2X/ZrVgQ1T/nJjBx077gUVyqAZgyChyUHZJAWKT467iMPQBTr5kVl1R3Y8P9m+ 4LoUkPkNWqsAfZBM5oyW8niKhIKhg4p4HAUHrim8EVFqPt/n6t7u4kjCFA0DvT22dh/K +W3A== X-Gm-Message-State: AOAM530GpiRtAiXCNIFjiQbVr7feyBiOlankbDrs4g89tsEFbtU5tmP0 oJc+MtLspVuNpC2PaImZU7ivN9PCfwI= X-Google-Smtp-Source: ABdhPJxSkan9tPEU6nu3Z2YkWc/pTb4lDbMdai3F2QehJXcewFLxpd5QbofFkm31AOYEh92pCatljA== X-Received: by 2002:a37:b50:: with SMTP id 77mr21193804qkl.152.1592323316006; Tue, 16 Jun 2020 09:01:56 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id x4sm15908465qtj.43.2020.06.16.09.01.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 09:01:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Sean Turner In-Reply-To: Date: Tue, 16 Jun 2020 12:01:54 -0400 Cc: MLS List Content-Transfer-Encoding: quoted-printable Message-Id: References: <158803574083.19043.1196953972603957712@ietfa.amsl.com> <9A5C42D2-95E3-4AA3-91F1-6AE9216CE77C@sn3rd.com> To: Richard Barnes X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 16:01:59 -0000 I had not scheduled them. There is one today: 16 June 2020. spt > On Jun 16, 2020, at 11:57, Richard Barnes wrote: >=20 > Sean: Are we going to do another round of these? I think it would = probably be useful. >=20 > On Tue, Jun 16, 2020 at 10:47 AM Sean Turner wrote: > Just a reminder that there is another interim meeting today in about = an hour. >=20 > spt >=20 > > On Jun 1, 2020, at 20:33, Sean Turner wrote: > >=20 > >=20 > >> On May 4, 2020, at 12:23, Sean Turner wrote: > >>=20 > >>=20 > >>=20 > >>> On Apr 27, 2020, at 21:35, Sean Turner wrote: > >>>=20 > >>>=20 > >>>> On Apr 27, 2020, at 21:02, IETF Meeting Session Request Tool = wrote: > >>>>=20 > >>>>=20 > >>>> A new interim meeting series request has just been submitted by = Sean Turner. > >>>>=20 > >>>> This request requires approval by the Area Director of the = Security Area > >>>>=20 > >>>> The meetings can be approved here:=20 > >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-12 > >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-13 > >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-14 > >>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-15 > >>>>=20 > >>>>=20 > >>>> Meeting: 1 > >>>> --------------------------------------------------------- > >>>> Working Group Name: Messaging Layer Security > >>>> Area Name: Security Area > >>>> Session Requester: Sean Turner > >>>>=20 > >>>> Meeting Type: Virtual Meeting > >>>>=20 > >>>> Session 1: > >>>>=20 > >>>> Date: 2020-05-05 > >>>> Start Time: 12:00 America/New_York > >>>> Duration: 01:00 > >>>> Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm7822117cbe3d654736b2dbaf0078e353= > >>>> Agenda Note:=20 > >>>=20 > >>> Please note that the first of these interim meeting (the one = above) will be dedicated to key schedule related issues/PRs. > >>>=20 > >>> spt > >>=20 > >> Just another reminder about our interim tomorrow. We will be = focusing on key schedule related issues/PRs. > >>=20 > >> spt > >=20 > > Just a reminder that we have another interim tomorrow. > >=20 > > spt >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Jun 17 15:54:37 2020 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 51D4F3A090A for ; Wed, 17 Jun 2020 15:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 ifqzWpi61tGm for ; Wed, 17 Jun 2020 15:54:34 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 6581D3A08F8 for ; Wed, 17 Jun 2020 15:54:33 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id g28so3796885qkl.0 for ; Wed, 17 Jun 2020 15:54:33 -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=07ef65sj+xDFa5dV7JsMRVhGWU2wzenulYK6oz7ygRE=; b=p3Bi6RGzBcfXHxL/1ltP6qlM6UrdZTHh9YpNlh72UyZY4LgHcw2WbG4nkt+REHVOc6 qlOCF+DtVKkxktGIqS8gYiZKCJT+HztjUFO+89Guxh+e/Utae1PbNIIRuL4u7AQxNc+0 k5IqqEZNRjedI75cD/YYu4DvzVA/yeN5g+G/ELtUJKrGyG5sdN8kOzSZmw1lXKM0oGbL kpR1tIb6ZjLZ5fxIjBqMPuK3xa+7woE63Piyvxt5eE4o/oumNJbAPw39kVrh9F8bFLgb Xkl5GFECb49lnNYYk3py0vtgUSHTj06k42TcRgAcMUK4I0DN412RUvQaSsfi4mFie94H t3Fg== 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=07ef65sj+xDFa5dV7JsMRVhGWU2wzenulYK6oz7ygRE=; b=hCdrydvpLifJV/xF7BTPFri+tckJHFOy1uPhjZbfMfyGwKOi86oC7JNCoZAFyrevqA DHCfxgfL3CmhaKFoTG+P0wnYREgvvMaA3wQHr3kgC6TlThcmxPNTfD9gDFfhqBdiIUU1 h7tHuqIM3lLm8jsVUFHW9KsvE0JFmn6tLWhvcL/V7b3tKcVXWUZ8B64fI3HvzcgPr4F5 HIN6R512YJcMGd3Qa53fgXxh88F4YcrP8gpwtRYemR9IZbhkKPIAm2JiCoNgoKkFADHF NPRuTjg7+qEquGlU0IL0TLiZXFbGnBefyHfhn6zX645AVWWNYXNGELn+kxuKhydO746q zk/Q== X-Gm-Message-State: AOAM530bfC2TldmB8KeAf0HJ7QXiK4CQ/Znc35/deNb8QmjfqwGmpmJN IKAX2BcyNXv/RbpX629EpxMVg6Gp271G8SCueqZJzdeiRH/nsQ== X-Google-Smtp-Source: ABdhPJyzs3AS4prYBGTK6N5PchR1Ibu88OKwbkJleD23pTXn3iwtjCYesnACt12gBVlz925j05tWyQb571mfRxt17Tw= X-Received: by 2002:a37:4a85:: with SMTP id x127mr932420qka.159.1592434472444; Wed, 17 Jun 2020 15:54:32 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Wed, 17 Jun 2020 18:54:16 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000000ef7b805a84f8bf0" Archived-At: Subject: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) 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, 17 Jun 2020 22:54:36 -0000 --0000000000000ef7b805a84f8bf0 Content-Type: text/plain; charset="UTF-8" Hey all, Sorry for the late review on this PR, I have finally gotten a chance to really dig into it, and ... I have some concerns. My current thinking is consistent with my earlier comments that the general thrust of this PR is OK. But I think the actual approach needs to change a fair bit. As its title implies, this PR is trying to do several things at once, which seem to me to be fairly separable: 0. Update the key schedule so that PSKs are injected at the right point and multiple PSKs are supported 1. Signal that a PSK should get injected into a given epoch 2. Request injection of PSK at join / in Welcome 3. Re-initialize the group with different parameters 4. Re-sync group members that have lost state For the most part, I think these are worthwhile goals, but they should be accomplished in different ways than the PR proposes. Detailed thoughts by objective: # 0. Update the key schedule so that PSKs are injected at the right point and multiple PSKs are supported This part of the PR is fine, but I think is ultimately done a bit more elegantly with the n-PRF stuff in #337. # 1. Signal that a PSK should get injected into a given epoch # 2. Request injection of PSK at join / in Welcome (These go together) The PR proposes (heh) an EPSK proposal or an Add proposal, but then requires that only one EPSK be used. I actually don't the proposal for including PSKs in Adds actually works. The joiner would have to know all of them plus the EPSK, and there's not even any syntax in the PR to tell the joiner which ones to include. I would propose that instead we add an extensions field to the Commit message, then add a Commit extension that specifies the PSK ID for the PSK to be added. That extension can then also go in the Welcome message corresponding to the commit, so that joiners know to add the PSK. This change actually doesn't make a difference in terms of what ends up in the transcript -- either way, only the PSK ID selected by the committer goes in the transcript. It seems better not to deliberately have proposals floating around that never get included in the transcript. # 3. Re-initialize the group with different parameters The PR proposes another proposal type for reinitialization, but it's really under-specified what you do to re-init. For example, what goes in the ratchet tree? Clearly you need a brand new tree, since the one you have might be tied to the wrong ciphersuite. What you really need is something like a Welcome message. And that's how I think we should actually arrange things. Instead of having the parent group do something to spawn, have the initiator of the child send a Welcome that has a pointer back to the parent. So we have another Welcome extension (`parent_group`, say) that has a pointer to the parent group by group ID and epoch, and instructs the joiner to take a secret from that group/epoch's key schedule and add it into the new group's key schedule. # 4. Re-sync group members that have lost state We should not do these. At the January interim, we decided not to drop the resync issue (#93) given that there were some subtleties depending on exactly what state had been lost, and that it could be cleanly done in a separate spec. # Conclusions Given the above, I would propose we break this into separate issues to be closed with individual, smaller PRs. Assuming that (0) will get addressed by the n-PRF PR, that leaves us with: #XXX Add Extensions to the Commit message #XXX Signal use of external PSKs in Commit/Welcome (=> extension to Commit/Welcome messages) #XXX Allow Welcome to signal the inclusion of information from a prior group (=> Welcome extension) Happy to write those up, and contribute to PRs. Sorry again for the slow progress here. --Richard --0000000000000ef7b805a84f8bf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

Sorry for the late review on this PR, I ha= ve finally gotten a chance to really dig into it, and ... I have some conce= rns.=C2=A0 My current thinking is consistent with my earlier comments that = the general thrust of this PR is OK.=C2=A0 But I think the actual approach = needs to change a fair bit.

As its title implies, this PR is trying = to do several things at once, which seem to me to be fairly separable:
<= br>0. Update the key schedule so that PSKs are injected at the right point = and multiple PSKs are supported
1. Signal that a PSK should get injected= into a given epoch
2. Request injection of PSK at join / in Welcome
= 3. Re-initialize the group with different parameters
4. Re-sync group me= mbers that have lost state

For the most part, I think these are wort= hwhile goals, but they should be accomplished in different ways than the PR= proposes.=C2=A0 Detailed thoughts by objective:


# 0. Update the= key schedule so that PSKs are injected at the right point and multiple PSK= s are supported

This part of the PR is fine, but I think is ultimate= ly done a bit more elegantly with the n-PRF stuff in #337.


# 1. = Signal that a PSK should get injected into a given epoch
# 2. Request in= jection of PSK at join / in Welcome

(These go together)

The P= R proposes (heh) an EPSK proposal or an Add proposal, but then requires tha= t only one EPSK be used.=C2=A0 I actually don't the proposal for includ= ing PSKs in Adds actually works.=C2=A0 The joiner would have to know all of= them plus the EPSK, and there's not even any syntax in the PR to tell = the joiner which ones to include.

I would propose that instead we ad= d an extensions field to the Commit message, then add a Commit extension th= at specifies the PSK ID for the PSK to be added.=C2=A0 That extension can t= hen also go in the Welcome message corresponding to the commit, so that joi= ners know to add the PSK.

This change actually doesn't make a di= fference in terms of what ends up in the transcript -- either way, only the= PSK ID selected by the committer goes in the transcript.=C2=A0 It seems be= tter not to deliberately have proposals floating around that never get incl= uded in the transcript.


# 3. Re-initialize the group with differ= ent parameters

The PR proposes another proposal type for reinitializ= ation, but it's really under-specified what you do to re-init.=C2=A0 Fo= r example, what goes in the ratchet tree?=C2=A0 Clearly you need a brand ne= w tree, since the one you have might be tied to the wrong ciphersuite.=C2= =A0 What you really need is something like a Welcome message.

And th= at's how I think we should actually arrange things.=C2=A0 Instead of ha= ving the parent group do something to spawn, have the initiator of the chil= d send a Welcome that has a pointer back to the parent.=C2=A0 So we have an= other Welcome extension (`parent_group`, say) that has a pointer to the par= ent group by group ID and epoch, and instructs the joiner to take a secret = from that group/epoch's key schedule and add it into the new group'= s key schedule.



# 4. Re-sync group members that have lost st= ate

We should not do these.=C2=A0 At the January interim, we decided= not to drop the resync issue (#93) given that there were some subtleties d= epending on exactly what state had been lost, and that it could be cleanly = done in a separate spec.


# Conclusions

Given the above, = I would propose we break this into separate issues to be closed with indivi= dual, smaller PRs.=C2=A0 Assuming that (0) will get addressed by the n-PRF = PR, that leaves us with:

#XXX Add Extensions to the Commit message#XXX Signal use of external PSKs in Commit/Welcome (=3D> extension to = Commit/Welcome messages)
#XXX Allow Welcome to signal the inclusion of i= nformation from a prior group (=3D> Welcome extension)

Happy to w= rite those up, and contribute to PRs.=C2=A0 Sorry again for the slow progre= ss here.

--Richard
--0000000000000ef7b805a84f8bf0-- From nobody Wed Jun 17 18:07:44 2020 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 F3B433A094E for ; Wed, 17 Jun 2020 18:07:41 -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, 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 PA8ykFTvC5ej for ; Wed, 17 Jun 2020 18:07:39 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id CF3C03A094A for ; Wed, 17 Jun 2020 18:07:39 -0700 (PDT) X-ASG-Debug-ID: 1592442457-0e394572da17f80001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id Q7jFIISHUVx10yzV; Wed, 17 Jun 2020 18:07:37 -0700 (PDT) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from skywalker.ern.nps.edu (172.20.4.117) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Wed, 17 Jun 2020 18:07:37 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.51) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Wed, 17 Jun 2020 18:07:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AgOEZ8gdx5SurMNK3XOkCer7RzypmIGYkYtUhUYcGi1Gz1zpyExqypfMJCs57kZET1ZS8sflp7g9wDJY38y6hNwsTJJyy9vx/qRD6bLITYMBcq/1NikHulot/4l4lWVoQIvPB4HRr/lpFmD+GuOXTR24L4ih4r2/kdrXD4jykpk9qirrt1t2s4E6Jis91LmhcDPlGii/l1jlGdnCSI/XWsd+B3bHbKtZItkB8lkGkAr7gAkixl9cNcz2QXR/wvhGafiOzicbmTgHy6QcXnas/+B7E7l7s7pPV14UxeLvL5E7g3z5f7mQ9ihANifbmymyP0mbd1OZ2hPkdVeLgoH3xQ== 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=+znb1D5giYQbspNKRdYvTygCRM6B6Qwtr1+d3oT8vxk=; b=FB8EtRhpAKXWTr2ddtBBFjmS7A+UHlNWkNRxIjYby+8w7yh23nS9XbXhAcOd5fEEq1ATCibtPddIAtGca65p6UsZhZladszbQFfx9nlltFAeAihX/JMMZij1DPXKC4FUvd9nnF8YJxMUq+FXu/Z7A+g7CoGEBYSNXavH3g6OkM58Dm5VqJ6ygrfEm6bdLtxRU90QZXnuyxvZkFfqXmrW/vKHNwxvt1TDuXyicptVb2PTzreL1fypF0tXmiryBsD5OYE6bX3KAz41sJiDehpkKmRsGu8WIzHRhu85H1vjdqxBfdXiIPQwirPtUV9kBgS2Ym2QUCM2cC8jV8mxOqJWlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BYAPR13MB2470.namprd13.prod.outlook.com (2603:10b6:a02:bd::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.15; Thu, 18 Jun 2020 01:07:36 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::cc82:a6a7:32b1:be38]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::cc82:a6a7:32b1:be38%6]) with mapi id 15.20.3131.009; Thu, 18 Jun 2020 01:07:36 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a02:bd::18] X-Barracuda-Apparent-Source-IP: 2603:10b6:a02:bd::18 From: "Hale, Britta (CIV)" To: Richard Barnes , Messaging Layer Security WG Thread-Topic: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) X-ASG-Orig-Subj: Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) Thread-Index: AQHWRPpKgd3HuS0F70KUZ1R3ixejz6jdGmaA Date: Thu, 18 Jun 2020 01:07:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.16.200509 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=nps.edu; x-originating-ip: [2601:647:cb00:2941:f5f3:50f0:7080:5702] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b623d86-97bc-4d32-9bb5-08d81323fcf7 x-ms-traffictypediagnostic: BYAPR13MB2470: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Nqm85Z0FcsUpg9/H6bcjFUMI2iG5dW9rUaKCWozFx7bgUYkm0TNRPp4DlGOfUfDoyFX1LWGeO18lGn+HlnfnHAl6BOllUoPP1IGzvmWucT+kaZwxF1AP3IwqPFENUDaNq9dMQvFzeBCLMHUs3NK7t58DZnqHyiXMymhyHCSaeCFgbcVt2iva/eBxfq/UpVv6u3xlLMP+Mu0YPf5JlWrR5oNDdNcpOOA+lr8/Df9XxjJMzoVRsL9hw9uqEbxupPM02PVzSXVkcCDRPDqj5qL0b7uKJDRMPssQtccDsoTg6DhC7fpapNwEllG+cAaFgISRai7D9GLDlM6rHycbD5kZiR9Sul1nuB+c4JaTBPj81FljW+vznm5OfqZiQrEjnm3T x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3013.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39850400004)(136003)(376002)(346002)(75432002)(83380400001)(5660300002)(33656002)(2906002)(8936002)(6512007)(2616005)(76116006)(66556008)(86362001)(64756008)(66446008)(71200400001)(53546011)(186003)(9326002)(110136005)(316002)(36756003)(478600001)(66946007)(786003)(66476007)(6506007)(6486002)(8676002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Hvl3l5Ix1yEw0xGXkHb0VK/3280idvk21kpV7HVS37+E4vwkHYHPqYeItp8EFS7OOfGgTdG4kUuNdmU+7saq7NqrZpyD/xZ+lWedPiA23116T1m93dlrDCdkkxuuNQ2F0bcVdK8z7KHuJOLXB/5kaN0GXciDYtpq/9XhT3lKXM/6uR5ZhwXdWY+5jIdrST8TyoVPYUdU4ln4z8mus84dEWSRXtkZipetIIj7P4hNXk1JI3MWyocEb9AGEmcKvoucez1pbZQi+GcN6G2ajsZYY6BxCce08UpQkFIgPq9ka7M5gLoq7EaZnJgzyWStPAE4sGDJgdnHu1KHFbGxvteS+0F4vNJUelw/BFHBYnI+QpfjRVINXA9UumllCcMMfjVTuO34wa9OOkdtHQyh7HwXs+un21uFvroCjxO8p/xqBpsTlkNdtRpv2TpGW6l/w4WRNJgux1x36ymkVNEcQQVUsbd7q7Tq/UnxAuZs8p/6h7akxADB98cp9hgHdVpyLXexFF1Zi7mUyMCHpGEscFLyXYGyjTLi5wLtj/s3e3pVXefKtM8kFHUTqyZ5upJIqzgX x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BFD5B4F7361741AD811FC6C49A803983npsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9b623d86-97bc-4d32-9bb5-08d81323fcf7 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 01:07:35.9595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C9xinP355bbw5I42NcbbPMzxS9fgj55VFUCoLgRqkjgCi3NaU3j2Vip20PNIlLIySSjApfUz6sbD+BwO4LwNYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2470 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1592442457 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 17105 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.82626 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) 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, 18 Jun 2020 01:07:42 -0000 --_000_BFD5B4F7361741AD811FC6C49A803983npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMgYW5kIGNhcmVmdWwgcmVh ZCBvZiB0aGUgUFIuDQoNCkZvciAjMS8jMjogSSBhbSBhbWljYWJsZSB0byB0aGUgaWRlYSBvZiBh ZGRpbmcgYW4gZXh0ZW5zaW9uIGZpZWxkIHRvIHRoZSBjb21taXQgbWVzc2FnZS4gQXMgYSBnZW5l cmFsIGNvbW1lbnQsIHdlIG1heSB3YW50IHRvIGNvbnNpZGVyIGlmIHRoZXJlIGFyZSBvdGhlciB0 eXBlcyBvZiBjb21taXQgZXh0ZW5zaW9ucyB3b3J0aCBhZGRpbmcgb3IsIGFsdGVybmF0aXZlbHks IGhvdyB0aGUgZmllbGQgbWF5IGJlIGFidXNlZCAoZS5nLiB0cmVhdGVkIGFzIEFEIGJ5IGFuIGFw cGxpY2F0aW9uKS4NCkl0IHRlcm1zIG9mIG9iamVjdGlvbiB0byB0aGUgY3VycmVudCBmb3JtIHRo b3VnaCwgeW91ciBhcmd1bWVudCBpcyBub3QgY2xlYXIuIFBTS0lkcyBzaG91bGQgdW5pcXVlbHkg aWRlbnRpZnkgUFNLcywgYW5kIGEgam9pbmVyIChvciBhbnlvbmUpIHNob3VsZCBiZSBhYmxlIHRv IGlkZW50aWZ5IHRoZSBjb3JyZWN0IFBTSyBnaXZlbiB0aGUgUFNLSWQsIGlmIHRoZXkgYXJlIGlu IHBvc3Nlc3Npb24gb2YgaXQuIFBTS3MgbXVzdCBvbmx5IGJlIHVzZWQgaW4gYW4gQWRkIGlmIHRo ZSBqb2luZXIgaXMgYSBwYXN0IGdyb3VwIG1lbWJlciAobGluZSAyMDU1KSBhbmQgdGhlcmVmb3Jl IGhhcyB0aGUgY29ycmVjdCBQU0tJZC9ncm91cF9pZC9wc2tfZXBvY2gsIGFsdGhvdWdoIHRoaXMg aXMgbnVsbGlmaWVkIGlmIHdlIG1ha2UgdGhlIGNoYW5nZSBkaXNjdXNzZWQgaW4gIzQuIEluIHRo YXQgY2FzZSwgdGhlIGlzc3VlIGZvciBBZGRzIGdvZXMgYXdheS4NClRoZSBQUiBhbHJlYWR5IGFs bG93cyBmb3IgYSBQU0sgaW4gdGhlIFdlbGNvbWUgbWVzc2FnZS4NCg0KRm9yICMzOiBDdXJyZW50 bHksIGluIHRoZSBQUiwgdGhlcmUgaXMgYSByZWNvdmVyeV9zZWNyZXQgZGVyaXZlZCBwZXItZXBv Y2guIFdoZW4gYSBtZW1iZXIgd2FudHMgdG8gcmUtaW5pdGlhbGl6ZSwgdGhleSBpc3N1ZSBhIFJl LUluaXQgcHJvcG9zYWwuIFRoZXkgbWF5IHRoZW4gcmUtaW5pdGlhbGl6ZSB0aGUgZ3JvdXAgYnkg c2VuZGluZyBhIFdlbGNvbWUgbWVzc2FnZSAoc2VlIGxpbmVzIDE5MjMsIDE5NDgsIGFuZCAyMzQ5 KSB3aXRoIHRoZSBQU0tJZCBmb3IgdGhlIHBhcmVudCBncm91cC9lcG9jaCBhbmQgYSBwc2t0eXBl IHRoYXQgaW5kaWNhdGVzIHRoYXQgdGhleSBhcmUgcmUtaW5pdGlhbGl6aW5nIHRoZSBncm91cCB3 aXRoIHRoZSBzdGF0ZWQgUFNLSWQuIFNvIHRoaXMgc2VlbXMgdG8gYWxyZWFkeSBiZSB3aGF0IHlv dSBkZXNjcmliZSBiZWxvdyBhcyDigJxoYXZlIHRoZSBpbml0aWF0b3Igb2YgdGhlIGNoaWxkIHNl bmQgYSBXZWxjb21lIHRoYXQgaGFzIGEgcG9pbnRlciBiYWNrIHRvIHRoZSBwYXJlbnTigJ0uIEhv d2V2ZXIsIHlvdSBhcmUgcmlnaHQgdGhhdCBtb3JlIGRldGFpbCBjYW4gYmUgYWRkZWQ7IGluIHBh cnRpY3VsYXIgYSByZXF1aXJlbWVudCBzaG91bGQgYmUgYWRkZWQgdG8gdGVybWluYXRlIHRoZSBw YXJlbnQgZ3JvdXAgYW5kIHRoYXQgdGhlIHRlcm1pbmF0aW5nIG1lbWJlci9yZS1pbml0IHByb3Bv c2VyIG11c3QgYWxzbyBjcmVhdGUgdGhlIG5ldyBncm91cC4NCg0KRm9yICM0OiBUaGVyZSB3YXMg YSBkaXNjdXNzaW9uIGF0IHRoZSBmaXJzdCB2aXJ0dWFsIGludGVyaW0gaW4gbGF0ZSBBcHJpbCAo SW50ZXJpbSAjMTEtMjAyMCkgd2hlcmVpbiBzb21lIGV4cHJlc3NlZCBhIGRlc2lyZSBmb3IgdGhp cyBmZWF0dXJlLiBOYW1lbHksIGluc3RlYWQgb2YgcmUtc3luY2luZyB0aGUgZW50aXJlIGdyb3Vw LCB0aGVyZSB3ZXJlIHVzZSBjYXNlcyBmb3IgcmUtc3luY2luZyB0aGUgb2RkIG1lbWJlciB3aGVu IG5lY2Vzc2FyeS4gSXRzIGluY2x1c2lvbiBpbiB0aGUgUFIgYXJpc2VzIGZyb20gdGhhdCBsYXRl ciByZXF1ZXN0LiBJIGFtIGZhdm9yYWJsZSB0byByZW1vdmluZyBpdCBzaW5jZSwgZnJvbSBzZWN1 cml0eSBzdGFuZHBvaW50LCBpdCBpcyBub3QgaWRlYWwuIEhvd2V2ZXIsIHRoZSBtb3RpdmF0aW9u IGZvciB0aGlzIHdhcyBwdXNoZWQgZnJvbSB0aGUgaW1wbGVtZW50YXRpb24gc3RhbmRwb2ludC4g Q29uc2VxdWVudGx5LCBub3cgaXMgYSBnb29kIHRpbWUgZm9yIGFueW9uZSB0byBzcGVhayB1cCB3 aG8gd2FudHMgdG8gcHVzaCBmb3IgdGhpcy4NCg0KDQpPbmUgaXRlbTogeW91IG1hZGUgcG9pbnQg b2Ygc3BlY2lmaWNhbGx5IHJlcXVlc3Rpbmcg4oCTIGEgZmV3IHRpbWVzIOKAkyBhdCB0aGUgdmly dHVhbCBpbnRlcmltcyAjMTEgYW5kICMxMiBpbiBBcHJpbC9NYXkgdGhhdCB0aGlzIFBTSyBQUiBh bmQgYXMgbWFueSBvdGhlciBrZXkgc2NoZWR1bGUtcmVsYXRlZCBQUnMgYmUgY29tYmluZWQgaW50 byBhIHNpbmdsZSBvbmUuIFJhcGhhZWwgbWFkZSBhIHNpbWlsYXIgcmVxdWVzdCB1bmRlciBnaXQg aXNzdWUgIzMyNS4gSW4gZmFjdCwgdGhlIGF1dGhvcnMgb2YgdGhpcyBQUiBoYWQgcHVzaGVkIGJh Y2sgb24gdGhhdCBpbnNpc3RlbmNlIHRvIGxpbWl0IHRoZSBjdXJyZW50IFBSIGRvd24gdG8gdGhl IGl0ZW1zIGl0IGN1cnJlbnRseSBjb3ZlcnMsIGluc3RlYWQgb2YgbWVyZ2luZyBpbiBvdGhlciBr ZXkgc2NoZWR1bGUgY2hhbmdlcyBhcyB3ZWxsLiBBcmUgeW91IHNheWluZyB0aGF0IHlvdSBoYXZl IGNoYW5nZWQgeW91ciBtaW5kPw0KV2UgY2FuLCBvZiBjb3Vyc2UsIGFjY29tbW9kYXRlIGEgcmV2 aXNlZCBwcmVmZXJlbmNlIGlmIG5lZWRlZC4NCg0KDQpCcml0dGENCg0KDQoNCkZyb206IE1MUyA8 bWxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlw di5zeD4NCkRhdGU6IFdlZG5lc2RheSwgSnVuZSAxNywgMjAyMCBhdCAzOjU0IFBNDQpUbzogTWVz c2FnaW5nIExheWVyIFNlY3VyaXR5IFdHIDxtbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTUxTXSBQ U0sgSW5qZWN0aW9uLCBHcm91cCByZWNvdmVyeSwgUmUtSW5pdCwgU3ViLWdyb3VwIEJyYW5jaGlu ZyAoIzMzNikNCg0KSGV5IGFsbCwNCg0KU29ycnkgZm9yIHRoZSBsYXRlIHJldmlldyBvbiB0aGlz IFBSLCBJIGhhdmUgZmluYWxseSBnb3R0ZW4gYSBjaGFuY2UgdG8gcmVhbGx5IGRpZyBpbnRvIGl0 LCBhbmQgLi4uIEkgaGF2ZSBzb21lIGNvbmNlcm5zLiAgTXkgY3VycmVudCB0aGlua2luZyBpcyBj b25zaXN0ZW50IHdpdGggbXkgZWFybGllciBjb21tZW50cyB0aGF0IHRoZSBnZW5lcmFsIHRocnVz dCBvZiB0aGlzIFBSIGlzIE9LLiAgQnV0IEkgdGhpbmsgdGhlIGFjdHVhbCBhcHByb2FjaCBuZWVk cyB0byBjaGFuZ2UgYSBmYWlyIGJpdC4NCg0KQXMgaXRzIHRpdGxlIGltcGxpZXMsIHRoaXMgUFIg aXMgdHJ5aW5nIHRvIGRvIHNldmVyYWwgdGhpbmdzIGF0IG9uY2UsIHdoaWNoIHNlZW0gdG8gbWUg dG8gYmUgZmFpcmx5IHNlcGFyYWJsZToNCg0KMC4gVXBkYXRlIHRoZSBrZXkgc2NoZWR1bGUgc28g dGhhdCBQU0tzIGFyZSBpbmplY3RlZCBhdCB0aGUgcmlnaHQgcG9pbnQgYW5kIG11bHRpcGxlIFBT S3MgYXJlIHN1cHBvcnRlZA0KMS4gU2lnbmFsIHRoYXQgYSBQU0sgc2hvdWxkIGdldCBpbmplY3Rl ZCBpbnRvIGEgZ2l2ZW4gZXBvY2gNCjIuIFJlcXVlc3QgaW5qZWN0aW9uIG9mIFBTSyBhdCBqb2lu IC8gaW4gV2VsY29tZQ0KMy4gUmUtaW5pdGlhbGl6ZSB0aGUgZ3JvdXAgd2l0aCBkaWZmZXJlbnQg cGFyYW1ldGVycw0KNC4gUmUtc3luYyBncm91cCBtZW1iZXJzIHRoYXQgaGF2ZSBsb3N0IHN0YXRl DQoNCkZvciB0aGUgbW9zdCBwYXJ0LCBJIHRoaW5rIHRoZXNlIGFyZSB3b3J0aHdoaWxlIGdvYWxz LCBidXQgdGhleSBzaG91bGQgYmUgYWNjb21wbGlzaGVkIGluIGRpZmZlcmVudCB3YXlzIHRoYW4g dGhlIFBSIHByb3Bvc2VzLiAgRGV0YWlsZWQgdGhvdWdodHMgYnkgb2JqZWN0aXZlOg0KDQoNCiMg MC4gVXBkYXRlIHRoZSBrZXkgc2NoZWR1bGUgc28gdGhhdCBQU0tzIGFyZSBpbmplY3RlZCBhdCB0 aGUgcmlnaHQgcG9pbnQgYW5kIG11bHRpcGxlIFBTS3MgYXJlIHN1cHBvcnRlZA0KDQpUaGlzIHBh cnQgb2YgdGhlIFBSIGlzIGZpbmUsIGJ1dCBJIHRoaW5rIGlzIHVsdGltYXRlbHkgZG9uZSBhIGJp dCBtb3JlIGVsZWdhbnRseSB3aXRoIHRoZSBuLVBSRiBzdHVmZiBpbiAjMzM3Lg0KDQoNCiMgMS4g U2lnbmFsIHRoYXQgYSBQU0sgc2hvdWxkIGdldCBpbmplY3RlZCBpbnRvIGEgZ2l2ZW4gZXBvY2gN CiMgMi4gUmVxdWVzdCBpbmplY3Rpb24gb2YgUFNLIGF0IGpvaW4gLyBpbiBXZWxjb21lDQoNCihU aGVzZSBnbyB0b2dldGhlcikNCg0KVGhlIFBSIHByb3Bvc2VzIChoZWgpIGFuIEVQU0sgcHJvcG9z YWwgb3IgYW4gQWRkIHByb3Bvc2FsLCBidXQgdGhlbiByZXF1aXJlcyB0aGF0IG9ubHkgb25lIEVQ U0sgYmUgdXNlZC4gIEkgYWN0dWFsbHkgZG9uJ3QgdGhlIHByb3Bvc2FsIGZvciBpbmNsdWRpbmcg UFNLcyBpbiBBZGRzIGFjdHVhbGx5IHdvcmtzLiAgVGhlIGpvaW5lciB3b3VsZCBoYXZlIHRvIGtu b3cgYWxsIG9mIHRoZW0gcGx1cyB0aGUgRVBTSywgYW5kIHRoZXJlJ3Mgbm90IGV2ZW4gYW55IHN5 bnRheCBpbiB0aGUgUFIgdG8gdGVsbCB0aGUgam9pbmVyIHdoaWNoIG9uZXMgdG8gaW5jbHVkZS4N Cg0KSSB3b3VsZCBwcm9wb3NlIHRoYXQgaW5zdGVhZCB3ZSBhZGQgYW4gZXh0ZW5zaW9ucyBmaWVs ZCB0byB0aGUgQ29tbWl0IG1lc3NhZ2UsIHRoZW4gYWRkIGEgQ29tbWl0IGV4dGVuc2lvbiB0aGF0 IHNwZWNpZmllcyB0aGUgUFNLIElEIGZvciB0aGUgUFNLIHRvIGJlIGFkZGVkLiAgVGhhdCBleHRl bnNpb24gY2FuIHRoZW4gYWxzbyBnbyBpbiB0aGUgV2VsY29tZSBtZXNzYWdlIGNvcnJlc3BvbmRp bmcgdG8gdGhlIGNvbW1pdCwgc28gdGhhdCBqb2luZXJzIGtub3cgdG8gYWRkIHRoZSBQU0suDQoN ClRoaXMgY2hhbmdlIGFjdHVhbGx5IGRvZXNuJ3QgbWFrZSBhIGRpZmZlcmVuY2UgaW4gdGVybXMg b2Ygd2hhdCBlbmRzIHVwIGluIHRoZSB0cmFuc2NyaXB0IC0tIGVpdGhlciB3YXksIG9ubHkgdGhl IFBTSyBJRCBzZWxlY3RlZCBieSB0aGUgY29tbWl0dGVyIGdvZXMgaW4gdGhlIHRyYW5zY3JpcHQu ICBJdCBzZWVtcyBiZXR0ZXIgbm90IHRvIGRlbGliZXJhdGVseSBoYXZlIHByb3Bvc2FscyBmbG9h dGluZyBhcm91bmQgdGhhdCBuZXZlciBnZXQgaW5jbHVkZWQgaW4gdGhlIHRyYW5zY3JpcHQuDQoN Cg0KIyAzLiBSZS1pbml0aWFsaXplIHRoZSBncm91cCB3aXRoIGRpZmZlcmVudCBwYXJhbWV0ZXJz DQoNClRoZSBQUiBwcm9wb3NlcyBhbm90aGVyIHByb3Bvc2FsIHR5cGUgZm9yIHJlaW5pdGlhbGl6 YXRpb24sIGJ1dCBpdCdzIHJlYWxseSB1bmRlci1zcGVjaWZpZWQgd2hhdCB5b3UgZG8gdG8gcmUt aW5pdC4gIEZvciBleGFtcGxlLCB3aGF0IGdvZXMgaW4gdGhlIHJhdGNoZXQgdHJlZT8gIENsZWFy bHkgeW91IG5lZWQgYSBicmFuZCBuZXcgdHJlZSwgc2luY2UgdGhlIG9uZSB5b3UgaGF2ZSBtaWdo dCBiZSB0aWVkIHRvIHRoZSB3cm9uZyBjaXBoZXJzdWl0ZS4gIFdoYXQgeW91IHJlYWxseSBuZWVk IGlzIHNvbWV0aGluZyBsaWtlIGEgV2VsY29tZSBtZXNzYWdlLg0KDQpBbmQgdGhhdCdzIGhvdyBJ IHRoaW5rIHdlIHNob3VsZCBhY3R1YWxseSBhcnJhbmdlIHRoaW5ncy4gIEluc3RlYWQgb2YgaGF2 aW5nIHRoZSBwYXJlbnQgZ3JvdXAgZG8gc29tZXRoaW5nIHRvIHNwYXduLCBoYXZlIHRoZSBpbml0 aWF0b3Igb2YgdGhlIGNoaWxkIHNlbmQgYSBXZWxjb21lIHRoYXQgaGFzIGEgcG9pbnRlciBiYWNr IHRvIHRoZSBwYXJlbnQuICBTbyB3ZSBoYXZlIGFub3RoZXIgV2VsY29tZSBleHRlbnNpb24gKGBw YXJlbnRfZ3JvdXBgLCBzYXkpIHRoYXQgaGFzIGEgcG9pbnRlciB0byB0aGUgcGFyZW50IGdyb3Vw IGJ5IGdyb3VwIElEIGFuZCBlcG9jaCwgYW5kIGluc3RydWN0cyB0aGUgam9pbmVyIHRvIHRha2Ug YSBzZWNyZXQgZnJvbSB0aGF0IGdyb3VwL2Vwb2NoJ3Mga2V5IHNjaGVkdWxlIGFuZCBhZGQgaXQg aW50byB0aGUgbmV3IGdyb3VwJ3Mga2V5IHNjaGVkdWxlLg0KDQoNCg0KIyA0LiBSZS1zeW5jIGdy b3VwIG1lbWJlcnMgdGhhdCBoYXZlIGxvc3Qgc3RhdGUNCg0KV2Ugc2hvdWxkIG5vdCBkbyB0aGVz ZS4gIEF0IHRoZSBKYW51YXJ5IGludGVyaW0sIHdlIGRlY2lkZWQgbm90IHRvIGRyb3AgdGhlIHJl c3luYyBpc3N1ZSAoIzkzKSBnaXZlbiB0aGF0IHRoZXJlIHdlcmUgc29tZSBzdWJ0bGV0aWVzIGRl cGVuZGluZyBvbiBleGFjdGx5IHdoYXQgc3RhdGUgaGFkIGJlZW4gbG9zdCwgYW5kIHRoYXQgaXQg Y291bGQgYmUgY2xlYW5seSBkb25lIGluIGEgc2VwYXJhdGUgc3BlYy4NCg0KDQojIENvbmNsdXNp b25zDQoNCkdpdmVuIHRoZSBhYm92ZSwgSSB3b3VsZCBwcm9wb3NlIHdlIGJyZWFrIHRoaXMgaW50 byBzZXBhcmF0ZSBpc3N1ZXMgdG8gYmUgY2xvc2VkIHdpdGggaW5kaXZpZHVhbCwgc21hbGxlciBQ UnMuICBBc3N1bWluZyB0aGF0ICgwKSB3aWxsIGdldCBhZGRyZXNzZWQgYnkgdGhlIG4tUFJGIFBS LCB0aGF0IGxlYXZlcyB1cyB3aXRoOg0KDQojWFhYIEFkZCBFeHRlbnNpb25zIHRvIHRoZSBDb21t aXQgbWVzc2FnZQ0KI1hYWCBTaWduYWwgdXNlIG9mIGV4dGVybmFsIFBTS3MgaW4gQ29tbWl0L1dl bGNvbWUgKD0+IGV4dGVuc2lvbiB0byBDb21taXQvV2VsY29tZSBtZXNzYWdlcykNCiNYWFggQWxs b3cgV2VsY29tZSB0byBzaWduYWwgdGhlIGluY2x1c2lvbiBvZiBpbmZvcm1hdGlvbiBmcm9tIGEg cHJpb3IgZ3JvdXAgKD0+IFdlbGNvbWUgZXh0ZW5zaW9uKQ0KDQpIYXBweSB0byB3cml0ZSB0aG9z ZSB1cCwgYW5kIGNvbnRyaWJ1dGUgdG8gUFJzLiAgU29ycnkgYWdhaW4gZm9yIHRoZSBzbG93IHBy b2dyZXNzIGhlcmUuDQoNCi0tUmljaGFyZA0K --_000_BFD5B4F7361741AD811FC6C49A803983npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUmljaGFy ZCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMgYW5k IGNhcmVmdWwgcmVhZCBvZiB0aGUgUFIuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciAj MS8jMjogSSBhbSBhbWljYWJsZSB0byB0aGUgaWRlYSBvZiBhZGRpbmcgYW4gZXh0ZW5zaW9uIGZp ZWxkIHRvIHRoZSBjb21taXQgbWVzc2FnZS4gQXMgYSBnZW5lcmFsIGNvbW1lbnQsIHdlIG1heSB3 YW50IHRvIGNvbnNpZGVyIGlmIHRoZXJlIGFyZSBvdGhlciB0eXBlcyBvZiBjb21taXQgZXh0ZW5z aW9ucyB3b3J0aCBhZGRpbmcgb3IsIGFsdGVybmF0aXZlbHksIGhvdyB0aGUgZmllbGQgbWF5IGJl IGFidXNlZA0KIChlLmcuIHRyZWF0ZWQgYXMgQUQgYnkgYW4gYXBwbGljYXRpb24pLiA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHRlcm1zIG9mIG9iamVjdGlvbiB0byB0 aGUgY3VycmVudCBmb3JtIHRob3VnaCwgeW91ciBhcmd1bWVudCBpcyBub3QgY2xlYXIuIFBTS0lk cyBzaG91bGQgdW5pcXVlbHkgaWRlbnRpZnkgUFNLcywgYW5kIGEgam9pbmVyIChvciBhbnlvbmUp IHNob3VsZCBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZSBjb3JyZWN0IFBTSyBnaXZlbiB0aGUgUFNL SWQsIGlmIHRoZXkgYXJlIGluIHBvc3Nlc3Npb24gb2YgaXQuIFBTS3MNCiBtdXN0IG9ubHkgYmUg dXNlZCBpbiBhbiBBZGQgaWYgdGhlIGpvaW5lciBpcyBhIHBhc3QgZ3JvdXAgbWVtYmVyIChsaW5l IDIwNTUpIGFuZCB0aGVyZWZvcmUgaGFzIHRoZSBjb3JyZWN0IFBTS0lkL2dyb3VwX2lkL3Bza19l cG9jaCwgYWx0aG91Z2ggdGhpcyBpcyBudWxsaWZpZWQgaWYgd2UgbWFrZSB0aGUgY2hhbmdlIGRp c2N1c3NlZCBpbiAjNC4gSW4gdGhhdCBjYXNlLCB0aGUgaXNzdWUgZm9yIEFkZHMgZ29lcyBhd2F5 Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgUFIgYWxyZWFkeSBh bGxvd3MgZm9yIGEgUFNLIGluIHRoZSBXZWxjb21lIG1lc3NhZ2UuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZvciAjMzogQ3VycmVudGx5LCBpbiB0aGUgUFIsIHRoZXJlIGlzIGEgcmVjb3Zlcnlf c2VjcmV0IGRlcml2ZWQgcGVyLWVwb2NoLiBXaGVuIGEgbWVtYmVyIHdhbnRzIHRvIHJlLWluaXRp YWxpemUsIHRoZXkgaXNzdWUgYSBSZS1Jbml0IHByb3Bvc2FsLiBUaGV5IG1heSB0aGVuIHJlLWlu aXRpYWxpemUgdGhlIGdyb3VwIGJ5IHNlbmRpbmcgYSBXZWxjb21lIG1lc3NhZ2UgKHNlZSBsaW5l cyAxOTIzLCAxOTQ4LCBhbmQNCiAyMzQ5KSB3aXRoIHRoZSBQU0tJZCBmb3IgdGhlIHBhcmVudCBn cm91cC9lcG9jaCBhbmQgYSBwc2t0eXBlIHRoYXQgaW5kaWNhdGVzIHRoYXQgdGhleSBhcmUgcmUt aW5pdGlhbGl6aW5nIHRoZSBncm91cCB3aXRoIHRoZSBzdGF0ZWQgUFNLSWQuIFNvIHRoaXMgc2Vl bXMgdG8gYWxyZWFkeSBiZSB3aGF0IHlvdSBkZXNjcmliZSBiZWxvdyBhcyDigJxoYXZlIHRoZSBp bml0aWF0b3Igb2YgdGhlIGNoaWxkIHNlbmQgYSBXZWxjb21lIHRoYXQgaGFzIGEgcG9pbnRlcg0K IGJhY2sgdG8gdGhlIHBhcmVudOKAnS4gSG93ZXZlciwgeW91IGFyZSByaWdodCB0aGF0IG1vcmUg ZGV0YWlsIGNhbiBiZSBhZGRlZDsgaW4gcGFydGljdWxhciBhIHJlcXVpcmVtZW50IHNob3VsZCBi ZSBhZGRlZCB0byB0ZXJtaW5hdGUgdGhlIHBhcmVudCBncm91cCBhbmQgdGhhdCB0aGUgdGVybWlu YXRpbmcgbWVtYmVyL3JlLWluaXQgcHJvcG9zZXIgbXVzdCBhbHNvIGNyZWF0ZSB0aGUgbmV3IGdy b3VwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgIzQ6IFRoZXJlIHdhcyBhIGRpc2N1c3Np b24gYXQgdGhlIGZpcnN0IHZpcnR1YWwgaW50ZXJpbSBpbiBsYXRlIEFwcmlsIChJbnRlcmltICMx MS0yMDIwKSB3aGVyZWluIHNvbWUgZXhwcmVzc2VkIGEgZGVzaXJlIGZvciB0aGlzIGZlYXR1cmUu IE5hbWVseSwgaW5zdGVhZCBvZiByZS1zeW5jaW5nIHRoZSBlbnRpcmUgZ3JvdXAsIHRoZXJlIHdl cmUgdXNlIGNhc2VzIGZvciByZS1zeW5jaW5nIHRoZSBvZGQgbWVtYmVyDQogd2hlbiBuZWNlc3Nh cnkuIEl0cyBpbmNsdXNpb24gaW4gdGhlIFBSIGFyaXNlcyBmcm9tIHRoYXQgbGF0ZXIgcmVxdWVz dC4gSSBhbSBmYXZvcmFibGUgdG8gcmVtb3ZpbmcgaXQgc2luY2UsIGZyb20gc2VjdXJpdHkgc3Rh bmRwb2ludCwgaXQgaXMgbm90IGlkZWFsLiBIb3dldmVyLCB0aGUgbW90aXZhdGlvbiBmb3IgdGhp cyB3YXMgcHVzaGVkIGZyb20gdGhlIGltcGxlbWVudGF0aW9uIHN0YW5kcG9pbnQuIENvbnNlcXVl bnRseSwgbm93IGlzIGEgZ29vZA0KIHRpbWUgZm9yIGFueW9uZSB0byBzcGVhayB1cCB3aG8gd2Fu dHMgdG8gcHVzaCBmb3IgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgaXRlbTogeW91IG1hZGUgcG9pbnQg b2Ygc3BlY2lmaWNhbGx5IHJlcXVlc3Rpbmcg4oCTIGEgZmV3IHRpbWVzIOKAkyBhdCB0aGUgdmly dHVhbCBpbnRlcmltcyAjMTEgYW5kICMxMiBpbiBBcHJpbC9NYXkgdGhhdCB0aGlzIFBTSyBQUiBh bmQgYXMgbWFueSBvdGhlciBrZXkgc2NoZWR1bGUtcmVsYXRlZCBQUnMgYmUgY29tYmluZWQgaW50 byBhIHNpbmdsZSBvbmUuIFJhcGhhZWwgbWFkZSBhIHNpbWlsYXIgcmVxdWVzdA0KIHVuZGVyIGdp dCBpc3N1ZSAjMzI1LiBJbiBmYWN0LCB0aGUgYXV0aG9ycyBvZiB0aGlzIFBSIGhhZCBwdXNoZWQg YmFjayBvbiB0aGF0IGluc2lzdGVuY2UgdG8gbGltaXQgdGhlIGN1cnJlbnQgUFIgZG93biB0byB0 aGUgaXRlbXMgaXQgY3VycmVudGx5IGNvdmVycywgaW5zdGVhZCBvZiBtZXJnaW5nIGluIG90aGVy IGtleSBzY2hlZHVsZSBjaGFuZ2VzIGFzIHdlbGwuIEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IGhh dmUgY2hhbmdlZCB5b3VyIG1pbmQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldlIGNhbiwgb2YgY291cnNlLCBhY2NvbW1vZGF0ZSBhIHJldmlzZWQgcHJlZmVyZW5jZSBp ZiBuZWVkZWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccml0dGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5NTFMgJmx0O21s cy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUmljaGFyZCBCYXJuZXMgJmx0O3Js YkBpcHYuc3gmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVuZSAxNywgMjAyMCBh dCAzOjU0IFBNPGJyPg0KPGI+VG86IDwvYj5NZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgV0cgJmx0 O21sc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W01MU10gUFNLIEluamVjdGlv biwgR3JvdXAgcmVjb3ZlcnksIFJlLUluaXQsIFN1Yi1ncm91cCBCcmFuY2hpbmcgKCMzMzYpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IZXkgYWxsLDxicj4NCjxicj4NClNvcnJ5IGZvciB0aGUgbGF0ZSByZXZpZXcgb24gdGhpcyBQ UiwgSSBoYXZlIGZpbmFsbHkgZ290dGVuIGEgY2hhbmNlIHRvIHJlYWxseSBkaWcgaW50byBpdCwg YW5kIC4uLiBJIGhhdmUgc29tZSBjb25jZXJucy4mbmJzcDsgTXkgY3VycmVudCB0aGlua2luZyBp cyBjb25zaXN0ZW50IHdpdGggbXkgZWFybGllciBjb21tZW50cyB0aGF0IHRoZSBnZW5lcmFsIHRo cnVzdCBvZiB0aGlzIFBSIGlzIE9LLiZuYnNwOyBCdXQgSSB0aGluayB0aGUgYWN0dWFsIGFwcHJv YWNoDQogbmVlZHMgdG8gY2hhbmdlIGEgZmFpciBiaXQuPGJyPg0KPGJyPg0KQXMgaXRzIHRpdGxl IGltcGxpZXMsIHRoaXMgUFIgaXMgdHJ5aW5nIHRvIGRvIHNldmVyYWwgdGhpbmdzIGF0IG9uY2Us IHdoaWNoIHNlZW0gdG8gbWUgdG8gYmUgZmFpcmx5IHNlcGFyYWJsZTo8YnI+DQo8YnI+DQowLiBV cGRhdGUgdGhlIGtleSBzY2hlZHVsZSBzbyB0aGF0IFBTS3MgYXJlIGluamVjdGVkIGF0IHRoZSBy aWdodCBwb2ludCBhbmQgbXVsdGlwbGUgUFNLcyBhcmUgc3VwcG9ydGVkPGJyPg0KMS4gU2lnbmFs IHRoYXQgYSBQU0sgc2hvdWxkIGdldCBpbmplY3RlZCBpbnRvIGEgZ2l2ZW4gZXBvY2g8YnI+DQoy LiBSZXF1ZXN0IGluamVjdGlvbiBvZiBQU0sgYXQgam9pbiAvIGluIFdlbGNvbWU8YnI+DQozLiBS ZS1pbml0aWFsaXplIHRoZSBncm91cCB3aXRoIGRpZmZlcmVudCBwYXJhbWV0ZXJzPGJyPg0KNC4g UmUtc3luYyBncm91cCBtZW1iZXJzIHRoYXQgaGF2ZSBsb3N0IHN0YXRlPGJyPg0KPGJyPg0KRm9y IHRoZSBtb3N0IHBhcnQsIEkgdGhpbmsgdGhlc2UgYXJlIHdvcnRod2hpbGUgZ29hbHMsIGJ1dCB0 aGV5IHNob3VsZCBiZSBhY2NvbXBsaXNoZWQgaW4gZGlmZmVyZW50IHdheXMgdGhhbiB0aGUgUFIg cHJvcG9zZXMuJm5ic3A7IERldGFpbGVkIHRob3VnaHRzIGJ5IG9iamVjdGl2ZTo8YnI+DQo8YnI+ DQo8YnI+DQojIDAuIFVwZGF0ZSB0aGUga2V5IHNjaGVkdWxlIHNvIHRoYXQgUFNLcyBhcmUgaW5q ZWN0ZWQgYXQgdGhlIHJpZ2h0IHBvaW50IGFuZCBtdWx0aXBsZSBQU0tzIGFyZSBzdXBwb3J0ZWQ8 YnI+DQo8YnI+DQpUaGlzIHBhcnQgb2YgdGhlIFBSIGlzIGZpbmUsIGJ1dCBJIHRoaW5rIGlzIHVs dGltYXRlbHkgZG9uZSBhIGJpdCBtb3JlIGVsZWdhbnRseSB3aXRoIHRoZSBuLVBSRiBzdHVmZiBp biAjMzM3Ljxicj4NCjxicj4NCjxicj4NCiMgMS4gU2lnbmFsIHRoYXQgYSBQU0sgc2hvdWxkIGdl dCBpbmplY3RlZCBpbnRvIGEgZ2l2ZW4gZXBvY2g8YnI+DQojIDIuIFJlcXVlc3QgaW5qZWN0aW9u IG9mIFBTSyBhdCBqb2luIC8gaW4gV2VsY29tZTxicj4NCjxicj4NCihUaGVzZSBnbyB0b2dldGhl cik8YnI+DQo8YnI+DQpUaGUgUFIgcHJvcG9zZXMgKGhlaCkgYW4gRVBTSyBwcm9wb3NhbCBvciBh biBBZGQgcHJvcG9zYWwsIGJ1dCB0aGVuIHJlcXVpcmVzIHRoYXQgb25seSBvbmUgRVBTSyBiZSB1 c2VkLiZuYnNwOyBJIGFjdHVhbGx5IGRvbid0IHRoZSBwcm9wb3NhbCBmb3IgaW5jbHVkaW5nIFBT S3MgaW4gQWRkcyBhY3R1YWxseSB3b3Jrcy4mbmJzcDsgVGhlIGpvaW5lciB3b3VsZCBoYXZlIHRv IGtub3cgYWxsIG9mIHRoZW0gcGx1cyB0aGUgRVBTSywgYW5kIHRoZXJlJ3Mgbm90IGV2ZW4NCiBh bnkgc3ludGF4IGluIHRoZSBQUiB0byB0ZWxsIHRoZSBqb2luZXIgd2hpY2ggb25lcyB0byBpbmNs dWRlLjxicj4NCjxicj4NCkkgd291bGQgcHJvcG9zZSB0aGF0IGluc3RlYWQgd2UgYWRkIGFuIGV4 dGVuc2lvbnMgZmllbGQgdG8gdGhlIENvbW1pdCBtZXNzYWdlLCB0aGVuIGFkZCBhIENvbW1pdCBl eHRlbnNpb24gdGhhdCBzcGVjaWZpZXMgdGhlIFBTSyBJRCBmb3IgdGhlIFBTSyB0byBiZSBhZGRl ZC4mbmJzcDsgVGhhdCBleHRlbnNpb24gY2FuIHRoZW4gYWxzbyBnbyBpbiB0aGUgV2VsY29tZSBt ZXNzYWdlIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGNvbW1pdCwgc28gdGhhdCBqb2luZXJzDQoga25v dyB0byBhZGQgdGhlIFBTSy48YnI+DQo8YnI+DQpUaGlzIGNoYW5nZSBhY3R1YWxseSBkb2Vzbid0 IG1ha2UgYSBkaWZmZXJlbmNlIGluIHRlcm1zIG9mIHdoYXQgZW5kcyB1cCBpbiB0aGUgdHJhbnNj cmlwdCAtLSBlaXRoZXIgd2F5LCBvbmx5IHRoZSBQU0sgSUQgc2VsZWN0ZWQgYnkgdGhlIGNvbW1p dHRlciBnb2VzIGluIHRoZSB0cmFuc2NyaXB0LiZuYnNwOyBJdCBzZWVtcyBiZXR0ZXIgbm90IHRv IGRlbGliZXJhdGVseSBoYXZlIHByb3Bvc2FscyBmbG9hdGluZyBhcm91bmQgdGhhdCBuZXZlciBn ZXQgaW5jbHVkZWQNCiBpbiB0aGUgdHJhbnNjcmlwdC48YnI+DQo8YnI+DQo8YnI+DQojIDMuIFJl LWluaXRpYWxpemUgdGhlIGdyb3VwIHdpdGggZGlmZmVyZW50IHBhcmFtZXRlcnM8YnI+DQo8YnI+ DQpUaGUgUFIgcHJvcG9zZXMgYW5vdGhlciBwcm9wb3NhbCB0eXBlIGZvciByZWluaXRpYWxpemF0 aW9uLCBidXQgaXQncyByZWFsbHkgdW5kZXItc3BlY2lmaWVkIHdoYXQgeW91IGRvIHRvIHJlLWlu aXQuJm5ic3A7IEZvciBleGFtcGxlLCB3aGF0IGdvZXMgaW4gdGhlIHJhdGNoZXQgdHJlZT8mbmJz cDsgQ2xlYXJseSB5b3UgbmVlZCBhIGJyYW5kIG5ldyB0cmVlLCBzaW5jZSB0aGUgb25lIHlvdSBo YXZlIG1pZ2h0IGJlIHRpZWQgdG8gdGhlIHdyb25nIGNpcGhlcnN1aXRlLiZuYnNwOw0KIFdoYXQg eW91IHJlYWxseSBuZWVkIGlzIHNvbWV0aGluZyBsaWtlIGEgV2VsY29tZSBtZXNzYWdlLjxicj4N Cjxicj4NCkFuZCB0aGF0J3MgaG93IEkgdGhpbmsgd2Ugc2hvdWxkIGFjdHVhbGx5IGFycmFuZ2Ug dGhpbmdzLiZuYnNwOyBJbnN0ZWFkIG9mIGhhdmluZyB0aGUgcGFyZW50IGdyb3VwIGRvIHNvbWV0 aGluZyB0byBzcGF3biwgaGF2ZSB0aGUgaW5pdGlhdG9yIG9mIHRoZSBjaGlsZCBzZW5kIGEgV2Vs Y29tZSB0aGF0IGhhcyBhIHBvaW50ZXIgYmFjayB0byB0aGUgcGFyZW50LiZuYnNwOyBTbyB3ZSBo YXZlIGFub3RoZXIgV2VsY29tZSBleHRlbnNpb24gKGBwYXJlbnRfZ3JvdXBgLA0KIHNheSkgdGhh dCBoYXMgYSBwb2ludGVyIHRvIHRoZSBwYXJlbnQgZ3JvdXAgYnkgZ3JvdXAgSUQgYW5kIGVwb2No LCBhbmQgaW5zdHJ1Y3RzIHRoZSBqb2luZXIgdG8gdGFrZSBhIHNlY3JldCBmcm9tIHRoYXQgZ3Jv dXAvZXBvY2gncyBrZXkgc2NoZWR1bGUgYW5kIGFkZCBpdCBpbnRvIHRoZSBuZXcgZ3JvdXAncyBr ZXkgc2NoZWR1bGUuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KIyA0LiBSZS1zeW5jIGdyb3VwIG1l bWJlcnMgdGhhdCBoYXZlIGxvc3Qgc3RhdGU8YnI+DQo8YnI+DQpXZSBzaG91bGQgbm90IGRvIHRo ZXNlLiZuYnNwOyBBdCB0aGUgSmFudWFyeSBpbnRlcmltLCB3ZSBkZWNpZGVkIG5vdCB0byBkcm9w IHRoZSByZXN5bmMgaXNzdWUgKCM5MykgZ2l2ZW4gdGhhdCB0aGVyZSB3ZXJlIHNvbWUgc3VidGxl dGllcyBkZXBlbmRpbmcgb24gZXhhY3RseSB3aGF0IHN0YXRlIGhhZCBiZWVuIGxvc3QsIGFuZCB0 aGF0IGl0IGNvdWxkIGJlIGNsZWFubHkgZG9uZSBpbiBhIHNlcGFyYXRlIHNwZWMuDQo8YnI+DQo8 YnI+DQo8YnI+DQojIENvbmNsdXNpb25zPGJyPg0KPGJyPg0KR2l2ZW4gdGhlIGFib3ZlLCBJIHdv dWxkIHByb3Bvc2Ugd2UgYnJlYWsgdGhpcyBpbnRvIHNlcGFyYXRlIGlzc3VlcyB0byBiZSBjbG9z ZWQgd2l0aCBpbmRpdmlkdWFsLCBzbWFsbGVyIFBScy4mbmJzcDsgQXNzdW1pbmcgdGhhdCAoMCkg d2lsbCBnZXQgYWRkcmVzc2VkIGJ5IHRoZSBuLVBSRiBQUiwgdGhhdCBsZWF2ZXMgdXMgd2l0aDo8 YnI+DQo8YnI+DQojWFhYIEFkZCBFeHRlbnNpb25zIHRvIHRoZSBDb21taXQgbWVzc2FnZTxicj4N CiNYWFggU2lnbmFsIHVzZSBvZiBleHRlcm5hbCBQU0tzIGluIENvbW1pdC9XZWxjb21lICg9Jmd0 OyBleHRlbnNpb24gdG8gQ29tbWl0L1dlbGNvbWUgbWVzc2FnZXMpPGJyPg0KI1hYWCBBbGxvdyBX ZWxjb21lIHRvIHNpZ25hbCB0aGUgaW5jbHVzaW9uIG9mIGluZm9ybWF0aW9uIGZyb20gYSBwcmlv ciBncm91cCAoPSZndDsgV2VsY29tZSBleHRlbnNpb24pPGJyPg0KPGJyPg0KSGFwcHkgdG8gd3Jp dGUgdGhvc2UgdXAsIGFuZCBjb250cmlidXRlIHRvIFBScy4mbmJzcDsgU29ycnkgYWdhaW4gZm9y IHRoZSBzbG93IHByb2dyZXNzIGhlcmUuPGJyPg0KPGJyPg0KLS1SaWNoYXJkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BFD5B4F7361741AD811FC6C49A803983npsedu_-- From nobody Thu Jun 18 07:29:43 2020 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 0E62D3A115D for ; Thu, 18 Jun 2020 07:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 OYNbsw4uvfM7 for ; Thu, 18 Jun 2020 07:29:33 -0700 (PDT) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050::465:102]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1733A1131 for ; Thu, 18 Jun 2020 07:29:32 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 49nkpg07xDzKmQY for ; Thu, 18 Jun 2020 16:29:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id G_n27Um8xHJo for ; Thu, 18 Jun 2020 16:29:26 +0200 (CEST) To: mls@ietf.org References: From: Konrad Kohbrok Message-ID: <710ba832-c77c-58d2-a7b4-b8dc8eaf09e3@datashrine.de> Date: Thu, 18 Jun 2020 17:29:25 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-MBO-SPAM-Probability: 0 X-Rspamd-Score: -5.58 / 15.00 / 15.00 X-Rspamd-Queue-Id: 965821762 X-Rspamd-UID: 23c5bf Archived-At: Subject: Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) 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, 18 Jun 2020 14:29:43 -0000 Hi, Just a small addition to Britta's response: For #3: We already mandate that the parent group must not be used anymore if a Re-Init proposal is included in a commit in lines 2341-2342 of the PR (although "to send messages" might as well be removed). We could also get rid of the proposal and simply have the intent to re-initialize be implicit in sending a Welcome message with a corresponding PSK Id. The idea behind the Proposal was to make that intent explicit such that the intent, as well as the target ciphersuite and MLS version are all entered into the transcript and thus agreed upon. Even though the group is terminated after the proposal is received, this agreement can be verified by using the authentication key technique that Britta proposed, i.e. each party can check that their authentication key corresponds to the one the committer uploaded. I'm also ok with splitting it into multiple individual PRs if that makes it easier to review and discuss. Cheers, Konrad On 18.06.20 04:07, Hale, Britta (CIV) wrote: > Hi Richard, > >   > > Thank you for the comments and careful read of the PR. > >   > > For #1/#2: I am amicable to the idea of adding an extension field to the commit > message. As a general comment, we may want to consider if there are other types > of commit extensions worth adding or, alternatively, how the field may be abused > (e.g. treated as AD by an application). > > It terms of objection to the current form though, your argument is not clear. > PSKIds should uniquely identify PSKs, and a joiner (or anyone) should be able to > identify the correct PSK given the PSKId, if they are in possession of it. PSKs > must only be used in an Add if the joiner is a past group member (line 2055) and > therefore has the correct PSKId/group_id/psk_epoch, although this is nullified > if we make the change discussed in #4. In that case, the issue for Adds goes away. > > The PR already allows for a PSK in the Welcome message. > >   > > For #3: Currently, in the PR, there is a recovery_secret derived per-epoch. When > a member wants to re-initialize, they issue a Re-Init proposal. They may then > re-initialize the group by sending a Welcome message (see lines 1923, 1948, and > 2349) with the PSKId for the parent group/epoch and a psktype that indicates > that they are re-initializing the group with the stated PSKId. So this seems to > already be what you describe below as “have the initiator of the child send a > Welcome that has a pointer back to the parent”. However, you are right that more > detail can be added; in particular a requirement should be added to terminate > the parent group and that the terminating member/re-init proposer must also > create the new group. > >   > > For #4: There was a discussion at the first virtual interim in late April > (Interim #11-2020) wherein some expressed a desire for this feature. Namely, > instead of re-syncing the entire group, there were use cases for re-syncing the > odd member when necessary. Its inclusion in the PR arises from that later > request. I am favorable to removing it since, from security standpoint, it is > not ideal. However, the motivation for this was pushed from the implementation > standpoint. Consequently, now is a good time for anyone to speak up who wants to > push for this. > >   > >   > > One item: you made point of specifically requesting – a few times – at the > virtual interims #11 and #12 in April/May that this PSK PR and as many other key > schedule-related PRs be combined into a single one. Raphael made a similar > request under git issue #325. In fact, the authors of this PR had pushed back on > that insistence to limit the current PR down to the items it currently covers, > instead of merging in other key schedule changes as well. Are you saying that > you have changed your mind? > > We can, of course, accommodate a revised preference if needed. > >   > >   > > Britta > >   > >   > >   > > *From: *MLS on behalf of Richard Barnes > *Date: *Wednesday, June 17, 2020 at 3:54 PM > *To: *Messaging Layer Security WG > *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) > >   > > Hey all, > > Sorry for the late review on this PR, I have finally gotten a chance to really > dig into it, and ... I have some concerns.  My current thinking is consistent > with my earlier comments that the general thrust of this PR is OK.  But I think > the actual approach needs to change a fair bit. > > As its title implies, this PR is trying to do several things at once, which seem > to me to be fairly separable: > > 0. Update the key schedule so that PSKs are injected at the right point and > multiple PSKs are supported > 1. Signal that a PSK should get injected into a given epoch > 2. Request injection of PSK at join / in Welcome > 3. Re-initialize the group with different parameters > 4. Re-sync group members that have lost state > > For the most part, I think these are worthwhile goals, but they should be > accomplished in different ways than the PR proposes.  Detailed thoughts by > objective: > > > # 0. Update the key schedule so that PSKs are injected at the right point and > multiple PSKs are supported > > This part of the PR is fine, but I think is ultimately done a bit more elegantly > with the n-PRF stuff in #337. > > > # 1. Signal that a PSK should get injected into a given epoch > # 2. Request injection of PSK at join / in Welcome > > (These go together) > > The PR proposes (heh) an EPSK proposal or an Add proposal, but then requires > that only one EPSK be used.  I actually don't the proposal for including PSKs in > Adds actually works.  The joiner would have to know all of them plus the EPSK, > and there's not even any syntax in the PR to tell the joiner which ones to include. > > I would propose that instead we add an extensions field to the Commit message, > then add a Commit extension that specifies the PSK ID for the PSK to be added.  > That extension can then also go in the Welcome message corresponding to the > commit, so that joiners know to add the PSK. > > This change actually doesn't make a difference in terms of what ends up in the > transcript -- either way, only the PSK ID selected by the committer goes in the > transcript.  It seems better not to deliberately have proposals floating around > that never get included in the transcript. > > > # 3. Re-initialize the group with different parameters > > The PR proposes another proposal type for reinitialization, but it's really > under-specified what you do to re-init.  For example, what goes in the ratchet > tree?  Clearly you need a brand new tree, since the one you have might be tied > to the wrong ciphersuite.  What you really need is something like a Welcome message. > > And that's how I think we should actually arrange things.  Instead of having the > parent group do something to spawn, have the initiator of the child send a > Welcome that has a pointer back to the parent.  So we have another Welcome > extension (`parent_group`, say) that has a pointer to the parent group by group > ID and epoch, and instructs the joiner to take a secret from that group/epoch's > key schedule and add it into the new group's key schedule. > > > > # 4. Re-sync group members that have lost state > > We should not do these.  At the January interim, we decided not to drop the > resync issue (#93) given that there were some subtleties depending on exactly > what state had been lost, and that it could be cleanly done in a separate spec. > > > # Conclusions > > Given the above, I would propose we break this into separate issues to be closed > with individual, smaller PRs.  Assuming that (0) will get addressed by the n-PRF > PR, that leaves us with: > > #XXX Add Extensions to the Commit message > #XXX Signal use of external PSKs in Commit/Welcome (=> extension to > Commit/Welcome messages) > #XXX Allow Welcome to signal the inclusion of information from a prior group (=> > Welcome extension) > > Happy to write those up, and contribute to PRs.  Sorry again for the slow > progress here. > > --Richard > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Sun Jun 21 00:41:43 2020 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 22B1F3A00B3 for ; Sun, 21 Jun 2020 00:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=mnot.net header.b=LOjl9g//; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l5xnj8fg 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 T36RHie_rHhA for ; Sun, 21 Jun 2020 00:41:36 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FD63A0A09 for ; Sun, 21 Jun 2020 00:41:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 679755C00BA for ; Sun, 21 Jun 2020 03:33:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 21 Jun 2020 03:33:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=S6tgMm3HMfVfgsWwcLDBttT7wG/lL5xxoeUKN4hct4k=; b=LOjl9g// QjYst+rsEL+qT2xQW/E5ZDdDnQDcd3SS/yZER+evtUtcZmaHzz08dqshwaQERL59 kFG3VnIsOz5DF4oG2AjBLq/CgjH1MbiaYS0/Tfuvdv1WMk7CXUYD7C73ZYINSBh2 l11fdmOiYNpSGOGw0rom/53oc2U4xX92qaV1BjJQJirywza2w0nspj+HT08SCGZ7 02/egvk728PLWlvlQR5uZBvHfmpGI3+vVarDfZj9s1aUqoMPqB0pLxDksfHBbDS0 AhTWQO/fp3IB7vh+R338TOkLO81uqfczzO6Ca91C3RGpBA/mG3R8di5JE1+liEDI YFR7miUhBD7gNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=S6tgMm3HMfVfgsWwcLDBttT7wG/lL 5xxoeUKN4hct4k=; b=l5xnj8fg1bmARpQfbIXI2u58gjleiowx4dV7f6pXL2tun 3QWcCW4lfkNx3gQXprx9AjvuurWDtotkWC9yUHN4uVh76xMr0JiRAnFCn2UOFfcs gqtqUKhzXoROmj3fBWloo6a23m9i8uGkBQHGtTbwkqAiolpbtZmklSxWX7W1L03g jDIcxyOspZxUlwY/PByYEp5WrhDYp1CXZtXLDU4RVaipYFaNxi6Q1tDQoze3KQPk 7KNFaIhgj0+0njFNiYeRvgc2VDtIXQuwwtDv3XMgbG9nmgzuo0e1nc/IBvNSqWdy FZNeLki1Le9IiLGcBv00glIfKs1O1XmLYX3I1TjTQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejledguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudegledrudehke drvddvheenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhm peguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az52.internal.cloudapp.net (unknown [52.149.158.225]) by mail.messagingengine.com (Postfix) with ESMTPA id 216333280067 for ; Sun, 21 Jun 2020 03:33:04 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============1571428888189835712==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200621073304.216333280067@mailuser.nyi.internal> Date: Sun, 21 Jun 2020 03:33:04 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) 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: Sun, 21 Jun 2020 07:41:39 -0000 --===============1571428888189835712== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-16/=F0=9F=92=AC1) 1 issues created: - Use HPKE KDF for the MLS key schedule (by bifurcation) https://github.com/mlswg/mls-protocol/issues/351=20 1 issues received 1 new comments: - #289 Make Editor's Copy and WG draft compare work properly (1 by katrie= lalex) https://github.com/mlswg/mls-protocol/issues/289 [build]=20 16 issues closed: - Discuss "closing" groups vs PCS https://github.com/mlswg/mls-protocol/i= ssues/249 [performance] [security]=20 - Ratcheting of External PSKs https://github.com/mlswg/mls-protocol/issue= s/346=20 - Targeted message https://github.com/mlswg/mls-protocol/issues/301 [disc= ussion] [functionality] [privacy]=20 - Allow indirection of credentials https://github.com/mlswg/mls-protocol/= issues/299 [enhancement] [performance]=20 - Varints https://github.com/mlswg/mls-protocol/issues/298 [enhancement] = [performance]=20 - Detection of tree forks by recipients via a commitment https://github.c= om/mlswg/mls-protocol/issues/291 [functionality] [work in progress]=20 - Create and send to sub-groups https://github.com/mlswg/mls-protocol/iss= ues/271 [discussion] [functionality] [work in progress]=20 - Make Editor's Copy and WG draft compare work properly https://github.co= m/mlswg/mls-protocol/issues/289 [build]=20 - Expiration on "last resort key" must not be omitted https://github.com/= mlswg/mls-protocol/issues/270 [security] [work in progress]=20 - Missing context in the PSK/Importer injection https://github.com/mlswg/= mls-protocol/issues/268 [bug] [security]=20 - Relax default policy of adding from left to right https://github.com/ml= swg/mls-protocol/issues/266 [performance] [privacy]=20 - Fix inconsistent definitions of Derive-Secret https://github.com/mlswg/= mls-protocol/issues/264 [bug] [security] [work in progress]=20 - Performance measurements https://github.com/mlswg/mls-protocol/issues/2= 22 [performance] [question]=20 - Discuss DH cofactor issues and Update DH and Elliptic Curve parameters = text. https://github.com/mlswg/mls-protocol/issues/118 [editorial]=20 - User-Initiated Add https://github.com/mlswg/mls-protocol/issues/91 [enh= ancement] [work in progress]=20 - Fix context for new-member-initiated Add https://github.com/mlswg/mls-p= rotocol/issues/323 [bug]=20 Pull requests ------------- * mlswg/mls-protocol (+4/-1/=F0=9F=92=AC8) 4 pull requests submitted: - Explain the meaning of a Commit with no proposals (by bifurcation) https://github.com/mlswg/mls-protocol/pull/353=20 - Use node_index for both hashes (by bifurcation) https://github.com/mlswg/mls-protocol/pull/352=20 - IANA updates and their consequences (by bifurcation) https://github.com/mlswg/mls-protocol/pull/350=20 - Use opaque epoch IDs and encrypt content type (by bifurcation) https://github.com/mlswg/mls-protocol/pull/349=20 5 pull requests received 8 new comments: - #352 Use node_index for both hashes (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/352=20 - #347 Explicitly specify which nodes are targeted (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/347=20 - #345 no need extra layer of optional in GroupInfo.tree (1 by bifurcatio= n) https://github.com/mlswg/mls-protocol/pull/345=20 - #337 Replace DKDF by n-PRF in key schedule; minor fix (4 by chrisbrzusk= a, jhoyla) https://github.com/mlswg/mls-protocol/pull/337 [discussion] [key schedu= le] [security] [work in progress]=20 - #336 PSK Injection, Group recovery, Re-Init, Sub-group Branching (1 by = bifurcation) https://github.com/mlswg/mls-protocol/pull/336 [key schedule]=20 1 pull requests merged: - Allow external proposals to be signed. https://github.com/mlswg/mls-protocol/pull/342=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============1571428888189835712== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday June 21, 2020

Issues

mlswg/mls-protocol (+1/-16/=F0=9F=92=AC1)

1 issues created:

1 issues received 1 new comments:

16 issues closed:

Pull requests

mlswg/mls-protocol (+4/-1/=F0=9F=92=AC8)

4 pull requests submitted:

5 pull requests received 8 new comments:

Repositories tracked by this digest:

--===============1571428888189835712==-- From nobody Sun Jun 21 18:12:05 2020 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 C7C973A083B for ; Sun, 21 Jun 2020 18:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 8H28q2jZkSfe for ; Sun, 21 Jun 2020 18:12:02 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 399483A07F4 for ; Sun, 21 Jun 2020 18:12:02 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id l6so10511987qkc.6 for ; Sun, 21 Jun 2020 18:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=C660hImSc3hxTZcDH5nc16NnN+BqX13pc1YnD0yxwRc=; b=Ku6AelK7OhCsGNgXVaQkkTCYCPrWDU0wbctDMeVdqNAJJ3kfvuVEn1uwLwTmZNvINo Y45Vc/qEePMdxA2NUh40cosNOHSvL5p/BDu3QWY1u3g0SdbX6AkTMKanOT2trDSd5LFp gTbNWcTdG2BKBjd274lBlYk8V9fC3taxaz/1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=C660hImSc3hxTZcDH5nc16NnN+BqX13pc1YnD0yxwRc=; b=Bc2S/OzOldOduaFymxtwuL/VYdQsphTdYPXHaMaff7sZNzbw9T0wurtVfK1JDsf0Rs slzIutS/uZPim9sQl7c2/yINc//6DgG7UWH5YJz+/3NFnE+NkkNqiSohXstTuamtHxCI CVTlpNm83feMTJWic+zab4e45qxYZNPvHele0g/u3BK0Ro4IISNlnz+37w5bSiCaDPun eKfe3rxC1vYXtfrl5OXeHy/EV/fDdWT8TUszlpPSgSky1YZ3+DI6UNkbtmONSob8fZF1 V8rz8ZD++i5t1AgzaCBr+jJMxaEYzm7mifswnCds3gHndd+UkDhHe8NK7Tv+6T3KqvLj kq6w== X-Gm-Message-State: AOAM531KUI111Bk5NuBo/GZ/WEnedBZh/iS/fT17kLGl5EZr+aaBt8FO 8co3puHYXuXJU1CoVybvp1Qbv+fBQm4= X-Google-Smtp-Source: ABdhPJwgU3c876oQb1s6DjAbW18opPBNahy5uyrBEU4rvSlBWfUj55mwJVZKndsAgLT6WCPlhZhAKw== X-Received: by 2002:a05:620a:b03:: with SMTP id t3mr14183994qkg.317.1592788320853; Sun, 21 Jun 2020 18:12:00 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id w68sm12772311qkc.68.2020.06.21.18.12.00 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jun 2020 18:12:00 -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 13.4 \(3608.80.23.2.2\)) Date: Sun, 21 Jun 2020 21:11:59 -0400 References: <158803574083.19043.1196953972603957712@ietfa.amsl.com> <9A5C42D2-95E3-4AA3-91F1-6AE9216CE77C@sn3rd.com> To: MLS List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 01:12:04 -0000 We discussed scheduling additional meetings. I will submit requests for = meetings on 7 and 14 July. We also have an hour scheduled for IETF 108 = so that=E2=80=99s 3 meeting this month. I figured we=E2=80=99d give = everybody the 21st to allow for the inevitable scramble before an IETF = meeting. spt > On Jun 16, 2020, at 12:01, Sean Turner wrote: >=20 > I had not scheduled them. There is one today: 16 June 2020. >=20 > spt >=20 >> On Jun 16, 2020, at 11:57, Richard Barnes wrote: >>=20 >> Sean: Are we going to do another round of these? I think it would = probably be useful. >>=20 >> On Tue, Jun 16, 2020 at 10:47 AM Sean Turner wrote: >> Just a reminder that there is another interim meeting today in about = an hour. >>=20 >> spt >>=20 >>> On Jun 1, 2020, at 20:33, Sean Turner wrote: >>>=20 >>>=20 >>>> On May 4, 2020, at 12:23, Sean Turner wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Apr 27, 2020, at 21:35, Sean Turner wrote: >>>>>=20 >>>>>=20 >>>>>> On Apr 27, 2020, at 21:02, IETF Meeting Session Request Tool = wrote: >>>>>>=20 >>>>>>=20 >>>>>> A new interim meeting series request has just been submitted by = Sean Turner. >>>>>>=20 >>>>>> This request requires approval by the Area Director of the = Security Area >>>>>>=20 >>>>>> The meetings can be approved here:=20 >>>>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-12 >>>>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-13 >>>>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-14 >>>>>> = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-15 >>>>>>=20 >>>>>>=20 >>>>>> Meeting: 1 >>>>>> --------------------------------------------------------- >>>>>> Working Group Name: Messaging Layer Security >>>>>> Area Name: Security Area >>>>>> Session Requester: Sean Turner >>>>>>=20 >>>>>> Meeting Type: Virtual Meeting >>>>>>=20 >>>>>> Session 1: >>>>>>=20 >>>>>> Date: 2020-05-05 >>>>>> Start Time: 12:00 America/New_York >>>>>> Duration: 01:00 >>>>>> Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm7822117cbe3d654736b2dbaf0078e353= >>>>>> Agenda Note:=20 >>>>>=20 >>>>> Please note that the first of these interim meeting (the one = above) will be dedicated to key schedule related issues/PRs. >>>>>=20 >>>>> spt >>>>=20 >>>> Just another reminder about our interim tomorrow. We will be = focusing on key schedule related issues/PRs. >>>>=20 >>>> spt >>>=20 >>> Just a reminder that we have another interim tomorrow. >>>=20 >>> spt >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Mon Jun 22 07:34:06 2020 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 B91CE3A0D98; Mon, 22 Jun 2020 07:34:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159283644046.25340.17104203348004944656@ietfa.amsl.com> Date: Mon, 22 Jun 2020 07:34:00 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-07-07 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, 22 Jun 2020 14:34:01 -0000 The Messaging Layer Security (mls) WG will hold a virtual interim meeting on 2020-07-07 from 12:00 to 13:00 America/New_York (16:00 to 17:00 UTC). Agenda: GitHub Issues and Pull Requests: https://github.com/mlswg Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7f300037f89a213366d395bd400579a8 From nobody Mon Jun 22 07:34:28 2020 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 B010D3A0DCD; Mon, 22 Jun 2020 07:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159283645568.28182.15044181722790530618@ietfa.amsl.com> Date: Mon, 22 Jun 2020 07:34:15 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-07-14 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 14:34:24 -0000 The Messaging Layer Security (mls) WG will hold a virtual interim meeting on 2020-07-14 from 12:00 to 13:00 America/New_York (16:00 to 17:00 UTC). Agenda: GitHub Issues and Pull Requests: https://github.com/mlswg Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7f300037f89a213366d395bd400579a8 From nobody Mon Jun 22 21:11:01 2020 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 4E2DE3A1772 for ; Mon, 22 Jun 2020 21:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 CE88HmEF8U-o for ; Mon, 22 Jun 2020 21:10:50 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 D83733A1778 for ; Mon, 22 Jun 2020 21:10:46 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id h23so7320181qtr.0 for ; Mon, 22 Jun 2020 21:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=e5jlGt6G1qjay+PIlfiWbigguYLPV/8ddQf8etDDrlc=; b=jvDOlQqfwdaYnOVR/B7eh3iu0PgnvjisDDyXZxUhHGFQGxP7QzLBTd/chD+NW2lS25 blzqqfcda36dQvDsVRAVqKLORt7+Iu3bIKFJ523s0NFFBcAG/UUIii/LW6FVL18gMcIa PePgb4RD0ERIP8pjB7RNaoL3JBJss3VM65904= 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:message-id:references :to:date; bh=e5jlGt6G1qjay+PIlfiWbigguYLPV/8ddQf8etDDrlc=; b=mBmlHDm5Glkf+QeUhvspT7l6OnMwUj03zCq5YXYoJjO4Zrlp/d7GXfIXAqmTTfHtFe BFNOzsLG5sBMIt1zwDTs3s9e782hG1IoKVOlXsvs3pW/lbffmf81WfXbGK3bxB69CAZW 8+Ctmp7Ekbrw+yuto5D1xU46X2cEEAwH0S9SLttLZZJdwyrzyfgoxC0qSUmv9UhbAGSM dESBjhk0YtFvRLkeGUEM851Mh8+7ntJHl4E6iM1y+epNqkb0AtmdZO/RJWiEX08wpF/R eSuXELMy+48CpeODKhe716f52aIXx3D+C2SgLI2bHhZr9Ytr+wJAtJiSF6maSLYl83rd VfGw== X-Gm-Message-State: AOAM533H8DZtRYR9Ah6/Ta1Ny2bFembwzf5ga+O9EKQif92TAPezhk7Y f3Lav6wl4Ghss4lE58tPJ5435qVuQlg= X-Google-Smtp-Source: ABdhPJwWza0giaHFLtWo47Gqsr9TjuXca37oXkDu78RIKu0s/TrGES4QFZIGjN5gd4CAVQkVofOfXw== X-Received: by 2002:ac8:302f:: with SMTP id f44mr19926449qte.48.1592885445727; Mon, 22 Jun 2020 21:10:45 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id g4sm14646847qka.97.2020.06.22.21.10.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 21:10:45 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_A79C418A-1843-4676-9FD7-F25823DEF230" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <679414F1-F929-4F3F-9AB3-B2BED4733DE6@sn3rd.com> References: <159251992201.11993.15942540018989542642@ietfa.amsl.com> To: MLS List Date: Tue, 23 Jun 2020 00:10:44 -0400 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [MLS] Fwd: Nomcom 2020-2021 Final Call For Volunteers 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, 23 Jun 2020 04:11:01 -0000 --Apple-Mail=_A79C418A-1843-4676-9FD7-F25823DEF230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In case you are not on the IETF discuss list. spt > Begin forwarded message: >=20 > From: NomCom Chair 2020 > Subject: Nomcom 2020-2021 Final Call For Volunteers > Date: June 18, 2020 at 18:38:42 EDT > To: "IETF Announcement List" > Cc: ietf@ietf.org >=20 > Hi IETFers, > We're down to the last week of accepting NomCom volunteers. And I need = more! Lots more! >=20 > I have 64. I'd really like to get another 100 names. Hopefully, some = of you are checking the volunteer box on IETF 108 registration. But I = don't have anything from canceled IETF 107 registration, and the NomCom = question wasn't asked on IETF 106. So I need a flood of volunteers to = come in over the next week. > Barbara > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The IETF NomCom appoints people to fill the open slots on the LLC, = IETF Trust, the IAB, and the IESG. >=20 > Ten voting members for the NomCom are selected in a verifiably random = way from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population. >=20 > The details of the operation of the NomCom can be found in BCP 10 (RFC = 8713). RFC 3797 details the selection algorithm. >=20 > Special for this year (and only this year), we also have RFC 8788 = (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to = volunteer: >=20 > Members of the IETF community must have attended at least three = of > the last five in-person IETF meetings in order to volunteer. >=20 > The five meetings are the five most recent in-person meetings = that > ended prior to the date on which the solicitation for NomCom > volunteers was submitted for distribution to the IETF community. > Because no IETF 107 in-person meeting was held, for the 2020-2021 > Nominating Committee those five meetings are IETFs > 102 [Montreal, Canada; July 2018], > 103 [Bangkok, Thailand; November 2018], > 104 [Prague, Czech Republic; March 2019], > 105 [Montreal, Canada; July 2019], and=20 > 106 [Singapore; November 2019]. >=20 > Keep in mind that eligibility is based on in-person attendance at the = five listed meetings. You can check your eligibility at: = https://www.ietf.org/registration/nomcom.py. >=20 > If you qualify, please volunteer. Before you decide to volunteer, = please remember that anyone appointed to this NomCom will not be = considered as a candidate for any of the positions that the 2020 - 2021 = NomCom is responsible for filling. >=20 > People commonly volunteer by ticking the box on IETF registration = forms. The IETF 106 form did not ask whether people were willing to = volunteer. IETF 107 did ask, but all those registrations were canceled. = I have asked the Secretariat if it is possible to get the list if = volunteers from canceled IETF 107 registrations. If that list is = available, I will contact all who are verified as eligible. But given = the uncertainty of this process, I would encourage people to volunteer = directly (see the bottom of this email for instructions). Thank you for = volunteering! >=20 > The list of people and posts whose terms end with the March 2021 IETF = meeting, and thus the positions for which this NomCom is responsible, = are >=20 > IETF Trust: > Joel Halpern >=20 > LLC: > Maja Andjelkovic >=20 > IAB: > Jari Arkko > Jeff Tantsura > Mark Nottingham > Stephen Farrell > Wes Hardaker > Zhenbin Li >=20 > IESG: > Alissa Cooper, IETF Chair/GEN AD > Alvaro Retana, RTG AD > Barry Leiba, ART AD > Deborah Brungard, RTG AD > =C3=89ric Vyncke, INT AD > Magnus Westerlund, TSV AD > Roman Danyliw, SEC AD > Warren Kumari, OPS AD >=20 > All appointments are for 2 years. The Routing area has 3 ADs and the = General area has 1; all other areas have 2 ADs. Thus, all areas (that = have more than one AD) have at least one continuing AD. >=20 > The primary activity for this NomCom will begin in July 2020 and = should be completed in January 2021. The NomCom will have regularly = scheduled conference calls to ensure progress. There will be activities = to collect requirements from the community, review candidate = questionnaires, review feedback from community members about candidates, = and talk to candidates. >=20 > While being a NomCom member does require some time commitment it is = also a very rewarding experience. >=20 > As a member of the NomCom it is very important that you be willing and = able to attend either videoconference or in-person meetings (which may = not happen) during 14-20 November (IETF 109 - Bangkok) to conduct = interviews. Videoconference attendance will be supported whether or not = there are in-person meetings. Orientation and setting of the NomCom = schedule will be done by videoconference during the week 20-24 July = (exact time and date to be determined after NomCom membership is = finalized on July 12), the week prior to IETF 108. Being at IETF 110 = (Prague) is not essential. >=20 > Please volunteer by sending me an email before 23:59 UTC June 24, = 2020, as follows: >=20 > To: nomcom-chair-2020@ietf.org > Subject: NomCom 2020-21 Volunteer >=20 > Please include the following information in the email body: >=20 > Your Full Name:=20 > // as you write it on the IETF registration form >=20 > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form >=20 > Emails:=20 > // All email addresses used to register for the past 5 IETF meetings > // Preferred email address first >=20 > Telephone:=20 > // For confirmation if selected >=20 > You should expect an email response from me within 5 business days = stating whether or not you are qualified. If you don't receive this = response, please re-send your email with the tag "RESEND"" added to the = subject line. >=20 > If you are not yet sure if you would like to volunteer, please = consider that NomCom members play a very important role in shaping the = leadership of the IETF. Questions by email or voice are welcome. = Volunteering for the NomCom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the NomCom web site at: > https://datatracker.ietf.org/nomcom/2020/ >=20 > I will be publishing a more detailed target timetable, as well as = details of the randomness seeds to be used for the RFC 3797 selection = process, within the next few weeks. >=20 > Thank you! >=20 > Barbara Stark > bs7652 at att dot com > nomcom-chair-2020 at ietf dot org >=20 --Apple-Mail=_A79C418A-1843-4676-9FD7-F25823DEF230 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = case you are not on the IETF discuss list.

spt

Begin = forwarded message:

From: = NomCom Chair 2020 <nomcom-chair-2020@ietf.org>
Subject: = Nomcom 2020-2021 = Final Call For Volunteers
Date: = June 18, 2020 at 18:38:42 = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: ietf@ietf.org

Hi IETFers,
We're= down to the last week of accepting NomCom volunteers. And I need more! = Lots more!

I have 64. I'd really like to = get another 100 names. Hopefully, some of you are checking the volunteer = box on IETF 108 registration. But I don't have anything from canceled = IETF 107 registration, and the NomCom question wasn't asked on IETF 106. = So I need a flood of volunteers to come in over the next week.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DThe IETF NomCom appoints people to fill the open slots on = the LLC, IETF Trust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a = verifiably random way from a pool of volunteers. The more volunteers, = the better chance we have of choosing a random yet representative cross = section of the IETF population.

The details = of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC = 3797 details the selection algorithm.

Special= for this year (and only this year), we also have RFC 8788 (one-off = update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

     Members of the = IETF community must have attended at least three of
=      the last five in-person IETF meetings in = order to volunteer.

=      The five meetings are the five most recent = in-person meetings that
=      ended prior to the date on which the = solicitation for NomCom
=      volunteers was submitted for distribution = to the IETF community.
=      Because no IETF 107 in-person meeting was = held, for the 2020-2021
=      Nominating Committee those five meetings = are IETFs
       102 = [Montreal, Canada; July 2018],
=        103 [Bangkok, Thailand; = November 2018],
=        104 [Prague, Czech Republic; = March 2019],
=        105 [Montreal, Canada; July = 2019], and
       106 = [Singapore; November 2019].

Keep in mind = that eligibility is based on in-person attendance at the five listed = meetings. You can check your eligibility at: https://www.ietf.org/registration/nomcom.py.

If you qualify, please volunteer. Before you = decide to volunteer, please remember that anyone appointed to this = NomCom will not be considered as a candidate for any of the positions = that the 2020 - 2021 NomCom is responsible for filling.

People commonly volunteer by ticking the box on IETF = registration forms. The IETF 106 form did not ask whether people were = willing to volunteer. IETF 107 did ask, but all those registrations were = canceled. I have asked the Secretariat if it is possible to get the list = if volunteers from canceled IETF 107 registrations. If that list is = available, I will contact all who are verified as eligible. But given = the uncertainty of this process, I would encourage people to volunteer = directly (see the bottom of this email for instructions). Thank you for = volunteering!

The list of people and posts = whose terms end with the March 2021 IETF meeting, and thus the positions = for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja = Andjelkovic

IAB:
=    Jari Arkko
   Jeff = Tantsura
   Mark Nottingham
=    Stephen Farrell
   Wes = Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF = Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
=    Deborah Brungard, RTG AD
=    =C3=89ric Vyncke, INT AD
=    Magnus Westerlund, TSV AD
=    Roman Danyliw, SEC AD
=    Warren Kumari, OPS AD

All = appointments are for 2 years. The Routing area has 3 ADs and the General = area has 1; all other areas have 2 ADs. Thus, all areas (that have more = than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 = and should be completed in January 2021.  The NomCom will have = regularly scheduled conference calls to ensure progress. There will be = activities to collect requirements from the community, review candidate = questionnaires, review feedback from community members about candidates, = and talk to candidates.

While being a = NomCom member does require some time commitment it is also a very = rewarding experience.

As a member of the = NomCom it is very important that you be willing and able to attend = either videoconference or in-person meetings (which may not happen) = during 14-20 November (IETF 109 - Bangkok) to conduct interviews. = Videoconference attendance will be supported whether or not there are = in-person meetings. Orientation and setting of the NomCom schedule will = be done by videoconference during the week 20-24 July (exact time and = date to be determined after NomCom membership is finalized on July 12), = the week prior to IETF 108.  Being at IETF 110 (Prague) is not = essential.

Please volunteer by sending me = an email before 23:59 UTC June 24, 2020, as follows:

To: nomcom-chair-2020@ietf.org
Subject: NomCom = 2020-21 Volunteer

Please include the = following information in the email body:

Your= Full Name:
   // as you write it on the = IETF registration form

Current Primary = Affiliation:
   // Typically what goes in = the Company field
   // in the IETF = Registration Form

Emails:
=   // All email addresses used to register for the past 5 IETF = meetings
  // Preferred email address first

Telephone:
=    // For confirmation if selected

You should expect an email response from me within 5 business = days stating whether or not you are qualified.  If you don't = receive this response, please re-send your email with the tag "RESEND"" = added to the subject line.

If you are not = yet sure if you would like to volunteer, please consider that NomCom = members play a very important role in shaping the leadership of the = IETF.  Questions by email or voice are welcome. Volunteering for = the NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site = at:
   https://datatracker.ietf.org/nomcom/2020/
I will be publishing a more detailed target timetable, as = well as details of the randomness seeds to be used for the RFC 3797 = selection process, within the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf = dot org


= --Apple-Mail=_A79C418A-1843-4676-9FD7-F25823DEF230-- From nobody Tue Jun 23 06:46:15 2020 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 25C273A0E16 for ; Tue, 23 Jun 2020 06:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=cis-india.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 13Yc-oqBflTx for ; Tue, 23 Jun 2020 06:46:12 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 DDDD93A0E12 for ; Tue, 23 Jun 2020 06:46:11 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jnjFY-00067O-Lc for mls@ietf.org; Tue, 23 Jun 2020 15:46:09 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org 518485834AAAF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1592919968; bh=3TtFGS7dHhdKjrZVIlycLbPiYkLD4mL72CaR9dQ/U2M=; h=From:Mime-Version:Message-Id:Date:To; b=Rzd9NoeVdkzpnqWggYbUz5JtcuqhNLmMyCakxhATmguEGcggYTV9MiuvZKcQqqYks ZObPL0N1k5hD00vsBBWeviOA1zId+398tmKzXAmEA5+H4lfGRnui8v2blcu3wmlYbA J4aEcPe+QOKDhxitHiCJGigTokO+efdklpQQgdFWD2PPXZv7NiINkDH9LFfjiRfS/7 15NuTguEqkoqryuOnHaxeiFW4jPKyFa/mKZF7Itby+ZRpWW5QSqY6uFLM8MM9TLMYz 8Oq6+z+xWJIpdzyZtPql9Ac863Q64ceG+wh7olz7IeaEBKMM5aDBqCfpLsD59B6xuQ U6s+6kqhnMmVw== From: Divyank Katira Content-Type: multipart/alternative; boundary="Apple-Mail=_C11C5DA8-EE4D-4B16-B2A9-97119BD4FB3A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: Date: Tue, 23 Jun 2020 19:16:01 +0530 To: mls@ietf.org X-Mailer: Apple Mail (2.3601.0.10) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 025acf9a139f050bc01ccdeba87e03e0 Archived-At: Subject: [MLS] draft-ietf-mls-architecture-04 Review 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, 23 Jun 2020 13:46:14 -0000 --Apple-Mail=_C11C5DA8-EE4D-4B16-B2A9-97119BD4FB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all, Thank you for your efforts in developing MLS. Please find my review of = draft-ietf-mls-architecture-04 below. > Section 2.2 Authentication Service >=20 > =E2=80=9CIt is important to note that this signature keypair might be = the identity keypair directly, or a different signature keypair for = which the public key has been for example signed by the identity private = key. ... ... This flexibility also comes at the price of a = security tradeoff, described in the security considerations, between = potential unlinkability of the signature keys across groups and the = amount of time required to reinstate authentication and secrecy of = messages after the compromise of a device.=E2=80=9D There is a slight inconsistency here. The text mentions a description in = the security considerations section about a tradeoff between using = different signature keys across groups in place of the long term = identity key for unlinkability, and the time it would take to reinstate = post-compromise. However, I found no such description there, = particularly, in the =E2=80=98Client Compromise=E2=80=99 section. > Section 3.1.5. Privacy >=20 > =E2=80=9CA Messaging Service provider that has control over both the = AS and the DS, will not be able to correlate encrypted messages = forwarded by the DS, with the initial public keys signed by the AS.=E2=80=9D= This is marked as an open issue, and I agree with the comment in the = document that the privacy statements seem strong. While MLS does make = reasonable attempts to protect metadata through message padding and = encrypting sender information, a service provider may still correlate = senders and receivers of a message. A sender could be unmasked through = traffic analysis, by using the group identifier in the common case of a = group size of two, or through knowledge of group membership in the = server fan-out model. I think that this section should acknowledge such = practical limitations to the privacy properties of the protocol. > Section 3.2.1. Connections between Clients and Servers (one-to-one) >=20 > =E2=80=9C... the security of MLS will generally survive compromise of = the transport layer, so long as identity keys provided by the AS are = authenticated at a minimum. However, MLS ciphertext contains the Group = Identifier, Epoch number and Content Type that may be used to improve = attacks on the privacy of the group.=E2=80=9D This section on transport layer security compromise should also = acknowledge that MLS allows certain handshake messages (external = proposals, for example) to be sent as =E2=80=98MLSPlaintext=E2=80=99 = which could reveal information such as group membership, and have a more = direct impact on privacy of a group. I have also submitted a pull request with minor editorial changes here = https://github.com/mlswg/mls-architecture/pull/65 = Hope this helps! Regards, Divyank --Apple-Mail=_C11C5DA8-EE4D-4B16-B2A9-97119BD4FB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello all,

Thank you for your efforts in developing MLS. Please find my = review of draft-ietf-mls-architecture-04 below.

Section 2.2 = Authentication Service

=E2=80=9CIt is = important to note that this signature keypair might be the identity = keypair directly, or a different signature keypair for which the public = key has been for example signed by the identity private key. ... = <snip> ... This flexibility also comes at the price of a security = tradeoff, described in the security considerations, between potential = unlinkability of the signature keys across groups and the amount of time = required to reinstate authentication and secrecy of messages after the = compromise of a device.=E2=80=9D

There is a slight inconsistency here. The text mentions a = description in the security considerations section about a tradeoff = between using different signature keys across groups in place of the = long term identity key for unlinkability, and the time it would take to = reinstate post-compromise. However, I found no such description there, = particularly, in the =E2=80=98Client Compromise=E2=80=99 section.

Section = 3.1.5. Privacy

=E2=80=9CA Messaging Service = provider that has control over both the AS and the DS, will not be able = to correlate encrypted messages forwarded by the DS, with the initial = public keys signed by the AS.=E2=80=9D

This is marked as an open issue, and I agree with the comment = in the document that the privacy statements seem strong. While MLS does = make reasonable attempts to protect metadata through message padding and = encrypting sender information, a service provider may still correlate = senders and receivers of a message. A sender could be unmasked through = traffic analysis, by using the group identifier in the common case of a = group size of two, or through knowledge of group membership in the = server fan-out model. I think that this section should acknowledge such = practical limitations to the privacy properties of the protocol.

Section = 3.2.1. Connections between Clients and Servers (one-to-one)

=E2=80=9C... the security of MLS will = generally survive compromise of the transport layer, so long as identity = keys provided by the AS are authenticated at a minimum. However, MLS = ciphertext contains the Group Identifier, Epoch number and Content Type = that may be used to improve attacks on the privacy of the group.=E2=80=9D<= br class=3D"">

This = section on transport layer security compromise should also acknowledge = that MLS allows certain handshake messages (external proposals, for = example) to be sent as =E2=80=98MLSPlaintext=E2=80=99 which could reveal = information such as group membership, and have a more direct impact on = privacy of a group.

I have also submitted a = pull request with minor editorial changes here https://github.com/mlswg/mls-architecture/pull/65

Hope this helps!

Regards,
Divyank
= --Apple-Mail=_C11C5DA8-EE4D-4B16-B2A9-97119BD4FB3A-- From nobody Sun Jun 28 00:41:31 2020 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 C37663A0BED for ; Sun, 28 Jun 2020 00:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=mnot.net header.b=hcDVtQqj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NI2YuhWQ 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 XqpgGzsmaYC5 for ; Sun, 28 Jun 2020 00:41:24 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A943A0BEE for ; Sun, 28 Jun 2020 00:41:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 697C75C00E4 for ; Sun, 28 Jun 2020 03:32:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 28 Jun 2020 03:32:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=pqrZEvIDPHgy2qv0WAZifrLlqasbJX+M4EGxDgTGwTE=; b=hcDVtQqj U1l9nnrzU6mx4Ym6xhbPk4p/lB5XuwMnVx//JhoTGjQWiSjIjjN0F25xuClAZ36s ViSyfWcwdqBJawxxXG1fghY37LuATCbLOyjFsE17asf6DkmdU79Kezq9sSWEcMZF X2t2XNA8Yrm2Ma9KVoldgpufL8YvsCrRxAPt0wUx8EFeTmc8Wo4i0Ddyh4xP4zf4 XP2HFgIi7xS6zA/yatAtWPWvQOAUszxwoSRQWnBHUIs3mWGhRHO+DnOG/PiKFUfu 0QKGNsNObsqv3Q8FT8sot+yOWCB4dPB+XXsnV4MvyvPYX+rmEerUs0dTH9VDScUN xFnMBGafIDQzjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=pqrZEvIDPHgy2qv0WAZifrLlqasbJ X+M4EGxDgTGwTE=; b=NI2YuhWQniT62aalxhtJoKQ6XAj/Ga6PloHgkP1pukFl4 Z9feVFMv5K60fVSmsXAalgLYWIHQqBI5noZ+MrPIqK/J0hG/auuz9jOeIgkBrowI D2I7hLLT9gO6VsnSWK1/wW2b7vwP2dq69V+zgWcimlcXo2XFJRgTnY6Sx0oJ2aiK DEONVUOWlbhpaB0AfJWTKrNOpejCtOqP9wtfry4/SvN9PnswXXPlIIBaWk6MuTkJ Wn4CwvQ1VODHoQRoeMQ4FNsrH3dcOGD2SLBa0JzZoE6iO0Lh3LzFcRITCdaSNf3X 2twFErPVtQioI9AsAwoelB8GQNiYx9RvWkWSMmJ4w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelhedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddvheegrdefrddvvd eknecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59.internal.cloudapp.net (unknown [52.254.3.228]) by mail.messagingengine.com (Postfix) with ESMTPA id 434C83067AE1 for ; Sun, 28 Jun 2020 03:32:41 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6843757077348103997==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200628073241.434C83067AE1@mailuser.nyi.internal> Date: Sun, 28 Jun 2020 03:32:41 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) 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: Sun, 28 Jun 2020 07:41:27 -0000 --===============6843757077348103997== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-architecture (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Editorial changes (by d1vyank) https://github.com/mlswg/mls-architecture/pull/65=20 * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - misc little fixes (by uhoreg) https://github.com/mlswg/mls-protocol/pull/354=20 1 pull requests received 1 new comments: - #337 Replace DKDF by n-PRF in key schedule; minor fix (1 by jhoyla) https://github.com/mlswg/mls-protocol/pull/337 [discussion] [key schedu= le] [security] [work in progress]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============6843757077348103997== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday June 28, 2020

Pull requests

mlswg/mls-architecture (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

mlswg/mls-protocol (+1/-0/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============6843757077348103997==--