From nobody Sun Jan 2 00:16:03 2022 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 96B6D3A060D for ; Sun, 2 Jan 2022 00:16:00 -0800 (PST) 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=ma26SOl1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B4pLsdlZ 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 HHOhGvgNj8Hg for ; Sun, 2 Jan 2022 00:15:55 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77ED3A061B for ; Sun, 2 Jan 2022 00:15:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id EE9E03200E42 for ; Sun, 2 Jan 2022 02:39:38 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 02 Jan 2022 02:39:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=pPXQU4FwOP0 9d+jpfyLLBot3f/WWbVQVg6kinHTFyto=; b=ma26SOl1RenFJI2qn45M/W0IYdn l5ZIA8PGNQSk1UorR055r45uGMf7Gb+3BUwZdrQkiE0Ag5cJhffov2K6G1yBS4lJ YAtY6AASUUMqDPhzFcTUZYazLpEL4UK2BZqfroLXut/2eFxpSwqj22gKb+PG5KpM /ao+NPrJ9sOraMqQ7HRxQ1792ney6ewQld/BTVvBRcLNYDhS11meiDsrTmQ0jtwx e9GpwQf3MnQ1CoQgOirCYKYfk+yR4+odNNY45kvhyNvz5fkFTwY096a8aNF1qpyA cWaee3XpDnAPjvKxQqAkkHAL/ZFVYPyYQRutQs9n98/rayafHc5iH+JfleQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=pPXQU4FwOP09d+jpfyLLBot3f/WWbVQVg6kinHTFyto=; b=B4pLsdlZ UVpHAhJYaxpJUexi0lwgdn5+s52SERq33FHzbHSbAFIopfs8NETqtDxHiUo1mevl hxSpKBq9PQCnSD2ftvYubECmS5g7nvuIWkLcrQ9RxPqaG1vF5q9SW9guSXhYctoy bW5jKMhkJccKpeTbfrBW4Zk1Y6vSJPS+lGQW+8MfjFAsdLuwy1nH1pCWVbSiB21g fWFHFWTQVX8w1Mk2ldVuxgOO5pvJGGE4UVq48oduZuytuxD7d0zQD0PaEHqafxBX iOfGa/lTmpIYGt0jizDHk9pT8kyG18rV9GdsjQr9akGzyqp6W/IJURRIoTJD/WM1 992sYwe5d1cvSw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvkedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 2 Jan 2022 02:39:38 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4122554797868537493==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20220102081555.C77ED3A061B@ietfa.amsl.com> Date: Sun, 2 Jan 2022 00:15:55 -0800 (PST) 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, 02 Jan 2022 08:16:01 -0000 --===============4122554797868537493== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Get rid of explicit protocol version fields (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/532=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============4122554797868537493== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 02, 2022

Pull requests

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

1 pull requests submitted:

Repositories tracked by this digest:
--===============4122554797868537493==-- From nobody Sun Jan 9 00:51:20 2022 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 1FB213A0FB0 for ; Sun, 9 Jan 2022 00:51:18 -0800 (PST) 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=KmrjTOcP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eAYZ1PcH 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 jEoFgRegaHji for ; Sun, 9 Jan 2022 00:51:13 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09303A0FB6 for ; Sun, 9 Jan 2022 00:51:13 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id ED1493200C14 for ; Sun, 9 Jan 2022 02:40:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 09 Jan 2022 02:40:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=HMqLQm8yq26 aflEI/sk6t2Jex1Hgs0GzIFxGnqP4iFk=; b=KmrjTOcP/mlCuy/w71aD6Pr7Qje /yYEotHYQJx5pPLbpss40fnwvkC9Pg8ANZQ4YP9U78EFb+mtdWDjA7VhBhZ/+jje 7LE5sb23cY5CsCZ/z+5sHhHROPS55BppHaHqPfZuShrJxCfNxojTDgVvRHliwTkP UuFYy9fJwWH7F/EDEQI2LTJTVtkvd3dwOahSXVC/vTUoNTYc6LrpdqWzIGcRRgFp oB8Ji0EFqk3tUV62BIPFEs9f/+BZVfUJ47UdbMOD/AS5eypI7Ebd8vRvMJeKipvK n8+PbmPzkPqsgCgc3dFtUd51v2yHck/X8wTmoDm8t2iBn7DIt3y7AIei4eQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=HMqLQm8yq26aflEI/sk6t2Jex1Hgs0GzIFxGnqP4iFk=; b=eAYZ1PcH 9KTRxp1Qh4pm9qJIBtmGfAXFP95WeL8QX9DsIiPpdyk7rNVi/HSIPdDXg5pjW4NV 9sHeR0wEYUH6QUwkYmCujoPOKjIOK1n08gsHBnA2OI0ZfyFRe7ny1vCCYiV8n37z 6E+oa48fjl5XGa9mi9F+AojJARxpz5YqRMDmVI2bMoiJ2AZgTiLtd3ID5LrgXGqP Q3dKjZIXVC11iZM7zuXNVq1TStfpc8jAGHnwe8MzIw9PoXhfNkg5aotVSSWIXt8O xw/QDxRe9cFoJJi5penRhXM8/eicCN+lFciO3k3e413HVpPLY0oZPOdMD63ZlvlE nkA9qfKDIMp/2g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudegjedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 9 Jan 2022 02:40:01 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4908916445543606051==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20220109085113.B09303A0FB6@ietfa.amsl.com> Date: Sun, 9 Jan 2022 00:51:13 -0800 (PST) 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, 09 Jan 2022 08:51:18 -0000 --===============4908916445543606051== 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=AC3) 1 issues created: - Improve padding description (by tomleavy) https://github.com/mlswg/mls-protocol/issues/534=20 3 issues received 3 new comments: - #534 Improve padding description (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/534=20 - #530 Require uniqueness of RatchetTreeExtensions in GroupInfo (1 by bif= urcation) https://github.com/mlswg/mls-protocol/issues/530=20 - #528 Include `context` in `MLSPlaintextTBS` for sender_type `NewMember`= (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/528=20 Pull requests ------------- * mlswg/mls-protocol (+1/-1/=F0=9F=92=AC2) 1 pull requests submitted: - Fix typo in EncryptedGroupSecrets (by TWal) https://github.com/mlswg/mls-protocol/pull/533=20 2 pull requests received 2 new comments: - #532 Get rid of explicit protocol version fields (1 by ekr) https://github.com/mlswg/mls-protocol/pull/532=20 - #527 Stronger parent hashes for authenticated identities (1 by bifurcat= ion) https://github.com/mlswg/mls-protocol/pull/527=20 1 pull requests merged: - Fix typo in EncryptedGroupSecrets https://github.com/mlswg/mls-protocol/pull/533=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============4908916445543606051== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 09, 2022

Issues

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

1 issues created:

3 issues received 3 new comments:

Pull requests

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

1 pull requests submitted:

2 pull requests received 2 new comments:

1 pull requests merged:

Repositories tracked by this digest:
--===============4908916445543606051==-- From nobody Mon Jan 10 11:42:56 2022 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 5386D3A0EFF for ; Mon, 10 Jan 2022 11:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=wire-com.20210112.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 JiONVXsOzFmk for ; Mon, 10 Jan 2022 11:42:49 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 BC6473A0EFC for ; Mon, 10 Jan 2022 11:42:49 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id z3so13554217plg.8 for ; Mon, 10 Jan 2022 11:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=wC+w/WUnAGONV2gC3DUhUJ040GIpek1nkMtvwLytnB8=; b=wtaQGek5rZZrKpB5RQdPiw5E0YODXrsR0h3CegH22s/uQahVUMbaLfsS0iJgMIQeia 6bG7G72tXF+k/sKNXFNPMnCgN108mhXVeIjgQZOI0jeERokTzEeZWK2Wry7suawy/BX8 HZUv71MuZLSiWHn+qZMDLlFOi5jcL7E6Q68oH0Z0Z/6xzuh3MpTK7WmYqZ6F+/dL28nr xHy1JGiJ5xI3cSGwIM9u0ZtZhCz4aqKUkLCRdD7LnMSDTaG1iGv9oPuvRWg1cOw1zteR pjGxJ8DKsHOIk7VzCalbRGBlW7ObXFnmWqznmCpZGbgr+MvlE1djKItvmXGwCixH9wfM SqyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wC+w/WUnAGONV2gC3DUhUJ040GIpek1nkMtvwLytnB8=; b=S4WsJo4I7AqFZvb4JjOrJXE7HjEpK4piRc3Myp3ePx6DglDnXEjIzzXaiFrdw4/Y5R +aiTIGJjLpmKcmmh+oVQ+v6xQmpiCVQa1+cuDBmUEvY6zi7jyEWPKT/g8HymOKpRnBRV o5rz2AnzSLI8E51GV1b3vqoYpsv1J0EC3MjqX/xHU7gx5GyNw3Grd5gZewngHX7E6foc kLcexxStO+D57qSky2uHsGUdpINXRJTr3W/lcSpu9h3oP/ai40WGGjzkph0Y5NgUFdxF rpJLYLVthnlG8PtaSmn6KWTwMHkTO/+kQxUkzcIXNJOMUVFjpPsDaVoiXdjB3E5nN+Hc 9BoA== X-Gm-Message-State: AOAM532+GRHHQyG9x2JetnUdW4ggpWRtR9rVo1GS13ul26djEZ/6PtcK ML1FQMfWDNjMAd8SaWJHRKbr2xoXhm24O9vGy5Cvw16AC5w0Xg== X-Google-Smtp-Source: ABdhPJxyX2xCh6cckpwwmwpuNSJo+iuagmC8GPSSn9ShurFDeUZ78zDajbma9MiADuTXgzY4F+vYnjmvzLjtiA38jK0= X-Received: by 2002:a63:6ecf:: with SMTP id j198mr1052886pgc.287.1641843767155; Mon, 10 Jan 2022 11:42:47 -0800 (PST) MIME-Version: 1.0 From: Rohan Mahy Date: Mon, 10 Jan 2022 11:42:36 -0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000084b4e505d53f8ab8" Archived-At: Subject: [MLS] TLS WireFormat: include Welcome and Public 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, 10 Jan 2022 19:42:54 -0000 --00000000000084b4e505d53f8ab8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, When implementing a distribution server, I think it should be possible to send application messages, handshake messages, welcome messages, and public group state messages over the same channel. The current format doesn't allow that. This seems like an important oversight. I propose a small modification by adding the WireFormat enum at the beginning of Welcome and PublicGroupState, and adding the two types to WireFormat. If we don't do this, I can expect someone in the IESG bringing this up at a much less convenient time. enum { reserved(0), mls_plaintext(1), mls_ciphertext(2), mls_welcome(3), mls_publicgroupstate(4), (255) } WireFormat; struct { WireFormat wire_format =3D mls_welcome; ... } Welcome; struct { WireFormat wire_format =3D mls_publicgroupstate; ... } PublicGroupState; Thanks, -rohan *Rohan Mahy *l Vice President Engineering, Architecture Chat: @rohan_wire on Wire Wire - Secure team messaging. *Zeta Project Germany GmbH *l Rosenthaler Stra=C3=9Fe 40, 10178 Berlin, Germany Gesch=C3=A4ftsf=C3=BChrer/Managing Director: Morten J. Broegger HRB 149847 beim Handelsregister Charlottenburg, Berlin VAT-ID DE288748675 --00000000000084b4e505d53f8ab8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
When implementing a distribution s= erver, I think it should be=20 possible to send application messages, handshake messages, welcome=20 messages, and public group state messages over the same channel. The=20 current format doesn't allow that. This seems like an important oversig= ht.

I propose a small modification by adding the W= ireFormat enum at the beginning of=20 Welcome and PublicGroupState, and adding the two types to WireFormat. If we= don't do this, I can expect someone in the IESG bringing this up at a = much less convenient time.



enum {
=C2=A0 reserved(0),
=C2=A0 mls_plaintext(1),
=C2=A0 = mls_ciphertext(2),
=C2=A0 mls_welcome(3),
=C2=A0 mls_pu= blicgroupstate(4),
=C2=A0 (255)
} WireFormat;

struct {
=C2=A0WireFormat wire_format =3D mls_welcom= e;
...
} Welcome;

struct = {
=C2=A0WireFormat wire_format =3D mls_publicgroupstate;
...
} PublicGroupState;

Thanks,
<= div>-rohan




=

Rohan Mahy=C2=A0 l=C2=A0 Vice President Engineering, Architecture<= br>

Chat: @roha= n_wire on=C2=A0Wire

=C2=A0

Wire=C2=A0- Secure team messaging.

Zeta Project Germany GmbH=C2=A0=C2=A0l=C2=A0=C2=A0Rosenthaler Stra=C3= =9Fe 40,=C2=A010178 Berlin,=C2=A0Germany

Gesch=C3=A4ftsf=C3= =BChrer/Managing Director: Morten J. Broegger=C2=A0

H= RB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE28874867= 5

--00000000000084b4e505d53f8ab8-- From nobody Mon Jan 10 12:29:07 2022 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 5DA483A0124 for ; Mon, 10 Jan 2022 12:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=wire-com.20210112.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 z_bemVkzLX8e for ; Mon, 10 Jan 2022 12:29:00 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 C852F3A0125 for ; Mon, 10 Jan 2022 12:29:00 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id t18so4218901plg.9 for ; Mon, 10 Jan 2022 12:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=oN7RiLix4SLvPVGKpKQEORsJPNoQDpJgX3Xsb62Oaic=; b=qjgbtVs6Tz2RjkKoXefZ8BW0t/uhbXW0XgLhIMvF/e4l6ouSBwRk9sA+ZkE4YN/82e MXGrrI7Z+nW6zq6OQLySqh+hkv9y1xNP4mgMwfpGcSV0qsCIVdPQaMKdZU8HjIkj9cVf /Df1CQB4ujzBsyA2/PuSFnhoUMXDafC1V2XXAuK0lzVvi1rvuZnKYSZY8gtBzzT6VxSx Tx4rSJNS3oyuMHh6aJ0+q3HgwVtwJ/sG11R4wR1j2CoUuVYK3Hg3VIXdni7Vpb9c18/v 0lwJDlqp3A61mJXgorHacB01XHnKTega4tYTxs3CZ+hMtA5jY3AuVa3vZ4e/zytcPdJC Dcmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oN7RiLix4SLvPVGKpKQEORsJPNoQDpJgX3Xsb62Oaic=; b=3iB41c77EdCTDGIdEDTHVxhoAc/qbHmmI2JnCDBHKUtMawhs9BwmjQ8781hT1fv2Hh Znmh0eGLYbCazlz1ZxvWsXnkgKWqO9Mibx2Abar0vamoYcvk4Cx1NyZPX31fXG5qApwn cUx+1tq8XF3IubIhAlrp1iSsONxZ7b/PSOPLvGdU3MiLcD0FycAodisas9ggrQy+Ag5o znC4oYUI1OOt/5p4AB/CmXQL3/AZNX31QNMxYHexcumAlqupVnDZF+YHLU0pG6wAPEDb +1fVMRT7DWfw5BzXPCLuOVFY2FFWw14o5L/UDye+Djme2koWfzuaAjvueObdk5tuWVkz Yhyg== X-Gm-Message-State: AOAM531sVIMSOjgd3l+MDQ+2AL6DzLemw+EQKAbisA3YJSNbTGY/GGLb STsmnCT9I6lFNzLdzZlnzJcDSER1lof0aeiBt2Q7aGSgpG/Y4w== X-Google-Smtp-Source: ABdhPJwfuden6wgBug45CTv25BxFU19PojPgLH0VE8NYCa5uijiwyIjDQ/EFJFWOpOvbnxAqWC1k4cSXncIf/Y5DDF0= X-Received: by 2002:a05:6a00:1a4f:b0:4bb:113a:677c with SMTP id h15-20020a056a001a4f00b004bb113a677cmr1210824pfv.63.1641846539087; Mon, 10 Jan 2022 12:28:59 -0800 (PST) MIME-Version: 1.0 From: Rohan Mahy Date: Mon, 10 Jan 2022 12:28:48 -0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000bd087605d5402fcb" Archived-At: Subject: [MLS] TLS presentation layer 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: Mon, 10 Jan 2022 20:29:06 -0000 --000000000000bd087605d5402fcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I've started rereading the spec from scratch trying to look at it in detail with fresh eyes. The following issues are related to our use of the TLS Presentation format. 1) The Comment format uses // in several places as a comment. But both TLS1.2 and TLS1.3 specify only /* */ for comments. 2) "authenticated_data" is a poor name, as it is alongside a bunch of other data which will all be authenticated. What is special about this authenticated data? At least there is some explanation of the separate "additional_authenticated_data" field. 3) There are a few places where "optional" is used, that are required or forbidden in specific cases that are straightforward to fully specify (reformulated below). 4) We shouldn't reuse a presentation stanza (MLSPlaintext) both for a wire framing format and for an intermediary unless they are the same (see reformulation below). struct { WireFormat wire_format; opaque group_id<0..255>; uint64 epoch; Sender sender; opaque extra_authenticated_data<0..2^32-1>; ContentType content_type; select (MLSPlaintext.content_type) { case application: opaque application_data<0..2^32-1>; case proposal: Proposal proposal; case commit: Commit commit; } } MLSPlaintextTBS; struct { WireFormat wire_format =3D mls_plaintext; opaque group_id<0..255>; uint64 epoch; Sender sender; opaque extra_authenticated_data<0..2^32-1>; ContentType content_type; select (MLSPlaintext.content_type) { case proposal: Proposal proposal; case commit: Commit commit; } opaque mls_plaintext_signature; select (MLSPlaintext.content_type) { case commit: opaque confirmation_tag; } select (MLSPlaintext.sender.sender_type) { case member: opaque membership_tag; } } MLSPlaintext; struct { select (MLSCiphertext.content_type) { case application: opaque application_data<0..2^32-1>; opaque signature<0..2^16-1>; case proposal: Proposal proposal; opaque signature<0..2^16-1>; case commit: Commit commit; opaque signature<0..2^16-1>; MAC confirmation_tag; } opaque padding<0..2^16-1>; } MLSCiphertextContent; Thanks, -rohan *Rohan Mahy *l Vice President Engineering, Architecture Chat: @rohan_wire on Wire Wire - Secure team messaging. *Zeta Project Germany GmbH *l Rosenthaler Stra=C3=9Fe 40, 10178 Berlin, Germany Gesch=C3=A4ftsf=C3=BChrer/Managing Director: Morten J. Broegger HRB 149847 beim Handelsregister Charlottenburg, Berlin VAT-ID DE288748675 --000000000000bd087605d5402fcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I've started rereading the spec fro= m scratch trying to look at it in detail with fresh eyes. The following iss= ues are related to our use of the TLS Presentation format.
<= br>
1) The Comment format uses // in several places as a comment.= But both TLS1.2 and TLS1.3 specify only /*=C2=A0 */ for comments.

2) "authenticated_data" is a poor name, as i= t is alongside a bunch of other data which will all be authenticated. What = is special about this authenticated data? At least there is some explanatio= n of the separate "additional_authenticated_data" field.

3) There are a few places where "optional" = is used, that are required or forbidden in specific cases that are straight= forward to fully specify (reformulated below).

4) = We shouldn't reuse a presentation stanza (MLSPlaintext) both for a wire= framing format and for an intermediary unless they are the same (see refor= mulation below).

struct {
=C2=A0 =C2=A0 Wir= eFormat wire_format;
=C2=A0 =C2=A0 opaque group_id<0..255>;
=C2= =A0 =C2=A0 uint64 epoch;
=C2=A0 =C2=A0 Sender sender;
=C2=A0 =C2=A0 o= paque extra_authenticated_data<0..2^32-1>;
=C2=A0 =C2=A0 ContentTy= pe content_type;
=C2=A0 =C2=A0 select (MLSPlaintext.content_type) {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 case application:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 opaque application_data<0..2^32-1>;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 case proposal:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Proposal pr= oposal;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case commit:
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Commit commit;
=C2=A0 =C2=A0 }
} MLSPlaintextTBS;
<= br>struct {
=C2=A0 =C2=A0 WireFormat wire_format =3D mls_plaintext;
= =C2=A0 =C2=A0 opaque group_id<0..255>;
=C2=A0 =C2=A0 uint64 epoch;=
=C2=A0 =C2=A0 Sender sender;
=C2=A0 =C2=A0 opaque extra_authenticate= d_data<0..2^32-1>;
=C2=A0 =C2=A0 ContentType content_type;
=C2= =A0 =C2=A0 select (MLSPlaintext.content_type) {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 case proposal:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Proposal proposal;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case commit:
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Commit commit;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 opaque mls_plain= text_signature<Signature_length>;
=C2=A0 =C2=A0 select (MLSPlainte= xt.content_type) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case commit:
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque confirmation_tag<MAC_length>= ;;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 select (MLSPlaintext.sender.sender_t= ype) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case member:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 opaque membership_tag<MAC_length>;
=C2=A0 =C2= =A0 }
} MLSPlaintext;

struct {
=C2=A0 =C2=A0 select (MLSCipher= text.content_type) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case application:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque application_data<0..2^32-1>= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque signature<0..2^16-1>;<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case proposal:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Proposal proposal;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque = signature<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case commit:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Commit commit;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 opaque signature<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 MAC confirmation_tag;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 opa= que padding<0..2^16-1>;
} MLSCiphertextContent;


Thanks,
-rohan

Rohan Mahy=C2=A0 l=C2=A0 Vice President Engineering, Architecture

Chat: @rohan_wire on=C2=A0Wire

=C2=A0

Wire=C2=A0- Secure= team messaging.

Zeta Project Ge= rmany GmbH=C2=A0=C2=A0l=C2=A0=C2=A0Rosenthaler Stra=C3=9Fe 40,=C2=A0101= 78 Berlin,=C2=A0Germany

=

Gesch=C3=A4ftsf=C3=BChrer/Managing Director: = Morten J. Broegger=C2=A0

<= p class=3D"MsoNormal" style=3D"color:rgb(0,0,0)">

HRB 149847 beim Handelsregis= ter Charlottenburg, Berlin

VAT-ID DE288748675

--000000000000bd087605d5402fcb-- From nobody Sat Jan 15 23:46:10 2022 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 423DE3A0AA7 for ; Sat, 15 Jan 2022 23:46:05 -0800 (PST) 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=QpSUEgJd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KkHuyl0y 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 Hz0oomIXiNgN for ; Sat, 15 Jan 2022 23:45:59 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DE73A0A9A for ; Sat, 15 Jan 2022 23:45:59 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 823C23200E5D for ; Sun, 16 Jan 2022 02:40:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 16 Jan 2022 02:40:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=g2yIg6RzETp 6JRzukL6ekcp7DbdvfJJ3XKJgk9jr1uc=; b=QpSUEgJdhDJfSPkfAdP6L3c5GTy O6JibkkgRt3JFpizhPi6DqksKMiYYt7mRLQBEG5deTZrFWZiH9gIu0VCqKBJKET8 yTXcAUOznz6hzoaLioee6vPxlaKXOJqjY2TqzxF5OWk6Z8Q73HoT9EIBvPpDje+m 2ggp3kE40dwYZNYPiM8PriWUULnsfmKSsgSQaggg806PBaui6Qd2NE9rC8FILOGw Ico9HSB2FADjHeKvQXAUbGLliJYZoBUau75Lnw/Gi/PuQsfvwpxCM0Uz0hfOEj07 7KPagnoY4w6DlW0xQjXiia8qc/ViyWMXZnSLF2N8cVgpA3bWDDrMja40ABA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=g2yIg6RzETp6JRzukL6ekcp7DbdvfJJ3XKJgk9jr1uc=; b=KkHuyl0y kH0RYjcnvxpLuAfBzVvocdrwaAojMFVQiQoeAmF5U0/FSH+pY/8JC2kDFY5r8f8v Q3AF+J3/GL/V58zzoJLTF7VJHY5sToU2ziKn5Q72vtpQXysPDUrnhVOoWLzOj1tX x4X6OKID86VCImPPy/QJIezpKv8ILc3b6gE6IpJeHQ+UKQRSv8A7Gdzu60iRSDs1 zZCT3lPoqzzPJ5tKSDkUXM1gxyfZWzhW5FR4lVstQ0I5OkTsd6X0PoholLfJDhDN rKpijICqHxIp57nyXbjMvAz3gG1otlm771tygIaHooR5P9FWAjuvTwr3Ef1k0dND BFXYFhsQKKsaZw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdekgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 16 Jan 2022 02:40:17 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8260921074975826655==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20220116074559.23DE73A0A9A@ietfa.amsl.com> Date: Sat, 15 Jan 2022 23:45:59 -0800 (PST) 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, 16 Jan 2022 07:46:05 -0000 --===============8260921074975826655== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+4/-0/=F0=9F=92=AC13) 4 issues created: - Proposals by reference in external commit (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/540=20 - Separation between pre-published key packages and leaf node content (by= TWal) https://github.com/mlswg/mls-protocol/issues/539=20 - KeyPackage lifetime handling (by tomleavy) https://github.com/mlswg/mls-protocol/issues/538=20 - Clarity around extensions and `RequiredCapabilities` (by tomleavy) https://github.com/mlswg/mls-protocol/issues/537=20 4 issues received 13 new comments: - #539 Separation between pre-published key packages and leaf node conten= t (7 by TWal, kkohbrok, tomleavy) https://github.com/mlswg/mls-protocol/issues/539=20 - #538 KeyPackage lifetime handling (4 by kkohbrok, tomleavy) https://github.com/mlswg/mls-protocol/issues/538=20 - #534 Improve padding description (1 by tomleavy) https://github.com/mlswg/mls-protocol/issues/534=20 - #530 Require uniqueness of RatchetTreeExtensions in GroupInfo (1 by kko= hbrok) https://github.com/mlswg/mls-protocol/issues/530=20 Pull requests ------------- * mlswg/mls-protocol (+3/-0/=F0=9F=92=AC12) 3 pull requests submitted: - Make some sections easier to read. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/541=20 - Reword padding section to reflect updated padding structure (by tomleav= y) https://github.com/mlswg/mls-protocol/pull/536=20 - Require extensions to be unique in any given extensions vector (by kkoh= brok) https://github.com/mlswg/mls-protocol/pull/535=20 5 pull requests received 12 new comments: - #532 Get rid of explicit protocol version fields (2 by kkohbrok, raphae= lrobert) https://github.com/mlswg/mls-protocol/pull/532=20 - #529 Refactor Group Joining and fix External Inits (2 by kkohbrok, raph= aelrobert) https://github.com/mlswg/mls-protocol/pull/529=20 - #527 Stronger parent hashes for authenticated identities (4 by TWal, kk= ohbrok, raphaelrobert) https://github.com/mlswg/mls-protocol/pull/527=20 - #524 Careful truncation (1 by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/524=20 - #523 Move `wire_format` to a separate tagged-union structure MLSMessage= (3 by TWal, kkohbrok, rohan-wire) https://github.com/mlswg/mls-protocol/pull/523=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============8260921074975826655== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 16, 2022

Issues

mlswg/mls-protocol (+4/-0/=F0=9F=92=AC13)

4 issues created:

4 issues received 13 new comments:

Pull requests

mlswg/mls-protocol (+3/-0/=F0=9F=92=AC12)

3 pull requests submitted:

5 pull requests received 12 new comments:

Repositories tracked by this digest:
--===============8260921074975826655==-- From nobody Tue Jan 18 08:27:19 2022 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 874BA3A0962 for ; Tue, 18 Jan 2022 08:27:17 -0800 (PST) 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 DwFrVcsrptTS for ; Tue, 18 Jan 2022 08:27:12 -0800 (PST) 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 58A733A0961 for ; Tue, 18 Jan 2022 08:27:12 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id p9so8084109qkh.3 for ; Tue, 18 Jan 2022 08:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Se0o+2udxMwseAvRTU60nbAGfL89GQQF9NrvzUwMH6E=; b=hB7T2iFVvMMKt8OPUzpyjDsG8/fIbOnpz6pvIQzB4RyKA/gKtcrybRsfOG1fjrNlxy W9lcKvlTUCR7MnmUk4GoQO75KVSougmOkfsNCCUGz6A6icw3HGflfcFZ7p59nu+n1feL hJVNXSU9JuRJmvoEoX1i0wY7tTGJFR1s7ZAk0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Se0o+2udxMwseAvRTU60nbAGfL89GQQF9NrvzUwMH6E=; b=AqrYDhZSMu+/yBm82LFu6s8Ahn9PKofDh4TeQnQ13+WOHqMU16JbXfThMA9rHGAmXZ 2V1uh77h2Huw6n7JEwwjrpEXnlyd8+B6I1IvwAjVodusJu961ei/kStB32Ltw60W4Xed lg7YimMyxXIGeL5yTPaSsXE5JodkE3IweaTlFAlEDBtFT6j5+8xJAU/f9UgEn/ZoqaMY /YQGWMOfW9/wwxWpA8D3abJgHQFB1pj2cqN8GWHBbfHKsEXfAcMqJhexfkMvdwriQ1+f FL/cjsKjUAa0MtmE5ua6Vho6X6ok4V31HxzthBFX6Z+MKrXRzryqVXk1ORVrOf5Fk7Qz lsZQ== X-Gm-Message-State: AOAM531DCzdsvDaCTXuidM+rhfSAdCpr3DUVA2gLGJo/oldO+I/hXdU3 wRC4BZay3Kaph6gX+UFzR4QN+8vIguTK1w== X-Google-Smtp-Source: ABdhPJzh22pzvN83OG7kmOuHISb86omOZnj+ggyXIwLEKQHcOZSpD3sn6wnj0KChuv8wmwP6V3vl9g== X-Received: by 2002:a37:786:: with SMTP id 128mr16602760qkh.431.1642523230374; Tue, 18 Jan 2022 08:27:10 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id w15sm9684972qkf.25.2022.01.18.08.27.09 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jan 2022 08:27:09 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: Date: Tue, 18 Jan 2022 11:27:08 -0500 To: MLS List X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [MLS] mls@ietf113: session 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, 18 Jan 2022 16:27:18 -0000 Hi! Scheduling requests can now be submitted for IETF 113 [0]. Does the = group think that a session will be needed? spt [0] https://www.ietf.org/how/meetings/113/= From nobody Tue Jan 18 08:57:25 2022 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 A665B3A0DD5 for ; Tue, 18 Jan 2022 08:57:23 -0800 (PST) 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.20210112.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 7NJeyqLMr5ID for ; Tue, 18 Jan 2022 08:57:19 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 6C7393A0DCA for ; Tue, 18 Jan 2022 08:57:19 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id v7so22773345qtw.13 for ; Tue, 18 Jan 2022 08:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hOH5mM5qZ40vxSZktGJFVIUB+iWwLG6wxn0HP7FZiWQ=; b=Icptsr1ZSaNk0HA3sqzhYZ4Qp5NylB0aoHSvmzDmAAKiOfqYkjW4aFMlqnNI6mvt83 rG509WAkJpMkN3obvfJPaPreuC/VSby2xGbrahGQofYHvOmUJ2d2vBTAoLbW2qUjY6ri 83rzBsw7Ggc1aPWV+AyBSOqRqFDaeNKVuGnbEmACwbW8bMUpCGbmt6bYw4v2wvRKcANG 6UvAhANe37YdPSx7ucmDrq1QPc69gM0vQDKo0YX0wfyYUPMer7lXSv1/Lhc4B3fUNLln O5Te7QpxLyuuw2kVF5vffrRLteKq1IgUcPegYiVHtvW4dc7UdlSogrZhVgkhQnn2xfea d6XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hOH5mM5qZ40vxSZktGJFVIUB+iWwLG6wxn0HP7FZiWQ=; b=LFqo/9jtYIZHMIWMWU37x0Akq/KmjhdTT4hqcYlmMt6qL4FCZ0ciY3hG5cY/1B6hcg FN+Jd1X0+l0tvtdJoe0gHyQkpo78tke4zraaRgakU7wFQHAlRoQEZY749e+7hRz9skCh m1+DitD/waNYdh0J4DFv6wKbIkpH9tO1sV0WfxCy54AKwuScx1ef6RcgRCS09jw22ETq IA2L0bMFDnUQyhDyiPlOWmwail3OUg1hTSeeEF3+jEgPeMipXVaQ7n32m8DiDdNnceV0 uYnkZcEOoW2RHT4X+nAE7uXE1u43ZbQv1yXG40QrICUQO+gtoyO8dSKsaTU3GZ2rL2dV meLQ== X-Gm-Message-State: AOAM533dfHpWoIrR+zFVAQsueWCKwCmzDW4swd+x3261ZRNy+tsp/uHj R0v0kqL09MZwFtw8akubl7V4eMJnfz3DU8AhplICioik0xU= X-Google-Smtp-Source: ABdhPJxRq/Pg5zjtyKKwuZ3e2Rx0/uTFIvZztrWrSiTllxEcbtprN5ze9zQmjHH79L+64AaiRMV0AaL3jj41uoog470= X-Received: by 2002:a05:622a:390:: with SMTP id j16mr21609438qtx.122.1642525037612; Tue, 18 Jan 2022 08:57:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 18 Jan 2022 11:57:06 -0500 Message-ID: To: Sean Turner Cc: MLS List Content-Type: multipart/alternative; boundary="00000000000066e15305d5de29e4" Archived-At: Subject: Re: [MLS] mls@ietf113: session 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, 18 Jan 2022 16:57:24 -0000 --00000000000066e15305d5de29e4 Content-Type: text/plain; charset="UTF-8" Yes. Hopefully we will be in/past WGLC then, but (a) we will likely have a few things to discuss out of that, and (b) even if not, it would be good to discuss what to do next (e.g., federation?) On Tue, Jan 18, 2022 at 11:27 AM Sean Turner wrote: > Hi! Scheduling requests can now be submitted for IETF 113 [0]. Does the > group think that a session will be needed? > > spt > > [0] https://www.ietf.org/how/meetings/113/ > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000066e15305d5de29e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes.=C2=A0 Hopefully we will be in/past WGLC then, but (a)= we will likely have a few things to discuss out of that, and (b) even if n= ot, it would be good to discuss what to do next (e.g., federation?)

On T= ue, Jan 18, 2022 at 11:27 AM Sean Turner <sean@sn3rd.com> wrote:
Hi! Scheduling requests can now be submitted for IETF 113= [0]. Does the group think that a session will be needed?

spt

[0] https://www.ietf.org/how/meetings/113/
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000066e15305d5de29e4-- From nobody Thu Jan 20 13:28:10 2022 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 4E93C3A2279 for ; Thu, 20 Jan 2022 13:28:08 -0800 (PST) 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.20210112.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 ciFhUFZFHzRP for ; Thu, 20 Jan 2022 13:28:03 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 735083A2275 for ; Thu, 20 Jan 2022 13:28:03 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id d24so7694086qkk.5 for ; Thu, 20 Jan 2022 13:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=vQMuULjA13CEVr0LRZU1KoWRAasRrv5tXclwAlenH3U=; b=iEur0iGglSeT4wSGTYC/yAjrHgBVRrFyM1jniAUCtRagsJPSDsPrX0S6iChpvzw3gD d1EsKAXiIPbcSqWBGsfZYsZcBtiVUdV7P8ZHX1cKxE3kjgnRRwUFDMs9SrQ3rVHiaHPn /Hnh6nNLkJxGI9nFC1zhkBLogCi6hTaK2sH/bcfQwgaNsPVkrzwHBDVIGTwrFhp7lda3 4gKota60mhtuyGqNMZqfNykzZDlLNvdbVb55EUKjL2y8Pt1C2/J5+aeiNVKfnfutf6eV NTcXYi7/9nG9aV9viYKZKUIr8yLpH40/qiE/G/AE4G5Yo81s/PC0SxC9atxgANgrWlo+ kr9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vQMuULjA13CEVr0LRZU1KoWRAasRrv5tXclwAlenH3U=; b=SXTfTIvHxb2d0wg2BjfIT3y/mS8aKFPSyDewpdjYNr2kq8dyBrHtIHxYSm8/pQuHlY q3l/SAe5w3RYTLcCbEoHb5c12YyGGGbEMqIMJw8cSe0/bgtj40+HY85XOr/hBm7iA8zI xjgOeWMSwDRL6vh/V+woYHAIGEVAgl3UebhiteyAjgy52lxEAyfAho0HfZ9KXKP3yZVb 77ZHTMs7QpnMRUhCQfa2kv3tLp8tK2tayTIU2UCBtoVDABJHAxPz2SSUlnK0ClBWyBUm RRwC2b25wWVPiDu55JSKwCbl3CGj0pdKNeQTVtOUxLZ4H7woemXRWdDY4UoBUGUpzJgA fXuQ== X-Gm-Message-State: AOAM530Nh5EreME7xKUZ15MQx2JjiO/gZfBZ2zlU8TAGe8bCMJQh+xfE bnGnisRb7BM35An+tN8qKOoO95yKyK7rfo67+jA5RWJmcXNdMw== X-Google-Smtp-Source: ABdhPJxOZauJ5yr3GLi1Ga5e6mZlHVUjAm/Fc2h3PKsek0h9Z8be9guxbZkYHmOYcFpLLPCv5OLTC7pSaymy5QhOXS8= X-Received: by 2002:a05:620a:410c:: with SMTP id j12mr625356qko.636.1642714081565; Thu, 20 Jan 2022 13:28:01 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 20 Jan 2022 16:27:50 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000004cacb905d60a2d65" Archived-At: Subject: [MLS] Working calls: Notes from today and plans for the next few weeks 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, 20 Jan 2022 21:28:08 -0000 --0000000000004cacb905d60a2d65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey folks, A few of us that had been working PRs/issues on GitHub had a call this morning to try to make faster progress. Notes are below. We're going to try to do weekly calls the next few weeks to keep progress moving. Next week will be unofficial, thereafter we'll make them official virtual interims. The planned time for next week is Thursday, Jan 27, 15:00-17:00 UTC. https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DMLS+PR%2FIssue+= calls&iso=3D20220127T10&p1=3D263&ah=3D2 Webex link for next week is: . For the official virtual interims after that, the chairs should be able to provide a bridge. Thanks to everyone who dialed in today. Look forward to advancing toward completion in the coming weeks! Best, --Richard (Notes by PR #) #546 - Filed just before the call, needs some time for review. #543 - Richard changed everything to =E2=80=9Cmls10=E2=80=9D. Th=C3=A9ophi= le says =E2=80=9CMLS 1.0=E2=80=9D is clearer. Richard agrees, will update the PR and merge. TODO(Richard) - Switch to =E2=80=9CMLS 1.0=E2=80=9D and merge #544 / #532 - Basically three options here: (1) do nothing, (2) remove version fields [#532], (3) remove version from ciphersuite [#544]. General agreement to do either 2 or 3. Richard is strongly opposed to removing version fields, to enable ciphersuite reuse across versions, and because versions are logically just different from ciphers. Raphael notes that the reasoning behind the current scheme was to force consideration of whether to carry ciphers forward into new versions. TODO(Richard) - Add some advisory text and merge. #526 - Richard suggests removing the context from the signature, pointing out that it=E2=80=99s duplicative with membership_tag / AEAD, so it would o= nly be necessary if the signature is to =E2=80=9Cstand alone=E2=80=9D. Raphael po= ints out that you might want to process the signature alone, e.g., at a delivery server. TODO(Th=C3=A9ophile) - Update to add context to new_member case, then ready= to merge. #525 - There are a couple of small things for Richard to fix, otherwise good to merge. TODO(Richard) - Clean up and merge #524 - Jo=C3=ABl presented some analysis that he had done with Marta and Da= niel on options here, basically (1) aggressive merge + removing =E2=80=9Credunda= nt=E2=80=9D parent nodes that have only one child, and (2) careful merge. While there=E2=80=99s some aesthetic appeal to removing redundancy, it would invo= lve a little complexity. So there was agreement to do careful truncation for now (to un-break the spec) and then see if we can figure out how to remove redundant nodes. TODO(Richard) - Merge #524 TODO(Richard+Marta) - Propose a PR removing redundant nodes #527 - Jo=C3=ABl mentioned an alternative approach based on incorporating o= nly leaf nodes (which provides similar properties to including the resolution assuming the tree invariant holds). This is probably less efficient than tree hashing, though the ambiguities around reconstruction in the tree hash case make it a little hard to tell. There was some discussion about exactly what high-level security properties we get out of a stronger tree hash. TODO(Th=C3=A9ophile) - Write a note to the list summarizing the tree-hash-b= ased parent hash proposal and its security implications, incorporating fixes to the =E2=80=9Cright edge of the tree=E2=80=9D problems. --0000000000004cacb905d60a2d65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey folks,

A few of us that = had been working PRs/issues on GitHub had a call this morning to try to mak= e faster progress.=C2=A0 Notes are below.

We'r= e going to try to do weekly calls the next few weeks to keep progress movin= g.=C2=A0 Next week will be unofficial, thereafter we'll make them offic= ial virtual interims.=C2=A0 The planned time for next week is Thursday, Jan= 27, 15:00-17:00 UTC.


Webex link for next week is: <= https://cisco.webex.com/m= eet/richbarn>.=C2=A0 For the official virtual interims after that, t= he chairs should be able to provide a bridge.

Than= ks to everyone who dialed in today.=C2=A0 Look forward to advancing toward = completion in the coming weeks!

Best,
--= Richard

(Notes by PR #)

#546 - Filed just before the call, needs some time for review.

#5= 43 - Richard changed everything to =E2=80=9Cmls10=E2=80=9D.=C2=A0 Th=C3=A9o= phile says =E2=80=9CMLS 1.0=E2=80=9D is clearer.=C2=A0 Richard agrees, will= update the PR and merge.

TODO(Richard) - Switch to =E2=80=9CMLS 1.0= =E2=80=9D and merge

#544 / #532 - Basically three options here: (1) = do nothing, (2) remove version fields [#532], (3) remove version from ciphe= rsuite [#544].=C2=A0 General agreement to do either 2 or 3.=C2=A0 Richard i= s strongly opposed to removing version fields, to enable ciphersuite reuse = across versions, and because versions are logically just different from cip= hers.=C2=A0 Raphael notes that the reasoning behind the current scheme was = to force consideration of whether to carry ciphers forward into new version= s. =C2=A0

TODO(Richard) - Add some advisory text and merge.

#= 526 - Richard suggests removing the context from the signature, pointing ou= t that it=E2=80=99s duplicative with membership_tag / AEAD, so it would onl= y be necessary if the signature is to =E2=80=9Cstand alone=E2=80=9D.=C2=A0 = Raphael points out that you might want to process the signature alone, e.g.= , at a delivery server.

TODO(Th=C3=A9ophile) - Update to add context= to new_member case, then ready to merge.

#525 - There are a couple = of small things for Richard to fix, otherwise good to merge.

TODO(Ri= chard) - Clean up and merge

#524 - Jo=C3=ABl presented some analysi= s that he had done with Marta and Daniel on options here, basically (1) agg= ressive merge + removing =E2=80=9Credundant=E2=80=9D parent nodes that have= only one child, and (2) careful merge.=C2=A0 While there=E2=80=99s some ae= sthetic appeal to removing redundancy, it would involve a little complexity= .=C2=A0 So there was agreement to do careful truncation for now (to un-brea= k the spec) and then see if we can figure out how to remove redundant nodes= .

TODO(Richard) - Merge #524
TODO(Richard+Marta) - Propose a PR r= emoving redundant nodes

#527 - Jo=C3=ABl mentioned an alternative ap= proach based on incorporating only leaf nodes (which provides similar prope= rties to including the resolution assuming the tree invariant holds).=C2=A0= This is probably less efficient than tree hashing, though the ambiguities = around reconstruction in the tree hash case make it a little hard to tell.= =C2=A0 There was some discussion about exactly what high-level security pro= perties we get out of a stronger tree hash.

TODO(Th=C3=A9ophile) - W= rite a note to the list summarizing the tree-hash-based parent hash proposa= l and its security implications, incorporating fixes to the =E2=80=9Cright = edge of the tree=E2=80=9D problems.

--0000000000004cacb905d60a2d65-- From nobody Thu Jan 20 18:37:08 2022 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 014553A1473 for ; Thu, 20 Jan 2022 18:37:07 -0800 (PST) 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 kB7ZG_IC7dfa for ; Thu, 20 Jan 2022 18:37:02 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 7B0663A1471 for ; Thu, 20 Jan 2022 18:37:02 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id m9so4794270qtq.10 for ; Thu, 20 Jan 2022 18:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=G3umZiufzKpHJn+OlFWRUBloessptJNVMDFkrSmVX+g=; b=FA2AbJrlMIgwW0uD+npSJCxBjtZzFFfZ37P5L+yXg9eLdfOUtSl4QvWijVaomgOeXV KHaTWxXcqZOPJpQ+2HLbXief1cyvtC4TW1jCQ0dvm2SrdAorpcHejM4AL3xzEfYPKm1N s6qs0Wd9dzPd5UE8kjKO1mm7T2RxV4vnXBAB8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=G3umZiufzKpHJn+OlFWRUBloessptJNVMDFkrSmVX+g=; b=OSeM8DQeuDJEa9W4sZEg1vj6LS3WRggWO1r/TjolHps1qHB4T/lIqM+08ejKNzeE04 3HK+Frs5hARffPnhjjVVfa0JP2CI60XQASdD5vkhmhHjxawP05b2cdz96O4RS1IrjhhL kcmDv2eaOxvuPXYz9DwHu3EH4rYDHgfGGnF/PJ6gxwTCqdIK8Tr1fPjiFc/2JA0w79RI KihA8QlZ+jyHjR3wRlqjw5TOBZi9C82pAUWvT4qhhbtu6uJZ3QTQ61zNa+JAVIQ/qpbx PF+N98QDKXhmtbSCBogO4cIRGhYDnLCXB/IaatMphmWMd3uFvLKDtXEO7y3Kt53e74Bi TDpA== X-Gm-Message-State: AOAM532vnVXcNDxRGFS7zDwk5AtuItcLti0iDACSuN3hZDwD9/++KHbA jjT0QEALujkNQ9XHJT2dGPHbtaUgmY7d2w== X-Google-Smtp-Source: ABdhPJw94OYoPTXzUUMiW1jt3IYm4/3bRcsEoTiMxjC++FtTEZ/8/ff3xX0ZytwHFaoXtngTGjFDWQ== X-Received: by 2002:a05:622a:648:: with SMTP id a8mr1759598qtb.427.1642732620154; Thu, 20 Jan 2022 18:37:00 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id v21sm2337698qtx.13.2022.01.20.18.36.59 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jan 2022 18:36:59 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <2A47607C-AC5B-4A7A-ADB5-3F2957D806A2@sn3rd.com> Date: Thu, 20 Jan 2022 21:36:58 -0500 To: MLS List X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [MLS] MLS Feb Interim Meetings 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, 21 Jan 2022 02:37:07 -0000 Hi! I just now I requested meetings for 2/3, 2/10, and 2/17 at from = 1500-1700 UTC. I will forward the info once they are populated in the = datatracker. spt= From nobody Thu Jan 20 18:45:36 2022 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 EFE533A14EE for ; Thu, 20 Jan 2022 18:45:35 -0800 (PST) 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 NO-6bzDGWN_d for ; Thu, 20 Jan 2022 18:45:31 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 42C363A14EB for ; Thu, 20 Jan 2022 18:45:31 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id g13so6371219qvw.4 for ; Thu, 20 Jan 2022 18:45:31 -0800 (PST) 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=SpCdMXeC/mnygbFbZ5/WVi6YdOaVsIcdmXN6EEu5A0s=; b=JNt5S1uREDcd0pUwzTShnkCESCIk6O/Hc0/hzwXba4MWjpPlMs/a2PbjQvw18zi1eI L+4aVEm6M0K7g2rNdcsetLOLMg62UFx8fDdC4/gvhLrWTgIugRP0++CyIiomsZHLiJjG rRSktJ4KllSyUM6pEJiVDn4SjorpFskthV9jE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SpCdMXeC/mnygbFbZ5/WVi6YdOaVsIcdmXN6EEu5A0s=; b=KyrDRG8TL3lJUi5eIZfps6AkfgmJBovTeagurIJobnpAITvb3CnLzx6y4n3uIwgpO6 YN12Dmbp+P36CHeE7iHKqC7byjA2ji6ng2APKzPINnAYihwf4QtitMOYQVe1KfCfWOMu LviUydhQhQWATD3wPAJTfwJD6wzIWsDBZ0PsVz2viAuL1aZ6eIoVAyWIMyKX1HOFaQVZ ZfXASGqQdl11auPsXsYmSDqyZd6WaGu2iLFxHeKZsL7FWlt9bTsxH6M4koCnMrFE0Jnl AOOXx//BPPdptVT2J6LfPSm22dcRSneyaUrW0Qir+DFP9v0wuz6VlSzYprE8LKYS1cLk tZSQ== X-Gm-Message-State: AOAM532p6VA/eXb13YkYon6W1Ve2DI8ioFqzaJD7Lm2zeEaXpPYUUlKy iMZLAB+DBk4t11nnzv5zw5g5SIxYVM0Qjw== X-Google-Smtp-Source: ABdhPJyK5ixloR/eUC34EAS+CvZiRToAqSUz5MsluMkAuPAKp0na4M02We33nj5wTOOqkNnpQLHhYA== X-Received: by 2002:a05:6214:c89:: with SMTP id r9mr1831658qvr.116.1642733128899; Thu, 20 Jan 2022 18:45:28 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id f18sm2334078qte.52.2022.01.20.18.45.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jan 2022 18:45:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: Date: Thu, 20 Jan 2022 21:45:26 -0500 Cc: MLS List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [MLS] mls@ietf113: session request? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2022 02:45:36 -0000 I will go ahead and request a 1-hr slot. spt > On Jan 18, 2022, at 11:57, Richard Barnes wrote: >=20 > Yes. Hopefully we will be in/past WGLC then, but (a) we will likely = have a few things to discuss out of that, and (b) even if not, it would = be good to discuss what to do next (e.g., federation?) >=20 > On Tue, Jan 18, 2022 at 11:27 AM Sean Turner wrote: > Hi! Scheduling requests can now be submitted for IETF 113 [0]. Does = the group think that a session will be needed? >=20 > spt >=20 > [0] https://www.ietf.org/how/meetings/113/ > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Thu Jan 20 18:49:51 2022 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 E57793A151A; Thu, 20 Jan 2022 18:49:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, mls-chairs@ietf.org, mls@ietf.org, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164273338992.25717.12135075103429275319@ietfa.amsl.com> Date: Thu, 20 Jan 2022 18:49:49 -0800 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 113 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, 21 Jan 2022 02:49:50 -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): 1 Hour Number of Attendees: 25 Conflicts to Avoid: Chair conflict: cfrg pearg tls quic wpack wish privacypass masque Key participant conflict: acme artarea dispatch perc secdispatch ohai People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jan 21 06:31:03 2022 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 3F4E63A2173; Fri, 21 Jan 2022 06:31:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164277546113.26962.7134721664916546381@ietfa.amsl.com> Date: Fri, 21 Jan 2022 06:31:01 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2022-02-03 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, 21 Jan 2022 14:31:01 -0000 The Messaging Layer Security (mls) WG will hold a virtual interim meeting on 2022-02-03 from 10:00 to 12:00 America/New_York (15:00 to 17:00 UTC). Agenda: Focus is on resoling any open issues and prs: https://github.com/mlswg/mls-protocol Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m2d98290521ba9a53eef29cf8d1433776 From nobody Fri Jan 21 06:31:38 2022 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 514AF3A2179; Fri, 21 Jan 2022 06:31:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164277548529.9483.10305779830843389799@ietfa.amsl.com> Date: Fri, 21 Jan 2022 06:31:25 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2022-02-10 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, 21 Jan 2022 14:31:32 -0000 The Messaging Layer Security (mls) WG will hold a virtual interim meeting on 2022-02-10 from 10:00 to 12:00 America/New_York (15:00 to 17:00 UTC). Agenda: Focus is on resoling any open issues and prs: https://github.com/mlswg/mls-protocol Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m2d98290521ba9a53eef29cf8d1433776 From nobody Fri Jan 21 06:31:52 2022 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 0C5563A21AC; Fri, 21 Jan 2022 06:31:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164277549602.26176.2426548391829472358@ietfa.amsl.com> Date: Fri, 21 Jan 2022 06:31:36 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2022-02-17 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, 21 Jan 2022 14:31:43 -0000 The Messaging Layer Security (mls) WG will hold a virtual interim meeting on 2022-02-17 from 10:00 to 12:00 America/New_York (15:00 to 17:00 UTC). Agenda: Focus is on resoling any open issues and prs: https://github.com/mlswg/mls-protocol Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m2d98290521ba9a53eef29cf8d1433776 From nobody Sat Jan 22 23:46:14 2022 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 1690C3A1B3E for ; Sat, 22 Jan 2022 23:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=mnot.net header.b=Ag5WQVra; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=ZPcRX+wZ 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 oD1F3HGm3RW4 for ; Sat, 22 Jan 2022 23:46:07 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492B23A1B36 for ; Sat, 22 Jan 2022 23:46:07 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8E5C43200A2A for ; Sun, 23 Jan 2022 02:38:50 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 23 Jan 2022 02:38:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:from:in-reply-to:mime-version:reply-to :sender:subject:subject:to:to; s=fm1; bh=E4VduUru/KlQFRPSaz8DVYD jC+hqrEBTPTkYRVAOZEQ=; b=Ag5WQVraKELada37CaHmV86v4hWLMrcClL2Hubl urKsa7zAWejhGb9j6CXQQBdGF4mpjyjbZs9hh0rO+NgivVPmQ2mrXBm0BihezN4W 3x2e7r5OjYDtoB9XcG7K2MR8GtXjHb5rntaqGkCs4kzuU8hLnh/2x19AA8BAHGak MZ+zUVZvLcAqYA2FfQ6pi5HjmLQkx9REJq7E+v0rAllrSKEDR81T+c2fAvboI2h2 7vZSmWNUkV+tcyvWgVcgxE6U7A7HiENSGiKrR+4Q8RVPDq+SEJelwrL+b1LRyz3k aYAzOZcY5WEe3wXWM00PVgaG6hqanisbNm9F2VYuDGCpfvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:from :in-reply-to:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=E4VduUru/KlQFRPSaz8DVYDjC+hqrEBTPTkYRVAOZEQ=; b=ZPcRX+wZ /zF1YFNR65RzzoOqucmTyPGWOZBS9yR8VZxDgV2i4wxCztTb4wLGCO6ElNNhq5uJ sRqJ7lMdTFe7boEfvVov5bI/h4MWEZPldtGT+GGFLLDf7Y5auzUC70TWPhz1+1iX 8pq4kK/6RxOV0Ql9OoOsNUkwjyPRP7iCq5nIPP1p4sa8/WBgoDEXjyNMEgBmd5gG Oxe1avW9DOZ94O9xmIJATiWiTHkAkPGY9f16tTTkgxmptT4behbiWGJkj25yS3ES +BsPhtXDpZNgIv9+nQ/zdDjeFyDdSfFyYVc4ew6MDDbpXCqGNKDwCV48Vm0tLm/0 RBKkVm6ex0uYDQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdefgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 23 Jan 2022 02:38:49 -0500 (EST) Content-Type: multipart/alternative; boundary="===============7786815579777048600==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20220123074607.492B23A1B36@ietfa.amsl.com> Date: Sat, 22 Jan 2022 23:46:07 -0800 (PST) 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, 23 Jan 2022 07:46:12 -0000 --===============7786815579777048600== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-3/=F0=9F=92=AC15) 1 issues created: - Conflicting proposal / commit behavior (by tomleavy) https://github.com/mlswg/mls-protocol/issues/542=20 5 issues received 15 new comments: - #542 Conflicting proposal / commit behavior (4 by bifurcation, kkohbrok= , tomleavy) https://github.com/mlswg/mls-protocol/issues/542=20 - #540 Proposals by reference in external commit (2 by bifurcation, kkohb= rok) https://github.com/mlswg/mls-protocol/issues/540=20 - #539 Separation between pre-published key packages and leaf node conten= t (5 by TWal, bifurcation, kkohbrok) https://github.com/mlswg/mls-protocol/issues/539=20 - #537 Clarity around extensions and `RequiredCapabilities` (3 by bifurca= tion, kkohbrok, tomleavy) https://github.com/mlswg/mls-protocol/issues/537=20 - #502 Consolidate resumption PSK definitions (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/502=20 3 issues closed: - Consolidate resumption PSK definitions https://github.com/mlswg/mls-pro= tocol/issues/502=20 - Require uniqueness of RatchetTreeExtensions in GroupInfo https://github= .com/mlswg/mls-protocol/issues/530=20 - Improve padding description https://github.com/mlswg/mls-protocol/issu= es/534=20 Pull requests ------------- * mlswg/mls-protocol (+5/-5/=F0=9F=92=AC9) 5 pull requests submitted: - Domain separation for KeyPackage and Proposal references (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/547=20 - Downgrade MUST to SHOULD for commit senders including all valid commits= (by tomleavy) https://github.com/mlswg/mls-protocol/pull/546=20 - Add missing word (by stefunctional) https://github.com/mlswg/mls-protocol/pull/545=20 - Remove version from ciphersuites (by bifurcation) https://github.com/mlswg/mls-protocol/pull/544=20 - Be consistent about version labeling (by bifurcation) https://github.com/mlswg/mls-protocol/pull/543=20 6 pull requests received 9 new comments: - #546 Downgrade MUST to SHOULD for commit senders including all valid co= mmits (3 by bifurcation, raphaelrobert, tomleavy) https://github.com/mlswg/mls-protocol/pull/546=20 - #544 Remove version from ciphersuites (2 by bifurcation, seanturner) https://github.com/mlswg/mls-protocol/pull/544=20 - #543 Be consistent about version labeling (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/543=20 - #527 Stronger parent hashes for authenticated identities (1 by TWal) https://github.com/mlswg/mls-protocol/pull/527=20 - #524 Careful truncation (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/524=20 - #509 Be explicit that Credentials can attest to multiple identities (1 = by bifurcation) https://github.com/mlswg/mls-protocol/pull/509=20 5 pull requests merged: - Careful truncation https://github.com/mlswg/mls-protocol/pull/524=20 - Add missing word https://github.com/mlswg/mls-protocol/pull/545=20 - Refactor Group Joining and fix External Inits https://github.com/mlswg/mls-protocol/pull/529=20 - Require extensions to be unique in any given extensions vector https://github.com/mlswg/mls-protocol/pull/535=20 - Reword padding section to reflect updated padding structure https://github.com/mlswg/mls-protocol/pull/536=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============7786815579777048600== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 23, 2022

Issues

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

1 issues created:

5 issues received 15 new comments:

3 issues closed:

Pull requests

mlswg/mls-protocol (+5/-5/=F0=9F=92=AC9)

5 pull requests submitted:

6 pull requests received 9 new comments:

5 pull requests merged:

Repositories tracked by this digest:
--===============7786815579777048600==-- From nobody Mon Jan 24 15:25:30 2022 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 12F743A16A8 for ; Mon, 24 Jan 2022 15:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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.20210112.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 9EpEcTBFKMjc for ; Mon, 24 Jan 2022 15:25:24 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 34A853A16A5 for ; Mon, 24 Jan 2022 15:25:23 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id w6so21594765qtk.4 for ; Mon, 24 Jan 2022 15:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+vqIegpyfFNMbdm/22GCdyyOCjAUdOFb1ngxp0mPWNk=; b=hjH0DEVZ2mLrQfSy0wZ4xqjjS4zGygPFdPMSsodhPErSA70A7TwSdMGjjBycsO4pWh 3LOO8Q3tZXaDQQMPxREb+rkNdal3lqbXQAzieWMDr5jnNCIeRGE9HBYZL9kBJYHoKNe6 WnWWnfMedhYLU9eS3Ha2IR9JNS91zz3+UWdeBh6oA+RtDewp4Dfmp10uIDsTEGiX45BN W3/aBkdyUTGqhB5cIZ7Hlv/b5OegQ4xnR0tSGQvRWWUIt+qZiGxWm33XwK7fC4t4aomH khd60u1DMnOwj8L5iTUDX8wrTrh04vBbB/NFJCVgaNg5vWzFB97jeXuzOOflKgzDla1Z KGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+vqIegpyfFNMbdm/22GCdyyOCjAUdOFb1ngxp0mPWNk=; b=HNSwKJpHA9s3DoUu4Jfk1QzlzqnAjH5CSn/Y68WtuwsHrVb+nAtRLV3n7LOkO7unzg UExTeOyBHolMgB1hBle2NFHPgst8gy4A0dzIkAFiaDs68GaPZAt7aBvNwN3+OS2RgF9+ SGDO8G0t9DaVYD99Ruda4Q+r/less4cOMb7EZi7rtHV270l2o8YBaiMfrlVQxwG00QD5 7k2OvbksS3SNLRMO/drR94v4pWhB4uEBYA0AEAe2exu0fq5MMEg38e+I/R0Q8gXSSdpZ R/COvvmfJL2kEgFiY3COswYZKHkikUyzX3uQunS2OBueceZG1l5LguCWITZGXVYF5l1H vl2Q== X-Gm-Message-State: AOAM531x+i1Y3YdAhyFoQUvMju37XY/vGW1WfQjGLX/e5g+Fio3Cry1q mH1yTVSRB3GIDrL3RbNlIIsdL8QFGAR3Ssj+kJRmDPu+cEg= X-Google-Smtp-Source: ABdhPJxWFmvWsrTZKFPmqzbNcc3/nEgh1zoK2gJ9BSWulA4yVOmSU2xMTpUu9iRwtvL714Xll15cmdRd44WH5pNO82M= X-Received: by 2002:a05:622a:178b:: with SMTP id s11mr3072550qtk.89.1643066721558; Mon, 24 Jan 2022 15:25:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 24 Jan 2022 18:25:10 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000047f3a905d65c48bc" Archived-At: Subject: Re: [MLS] Working calls: Notes from today and plans for the next few weeks 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, 24 Jan 2022 23:25:29 -0000 --00000000000047f3a905d65c48bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, I just sent an invite for Thursday morning (US time) to those who were on the call last week. Please let me know 1:1 if I should add you. --RLB On Thu, Jan 20, 2022 at 4:27 PM Richard Barnes wrote: > Hey folks, > > A few of us that had been working PRs/issues on GitHub had a call this > morning to try to make faster progress. Notes are below. > > We're going to try to do weekly calls the next few weeks to keep progress > moving. Next week will be unofficial, thereafter we'll make them officia= l > virtual interims. The planned time for next week is Thursday, Jan 27, > 15:00-17:00 UTC. > > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DMLS+PR%2FIssu= e+calls&iso=3D20220127T10&p1=3D263&ah=3D2 > > Webex link for next week is: . > For the official virtual interims after that, the chairs should be able t= o > provide a bridge. > > Thanks to everyone who dialed in today. Look forward to advancing toward > completion in the coming weeks! > > Best, > --Richard > > (Notes by PR #) > > #546 - Filed just before the call, needs some time for review. > > #543 - Richard changed everything to =E2=80=9Cmls10=E2=80=9D. Th=C3=A9op= hile says =E2=80=9CMLS 1.0=E2=80=9D is > clearer. Richard agrees, will update the PR and merge. > > TODO(Richard) - Switch to =E2=80=9CMLS 1.0=E2=80=9D and merge > > #544 / #532 - Basically three options here: (1) do nothing, (2) remove > version fields [#532], (3) remove version from ciphersuite [#544]. Gener= al > agreement to do either 2 or 3. Richard is strongly opposed to removing > version fields, to enable ciphersuite reuse across versions, and because > versions are logically just different from ciphers. Raphael notes that t= he > reasoning behind the current scheme was to force consideration of whether > to carry ciphers forward into new versions. > > TODO(Richard) - Add some advisory text and merge. > > #526 - Richard suggests removing the context from the signature, pointing > out that it=E2=80=99s duplicative with membership_tag / AEAD, so it would= only be > necessary if the signature is to =E2=80=9Cstand alone=E2=80=9D. Raphael = points out that > you might want to process the signature alone, e.g., at a delivery server= . > > TODO(Th=C3=A9ophile) - Update to add context to new_member case, then rea= dy to > merge. > > #525 - There are a couple of small things for Richard to fix, otherwise > good to merge. > > TODO(Richard) - Clean up and merge > > #524 - Jo=C3=ABl presented some analysis that he had done with Marta and = Daniel > on options here, basically (1) aggressive merge + removing =E2=80=9Credun= dant=E2=80=9D > parent nodes that have only one child, and (2) careful merge. While > there=E2=80=99s some aesthetic appeal to removing redundancy, it would in= volve a > little complexity. So there was agreement to do careful truncation for n= ow > (to un-break the spec) and then see if we can figure out how to remove > redundant nodes. > > TODO(Richard) - Merge #524 > TODO(Richard+Marta) - Propose a PR removing redundant nodes > > #527 - Jo=C3=ABl mentioned an alternative approach based on incorporating= only > leaf nodes (which provides similar properties to including the resolution > assuming the tree invariant holds). This is probably less efficient than > tree hashing, though the ambiguities around reconstruction in the tree ha= sh > case make it a little hard to tell. There was some discussion about > exactly what high-level security properties we get out of a stronger tree > hash. > > TODO(Th=C3=A9ophile) - Write a note to the list summarizing the tree-hash= -based > parent hash proposal and its security implications, incorporating fixes t= o > the =E2=80=9Cright edge of the tree=E2=80=9D problems. > > --00000000000047f3a905d65c48bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I just sent an invi= te for Thursday morning (US time) to those who were on the call last week.= =C2=A0 Please let me know 1:1 if I should add you.

--RLB

On Thu, Jan 20, 2022 at 4:27 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey folks,

A few of us that had been working PRs/issues on GitHub had = a call this morning to try to make faster progress.=C2=A0 Notes are below.<= /div>

We're going to try to do weekly calls the next= few weeks to keep progress moving.=C2=A0 Next week will be unofficial, the= reafter we'll make them official virtual interims.=C2=A0 The planned ti= me for next week is Thursday, Jan 27, 15:00-17:00 UTC.

= =

Webex link for next week is: <https://cisco.webex.com/meet/= richbarn>.=C2=A0 For the official virtual interims after that, the c= hairs should be able to provide a bridge.

Thanks t= o everyone who dialed in today.=C2=A0 Look forward to advancing toward comp= letion in the coming weeks!

Best,
--Rich= ard

(Notes by PR #)

#= 546 - Filed just before the call, needs some time for review.

#543 -= Richard changed everything to =E2=80=9Cmls10=E2=80=9D.=C2=A0 Th=C3=A9ophil= e says =E2=80=9CMLS 1.0=E2=80=9D is clearer.=C2=A0 Richard agrees, will upd= ate the PR and merge.

TODO(Richard) - Switch to =E2=80=9CMLS 1.0=E2= =80=9D and merge

#544 / #532 - Basically three options here: (1) do = nothing, (2) remove version fields [#532], (3) remove version from ciphersu= ite [#544].=C2=A0 General agreement to do either 2 or 3.=C2=A0 Richard is s= trongly opposed to removing version fields, to enable ciphersuite reuse acr= oss versions, and because versions are logically just different from cipher= s.=C2=A0 Raphael notes that the reasoning behind the current scheme was to = force consideration of whether to carry ciphers forward into new versions. = =C2=A0

TODO(Richard) - Add some advisory text and merge.

#526= - Richard suggests removing the context from the signature, pointing out t= hat it=E2=80=99s duplicative with membership_tag / AEAD, so it would only b= e necessary if the signature is to =E2=80=9Cstand alone=E2=80=9D.=C2=A0 Rap= hael points out that you might want to process the signature alone, e.g., a= t a delivery server.

TODO(Th=C3=A9ophile) - Update to add context to= new_member case, then ready to merge.

#525 - There are a couple of = small things for Richard to fix, otherwise good to merge.

TODO(Richa= rd) - Clean up and merge

#524 - Jo=C3=ABl presented some analysis t= hat he had done with Marta and Daniel on options here, basically (1) aggres= sive merge + removing =E2=80=9Credundant=E2=80=9D parent nodes that have on= ly one child, and (2) careful merge.=C2=A0 While there=E2=80=99s some aesth= etic appeal to removing redundancy, it would involve a little complexity.= =C2=A0 So there was agreement to do careful truncation for now (to un-break= the spec) and then see if we can figure out how to remove redundant nodes.=

TODO(Richard) - Merge #524
TODO(Richard+Marta) - Propose a PR re= moving redundant nodes

#527 - Jo=C3=ABl mentioned an alternative app= roach based on incorporating only leaf nodes (which provides similar proper= ties to including the resolution assuming the tree invariant holds).=C2=A0 = This is probably less efficient than tree hashing, though the ambiguities a= round reconstruction in the tree hash case make it a little hard to tell.= =C2=A0 There was some discussion about exactly what high-level security pro= perties we get out of a stronger tree hash.

TODO(Th=C3=A9ophile) - W= rite a note to the list summarizing the tree-hash-based parent hash proposa= l and its security implications, incorporating fixes to the =E2=80=9Cright = edge of the tree=E2=80=9D problems.

--00000000000047f3a905d65c48bc-- From nobody Thu Jan 27 06:35:35 2022 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 8A1F53A0E45 for ; Thu, 27 Jan 2022 06:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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.20210112.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 EGlfVkB7vW08 for ; Thu, 27 Jan 2022 06:35:29 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 9F4363A0E4D for ; Thu, 27 Jan 2022 06:35:29 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id b35so2201581qkp.6 for ; Thu, 27 Jan 2022 06:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vEq8npMb2J9qv6gEyDo2D+bZ6CScDiXoSlC2FVGnT7A=; b=kRwLC0MEvQRU5B9az5Nv75MGqZ8CwRRl0vEKZnL1kiB3f44VDYKSCJwUzn+fTeCZ2c VeAUzsfqGr2wF4RC01Xj2PY1ah+1A9GLa4P82scbqGGWb+dPW+4RzPGkmZIr8f0QUBRS WNFR4VTV+GBGDo5+9gQrL1Kl1xtGukElqNjLIzj9tLbAAHNfX7EEbVV8hmcLKub5Y3Ka s2b4GdK6db01IEddzzlfJuXFUlt4jJndY50+s/VebKhcAj40IZVG3aM/YNDKUUueEB2t gzQyAltuqWzQEvEdPoeJxoHXWx2HVzugidQ76WUgKEYGsxS0/XBUY84H/nya0yUo/mFQ Wf7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vEq8npMb2J9qv6gEyDo2D+bZ6CScDiXoSlC2FVGnT7A=; b=FhgBvwwvjz30NvLmT+3a5qpww0u5x/QLNH6RWDFjWhMChm+L3n9ZJEOJRo+UK+ACVd VZQKOe/HT76tFbORo2yA6onE6ClLoNYEt5VTpWVHok4HgCOe6VYrmSGM0PVqYnF7keTa 44btSxVbojv0G8DUtVceabsINt7jP5Xs5U4ZdbW48+fkqhA35f3WYuNFDxkYZpg/hCO1 fa0V2rl5v/LbhlRb83KMM1NEW7KPycmMZfFof/mSkKSIQfBJytwGcseYzeuX8BjqBE51 NT7ksRyZypdr82zKGSi13d1Ri6oFZaaEXIc5f2Xs/wVieCNtZ6DIvLVLkF8sFLEIohr0 B65Q== X-Gm-Message-State: AOAM533R8El+Aqw+A2HcJ6G2VAdp2/YHzX+Hv9zU1M31wJF3nGQgGKqm OYRD2QSXLtNk7+/7JLiMHrZjR1/mMsyRXHRDLZDlgtxvCTINyg== X-Google-Smtp-Source: ABdhPJzBeEX9hjhwyuwSxfNzxIzp1IM6gm+QEEH5Q+ql/RI+d2yop52HuEqwA6K+KquBBh6dapSgwvpRC/Jc22gi/+w= X-Received: by 2002:a05:620a:579:: with SMTP id p25mr2780350qkp.344.1643294126970; Thu, 27 Jan 2022 06:35:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 27 Jan 2022 09:35:15 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000b335d605d6913ac0" Archived-At: Subject: Re: [MLS] Working calls: Notes from today and plans for the next few weeks 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, 27 Jan 2022 14:35:35 -0000 --000000000000b335d605d6913ac0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, Sorry, I thought I sent this out yesterday, but apparently failed to and deleted the draft. Here's a proposed agenda for today's call. --Richard #546 - Downgrade MUST to SHOULD for commit senders including all valid commits #542 - Conflicting proposal / commit behavior #509 - Be explicit that Credentials can attest to multiple identities #523 - Move wire_format to a separate tagged-union structure MLSMessage #540 - Proposals by reference in external commit #537 - Clarity around extensions and RequiredCapabilities #539 - Separation between pre-published key packages and leaf node content #538 - KeyPackage lifetime handling #527 - Stronger parent hashes for authenticated identities #556 - Fix some typos. #555 - Add clarifying note about _resolution_ in the most common case. #554 - Use common-sense definition of _descendant_ #553 - Make definition of _group_ match the Introduction definition #552 - fetching KeyPackages SHOULD be rate limited. #551 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState #409 - Draft structure/Editorial Changes editorial On Thu, Jan 20, 2022 at 4:27 PM Richard Barnes wrote: > Hey folks, > > A few of us that had been working PRs/issues on GitHub had a call this > morning to try to make faster progress. Notes are below. > > We're going to try to do weekly calls the next few weeks to keep progress > moving. Next week will be unofficial, thereafter we'll make them officia= l > virtual interims. The planned time for next week is Thursday, Jan 27, > 15:00-17:00 UTC. > > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DMLS+PR%2FIssu= e+calls&iso=3D20220127T10&p1=3D263&ah=3D2 > > Webex link for next week is: . > For the official virtual interims after that, the chairs should be able t= o > provide a bridge. > > Thanks to everyone who dialed in today. Look forward to advancing toward > completion in the coming weeks! > > Best, > --Richard > > (Notes by PR #) > > #546 - Filed just before the call, needs some time for review. > > #543 - Richard changed everything to =E2=80=9Cmls10=E2=80=9D. Th=C3=A9op= hile says =E2=80=9CMLS 1.0=E2=80=9D is > clearer. Richard agrees, will update the PR and merge. > > TODO(Richard) - Switch to =E2=80=9CMLS 1.0=E2=80=9D and merge > > #544 / #532 - Basically three options here: (1) do nothing, (2) remove > version fields [#532], (3) remove version from ciphersuite [#544]. Gener= al > agreement to do either 2 or 3. Richard is strongly opposed to removing > version fields, to enable ciphersuite reuse across versions, and because > versions are logically just different from ciphers. Raphael notes that t= he > reasoning behind the current scheme was to force consideration of whether > to carry ciphers forward into new versions. > > TODO(Richard) - Add some advisory text and merge. > > #526 - Richard suggests removing the context from the signature, pointing > out that it=E2=80=99s duplicative with membership_tag / AEAD, so it would= only be > necessary if the signature is to =E2=80=9Cstand alone=E2=80=9D. Raphael = points out that > you might want to process the signature alone, e.g., at a delivery server= . > > TODO(Th=C3=A9ophile) - Update to add context to new_member case, then rea= dy to > merge. > > #525 - There are a couple of small things for Richard to fix, otherwise > good to merge. > > TODO(Richard) - Clean up and merge > > #524 - Jo=C3=ABl presented some analysis that he had done with Marta and = Daniel > on options here, basically (1) aggressive merge + removing =E2=80=9Credun= dant=E2=80=9D > parent nodes that have only one child, and (2) careful merge. While > there=E2=80=99s some aesthetic appeal to removing redundancy, it would in= volve a > little complexity. So there was agreement to do careful truncation for n= ow > (to un-break the spec) and then see if we can figure out how to remove > redundant nodes. > > TODO(Richard) - Merge #524 > TODO(Richard+Marta) - Propose a PR removing redundant nodes > > #527 - Jo=C3=ABl mentioned an alternative approach based on incorporating= only > leaf nodes (which provides similar properties to including the resolution > assuming the tree invariant holds). This is probably less efficient than > tree hashing, though the ambiguities around reconstruction in the tree ha= sh > case make it a little hard to tell. There was some discussion about > exactly what high-level security properties we get out of a stronger tree > hash. > > TODO(Th=C3=A9ophile) - Write a note to the list summarizing the tree-hash= -based > parent hash proposal and its security implications, incorporating fixes t= o > the =E2=80=9Cright edge of the tree=E2=80=9D problems. > > --000000000000b335d605d6913ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

Sorry, I thought I = sent this out yesterday, but apparently failed to and deleted the draft.=C2= =A0 Here's a proposed agenda for today's call.

--Richard

#546 - Downgrade MUST to SHOULD= for commit senders including all valid commits
#542 - Conflicting propo= sal / commit behavior

#509 - Be explicit that Credentials can attest= to multiple identities

#523 - Move wire_format to a separate tagged= -union structure MLSMessage

#540 - Proposals by reference in externa= l commit

#537 - Clarity around extensions and RequiredCapabilities
#539 - Separation between pre-published key packages and leaf node co= ntent
#538 - KeyPackage lifetime handling

#527 - Stronger parent = hashes for authenticated identities

#556 - Fix some typos.
#555 -= Add clarifying note about _resolution_ in the most common case.
#554 - = Use common-sense definition of _descendant_
#553 - Make definition of _g= roup_ match the Introduction definition
#552 - fetching KeyPackages SHOU= LD be rate limited.
#551 - Rename InitKeys -> KeyPackages; and GroupI= nfo -> PublicGroupState

#409 - Draft structure/Editorial Changes = editorial


On Thu, Jan 20, 2022 at 4:27 PM Richard Barne= s <rlb@ipv.sx> wrote:
Hey fol= ks,

A few of us that had been working PRs/issues o= n GitHub had a call this morning to try to make faster progress.=C2=A0 Note= s are below.

We're going to try to do weekly c= alls the next few weeks to keep progress moving.=C2=A0 Next week will be un= official, thereafter we'll make them official virtual interims.=C2=A0 T= he planned time for next week is Thursday, Jan 27, 15:00-17:00 UTC.


Webex link for next week is: <https://cisco.webe= x.com/meet/richbarn>.=C2=A0 For the official virtual interims after = that, the chairs should be able to provide a bridge.

Thanks to everyone who dialed in today.=C2=A0 Look forward to advancing = toward completion in the coming weeks!

Best,
=
--Richard

(Notes by PR #)

<= /div>
#546 - Filed just before the call, needs some time for review.
#543 - Richard changed everything to =E2=80=9Cmls10=E2=80=9D.=C2=A0 Th= =C3=A9ophile says =E2=80=9CMLS 1.0=E2=80=9D is clearer.=C2=A0 Richard agree= s, will update the PR and merge.

TODO(Richard) - Switch to =E2=80=9C= MLS 1.0=E2=80=9D and merge

#544 / #532 - Basically three options her= e: (1) do nothing, (2) remove version fields [#532], (3) remove version fro= m ciphersuite [#544].=C2=A0 General agreement to do either 2 or 3.=C2=A0 Ri= chard is strongly opposed to removing version fields, to enable ciphersuite= reuse across versions, and because versions are logically just different f= rom ciphers.=C2=A0 Raphael notes that the reasoning behind the current sche= me was to force consideration of whether to carry ciphers forward into new = versions. =C2=A0

TODO(Richard) - Add some advisory text and merge.
#526 - Richard suggests removing the context from the signature, poin= ting out that it=E2=80=99s duplicative with membership_tag / AEAD, so it wo= uld only be necessary if the signature is to =E2=80=9Cstand alone=E2=80=9D.= =C2=A0 Raphael points out that you might want to process the signature alon= e, e.g., at a delivery server.

TODO(Th=C3=A9ophile) - Update to add = context to new_member case, then ready to merge.

#525 - There are a = couple of small things for Richard to fix, otherwise good to merge.

= TODO(Richard) - Clean up and merge

#524 - Jo=C3=ABl presented some = analysis that he had done with Marta and Daniel on options here, basically = (1) aggressive merge + removing =E2=80=9Credundant=E2=80=9D parent nodes th= at have only one child, and (2) careful merge.=C2=A0 While there=E2=80=99s = some aesthetic appeal to removing redundancy, it would involve a little com= plexity.=C2=A0 So there was agreement to do careful truncation for now (to = un-break the spec) and then see if we can figure out how to remove redundan= t nodes.

TODO(Richard) - Merge #524
TODO(Richard+Marta) - Propose= a PR removing redundant nodes

#527 - Jo=C3=ABl mentioned an alterna= tive approach based on incorporating only leaf nodes (which provides simila= r properties to including the resolution assuming the tree invariant holds)= .=C2=A0 This is probably less efficient than tree hashing, though the ambig= uities around reconstruction in the tree hash case make it a little hard to= tell.=C2=A0 There was some discussion about exactly what high-level securi= ty properties we get out of a stronger tree hash.

TODO(Th=C3=A9ophil= e) - Write a note to the list summarizing the tree-hash-based parent hash p= roposal and its security implications, incorporating fixes to the =E2=80=9C= right edge of the tree=E2=80=9D problems.

--000000000000b335d605d6913ac0-- From nobody Thu Jan 27 06:50:39 2022 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 958E23A0FB5 for ; Thu, 27 Jan 2022 06:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=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 Zb8-1PaMknHI for ; Thu, 27 Jan 2022 06:50:31 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AF43A0F47 for ; Thu, 27 Jan 2022 06:50:31 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.88,320,1635199200"; d="scan'208,217"; a="18284870" Received: from wifi-pro-82-070.paris.inria.fr (HELO [128.93.82.70]) ([128.93.82.70]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2022 15:50:29 +0100 Content-Type: multipart/alternative; boundary="------------8UbUtM0sKKprhWe6NHDZD01x" Message-ID: <83d58328-2dfd-c678-177d-55990b2196f9@inria.fr> Date: Thu, 27 Jan 2022 15:52:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: mls@ietf.org References: From: =?UTF-8?Q?Th=c3=a9ophile_Wallez?= In-Reply-To: Archived-At: Subject: Re: [MLS] Working calls: Notes from today and plans for the next few weeks 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, 27 Jan 2022 14:50:37 -0000 This is a multi-part message in MIME format. --------------8UbUtM0sKKprhWe6NHDZD01x Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hey, Can we talk about #527 (stronger parent hash) earlier (at least a bit briefly)? Karthik would like to attend this part of the call but it's already quite late in his current location. Thanks, Théophile. On 27/01/2022 15:35, Richard Barnes wrote: > Hey all, > > Sorry, I thought I sent this out yesterday, but apparently failed to > and deleted the draft.  Here's a proposed agenda for today's call. > > --Richard > > #546 - Downgrade MUST to SHOULD for commit senders including all valid > commits > #542 - Conflicting proposal / commit behavior > > #509 - Be explicit that Credentials can attest to multiple identities > > #523 - Move wire_format to a separate tagged-union structure MLSMessage > > #540 - Proposals by reference in external commit > > #537 - Clarity around extensions and RequiredCapabilities > > #539 - Separation between pre-published key packages and leaf node content > #538 - KeyPackage lifetime handling > > #527 - Stronger parent hashes for authenticated identities > > #556 - Fix some typos. > #555 - Add clarifying note about _resolution_ in the most common case. > #554 - Use common-sense definition of _descendant_ > #553 - Make definition of _group_ match the Introduction definition > #552 - fetching KeyPackages SHOULD be rate limited. > #551 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState > > #409 - Draft structure/Editorial Changes editorial > > > On Thu, Jan 20, 2022 at 4:27 PM Richard Barnes wrote: > > Hey folks, > > A few of us that had been working PRs/issues on GitHub had a call > this morning to try to make faster progress. Notes are below. > > We're going to try to do weekly calls the next few weeks to keep > progress moving.  Next week will be unofficial, thereafter we'll > make them official virtual interims.  The planned time for next > week is Thursday, Jan 27, 15:00-17:00 UTC. > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=MLS+PR%2FIssue+calls&iso=20220127T10&p1=263&ah=2 > > > Webex link for next week is: > . For the official virtual > interims after that, the chairs should be able to provide a bridge. > > Thanks to everyone who dialed in today.  Look forward to advancing > toward completion in the coming weeks! > > Best, > --Richard > > (Notes by PR #) > > #546 - Filed just before the call, needs some time for review. > > #543 - Richard changed everything to “mls10”.  Théophile says “MLS > 1.0” is clearer.  Richard agrees, will update the PR and merge. > > TODO(Richard) - Switch to “MLS 1.0” and merge > > #544 / #532 - Basically three options here: (1) do nothing, (2) > remove version fields [#532], (3) remove version from ciphersuite > [#544].  General agreement to do either 2 or 3.  Richard is > strongly opposed to removing version fields, to enable ciphersuite > reuse across versions, and because versions are logically just > different from ciphers.  Raphael notes that the reasoning behind > the current scheme was to force consideration of whether to carry > ciphers forward into new versions. > > TODO(Richard) - Add some advisory text and merge. > > #526 - Richard suggests removing the context from the signature, > pointing out that it’s duplicative with membership_tag / AEAD, so > it would only be necessary if the signature is to “stand alone”.  > Raphael points out that you might want to process the signature > alone, e.g., at a delivery server. > > TODO(Théophile) - Update to add context to new_member case, then > ready to merge. > > #525 - There are a couple of small things for Richard to fix, > otherwise good to merge. > > TODO(Richard) - Clean up and merge > > #524 - Joël presented some analysis that he had done with Marta > and Daniel on options here, basically (1) aggressive merge + > removing “redundant” parent nodes that have only one child, and > (2) careful merge.  While there’s some aesthetic appeal to > removing redundancy, it would involve a little complexity.  So > there was agreement to do careful truncation for now (to un-break > the spec) and then see if we can figure out how to remove > redundant nodes. > > TODO(Richard) - Merge #524 > TODO(Richard+Marta) - Propose a PR removing redundant nodes > > #527 - Joël mentioned an alternative approach based on > incorporating only leaf nodes (which provides similar properties > to including the resolution assuming the tree invariant holds).  > This is probably less efficient than tree hashing, though the > ambiguities around reconstruction in the tree hash case make it a > little hard to tell. There was some discussion about exactly what > high-level security properties we get out of a stronger tree hash. > > TODO(Théophile) - Write a note to the list summarizing the > tree-hash-based parent hash proposal and its security > implications, incorporating fixes to the “right edge of the tree” > problems. > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --------------8UbUtM0sKKprhWe6NHDZD01x Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hey,

Can we talk about #527 (stronger parent hash) earlier (at least a bit briefly)? Karthik would like to attend this part of the call but it's already quite late in his current location.

Thanks,
Théophile.

On 27/01/2022 15:35, Richard Barnes wrote:
Hey all,

Sorry, I thought I sent this out yesterday, but apparently failed to and deleted the draft.  Here's a proposed agenda for today's call.

--Richard

#546 - Downgrade MUST to SHOULD for commit senders including all valid commits
#542 - Conflicting proposal / commit behavior

#509 - Be explicit that Credentials can attest to multiple identities

#523 - Move wire_format to a separate tagged-union structure MLSMessage

#540 - Proposals by reference in external commit

#537 - Clarity around extensions and RequiredCapabilities

#539 - Separation between pre-published key packages and leaf node content
#538 - KeyPackage lifetime handling

#527 - Stronger parent hashes for authenticated identities

#556 - Fix some typos.
#555 - Add clarifying note about _resolution_ in the most common case.
#554 - Use common-sense definition of _descendant_
#553 - Make definition of _group_ match the Introduction definition
#552 - fetching KeyPackages SHOULD be rate limited.
#551 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState

#409 - Draft structure/Editorial Changes editorial


On Thu, Jan 20, 2022 at 4:27 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey folks,

A few of us that had been working PRs/issues on GitHub had a call this morning to try to make faster progress.  Notes are below.

We're going to try to do weekly calls the next few weeks to keep progress moving.  Next week will be unofficial, thereafter we'll make them official virtual interims.  The planned time for next week is Thursday, Jan 27, 15:00-17:00 UTC.


Webex link for next week is: <https://cisco.webex.com/meet/richbarn>.  For the official virtual interims after that, the chairs should be able to provide a bridge.

Thanks to everyone who dialed in today.  Look forward to advancing toward completion in the coming weeks!

Best,
--Richard

(Notes by PR #)

#546 - Filed just before the call, needs some time for review.

#543 - Richard changed everything to “mls10”.  Théophile says “MLS 1.0” is clearer.  Richard agrees, will update the PR and merge.

TODO(Richard) - Switch to “MLS 1.0” and merge

#544 / #532 - Basically three options here: (1) do nothing, (2) remove version fields [#532], (3) remove version from ciphersuite [#544].  General agreement to do either 2 or 3.  Richard is strongly opposed to removing version fields, to enable ciphersuite reuse across versions, and because versions are logically just different from ciphers.  Raphael notes that the reasoning behind the current scheme was to force consideration of whether to carry ciphers forward into new versions.  

TODO(Richard) - Add some advisory text and merge.

#526 - Richard suggests removing the context from the signature, pointing out that it’s duplicative with membership_tag / AEAD, so it would only be necessary if the signature is to “stand alone”.  Raphael points out that you might want to process the signature alone, e.g., at a delivery server.

TODO(Théophile) - Update to add context to new_member case, then ready to merge.

#525 - There are a couple of small things for Richard to fix, otherwise good to merge.

TODO(Richard) - Clean up and merge

#524 - Joël presented some analysis that he had done with Marta and Daniel on options here, basically (1) aggressive merge + removing “redundant” parent nodes that have only one child, and (2) careful merge.  While there’s some aesthetic appeal to removing redundancy, it would involve a little complexity.  So there was agreement to do careful truncation for now (to un-break the spec) and then see if we can figure out how to remove redundant nodes.

TODO(Richard) - Merge #524
TODO(Richard+Marta) - Propose a PR removing redundant nodes

#527 - Joël mentioned an alternative approach based on incorporating only leaf nodes (which provides similar properties to including the resolution assuming the tree invariant holds).  This is probably less efficient than tree hashing, though the ambiguities around reconstruction in the tree hash case make it a little hard to tell.  There was some discussion about exactly what high-level security properties we get out of a stronger tree hash.

TODO(Théophile) - Write a note to the list summarizing the tree-hash-based parent hash proposal and its security implications, incorporating fixes to the “right edge of the tree” problems.


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--------------8UbUtM0sKKprhWe6NHDZD01x-- From nobody Thu Jan 27 10:29:49 2022 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 C03F23A0AD7 for ; Thu, 27 Jan 2022 10:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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.20210112.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 1pBdMlVtkiYI for ; Thu, 27 Jan 2022 10:29:45 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 78DE33A0AD0 for ; Thu, 27 Jan 2022 10:29:45 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id y17so3219973qtx.9 for ; Thu, 27 Jan 2022 10:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=g8PFS0sFt2OuPEN1njJKSYvLRODI9Wo0oJ5d8GihvUg=; b=aZETf67mpf3FQPivkcrkal1F4XnPhohDRfDXuIxLgYFvqyCjsB4snDpKuAKz+yj0O5 U9n61EYtbk+NwuMyALyW/4naCo55VNtyJoWT/NUnzGq9kMY+/XJhE+IciH5Hxt6TsU2H PRUrrePTMnQL9WoB6/f8OpqKhyONmBkwEB8ZfhvXBpW8vEft2uPjb7zyocX2pFbtp78Z w95qDmomCJMnr+bejhShF1GioG1a7tw/NVWtylzOeyeJk0zllSvgHkovaEU78XY++OQO zreNJrnbKpTHKw3lhlmPuLVGOwl6uLPVQKY6nXIWyh7So8Fh/FQOmqWGwaTL7Cqv2d9v HvdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=g8PFS0sFt2OuPEN1njJKSYvLRODI9Wo0oJ5d8GihvUg=; b=QxFzxSP6+6q5UzGTBqkkgYM2yg0aj/1FYi+daOvk1hTXgx4/5ArVx0ESKgK5fXk2ns aCEDPAcAXIBsKlrRTR1yE5q1Ps1+KSdVifrSk2aXGqzsXZWR0/uClfs1VMPLFXJPVVRZ DfWbSITiVXL6Rmb/HK14lAbqIGdl5Y/H+DbSzgv2J4x9gliSF4TxaWdlNO7WQq1VexRS 754GZRF1Kaha18H6VnJGzrjKcSPAjHvbrKF2fPyhESK6jlFHWVosKjkql/QHBVNfe9Dr kthHg/MbfVRcTmW36Ms2xXfGMGfMx+imTGrGm2Ru+1Bcw5NN2KR2zMOAXRvBxb3bEBK3 0v1w== X-Gm-Message-State: AOAM532rhp+N8RNmLHFukXWTRm7S69UB1Imq8+T6EUn+3yQBFU2PeNuA DGtLDacJJ/ukVBnHtI+b0MiDSXW2/iQqPX/NhoIgm9adhOfggA== X-Google-Smtp-Source: ABdhPJyW9WWQ8z+p7J98yxI1ZKIH+HAMerZXD5Otm+4mw8J5oa6t/4C03xqIvfQDwdYPrgYlB66YWcMYosFiWplhuf8= X-Received: by 2002:a05:622a:1189:: with SMTP id m9mr3649910qtk.573.1643308183129; Thu, 27 Jan 2022 10:29:43 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 27 Jan 2022 13:29:32 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000832d4b05d694808e" Archived-At: Subject: [MLS] Notes from today's working call 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, 27 Jan 2022 18:29:48 -0000 --000000000000832d4b05d694808e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, We had a very productive call today, and covered pretty much all the outstanding issues and PRs! I put some notes in the PRs as we went along, but a consolidated summary is below. In addition to the below details, the overall plan the editors have for the next few steps is: 1. Merge what can be merged from the current list of proposals 2. Make a PR to rearrange sections, without modifying the text of the sections 3. Continue work on remaining issues The need for (2) has been around for a while and is becoming increasingly urgent. So we're basically imposing a blackout period so that people don't have to do tough rebases. Round (1) will include everything that is basically ready to go now. Round (3) will cover the few substantive things we have outstanding. Thanks again to everyone who participated today, --RLB #556 - Fix some typos. #555 - Add clarifying note about _resolution_ in the most common case. #554 - Use common-sense definition of _descendant_ #553 - Make definition of _group_ match the Introduction definition #552 - fetching KeyPackages SHOULD be rate limited. #551 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState * Editors will handle these, didn't look like they needed WG discussion #509 - Be explicit that Credentials can attest to multiple identities * Core thing to assure is that we have the same validation logic across Add, Update, and Commit * TODO(Richard) Update and propose merging #546 - Downgrade MUST to SHOULD for commit senders including all valid commits #542 - Conflicting proposal / commit behavior * Agreement on the resolution in the PR: Clarify that receivers need not generate an error if they see a Commit that they don't believe covers all valid proposals. * TODO(Tom) Update PR, then editors will review + merge #523 - Move wire_format to a separate tagged-union structure MLSMessage * Agreement that this is a good idea; some specifics noted in PR * On hold until after move-sections-around PR #527 - Stronger parent hashes for authenticated identities * Th=C3=A9ophile reviewed the state of the discussions and current options * Karthik elaborated on the motivations for covering the credentials in the leaves * Agreement that covering the leaves as a list would provide the desired security property, possibly with lower efficiency * Richard raised the possibility of eliminating unmerged_leaves **only when the tree is extended**, which should avoid the issues blocking the use of the tree hash. * In general, we have the following decision tree among the various parent hash options: * Do we want to authenticate credentials in parent hash? * No =3D> resolution hash * Yes =3D> Are we OK with efficiency of leaf hash? * Yes =3D> leaf hash * No =3D> Do we need unmerged_leaves? * No =3D> tree hash * Yes =3D> tree hash + one of: * Always tree hash over full tree * Store number of leaves at tree parent hash alongside parent has= h * TODO(Richard) Describe partial removal of unmerged leaves on PR * On hold until after move-sections-around PR #540 - Proposals by reference in external commit * Agreement to forbid proposals by reference in external commits * ... since the external joiner can't verify their validity * TODO(Richard) File a PR to implement this #537 - Clarity around extensions and RequiredCapabilities * Agreement on the "everything in the spec is MTI" approach * TODO(Richard) File a PR to implement, or close if it doesn't look like one is necessary #538 - KeyPackage lifetime handling * TODO(Richard) Close in favor of #539 #539 - Separation between pre-published key packages and leaf node content * General agreement that the basic idea of the separation is good * Broad support for signing ciphersuite, group_id in leaves * Some details to be worked out with regard to how to represent this * Storing information in the leaves vs. just inserting into the signature * Need to consider whether extensions are needed at both levels * On hold until after move-sections-around PR --000000000000832d4b05d694808e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

We had a very productive call today, and co= vered pretty much all the outstanding issues and PRs!=C2=A0 I put some note= s in the PRs as we went along, but a consolidated summary is below.

= In addition to the below details, the overall plan the editors have for the= next few steps is:

1. Merge what can be merged from the current lis= t of proposals
2. Make a PR to rearrange sections, without modifying the= text of the sections
3. Continue work on remaining issues

The ne= ed for (2) has been around for a while and is becoming increasingly urgent.= =C2=A0 So we're basically imposing a blackout period so that people don= 't have to do tough rebases.=C2=A0 Round (1) will include everything th= at is basically ready to go now.=C2=A0 Round (3) will cover the few substan= tive things we have outstanding.

Thanks again to everyone who partic= ipated today,
--RLB


#556 - Fix some typos.
#555 - Add clar= ifying note about _resolution_ in the most common case.
#554 - Use commo= n-sense definition of _descendant_
#553 - Make definition of _group_ mat= ch the Introduction definition
#552 - fetching KeyPackages SHOULD be rat= e limited.
#551 - Rename InitKeys -> KeyPackages; and GroupInfo ->= PublicGroupState

* Editors will handle these, didn't look like = they needed WG discussion


#509 - Be explicit that Credentials ca= n attest to multiple identities

* Core thing to assure is that we ha= ve the same validation logic across Add, Update, and Commit
* TODO(Richa= rd) Update and propose merging


#546 - Downgrade MUST to SHOULD f= or commit senders including all valid commits
#542 - Conflicting proposa= l / commit behavior

* Agreement on the resolution in the PR: Clarify= that receivers need not generate an error if they see a Commit that they d= on't believe covers all valid proposals.
* TODO(Tom) Update PR, then= editors will review + merge


#523 - Move wire_format to a separa= te tagged-union structure MLSMessage

* Agreement that this is a good= idea; some specifics noted in PR
* On hold until after move-sections-ar= ound PR


#527 - Stronger parent hashes for authenticated identiti= es

* Th=C3=A9ophile reviewed the state of the discussions and curren= t options
* Karthik elaborated on the motivations for covering the crede= ntials in the leaves
* Agreement that covering the leaves as a list woul= d provide the desired security property, possibly with lower efficiency
= * Richard raised the possibility of eliminating unmerged_leaves **only when= the tree is extended**, which should avoid the issues blocking the use of = the tree hash.
* In general, we have the following decision tree among t= he various parent hash options:
=C2=A0 * Do we want to authenticate cred= entials in parent hash?
=C2=A0 =C2=A0 * No =3D> resolution hash
= =C2=A0 =C2=A0 * Yes =3D> Are we OK with efficiency of leaf hash?
=C2= =A0 =C2=A0 =C2=A0 * Yes =3D> leaf hash
=C2=A0 =C2=A0 =C2=A0 * No =3D&= gt; Do we need unmerged_leaves?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * No =3D>= tree hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Yes =3D> tree hash + one of:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Always tree hash over full tree=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Store number of leaves at tree parent= hash alongside parent hash
* TODO(Richard) Describe partial removal of = unmerged leaves on PR
* On hold until after move-sections-around PR
<= br>
#540 - Proposals by reference in external commit

* Agreement = to forbid proposals by reference in external commits
* ... since the ext= ernal joiner can't verify their validity
* TODO(Richard) File a PR t= o implement this


#537 - Clarity around extensions and RequiredCa= pabilities

* Agreement on the "everything in the spec is MTI&qu= ot; approach
* TODO(Richard) File a PR to implement, or close if it does= n't look like one is necessary


#538 - KeyPackage lifetime ha= ndling

* TODO(Richard) Close in favor of #539


#539 - Sepa= ration between pre-published key packages and leaf node content

* Ge= neral agreement that the basic idea of the separation is good
* Broad su= pport for signing ciphersuite, group_id in leaves
=C2=A0 * Some details = to be worked out with regard to how to represent this
=C2=A0 * Storing i= nformation in the leaves vs. just inserting into the signature
* Need to= consider whether extensions are needed at both levels
* On hold until a= fter move-sections-around PR
--000000000000832d4b05d694808e-- From nobody Sat Jan 29 23:46:00 2022 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 CF0C53A1BF2 for ; Sat, 29 Jan 2022 23:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=mnot.net header.b=NDMAzdRv; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=XqSA2Zo2 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 bBrnqY03RgWI for ; Sat, 29 Jan 2022 23:45:53 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B803A1BEE for ; Sat, 29 Jan 2022 23:45:53 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 157633200BF9 for ; Sun, 30 Jan 2022 02:38:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 30 Jan 2022 02:38:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:from:in-reply-to:mime-version:reply-to :sender:subject:subject:to:to; s=fm1; bh=su2PHed0vMpdHvi6dEhAkMi /YTmzovhGoRdDYT4+Bys=; b=NDMAzdRvdsCWV7MIuXgf2PA3wJj7riLQzY2lipw 8Y+Ln6d9Ta86XelEC7O/C2jrgvZop0nN+QRfB0LCE/ZfVxnOUxizr/SZ1fFjBQ64 Qxnjie4FjnHdDVLNdFImEnhkbe59yAAGFkP4AuztF7LmpGGRL0yo7hQ9qTTUFlrv 8mjiOg+gSHwSDiEHQARHtM/T4hzcU2rfcTsO80+cLZhK5b0fei8f44iB7JjADw39 ADEZegDK7LAfMaeKVsizYzQ8O6V7Spysjmy5iGkLqGHl5vAOdz7cU8wNGxqEKjnD cb/sNeDwAGmKQN2ZQbJ/B2Uw8LZTEJ2Qg01wu60Hsj14p6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:from :in-reply-to:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=su2PHed0vMpdHvi6dEhAkMi/YTmzovhGoRdDYT4+Bys=; b=XqSA2Zo2 qL1rQX2S3+GQokfQKcl3owXAk3n54UnsHh6uLrbOAIK31uyIYCqTtPZF6uitkHEH xsamSE37wCh93MPIAesNMTEwgUVJace7JG9qHPs0XPFRBspz9T7PI+0FhyCXfQ66 wxfrK3jieyvsOACnymHIPs46Idm4MbqqkeGIWAhdJKO+6Ubqb26kP//GbfUaxnDe x9Or/FDyNXA2Z/FEo0gk6BwKLCp01N85XozGJG78MFQ1PcNyBaxplKEgN93EbyCl NSKBhcrLMSd57fxCOlNSWLUV0NPxfuYrrUZsB7f2Epxik29eEgzq5VHdWtNv2BE9 IOpWKBPrua9SGQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeekgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmnecujf gurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhihucet tghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeugfef hfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 30 Jan 2022 02:38:46 -0500 (EST) Content-Type: multipart/alternative; boundary="===============1261815378385522868==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20220130074553.38B803A1BEE@ietfa.amsl.com> Date: Sat, 29 Jan 2022 23:45:53 -0800 (PST) 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, 30 Jan 2022 07:45:58 -0000 --===============1261815378385522868== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+3/-7/=F0=9F=92=AC10) 3 issues created: - Remove redundant nodes from the tree (by bifurcation) https://github.com/mlswg/mls-protocol/issues/559=20 - Do we still need `endpoint_id`? (by bifurcation) https://github.com/mlswg/mls-protocol/issues/558=20 - Relationship and definition of Key Schedule and Secret Tree? (by rohan-= wire) https://github.com/mlswg/mls-protocol/issues/557=20 7 issues received 10 new comments: - #558 Remove `endpoint_id` (3 by bifurcation, br-hale, kkohbrok) https://github.com/mlswg/mls-protocol/issues/558=20 - #540 Proposals by reference in external commit (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/540=20 - #539 Separation between pre-published key packages and leaf node conten= t (2 by bifurcation) https://github.com/mlswg/mls-protocol/issues/539=20 - #538 KeyPackage lifetime handling (1 by tomleavy) https://github.com/mlswg/mls-protocol/issues/538=20 - #537 Clarity around extensions and `RequiredCapabilities` (1 by bifurca= tion) https://github.com/mlswg/mls-protocol/issues/537=20 - #528 Include `context` in `MLSPlaintextTBS` for sender_type `NewMember`= (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/528=20 - #409 Draft structure/Editorial Changes (1 by rohan-wire) https://github.com/mlswg/mls-protocol/issues/409 [editorial]=20 7 issues closed: - Proposals by reference in external commit https://github.com/mlswg/mls-= protocol/issues/540=20 - Relationship and definition of Key Schedule and Secret Tree? https://gi= thub.com/mlswg/mls-protocol/issues/557=20 - Clarity around extensions and `RequiredCapabilities` https://github.com= /mlswg/mls-protocol/issues/537=20 - Conflicting proposal / commit behavior https://github.com/mlswg/mls-pro= tocol/issues/542=20 - KeyPackage lifetime handling https://github.com/mlswg/mls-protocol/issu= es/538=20 - Include `context` in `MLSPlaintextTBS` for sender_type `NewMember` http= s://github.com/mlswg/mls-protocol/issues/528=20 - MLS version is used inconsistently in strings https://github.com/mlswg/= mls-protocol/issues/531=20 Pull requests ------------- * mlswg/mls-protocol (+18/-24/=F0=9F=92=AC37) 18 pull requests submitted: - Consolidate ratchet-tree-related sections (by bifurcation) https://github.com/mlswg/mls-protocol/pull/568=20 - Reorg move crypto forward (by bifurcation) https://github.com/mlswg/mls-protocol/pull/567=20 - Split ratchet tree into concepts and operations (by bifurcation) https://github.com/mlswg/mls-protocol/pull/566=20 - Add some subsection divisions to the Commit section (by bifurcation) https://github.com/mlswg/mls-protocol/pull/565=20 - Define _key schedule_ and reference in Figure 1 (by rohan-wire) https://github.com/mlswg/mls-protocol/pull/564=20 - Align cryptographic state description with figure (by bifurcation) https://github.com/mlswg/mls-protocol/pull/563=20 - Forbid proposals by reference in external commits (by bifurcation) https://github.com/mlswg/mls-protocol/pull/562=20 - Strip end of line whitespace (by bifurcation) https://github.com/mlswg/mls-protocol/pull/561=20 - Exempt default features from RequiredCapabilities (by bifurcation) https://github.com/mlswg/mls-protocol/pull/560=20 - Fix some typos. (by rohan-wire) https://github.com/mlswg/mls-protocol/pull/556=20 - Add clarifying note about _resolution_ in the most common case. (by roh= an-wire) https://github.com/mlswg/mls-protocol/pull/555=20 - Use common-sense definition of _descendant_ (by rohan-wire) https://github.com/mlswg/mls-protocol/pull/554=20 - Make definition of _group_ match the Introduction definition (by rohan-= wire) https://github.com/mlswg/mls-protocol/pull/553=20 - fetching KeyPackages SHOULD be rate limited. (by rohan-wire) https://github.com/mlswg/mls-protocol/pull/552=20 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState (by = rohan-wire) https://github.com/mlswg/mls-protocol/pull/551=20 - Adjust ASCII art to fit within 72 character limit. (by rohan-wire) https://github.com/mlswg/mls-protocol/pull/550=20 - Add branch/init overview (by bifurcation) https://github.com/mlswg/mls-protocol/pull/549=20 - Update the description of the evolution of GroupContext (by bifurcation) https://github.com/mlswg/mls-protocol/pull/548=20 11 pull requests received 37 new comments: - #565 Add some subsection divisions to the Commit section (1 by bifurcat= ion) https://github.com/mlswg/mls-protocol/pull/565=20 - #562 Forbid proposals by reference in external commits (1 by bifurcatio= n) https://github.com/mlswg/mls-protocol/pull/562=20 - #560 Exempt default features from RequiredCapabilities (2 by bifurcatio= n, tomleavy) https://github.com/mlswg/mls-protocol/pull/560=20 - #555 Add clarifying note about _resolution_ in the most common case. (2= by Bren2010, rohan-wire) https://github.com/mlswg/mls-protocol/pull/555=20 - #549 Add branch/init overview (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/549=20 - #547 Domain separation for KeyPackage and Proposal references (2 by TWa= l, kkohbrok) https://github.com/mlswg/mls-protocol/pull/547=20 - #546 Downgrade MUST to SHOULD for commit senders including all valid co= mmits (5 by bifurcation, raphaelrobert, tomleavy) https://github.com/mlswg/mls-protocol/pull/546=20 - #532 Get rid of explicit protocol version fields (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/532=20 - #527 Stronger parent hashes for authenticated identities (10 by MartaMu= larczyk, TWal, bifurcation, kkohbrok, psyoptix) https://github.com/mlswg/mls-protocol/pull/527=20 - #523 Move `wire_format` to a separate tagged-union structure MLSMessage= (2 by bifurcation, rohan-wire) https://github.com/mlswg/mls-protocol/pull/523=20 - #509 Be explicit that Credentials can attest to multiple identities (10= by bifurcation, br-hale, tomleavy) https://github.com/mlswg/mls-protocol/pull/509=20 24 pull requests merged: - Split ratchet tree into concepts and operations https://github.com/mlswg/mls-protocol/pull/566=20 - Add some subsection divisions to the Commit section https://github.com/mlswg/mls-protocol/pull/565=20 - Forbid proposals by reference in external commits https://github.com/mlswg/mls-protocol/pull/562=20 - Be explicit that Credentials can attest to multiple identities https://github.com/mlswg/mls-protocol/pull/509=20 - Define _key schedule_ and reference in Figure 1 https://github.com/mlswg/mls-protocol/pull/564=20 - Align cryptographic state description with figure https://github.com/mlswg/mls-protocol/pull/563=20 - Exempt default features from RequiredCapabilities https://github.com/mlswg/mls-protocol/pull/560=20 - Strip end of line whitespace https://github.com/mlswg/mls-protocol/pull/561=20 - fetching KeyPackages SHOULD be rate limited. https://github.com/mlswg/mls-protocol/pull/552=20 - Use common-sense definition of _descendant_ https://github.com/mlswg/mls-protocol/pull/554=20 - Add clarifying note about _resolution_ in the most common case. https://github.com/mlswg/mls-protocol/pull/555=20 - Make definition of _group_ match the Introduction definition https://github.com/mlswg/mls-protocol/pull/553=20 - Fix some typos. https://github.com/mlswg/mls-protocol/pull/556=20 - Rename InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState https://github.com/mlswg/mls-protocol/pull/551=20 - Downgrade MUST to SHOULD for commit senders including all valid commits https://github.com/mlswg/mls-protocol/pull/546=20 - Adjust ASCII art to fit within 72 character limit. https://github.com/mlswg/mls-protocol/pull/550=20 - Add branch/init overview https://github.com/mlswg/mls-protocol/pull/549=20 - Domain separation for KeyPackage and Proposal references https://github.com/mlswg/mls-protocol/pull/547=20 - Tighten up branch and reinit; define ResumptionPSKUsage https://github.com/mlswg/mls-protocol/pull/525=20 - Update the description of the evolution of GroupContext https://github.com/mlswg/mls-protocol/pull/548=20 - Remove version from ciphersuites https://github.com/mlswg/mls-protocol/pull/544=20 - Make some sections easier to read. https://github.com/mlswg/mls-protocol/pull/541=20 - Be consistent about version labeling https://github.com/mlswg/mls-protocol/pull/543=20 - Unambiguous signatures https://github.com/mlswg/mls-protocol/pull/526=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============1261815378385522868== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday January 30, 2022

Issues

mlswg/mls-protocol (+3/-7/=F0=9F=92=AC10)

3 issues created:

7 issues received 10 new comments:

7 issues closed:

Pull requests

mlswg/mls-protocol (+18/-24/=F0=9F=92=AC37)

18 pull requests submitted:

11 pull requests received 37 new comments:

24 pull requests merged:

Repositories tracked by this digest:
--===============1261815378385522868==-- From nobody Mon Jan 31 19:16:10 2022 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 A20723A0E1C for ; Mon, 31 Jan 2022 19:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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.20210112.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 UOW8hVQhn1P7 for ; Mon, 31 Jan 2022 19:16:06 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 91BC93A0E1A for ; Mon, 31 Jan 2022 19:16:06 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id o10so14053827qkg.0 for ; Mon, 31 Jan 2022 19:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=EjuNUA4FybztYsLnZQIYdSC7srTf21UNwCcUo91dNfs=; b=2fr9o/j1Mih8Bt6TyP75W6Us5EUyTY8q4yrWPEUjXmAWm1Yh9LYAVdiHVB1uoAklc7 kf5wk2wbaCNVP6D6yIoBhsmykJSNZ0YdSQtAfwqBp21VulxVVvURpTx+ooQlaMKkZT1x Bx0qaJdl+ZZcxpS70VZGZOnBniWONsmL0WI1CPPDiX7x5L47SZUsnL15aJ4k/cVnzRHK nOpEiyzLXxvsbVRpftSYCpWoHLQ9G1e9MpX+FZrubSW3kJ12Q78+7Mfk/VZpmTEbXwaM gDmONZKCwAMXUc97OU9IK2uTMZqPuGNnDnQSXbhOsiL/y3M1xsF3bavyVkALXX35aYTb Vxdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EjuNUA4FybztYsLnZQIYdSC7srTf21UNwCcUo91dNfs=; b=KYq31QFOtrmKdxxguRwbqKUWCJbKTojwcXjzlXfCQ9qBEHSAjjBCdaop/DYiA8YC+x aAf+W+rzq5+XElBNJlufs0RI2C7WZGkCjmC14qLzJXvzDfZdIcX7SvCHkiSUQr4PbxU2 /RrZbaEj6x0ildQ/WCzpuudebNSgwLnHrXXjXX+qIy2j8Jk2eFFL6dm1CDmdb3gSblSV tCG49mCeQER5FavkctBj9PlD+4XQagUSERzf0ite/UNiXUxZTwKs9zeBA3Gy4Hoj977g QGnEHq5OnnaF1M0n1ArKFEoBqgNF8VapjSjUX/QAh0IvmRzVR1ezKNgex/422lQQuNGG mygg== X-Gm-Message-State: AOAM5302N9lkPINuGf7AkuCKPFHUeNfkrMu1dLknsQbbELUkr59FstwQ ARGdOlj3SC/cWnt/XVDI9+SKo/5UTsoxlEY5Q10EN8t7KWY= X-Google-Smtp-Source: ABdhPJwcos4P2AYalr6EaaPTBEC1Tsig11TICck6f1IllDSuP2XFi+p6iTBmJf5JC5p7OHdZGCSi7Ld8B0IcV9Z+4mg= X-Received: by 2002:a37:9444:: with SMTP id w65mr15382330qkd.468.1643685364376; Mon, 31 Jan 2022 19:16:04 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 31 Jan 2022 22:15:53 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000443a1405d6ec522d" Archived-At: Subject: [MLS] Reorg complete 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, 01 Feb 2022 03:16:09 -0000 --000000000000443a1405d6ec522d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, The series of PRs reorganizing sections in the MLS protocol spec have now all landed. (Except for one that is so small I=E2=80=99m not counting it.)= The spec should now be safe to make PRs on without risk of bad rebases. Thanks to Rohan and Brendan for helping get this done! =E2=80=94Richard --000000000000443a1405d6ec522d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all,

The series of PRs reor= ganizing sections in the MLS protocol spec have now all landed. =C2=A0(Exce= pt for one that is so small I=E2=80=99m not counting it.) =C2=A0The spec sh= ould now be safe to make PRs on without risk of bad rebases.=C2=A0

Thanks to Rohan and Brendan for = helping get this done!=C2=A0

=E2=80=94Richard
--000000000000443a1405d6ec522d--