From nobody Sun Oct 3 00:46:06 2021 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 CF99C3A0B92 for ; Sun, 3 Oct 2021 00:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=epNGRW5b; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KKi+3gp0 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 5ZXhQkYXyiHy for ; Sun, 3 Oct 2021 00:45:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182F63A0B98 for ; Sun, 3 Oct 2021 00:45:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2AC8E5C0108 for ; Sun, 3 Oct 2021 03:38:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 03 Oct 2021 03:38:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=Vli9A+TkLUU oQIvoxyITTpZxlUou9QcLbHXgeTXSZtc=; b=epNGRW5bEuTnur2sWZGVfktEZ3I mbXLzf7UZ8MhY3X/tnBXOCYgK60ovkACva3kecFoosXY50QLku2CSbUcDYqJ23Ge 7VWGkZZI3vKhQeMHV6MVFip71EMNyfpz8ViaX33lUWFpU/W0piO5kWLiK9CIKSQi +mrZujw8bQg5gntMR03LK+iR43f4K2QYSuAHIXDHXyNpt9mlePzocyHakrgt8cOY xTooNkXKgPsKsP7uySJItd8+BUttNY2Yz+UKTe4MZXVZwylruBDSe+JRqOK3zqx+ dBQFpBPErq0ftVUdhwGdVpVz+9EkK+Phv/vDDTDi1be1uhdsB+RAEcDxm2g== 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=Vli9A+TkLUUoQIvoxyITTpZxlUou9QcLbHXgeTXSZtc=; b=KKi+3gp0 FaKQseZzBMOGwuinguYLU/COSBLbtejs0fJAcSk/L8s+gk/yeGSYr7anJi4bmexR YbjZr7Xhwj4DiCXHuEnf4UYbm6vC9zasVFsX/5/aXaKud86G7yE4jWHzLp3lPrCt zas7PZ6XJRP2YIxVaBSNHi8KobsNcOvKA0D+H8RufD5y/pIA+BvX2mKw/69Z3oSt 96jxZvLFBzw8oyyGwzgsYzNESpUIywpic77YR7Efj/H4dyMByrUvANTswSh77JYS D8RxDc/+tna2D1eSBi+V5gcPwS1IwPM8RHUNblB6SAb+W6gM3CzzWFD8YReaPaFS zCyFi8EE9rtwTw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekledguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 3 Oct 2021 03:38:41 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4218951101691814341==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20211003074551.182F63A0B98@ietfa.amsl.com> Date: Sun, 3 Oct 2021 00:45:50 -0700 (PDT) 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, 03 Oct 2021 07:45:57 -0000 --===============4218951101691814341== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+1/-0/=F0=9F=92=AC1) 1 issues created: - Address Open TODOs in Document (by br-hale) https://github.com/mlswg/mls-architecture/issues/83=20 1 issues received 1 new comments: - #71 Definition of a group member can be strengthened (1 by br-hale) https://github.com/mlswg/mls-architecture/issues/71 [editorial]=20 * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #443 External commit for resync used with PSK (2 by bifurcation) https://github.com/mlswg/mls-protocol/issues/443=20 Pull requests ------------- * mlswg/mls-architecture (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Architecture Document Review (by br-hale) https://github.com/mlswg/mls-architecture/pull/82=20 * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #480 Improve extensibility of Proposals (1 by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/480=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============4218951101691814341== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 03, 2021

Issues

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

1 issues created:

1 issues received 1 new comments:

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

1 issues received 2 new comments:

Pull requests

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

1 pull requests submitted:

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

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============4218951101691814341==-- From nobody Mon Oct 4 05:14:24 2021 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 E4D943A144E for ; Mon, 4 Oct 2021 05:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 NJ95bP1ZbT_7 for ; Mon, 4 Oct 2021 05:14:18 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 BB8303A144A for ; Mon, 4 Oct 2021 05:14:17 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id l6so10940740plh.9 for ; Mon, 04 Oct 2021 05:14:17 -0700 (PDT) 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=nYT4STfZ5msZ9HTpHVDtyeNORTtvL5tKjKvDRwIiBbQ=; b=NSXFk+fgQImAWC9Elm/DUMLzYT+rHbkns27vo6ZA0TIHHzX5LHdrJvW93cT6g2rRY1 wxsnJfUqafLU6rxNydElqfHDQIsikKSB5D0peBObnDURDShjanDqig6IQxeEWnaMbGgx Tv/nJJXL6b7FC3CxO8PhMy9f24nCwJ24cK56/ae6cXyeuVkZ3g9ya+eGowcNbjkLqRx3 FWa34SMYaJ7u48GcEnK19tq4eeghzA5cXKgTbI0/WxWsE0cA65OSVDurZq951qUq+HP6 qKK0B4GAM5gzjdHaQE7m1T7iLND9uAZuguO3InZoL/t2FhshxLWPFgc669EvHn4imcS5 EZDQ== 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=nYT4STfZ5msZ9HTpHVDtyeNORTtvL5tKjKvDRwIiBbQ=; b=aonwyI2BjBAHMG0etlNdcZXj/r4AQHuL6pbanYwOMStsh9NfbiVmpH/jC44XVFNwsT SPletc82rhZNhxbVDsH36cazGwp2GoOtZ4SCwBw2byXuK/kUM1XHElnOEB2QJRn2NINX whRsEEzV0jWGbK8V03jfl8hGp8zwOU8wCy+vmos4yjFg66qoCezE9pgoerWyWuFr730G kVh5ySdqWgcqeNAJPkoiulhkGSaPByyl+Gy627Hp285rVsoXjX/e4RlG+pC7F/lKBlKj ivRqoW+Dxho12WDS0wEkraZQKJky3oqkSYF5T+86Q4wAjo0zzcZ5IpVZUkUTDijAUSpr gXoA== X-Gm-Message-State: AOAM5302iLCq8qgTur809uSB5fVXejzV2DibjIWmPOOfCxYzo1/5cavm 3uOv8bpcYwdItciPS9ZXbk9eT0nkeOaC8yPds9miKkb3NwgsLA== X-Google-Smtp-Source: ABdhPJx8g7RZ+G6D+axa6TYLTCYNd72N5tYJrsoSKGG3m7XJUrqz9Dab3zOmuHDti1TRSc11BKiTTQz5UkRWtHc+MYs= X-Received: by 2002:a17:902:7b85:b0:13d:cdc4:9531 with SMTP id w5-20020a1709027b8500b0013dcdc49531mr22984918pll.27.1633349656409; Mon, 04 Oct 2021 05:14:16 -0700 (PDT) MIME-Version: 1.0 From: Rohan Mahy Date: Mon, 4 Oct 2021 05:14:05 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000010897d05cd85daaf" Archived-At: Subject: [MLS] Mandatory extensions in MLS? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 12:14:23 -0000 --00000000000010897d05cd85daaf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Do we want to be able to support mandatory extensions in MLS? Many protocols which have an extensibility mechanism have a way to indicate that understanding an extension is mandatory for certain behaviors. If we do not add this capability now, we can never add it later without updating the MLS version number. For MLS, this would mean having a way to require a member understand an MLS extension before it can join a group. The three extension types defined currently are: MLS ciphersuites, MLS extension types, and MLS credential types. One logical way to add mandatory extensions would be to pick one of these types (the MLS extensions type) and use the high order bit or a specific range to indicate that a member must understand and implement the extension to join a group which uses that extension. The IANA values could be changed as follows: Values from 0x8000-0xffff indicate understanding the extension is required 0x7f00 - 0x7fff Reserved for Private Use (not required) 0xff00 - 0xfff Reserved for Private Use (required) If a required ciphersuite or credential becomes necessary, a new extension type could be created to add an extension in the KeyPackage or GroupInfo which would be required and would indicate support for the mandatory ciphersuites or credentials. In order to prevent some other entity from adding an MLS client that does not support a mandatory extension, we already have the KeyPackage Client Capabilities, which lists which extensions are supported by the client. Thoughts? 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 --00000000000010897d05cd85daaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Do we want to be = able to support mandatory extensions in MLS? Many protocols which have an e= xtensibility mechanism have a way to indicate that understanding an extensi= on is mandatory for certain behaviors. If we do not add this capability now= , we can never add it later without updating the MLS version number.
For MLS, this would mean having a way to require a member understand an ML= S extension before it can join a group. The three extension types defined c= urrently are:
=C2=A0MLS ciphersuites,
=C2=A0MLS extension types, an= d
=C2=A0MLS credential types.

One logical way to add mandatory = extensions would be to pick one of these types (the MLS extensions type) an= d use the high order bit or a specific range to indicate that a member must= understand and implement the extension to join a group which uses that ext= ension. The IANA values could be changed as follows:

Values from 0x8= 000-0xffff indicate understanding the extension is required
0x7f00 - 0x7= fff =C2=A0Reserved for Private Use (not required)
0xff00 - 0xfff =C2=A0 = Reserved for Private Use (required)

If a required ciphersuite or cre= dential becomes necessary, a new extension type could be created to add an = extension in the KeyPackage or GroupInfo which would be required and would = indicate support for the mandatory ciphersuites or credentials.

In o= rder to prevent some other entity from adding an MLS client that does not s= upport a mandatory extension, we already have the KeyPackage Client Capabil= ities, which lists which extensions are supported by the client.

Thoughts?
Thanks,
-rohan
=

Rohan Mahy=C2=A0 l=C2=A0 Vice President Engineering, Archi= tecture

Cha= t: @rohan_wire on=C2=A0Wire

= =C2=A0

Wire=C2=A0- Secure team messaging.

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

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

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE2= 88748675

--00000000000010897d05cd85daaf-- From nobody Mon Oct 4 05:28:23 2021 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 124C33A147B for ; Mon, 4 Oct 2021 05:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 0EntNgWfXIZ0 for ; Mon, 4 Oct 2021 05:28:14 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 87AD53A1467 for ; Mon, 4 Oct 2021 05:28:14 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id pf6-20020a17090b1d8600b0019fa884ab85so3411700pjb.5 for ; Mon, 04 Oct 2021 05:28:14 -0700 (PDT) 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=oW10PE1Wm24xfoWp/TEyjRaJXjMpo19letg24G0gLMU=; b=69NSw5oU1+dDYKliWvBd2r7x+opZz44Mun2xVIGIbsB2QRYChAwW4/Nqgim4P+4sMX n8V3G+CBgp7DrNfebOQy5+jIWYc2YnR1HMbt4t4gjf9+w5EYScSc4sEx9QEz6eXp1Wqg i+Uel4H/eTWme6mPK7/ZboW14E+B+w0k5dD8SOaQAX4D74J45llcA2lDwdrwGKodEpyU LtKWXGZM1EuDvPdgcjR9j1f1CpJbJpmKvKnL+cxhuH78FAF5fFpMzpg0rjOGtunPwv42 OvctI6gajcZbK9/isHC8CakJD27LyO4bK/YPKmt/FJsh2+SE9IpbnoXrqYsWAOniqQvJ dKzg== 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=oW10PE1Wm24xfoWp/TEyjRaJXjMpo19letg24G0gLMU=; b=qPRi3fWd1i8vR1bx8QkiQkbMkR2o1oqv4r9gBwhIKbO5SrGemEnGbgiYfcs+My+LOX HNXa/CIEy1Bx5lPzjzgfcGKAb8fIUGBrLeJC3sxk1dE1ZOKLg73OlTY++XHdh7oYjTX/ 7CvTxRzhkh6WD9OnbKR9mVUgFGpwyhtqjjF91OUiCljXhpnWBbuZu8Iw1EgTEsoiX0JH +IhwOtl+gCVFEyfNUDUKGYuFSyvD6aN1u/x2x4p5GcNY4ASkEcKv+suCl4kAoXJuea5m 3ot3WmMpkwAKyO/tLcBbtBv1jMfboG6e440MWP67zuxqkhiIWAspNJ+PqcWzzkIRXXVb LNSw== X-Gm-Message-State: AOAM533RFHOC66cEB+jLLsHNHjiy+nDfvJ1tDQUWGwIfHkxL/bRMP/CB k8FoMbXiy5hIXjHsugr7SSNGo27xcTE1U+fVhaC/Yl+eRTQZwQ== X-Google-Smtp-Source: ABdhPJzk/alqxrNl19bCCQMv0+YaSIIBGtpXzL2Mt2PhD/NA98k/KuPH4Q+SkDPBxabqNnjsSnSiSG9WKjL9TnOtpb8= X-Received: by 2002:a17:902:7b85:b0:13d:cdc4:9531 with SMTP id w5-20020a1709027b8500b0013dcdc49531mr23043679pll.27.1633350493399; Mon, 04 Oct 2021 05:28:13 -0700 (PDT) MIME-Version: 1.0 From: Rohan Mahy Date: Mon, 4 Oct 2021 05:28:02 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000f3fcf905cd860b44" Archived-At: Subject: [MLS] solution to getting in a Commit fairly in a busy group 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, 04 Oct 2021 12:28:20 -0000 --000000000000f3fcf905cd860b44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, The protocol document describes a situation in large groups with frequent adds and joins where a client (especially over a high latency connection) may be trying to issue a Commit, but other clients keep getting their Commits in first. I think this could potentially yield unpredictable behavior. If clients can request a commit sequence number from the Delivery Service, all other clients with a higher commit sequence number could wait for the commits with a lower number to complete before sending their commit. The commit sequence number could be supplemented with a lifetime (ex: 30 seconds) after which a client loses its place in line. This seems like an ideal extension to MLS, but unless there is a way to make extensions mandatory within a group, I don't see how we could add this functionality later. Many 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 --000000000000f3fcf905cd860b44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

The protocol document= describes a situation in large groups with frequent adds and joins where a= client (especially over a high latency connection) may be trying to issue = a Commit, but other clients keep getting their Commits in first. I think th= is could potentially yield unpredictable behavior.

If clients can request a commit sequence number from the Delivery Ser= vice, all other clients with a higher commit sequence number could wait for= the commits with a lower number to complete before sending their commit. T= he commit sequence number could be supplemented with a lifetime (ex: 30 sec= onds) after which a client loses its place in line.

This seems like an ideal extension to MLS, but unless there is a way to m= ake extensions mandatory within a group, I don't see how we could add t= his functionality later.

Many thanks,
-rohan

Rohan Mahy=C2=A0 <= span style=3D"font-family:Arial,sans-serif">l=C2=A0 Vice President Engineer= ing, Architecture

Chat: @rohan_wire on=C2=A0Wire

=C2=A0

Wire=C2=A0- Secure team messaging.

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

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

HRB 149847 beim Handelsregister Charlottenburg, Berlin=

VA= T-ID DE288748675

--000000000000f3fcf905cd860b44-- From nobody Mon Oct 4 05:46:46 2021 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 8515A3A00AD for ; Mon, 4 Oct 2021 05:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 tc3y_C9ypKU1 for ; Mon, 4 Oct 2021 05:46:38 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 301AD3A00B0 for ; Mon, 4 Oct 2021 05:46:38 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id g14so14430345pfm.1 for ; Mon, 04 Oct 2021 05:46:38 -0700 (PDT) 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=4dkiwYwFvCW4tRZSPgVfKLg+zaUEcZIOcawzvhG7gBw=; b=T50svo9A8nMsOjwU8diaGYwLxr45hacpvtVSM+vcwm9wZuMjcx7dMV2BGjCs3117kS ZLvWjneXEFhbwiBeQhDlrhkYnHB45r26mT3OGuiapR0GJ+QCIU3z5d9EwAonbo3ck/bz JddwQ2pkzFnX3X/S77nCD6p9miG0ypG36C90f6yVpqtNq12ZWHjo5WeGRoIxdfq4trn9 9/LPiWCyJKfIawcBlSjaogVkx4xs05piYkqVvaFyIqOPukHmYxdqYWk4+HaeZgGKbnsf IUbzYwvgCzdPii1UkQHhGET7CiIQ1whKJRH07uqPpVskApsIT/Q6qJtwMnCQSvCYN0Q3 UFHQ== 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=4dkiwYwFvCW4tRZSPgVfKLg+zaUEcZIOcawzvhG7gBw=; b=p3rBWpsEqw8iBCva28s13a8BG7zt8qa6877Q4yvp/EtdgJJLHtcU7qjHJnBa7sp+Pv tbjV+lXusBEELeg4j0cP6AAWcifMdJcD3snBWhrRZNpE2FOftq32eRYTVEL73z68QMcx a0LCLgddf32vIU3ynoropd27AmOHCKINxcEsf4unvuHnmOj1PPX/w2XVLU4ECyEpv8Lv ppmLPXgxYH9E9gTlbs9CZPnWjKrdFf4GK28VhFMz39+w06gZXu7Me3o6O/mCjKN0/TQB vCut24PwuATdpfaAbFQffyeO3sM0yfINB/Zi9TE66lhhYL5RYm1RawZaJ3YANbWDEk0P VkiA== X-Gm-Message-State: AOAM532BzH3f8TT9B6cC8nQ1Mzy/axD/3LsWgiPEdAGPabD+ielC1Y7S tQrkISPeo26OI5HrsokQaamHq9p8jSNrRBo+gTooCM1coWk= X-Google-Smtp-Source: ABdhPJyrSCEhV/f3iZXhCYC+2mW7NrYPbaVpEQfLobQxdbKG0D8oCi1pZOTVJv4gBNVDuWsWleFZqrDDpNeylQLBvCY= X-Received: by 2002:a63:9d0d:: with SMTP id i13mr10574979pgd.117.1633351597049; Mon, 04 Oct 2021 05:46:37 -0700 (PDT) MIME-Version: 1.0 From: Rohan Mahy Date: Mon, 4 Oct 2021 05:46:26 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000bc629005cd864dd6" Archived-At: Subject: [MLS] normative vs. non-normative references in mls-protocol draft 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, 04 Oct 2021 12:46:44 -0000 --000000000000bc629005cd864dd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, According to my understanding of normative vs. informative references, several more of the references in the mls-protocol draft should be normative, and all the components of the MLS ciphersuites should have normative references as well: make normative? [RFC8032] [SECG] [SHS] add [RFC5869] [RFC7748] [RFC8439] 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 --000000000000bc629005cd864dd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

According to my under= standing of normative vs. informative references, several more of the refer= ences in the mls-protocol draft should be normative, and all the components= of the MLS ciphersuites should have normative references as well:

make normative?
[RFC8032]
[SEC= G]
[SHS]

add
[RFC5869]=
[RFC7748]
[RFC8439]

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 messagi= ng.

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

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

HRB 149847 beim Handelsregister Charlott= enburg, Berlin

VAT-ID DE288748675

--000000000000bc629005cd864dd6-- From nobody Mon Oct 4 05:48:42 2021 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 B616E3A00C3 for ; Mon, 4 Oct 2021 05:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URI90lYURNwP for ; Mon, 4 Oct 2021 05:48:37 -0700 (PDT) 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 20B2B3A00C4 for ; Mon, 4 Oct 2021 05:48:37 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id f15so15685570qtv.9 for ; Mon, 04 Oct 2021 05:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=cyyBkyiQSTqDgf9QdrqWUTUfFgrzPC6Pz79X6LwL/ZY=; b=A0etXbNRQQD3uZNQ/42G0S9H4gEm7PVO9QuvwrLMpEhHCPzeMwoj+g6u/KTnpbxyQA 9bI4GiSsDIx7VXPhUYKOnSWsVISSYdjaYTtC/UM2wMkycBHogyYxr45nvDbtEWKTZnZS K2qaMcyC1Zo6T/07KGeik4F9zLR8jhCbn6adY= 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=cyyBkyiQSTqDgf9QdrqWUTUfFgrzPC6Pz79X6LwL/ZY=; b=wi7oY5clEjckQnTpt24In+SN6sUKKuaLId5hA+xy0T5ddxg7r90GgYfGVOhICDHm4l 8jE85ImJ2EODOC6VlNeGCa5tJf0Sc2QQnMw9j2uEYETW1ycj8dzo28qvUg0ws8I5knON N0G83vzqqXY6H2covvfzBL84j6QdVTBDyAzVL8DTUY63LyGuVyUO9oGXJ0JLvUBT8cIl R64o0MwMwYOcLV2fX1+lA8zphIWnPp/aK+e0s8FwccAz4Nuj4kqPjaSWrCMLdqDeZ4rT xBDZxwyvB/RFQ4dqFzGzdokGYJpPe+c/Wc2l7OIkfzRyslonzEuSrK5jKw8lWrQEFBZs GeWg== X-Gm-Message-State: AOAM5325NHRZI1pNMWSsfEeE0klrRyzLwPjA3ahvUidAmqkGicR6zlYp 1vIGy/qXldhRQkcMOnVPLCg9cNBGGh4Grw== X-Google-Smtp-Source: ABdhPJwBAWio+UDvixv3OYtKUbqJLGEIZZesld5WicnJms43QIB7JUshLuun1XoT8icIcL0aXYK+QA== X-Received: by 2002:ac8:428d:: with SMTP id o13mr13284554qtl.44.1633351715660; Mon, 04 Oct 2021 05:48:35 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id r196sm7602349qka.119.2021.10.04.05.48.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Oct 2021 05:48:35 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <9AAE4C63-C16C-4FC5-B7BE-FDDBADE807CB@sn3rd.com> Date: Mon, 4 Oct 2021 08:48:34 -0400 To: MLS List X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [MLS] Reminder: 20211004 MLS Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 12:48:42 -0000 Hi! Last minute reminder that our interim is today. I updated the repo = to include the relevant information and some chair slides: https://github.com/mlswg/wg-materials/tree/main/interim-2021-10 This information can also be found at: https://datatracker.ietf.org/meeting/interim-2021-mls-02/session/mls Cheers, spt (for the chairs)= From nobody Mon Oct 4 05:57:54 2021 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 178833A0127 for ; Mon, 4 Oct 2021 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 MIeRuSb-IpP2 for ; Mon, 4 Oct 2021 05:57:47 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 225243A0115 for ; Mon, 4 Oct 2021 05:57:47 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id r2so16441377pgl.10 for ; Mon, 04 Oct 2021 05:57:47 -0700 (PDT) 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=jebQkO+GPbFjXBwOk7ndYtOJIP35gMjRYHRwDT1acU0=; b=2s40oqfVTnct5tOAGhdiXCiMfh8GO5Lupeut2OvhKrahsnyW+AL/oQU0VsBOKKg4XU ZwbBVpX97ktDMCjMZEv24smk9xy3tMrBmhHe4twuY2ueaVLTRwnce52/3m4BAGu6AW6E 5ULTENlkFj3EKzUvZYP2feoPw7yqPCTofU18TvSmvwc3ABxI3mqGeaTLrkZi7IKxmdRZ 9huDQRcI1PYVpWyL9XolcfuJZQRuHbdddPHHtRfpG0XPDIG6esGbPCSuBBKFSoG2Pkls MFtzECCbZtI64GCkcjiMpam8G6Kw8EjK+8uMI8Lxhv0JfXnxmQMR1IKfm9YeINBxYEhy f3WA== 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=jebQkO+GPbFjXBwOk7ndYtOJIP35gMjRYHRwDT1acU0=; b=cDw6wiePK7+nIdKmBg5nT+9tq7tmcZBsb65Yd+ImMT0yGI69ZBIuuLksyP5RcStSOR igCig0BOqQxA7CK+jcfNguN3ZXbuFjjZWuycqTRztZevM38CS01SGL4tjzbK3rBi5f54 BDqvj0BMOxpanMcU2O+lrMAIEwSRS/iATUDq9GZZktOYS0x+ID19MSlM2cd+MCZw3PGC jNwa7npEQQjHUo726iGzKacaAwiY3jydjmnB70i/QjSC3ae7HOWVg3wKCbapQKp4j96Q amowYwq7APG8NBow+FrUlTTTX1IgidKcA/wo89WAzGyu5qCpCj8xQqBCA8zVFmn1mFkz i3Xg== X-Gm-Message-State: AOAM531+hkbXcuRLoThSW9Dd0P0ABSZRRliJRSQnpp+cjgz46x5DXcSD WGoQB3zQfQZlrKy7yF/LzNTVDIzFJGiQfMvYD4y/NAQdUGE= X-Google-Smtp-Source: ABdhPJy1/MZrcTHpmMlY5eGuu8afdI6VWquZVaKn8U5JZhVZFrT1AXiUc3sBKg3n645WOqK5lwuqZ/YGt4EjTTSh/2w= X-Received: by 2002:a63:dd56:: with SMTP id g22mr10499460pgj.38.1633352265959; Mon, 04 Oct 2021 05:57:45 -0700 (PDT) MIME-Version: 1.0 From: Rohan Mahy Date: Mon, 4 Oct 2021 05:57:35 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000009b1f2a05cd867525" Archived-At: Subject: [MLS] consistent labeling conventions for tree diagrams 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, 04 Oct 2021 12:57:52 -0000 --0000000000009b1f2a05cd867525 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The MLS protocol draft uses many different and inconsistent labeling conventions in the ASCII art of ratchet trees. In Section 5.1, non-leaf nodes are labeled with the leaf nodes descendants (ex: AB; EF ; ABCD ) In Section 5.2, a parent node is labeled CD[C] (presumably to indicate an unmerged node?) In Section 5.4, on diagram has parent nodes labeled with letters E and G ; another diagram uses np[0] and np[1] I propose that we use letters to refer to leaf nodes, and use the node index to refer to all non-leaf nodes, followed by a table indicating any special properties (blank parent nodes, unmerged leaves, etc). 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 --0000000000009b1f2a05cd867525 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
The MLS protocol draft uses many differ= ent and inconsistent labeling conventions in the ASCII art of ratchet trees= .

In Section 5.1, non-leaf nodes are labeled with = the leaf nodes descendants (ex: AB; EF ; ABCD )
In Section 5.2, a= parent node is labeled CD[C] (presumably to indicate an unmerged node?)
In Section 5.4, on diagram has parent nodes labeled with letters E = and G ; another diagram uses np[0] and np[1]

I pro= pose that we use letters to refer to leaf nodes, and use the node index to = refer to all non-leaf nodes, followed by a table indicating any special pro= perties (blank parent nodes, unmerged leaves, etc).

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

--0000000000009b1f2a05cd867525-- From nobody Mon Oct 4 05:58:32 2021 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 77EB63A0127 for ; Mon, 4 Oct 2021 05:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH-ZSA7bYRtJ for ; Mon, 4 Oct 2021 05:58:25 -0700 (PDT) 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 4BB103A05DF for ; Mon, 4 Oct 2021 05:58:25 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id p4so16266372qki.3 for ; Mon, 04 Oct 2021 05:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6dAA9xVw35OY5D6RfIyXxkKJZT9vrLj4HWVyUe/EnC0=; b=Y/d3JmewQurpLzKLLFJJ65H9WUWQ5MOOy+4UTFG+mOpPZenxI2qDt+Dl4WdjeOvEPl RM+38MDGqkDosNvj3PC6q7UsefMu3+ldDzFWk+RgA9YnccIRfAfM0w6BP5GLDYbW/xHu 0sB7az+j/Mh4jN61p/xsnBC22HyAA/CY5NNWE= 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=6dAA9xVw35OY5D6RfIyXxkKJZT9vrLj4HWVyUe/EnC0=; b=4rnR/7oIqt1m4uUwIqYwgG45fxTopFUszm1y3SinQmzkIzb7ijhbRbXWoayrRm6Vep YvmuW0T9zocyI/xMihM1doSIQ/gLZgOGdCzvMKCgSN3K6i28O9ZzCS5Vw8QxJ5/22hRz I95KVmbb9nKfmt5IQxu3uInk2bnrDXl7jA/9k+z4ijD14lGoK2mZa0VKTEernXnLOSp8 4u6sj0tqid/tCJSAmyrMFY1rP9t9syr6rbEc3RyYnpDknDVNOrXvqYrUQpgtUELqnXda yJbHzbEFxbr6TPWsjt7QP/3Yr6YGtmUXPAvt9vMtGmovCeRpRsFcym7FK3q37IrSnOPL PP9A== X-Gm-Message-State: AOAM5320hIgUF/TYmYJoDCVwlCJXB6t0l4GwYfzDhPvILVJUfnrlfmZd bhiRjQPNzh8QTwWpnGf7246jcvSPLqysAw== X-Google-Smtp-Source: ABdhPJwvKKeTbZRF+qL0yY8RsfV1TJ9csI7tksOGaREkJQljQWNDmooUSTYXlydwfP3M1GctMj+bdQ== X-Received: by 2002:a05:620a:5fd:: with SMTP id z29mr9789045qkg.36.1633352304051; Mon, 04 Oct 2021 05:58:24 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id 10sm8996001qtu.66.2021.10.04.05.58.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Oct 2021 05:58:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: Date: Mon, 4 Oct 2021 08:58:22 -0400 Cc: MLS List Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rohan Mahy X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [MLS] normative vs. non-normative references in mls-protocol draft 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, 04 Oct 2021 12:58:31 -0000 Rohan, The rule can be basically summarized as: if have to implement it for = interoperability it=E2=80=99s normative. I suspect that you are right = about all of these. Mind you, I would rather refer to RFC 6090 instead = of SECG if we can get away with it. spt > On Oct 4, 2021, at 08:46, Rohan Mahy = wrote: >=20 > Hello, >=20 > According to my understanding of normative vs. informative references, = several more of the references in the mls-protocol draft should be = normative, and all the components of the MLS ciphersuites should have = normative references as well: >=20 > make normative? > [RFC8032] > [SECG] > [SHS] >=20 > add > [RFC5869] > [RFC7748] > [RFC8439] >=20 > Thanks, > -rohan >=20 >=20 > Rohan Mahy l Vice President Engineering, Architecture >=20 > Chat: @rohan_wire on Wire >=20 > =20 >=20 > Wire - Secure team messaging. >=20 > Zeta Project Germany GmbH l Rosenthaler Stra=C3=9Fe 40, 10178 = Berlin, Germany >=20 >=20 > Gesch=C3=A4ftsf=C3=BChrer/Managing Director: Morten J. Broegger=20 >=20 >=20 > HRB 149847 beim Handelsregister Charlottenburg, Berlin >=20 > VAT-ID DE288748675 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Mon Oct 4 06:17:41 2021 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 9CDB23A03FF; Mon, 4 Oct 2021 06:17:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <163335344044.19663.16839282232171332725@ietfa.amsl.com> Date: Mon, 04 Oct 2021 06:17:20 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-architecture-07.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 13:17:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Architecture Authors : Benjamin Beurdouche Eric Rescorla Emad Omara Srinivas Inguva Albert Kwon Alan Duric Filename : draft-ietf-mls-architecture-07.txt Pages : 34 Date : 2021-10-04 Abstract: The Messaging Layer Security (MLS) protocol [MLSPROTO] document has the role of defining a Group Key Agreement, all the necessary cryptographic operations, and serialization/deserialization functions necessary to create a scalable and secure group messaging protocol. The MLS protocol is meant to protect against eavesdropping, tampering, message forgery, and provide good properties such as forward-secrecy (FS) and post-compromise security (PCS) in the case of past or future device compromises. This document, on the other hand is intended to describe a general secure group messaging infrastructure and its security goals. It provides guidance on building a group messaging system and discusses security and privacy tradeoffs offered by multiple security mechanism that are part of the MLS protocol (ie. frequency of public encryption key rotation). The document also extends the guidance to parts of the infrastructure that are not standardized by the MLS Protocol document and left to the application or the infrastructure architects to design. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, most will vastly influence the overall security guarantees that are achieved by the overall messaging system. This is especially true in case of active adversaries that are able to compromise clients, the delivery service or the authentication service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-mls-architecture-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-architecture-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 4 06:21:42 2021 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 5EF8D3A040F for ; Mon, 4 Oct 2021 06:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 O156jgwxrS2v for ; Mon, 4 Oct 2021 06:21:33 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 B40FF3A0408 for ; Mon, 4 Oct 2021 06:21:33 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id m22so25338897wrb.0 for ; Mon, 04 Oct 2021 06:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cvFhgG3gnW2NkIikc0X51AH5BO9r68yl4q18QTTMlps=; b=fL3bbAgAG/9eMBoUSNbeIFS6ktJP3qFbtUujofOh5/BPPN1KZ82SU0RSCJnAnIANvj Dyq+EVcVQc/aRNlbLo0ahAFL0gZnQK0cpjCgcbVcMt7OJZVKibL4riXodjz3DISYr35N NeWZ5KotTe1jcR3r9hPQDg7bM9mX4bCmnwTDI= 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=cvFhgG3gnW2NkIikc0X51AH5BO9r68yl4q18QTTMlps=; b=yjub2PMc0eo7e4tPzV0m9TDTMHuKo7Na++Ck0gAxQVvbEzvnyEvIfiOzm4LXqYMZkk cD87CnnC7hj5W/xB8k2+i0WBKlRvTVP/HUEQ2RFq1cz+W5yK3eMYHdRMNLqjqBjwnVW8 2NcNZKICtgR4Dc7zYfX/Wp3yL/nELdhvlRX7ZK6juyJbnpYjtq2yrBdDBh67+nVz7U5i LFq8pXLwuZI20uvun3TZWLshRbibgpl8JHRugyfWhuV0p3ftSMxMoH2grsedFzMwDnzz jBlv+ydGEN3DXKv2airAl+4Km6d45zyISf+u7kmzn7MN4TZSI6NHx3CrQGK1yj+gkwgM 0DAA== X-Gm-Message-State: AOAM532/PLOm0fqDaaZHqX0YmpPMBWP/3BTdD2VAs8p2KvS6S5zmoTky V/BZo8yJnagsUKaQSR90aSAlDfy1QNZ+njw6FFbgoTLLRf8= X-Google-Smtp-Source: ABdhPJzVHRs/a0WT1Yxkw+FVTQ82UsFmvqCm1MTV3EN2OwkA2Q5LN3Vp3dasbiUmh4Nv9fiCRq09fcT1RR9x7wPVM8g= X-Received: by 2002:adf:aadc:: with SMTP id i28mr4156486wrc.320.1633353691438; Mon, 04 Oct 2021 06:21:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cridland Date: Mon, 4 Oct 2021 14:21:20 +0100 Message-ID: To: Rohan Mahy Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000924df205cd86cab2" Archived-At: Subject: Re: [MLS] solution to getting in a Commit fairly in a busy group 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, 04 Oct 2021 13:21:39 -0000 --000000000000924df205cd86cab2 Content-Type: text/plain; charset="UTF-8" On Mon, 4 Oct 2021 at 13:28, Rohan Mahy wrote: > The protocol document describes a situation in large groups with frequent > adds and joins where a client (especially over a high latency connection) > may be trying to issue a Commit, but other clients keep getting their > Commits in first. I think this could potentially yield unpredictable > behavior. > Out of curiosity, could a malicious (or at least annoyingly contrary) client issue spurious commits to deliberately cause other clients' commits to fail, forcing them to (for example) continue using existing keying material? Dave. --000000000000924df205cd86cab2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 4 Oct 2021 at 13:28, Rohan Ma= hy <rohan.mahy=3D40wire.com= @dmarc.ietf.org> wrote:
The protocol document describes a situ= ation in large groups with frequent adds and joins where a client (especial= ly over a high latency connection) may be trying to issue a Commit, but oth= er clients keep getting their Commits in first. I think this could potentia= lly yield unpredictable behavior.

Out of curiosity, could a malicious (or at least annoyingly contrary) cl= ient issue spurious commits to deliberately cause other clients' commit= s to fail, forcing them to (for example) continue using existing keying mat= erial?

Dave.
--000000000000924df205cd86cab2-- From nobody Mon Oct 4 06:35:11 2021 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 09E9D3A0486 for ; Mon, 4 Oct 2021 06:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 vXz6liwApD0x for ; Mon, 4 Oct 2021 06:35:02 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 17E043A00E5 for ; Mon, 4 Oct 2021 06:35:02 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id rj12-20020a17090b3e8c00b0019f88e44d85so5644651pjb.4 for ; Mon, 04 Oct 2021 06:35:02 -0700 (PDT) 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=Mmvxaoo15WAq2iJjCirlmGUEiw/0hnZDo3mRW5kV8hY=; b=ZsBBKNr3yY0zh5ayYJRbPw1CN/bFv49f5QER4lkcTLIxajYj2sMWeJu/UGUl47bXRp SutCdAYv1pl2b8hwRGPVKwdCkj99tZmXNzbXYTVECG1JXeBPGLkR0SCcQNC8Rp4FCuLD yS1pQgYgESZK7A56drALr+uU7/7+d2QeIfiUZOLyG16bGGqUYK+u1tKqvy5JnTwOFD/g xBRULF7mHcsgMovMbuCzkiFo/p/L9vxcj/Uk2tpflpiAByky4YEZcVCU8H9lX1uvb0SI OMxdKrNGZzaLVvsgTODSzSoclIvoZAkytnWAIf+3g0KaIFO9SEaD9REvFpegntViGKoq ppRQ== 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=Mmvxaoo15WAq2iJjCirlmGUEiw/0hnZDo3mRW5kV8hY=; b=x2uwxj87nR8oHjjAhJ7e4lJqNVoRH7S4dcbaVmLM6LDE5cVri6edmnpHd7PWvuFnJa 8bmmVfOemGKcInQp0ogcE+JL8CTkUtvOEsdjNZ1w8+5K2rl7ry9/9vNrV6ro3zdV2nPF j7xbHk2UClrGfig+lKx8v+fYwwEgj6vAazuQo8T0iYh4Og9PVGPabUME08cKNuVn3HmH 3tPB5fqErqKkoByY1YML7KIDvWA9mRz6jWnvKbzWAk/uKftjK40AvmsrIoT4H+uGY1lX klyGR5Jv67iiU0WAnrUpUVcV3f727h8R8PAjk2m9Otg6nn6KsMe8UEnZvLyRkke/vNGo OHnA== X-Gm-Message-State: AOAM530k3KqpcMyUlo+/u6XtzJ6aRw7vVTjoWDqsSKFWnPtoQsM5HfHW oVZo5qvu9zXwQNLXNxAwLaKmCS/oIZEeoM8TtYTdjJyvJB5H8A== X-Google-Smtp-Source: ABdhPJwh+CfrofsjF7P//bW0baeMktXxA9GurGECXTJ4AM+I/fX7rSOfpUAzUAKGUJ9z26MuxyKY1GzIF6J4Lm2eQqA= X-Received: by 2002:a17:90a:f0c4:: with SMTP id fa4mr2673457pjb.21.1633354500940; Mon, 04 Oct 2021 06:35:00 -0700 (PDT) MIME-Version: 1.0 From: Rohan Mahy Date: Mon, 4 Oct 2021 06:34:50 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d23dcb05cd86fa92" Archived-At: Subject: [MLS] Restructure of Section 5: Ratchet Trees of mls-protocol 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, 04 Oct 2021 13:35:07 -0000 --000000000000d23dcb05cd86fa92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I'd like to suggest a restructure of Section 5 of the mls-protocol draft on Ratchet Trees. I think it is important even for those who do not implement the ratchet tree themselves but use (for example) an external library, to have a good mental model of their operation. Right now there are a lot of forward references and terms which are mentioned but left undefined or unexplained until much later. There are even some places where we have an apparently contradictory sentence a few paragraphs later. I will send text for these (or a pull request), but I wanted to propose a slightly different order of introducing the key concepts inside the ratchet trees sections. *Basic tree terminology (currently section 5.1)* - Keep the first 5 paragraphs in the same order (start with introducing nodes and leaves and end, up to left-balanced trees) (move direct path and copath forward) - Introduce node and leaf indexes *Add a non-normative explanation "Overview of Ratchet Tree Operations" in a new subsection* - paragraphs 1,2,4,5 from current section 5.3 "Views of a Ratchet Tree" - show examples of removing a node, adding a node, an update, and a commit - explain which keying material is updated, and propagated where, without explaining how yet. - add a few more diagrams *Rewrite "Ratchet tree nodes" (currently section 5.2) and rename it "Ratchet tree data structures"* - explain data structures which are associated with various nodes - explain blank nodes - explain direct paths and copaths - explain unmerged nodes - explain resolution *Remove current Section 5.3* *Current Section 5.4 "Ratchet Tree Evolution" and Section 5.5 "Synchronizing View of the Tree"* How do people feel about this? 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 --000000000000d23dcb05cd86fa92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'd like to suggest = a restructure of Section 5 of the mls-protocol draft on Ratchet Trees. I th= ink it is important even for those who do not implement the ratchet tree th= emselves but use (for example) an external library, to have a good mental m= odel of their operation.

Right now there are a lot= of forward references and terms which are mentioned but left undefined or = unexplained until much later.
There are even some places where we= have an apparently contradictory sentence a few paragraphs later. I will s= end text for these (or a pull request), but I wanted to propose a slightly = different order of introducing the key concepts inside the ratchet trees se= ctions.

Basic tree terminology (currently secti= on 5.1)
- Keep the first 5 paragraphs in the same order (= start with introducing nodes and leaves and end, up to left-balanced trees)=
(move direct path and copath forward)
- Introd= uce node and leaf indexes

Add a non-normative e= xplanation "Overview of Ratchet Tree Operations" in a new subsect= ion
- paragraphs 1,2,4,5 from current section 5.3 "V= iews of a Ratchet Tree"
- show examples of removing a no= de, adding a node, an update, and a commit
- explain which keying= material is updated, and propagated where, without explaining how yet.
- add a few more diagrams

Rewrite "= Ratchet tree nodes" (currently section 5.2) and rename it "Ratche= t tree data structures"
- explain data structures wh= ich are associated with various nodes
- explain blank nodes- explain direct paths and copaths
- explain unmerged nodes- explain resolution

Remove current Sect= ion 5.3

Current Section 5.4 "Ratch= et Tree Evolution" and Section 5.5 "Synchronizing View of the Tre= e"

How do people feel about this?
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 messagi= ng.

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

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

HRB 149847 beim Handelsregister Charlott= enburg, Berlin

VAT-ID DE288748675

--000000000000d23dcb05cd86fa92-- From nobody Mon Oct 4 06:50:42 2021 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 47DAA3A07C1 for ; Mon, 4 Oct 2021 06:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Vbh7x5yhuZus for ; Mon, 4 Oct 2021 06:50:16 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 03D6D3A079D for ; Mon, 4 Oct 2021 06:50:15 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id a16so654007qvm.2 for ; Mon, 04 Oct 2021 06:50:15 -0700 (PDT) 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=0V1HKCFLE+XkSXQ1fTsOCdBYA4VJUWV8SkeQuphC9Ws=; b=UOGbohqxDXTC/ft5awwrFHySS26b/A3umCv46BfifnsyLEwL7OWCy+w3jesPnkQILE 0H2Kr7YglyliaE3cqEFb+RmPuOvEniAQZg9q37+WXbL/nCexD8YMKC3Fs6q+j+o1Q3d/ uJy5NPgIfvgq8unG+WyECyFmty3rrrsTn+NcrhihfFvgldJY4WIqm0q14Qkq911mcB/S yxIikpRItDSwsqV3bcbF0ouyhC6SPWvQTPaDgD9jnRf7YDexrRMQMI2HsLzaReB13Ns6 bYy1q1ElphRMrnMI/MR63KWiaoD22duPx+J4Rfb2buwv+U7VUTQQu5eoeBwdiWJHoVIw K6yQ== 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=0V1HKCFLE+XkSXQ1fTsOCdBYA4VJUWV8SkeQuphC9Ws=; b=Xl2bppbFbYJoCNMMFsj56W5lVb1Xi8+l8jQu9YiLbTIWhrt2t6L29Zk3h8vm699HTQ SZwVNcV3U2nFTXb+dULEXNzW1a9mMSMMys+h3pcRZ5AUXaa/XOqAmaNMXQ6BvoIdpaMv dL5lWv8rAsM5mNrD3QUrImpcmgyk2Umkl2RldW/e83NejpK5INSON4cdCdLpO/eJeW6h p8EBHKBHn04yps10JlvJW6gPRRWV5txaJrDyr0sHOn4giZSV/QVrgixTZJIdFY3ANYqp OzigfI6nn/Dv1wZo38Id9zsPrY4hqRvc0faQiDGLh1ImSv1i6N0uFwBu0QFY36mTaj0D 06XQ== X-Gm-Message-State: AOAM533wop3LrIPTYpSLbaUpmF3aOAiSNCjmK89wKU3fzFDQ4hQwBITW PllxxXweA9nC1vVF9jI3xxXuWDQEeGhwhHlVP84gmw== X-Google-Smtp-Source: ABdhPJzjZK3If5LIqp0CiwMmHoqodH9tJjg6kdbC/dMvufcSYGwVyGK8YMWe5pTx4V8petnLrIaymoEWBeEXGnNqZm0= X-Received: by 2002:a0c:c34e:: with SMTP id j14mr12213810qvi.56.1633355414528; Mon, 04 Oct 2021 06:50:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 4 Oct 2021 09:50:03 -0400 Message-ID: To: Dave Cridland Cc: Rohan Mahy , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000046719b05cd873146" Archived-At: Subject: Re: [MLS] solution to getting in a Commit fairly in a busy group 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, 04 Oct 2021 13:50:31 -0000 --00000000000046719b05cd873146 Content-Type: text/plain; charset="UTF-8" To Dave's question: No, that's not possible, at least not as you describe it. Any Commit causes the key schedule to move forward, so if a malicious client uses their Commits to block others' commits, they would still be ratcheting the key schedule forward. That's not to say that they don't have other objectives that would be accomplished that way, e.g., preventing themselves being evicted by another participant. On the more general question: I don't think this is really a problem for the MLS protocol to solve, but rather a question of DS design / MLS orchestration. As long as you have a centralized DS, it's pretty straightforward to have the DS enforce some notion of fairness. For example, in the Webex implementation, all Commits are generated by one "leader" (with other participants generating only requests to join or leave), which makes them non-rivalrous except for leader transitions. You could also have the DS implement a locking scheme of the type you describe, but there's not really any need to tie that into the crypto protocol. If you were going to do something integrated with MLS, ISTM you would basically want to tunnel some Byzantine fault-tolerant consensus protocol in Proposals (Paxos, Raft, etc.), using some Proposals designed for this purpose. But this would be a pretty complex extension. --RLB On Mon, Oct 4, 2021 at 9:21 AM Dave Cridland wrote: > > > On Mon, 4 Oct 2021 at 13:28, Rohan Mahy 40wire.com@dmarc.ietf.org> wrote: > >> The protocol document describes a situation in large groups with frequent >> adds and joins where a client (especially over a high latency connection) >> may be trying to issue a Commit, but other clients keep getting their >> Commits in first. I think this could potentially yield unpredictable >> behavior. >> > > Out of curiosity, could a malicious (or at least annoyingly contrary) > client issue spurious commits to deliberately cause other clients' commits > to fail, forcing them to (for example) continue using existing keying > material? > > Dave. > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000046719b05cd873146 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To Dave's question: No, that's not possible, = at least not as you describe it.=C2=A0 Any Commit causes the key schedule t= o move forward, so if a malicious client uses their Commits to block others= ' commits, they would still be ratcheting the key schedule forward.=C2= =A0 That's not to say that they don't have other objectives that wo= uld be accomplished that way, e.g., preventing themselves being evicted by = another participant.

On the more general quest= ion: I don't think this is really a problem for the MLS protocol to sol= ve, but rather a question of DS design / MLS orchestration.=C2=A0 As long a= s you have a centralized DS, it's pretty straightforward to have the DS= enforce some notion of fairness.=C2=A0 For example, in the Webex implement= ation, all Commits are generated by one "leader" (with other part= icipants generating only requests to join or leave), which makes them non-r= ivalrous except for leader transitions.=C2=A0 You could also have the DS im= plement a locking scheme of the type you describe, but there's not real= ly any need to tie that into the crypto protocol.

= If you were going to do something integrated with MLS, ISTM you would basic= ally want to tunnel some Byzantine fault-tolerant consensus protocol in Pro= posals (Paxos, Raft, etc.), using some Proposals designed for this purpose.= =C2=A0 But this would be a pretty complex extension.

--RLB

On Mon, Oct 4, 2021 at 9:21 AM Dave Cridland <dave@cridland.net> wrote:
=


On Mon, 4 Oct 2021 at 13:28, Rohan Mahy <rohan.mahy=3D40wire.com@dmarc.= ietf.org> wrote:
The protocol document describes a situation i= n large groups with frequent adds and joins where a client (especially over= a high latency connection) may be trying to issue a Commit, but other clie= nts keep getting their Commits in first. I think this could potentially yie= ld unpredictable behavior.

Out = of curiosity, could a malicious (or at least annoyingly contrary) client is= sue spurious commits to deliberately cause other clients' commits to fa= il, forcing them to (for example) continue using existing keying material?<= /div>

Dave.
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000046719b05cd873146-- From nobody Mon Oct 4 08:58:55 2021 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 2101C3A091F for ; Mon, 4 Oct 2021 08:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 Vc4wMPjCrWfq for ; Mon, 4 Oct 2021 08:58:46 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 522FE3A0918 for ; Mon, 4 Oct 2021 08:58:46 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id m21so16917233pgu.13 for ; Mon, 04 Oct 2021 08:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bnNOGxCUeutc9moVm8sw/mKFSQ7q10YRGe0i86CRJrQ=; b=tVCa05lKQMMt/0xm206GlkDs34r717scbvtoPDRiPtNU+CmVpLI8xln05PmpCrfEg7 /WRUUj/UnNRlRCPXw00JccyFmFftZpXTtz4xwglM/ai/KrrZHsvuQMG0jEGap1xO45Hh gbnG9W/HggDvqsg+V0EMLWpuzhA7ZY9vI5mfpc74W6H9AqBsWKVJ1BBbVhlgR6aq9PaZ f2NfWVhw1Ceqbjj0EwxQnBRBGIYT238BIfQW7xuVXRf72A+ry+Vgq6TP5XAtRZgW6kZJ Neo2QZKvkkUjtSoGzZNWu5WvXpsXOuw3Z0zSr0PfOFkoqa7lBt5W79R6vgQfeavLkjxX fB1w== 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=bnNOGxCUeutc9moVm8sw/mKFSQ7q10YRGe0i86CRJrQ=; b=IU3Mv++fUQc7WYKiTn5KE/mZAeCU4N/HzvqxRJUeM4CD7viA/zxULOPWZY6MLne1z5 uKKSdWayWjw64dSkHA8RqDRieCcAyQQFS1iJ+KtjeO+V+LhHYGBjj2uvK2/AbcNCvwZl iJ2PXt6POjTPpfHPY3zhIoFnSTcIHNlXh3oBkaizDF0+OfG269k6T7hZQ5I7WhEuQ1QL 2Olh5+7Kb+WGCzPq+b26aQ4MYT4JDOuV740qCGfYI/T5dhcVsfrIFDWG99DxbBXsU/y8 w+E6IRBZh+wbCQgy6FegupKuboKw5der1qXogl251QioD8e4AtkyZ+T7rlx51Cct+zQu JjEQ== X-Gm-Message-State: AOAM532e7WQai4K80sFS2Tka9hxEJojcu8oZuFFkBhdl3AYdaoXzKX08 N6eX3eyEK0Y/Yny5n/SHQao/JBil6g5J86/sArvOjRRHIP1w4g== X-Google-Smtp-Source: ABdhPJxCCSCcIhLbjMGJuRJyWmeE6fIqP9vHs3PRu9DJEU6p924XTBCuQ6IzBdN1ndc5EYvQzZCvS0ObXl0abKUCnl0= X-Received: by 2002:a62:5804:0:b0:44b:b75b:ec8f with SMTP id m4-20020a625804000000b0044bb75bec8fmr25387887pfb.63.1633363125013; Mon, 04 Oct 2021 08:58:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rohan Mahy Date: Mon, 4 Oct 2021 08:58:34 -0700 Message-ID: To: Richard Barnes Cc: Dave Cridland , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000db2db105cd88fc16" Archived-At: Subject: Re: [MLS] solution to getting in a Commit fairly in a busy group 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, 04 Oct 2021 15:58:53 -0000 --000000000000db2db105cd88fc16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, > On the more general question: I don't think this is really a problem for > the MLS protocol to solve, but rather a question of DS design / MLS > orchestration. As long as you have a centralized DS, it's pretty > straightforward to have the DS enforce some notion of fairness. For > example, in the Webex implementation, all Commits are generated by one > "leader" (with other participants generating only requests to join or > leave), which makes them non-rivalrous except for leader transitions. Yo= u > could also have the DS implement a locking scheme of the type you describ= e, > but there's not really any need to tie that into the crypto protocol. > The relatively light-weight solution of DS orchestration I proposed, still required a place to put the "commit sequence number" inside MLS so all the clients could see it. To be clear, I think this would be an MLS extension and not part of the core protocol. 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 On Mon, Oct 4, 2021 at 6:50 AM Richard Barnes wrote: > To Dave's question: No, that's not possible, at least not as you describe > it. Any Commit causes the key schedule to move forward, so if a maliciou= s > client uses their Commits to block others' commits, they would still be > ratcheting the key schedule forward. That's not to say that they don't > have other objectives that would be accomplished that way, e.g., preventi= ng > themselves being evicted by another participant. > > On the more general question: I don't think this is really a problem for > the MLS protocol to solve, but rather a question of DS design / MLS > orchestration. As long as you have a centralized DS, it's pretty > straightforward to have the DS enforce some notion of fairness. For > example, in the Webex implementation, all Commits are generated by one > "leader" (with other participants generating only requests to join or > leave), which makes them non-rivalrous except for leader transitions. Yo= u > could also have the DS implement a locking scheme of the type you describ= e, > but there's not really any need to tie that into the crypto protocol. > > If you were going to do something integrated with MLS, ISTM you would > basically want to tunnel some Byzantine fault-tolerant consensus protocol > in Proposals (Paxos, Raft, etc.), using some Proposals designed for this > purpose. But this would be a pretty complex extension. > > --RLB > > On Mon, Oct 4, 2021 at 9:21 AM Dave Cridland wrote: > >> >> >> On Mon, 4 Oct 2021 at 13:28, Rohan Mahy > 40wire.com@dmarc.ietf.org> wrote: >> >>> The protocol document describes a situation in large groups with >>> frequent adds and joins where a client (especially over a high latency >>> connection) may be trying to issue a Commit, but other clients keep get= ting >>> their Commits in first. I think this could potentially yield unpredicta= ble >>> behavior. >>> >> >> Out of curiosity, could a malicious (or at least annoyingly contrary) >> client issue spurious commits to deliberately cause other clients' commi= ts >> to fail, forcing them to (for example) continue using existing keying >> material? >> >> Dave. >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --000000000000db2db105cd88fc16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,
On the more general question: I don't think this is = really a problem for the MLS protocol to solve, but rather a question of DS design / MLS=20 orchestration.=C2=A0 As long as you have a centralized DS, it's pretty= =20 straightforward to have the DS enforce some notion of fairness.=C2=A0 For= =20 example, in the Webex implementation, all Commits are generated by one=20 "leader" (with other participants generating only requests to joi= n or=20 leave), which makes them non-rivalrous except for leader transitions.=C2=A0= =20 You could also have the DS implement a locking scheme of the type you=20 describe, but there's not really any need to tie that into the crypto= =20 protocol.

The relatively light-weight= solution of DS orchestration I proposed, still required a place to put the= "commit sequence number" inside MLS so all the clients could see= it. To be clear, I think this would be an MLS extension and not part of th= e core protocol.

Thanks,
-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



On Mon, Oct 4, 2= 021 at 6:50 AM Richard Barnes <rlb@ipv.sx<= /a>> wrote:
<= div dir=3D"ltr">
To Dave's question: No, that's not possible, a= t least not as you describe it.=C2=A0 Any Commit causes the key schedule to= move forward, so if a malicious client uses their Commits to block others&= #39; commits, they would still be ratcheting the key schedule forward.=C2= =A0 That's not to say that they don't have other objectives that wo= uld be accomplished that way, e.g., preventing themselves being evicted by = another participant.

On the more general quest= ion: I don't think this is really a problem for the MLS protocol to sol= ve, but rather a question of DS design / MLS orchestration.=C2=A0 As long a= s you have a centralized DS, it's pretty straightforward to have the DS= enforce some notion of fairness.=C2=A0 For example, in the Webex implement= ation, all Commits are generated by one "leader" (with other part= icipants generating only requests to join or leave), which makes them non-r= ivalrous except for leader transitions.=C2=A0 You could also have the DS im= plement a locking scheme of the type you describe, but there's not real= ly any need to tie that into the crypto protocol.

= If you were going to do something integrated with MLS, ISTM you would basic= ally want to tunnel some Byzantine fault-tolerant consensus protocol in Pro= posals (Paxos, Raft, etc.), using some Proposals designed for this purpose.= =C2=A0 But this would be a pretty complex extension.

--RLB



On Mon, 4 Oct 2021 at 13:28, Rohan Mahy <= rohan.mahy=3D40wire.com@dmarc.ietf.org> wrote:
The protocol document descr= ibes a situation in large groups with frequent adds and joins where a clien= t (especially over a high latency connection) may be trying to issue a Comm= it, but other clients keep getting their Commits in first. I think this cou= ld potentially yield unpredictable behavior.
<= br>
Out of curiosity, could a malicious (or at least annoyingly c= ontrary) client issue spurious commits to deliberately cause other clients&= #39; commits to fail, forcing them to (for example) continue using existing= keying material?

Dave.
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000db2db105cd88fc16-- From nobody Mon Oct 4 10:22:39 2021 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 2C46D3A0A01 for ; Mon, 4 Oct 2021 10:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 RTUTY3fTu3Pk for ; Mon, 4 Oct 2021 10:22:30 -0700 (PDT) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 684973A0A13 for ; Mon, 4 Oct 2021 10:22:30 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id j10so442722qvl.13 for ; Mon, 04 Oct 2021 10:22:30 -0700 (PDT) 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=oX7OssQKYLTVKn+RUO2s68z73jLQCnSsFqEgJvyZ/r4=; b=KpkAcA/7/QO5V3kzzEwO0NVIoj8gPeddrNdDNJFDpvVnr2UjUHDhnsF6eXGSU7Ua1p M/+Lr7FSOLojIsR6RFfjXjg3x03mUcCq6GUsc7gYMkTVKw97fECWwPK9+O2nbJlvh0/6 PYW1l+JPP0tZhuSOIEhm+BOELIaVAlLwVMEBnVafpAlCNXqsXl0H4mXam6TMmVyAX3PN KbKar9atkjBUFlRR1TJDGrDTXuWzwfIa1OFGuEyc9lbO+QquWg5tMY7iDlLAxTCGxfr3 LmXS8oA/AZSfSXi5WT5HL97jcwQnfCkY5qATeGQ8Rf+r3FuKhaz71l2eeJWnJ8H/Hs63 3ANw== 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=oX7OssQKYLTVKn+RUO2s68z73jLQCnSsFqEgJvyZ/r4=; b=iPJX5u6eZz+ykZCsHbGa+NoTrnuS7cOWeAqiAXGh45h4/5fVMvkMFnCytORUB+Y+Wk ROqEim8eY2IY3Ermh1RJnUvdZi9sKz1Uz7Fdc4ucvUSHisc5CQNHXPYdz60ASAvZhbMO 8aM7g+Ox4vlJMdtHPFAe6161s5GBcxPayXViU2OpzQqcUvgN0mODH5C67Hc2qyD7TMj7 JaTaeObdlnzIbk6qa8OjnryS1lS255bxzBx1g9bFG/JWh5Dk615FlO6F7H1lPaU7+4/w FiD59aMgQvnGZex3cx2I/37V5jDBYbZZ5q+8XNlcktthyMtuvTZeSoskaeX/KsPCfCyN vItQ== X-Gm-Message-State: AOAM531iBWL5gymYX9B7HFIwFwunhatOb7Z8tQQpNll5Kjps7lW22dtD sl1b54cIyw5G8f2WOUulx//mZQOeq0y3yw/aaRXDp/O0jj7mubz/ X-Google-Smtp-Source: ABdhPJw/UJ+DyFnDqNPOb+WlcdWq6pBoFrKbQDnZJBxIFpnpsM9ETWi0EEfqYMlz6TPy7JJ80hGsWC2ut80t2KaDJyA= X-Received: by 2002:a0c:e183:: with SMTP id p3mr22940948qvl.65.1633368148826; Mon, 04 Oct 2021 10:22:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 4 Oct 2021 13:22:17 -0400 Message-ID: To: Rohan Mahy Cc: Dave Cridland , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000004c7eee05cd8a28ed" Archived-At: Subject: Re: [MLS] solution to getting in a Commit fairly in a busy group 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, 04 Oct 2021 17:22:36 -0000 --0000000000004c7eee05cd8a28ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 4, 2021 at 11:58 AM Rohan Mahy wrote: > Hi Richard, > >> On the more general question: I don't think this is really a problem for >> the MLS protocol to solve, but rather a question of DS design / MLS >> orchestration. As long as you have a centralized DS, it's pretty >> straightforward to have the DS enforce some notion of fairness. For >> example, in the Webex implementation, all Commits are generated by one >> "leader" (with other participants generating only requests to join or >> leave), which makes them non-rivalrous except for leader transitions. Y= ou >> could also have the DS implement a locking scheme of the type you descri= be, >> but there's not really any need to tie that into the crypto protocol. >> > > The relatively light-weight solution of DS orchestration I proposed, stil= l > required a place to put the "commit sequence number" inside MLS so all th= e > clients could see it. To be clear, I think this would be an MLS extension > and not part of the core protocol. > What I'm saying is just that you could put the sequence number in whatever framing you're using to send around MLS messages, and not touch the MLS at all. Just to be clear about one aspect of this proposed solution: Consider the case where a client receives CommitB with a higher sequence number, then CommitA shows up. You might think that the client could apply CommitA, then CommitB. That is not necessarily the case -- Commits are ordered because they depend on the state established by the previous commit. If both CommitB and CommitA were generated from the same epoch, they are in conflict; the client would have to throw away CommitB instead of applying it. In general, there are kind of two broad classes of solution here that people tend to come to: 1. Locking: Designating one member is the only authorized committer for some period of time 2. Tie-breakers: Queuing up Commits over some time period, and applying the one that wins according to some tie-breaking function Your proposal is in the "tie-breaker" bucket, with "lowest sequence number" as the tie-breaker. (You could also just do something like "leftmost in the tree" or "smallest u64 derived from H(epoch || leaf index)") Webex is in the "locking" bucket, with the leader holding the lock. The two approaches have kind of complementary sets of trade-offs. --RLB > 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 > > > On Mon, Oct 4, 2021 at 6:50 AM Richard Barnes wrote: > >> To Dave's question: No, that's not possible, at least not as you describ= e >> it. Any Commit causes the key schedule to move forward, so if a malicio= us >> client uses their Commits to block others' commits, they would still be >> ratcheting the key schedule forward. That's not to say that they don't >> have other objectives that would be accomplished that way, e.g., prevent= ing >> themselves being evicted by another participant. >> >> On the more general question: I don't think this is really a problem for >> the MLS protocol to solve, but rather a question of DS design / MLS >> orchestration. As long as you have a centralized DS, it's pretty >> straightforward to have the DS enforce some notion of fairness. For >> example, in the Webex implementation, all Commits are generated by one >> "leader" (with other participants generating only requests to join or >> leave), which makes them non-rivalrous except for leader transitions. Y= ou >> could also have the DS implement a locking scheme of the type you descri= be, >> but there's not really any need to tie that into the crypto protocol. >> >> If you were going to do something integrated with MLS, ISTM you would >> basically want to tunnel some Byzantine fault-tolerant consensus protoco= l >> in Proposals (Paxos, Raft, etc.), using some Proposals designed for this >> purpose. But this would be a pretty complex extension. >> >> --RLB >> >> On Mon, Oct 4, 2021 at 9:21 AM Dave Cridland wrote: >> >>> >>> >>> On Mon, 4 Oct 2021 at 13:28, Rohan Mahy >> 40wire.com@dmarc.ietf.org> wrote: >>> >>>> The protocol document describes a situation in large groups with >>>> frequent adds and joins where a client (especially over a high latency >>>> connection) may be trying to issue a Commit, but other clients keep ge= tting >>>> their Commits in first. I think this could potentially yield unpredict= able >>>> behavior. >>>> >>> >>> Out of curiosity, could a malicious (or at least annoyingly contrary) >>> client issue spurious commits to deliberately cause other clients' comm= its >>> to fail, forcing them to (for example) continue using existing keying >>> material? >>> >>> Dave. >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> --0000000000004c7eee05cd8a28ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 4, 2021 at 11:58 AM Rohan Mah= y <rohan.mahy@wire.com> wr= ote:
Hi Richard,
On the more general question: I don'= t think this is really a problem for the MLS protocol to solve, but rather a question of DS design / MLS=20 orchestration.=C2=A0 As long as you have a centralized DS, it's pretty= =20 straightforward to have the DS enforce some notion of fairness.=C2=A0 For= =20 example, in the Webex implementation, all Commits are generated by one=20 "leader" (with other participants generating only requests to joi= n or=20 leave), which makes them non-rivalrous except for leader transitions.=C2=A0= =20 You could also have the DS implement a locking scheme of the type you=20 describe, but there's not really any need to tie that into the crypto= =20 protocol.

The relatively light-weight= solution of DS orchestration I proposed, still required a place to put the= "commit sequence number" inside MLS so all the clients could see= it. To be clear, I think this would be an MLS extension and not part of th= e core protocol.

What I'm s= aying is just that you could put the sequence number in whatever framing yo= u're using to send around MLS messages, and not touch the MLS at all.

Just to be clear about one aspect of this proposed = solution: Consider the case where a client receives CommitB with a higher s= equence number, then CommitA shows up.=C2=A0 You might think that the clien= t could apply CommitA, then CommitB.=C2=A0 That is not necessarily the case= -- Commits are ordered because they depend on the state established by the= previous commit.=C2=A0 If both CommitB and CommitA were generated from the= same epoch, they are in conflict; the client would have to throw away Comm= itB instead of applying it.

In general, there = are kind of two broad classes of solution here that people tend to come to:=
1. Locking: Designating one member is the only authorized co= mmitter for some period of time
2. Tie-breakers: Queuing up C= ommits over some time period, and applying the one that wins according to s= ome tie-breaking function
=C2=A0
Your proposal is i= n the "tie-breaker" bucket, with "lowest sequence number&quo= t; as the tie-breaker.=C2=A0 (You could also just do something like "l= eftmost in the tree" or "smallest u64 derived from H(epoch || lea= f index)")=C2=A0 Webex is in the "locking" bucket, with the = leader holding the lock.=C2=A0 The two approaches have kind of complementar= y sets of trade-offs.

--RLB

=

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 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

HRB 14984= 7 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675=



On Mon, Oct 4, 2021 at 6= :50 AM Richard Barnes <r= lb@ipv.sx> wrote:
To Dave's question: No, that's not= possible, at least not as you describe it.=C2=A0 Any Commit causes the key= schedule to move forward, so if a malicious client uses their Commits to b= lock others' commits, they would still be ratcheting the key schedule f= orward.=C2=A0 That's not to say that they don't have other objectiv= es that would be accomplished that way, e.g., preventing themselves being e= victed by another participant.

On the more gen= eral question: I don't think this is really a problem for the MLS proto= col to solve, but rather a question of DS design / MLS orchestration.=C2=A0= As long as you have a centralized DS, it's pretty straightforward to h= ave the DS enforce some notion of fairness.=C2=A0 For example, in the Webex= implementation, all Commits are generated by one "leader" (with = other participants generating only requests to join or leave), which makes = them non-rivalrous except for leader transitions.=C2=A0 You could also have= the DS implement a locking scheme of the type you describe, but there'= s not really any need to tie that into the crypto protocol.

<= /div>
If you were going to do something integrated with MLS, ISTM you w= ould basically want to tunnel some Byzantine fault-tolerant consensus proto= col in Proposals (Paxos, Raft, etc.), using some Proposals designed for thi= s purpose.=C2=A0 But this would be a pretty complex extension.

--RLB

On Mon, Oct 4, 2021 at 9:21 AM Dave Cridlan= d <dave@cridland.= net> wrote:


On Mon, 4 Oct 2021 at 13:28, Rohan= Mahy <rohan.mahy=3D40wire.com@dmarc.ietf.org> wrote:
The protocol doc= ument describes a situation in large groups with frequent adds and joins wh= ere a client (especially over a high latency connection) may be trying to i= ssue a Commit, but other clients keep getting their Commits in first. I thi= nk this could potentially yield unpredictable behavior.

Out of curiosity, could a malicious (or at least a= nnoyingly contrary) client issue spurious commits to deliberately cause oth= er clients' commits to fail, forcing them to (for example) continue usi= ng existing keying material?

Dave.
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000004c7eee05cd8a28ed-- From nobody Mon Oct 4 14:22:40 2021 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 8B5C13A09EF for ; Mon, 4 Oct 2021 14:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 I2Cm7wlLq9tN for ; Mon, 4 Oct 2021 14:22:33 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 B81E33A07F7 for ; Mon, 4 Oct 2021 14:22:33 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id c7so17974242qka.2 for ; Mon, 04 Oct 2021 14:22:33 -0700 (PDT) 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=l4iG+/CdCwnwez1LhhbcyNi4PsdB4g4FsXUqUaGBO78=; b=51WGAdJvsCCWM6ZrDYxTJFeEGrT96yN+Ek5gmb40rG5yJHaVGs9xiZ1eTgIM/mw9fh AZIq3OeXhZqn338n4AG1+hC1ffTgFcwwwP+8SFfgOWPIUer9KqYq0A0r2nZ7q63YtoER 1k5lLyQFN3pFGpp8aGYRdSZIW2K1nV+VKlPYRxjXuNEXWHl4in6c/OiYnQWfupa9pWC6 Er7QsUNCXicDd7OE9pRsMH57YgI0et626qxAQyGiOUJCP7ctRO3VVasZeGT/eWRciiC8 Ge4WJtdLg/VjFxicMZhjJQ25M6UydV8WeLutWDpFnBeLg7hrw8S46dTcJXch+wjvLVb7 G0zQ== 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=l4iG+/CdCwnwez1LhhbcyNi4PsdB4g4FsXUqUaGBO78=; b=aUf/NaSnqj+Pl7FskqfOm+2Qvc9zvVxvNiuwOoAY/E1GTgP5kapva3m0Ivq3bG6lvN GaSEtxiWAnJnuSSJom1EtxKwiAsAkAjoDLtBFSuZpSE3ldpK6+d7EJx1rC4P9mo0XitC r3VgJ0ZO2/dLMt0pPudMIy1gxp+Q8mV5tcpHQBWKYsjc9NoSVSsOjFx5zoCfziWLJYod CYwXmeGcLLaXDggdiWUwZqe4NbRUTz5EkB5LkYFO1zOsLdVrQRA0tyYMV9CA/CteP2Q9 00Duhi/zfNjDxcNr6RvIcbX0snRdrm+RpiXA+x+GtGe+9jPCkLRKpTWVv/efEi9ttzqi RGyw== X-Gm-Message-State: AOAM53230ywm0YnyT3sfb0rIQYmBRljKijohr0ikPW92ZR61B9RFWj1M O9pUgtYVKfH891blFTow8OUEXGP+/k+y4BonyH3xKIJM9iA9vw== X-Google-Smtp-Source: ABdhPJzxYMMaeWJaOXKTPHwIXJH/JhSI0dpnmDGAUKIW9exBpuqdAo8Kz1YFexnEvzNizJ3I88NXmgi7BxjzS19akQU= X-Received: by 2002:a37:b403:: with SMTP id d3mr12134819qkf.174.1633382552325; Mon, 04 Oct 2021 14:22:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 4 Oct 2021 17:22:21 -0400 Message-ID: To: Rohan Mahy Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d0600f05cd8d82e6" Archived-At: Subject: Re: [MLS] Restructure of Section 5: Ratchet Trees of mls-protocol 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, 04 Oct 2021 21:22:39 -0000 --000000000000d0600f05cd8d82e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rohan, This restructuring sounds pretty good to me. I'm not surprised that that section is a little grizzled; it's one of the older sections, and has kind of been tweaked as we went along without a coherent rewrite. A PR would be welcome. That said, as we discussed on the interim call today, I would propose that we go ahead and issue WGLC once the technical fixes are in, and handle editorial / clarity stuff like this along with WGLC comments. --RLB On Mon, Oct 4, 2021 at 9:35 AM Rohan Mahy wrote: > Hi, > > I'd like to suggest a restructure of Section 5 of the mls-protocol draft > on Ratchet Trees. I think it is important even for those who do not > implement the ratchet tree themselves but use (for example) an external > library, to have a good mental model of their operation. > > Right now there are a lot of forward references and terms which are > mentioned but left undefined or unexplained until much later. > There are even some places where we have an apparently contradictory > sentence a few paragraphs later. I will send text for these (or a pull > request), but I wanted to propose a slightly different order of introduci= ng > the key concepts inside the ratchet trees sections. > > > *Basic tree terminology (currently section 5.1)* > - Keep the first 5 paragraphs in the same order (start with introducing > nodes and leaves and end, up to left-balanced trees) > (move direct path and copath forward) > - Introduce node and leaf indexes > > > *Add a non-normative explanation "Overview of Ratchet Tree Operations" in > a new subsection* > - paragraphs 1,2,4,5 from current section 5.3 "Views of a Ratchet Tree" > - show examples of removing a node, adding a node, an update, and a commi= t > - explain which keying material is updated, and propagated where, without > explaining how yet. > - add a few more diagrams > > > *Rewrite "Ratchet tree nodes" (currently section 5.2) and rename it > "Ratchet tree data structures"* > - explain data structures which are associated with various nodes > - explain blank nodes > - explain direct paths and copaths > - explain unmerged nodes > - explain resolution > > > *Remove current Section 5.3* > > > *Current Section 5.4 "Ratchet Tree Evolution" and Section 5.5 > "Synchronizing View of the Tree"* > > How do people feel about this? > 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 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d0600f05cd8d82e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rohan,

This restructuring= sounds pretty good to me.=C2=A0 I'm not surprised that that section is= a little grizzled; it's one of the older sections, and has kind of bee= n tweaked as we went along without a coherent rewrite.=C2=A0 A PR would be = welcome.

That said, as we discussed on the interim= call today, I would propose that we go ahead and issue WGLC once the techn= ical fixes are in, and handle editorial / clarity stuff like this along wit= h WGLC comments.

--RLB

On Mon, Oct 4, 202= 1 at 9:35 AM Rohan Mahy <rohan.mahy=3D40wire.com@dmarc.ietf.org> wrote:
Hi,
I'd like to suggest a restructure of Section 5 of the mls-p= rotocol draft on Ratchet Trees. I think it is important even for those who = do not implement the ratchet tree themselves but use (for example) an exter= nal library, to have a good mental model of their operation.

=
Right now there are a lot of forward references and terms which = are mentioned but left undefined or unexplained until much later.
There are even some places where we have an apparently contradictory sente= nce a few paragraphs later. I will send text for these (or a pull request),= but I wanted to propose a slightly different order of introducing the key = concepts inside the ratchet trees sections.

Bas= ic tree terminology (currently section 5.1)
- Keep the fi= rst 5 paragraphs in the same order (start with introducing nodes and leaves= and end, up to left-balanced trees)
(move direct path and co= path forward)
- Introduce node and leaf indexes
Add a non-normative explanation "Overview of Ratchet Tr= ee Operations" in a new subsection
- paragraphs 1,2,= 4,5 from current section 5.3 "Views of a Ratchet Tree"
<= div>- show examples of removing a node, adding a node, an update, and a com= mit
- explain which keying material is updated, and propagated wh= ere, without explaining how yet.
- add a few more diagrams
<= div>
Rewrite "Ratchet tree nodes" (currently sec= tion 5.2) and rename it "Ratchet tree data structures"
- explain data structures which are associated with various nodes
- explain blank nodes
- explain direct paths and copaths<= div>
- explain unmerged nodes
- explain resolution
<= br>
Remove current Section 5.3

Current Section 5.4 "Ratchet Tree Evolution" and Section 5.5= "Synchronizing View of the Tree"

How do people feel about this?
Thanks,
-rohan


Rohan Mah= y=C2=A0 l=C2=A0 Vic= e President Engineering, Architecture

Chat: @rohan_wire on=C2=A0Wire

=C2=A0

Wire=C2=A0- Secure team messag= ing.

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

<= /span>

HRB 149847 beim Handelsregister Cha= rlottenburg, Berlin

VAT-ID DE288748675

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d0600f05cd8d82e6-- From nobody Mon Oct 4 16:07:14 2021 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 E7CA13A0CBA for ; Mon, 4 Oct 2021 16:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 9SCd_hl8Z1lT for ; Mon, 4 Oct 2021 16:07:07 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 C53523A0B6C for ; Mon, 4 Oct 2021 16:07:06 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id x8so10977679qvp.1 for ; Mon, 04 Oct 2021 16:07:06 -0700 (PDT) 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=zMtDDe9hoWPM0B1VCCT4sZiLTUrXDtHiNPueOuwx5WY=; b=xGLMmEat3aurb9OsFh77QVasZ3LML/NgGivwda8ZtRvKmUK/zfoYw9QL1ZXfJB2cF8 XWfQZ2qJKMQdDKYBviFN7rFgQTPXH3zVs0pICNbKM+WZARTvg63BPWTY6ZTa/kasmu1/ ryhtat6xPTUOIQv9YEyfVxq+gtXGg2EYK6zGDclZnWQY2wlB0BU6JIKj4IpuYGd1lkp4 /2uhO8fMAp4Rtsp3gq2P9zUJTY7ZIoTMRCVGPXEs28GzOE02yt5NsKl1T1Q/3YqSMBX+ R1YFB7SoulaGC+i4H4AoGBF0exnVp/en7kw/iiV9Zsv+lCAt5frqbnhRfcANQ7HFXf8M aCCg== 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=zMtDDe9hoWPM0B1VCCT4sZiLTUrXDtHiNPueOuwx5WY=; b=gWlKMyamd0rXmtaZz0SqZQdkgDjkZP2PpRJUnacyHrTqw6dd7D7uTXx6vkd0921wT1 vQxpoNKCioxkFluQn4THvPbcc6JHZxThD8XrmJl+BWkvq57JhkSBuT5rfHOaPY1LSOQ8 eI8nk4hyycM6JPSMde6Nwr/3y8b6y7PN+LXgQF2R2rjslsWNvhpCcQS+CVuWHIwXFz6n BcArVF3Tq6uH54hJDKLphofMtxpG7zkqHzpgwFyX8oiPQBhS2sl8cLHTp1+fFOE/ZdNx XjuoOsn0EaiEwKCmLrTjilnPSCXtTUSBxq2ninFrKu9VJT63riaxL+ePmCVt3F9H4k77 XT6A== X-Gm-Message-State: AOAM531al5Wl1hht+czQ1FybbGZKVp20Zn6dIAmoB/l55jYa6fZR1c9O Nh3oMTcxUYBbzPuX7LZdabEfcAHmDB+YXUmU+H2VPVHkalm5YhRC X-Google-Smtp-Source: ABdhPJztxjiD8oCmN+E0UaiVNLGtjBCb4ln7ustgek+dD7PbuR7v9Jo1WKzkt9rriPsftrpmLm4U55eGPiIUpjXaV5E= X-Received: by 2002:a0c:e345:: with SMTP id a5mr24202948qvm.14.1633388824778; Mon, 04 Oct 2021 16:07:04 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 4 Oct 2021 19:06:53 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000ae69a405cd8ef834" Archived-At: Subject: [MLS] Resync archaeology + analysis + prognosis 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, 04 Oct 2021 23:07:12 -0000 --000000000000ae69a405cd8ef834 Content-Type: text/plain; charset="UTF-8" OK, I think I have traced back some idea of why we removed the earlier resync proposal. Here's a little essay on how we got here, a recap of the trade-offs, and my thoughts on where we should go. tl;dr: Earlier decision not dispositive; we should do basically what's in the PR now. # History The story starts all the way back at the January 2019 interim at Mozilla / Mountain View. There was a discussion there of ACK/NACK and replay as related issues [1]. That discussion seems to have led to agreement that a complete error recovery system was a complex enough topic, and clearly enough separated from the main protocol that it could be handled in a separate specification. As a result, the issues that had been opened for ACK/NACK and resync were closed [2][3]. When Britta and Konrad posted #336 [4] including a resync mechanism, my review simply cited that earlier closed issue as a reason for taking it out [5]. One other note with regard to #336 -- It looks to me like the "resync" mechanism in there was not really fleshed out enough to be implementable. The state linked above was the last state before my review, and the word "resync" doesn't actually appear. Instead the PR talks about "recovering lost group members" using Add and PSK, which could be elaborated to solve a version of this problem, but would require the assistance of a continuing member rather than allowing the lost member to resync unilaterally. It would also have the same issues noted in terms of new joiners not having resync PSKs. Overall, though, reading this history doesn't seem to me like we really made a principled decision not to do resync. We just punted after some discussion in the abstract, and that stuck. We have a more concrete question now. # Analysis Since the discussion of #336 in 2020, we have added external commits in order to have groups you can join unilaterally. So regardless of the broader question of resync, we have to decide what proposals a joiner is allowed to originate in their Commit (sending them by value), in particular, whether an external Commit can contain a joiner-originated Remove proposal. We have a spectrum of options here: 1. Forbid Remove 2. Allow Remove + require the (identity, endpoint_id) and signature key to match the removed node + require resumption PSK 3. Allow Remove + require the (identity, endpoint_id) and signature key to match the removed node 4. Allow Remove without restriction Options (1) and (2) would block an attacker that has compromised a member's signature key from joining as that member and evicting the old appearance. Option (2) because of the PSK; option (1) because of the uniqueness requirements (as Raphael pointed out on the call). Options (1) and (2) do not allow a client who has lost everything but their signature key to resync. Option (1) would require a new endpoint_id and signature key, which might not be feasible in all cases. Option (2) would also need to have extra mechanism to account for recent joiners not having the required resumption PSK. Option (1) would also not allow for resync with just a signature key. As Raphael pointed out, because we now require signature keys to be unique, the member would have to mint a new signature key and get it authenticated, or else their attempt to rejoin would be rejected as a duplicate entry. Options (3) and (4) would allow a client who has lost everything but their signature key to resync, at the risk that an attacker who has compromised a member's signature key could abuse it to join as that member and evict the old, legitimate appearance. # Prognosis After this discussion and analysis, I continue to think that (3) above is the right answer, with an optional upgade to (2). Proceeding by elimination: Option (4), while technically feasible, is clearly a little silly. There's no reason to allow joiners to do a remove in the same operation as they join; they could do this afterward. Option (2) does not seem workable in general because of the recent-joiner problem. While mechanism could be designed to provide the PSK to recent joiners, it would add a lot of complexity, and the recent joiners wouldn't get any benefit from it, which dilutes the value of this mechanism. (It's not impossible to arrive at the case where everyone besides the resync'ing participant is new!) With option (1), you lose any notion of resync; I think the need for endpoint_id rotation makes this unworkable in practice. And it has kind of an odd notion of security: You are protected against an attacker that has compromised a current signature key but can't get a new one authenticated. This is a problem for the authentication system to handle (e.g., with revocation), not for the key exchange -- if you have valid credentials with compromised keys floating around, you have bigger problems to solve. So my personal assessment is that (1) doesn't provide a big jump in security over (3), assuming you have a functioning authentication system. Two side notes about (3): First, if we do (3) but *allow* PSKs, then an application could opt in to (2). Second, this whole mechanism is opt-in for the application, since you can't do an external commit if a PublicGroupState hasn't been published. Concretely, my proposal here would be (3) + (2*) -- Allow Remove with matching parameters, and allow PSKs so that applications can opt in to (2) where they can make it work. That way, if an application opts in to external Commits, they get the benefit of resync and the same signature-key-compromise bound on impersonation for resync as well as net-new joins. And if an application can figure out how to make (2) work, they can require it. Looking forward to others' thoughts here! --RLB [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm [2] https://github.com/mlswg/mls-protocol/issues/92 [3] https://github.com/mlswg/mls-protocol/issues/93 [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202 [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ --000000000000ae69a405cd8ef834 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I think I have traced back some idea of why we re= moved the earlier resync proposal.=C2=A0 Here's a little essay on how w= e got here, a recap of the trade-offs, and my thoughts on where we should g= o.

tl;dr: Earlier decision not dispositive; we sho= uld do basically what's in the PR now.

# History

Th= e story starts all the way back at the January 2019 interim at Mozilla / Mo= untain View.=C2=A0 There was a discussion there of ACK/NACK and replay as r= elated issues [1].=C2=A0 That discussion seems to have led to agreement tha= t a complete error recovery system was a complex enough topic, and clearly = enough separated from the main protocol that it could be handled in a separ= ate specification.=C2=A0 As a result, the issues that had been opened for A= CK/NACK and resync were closed [2][3].=C2=A0 When Britta and Konrad posted = #336 [4] including a resync mechanism, my review simply cited that earlier = closed issue as a reason for taking it out [5].

One other note with = regard to #336 -- It looks to me like the "resync" mechanism in t= here was not really fleshed out enough to be implementable.=C2=A0 The state= linked above was the last state before my review, and the word "resyn= c" doesn't actually appear.=C2=A0 Instead the PR talks about "= ;recovering lost group members" using Add and PSK, which could be elab= orated to solve a version of this problem, but would require the assistance= of a continuing member rather than allowing the lost member to resync unil= aterally.=C2=A0 It would also have the same issues noted in terms of new jo= iners not having resync PSKs.

Overall, though, reading this history = doesn't seem to me like we really made a principled decision not to do = resync.=C2=A0 We just punted after some discussion in the abstract, and tha= t stuck.=C2=A0 We have a more concrete question now.

# Analysis
<= br>Since the discussion of #336 in 2020, we have added external commits in = order to have groups you can join unilaterally.=C2=A0 So regardless of the = broader question of resync, we have to decide what proposals a joiner is al= lowed to originate in their Commit (sending them by value), in particular, = whether an external Commit can contain a joiner-originated Remove proposal.= =C2=A0 We have a spectrum of options here:

1. Forbid Remove
2. A= llow Remove + require the (identity, endpoint_id) and signature key to matc= h the removed node + require resumption PSK
3. Allow Remove + require th= e (identity, endpoint_id) and signature key to match the removed node
4.= Allow Remove without restriction

Options (1) and (2) would block an= attacker that has compromised a member's signature key from joining as= that member and evicting the old appearance.=C2=A0 Option (2) because of t= he PSK; option (1) because of the uniqueness requirements (as Raphael point= ed out on the call).

Options (1) and (2) do not allow a client who h= as lost everything but their signature key to resync.=C2=A0 Option (1) woul= d require a new endpoint_id and signature key, which might not be feasible = in all cases.=C2=A0 Option (2) would also need to have extra mechanism to a= ccount for recent joiners not having the required resumption PSK.

Op= tion (1) would also not allow for resync with just a signature key.=C2=A0 A= s Raphael pointed out, because we now require signature keys to be unique, = the member would have to mint a new signature key and get it authenticated,= or else their attempt to rejoin would be rejected as a duplicate entry.
Options (3) and (4) would allow a client who has lost everything but t= heir signature key to resync, at the risk that an attacker who has compromi= sed a member's signature key could abuse it to join as that member and = evict the old, legitimate appearance.

# Prognosis

After this = discussion and analysis, I continue to think that (3) above is the right an= swer, with an optional upgade to (2).=C2=A0 Proceeding by elimination:
<= br>Option (4), while technically feasible, is clearly a little silly.=C2=A0= There's no reason to allow joiners to do a remove in the same operatio= n as they join; they could do this afterward.

Option (2) does not se= em workable in general because of the recent-joiner problem.=C2=A0 While me= chanism could be designed to provide the PSK to recent joiners, it would ad= d a lot of complexity, and the recent joiners wouldn't get any benefit = from it, which dilutes the value of this mechanism. =C2=A0(It's not imp= ossible to arrive at the case where everyone besides the resync'ing par= ticipant is new!) =C2=A0

With option (1), you lose any notion of res= ync; I think the need for endpoint_id rotation makes this unworkable in pra= ctice.=C2=A0 And it has kind of an odd notion of security: You are protecte= d against an attacker that has compromised a current signature key but can&= #39;t get a new one authenticated.=C2=A0 This is a problem for the authenti= cation system to handle (e.g., with revocation), not for the key exchange -= - if you have valid credentials with compromised keys floating around, you = have bigger problems to solve.=C2=A0 So my personal assessment is that (1) = doesn't provide a big jump in security over (3), assuming you have a fu= nctioning authentication system.

Two side notes about (3): First, if= we do (3) but *allow* PSKs, then an application could opt in to (2).=C2=A0= Second, this whole mechanism is opt-in for the application, since you can&= #39;t do an external commit if a PublicGroupState hasn't been published= .

Concretely, my proposal here would be (3) + (2*) -- Allow Remove w= ith matching parameters, and allow PSKs so that applications can opt in to = (2) where they can make it work.=C2=A0 That way, if an application opts in = to external Commits, they get the benefit of resync and the same signature-= key-compromise bound on impersonation for resync as well as net-new joins.= =C2=A0 And if an application can figure out how to make (2) work, they can = require it.

Looking forward to others' thoughts here!

--R= LB


[1] https://github.com/mlswg/= wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm[2] https://g= ithub.com/mlswg/mls-protocol/issues/92
[3] https://github.com/mlswg/mls-protocol/is= sues/93
[4] https://github.com/mlswg/= mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202[5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiK= u1CFSAE/
--000000000000ae69a405cd8ef834-- From nobody Mon Oct 4 17:42:19 2021 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 B833A3A0D9B for ; Mon, 4 Oct 2021 17:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qciKl2Gs0jFb for ; Mon, 4 Oct 2021 17:42:12 -0700 (PDT) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08on2057.outbound.protection.outlook.com [40.107.101.57]) (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 012E93A0D77 for ; Mon, 4 Oct 2021 17:42:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SXgXvZxyZJZeiQKGeXMH+P6LLbxACfVh7IYES3cFZWxrxQhty7E9dbsZDMYgynGEWS+N4WXTSIMbaN/Eo6CTWwxsQBqgR+HW7owfZp9tPVYJYBfGYB/LXAp7YlYwlAQgZ5Ej39sEQsLTuugydoyTkfCMJSTKzVMrvQd1iuQTb8+rdZhNjXR3EU1QawGy+s4uU+7Bv/B3BCI7h9eVq3tqKCDTvwJJTXM3vRakJ5vviO9awCc8C0f6EMvacvAlnEZkmvSGGi2UEmuqZ4XfrhjUu1FmXydBJZOzEI6u1B+nNIC7Kx17fXOJdvRLjB/sLRYJt5T3dF53G/DVE+Z8YUaVWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=L5iQZfp/SMmf6Qi92lTg+zKsgomFJ61k6qtt61gzW/o=; b=FdOQVHMhTuOvSgRJEdQ2eGtKemL+aWXdFrddXEpT1pGb3nbH7An8DBtu7S1GijLceB4/p8zsijDphbXh9dfIouIwTydJcd1sor9mfwZycFr4Ex7zr3h88FOCcHYCWKqcByBMKhE9Bc2xWyTsX7CSQ82a1/4TYMOm+p+bA6dCYdMAiyGWkDCB49XzInwSw7g/MnOPzZugQ+R2UrLGDerK1gW/Z1xpN/jTj2WAA9uc5bDzWn8OKoU/2LRc1O3vP8eglVYxLKFYtJInRTWMgqOiFR4UODb1qbVKeNHaj7hT+5TLNU3okVV1cf61JK78MK/YSsJ7AmvjAvSo3qC/DgWHew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3348.namprd13.prod.outlook.com (2603:10b6:a03:1aa::23) by BY5PR13MB3272.namprd13.prod.outlook.com (2603:10b6:a03:192::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.15; Tue, 5 Oct 2021 00:42:08 +0000 Received: from BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::d8e0:3c03:4413:3677]) by BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::d8e0:3c03:4413:3677%3]) with mapi id 15.20.4587.017; Tue, 5 Oct 2021 00:42:08 +0000 From: "Hale, Britta (CIV)" To: Richard Barnes , Messaging Layer Security WG CC: Konrad Kohbrok Thread-Topic: [MLS] Resync archaeology + analysis + prognosis Thread-Index: AQHXuXTwvWYe4kyU9EeV1eVric9LDqvDG2QA Date: Tue, 5 Oct 2021 00:42:08 +0000 Message-ID: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=nps.edu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 37d65197-c4bf-4328-0fd3-08d98798f650 x-ms-traffictypediagnostic: BY5PR13MB3272: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pxOD5GfRxqGY4+2UbtXcZ/BGpVt6140JN9a0Vz1okjGF8sY6CwH/FZkghiuVoUW4aliqkPUKe1fAO2emJvrcooCh3oA5M/UsoQOJFf1y1F/B3oteru7OB8ZD+TzByEmLSpGoRI30gBhKf5QQR9xyLXjT6dqmtLVrisdmSh1aom+zm7rn2wA25+syPMKQFkcB1Dy1k69JJhWpJnjNSjaRWgGgIQjnSDTjf8NKh/AFut63b2hjgNcPy1dPXcxVzpwK+uNjWATjbsfbl4D8S0+cn/fVSUHhg7FkgiqJfkXvkda1xSMhgEuBjksw00xf3Bseu5A2q+UmxPze2PwDzOGW3lVP0YBCTYyW4avdHVDwtfit8aK3xtRdt3R4IcCTeBzSbYL8FrYCdjSiIst9jsCLx2r5mj4zuZsiKjwkqQ9OvxTzSqK99A/mAL7qBkhtIFElwnQjaQ3eASa19NdwQcMZEXX623W4CsbOPuK7+lqSxVFiQW1L1P4xwDOX50agYa1fkVWuekIj3pzaaA04BrRRUogxhMvSR/q1t6uWbfG53orkgcCbf0D8hmO6b5ccKSpYVZMikEGzzzarvqChiXG2NShfqYhyKvCViUc8m93xZNN5hxM2j32O98uIzw5aYU+nQdjA+Utl/y48miVCpnh7E3TFyhpiM1X66n8qV8vgoA4cc/c9bF/+CDYbBC4akcS0A0zAliksZWoZZy+4Vhe8h5ODNF+ud8/d/iNVvKf5l2bkWiNJglNvnKc8IFEbm2wGG77PfXlKvHmQAEtMuxm6rQFRUbip/G64GXTyXAMghkTBxh18f0Z9yYUViq5ty7T3pao2/8BvwQF/46k2iwqCmlxWlrcn9AaUVS3eX5ahzzQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3348.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(71200400001)(2906002)(6486002)(66446008)(83380400001)(186003)(64756008)(6512007)(75432002)(36756003)(33656002)(76116006)(8936002)(66946007)(66556008)(122000001)(66476007)(38070700005)(38100700002)(966005)(53546011)(8676002)(4326008)(508600001)(786003)(316002)(6506007)(2616005)(86362001)(166002)(30864003)(110136005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U3NHNzk3MUoyeDhGQjlHZ1N0UXdDeCsxZ2JFWnh1Z3YvVFREZENmZlF0ay9H?= =?utf-8?B?aGtFWFFRQ1BmbUQ4UGMxOXhjWmpUZUErNWxoR2M5NmtRYmkzeGtOMy8xQXZY?= =?utf-8?B?VlR3Q3dWN2c5aklyUTZOMzc2WlNtRVNJR2hnTXpLTExMQkhrUFNjTDFreG0w?= =?utf-8?B?ZE9HaGp6a3F3cjdBNUY3cHo2UWFwM1ZuUzRxM1dxZWc3dEdaSUp2NXUzdWdH?= =?utf-8?B?QXVLK3ZFZ09vNzR4cXdFL1RLbyt5cS9KbXBjWnBNVzRiY3E5NERUQTcxZm82?= =?utf-8?B?bGlvVnRvNFQ5UFhYb2xtUlB4ZGRUWENKbHZGdE1GTzcxaGh0NTlZbFYrOGNM?= =?utf-8?B?TXNhZ2Vrenh0TU53ejBJemdpMlJudStRa2h1TVBHbE1BUDNIcVdwWHo1czRs?= =?utf-8?B?RVhSSVJEeUx3Nkc3cGV1dG9lUXE2Z2wvdXBOaVYzMitjSDVIdnRYemFWdXNT?= =?utf-8?B?MFNIbU5oT0ZXWjFLMDVCM2w0dzlBQnplL1lJM2RGeE9DUjFMTlJIZ1BVR0tk?= =?utf-8?B?bDZ5ZmVMWE9BVVBQRkZtdGNQcG1rMDk3bFkrWTVSdU5hMFZoQUZCSlJrSFRk?= =?utf-8?B?amRlSEVsaEZIc1VPMXlBWWkxMThxMFBIUmVJWGh5YnA4NnFNZmtBZTFiU3RE?= =?utf-8?B?UXBSM1gzOUNJZytxdVJLbjV4WE1RcmFaUnVmRFl5bmh5UmVKTnRMS2Yxcy9B?= =?utf-8?B?aGtTT0p3aUNnam4xV214K0JKRDZUNHlKMWhnMlJBNW5yNGIxU0Fsd0RabHQ5?= =?utf-8?B?bkdWOTBKZlgzajlraGlZcVhsbjUvalcxcmlBWEttZ2U5Nm0ydHMyS3puMVdV?= =?utf-8?B?cFg3WEZqUm5uWTZvTDJyMjNwNEp5MXhGZklCYVNKdDhSL1owZ1JXL2h3MUVs?= =?utf-8?B?dnRDeWFJWDRNM1Q2V1k0dmJpN0MvTkJINUFuaGdTNUUvSHpIOXAySlJhdStS?= =?utf-8?B?akQySlROT1ZTOTE1Y1FWRTl4MS9YY2l5YUhhYjdzSTdGMjZZajBiUGJsb004?= =?utf-8?B?VDFLbnFGV09vdFFiMWk4ZURIcFFUOEJQS2pkMXU1d09ncllId3NpVk94S0tH?= =?utf-8?B?SlV2dFJUYk42UUN5VFRJc1p3YjZwMFJGUkFPUDFLNDNiUWwzSTdmUFo2VlRx?= =?utf-8?B?dzIvYUt1WWZsTk1zZGhGUkpHUHpWdG9EelJnNTFBTExXdm13T3NTenJhd1Ey?= =?utf-8?B?M2hBR3FaRTVBdURnY01xblVkQ3pPZk1sUTEzak9lNzIzUjBYMnhCY1JvbTU1?= =?utf-8?B?ekk0WTFNZDdUZ1NqNUFhTHJFREpiUXZQa3hxcTMzRHJ5R2hITWVUSkNrYTdE?= =?utf-8?B?UWVOZkg3MGp4c0FNYVpROXpNMzZmYTRxekJQMU4yN0xhdGZJZTk1clZVMTdj?= =?utf-8?B?dnlHeWtMTVA2T0RCWnhWT0JaS0h4UFNrT3BTdml3WldNZUJYZGNQME03bHpV?= =?utf-8?B?Mmkvc0prV0VxODFDOTg5a3lLY3hLbnUzRUJqU3JvblFRSDVEV3NIVkx2UWFt?= =?utf-8?B?YkdqSy9VVm1SY1JleEwwS1dQSXUzendCamN5L3hVRVFRenNFNjI1ZkVIVFRm?= =?utf-8?B?b3FBU0g3VWVZT2w1VDVoZlBWNnpDWkwrVjFqREZQSUMyQWM0U2dOeEpwT3F2?= =?utf-8?B?bGRzVHJJOG9nQUlQRW1DMU1uUGFWM3JUa25YZVR5THprOHpjNWVnRWNFWS9I?= =?utf-8?B?SGxmQXNzMytBQ2tpYlJUTlROTk1ocGVBejlEUzg5dE9YZURRaytnYVB0bjZT?= =?utf-8?B?OWE5QTQ5MmJXYVNBM2tMZkNPdVRDTXJVMUtaZ0NYMUtsQXc3U3JJcFdnbVp2?= =?utf-8?B?NjU2UTdkcTBiZUtVMGVkQWFjN25WaXNSQUd6cnB2MDBVQXJRa2oyNE92RExL?= =?utf-8?B?NGpKd09ZWXI4SnNoYWRuaW9aSStkaDE4YlYzNVovWERSOFE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_25D37E5CF7C048C7849E28C8A54762D0npsedu_" MIME-Version: 1.0 X-OriginatorOrg: nps.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37d65197-c4bf-4328-0fd3-08d98798f650 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2021 00:42:08.5257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ADwkxnFGvx4EU6j/SrxSfl9qHrazIteMVKUNvhwfayNWShOHp8TJdOmtApjEYZn0CtuGGQfSecS3HeID9NdvJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3272 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2601:647:cb00:2941:e4b0:5488:3046:6fd8 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: BY5PR13MB3272.namprd13.prod.outlook.com Archived-At: Subject: Re: [MLS] Resync archaeology + analysis + prognosis X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 00:42:18 -0000 --_000_25D37E5CF7C048C7849E28C8A54762D0npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZCwNCg0KW1RMOkRSICgzKSBpcyBub3QgZW50aXJlbHkgZGlzc2ltaWxhciB0byB0aGUg Y3VycmVudCBzZWN1cml0eSBhc3N1bXB0aW9ucywgYnV0IGl0IGlzIGNvbmRpdGlvbmVkIG9uIGVu c3VyaW5nIHRoYXQgb3VyIGN1cnJlbnQgc2lnbmF0dXJlIGhhbmRsaW5nIGRvZXMgbm90IHByZXZl bnQgcm90YXRpbmcgc2lnbmF0dXJlIGtleXMuXQ0KDQoNClRoYW5rIHlvdSBmb3IgdGhlIHN1bW1h cnkgYW5kIGRpZ2dpbmcgdGhyb3VnaCB0aGUgaGlzdG9yeS4gVGhhdCB0YWtlcyB0aW1lISBUaGUg YnJlYWtkb3duIG9mIG9wdGlvbnMgYWxzbyBwcm92aWRlcyBhIGd1aWRpbmcgcG9pbnQgZm9yIHRo ZSBjb252ZXJzYXRpb24uDQoNCllvdXIgaW52ZXN0aWdhdGlvbiBub3RlcyBoYXZlIGpvbHRlZCBt eSBtZW1vcnkgdG8gc29tZSBleHRlbnQsIGF0IGxlYXN0IG9uIHRoZSBzdGF0ZSBvZiAjMzM2IGFu ZCBzb21lIFdHIGRlY2lzaW9ucyBsZWFkaW5nIHVwIHRvIHRoYXQuIFRoZXJlIHdhcyBhbiBpbnRl cmltIGNhbGwgaW4gQXByaWwgb2YgMjAyMCB3aGVyZSBhIHNsaWRlZGVjayB3YXMgcHJlc2VudGVk IHdpdGggdmFyaW91cyBwcm9wb3NhbCB1c2VzOyBkaXNjdXNzaW9uIGFjY29tcGFueWluZyB0aGF0 IHNsaWRlZGVjayBjb3ZlcmVkIHZhcmlvdXMgc2VjdXJpdHkgcHJvcyBhbmQgY29ucyBmb3IgZGlm ZmVyZW50IHVzZXMuIFRoaXMgd2FzIHByZXNlbnRlZCBwcmlvciB0byB0aGUgUFIgc3VibWlzc2lv biB0byBhbGxvdyBmb3IgcG9saXNoaW5nLiDigJxSZWNvdmVyeeKAnSB3YXMgdGhlIHRlcm0gYXBw bGllZCBhdCB0aGF0IHBvaW50IHRvIHJlZmVyIHRvIHdoYXQgaXMgbm93IGJlaW5nIHRlcm1lZCDi gJxyZXN5bmPigJ0uIFRoZXJlIHdhcyBwdXNoIGJhY2sgYXQgdGhhdCBpbnRlcmltIGNhbGwgYWdh aW5zdCByZWNvdmVyeSBhbmQgY29uc2VxdWVudGx5IHRoZSByZWNvdmVyeSBvcHRpb24gd2FzIHJl bW92ZWQgZW50aXJlbHk7IGhlbmNlIHdoeSBpdCBkb2VzIG5vdCBhcHBlYXIgaW4gdGhlIFBSIG1l bnRpb25lZC4NCg0KVW5mb3J0dW5hdGVseSBJIGRvIG5vdCByZWNhbGwgdGhlIHZlcmJhbCByZWFz b25zIGdpdmVuIGZvciB0aGF0IHJlbW92YWwgYW5kIHRoZXkgYXJlIG5vdCBpbiB0aGUgbWludXRl cy4gQEtvbnJhZCBLb2hicm9rPG1haWx0bzprb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPiBh bmQgSSBjYW4gdGFrZSBhIGxvb2sgaW4gdGhlIGdpdCByZXBvIG9uIHRoZSBlZGl0cyBsZWFkaW5n IHVwIHRvIHRoZSBQUiAoYW5kIHRoZXJlZm9yZSB0aGUgZWRpdHMgd2hpY2ggcmVtb3ZlZCByZWNv dmVyeSksIGJ1dCBJIGFtIG5vdCBzdXJlIGhvdyBtdWNoIHRoYXQgd291bGQgZWx1Y2lkYXRlLiBJ dCB3YXMgZGVjaWRlZCBhdCB0aGUgdGltZSB0aGF0IE1MUyBzaG91bGQgc3VwcG9ydCBhIGdyYWNl ZnVsIHJlc3RhcnQgb2YgdGhlIHdob2xlIGdyb3VwLCBidXQgZm9yIG9uZS1vZmYgbWVtYmVyIGRl c3luY2hyb25pemF0aW9uIGl0IHdvdWxkIGJlIHN1ZmZpY2llbnQgdG8gcGVyZm9ybSBhbiBhZGQg d2l0aCBQU0sgcHJvb2YgZnJvbSBhIHByaW9yIHN0YXRlLiBJdCB3YXMgbm90IGRlY2lkZWQgd2hh dCBQU0sgbGlmZXRpbWVzIHdvdWxkIGJlIGNvbnNpZGVyZWQgYWNjZXB0YWJsZSBmb3IgdGhpcy4N Cg0KLS0tDQoNClRvIHRoZSBwcmVzZW50IHByb3Bvc2VkIG9wdGlvbnMsIEkgd2lsbCBub3RlIHRo YXQgdGhlIOKAmG5ldyBqb2luZXJzIGluIGludGVyaW3igJkgY2FzZSBpcyBsaWtlbHkgYSBtaXNs ZWFkaW5nIGZvY3VzIHBvaW50IGZvciB0aGUgZGlzY3Vzc2lvbiwgYW5kIHdlIHNob3VsZCBhdm9p ZCB0cmlwcGluZyBpbnRvIHRoYXQgZGl0Y2ggZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnM6DQoNCiAg KiAgIE5vdGFibHksIGlmIGV2ZXJ5b25lIGV4Y2VwdCBmb3IgdGhlIHJlLXN5bmNpbmcgcGFydGlj aXBhbnQgaXMgbmV3LCB3aHkgbm90IGp1c3QgcmVxdWlyZSB0aGUgcmUtc3luY2luZyBwYXJ0aWNp cGFudCB0byBiZSBhZGRlZCBhcyBhIG5ldyBtZW1iZXIgdGhlbXNlbHZlcz8gSXQgaXMsIGFmdGVy IGFsbCwgcHJhY3RpY2FsbHkgYSBicmFuZCBuZXcgZ3JvdXAgYXQgdGhhdCBwb2ludC4NCiAgKiAg IEl0IGlzIHRydWUgdGhhdCBhIG5ldyBtZW1iZXIgd291bGQgbm90IGdhaW4gZnJvbSBhIFBTSyBn dWFyYW50ZWUsIGJ1dCB3aHkgc2hvdWxkIHdlIHJlZHVjZSB0aGUgZ3VhcmFudGVlcyBmb3IgYWxs IG90aGVyIHBhcnRpY2lwYW50cyB0byB0aGF0IG9mIHRoZSBuZXcgam9pbmVyPyBGcm9tIHRoZSB2 aWV3IG9mIHRoZSBuZXcgam9pbmVyLCBhbGwgcGFydGljaXBhbnRzIGFyZSBuZXcgaW4gYW55IGNh c2UsIHNvIGUuZy4gUENTIGRvZXMgbm90IGhhdmUgc3Vic3RhbnRpYWwgbWVhbmluZyBhcyBvZiB5 ZXQuIEV4aXN0aW5nIG1lbWJlcnMgaGF2ZSBtb3JlIHRvIGxvc2UgYW5kIGFsc28gaGF2ZSB0aGUg bW9yZSB0byBnYWluIGZyb20gUFNLIHVzZS4gSSBkbyBub3QgYmVsaWV2ZSB3ZSB3YW50IHRvIGFk YXB0IGEgc3RhbmNlIG9mIOKAmGlmIHRoZSBuZXcgam9pbmVyIGRvZXNu4oCZdCBnZXQgYSBzZWN1 cml0eSBndWFyYW50ZWUsIG5vIG9uZSBzaG91bGQgaGF2ZSB0aGUgc2VjdXJpdHkgZ3VhcmFudGVl 4oCZIOKAkyBpbiBmYWN0LCB0aGUgdHJlZSBzdHJ1Y3R1cmUsIGNvbW1pdCBoaXN0b3J5LCBhbmQg dGhlIGxpa2UgcHJvdmlkZSBpbnNpZ2h0IHRvIGxvbmdlciB0ZXJtIG1lbWJlcnMgdGhhdCBhIG5l dyBqb2luZXIgZG9lcyBub3QgaGF2ZS4gU28gKDIpIG9mZmVycyBhIG5ldyBqb2luZXIgdGhlIGJl bmVmaXRzIG9mICgzKSBidXQgdG8gYWxsIG90aGVycyBhbiBldmVuIHN0cm9uZ2VyIGd1YXJhbnRl ZS4NCiAgKiAgIEFzIGEgbm9kIHRvIHdoYXQgYSBuZXcgam9pbmVyIG1heSBnYWluLCB3ZSBjYW4g b2ZmZXIgdGhlIGZvbGxvd2luZzogaWYgYSByZS1zeW5jIFBTSyBmYWlscywgdGhlbiB3aGljaGV2 ZXIgZXhpc3RpbmcgbWVtYmVyIGNoZWNrcyBhbmQgbm90ZXMgdGhlIFBTSyBmYWlsdXJlIHNob3Vs ZCBpbml0aWF0ZSBhIHJlbW92YWwgb2YgdGhlIHJlc3luY2luZyBtZW1iZXIuIElmIHRoZXJlIGlz IGEgbmV3IGpvaW5lciwgdGhlbiBieSBjb250aW51ZWQgcHJlc2VuY2Ugb2YgdGhlIHJlLXN5bmNp bmcgbWVtYmVyIHRoZXkgZ2FpbiB0aGUgZ3VhcmFudGVlIHRoYXQgYXQgbGVhc3Qgb25lIG90aGVy IGdyb3VwIG1lbWJlciBoYXMgcHJldmlvdXNseSBzZWVuIHRoYXQgbWVtYmVyLCBvciBlbHNlIHdv dWxkIGhhdmUgZWplY3RlZCB0aGVtIChhc3N1bWluZyB0aGF0IHRoZSBjaGVja2VyIGlzIG9ubGlu ZSkuDQoNCg0KVGhlIHNlY3VyaXR5IGdvYWwgaW4gdGhlIGJhbGFuY2UgaGVyZSBpcyBQQ1MuIEFk ZGluZyBhIHJlLXN5bmMgb3B0aW9uIG9mIGFueSBvZiB0aGUgdmFyaWV0aWVzICgyKS0oNCkgd291 bGQgYnJlYWsgdGhhdCB0byBzb21lIGRlZ3JlZSwgc2luY2UgZm9sbG93aW5nIGEgY29tcHJvbWlz ZSBhbmQgcGFzc2l2ZSBwZXJpb2QgdGhlIGFkdmVyc2FyeSBpcyB0aGVuIGVuYWJsZWQgdG8gcmVn YWluIGEgZm9vdGhvbGQuIFRoZSBxdWVzdGlvbiBpcyBob3cgbXVjaCBvZiBhIGRlZ3JlZSBvZiBs b3NzIGFyZSB3ZSB3aWxsaW5nIHRvIHRvbGVyYXRlLg0KDQogICogICBJIGFncmVlIHRoYXQgKDQp IGlzIGFuIGltbWVkaWF0ZSBkaXNjYXJkLg0KICAqICAgVW5kZXIgKDIpIGEgUFNLIHVzZSwgdGhl IFBTSyB1c2UgYXQgbGVhc3QgbW9yZSBsaW1pdGVkIGR1ZSB0byB0aGUgcHJvb2Ygb2Yga25vd2xl ZGdlIG9mIGEgcGFzdCBzdGF0ZSAoZS5nLiBub3RlcyBhYm92ZSkuIFRoaXMgaXMgYSB3b3J0aHdo aWxlIHByb3BlcnR5IHRvIGVuZm9yY2UgaW4gbXkgdmlldyBzaW5jZSBpdCBiYWxhbmNlcyBhdXRo ZW50aWNhdGlvbiBhY3Jvc3MgdHdvIHZlY3RvcnM6IHRoZSBzaWduYXR1cmUga2V5IGFuZCBrbm93 bGVkZ2Ugb2YgZ3JvdXAgc3RhdGUuIEFkdmVyc2FyeSBhY2Nlc3MgdG8gb25seSBvbmUgb3IgdGhl IG90aGVyIGlzIGluc3VmZmljaWVudCBmb3IgdGhlIGFkdmVyc2FyeSB0byBlamVjdCBBbGljZSBh bmQgcmVwbGFjZSBoZXIgaW4gdGhlIGdyb3VwLg0KICAqICAgVW5kZXIgKDMpLCB0aGUgYXR0YWNr IHNjZW5hcmlvIG9mIEV2ZSBjb21wcm9taXNpbmcgQWxpY2UgKGZ1bGwgc3RhdGUgKyBzaWcga2V5 KSwgZm9sbG93ZWQgZXZlbnR1YWxseSogYnkgcmVtb3ZpbmcgQWxpY2Ugd2hpbGUgYWRkaW5nIGhl cnNlbGYsIGlzIG5vdCBkaXNzaW1pbGFyIGZyb20gdGhlIGF0dGFjayBzY2VuYXJpbyBvZiBFdmUg Y29tcHJvbWlzaW5nIEFsaWNlIGZ1bGwgc3RhdGUgKyBzaWcga2V5KSBmb2xsb3dlZCBldmVudHVh bGx5KiBieSBwcm92aWRpbmcgYW4gaW1wZXJzb25hdGluZyB1cGRhdGUgaW4gQWxpY2XigJlzIG5h bWUuIFdoYXQgaGFzIGJlZW4gc2hvd24gc28gZmFyIGlzIHRoYXQgdGhpcyB0eXBlIG9mIHNjZW5h cmlvIGNhbiBiZSBsaW1pdGVkIGJ5IHJvdGF0aW5nIHNpZ25hdHVyZSBrZXlzLiBBIGltcG9ydGFu dCBwb2ludCB0aGF0IGlzIGRpZmZlcmVudCBpbiB0aGVzZSBzY2VuYXJpb3MgaXMgdGhhdCB1bmRl ciB0aGUgZmlyc3QgQWxpY2Uga25vd3Mgc2hlIHdhcyByZW1vdmVkIChhIHBsdXMpIHdoaWxlIHVu ZGVyIHRoZSBzZWNvbmQgKGN1cnJlbnRseSBwb3NzaWJsZSkgc2NlbmFyaW8gdGhlIGdyb3VwIHNp bXBseSBnb2VzIHNpbGVudCBhbmQgQWxpY2UgZG9lcyBub3Qga25vdyBpZiBpdCB3YXMgbWFsaWNp b3VzIG9yIG5vdC4gQWxsIHNhaWQsIGl0IGNvdWxkIGJlIHdvcnNlLiBUaGF0IGRvZXMgbm90IGNv bnNpZGVyIG90aGVyIGF0dGFjayBzY2VuYXJpb3MgdGhvdWdoLCBmb3IgZXhhbXBsZSB3aGVuIHRo ZSBhdHRhY2tlciBnYWlucyB0aGUgc2lnbmF0dXJlIGtleSBidXQgbm90IHBhc3Qgc3RhdGUvUFNL Lg0KDQoNCg0KKkkuZS4gYWZ0ZXIgYSBwb3RlbnRpYWxseSBwYXNzaXZlIHBlcmlvZCwgaWYgd2Ug YXJlIHRvIHNob3cgaG93IHRoaXMgYmVoYXZlcyBpbiB0aGUgUENTIHNjZW5hcmlvLg0KDQoNClRo aXMgbGVhZHMgdG8gYW4gaW1wb3J0YW50IHF1ZXN0aW9uOiBkb2VzIG91ciBjdXJyZW50IHVuaXF1 ZW5lc3Mgb2Ygc2lnIGtleSBwcmVkaWNhdGUgbGltaXQgdGhlIGFiaWxpdHkgdG8gcm90YXRlIHNp Z25hdHVyZSBrZXlzIHdpdGhpbiBhIGdyb3VwPyBUaGF0IGlzIG91ciBtZWFucyBvZiBsaW1pdGlu ZyB0aGUgZnVsbCBzdGF0ZSArIHNpZyBrZXkgY29tcHJvbWlzZSBzY2VuYXJpbyBpbXBhY3RzIG1l bnRpb25lZCBhYm92ZSwgYW5kIHRoZXJlZm9yZSB0aGUgbWVhbnMgb2YgbGltaXRpbmcgdGhlIGRy YXdiYWNrcyBvZiAoMykuIFdlIHNob3VsZCBtYWtlIHN1cmUgdGhhdCB0aGUgbGltaXRpbmcgYWJp bGl0eSBpcyBmZWFzaWJsZS4gSWYgdGhhdCBoaW5kZXJlZCBpbiBhbnkgd2F5LCB0aGVuIEkgd291 bGQgdm90ZSB2ZXJ5IHN0cm9uZ2x5IGZvciAoMikgYXMgaXQgYXQgbGVhc3QgYm9vdHN0cmFwcyBz b21lIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9wZXJ0aWVzIGZyb20gdGhlIGdyb3VwIHN0YXRl IGluIHRoZSBzY2VuYXJpbyB0aGF0IHRoZSBzaWcga2V5IGlzIGNvbXByb21pc2VkLg0KDQoNCkFs bCB0aGUgYmVzdCwNCg0KQnJpdHRhDQoNCg0KDQpGcm9tOiBNTFMgPG1scy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+DQpEYXRlOiBNb25k YXksIE9jdG9iZXIgNCwgMjAyMSBhdCA0OjA5IFBNDQpUbzogTWVzc2FnaW5nIExheWVyIFNlY3Vy aXR5IFdHIDxtbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTUxTXSBSZXN5bmMgYXJjaGFlb2xvZ3kg KyBhbmFseXNpcyArIHByb2dub3Npcw0KDQpPSywgSSB0aGluayBJIGhhdmUgdHJhY2VkIGJhY2sg c29tZSBpZGVhIG9mIHdoeSB3ZSByZW1vdmVkIHRoZSBlYXJsaWVyIHJlc3luYyBwcm9wb3NhbC4g IEhlcmUncyBhIGxpdHRsZSBlc3NheSBvbiBob3cgd2UgZ290IGhlcmUsIGEgcmVjYXAgb2YgdGhl IHRyYWRlLW9mZnMsIGFuZCBteSB0aG91Z2h0cyBvbiB3aGVyZSB3ZSBzaG91bGQgZ28uDQoNCnRs O2RyOiBFYXJsaWVyIGRlY2lzaW9uIG5vdCBkaXNwb3NpdGl2ZTsgd2Ugc2hvdWxkIGRvIGJhc2lj YWxseSB3aGF0J3MgaW4gdGhlIFBSIG5vdy4NCg0KIyBIaXN0b3J5DQoNClRoZSBzdG9yeSBzdGFy dHMgYWxsIHRoZSB3YXkgYmFjayBhdCB0aGUgSmFudWFyeSAyMDE5IGludGVyaW0gYXQgTW96aWxs YSAvIE1vdW50YWluIFZpZXcuICBUaGVyZSB3YXMgYSBkaXNjdXNzaW9uIHRoZXJlIG9mIEFDSy9O QUNLIGFuZCByZXBsYXkgYXMgcmVsYXRlZCBpc3N1ZXMgWzFdLiAgVGhhdCBkaXNjdXNzaW9uIHNl ZW1zIHRvIGhhdmUgbGVkIHRvIGFncmVlbWVudCB0aGF0IGEgY29tcGxldGUgZXJyb3IgcmVjb3Zl cnkgc3lzdGVtIHdhcyBhIGNvbXBsZXggZW5vdWdoIHRvcGljLCBhbmQgY2xlYXJseSBlbm91Z2gg c2VwYXJhdGVkIGZyb20gdGhlIG1haW4gcHJvdG9jb2wgdGhhdCBpdCBjb3VsZCBiZSBoYW5kbGVk IGluIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbi4gIEFzIGEgcmVzdWx0LCB0aGUgaXNzdWVzIHRo YXQgaGFkIGJlZW4gb3BlbmVkIGZvciBBQ0svTkFDSyBhbmQgcmVzeW5jIHdlcmUgY2xvc2VkIFsy XVszXS4gIFdoZW4gQnJpdHRhIGFuZCBLb25yYWQgcG9zdGVkICMzMzYgWzRdIGluY2x1ZGluZyBh IHJlc3luYyBtZWNoYW5pc20sIG15IHJldmlldyBzaW1wbHkgY2l0ZWQgdGhhdCBlYXJsaWVyIGNs b3NlZCBpc3N1ZSBhcyBhIHJlYXNvbiBmb3IgdGFraW5nIGl0IG91dCBbNV0uDQoNCk9uZSBvdGhl ciBub3RlIHdpdGggcmVnYXJkIHRvICMzMzYgLS0gSXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgInJl c3luYyIgbWVjaGFuaXNtIGluIHRoZXJlIHdhcyBub3QgcmVhbGx5IGZsZXNoZWQgb3V0IGVub3Vn aCB0byBiZSBpbXBsZW1lbnRhYmxlLiAgVGhlIHN0YXRlIGxpbmtlZCBhYm92ZSB3YXMgdGhlIGxh c3Qgc3RhdGUgYmVmb3JlIG15IHJldmlldywgYW5kIHRoZSB3b3JkICJyZXN5bmMiIGRvZXNuJ3Qg YWN0dWFsbHkgYXBwZWFyLiAgSW5zdGVhZCB0aGUgUFIgdGFsa3MgYWJvdXQgInJlY292ZXJpbmcg bG9zdCBncm91cCBtZW1iZXJzIiB1c2luZyBBZGQgYW5kIFBTSywgd2hpY2ggY291bGQgYmUgZWxh Ym9yYXRlZCB0byBzb2x2ZSBhIHZlcnNpb24gb2YgdGhpcyBwcm9ibGVtLCBidXQgd291bGQgcmVx dWlyZSB0aGUgYXNzaXN0YW5jZSBvZiBhIGNvbnRpbnVpbmcgbWVtYmVyIHJhdGhlciB0aGFuIGFs bG93aW5nIHRoZSBsb3N0IG1lbWJlciB0byByZXN5bmMgdW5pbGF0ZXJhbGx5LiAgSXQgd291bGQg YWxzbyBoYXZlIHRoZSBzYW1lIGlzc3VlcyBub3RlZCBpbiB0ZXJtcyBvZiBuZXcgam9pbmVycyBu b3QgaGF2aW5nIHJlc3luYyBQU0tzLg0KDQpPdmVyYWxsLCB0aG91Z2gsIHJlYWRpbmcgdGhpcyBo aXN0b3J5IGRvZXNuJ3Qgc2VlbSB0byBtZSBsaWtlIHdlIHJlYWxseSBtYWRlIGEgcHJpbmNpcGxl ZCBkZWNpc2lvbiBub3QgdG8gZG8gcmVzeW5jLiAgV2UganVzdCBwdW50ZWQgYWZ0ZXIgc29tZSBk aXNjdXNzaW9uIGluIHRoZSBhYnN0cmFjdCwgYW5kIHRoYXQgc3R1Y2suICBXZSBoYXZlIGEgbW9y ZSBjb25jcmV0ZSBxdWVzdGlvbiBub3cuDQoNCiMgQW5hbHlzaXMNCg0KU2luY2UgdGhlIGRpc2N1 c3Npb24gb2YgIzMzNiBpbiAyMDIwLCB3ZSBoYXZlIGFkZGVkIGV4dGVybmFsIGNvbW1pdHMgaW4g b3JkZXIgdG8gaGF2ZSBncm91cHMgeW91IGNhbiBqb2luIHVuaWxhdGVyYWxseS4gIFNvIHJlZ2Fy ZGxlc3Mgb2YgdGhlIGJyb2FkZXIgcXVlc3Rpb24gb2YgcmVzeW5jLCB3ZSBoYXZlIHRvIGRlY2lk ZSB3aGF0IHByb3Bvc2FscyBhIGpvaW5lciBpcyBhbGxvd2VkIHRvIG9yaWdpbmF0ZSBpbiB0aGVp ciBDb21taXQgKHNlbmRpbmcgdGhlbSBieSB2YWx1ZSksIGluIHBhcnRpY3VsYXIsIHdoZXRoZXIg YW4gZXh0ZXJuYWwgQ29tbWl0IGNhbiBjb250YWluIGEgam9pbmVyLW9yaWdpbmF0ZWQgUmVtb3Zl IHByb3Bvc2FsLiAgV2UgaGF2ZSBhIHNwZWN0cnVtIG9mIG9wdGlvbnMgaGVyZToNCg0KMS4gRm9y YmlkIFJlbW92ZQ0KMi4gQWxsb3cgUmVtb3ZlICsgcmVxdWlyZSB0aGUgKGlkZW50aXR5LCBlbmRw b2ludF9pZCkgYW5kIHNpZ25hdHVyZSBrZXkgdG8gbWF0Y2ggdGhlIHJlbW92ZWQgbm9kZSArIHJl cXVpcmUgcmVzdW1wdGlvbiBQU0sNCjMuIEFsbG93IFJlbW92ZSArIHJlcXVpcmUgdGhlIChpZGVu dGl0eSwgZW5kcG9pbnRfaWQpIGFuZCBzaWduYXR1cmUga2V5IHRvIG1hdGNoIHRoZSByZW1vdmVk IG5vZGUNCjQuIEFsbG93IFJlbW92ZSB3aXRob3V0IHJlc3RyaWN0aW9uDQoNCk9wdGlvbnMgKDEp IGFuZCAoMikgd291bGQgYmxvY2sgYW4gYXR0YWNrZXIgdGhhdCBoYXMgY29tcHJvbWlzZWQgYSBt ZW1iZXIncyBzaWduYXR1cmUga2V5IGZyb20gam9pbmluZyBhcyB0aGF0IG1lbWJlciBhbmQgZXZp Y3RpbmcgdGhlIG9sZCBhcHBlYXJhbmNlLiAgT3B0aW9uICgyKSBiZWNhdXNlIG9mIHRoZSBQU0s7 IG9wdGlvbiAoMSkgYmVjYXVzZSBvZiB0aGUgdW5pcXVlbmVzcyByZXF1aXJlbWVudHMgKGFzIFJh cGhhZWwgcG9pbnRlZCBvdXQgb24gdGhlIGNhbGwpLg0KDQpPcHRpb25zICgxKSBhbmQgKDIpIGRv IG5vdCBhbGxvdyBhIGNsaWVudCB3aG8gaGFzIGxvc3QgZXZlcnl0aGluZyBidXQgdGhlaXIgc2ln bmF0dXJlIGtleSB0byByZXN5bmMuICBPcHRpb24gKDEpIHdvdWxkIHJlcXVpcmUgYSBuZXcgZW5k cG9pbnRfaWQgYW5kIHNpZ25hdHVyZSBrZXksIHdoaWNoIG1pZ2h0IG5vdCBiZSBmZWFzaWJsZSBp biBhbGwgY2FzZXMuICBPcHRpb24gKDIpIHdvdWxkIGFsc28gbmVlZCB0byBoYXZlIGV4dHJhIG1l Y2hhbmlzbSB0byBhY2NvdW50IGZvciByZWNlbnQgam9pbmVycyBub3QgaGF2aW5nIHRoZSByZXF1 aXJlZCByZXN1bXB0aW9uIFBTSy4NCg0KT3B0aW9uICgxKSB3b3VsZCBhbHNvIG5vdCBhbGxvdyBm b3IgcmVzeW5jIHdpdGgganVzdCBhIHNpZ25hdHVyZSBrZXkuICBBcyBSYXBoYWVsIHBvaW50ZWQg b3V0LCBiZWNhdXNlIHdlIG5vdyByZXF1aXJlIHNpZ25hdHVyZSBrZXlzIHRvIGJlIHVuaXF1ZSwg dGhlIG1lbWJlciB3b3VsZCBoYXZlIHRvIG1pbnQgYSBuZXcgc2lnbmF0dXJlIGtleSBhbmQgZ2V0 IGl0IGF1dGhlbnRpY2F0ZWQsIG9yIGVsc2UgdGhlaXIgYXR0ZW1wdCB0byByZWpvaW4gd291bGQg YmUgcmVqZWN0ZWQgYXMgYSBkdXBsaWNhdGUgZW50cnkuDQoNCk9wdGlvbnMgKDMpIGFuZCAoNCkg d291bGQgYWxsb3cgYSBjbGllbnQgd2hvIGhhcyBsb3N0IGV2ZXJ5dGhpbmcgYnV0IHRoZWlyIHNp Z25hdHVyZSBrZXkgdG8gcmVzeW5jLCBhdCB0aGUgcmlzayB0aGF0IGFuIGF0dGFja2VyIHdobyBo YXMgY29tcHJvbWlzZWQgYSBtZW1iZXIncyBzaWduYXR1cmUga2V5IGNvdWxkIGFidXNlIGl0IHRv IGpvaW4gYXMgdGhhdCBtZW1iZXIgYW5kIGV2aWN0IHRoZSBvbGQsIGxlZ2l0aW1hdGUgYXBwZWFy YW5jZS4NCg0KIyBQcm9nbm9zaXMNCg0KQWZ0ZXIgdGhpcyBkaXNjdXNzaW9uIGFuZCBhbmFseXNp cywgSSBjb250aW51ZSB0byB0aGluayB0aGF0ICgzKSBhYm92ZSBpcyB0aGUgcmlnaHQgYW5zd2Vy LCB3aXRoIGFuIG9wdGlvbmFsIHVwZ2FkZSB0byAoMikuICBQcm9jZWVkaW5nIGJ5IGVsaW1pbmF0 aW9uOg0KDQpPcHRpb24gKDQpLCB3aGlsZSB0ZWNobmljYWxseSBmZWFzaWJsZSwgaXMgY2xlYXJs eSBhIGxpdHRsZSBzaWxseS4gIFRoZXJlJ3Mgbm8gcmVhc29uIHRvIGFsbG93IGpvaW5lcnMgdG8g ZG8gYSByZW1vdmUgaW4gdGhlIHNhbWUgb3BlcmF0aW9uIGFzIHRoZXkgam9pbjsgdGhleSBjb3Vs ZCBkbyB0aGlzIGFmdGVyd2FyZC4NCg0KT3B0aW9uICgyKSBkb2VzIG5vdCBzZWVtIHdvcmthYmxl IGluIGdlbmVyYWwgYmVjYXVzZSBvZiB0aGUgcmVjZW50LWpvaW5lciBwcm9ibGVtLiAgV2hpbGUg bWVjaGFuaXNtIGNvdWxkIGJlIGRlc2lnbmVkIHRvIHByb3ZpZGUgdGhlIFBTSyB0byByZWNlbnQg am9pbmVycywgaXQgd291bGQgYWRkIGEgbG90IG9mIGNvbXBsZXhpdHksIGFuZCB0aGUgcmVjZW50 IGpvaW5lcnMgd291bGRuJ3QgZ2V0IGFueSBiZW5lZml0IGZyb20gaXQsIHdoaWNoIGRpbHV0ZXMg dGhlIHZhbHVlIG9mIHRoaXMgbWVjaGFuaXNtLiAgKEl0J3Mgbm90IGltcG9zc2libGUgdG8gYXJy aXZlIGF0IHRoZSBjYXNlIHdoZXJlIGV2ZXJ5b25lIGJlc2lkZXMgdGhlIHJlc3luYydpbmcgcGFy dGljaXBhbnQgaXMgbmV3ISkNCg0KV2l0aCBvcHRpb24gKDEpLCB5b3UgbG9zZSBhbnkgbm90aW9u IG9mIHJlc3luYzsgSSB0aGluayB0aGUgbmVlZCBmb3IgZW5kcG9pbnRfaWQgcm90YXRpb24gbWFr ZXMgdGhpcyB1bndvcmthYmxlIGluIHByYWN0aWNlLiAgQW5kIGl0IGhhcyBraW5kIG9mIGFuIG9k ZCBub3Rpb24gb2Ygc2VjdXJpdHk6IFlvdSBhcmUgcHJvdGVjdGVkIGFnYWluc3QgYW4gYXR0YWNr ZXIgdGhhdCBoYXMgY29tcHJvbWlzZWQgYSBjdXJyZW50IHNpZ25hdHVyZSBrZXkgYnV0IGNhbid0 IGdldCBhIG5ldyBvbmUgYXV0aGVudGljYXRlZC4gIFRoaXMgaXMgYSBwcm9ibGVtIGZvciB0aGUg YXV0aGVudGljYXRpb24gc3lzdGVtIHRvIGhhbmRsZSAoZS5nLiwgd2l0aCByZXZvY2F0aW9uKSwg bm90IGZvciB0aGUga2V5IGV4Y2hhbmdlIC0tIGlmIHlvdSBoYXZlIHZhbGlkIGNyZWRlbnRpYWxz IHdpdGggY29tcHJvbWlzZWQga2V5cyBmbG9hdGluZyBhcm91bmQsIHlvdSBoYXZlIGJpZ2dlciBw cm9ibGVtcyB0byBzb2x2ZS4gIFNvIG15IHBlcnNvbmFsIGFzc2Vzc21lbnQgaXMgdGhhdCAoMSkg ZG9lc24ndCBwcm92aWRlIGEgYmlnIGp1bXAgaW4gc2VjdXJpdHkgb3ZlciAoMyksIGFzc3VtaW5n IHlvdSBoYXZlIGEgZnVuY3Rpb25pbmcgYXV0aGVudGljYXRpb24gc3lzdGVtLg0KDQpUd28gc2lk ZSBub3RlcyBhYm91dCAoMyk6IEZpcnN0LCBpZiB3ZSBkbyAoMykgYnV0ICphbGxvdyogUFNLcywg dGhlbiBhbiBhcHBsaWNhdGlvbiBjb3VsZCBvcHQgaW4gdG8gKDIpLiAgU2Vjb25kLCB0aGlzIHdo b2xlIG1lY2hhbmlzbSBpcyBvcHQtaW4gZm9yIHRoZSBhcHBsaWNhdGlvbiwgc2luY2UgeW91IGNh bid0IGRvIGFuIGV4dGVybmFsIGNvbW1pdCBpZiBhIFB1YmxpY0dyb3VwU3RhdGUgaGFzbid0IGJl ZW4gcHVibGlzaGVkLg0KDQpDb25jcmV0ZWx5LCBteSBwcm9wb3NhbCBoZXJlIHdvdWxkIGJlICgz KSArICgyKikgLS0gQWxsb3cgUmVtb3ZlIHdpdGggbWF0Y2hpbmcgcGFyYW1ldGVycywgYW5kIGFs bG93IFBTS3Mgc28gdGhhdCBhcHBsaWNhdGlvbnMgY2FuIG9wdCBpbiB0byAoMikgd2hlcmUgdGhl eSBjYW4gbWFrZSBpdCB3b3JrLiAgVGhhdCB3YXksIGlmIGFuIGFwcGxpY2F0aW9uIG9wdHMgaW4g dG8gZXh0ZXJuYWwgQ29tbWl0cywgdGhleSBnZXQgdGhlIGJlbmVmaXQgb2YgcmVzeW5jIGFuZCB0 aGUgc2FtZSBzaWduYXR1cmUta2V5LWNvbXByb21pc2UgYm91bmQgb24gaW1wZXJzb25hdGlvbiBm b3IgcmVzeW5jIGFzIHdlbGwgYXMgbmV0LW5ldyBqb2lucy4gIEFuZCBpZiBhbiBhcHBsaWNhdGlv biBjYW4gZmlndXJlIG91dCBob3cgdG8gbWFrZSAoMikgd29yaywgdGhleSBjYW4gcmVxdWlyZSBp dC4NCg0KTG9va2luZyBmb3J3YXJkIHRvIG90aGVycycgdGhvdWdodHMgaGVyZSENCg0KLS1STEIN Cg0KDQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL3dnLW1hdGVyaWFscy9ibG9iL21haW4v aW50ZXJpbS0yMDE5LTAxL21pbnV0ZXMubWQjYWNrcy1hbmQtbmFja3Mtam9ubTxodHRwczovL25h bTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZn aXRodWIuY29tJTJGbWxzd2clMkZ3Zy1tYXRlcmlhbHMlMkZibG9iJTJGbWFpbiUyRmludGVyaW0t MjAxOS0wMSUyRm1pbnV0ZXMubWQlMjNhY2tzLWFuZC1uYWNrcy1qb25tJmRhdGE9MDQlN0MwMSU3 Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzFlYmY5NmMzMGNjNDRmYzk2ZTFkMDhkOTg3OGJiNmI1 JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY4OTg1Nzkz MTg0NDgwOCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPSUy QkVwclFNT1ZrJTJCSU5oZHRSeEhMNUpmR1ElMkZlUDZ0Q0Z2Y0FNM3VvcE1GcTQlM0QmcmVzZXJ2 ZWQ9MD4NClsyXSBodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL2lzc3Vlcy85 MjxodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wlMkZpc3N1ZXMlMkY5 MiZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MxZWJmOTZjMzBjYzQ0ZmM5 NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3 QzAlN0M2Mzc2ODk4NTc5MzE4NTQ4MDAlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lN QzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNE JTdDMzAwMCZzZGF0YT1sRmVZd3lIQ0dabHNIeiUyQk8yY1ZQRzdlVVRVanpvTGh6UTBmbml6JTJG YmxtYyUzRCZyZXNlcnZlZD0wPg0KWzNdIGh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJv dG9jb2wvaXNzdWVzLzkzPGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2Nv bCUyRmlzc3VlcyUyRjkzJmRhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzFl YmY5NmMzMGNjNDRmYzk2ZTFkMDhkOTg3OGJiNmI1JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3 ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY4OTg1NzkzMTg1NDgwMCU3Q1Vua25vd24lN0NUV0ZwYkda c2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dp TENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPXpwVyUyQkNReiUyQmVFd2tsWWJwNE5RbUZjVWVI QkdtQWgwaktCUkMwNUN5VkJzJTNEJnJlc2VydmVkPTA+DQpbNF0gaHR0cHM6Ly9naXRodWIuY29t L21sc3dnL21scy1wcm90b2NvbC9wdWxsLzMzNi9maWxlcy8yMDE0NWU0OWFjY2UwMWRjZWRjYTdk YjJkMDVjNTc5MDhhMjkyMjAyPGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90 b2NvbCUyRnB1bGwlMkYzMzYlMkZmaWxlcyUyRjIwMTQ1ZTQ5YWNjZTAxZGNlZGNhN2RiMmQwNWM1 NzkwOGEyOTIyMDImZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMWViZjk2 YzMwY2M0NGZjOTZlMWQwOGQ5ODc4YmI2YjUlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYz Mzc4ZSU3QzAlN0MwJTdDNjM3Njg5ODU3OTMxODY0Nzk0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNk OGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pY VkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9ME9nVmRkYyUyQkl6anU2MU13ZlFGTmlZamVqWklOdHJJ cWYwOENrSWdHbSUyQlElM0QmcmVzZXJ2ZWQ9MD4NCls1XSBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL21scy9Ic19uQVgzbHVEamlRNG1Jd2tpS3UxQ0ZTQUUvPGh0dHBzOi8v bmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rm1haWxhcmNoaXZlLmlldGYub3JnJTJGYXJjaCUyRm1zZyUyRm1scyUyRkhzX25BWDNsdURqaVE0 bUl3a2lLdTFDRlNBRSUyRiZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0Mx ZWJmOTZjMzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1 Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NzQ3ODklN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT1tb1VBWkozdE9BaEZJJTJCTU1GcTk5QjExMXdK cHhCUkJ3YlJQWXM1bER4QzAlM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_25D37E5CF7C048C7849E28C8A54762D0npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <81D1ADAA8FF2334085D88B1CF974481A@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MTg3NTY0ODg7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjcyMTczMzI1MCAt NTc4MTE4MzQyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt c3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTExOTQ0ODg1ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTU1OTE1NjAgLTEyMTYzMjUzMjggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmljaGFyZCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1RM OkRSICgzKSBpcyBub3QgZW50aXJlbHkgZGlzc2ltaWxhciB0byB0aGUgY3VycmVudCBzZWN1cml0 eSBhc3N1bXB0aW9ucywgYnV0IGl0IGlzIGNvbmRpdGlvbmVkIG9uIGVuc3VyaW5nIHRoYXQgb3Vy IGN1cnJlbnQgc2lnbmF0dXJlIGhhbmRsaW5nIGRvZXMgbm90IHByZXZlbnQgcm90YXRpbmcgc2ln bmF0dXJlIGtleXMuXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBmb3IgdGhlIHN1bW1hcnkgYW5kIGRp Z2dpbmcgdGhyb3VnaCB0aGUgaGlzdG9yeS4gVGhhdCB0YWtlcyB0aW1lISBUaGUgYnJlYWtkb3du IG9mIG9wdGlvbnMgYWxzbyBwcm92aWRlcyBhIGd1aWRpbmcgcG9pbnQgZm9yIHRoZSBjb252ZXJz YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXIgaW52ZXN0aWdhdGlvbiBub3RlcyBo YXZlIGpvbHRlZCBteSBtZW1vcnkgdG8gc29tZSBleHRlbnQsIGF0IGxlYXN0IG9uIHRoZSBzdGF0 ZSBvZiAjMzM2IGFuZCBzb21lIFdHIGRlY2lzaW9ucyBsZWFkaW5nIHVwIHRvIHRoYXQuIFRoZXJl IHdhcyBhbiBpbnRlcmltIGNhbGwgaW4gQXByaWwgb2YgMjAyMCB3aGVyZSBhIHNsaWRlZGVjayB3 YXMgcHJlc2VudGVkIHdpdGggdmFyaW91cyBwcm9wb3NhbCB1c2VzOw0KIGRpc2N1c3Npb24gYWNj b21wYW55aW5nIHRoYXQgc2xpZGVkZWNrIGNvdmVyZWQgdmFyaW91cyBzZWN1cml0eSBwcm9zIGFu ZCBjb25zIGZvciBkaWZmZXJlbnQgdXNlcy4gVGhpcyB3YXMgcHJlc2VudGVkIHByaW9yIHRvIHRo ZSBQUiBzdWJtaXNzaW9uIHRvIGFsbG93IGZvciBwb2xpc2hpbmcuIOKAnFJlY292ZXJ54oCdIHdh cyB0aGUgdGVybSBhcHBsaWVkIGF0IHRoYXQgcG9pbnQgdG8gcmVmZXIgdG8gd2hhdCBpcyBub3cg YmVpbmcgdGVybWVkIOKAnHJlc3luY+KAnS4NCiBUaGVyZSB3YXMgcHVzaCBiYWNrIGF0IHRoYXQg aW50ZXJpbSBjYWxsIGFnYWluc3QgcmVjb3ZlcnkgYW5kIGNvbnNlcXVlbnRseSB0aGUgcmVjb3Zl cnkgb3B0aW9uIHdhcyByZW1vdmVkIGVudGlyZWx5OyBoZW5jZSB3aHkgaXQgZG9lcyBub3QgYXBw ZWFyIGluIHRoZSBQUiBtZW50aW9uZWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5mb3J0 dW5hdGVseSBJIGRvIG5vdCByZWNhbGwgdGhlIHZlcmJhbCByZWFzb25zIGdpdmVuIGZvciB0aGF0 IHJlbW92YWwgYW5kIHRoZXkgYXJlIG5vdCBpbiB0aGUgbWludXRlcy4NCjxhIGlkPSJPV0FBTUQz RTAxRjFDOTMyMTIxNDBBMjA4MTZDMjhDRjYxMzg3IiBocmVmPSJtYWlsdG86a29ucmFkLmtvaGJy b2tAZGF0YXNocmluZS5kZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO3RleHQtZGVjb3JhdGlvbjpub25lIj5AS29ucmFkIEtvaGJyb2s8 L3NwYW4+PC9hPiBhbmQgSSBjYW4gdGFrZSBhIGxvb2sgaW4gdGhlIGdpdCByZXBvIG9uIHRoZSBl ZGl0cyBsZWFkaW5nIHVwIHRvIHRoZSBQUiAoYW5kIHRoZXJlZm9yZSB0aGUgZWRpdHMgd2hpY2gg cmVtb3ZlZCByZWNvdmVyeSksIGJ1dCBJIGFtIG5vdCBzdXJlIGhvdyBtdWNoIHRoYXQgd291bGQg ZWx1Y2lkYXRlLg0KIEl0IHdhcyBkZWNpZGVkIGF0IHRoZSB0aW1lIHRoYXQgTUxTIHNob3VsZCBz dXBwb3J0IGEgZ3JhY2VmdWwgcmVzdGFydCBvZiB0aGUgd2hvbGUgZ3JvdXAsIGJ1dCBmb3Igb25l LW9mZiBtZW1iZXIgZGVzeW5jaHJvbml6YXRpb24gaXQgd291bGQgYmUgc3VmZmljaWVudCB0byBw ZXJmb3JtIGFuIGFkZCB3aXRoIFBTSyBwcm9vZiBmcm9tIGEgcHJpb3Igc3RhdGUuIEl0IHdhcyBu b3QgZGVjaWRlZCB3aGF0IFBTSyBsaWZldGltZXMgd291bGQgYmUgY29uc2lkZXJlZA0KIGFjY2Vw dGFibGUgZm9yIHRoaXMuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VG8gdGhlIHByZXNlbnQgcHJvcG9zZWQgb3B0aW9ucywgSSB3aWxsIG5vdGUg dGhhdCB0aGUg4oCYbmV3IGpvaW5lcnMgaW4gaW50ZXJpbeKAmSBjYXNlIGlzIGxpa2VseSBhIG1p c2xlYWRpbmcgZm9jdXMgcG9pbnQgZm9yIHRoZSBkaXNjdXNzaW9uLCBhbmQgd2Ugc2hvdWxkIGF2 b2lkIHRyaXBwaW5nIGludG8gdGhhdCBkaXRjaCBmb3IgYSBudW1iZXIgb2YgcmVhc29uczoNCjxv OnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPk5vdGFibHksIGlmIGV2ZXJ5b25lIGV4Y2VwdCBmb3IgdGhlIHJl LXN5bmNpbmcgcGFydGljaXBhbnQgaXMgbmV3LCB3aHkgbm90IGp1c3QgcmVxdWlyZSB0aGUgcmUt c3luY2luZyBwYXJ0aWNpcGFudCB0byBiZSBhZGRlZCBhcyBhIG5ldyBtZW1iZXIgdGhlbXNlbHZl cz8gSXQgaXMsIGFmdGVyIGFsbCwgcHJhY3RpY2FsbHkNCiBhIGJyYW5kIG5ldyBncm91cCBhdCB0 aGF0IHBvaW50LiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5JdCBpcyB0cnVl IHRoYXQgYSBuZXcgbWVtYmVyIHdvdWxkIG5vdCBnYWluIGZyb20gYSBQU0sgZ3VhcmFudGVlLCBi dXQgd2h5IHNob3VsZCB3ZSByZWR1Y2UgdGhlIGd1YXJhbnRlZXMgZm9yIGFsbCBvdGhlciBwYXJ0 aWNpcGFudHMgdG8gdGhhdCBvZiB0aGUgbmV3IGpvaW5lcj8gRnJvbSB0aGUgdmlldyBvZiB0aGUN CiBuZXcgam9pbmVyLCBhbGwgcGFydGljaXBhbnRzIGFyZSBuZXcgaW4gYW55IGNhc2UsIHNvIGUu Zy4gUENTIGRvZXMgbm90IGhhdmUgc3Vic3RhbnRpYWwgbWVhbmluZyBhcyBvZiB5ZXQuIEV4aXN0 aW5nIG1lbWJlcnMgaGF2ZSBtb3JlIHRvIGxvc2UgYW5kIGFsc28gaGF2ZSB0aGUgbW9yZSB0byBn YWluIGZyb20gUFNLIHVzZS4gSSBkbyBub3QgYmVsaWV2ZSB3ZSB3YW50IHRvIGFkYXB0IGEgc3Rh bmNlIG9mIOKAmGlmIHRoZSBuZXcgam9pbmVyIGRvZXNu4oCZdA0KIGdldCBhIHNlY3VyaXR5IGd1 YXJhbnRlZSwgbm8gb25lIHNob3VsZCBoYXZlIHRoZSBzZWN1cml0eSBndWFyYW50ZWXigJkg4oCT IGluIGZhY3QsIHRoZSB0cmVlIHN0cnVjdHVyZSwgY29tbWl0IGhpc3RvcnksIGFuZCB0aGUgbGlr ZSBwcm92aWRlIGluc2lnaHQgdG8gbG9uZ2VyIHRlcm0gbWVtYmVycyB0aGF0IGEgbmV3IGpvaW5l ciBkb2VzIG5vdCBoYXZlLiBTbyAoMikgb2ZmZXJzIGEgbmV3IGpvaW5lciB0aGUgYmVuZWZpdHMg b2YgKDMpIGJ1dCB0byBhbGwNCiBvdGhlcnMgYW4gZXZlbiBzdHJvbmdlciBndWFyYW50ZWUuIDxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPkFzIGEgbm9kIHRvIHdoYXQgYSBuZXcg am9pbmVyIG1heSBnYWluLCB3ZSBjYW4gb2ZmZXIgdGhlIGZvbGxvd2luZzogaWYgYSByZS1zeW5j IFBTSyBmYWlscywgdGhlbiB3aGljaGV2ZXIgZXhpc3RpbmcgbWVtYmVyIGNoZWNrcyBhbmQgbm90 ZXMgdGhlIFBTSyBmYWlsdXJlIHNob3VsZCBpbml0aWF0ZSBhIHJlbW92YWwNCiBvZiB0aGUgcmVz eW5jaW5nIG1lbWJlci4gSWYgdGhlcmUgaXMgYSBuZXcgam9pbmVyLCB0aGVuIGJ5IGNvbnRpbnVl ZCBwcmVzZW5jZSBvZiB0aGUgcmUtc3luY2luZyBtZW1iZXIgdGhleSBnYWluIHRoZSBndWFyYW50 ZWUgdGhhdCBhdCBsZWFzdCBvbmUgb3RoZXIgZ3JvdXAgbWVtYmVyIGhhcyBwcmV2aW91c2x5IHNl ZW4gdGhhdCBtZW1iZXIsIG9yIGVsc2Ugd291bGQgaGF2ZSBlamVjdGVkIHRoZW0gKGFzc3VtaW5n IHRoYXQgdGhlIGNoZWNrZXINCiBpcyBvbmxpbmUpLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzZWN1 cml0eSBnb2FsIGluIHRoZSBiYWxhbmNlIGhlcmUgaXMgUENTLiBBZGRpbmcgYSByZS1zeW5jIG9w dGlvbiBvZiBhbnkgb2YgdGhlIHZhcmlldGllcyAoMiktKDQpIHdvdWxkIGJyZWFrIHRoYXQgdG8g c29tZSBkZWdyZWUsIHNpbmNlIGZvbGxvd2luZyBhIGNvbXByb21pc2UgYW5kIHBhc3NpdmUgcGVy aW9kIHRoZSBhZHZlcnNhcnkgaXMgdGhlbiBlbmFibGVkIHRvIHJlZ2FpbiBhIGZvb3Rob2xkLiBU aGUNCiBxdWVzdGlvbiBpcyBob3cgbXVjaCBvZiBhIGRlZ3JlZSBvZiBsb3NzIGFyZSB3ZSB3aWxs aW5nIHRvIHRvbGVyYXRlLiA8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5JIGFncmVlIHRoYXQgKDQpIGlz IGFuIGltbWVkaWF0ZSBkaXNjYXJkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi PlVuZGVyICgyKSBhIFBTSyB1c2UsIHRoZSBQU0sgdXNlIGF0IGxlYXN0IG1vcmUgbGltaXRlZCBk dWUgdG8gdGhlIHByb29mIG9mIGtub3dsZWRnZSBvZiBhIHBhc3Qgc3RhdGUgKGUuZy4gbm90ZXMg YWJvdmUpLiBUaGlzIGlzIGEgd29ydGh3aGlsZSBwcm9wZXJ0eSB0byBlbmZvcmNlIGluIG15IHZp ZXcgc2luY2UgaXQNCiBiYWxhbmNlcyBhdXRoZW50aWNhdGlvbiBhY3Jvc3MgdHdvIHZlY3RvcnM6 IHRoZSBzaWduYXR1cmUga2V5IGFuZCBrbm93bGVkZ2Ugb2YgZ3JvdXAgc3RhdGUuIEFkdmVyc2Fy eSBhY2Nlc3MgdG8gb25seSBvbmUgb3IgdGhlIG90aGVyIGlzIGluc3VmZmljaWVudCBmb3IgdGhl IGFkdmVyc2FyeSB0byBlamVjdCBBbGljZSBhbmQgcmVwbGFjZSBoZXIgaW4gdGhlIGdyb3VwLg0K PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+VW5kZXIgKDMpLCB0aGUgYXR0YWNr IHNjZW5hcmlvIG9mIEV2ZSBjb21wcm9taXNpbmcgQWxpY2UgKGZ1bGwgc3RhdGUgKyBzaWcga2V5 KSwgZm9sbG93ZWQgZXZlbnR1YWxseSogYnkgcmVtb3ZpbmcgQWxpY2Ugd2hpbGUgYWRkaW5nIGhl cnNlbGYsIGlzIG5vdCBkaXNzaW1pbGFyIGZyb20gdGhlIGF0dGFjayBzY2VuYXJpbw0KIG9mIEV2 ZSBjb21wcm9taXNpbmcgQWxpY2UgZnVsbCBzdGF0ZSArIHNpZyBrZXkpIGZvbGxvd2VkIGV2ZW50 dWFsbHkqIGJ5IHByb3ZpZGluZyBhbiBpbXBlcnNvbmF0aW5nIHVwZGF0ZSBpbiBBbGljZeKAmXMg bmFtZS4gV2hhdCBoYXMgYmVlbiBzaG93biBzbyBmYXIgaXMgdGhhdCB0aGlzIHR5cGUgb2Ygc2Nl bmFyaW8gY2FuIGJlIGxpbWl0ZWQgYnkgcm90YXRpbmcgc2lnbmF0dXJlIGtleXMuIEEgaW1wb3J0 YW50IHBvaW50IHRoYXQgaXMgZGlmZmVyZW50DQogaW4gdGhlc2Ugc2NlbmFyaW9zIGlzIHRoYXQg dW5kZXIgdGhlIGZpcnN0IEFsaWNlIGtub3dzIHNoZSB3YXMgcmVtb3ZlZCAoYSBwbHVzKSB3aGls ZSB1bmRlciB0aGUgc2Vjb25kIChjdXJyZW50bHkgcG9zc2libGUpIHNjZW5hcmlvIHRoZSBncm91 cCBzaW1wbHkgZ29lcyBzaWxlbnQgYW5kIEFsaWNlIGRvZXMgbm90IGtub3cgaWYgaXQgd2FzIG1h bGljaW91cyBvciBub3QuIEFsbCBzYWlkLCBpdCBjb3VsZCBiZSB3b3JzZS4gVGhhdCBkb2VzIG5v dA0KIGNvbnNpZGVyIG90aGVyIGF0dGFjayBzY2VuYXJpb3MgdGhvdWdoLCBmb3IgZXhhbXBsZSB3 aGVuIHRoZSBhdHRhY2tlciBnYWlucyB0aGUgc2lnbmF0dXJlIGtleSBidXQgbm90IHBhc3Qgc3Rh dGUvUFNLLg0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+Kkku ZS4gYWZ0ZXIgYSBwb3RlbnRpYWxseSBwYXNzaXZlIHBlcmlvZCwgaWYgd2UgYXJlIHRvIHNob3cg aG93IHRoaXMgYmVoYXZlcyBpbiB0aGUgUENTIHNjZW5hcmlvLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBsZWFkcyB0byBhbiBpbXBvcnRhbnQgcXVlc3Rpb246IGRvZXMgb3Vy IGN1cnJlbnQgdW5pcXVlbmVzcyBvZiBzaWcga2V5IHByZWRpY2F0ZSBsaW1pdCB0aGUgYWJpbGl0 eSB0byByb3RhdGUgc2lnbmF0dXJlIGtleXMgd2l0aGluIGEgZ3JvdXA/IFRoYXQgaXMgb3VyIG1l YW5zIG9mIGxpbWl0aW5nIHRoZSBmdWxsIHN0YXRlICsgc2lnIGtleSBjb21wcm9taXNlIHNjZW5h cmlvIGltcGFjdHMgbWVudGlvbmVkDQogYWJvdmUsIGFuZCB0aGVyZWZvcmUgdGhlIG1lYW5zIG9m IGxpbWl0aW5nIHRoZSBkcmF3YmFja3Mgb2YgKDMpLiBXZSBzaG91bGQgbWFrZSBzdXJlIHRoYXQg dGhlIGxpbWl0aW5nIGFiaWxpdHkgaXMgZmVhc2libGUuIElmIHRoYXQgaGluZGVyZWQgaW4gYW55 IHdheSwgdGhlbiBJIHdvdWxkIHZvdGUgdmVyeSBzdHJvbmdseSBmb3IgKDIpIGFzIGl0IGF0IGxl YXN0IGJvb3RzdHJhcHMgc29tZSBvZiB0aGUgYXV0aGVudGljYXRpb24gcHJvcGVydGllcw0KIGZy b20gdGhlIGdyb3VwIHN0YXRlIGluIHRoZSBzY2VuYXJpbyB0aGF0IHRoZSBzaWcga2V5IGlzIGNv bXByb21pc2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCB0aGUgYmVzdCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QnJpdHRhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+TUxTICZsdDttbHMtYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIFJpY2hhcmQgQmFybmVzICZsdDtybGJAaXB2LnN4Jmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5Nb25kYXksIE9jdG9iZXIgNCwgMjAyMSBhdCA0OjA5IFBNPGJyPg0KPGI+VG86 IDwvYj5NZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgV0cgJmx0O21sc0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+W01MU10gUmVzeW5jIGFyY2hhZW9sb2d5ICsgYW5hbHlzaXMgKyBw cm9nbm9zaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T0ssIEkgdGhpbmsgSSBoYXZlIHRyYWNlZCBiYWNrIHNvbWUgaWRlYSBvZiB3 aHkgd2UgcmVtb3ZlZCB0aGUgZWFybGllciByZXN5bmMgcHJvcG9zYWwuJm5ic3A7IEhlcmUncyBh IGxpdHRsZSBlc3NheSBvbiBob3cgd2UgZ290IGhlcmUsIGEgcmVjYXAgb2YgdGhlIHRyYWRlLW9m ZnMsIGFuZCBteSB0aG91Z2h0cyBvbiB3aGVyZSB3ZSBzaG91bGQgZ28uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRsO2RyOiBFYXJsaWVyIGRl Y2lzaW9uIG5vdCBkaXNwb3NpdGl2ZTsgd2Ugc2hvdWxkIGRvIGJhc2ljYWxseSB3aGF0J3MgaW4g dGhlIFBSIG5vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KIyBIaXN0b3J5PGJyPg0KPGJyPg0KVGhlIHN0b3J5IHN0YXJ0cyBhbGwgdGhlIHdheSBi YWNrIGF0IHRoZSBKYW51YXJ5IDIwMTkgaW50ZXJpbSBhdCBNb3ppbGxhIC8gTW91bnRhaW4gVmll dy4mbmJzcDsgVGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiB0aGVyZSBvZiBBQ0svTkFDSyBhbmQgcmVw bGF5IGFzIHJlbGF0ZWQgaXNzdWVzIFsxXS4mbmJzcDsgVGhhdCBkaXNjdXNzaW9uIHNlZW1zIHRv IGhhdmUgbGVkIHRvIGFncmVlbWVudCB0aGF0IGEgY29tcGxldGUgZXJyb3IgcmVjb3Zlcnkgc3lz dGVtIHdhcyBhDQogY29tcGxleCBlbm91Z2ggdG9waWMsIGFuZCBjbGVhcmx5IGVub3VnaCBzZXBh cmF0ZWQgZnJvbSB0aGUgbWFpbiBwcm90b2NvbCB0aGF0IGl0IGNvdWxkIGJlIGhhbmRsZWQgaW4g YSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBBcyBhIHJlc3VsdCwgdGhlIGlzc3VlcyB0 aGF0IGhhZCBiZWVuIG9wZW5lZCBmb3IgQUNLL05BQ0sgYW5kIHJlc3luYyB3ZXJlIGNsb3NlZCBb Ml1bM10uJm5ic3A7IFdoZW4gQnJpdHRhIGFuZCBLb25yYWQgcG9zdGVkICMzMzYgWzRdDQogaW5j bHVkaW5nIGEgcmVzeW5jIG1lY2hhbmlzbSwgbXkgcmV2aWV3IHNpbXBseSBjaXRlZCB0aGF0IGVh cmxpZXIgY2xvc2VkIGlzc3VlIGFzIGEgcmVhc29uIGZvciB0YWtpbmcgaXQgb3V0IFs1XS48YnI+ DQo8YnI+DQpPbmUgb3RoZXIgbm90ZSB3aXRoIHJlZ2FyZCB0byAjMzM2IC0tIEl0IGxvb2tzIHRv IG1lIGxpa2UgdGhlICZxdW90O3Jlc3luYyZxdW90OyBtZWNoYW5pc20gaW4gdGhlcmUgd2FzIG5v dCByZWFsbHkgZmxlc2hlZCBvdXQgZW5vdWdoIHRvIGJlIGltcGxlbWVudGFibGUuJm5ic3A7IFRo ZSBzdGF0ZSBsaW5rZWQgYWJvdmUgd2FzIHRoZSBsYXN0IHN0YXRlIGJlZm9yZSBteSByZXZpZXcs IGFuZCB0aGUgd29yZCAmcXVvdDtyZXN5bmMmcXVvdDsgZG9lc24ndCBhY3R1YWxseSBhcHBlYXIu Jm5ic3A7IEluc3RlYWQNCiB0aGUgUFIgdGFsa3MgYWJvdXQgJnF1b3Q7cmVjb3ZlcmluZyBsb3N0 IGdyb3VwIG1lbWJlcnMmcXVvdDsgdXNpbmcgQWRkIGFuZCBQU0ssIHdoaWNoIGNvdWxkIGJlIGVs YWJvcmF0ZWQgdG8gc29sdmUgYSB2ZXJzaW9uIG9mIHRoaXMgcHJvYmxlbSwgYnV0IHdvdWxkIHJl cXVpcmUgdGhlIGFzc2lzdGFuY2Ugb2YgYSBjb250aW51aW5nIG1lbWJlciByYXRoZXIgdGhhbiBh bGxvd2luZyB0aGUgbG9zdCBtZW1iZXIgdG8gcmVzeW5jIHVuaWxhdGVyYWxseS4mbmJzcDsgSXQg d291bGQNCiBhbHNvIGhhdmUgdGhlIHNhbWUgaXNzdWVzIG5vdGVkIGluIHRlcm1zIG9mIG5ldyBq b2luZXJzIG5vdCBoYXZpbmcgcmVzeW5jIFBTS3MuPGJyPg0KPGJyPg0KT3ZlcmFsbCwgdGhvdWdo LCByZWFkaW5nIHRoaXMgaGlzdG9yeSBkb2Vzbid0IHNlZW0gdG8gbWUgbGlrZSB3ZSByZWFsbHkg bWFkZSBhIHByaW5jaXBsZWQgZGVjaXNpb24gbm90IHRvIGRvIHJlc3luYy4mbmJzcDsgV2UganVz dCBwdW50ZWQgYWZ0ZXIgc29tZSBkaXNjdXNzaW9uIGluIHRoZSBhYnN0cmFjdCwgYW5kIHRoYXQg c3R1Y2suJm5ic3A7IFdlIGhhdmUgYSBtb3JlIGNvbmNyZXRlIHF1ZXN0aW9uIG5vdy48YnI+DQo8 YnI+DQojIEFuYWx5c2lzPGJyPg0KPGJyPg0KU2luY2UgdGhlIGRpc2N1c3Npb24gb2YgIzMzNiBp biAyMDIwLCB3ZSBoYXZlIGFkZGVkIGV4dGVybmFsIGNvbW1pdHMgaW4gb3JkZXIgdG8gaGF2ZSBn cm91cHMgeW91IGNhbiBqb2luIHVuaWxhdGVyYWxseS4mbmJzcDsgU28gcmVnYXJkbGVzcyBvZiB0 aGUgYnJvYWRlciBxdWVzdGlvbiBvZiByZXN5bmMsIHdlIGhhdmUgdG8gZGVjaWRlIHdoYXQgcHJv cG9zYWxzIGEgam9pbmVyIGlzIGFsbG93ZWQgdG8gb3JpZ2luYXRlIGluIHRoZWlyIENvbW1pdCAo c2VuZGluZw0KIHRoZW0gYnkgdmFsdWUpLCBpbiBwYXJ0aWN1bGFyLCB3aGV0aGVyIGFuIGV4dGVy bmFsIENvbW1pdCBjYW4gY29udGFpbiBhIGpvaW5lci1vcmlnaW5hdGVkIFJlbW92ZSBwcm9wb3Nh bC4mbmJzcDsgV2UgaGF2ZSBhIHNwZWN0cnVtIG9mIG9wdGlvbnMgaGVyZTo8YnI+DQo8YnI+DQox LiBGb3JiaWQgUmVtb3ZlIDxicj4NCjIuIEFsbG93IFJlbW92ZSArIHJlcXVpcmUgdGhlIChpZGVu dGl0eSwgZW5kcG9pbnRfaWQpIGFuZCBzaWduYXR1cmUga2V5IHRvIG1hdGNoIHRoZSByZW1vdmVk IG5vZGUgKyByZXF1aXJlIHJlc3VtcHRpb24gUFNLPGJyPg0KMy4gQWxsb3cgUmVtb3ZlICsgcmVx dWlyZSB0aGUgKGlkZW50aXR5LCBlbmRwb2ludF9pZCkgYW5kIHNpZ25hdHVyZSBrZXkgdG8gbWF0 Y2ggdGhlIHJlbW92ZWQgbm9kZTxicj4NCjQuIEFsbG93IFJlbW92ZSB3aXRob3V0IHJlc3RyaWN0 aW9uPGJyPg0KPGJyPg0KT3B0aW9ucyAoMSkgYW5kICgyKSB3b3VsZCBibG9jayBhbiBhdHRhY2tl ciB0aGF0IGhhcyBjb21wcm9taXNlZCBhIG1lbWJlcidzIHNpZ25hdHVyZSBrZXkgZnJvbSBqb2lu aW5nIGFzIHRoYXQgbWVtYmVyIGFuZCBldmljdGluZyB0aGUgb2xkIGFwcGVhcmFuY2UuJm5ic3A7 IE9wdGlvbiAoMikgYmVjYXVzZSBvZiB0aGUgUFNLOyBvcHRpb24gKDEpIGJlY2F1c2Ugb2YgdGhl IHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnRzIChhcyBSYXBoYWVsIHBvaW50ZWQgb3V0DQogb24gdGhl IGNhbGwpLjxicj4NCjxicj4NCk9wdGlvbnMgKDEpIGFuZCAoMikgZG8gbm90IGFsbG93IGEgY2xp ZW50IHdobyBoYXMgbG9zdCBldmVyeXRoaW5nIGJ1dCB0aGVpciBzaWduYXR1cmUga2V5IHRvIHJl c3luYy4mbmJzcDsgT3B0aW9uICgxKSB3b3VsZCByZXF1aXJlIGEgbmV3IGVuZHBvaW50X2lkIGFu ZCBzaWduYXR1cmUga2V5LCB3aGljaCBtaWdodCBub3QgYmUgZmVhc2libGUgaW4gYWxsIGNhc2Vz LiZuYnNwOyBPcHRpb24gKDIpIHdvdWxkIGFsc28gbmVlZCB0byBoYXZlIGV4dHJhIG1lY2hhbmlz bQ0KIHRvIGFjY291bnQgZm9yIHJlY2VudCBqb2luZXJzIG5vdCBoYXZpbmcgdGhlIHJlcXVpcmVk IHJlc3VtcHRpb24gUFNLLjxicj4NCjxicj4NCk9wdGlvbiAoMSkgd291bGQgYWxzbyBub3QgYWxs b3cgZm9yIHJlc3luYyB3aXRoIGp1c3QgYSBzaWduYXR1cmUga2V5LiZuYnNwOyBBcyBSYXBoYWVs IHBvaW50ZWQgb3V0LCBiZWNhdXNlIHdlIG5vdyByZXF1aXJlIHNpZ25hdHVyZSBrZXlzIHRvIGJl IHVuaXF1ZSwgdGhlIG1lbWJlciB3b3VsZCBoYXZlIHRvIG1pbnQgYSBuZXcgc2lnbmF0dXJlIGtl eSBhbmQgZ2V0IGl0IGF1dGhlbnRpY2F0ZWQsIG9yIGVsc2UgdGhlaXIgYXR0ZW1wdCB0byByZWpv aW4gd291bGQNCiBiZSByZWplY3RlZCBhcyBhIGR1cGxpY2F0ZSBlbnRyeS48YnI+DQo8YnI+DQpP cHRpb25zICgzKSBhbmQgKDQpIHdvdWxkIGFsbG93IGEgY2xpZW50IHdobyBoYXMgbG9zdCBldmVy eXRoaW5nIGJ1dCB0aGVpciBzaWduYXR1cmUga2V5IHRvIHJlc3luYywgYXQgdGhlIHJpc2sgdGhh dCBhbiBhdHRhY2tlciB3aG8gaGFzIGNvbXByb21pc2VkIGEgbWVtYmVyJ3Mgc2lnbmF0dXJlIGtl eSBjb3VsZCBhYnVzZSBpdCB0byBqb2luIGFzIHRoYXQgbWVtYmVyIGFuZCBldmljdCB0aGUgb2xk LCBsZWdpdGltYXRlIGFwcGVhcmFuY2UuPGJyPg0KPGJyPg0KIyBQcm9nbm9zaXM8YnI+DQo8YnI+ DQpBZnRlciB0aGlzIGRpc2N1c3Npb24gYW5kIGFuYWx5c2lzLCBJIGNvbnRpbnVlIHRvIHRoaW5r IHRoYXQgKDMpIGFib3ZlIGlzIHRoZSByaWdodCBhbnN3ZXIsIHdpdGggYW4gb3B0aW9uYWwgdXBn YWRlIHRvICgyKS4mbmJzcDsgUHJvY2VlZGluZyBieSBlbGltaW5hdGlvbjo8YnI+DQo8YnI+DQpP cHRpb24gKDQpLCB3aGlsZSB0ZWNobmljYWxseSBmZWFzaWJsZSwgaXMgY2xlYXJseSBhIGxpdHRs ZSBzaWxseS4mbmJzcDsgVGhlcmUncyBubyByZWFzb24gdG8gYWxsb3cgam9pbmVycyB0byBkbyBh IHJlbW92ZSBpbiB0aGUgc2FtZSBvcGVyYXRpb24gYXMgdGhleSBqb2luOyB0aGV5IGNvdWxkIGRv IHRoaXMgYWZ0ZXJ3YXJkLjxicj4NCjxicj4NCk9wdGlvbiAoMikgZG9lcyBub3Qgc2VlbSB3b3Jr YWJsZSBpbiBnZW5lcmFsIGJlY2F1c2Ugb2YgdGhlIHJlY2VudC1qb2luZXIgcHJvYmxlbS4mbmJz cDsgV2hpbGUgbWVjaGFuaXNtIGNvdWxkIGJlIGRlc2lnbmVkIHRvIHByb3ZpZGUgdGhlIFBTSyB0 byByZWNlbnQgam9pbmVycywgaXQgd291bGQgYWRkIGEgbG90IG9mIGNvbXBsZXhpdHksIGFuZCB0 aGUgcmVjZW50IGpvaW5lcnMgd291bGRuJ3QgZ2V0IGFueSBiZW5lZml0IGZyb20gaXQsIHdoaWNo IGRpbHV0ZXMNCiB0aGUgdmFsdWUgb2YgdGhpcyBtZWNoYW5pc20uICZuYnNwOyhJdCdzIG5vdCBp bXBvc3NpYmxlIHRvIGFycml2ZSBhdCB0aGUgY2FzZSB3aGVyZSBldmVyeW9uZSBiZXNpZGVzIHRo ZSByZXN5bmMnaW5nIHBhcnRpY2lwYW50IGlzIG5ldyEpICZuYnNwOzxicj4NCjxicj4NCldpdGgg b3B0aW9uICgxKSwgeW91IGxvc2UgYW55IG5vdGlvbiBvZiByZXN5bmM7IEkgdGhpbmsgdGhlIG5l ZWQgZm9yIGVuZHBvaW50X2lkIHJvdGF0aW9uIG1ha2VzIHRoaXMgdW53b3JrYWJsZSBpbiBwcmFj dGljZS4mbmJzcDsgQW5kIGl0IGhhcyBraW5kIG9mIGFuIG9kZCBub3Rpb24gb2Ygc2VjdXJpdHk6 IFlvdSBhcmUgcHJvdGVjdGVkIGFnYWluc3QgYW4gYXR0YWNrZXIgdGhhdCBoYXMgY29tcHJvbWlz ZWQgYSBjdXJyZW50IHNpZ25hdHVyZSBrZXkgYnV0DQogY2FuJ3QgZ2V0IGEgbmV3IG9uZSBhdXRo ZW50aWNhdGVkLiZuYnNwOyBUaGlzIGlzIGEgcHJvYmxlbSBmb3IgdGhlIGF1dGhlbnRpY2F0aW9u IHN5c3RlbSB0byBoYW5kbGUgKGUuZy4sIHdpdGggcmV2b2NhdGlvbiksIG5vdCBmb3IgdGhlIGtl eSBleGNoYW5nZSAtLSBpZiB5b3UgaGF2ZSB2YWxpZCBjcmVkZW50aWFscyB3aXRoIGNvbXByb21p c2VkIGtleXMgZmxvYXRpbmcgYXJvdW5kLCB5b3UgaGF2ZSBiaWdnZXIgcHJvYmxlbXMgdG8gc29s dmUuJm5ic3A7IFNvIG15DQogcGVyc29uYWwgYXNzZXNzbWVudCBpcyB0aGF0ICgxKSBkb2Vzbid0 IHByb3ZpZGUgYSBiaWcganVtcCBpbiBzZWN1cml0eSBvdmVyICgzKSwgYXNzdW1pbmcgeW91IGhh dmUgYSBmdW5jdGlvbmluZyBhdXRoZW50aWNhdGlvbiBzeXN0ZW0uPGJyPg0KPGJyPg0KVHdvIHNp ZGUgbm90ZXMgYWJvdXQgKDMpOiBGaXJzdCwgaWYgd2UgZG8gKDMpIGJ1dCAqYWxsb3cqIFBTS3Ms IHRoZW4gYW4gYXBwbGljYXRpb24gY291bGQgb3B0IGluIHRvICgyKS4mbmJzcDsgU2Vjb25kLCB0 aGlzIHdob2xlIG1lY2hhbmlzbSBpcyBvcHQtaW4gZm9yIHRoZSBhcHBsaWNhdGlvbiwgc2luY2Ug eW91IGNhbid0IGRvIGFuIGV4dGVybmFsIGNvbW1pdCBpZiBhIFB1YmxpY0dyb3VwU3RhdGUgaGFz bid0IGJlZW4gcHVibGlzaGVkLjxicj4NCjxicj4NCkNvbmNyZXRlbHksIG15IHByb3Bvc2FsIGhl cmUgd291bGQgYmUgKDMpICsgKDIqKSAtLSBBbGxvdyBSZW1vdmUgd2l0aCBtYXRjaGluZyBwYXJh bWV0ZXJzLCBhbmQgYWxsb3cgUFNLcyBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gb3B0IGluIHRv ICgyKSB3aGVyZSB0aGV5IGNhbiBtYWtlIGl0IHdvcmsuJm5ic3A7IFRoYXQgd2F5LCBpZiBhbiBh cHBsaWNhdGlvbiBvcHRzIGluIHRvIGV4dGVybmFsIENvbW1pdHMsIHRoZXkgZ2V0IHRoZSBiZW5l Zml0IG9mIHJlc3luYw0KIGFuZCB0aGUgc2FtZSBzaWduYXR1cmUta2V5LWNvbXByb21pc2UgYm91 bmQgb24gaW1wZXJzb25hdGlvbiBmb3IgcmVzeW5jIGFzIHdlbGwgYXMgbmV0LW5ldyBqb2lucy4m bmJzcDsgQW5kIGlmIGFuIGFwcGxpY2F0aW9uIGNhbiBmaWd1cmUgb3V0IGhvdyB0byBtYWtlICgy KSB3b3JrLCB0aGV5IGNhbiByZXF1aXJlIGl0Ljxicj4NCjxicj4NCkxvb2tpbmcgZm9yd2FyZCB0 byBvdGhlcnMnIHRob3VnaHRzIGhlcmUhPGJyPg0KPGJyPg0KLS1STEI8YnI+DQo8YnI+DQo8YnI+ DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGd2ctbWF0ZXJpYWxz JTJGYmxvYiUyRm1haW4lMkZpbnRlcmltLTIwMTktMDElMkZtaW51dGVzLm1kJTIzYWNrcy1hbmQt bmFja3Mtam9ubSZhbXA7ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMWVi Zjk2YzMwY2M0NGZjOTZlMWQwOGQ5ODc4YmI2YjUlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4 OTYzMzc4ZSU3QzAlN0MwJTdDNjM3Njg5ODU3OTMxODQ0ODA4JTdDVW5rbm93biU3Q1RXRnBiR1pz YjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lM Q0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPSUyQkVwclFNT1ZrJTJCSU5oZHRSeEhMNUpm R1ElMkZlUDZ0Q0Z2Y0FNM3VvcE1GcTQlM0QmYW1wO3Jlc2VydmVkPTAiPg0KaHR0cHM6Ly9naXRo dWIuY29tL21sc3dnL3dnLW1hdGVyaWFscy9ibG9iL21haW4vaW50ZXJpbS0yMDE5LTAxL21pbnV0 ZXMubWQjYWNrcy1hbmQtbmFja3Mtam9ubTwvYT48YnI+DQpbMl0gPGEgaHJlZj0iaHR0cHM6Ly9u YW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG Z2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTImYW1wO2RhdGE9 MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzFlYmY5NmMzMGNjNDRmYzk2ZTFkMDhk OTg3OGJiNmI1JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYz NzY4OTg1NzkzMTg1NDgwMCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3 TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAw JmFtcDtzZGF0YT1sRmVZd3lIQ0dabHNIeiUyQk8yY1ZQRzdlVVRVanpvTGh6UTBmbml6JTJGYmxt YyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+DQpodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3Rv Y29sL2lzc3Vlcy85MjwvYT48YnI+DQpbM10gPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUy Rm1sc3dnJTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTMmYW1wO2RhdGE9MDQlN0MwMSU3Q2Jy aXR0YS5oYWxlJTQwbnBzLmVkdSU3QzFlYmY5NmMzMGNjNDRmYzk2ZTFkMDhkOTg3OGJiNmI1JTdD NmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY4OTg1NzkzMTg1 NDgwMCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9p VjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT16 cFclMkJDUXolMkJlRXdrbFlicDROUW1GY1VlSEJHbUFoMGpLQlJDMDVDeVZCcyUzRCZhbXA7cmVz ZXJ2ZWQ9MCI+DQpodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL2lzc3Vlcy85 MzwvYT48YnI+DQpbNF0gPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxz LXByb3RvY29sJTJGcHVsbCUyRjMzNiUyRmZpbGVzJTJGMjAxNDVlNDlhY2NlMDFkY2VkY2E3ZGIy ZDA1YzU3OTA4YTI5MjIwMiZhbXA7ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1 JTdDMWViZjk2YzMwY2M0NGZjOTZlMWQwOGQ5ODc4YmI2YjUlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5 OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3Njg5ODU3OTMxODY0Nzk0JTdDVW5rbm93biU3Q1RX RnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsx aGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmYW1wO3NkYXRhPTBPZ1ZkZGMlMkJJemp1NjFNd2ZR Rk5pWWplalpJTnRySXFmMDhDa0lnR20lMkJRJTNEJmFtcDtyZXNlcnZlZD0wIj4NCmh0dHBzOi8v Z2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJvdG9jb2wvcHVsbC8zMzYvZmlsZXMvMjAxNDVlNDlhY2Nl MDFkY2VkY2E3ZGIyZDA1YzU3OTA4YTI5MjIwMjwvYT48YnI+DQpbNV0gPGEgaHJlZj0iaHR0cHM6 Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZhcmNoJTJGbXNnJTJGbWxzJTJGSHNfbkFYM2x1RGpp UTRtSXdraUt1MUNGU0FFJTJGJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5l ZHUlN0MxZWJmOTZjMzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5 MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NzQ3ODklN0NVbmtub3duJTdD VFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJ azFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9bW9VQVpKM3RPQWhGSSUyQk1N RnE5OUIxMTF3SnB4QlJCd2JSUFlzNWxEeEMwJTNEJmFtcDtyZXNlcnZlZD0wIj4NCmh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbWxzL0hzX25BWDNsdURqaVE0bUl3a2lLdTFD RlNBRS88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_25D37E5CF7C048C7849E28C8A54762D0npsedu_-- From nobody Mon Oct 4 19:12:49 2021 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 030A93A0E22 for ; Mon, 4 Oct 2021 19:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 Z1_ddSdat1gF for ; Mon, 4 Oct 2021 19:12:44 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 6A0B53A0E18 for ; Mon, 4 Oct 2021 19:12:44 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id q81so1666981qke.5 for ; Mon, 04 Oct 2021 19:12:44 -0700 (PDT) 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=AnqxQlAHsDyQcQz8O1HRwpEZuLpYADnUWZF7y2HgatU=; b=Him4CsoGAlJPIG37qmOf7b1tqeqe3KxcdITiBe996hKlYK4YuZnVWHfRCxr78CFnfZ Kfi52lOK8gEiANVUzpRY8R9hXEng7lqGsAF4wb9+E+RbJphtF5+KdTBVDTbi8Rs0aPRw gNdJS+YS/zo9WnPjQyN81k4L6XAMM4dWCwvdZCQ/8mMNwsdRoJSXlmAUhYa6LMAwB1Mp RUGRPLNP4/GSBYYUmRADRwYG8JMIfLyhK3r10d+jjsULwi5oTvBvZ6GLa8oT1mhXwDEp v8JrIME1thlSfLe1zg4lj9Q6LXNJNnjA5XprJRZT90kL2T3OglLaZ6R3bWiKVHRW0yaN fHnA== 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=AnqxQlAHsDyQcQz8O1HRwpEZuLpYADnUWZF7y2HgatU=; b=NHKOPevFfr59hxk3pR3QfzN7yT/eWEAEZZ3aP3cTYoRbg8ZbH6mohGuaZN/ji0cdiD P1yVJQgYciW4cem1TDS3wVLh5bUHSJf7vFtRe2PKwn7LBGybF181O8xjeCWmQMKb6r+d 0Ktx9w3uoVohhR5tkG53L4L3W1XqMtIjYTDEWtgz97ntRMovDxplMDdE5FN2pWQK4uT2 avjLw63DA60BvthiMCYPSbXEZzEfiYl5ZUQi0/hFHjrK2soErcnO4QQA0E5F8lDoRKCA SEEY3N6ydpLiLOkInuYdw11KmBWH7krpn+eaSOyYF5dgE15OSc98WbassOaTj8t+Sh6M +nCQ== X-Gm-Message-State: AOAM531Ymdb4znAefn8JEfW4i/Um3BpitOC7O93ukSgOtxpSOk9hD8Q6 pVJwJvZd1MaN2UZ/5XIX4RuJfPH4VpVYp4QOkQrku5jpxakJasGJ X-Google-Smtp-Source: ABdhPJx03v8QKKWrB0LKCs32Vi+v4fF7Q2CGiEAIpe6euik5j8nXsArzIZh5l2mK+2ueFWM9JPeIFUJ2iZEX0lBP23s= X-Received: by 2002:a37:a413:: with SMTP id n19mr12890059qke.461.1633399962877; Mon, 04 Oct 2021 19:12:42 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 4 Oct 2021 22:12:30 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000090570905cd91908b" Archived-At: Subject: [MLS] Post-interim PRs X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 02:12:47 -0000 --00000000000090570905cd91908b Content-Type: text/plain; charset="UTF-8" Hi all, Thanks for the good discussion on the interim call today. I have posted a salvo of PRs capturing where I think we ended up. Given that these have already had some discussion, if we could get some quick reviews, I think we can go ahead and merge. Then once we resolve the rsync discussion one way or another, we can cut a new draft and kick off WGLC. #487 - Remove the notion of a 'leaf index' https://github.com/mlswg/mls-protocol/pull/487 #489 - Add RequiredCapabilities extension (implementing Rohan's suggestion) https://github.com/mlswg/mls-protocol/pull/489 #490 - Use cascaded KDF instead of concatenation to consolidate PSKs https://github.com/mlswg/mls-protocol/pull/490 Thanks a lot, --Richard --00000000000090570905cd91908b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks for the good = discussion on the interim call today.=C2=A0 I have posted a salvo of PRs ca= pturing where I think we ended up.=C2=A0 Given that these have already had = some discussion, if we could get some quick reviews, I think we can go ahea= d and merge.=C2=A0 Then once we resolve the rsync discussion one way or ano= ther, we can cut a new draft and kick off WGLC.

#4= 87 - Remove the notion of a 'leaf index'

#489 - Add RequiredCapabilities= extension (implementing Rohan's suggestion)

#490 - Use cascaded KDF ins= tead of concatenation to consolidate PSKs

Thanks a lot,
--Richard
<= /div>
--00000000000090570905cd91908b-- From nobody Mon Oct 4 19:32:07 2021 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 D5DE13A1027 for ; Mon, 4 Oct 2021 19:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EfOhg2aOddwe for ; Mon, 4 Oct 2021 19:31:55 -0700 (PDT) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 878913A0E9E for ; Mon, 4 Oct 2021 19:31:46 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id z15so1286399qvj.7 for ; Mon, 04 Oct 2021 19:31:46 -0700 (PDT) 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=h9xsujzvtf+Yoo+HjvvFPvrb+T8sN8UDx3ImaANniDE=; b=wAs1mhUeTSe+QWZLslAUcMDR3UghVj/TFdNAklzkpb6qmK2aXiFhTPHeJ62kh3hITu NC53UBr2jRPblTcW7MItEbd3AW/sb5IXvvYeOSoTGfMIMta9zVyrx9wZA6nUWeKQZmTs mv14Rq0lr/12e8fePWmeNIWyLaQpPX+zn8tuPH7s9Fth+5IAjF48z75HqL9j7UG5HeEy e1owGX523sZJnVl4jb/CE3lwyEHwUQVMFWzJqAlNZVApLjBxx4ZxbiwNz5r6hMq1sQRj 2FvfzIct8BgPIlnvfeMIjK5wZjStCKZ6l1s5kLxo/LQekSqH3y12XtjpzBg78BwxvX10 U3Ug== 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=h9xsujzvtf+Yoo+HjvvFPvrb+T8sN8UDx3ImaANniDE=; b=hkNMuDtcmGcT5xlNFCCuv64oxOXb2lHNHoHV26gh3YwmR2cxwm4HAJIwBQgZFnyBJ0 CQ7MT5I6m0DpIIUMuTrtNfClBUV9Sy+myH56jV2Ex0AD+j/3uX2HlOOpVt+4YzGLAxCp wmeV/UhZh0xhQGuaLlYj6yS1A6JBY7kD1UrlCNIWSN4q0gSML81LGzkPHxkORyi4P7n5 SzvN7larWc54GH29wwOdzNoHQ3CSN0jSxFqhlsC2Dh/EVfGib3l27Q8/XGPyOrxmH9fY EOrAqImX55Or/go4Yvv51O8ndopE5g+d1793BFiO4feBo38kLNuHqzh/QGVYHCaavO/V 2Ayg== X-Gm-Message-State: AOAM533G2gNsjHEmbql8j12vlvhdF0be4OTPRTQ7oiNNE7zmkrvV+96G 6bWTaphA8O2b1rzqkdTaW4+D6Nf4KxcxlZTR+t+Ssg== X-Google-Smtp-Source: ABdhPJykBKwspzBMWXVCcMsb84/XBr2O4M2ZblA5HQa2xKAqBhtpf/ztmJDgux1CfRiO6dmFhg3MIJ+vMZb3dsRU6nc= X-Received: by 2002:a05:6214:3ea:: with SMTP id cf10mr25702196qvb.53.1633401104866; Mon, 04 Oct 2021 19:31:44 -0700 (PDT) MIME-Version: 1.0 References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> In-Reply-To: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> From: Richard Barnes Date: Mon, 4 Oct 2021 22:31:31 -0400 Message-ID: To: "Hale, Britta (CIV)" Cc: Messaging Layer Security WG , Konrad Kohbrok Content-Type: multipart/alternative; boundary="000000000000a1b1dc05cd91d40f" Archived-At: Subject: Re: [MLS] Resync archaeology + analysis + prognosis X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 02:32:04 -0000 --000000000000a1b1dc05cd91d40f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Britta, Couple of responses inline... On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) wrote: > [trimmed] > > > > To the present proposed options, I will note that the =E2=80=98new joiner= s in > interim=E2=80=99 case is likely a misleading focus point for the discussi= on, and we > should avoid tripping into that ditch for a number of reasons: > > - Notably, if everyone except for the re-syncing participant is new, > why not just require the re-syncing participant to be added as a new m= ember > themselves? It is, after all, practically a brand new group at that po= int. > - It is true that a new member would not gain from a PSK guarantee, > but why should we reduce the guarantees for all other participants to = that > of the new joiner? From the view of the new joiner, all participants a= re > new in any case, so e.g. PCS does not have substantial meaning as of y= et. > Existing members have more to lose and also have the more to gain from= PSK > use. I do not believe we want to adapt a stance of =E2=80=98if the new= joiner > doesn=E2=80=99t get a security guarantee, no one should have the secur= ity > guarantee=E2=80=99 =E2=80=93 in fact, the tree structure, commit histo= ry, and the like > provide insight to longer term members that a new joiner does not have= . So > (2) offers a new joiner the benefits of (3) but to all others an even > stronger guarantee. > - As a nod to what a new joiner may gain, we can offer the following: > if a re-sync PSK fails, then whichever existing member checks and note= s the > PSK failure should initiate a removal of the resyncing member. If ther= e is > a new joiner, then by continued presence of the re-syncing member they= gain > the guarantee that at least one other group member has previously seen= that > member, or else would have ejected them (assuming that the checker is > online). > > I don't mean to over-rotate on this case, but software being software, we need an algorithm to implement that covers all the cases. While the "everyone is new" scenario is outlandish, it wouldn't be all that surprising to have one or two new members, so it's a case that would need addressing. The seemingly most obvious approach to addressing this problem is to encrypt the PSK to new members, which requires you at least have enough state to figure out who the new members are. It also occurs to me now that the PSK approach presumes that you know when your state went bad, since you would want to use a PSK from before that point. In Raphael's example where persistent storage is corrupted, all you know is that messages stopped decrypting, which gives you an upper bound on the time of corruption, but not really a way to go back and figure out what's good. The security goal in the balance here is PCS. Adding a re-sync option of > any of the varieties (2)-(4) would break that to some degree, since > following a compromise and passive period the adversary is then enabled t= o > regain a foothold. The question is how much of a degree of loss are we > willing to tolerate. > I'm not sure I would really characterize this as a PCS violation. PCS is a guarantee that you get when you take a certain action. For example, when a member issue an Update or a Commit with a fresh HPKE key pair, you should get PCS with regard to that participant's HPKE key pair; likewise with rotating signature keys. Here, the signature key has not been rotated, so there's no PCS boundary. It is worth considering whether this mechanism gives the attacker any additional capabilities in the event that (1) the signature key is compromised, and (2) the compromised member issues an Update or Commit rotating the signature key. ISTM that you still get PCS there in option (3), since the requirement that the signature keys match ensures that the old, compromised signature key is not allowed to resync back into the group. There's still a risk that the compromised key / credential could be used for a fresh, non-resync join, but that's an inherent risk with external Commit / freely joinable groups, and also an opportunity for the AS's revocation/invalidation system to help. Will take a look at the remainder in the morning... --RLB > > - I agree that (4) is an immediate discard. > - Under (2) a PSK use, the PSK use at least more limited due to the > proof of knowledge of a past state (e.g. notes above). This is a worth= while > property to enforce in my view since it balances authentication across= two > vectors: the signature key and knowledge of group state. Adversary acc= ess > to only one or the other is insufficient for the adversary to eject Al= ice > and replace her in the group. > - Under (3), the attack scenario of Eve compromising Alice (full state > + sig key), followed eventually* by removing Alice while adding hersel= f, is > not dissimilar from the attack scenario of Eve compromising Alice full > state + sig key) followed eventually* by providing an impersonating up= date > in Alice=E2=80=99s name. What has been shown so far is that this type = of scenario > can be limited by rotating signature keys. A important point that is > different in these scenarios is that under the first Alice knows she w= as > removed (a plus) while under the second (currently possible) scenario = the > group simply goes silent and Alice does not know if it was malicious o= r > not. All said, it could be worse. That does not consider other attack > scenarios though, for example when the attacker gains the signature ke= y but > not past state/PSK. > > > > *I.e. after a potentially passive period, if we are to show how this > behaves in the PCS scenario. > > > > This leads to an important question: does our current uniqueness of sig > key predicate limit the ability to rotate signature keys within a group? > That is our means of limiting the full state + sig key compromise scenari= o > impacts mentioned above, and therefore the means of limiting the drawback= s > of (3). We should make sure that the limiting ability is feasible. If tha= t > hindered in any way, then I would vote very strongly for (2) as it at lea= st > bootstraps some of the authentication properties from the group state in > the scenario that the sig key is compromised. > > > > > > All the best, > > > > Britta > > > > > > > > *From: *MLS on behalf of Richard Barnes > > *Date: *Monday, October 4, 2021 at 4:09 PM > *To: *Messaging Layer Security WG > *Subject: *[MLS] Resync archaeology + analysis + prognosis > > > > OK, I think I have traced back some idea of why we removed the earlier > resync proposal. Here's a little essay on how we got here, a recap of th= e > trade-offs, and my thoughts on where we should go. > > > > tl;dr: Earlier decision not dispositive; we should do basically what's in > the PR now. > > > # History > > The story starts all the way back at the January 2019 interim at Mozilla = / > Mountain View. There was a discussion there of ACK/NACK and replay as > related issues [1]. That discussion seems to have led to agreement that = a > complete error recovery system was a complex enough topic, and clearly > enough separated from the main protocol that it could be handled in a > separate specification. As a result, the issues that had been opened for > ACK/NACK and resync were closed [2][3]. When Britta and Konrad posted #3= 36 > [4] including a resync mechanism, my review simply cited that earlier > closed issue as a reason for taking it out [5]. > > One other note with regard to #336 -- It looks to me like the "resync" > mechanism in there was not really fleshed out enough to be implementable. > The state linked above was the last state before my review, and the word > "resync" doesn't actually appear. Instead the PR talks about "recovering > lost group members" using Add and PSK, which could be elaborated to solve= a > version of this problem, but would require the assistance of a continuing > member rather than allowing the lost member to resync unilaterally. It > would also have the same issues noted in terms of new joiners not having > resync PSKs. > > Overall, though, reading this history doesn't seem to me like we really > made a principled decision not to do resync. We just punted after some > discussion in the abstract, and that stuck. We have a more concrete > question now. > > # Analysis > > Since the discussion of #336 in 2020, we have added external commits in > order to have groups you can join unilaterally. So regardless of the > broader question of resync, we have to decide what proposals a joiner is > allowed to originate in their Commit (sending them by value), in > particular, whether an external Commit can contain a joiner-originated > Remove proposal. We have a spectrum of options here: > > 1. Forbid Remove > 2. Allow Remove + require the (identity, endpoint_id) and signature key t= o > match the removed node + require resumption PSK > 3. Allow Remove + require the (identity, endpoint_id) and signature key t= o > match the removed node > 4. Allow Remove without restriction > > Options (1) and (2) would block an attacker that has compromised a > member's signature key from joining as that member and evicting the old > appearance. Option (2) because of the PSK; option (1) because of the > uniqueness requirements (as Raphael pointed out on the call). > > Options (1) and (2) do not allow a client who has lost everything but > their signature key to resync. Option (1) would require a new endpoint_i= d > and signature key, which might not be feasible in all cases. Option (2) > would also need to have extra mechanism to account for recent joiners not > having the required resumption PSK. > > Option (1) would also not allow for resync with just a signature key. As > Raphael pointed out, because we now require signature keys to be unique, > the member would have to mint a new signature key and get it authenticate= d, > or else their attempt to rejoin would be rejected as a duplicate entry. > > Options (3) and (4) would allow a client who has lost everything but thei= r > signature key to resync, at the risk that an attacker who has compromised= a > member's signature key could abuse it to join as that member and evict th= e > old, legitimate appearance. > > # Prognosis > > After this discussion and analysis, I continue to think that (3) above is > the right answer, with an optional upgade to (2). Proceeding by > elimination: > > Option (4), while technically feasible, is clearly a little silly. > There's no reason to allow joiners to do a remove in the same operation a= s > they join; they could do this afterward. > > Option (2) does not seem workable in general because of the recent-joiner > problem. While mechanism could be designed to provide the PSK to recent > joiners, it would add a lot of complexity, and the recent joiners wouldn'= t > get any benefit from it, which dilutes the value of this mechanism. (It'= s > not impossible to arrive at the case where everyone besides the resync'in= g > participant is new!) > > With option (1), you lose any notion of resync; I think the need for > endpoint_id rotation makes this unworkable in practice. And it has kind = of > an odd notion of security: You are protected against an attacker that has > compromised a current signature key but can't get a new one authenticated= . > This is a problem for the authentication system to handle (e.g., with > revocation), not for the key exchange -- if you have valid credentials wi= th > compromised keys floating around, you have bigger problems to solve. So = my > personal assessment is that (1) doesn't provide a big jump in security ov= er > (3), assuming you have a functioning authentication system. > > Two side notes about (3): First, if we do (3) but *allow* PSKs, then an > application could opt in to (2). Second, this whole mechanism is opt-in > for the application, since you can't do an external commit if a > PublicGroupState hasn't been published. > > Concretely, my proposal here would be (3) + (2*) -- Allow Remove with > matching parameters, and allow PSKs so that applications can opt in to (2= ) > where they can make it work. That way, if an application opts in to > external Commits, they get the benefit of resync and the same > signature-key-compromise bound on impersonation for resync as well as > net-new joins. And if an application can figure out how to make (2) work= , > they can require it. > > Looking forward to others' thoughts here! > > --RLB > > > [1] > https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.m= d#acks-and-nacks-jonm > > [2] https://github.com/mlswg/mls-protocol/issues/92 > > [3] https://github.com/mlswg/mls-protocol/issues/93 > > [4] > https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca= 7db2d05c57908a292202 > > [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE= / > > --000000000000a1b1dc05cd91d40f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Britta,

= Couple of responses inline...

On Mon, Oct 4, 2021 at 8:42 PM Hale,= Britta (CIV) <britta.hale@nps.ed= u> wrote:
[trimmed]=

=C2=A0

To the present proposed options, I will note that th= e =E2=80=98new joiners in interim=E2=80=99 case is likely a misleading focu= s point for the discussion, and we should avoid tripping into that ditch fo= r a number of reasons:

  • Notably, if everyone except for the re-syncing participant is new= , why not just require the re-syncing participant to be added as a new memb= er themselves? It is, after all, practically a brand new group at that point.
  • It is true t= hat a new member would not gain from a PSK guarantee, but why should we red= uce the guarantees for all other participants to that of the new joiner? Fr= om the view of the new joiner, all participants are new in any case, so e.g. PCS does not hav= e substantial meaning as of yet. Existing members have more to lose and als= o have the more to gain from PSK use. I do not believe we want to adapt a s= tance of =E2=80=98if the new joiner doesn=E2=80=99t get a security guarantee, no one should have the security guarantee=E2=80= =99 =E2=80=93 in fact, the tree structure, commit history, and the like pro= vide insight to longer term members that a new joiner does not have. So (2)= offers a new joiner the benefits of (3) but to all others an even stronger guarantee.
  • As a nod t= o what a new joiner may gain, we can offer the following: if a re-sync PSK = fails, then whichever existing member checks and notes the PSK failure shou= ld initiate a removal of the resyncing member. If there is a new joiner, then by continued prese= nce of the re-syncing member they gain the guarantee that at least one othe= r group member has previously seen that member, or else would have ejected = them (assuming that the checker is online).
I don't mean to ove= r-rotate on this case, but software being software, we need an algorithm to= implement that covers all the cases.=C2=A0 While the "everyone is new= " scenario is outlandish, it wouldn't be all that surprising to ha= ve one or two new members, so it's a case that would need addressing.= =C2=A0 The seemingly most obvious approach to addressing this problem is to= encrypt the PSK to new members, which requires you at least have enough st= ate to figure out who the new members are.

It also= occurs to me now that the PSK approach presumes that you know when your st= ate went bad, since you would want to use a PSK from before that point.=C2= =A0 In Raphael's example where persistent storage is corrupted, all you= know is that messages stopped decrypting, which gives you an upper bound o= n the time of corruption, but not really a way to go back and figure out wh= at's good.


The security goal in the balance here is PCS. Adding a re-sy= nc option of any of the varieties (2)-(4) would break that to some degree, = since following a compromise and passive period the adversary is then enabl= ed to regain a foothold. The question is how much of a degree of loss are we willing to tolerate.


I'm not sure = I would really characterize this as a PCS violation.=C2=A0 PCS is a guarant= ee that you get when you take a certain action.=C2=A0 For example, when a m= ember issue an Update or a Commit with a fresh HPKE key pair, you should ge= t PCS with regard to that participant's HPKE key pair; likewise with ro= tating signature keys.=C2=A0 Here, the signature key has not been rotated, = so there's no PCS boundary.

It is worth consid= ering whether this mechanism gives the attacker any additional capabilities= in the event that (1) the signature key is compromised, and (2) the compro= mised member issues an Update or Commit rotating the signature key.=C2=A0 I= STM that you still get PCS there in option (3), since the requirement that = the signature keys match ensures that the old, compromised signature key is= not allowed to resync back into the group.=C2=A0 There's still a risk = that the compromised key / credential could be used for a fresh, non-resync= join, but that's an inherent risk with external Commit / freely joinab= le groups, and also an opportunity for the AS's revocation/invalidation= system to help.

Will take a look at the remai= nder in the morning...

--RLB

=C2=A0

  • I agree that (4) is an immediate discard.
  • Under (2) a PSK use, the PSK use at least more limited due to the proo= f of knowledge of a past state (e.g. notes above). This is a worthwhile pro= perty to enforce in my view since it balances authentication across two vectors: the signature key and knowledg= e of group state. Adversary access to only one or the other is insufficient= for the adversary to eject Alice and replace her in the group.
  • Under (3), the attack scenario of Eve compromi= sing Alice (full state + sig key), followed eventually* by removing Alice w= hile adding herself, is not dissimilar from the attack scenario of Eve compromising Alice full state + sig key) followed eventually* by pr= oviding an impersonating update in Alice=E2=80=99s name. What has been show= n so far is that this type of scenario can be limited by rotating signature= keys. A important point that is different in these scenarios is that under the first Alice knows she was removed (a = plus) while under the second (currently possible) scenario the group simply= goes silent and Alice does not know if it was malicious or not. All said, = it could be worse. That does not consider other attack scenarios though, for example when the attacker gain= s the signature key but not past state/PSK.

=C2=A0<= /u>

*I.e. after a pot= entially passive period, if we are to show how this behaves in the PCS scen= ario.

=C2=A0<= /u>

This leads to an important question: does our curren= t uniqueness of sig key predicate limit the ability to rotate signature key= s within a group? That is our means of limiting the full state + sig key co= mpromise scenario impacts mentioned above, and therefore the means of limiting the drawbacks of (3). We should= make sure that the limiting ability is feasible. If that hindered in any w= ay, then I would vote very strongly for (2) as it at least bootstraps some = of the authentication properties from the group state in the scenario that the sig key is compromised.

=C2=A0

=C2=A0

All the best,

=C2=A0

Britta

=C2=A0

=C2=A0

=C2=A0

From: = MLS <mls-bounces@ietf.org> o= n behalf of Richard Barnes <rlb@ipv.sx>
Date: Monday, October 4, 2021 at 4:09 PM
To: Messaging Layer Security WG <mls@ietf.org>
Subject: [MLS] Resync archaeology + analysis + prognosis

=C2=A0

OK, I think I have traced back some idea of why we r= emoved the earlier resync proposal.=C2=A0 Here's a little essay on how = we got here, a recap of the trade-offs, and my thoughts on where we should = go.

=C2=A0

tl;dr: Earlier decision not dispositive; we should d= o basically what's in the PR now.


# History

The story starts all the way back at the January 2019 interim at Mozilla / = Mountain View.=C2=A0 There was a discussion there of ACK/NACK and replay as= related issues [1].=C2=A0 That discussion seems to have led to agreement t= hat a complete error recovery system was a complex enough topic, and clearly enough separated from the main protocol = that it could be handled in a separate specification.=C2=A0 As a result, th= e issues that had been opened for ACK/NACK and resync were closed [2][3].= =C2=A0 When Britta and Konrad posted #336 [4] including a resync mechanism, my review simply cited that earlier closed i= ssue as a reason for taking it out [5].

One other note with regard to #336 -- It looks to me like the "resync&= quot; mechanism in there was not really fleshed out enough to be implementa= ble.=C2=A0 The state linked above was the last state before my review, and = the word "resync" doesn't actually appear.=C2=A0 Instead the PR talks about "recovering lost group members" using Add and= PSK, which could be elaborated to solve a version of this problem, but wou= ld require the assistance of a continuing member rather than allowing the l= ost member to resync unilaterally.=C2=A0 It would also have the same issues noted in terms of new joiners not having resync = PSKs.

Overall, though, reading this history doesn't seem to me like we really= made a principled decision not to do resync.=C2=A0 We just punted after so= me discussion in the abstract, and that stuck.=C2=A0 We have a more concret= e question now.

# Analysis

Since the discussion of #336 in 2020, we have added external commits in ord= er to have groups you can join unilaterally.=C2=A0 So regardless of the bro= ader question of resync, we have to decide what proposals a joiner is allow= ed to originate in their Commit (sending them by value), in particular, whether an external Commit can contain a jo= iner-originated Remove proposal.=C2=A0 We have a spectrum of options here:<= br>
1. Forbid Remove
2. Allow Remove + require the (identity, endpoint_id) and signature key to = match the removed node + require resumption PSK
3. Allow Remove + require the (identity, endpoint_id) and signature key to = match the removed node
4. Allow Remove without restriction

Options (1) and (2) would block an attacker that has compromised a member&#= 39;s signature key from joining as that member and evicting the old appeara= nce.=C2=A0 Option (2) because of the PSK; option (1) because of the uniquen= ess requirements (as Raphael pointed out on the call).

Options (1) and (2) do not allow a client who has lost everything but their= signature key to resync.=C2=A0 Option (1) would require a new endpoint_id = and signature key, which might not be feasible in all cases.=C2=A0 Option (= 2) would also need to have extra mechanism to account for recent joiners not having the required resumption PSK.

Option (1) would also not allow for resync with just a signature key.=C2=A0= As Raphael pointed out, because we now require signature keys to be unique= , the member would have to mint a new signature key and get it authenticate= d, or else their attempt to rejoin would be rejected as a duplicate entry.

Options (3) and (4) would allow a client who has lost everything but their = signature key to resync, at the risk that an attacker who has compromised a= member's signature key could abuse it to join as that member and evict= the old, legitimate appearance.

# Prognosis

After this discussion and analysis, I continue to think that (3) above is t= he right answer, with an optional upgade to (2).=C2=A0 Proceeding by elimin= ation:

Option (4), while technically feasible, is clearly a little silly.=C2=A0 Th= ere's no reason to allow joiners to do a remove in the same operation a= s they join; they could do this afterward.

Option (2) does not seem workable in general because of the recent-joiner p= roblem.=C2=A0 While mechanism could be designed to provide the PSK to recen= t joiners, it would add a lot of complexity, and the recent joiners wouldn&= #39;t get any benefit from it, which dilutes the value of this mechanism. =C2=A0(It's not impossible to arrive at t= he case where everyone besides the resync'ing participant is new!) =C2= =A0

With option (1), you lose any notion of resync; I think the need for endpoi= nt_id rotation makes this unworkable in practice.=C2=A0 And it has kind of = an odd notion of security: You are protected against an attacker that has c= ompromised a current signature key but can't get a new one authenticated.=C2=A0 This is a problem for the aut= hentication system to handle (e.g., with revocation), not for the key excha= nge -- if you have valid credentials with compromised keys floating around,= you have bigger problems to solve.=C2=A0 So my personal assessment is that (1) doesn't provide a big jump in security= over (3), assuming you have a functioning authentication system.

Two side notes about (3): First, if we do (3) but *allow* PSKs, then an app= lication could opt in to (2).=C2=A0 Second, this whole mechanism is opt-in = for the application, since you can't do an external commit if a PublicG= roupState hasn't been published.

Concretely, my proposal here would be (3) + (2*) -- Allow Remove with match= ing parameters, and allow PSKs so that applications can opt in to (2) where= they can make it work.=C2=A0 That way, if an application opts in to extern= al Commits, they get the benefit of resync and the same signature-key-compromise bound on impersonation for resync as= well as net-new joins.=C2=A0 And if an application can figure out how to m= ake (2) work, they can require it.

Looking forward to others' thoughts here!

--RLB


[1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#= acks-and-nacks-jonm
[2] https://github.com/mlswg/mls-protocol/issues/92
[3] https://github.com/mlswg/mls-protocol/issues/93
[4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7d= b2d05c57908a292202
[5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/<= u>

--000000000000a1b1dc05cd91d40f-- From nobody Tue Oct 5 05:04:16 2021 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 C92173A0942 for ; Tue, 5 Oct 2021 05:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMVIFd3Gg5vp for ; Tue, 5 Oct 2021 05:04:08 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 6A9CD3A093B for ; Tue, 5 Oct 2021 05:04:08 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id r16so18767009qtw.11 for ; Tue, 05 Oct 2021 05:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Q0+C2qUuVa1YqtrksvTLiotTdSRMk25lRPHuH/RCZnc=; b=QOWbu6pmjDAm5zugir9CJJHD5cHu01rRwCojdkhUVbPzvTBFTSYC4gzMhhZ19bK2fZ SAK6OO4Zbka3vKBRcNlBeVQ+u9M6kS0+HdktEKLD0DNIastos7qIIkyY+i6p0/HKJ4BP tpvnQJKhmARk3BSuAeIDHEMfRs87UEzZQ3T5o= 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:date:references:to:in-reply-to:message-id; bh=Q0+C2qUuVa1YqtrksvTLiotTdSRMk25lRPHuH/RCZnc=; b=gOHwkyK5ZA7a0IHR0lDEjhio5ToLqisNKnsSowD4Bpcbh5cSO6XYb0h6k7ZYF/luuR HGg+IgTDWSvBZMgAmdSl2a+H5/pahvg3AtY+9EIswSgymckO9qtztUlRcQhAdWcO9wOb aAFzeZiGukkV+aa+TPaNDfkJVgxUhgp2Q+asJaoVJd1j1/ik7dVs5VQWKYejeEzpkilH JdvjnhTUryXCb4Ily9ST4USZS7J4UROeTSpVt2tmH7OxQMyCF6iguPmoJN7P/uDIJb59 qwH0JEZaB/lg3Zzd2c1mmukMbiE/g43+1P6hCRI55vPo4HgSx8J9LsQZ0wHbfaSj7eZ+ AUQQ== X-Gm-Message-State: AOAM533Cmh8faeeeLTmwXzTuQirsfWPs8XjOuSiDzDm6eu3rGmQbVx3R 0X1XiG4w1JVUcZydnt8aWuxRbhH/Sq+E7g== X-Google-Smtp-Source: ABdhPJyxVc/qVboLZbBPvvTNZpy5/6J94mIQ2GVyev1ntrnHk7dlHJju485XylHmCwICk9HI4vmVeQ== X-Received: by 2002:ac8:7010:: with SMTP id x16mr19811066qtm.136.1633435446958; Tue, 05 Oct 2021 05:04:06 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id h4sm10247378qta.46.2021.10.05.05.04.06 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Oct 2021 05:04:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 5 Oct 2021 08:04:06 -0400 References: <9AAE4C63-C16C-4FC5-B7BE-FDDBADE807CB@sn3rd.com> To: MLS List In-Reply-To: <9AAE4C63-C16C-4FC5-B7BE-FDDBADE807CB@sn3rd.com> Message-Id: <1F599381-C913-4408-8E7C-A6F4FFB207F6@sn3rd.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [MLS] Reminder: 20211004 MLS Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2021 12:04:14 -0000 Thanks again to everyone who participated. Special thanks to = rlb/bifurcation for his multitasking abilities that allowed him to lead = many of the discussions and take notes at the same time. We managed to = get through all of the protocol-related PRs and found ways forward for = all. At least two new PRs will be submitted as a result of the = discussions. Hoping to post a new version shortly that will be ready for = WGLC. We ended up using all of the time for the protocol I-D so we might = schedule an interim for the architecture I-D. Will circle with the = authors. Cheers, spt > On Oct 4, 2021, at 08:48, Sean Turner wrote: >=20 > Hi! Last minute reminder that our interim is today. I updated the repo = to include the relevant information and some chair slides: > https://github.com/mlswg/wg-materials/tree/main/interim-2021-10 >=20 > This information can also be found at: > https://datatracker.ietf.org/meeting/interim-2021-mls-02/session/mls >=20 > Cheers, > spt (for the chairs) From nobody Tue Oct 5 23:05:42 2021 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 741293A138B for ; Tue, 5 Oct 2021 23:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr1S__BHAZpL for ; Tue, 5 Oct 2021 23:05:34 -0700 (PDT) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050::465:101]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9963A138F for ; Tue, 5 Oct 2021 23:05:32 -0700 (PDT) Received: from smtp202.mailbox.org (smtp202.mailbox.org [80.241.60.245]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4HPP7r3GMqzQkHv; Wed, 6 Oct 2021 08:05:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Date: Wed, 6 Oct 2021 08:05:22 +0200 (CEST) From: Konrad Kohbrok To: Richard Barnes , "Hale, Britta (CIV)" Cc: Messaging Layer Security WG Message-ID: <1698663123.17469.1633500322380@office.mailbox.org> In-Reply-To: References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Rspamd-Queue-Id: A2C47270 Archived-At: Subject: Re: [MLS] Resync archaeology + analysis + prognosis X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 06:05:41 -0000 Hi, If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 fo= r now) represent trade-offs in security guarantees and their applicability = depends on the specific deployment scenario. My understanding is that exter= nal joins will be subject to some sort of policy anyway. Should we then be = strict in the spec in terms of what we mandate the exact policy w.r.t. PSKs= is?=20 Since I don't think either solution represents much of a foot-gun, I propos= e we include the capability to include resync PSKs in the spec for this pur= pose, but don't mandate them. Instead we relegate the policy decision to th= e application layer and detail the security trade-offs in the architecture = document. I realize that delegating decisions to the application layer is a= bit of a cop-out solution, but I think in this case it makes sense to incl= ude the mechanism in the spec and then let the application decide. Cheers, Konrad > Richard Barnes hat am 05.10.2021 04:31 geschrieben: >=20 >=20 > Hi Britta, >=20 > Couple of responses inline... >=20 >=20 > On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) w= rote: > > [trimmed] > > =C2=A0 > > To the present proposed options, I will note that the =E2=80=98new join= ers in interim=E2=80=99 case is likely a misleading focus point for the dis= cussion, and we should avoid tripping into that ditch for a number of reaso= ns:=20 > > * Notably, if everyone except for the re-syncing participant is new, = why not just require the re-syncing participant to be added as a new member= themselves? It is, after all, practically a brand new group at that point.= =20 > > * It is true that a new member would not gain from a PSK guarantee, b= ut why should we reduce the guarantees for all other participants to that o= f the new joiner? From the view of the new joiner, all participants are new= in any case, so e.g. PCS does not have substantial meaning as of yet. Exis= ting members have more to lose and also have the more to gain from PSK use.= I do not believe we want to adapt a stance of =E2=80=98if the new joiner d= oesn=E2=80=99t get a security guarantee, no one should have the security gu= arantee=E2=80=99 =E2=80=93 in fact, the tree structure, commit history, and= the like provide insight to longer term members that a new joiner does not= have. So (2) offers a new joiner the benefits of (3) but to all others an = even stronger guarantee.=20 > > * As a nod to what a new joiner may gain, we can offer the following:= if a re-sync PSK fails, then whichever existing member checks and notes th= e PSK failure should initiate a removal of the resyncing member. If there i= s a new joiner, then by continued presence of the re-syncing member they ga= in the guarantee that at least one other group member has previously seen t= hat member, or else would have ejected them (assuming that the checker is o= nline). > I don't mean to over-rotate on this case, but software being software, we= need an algorithm to implement that covers all the cases. While the "every= one is new" scenario is outlandish, it wouldn't be all that surprising to h= ave one or two new members, so it's a case that would need addressing. The = seemingly most obvious approach to addressing this problem is to encrypt th= e PSK to new members, which requires you at least have enough state to figu= re out who the new members are. >=20 > It also occurs to me now that the PSK approach presumes that you know whe= n your state went bad, since you would want to use a PSK from before that p= oint. In Raphael's example where persistent storage is corrupted, all you k= now is that messages stopped decrypting, which gives you an upper bound on = the time of corruption, but not really a way to go back and figure out what= 's good. >=20 >=20 > > The security goal in the balance here is PCS. Adding a re-sync option o= f any of the varieties (2)-(4) would break that to some degree, since follo= wing a compromise and passive period the adversary is then enabled to regai= n a foothold. The question is how much of a degree of loss are we willing t= o tolerate.=20 >=20 > I'm not sure I would really characterize this as a PCS violation. PCS is = a guarantee that you get when you take a certain action. For example, when = a member issue an Update or a Commit with a fresh HPKE key pair, you should= get PCS with regard to that participant's HPKE key pair; likewise with rot= ating signature keys. Here, the signature key has not been rotated, so ther= e's no PCS boundary. >=20 > It is worth considering whether this mechanism gives the attacker any add= itional capabilities in the event that (1) the signature key is compromised= , and (2) the compromised member issues an Update or Commit rotating the si= gnature key. ISTM that you still get PCS there in option (3), since the req= uirement that the signature keys match ensures that the old, compromised si= gnature key is not allowed to resync back into the group. There's still a r= isk that the compromised key / credential could be used for a fresh, non-re= sync join, but that's an inherent risk with external Commit / freely joinab= le groups, and also an opportunity for the AS's revocation/invalidation sys= tem to help. >=20 > Will take a look at the remainder in the morning... >=20 > --RLB >=20 >=20 > > * I agree that (4) is an immediate discard. > > * Under (2) a PSK use, the PSK use at least more limited due to the p= roof of knowledge of a past state (e.g. notes above). This is a worthwhile = property to enforce in my view since it balances authentication across two = vectors: the signature key and knowledge of group state. Adversary access t= o only one or the other is insufficient for the adversary to eject Alice an= d replace her in the group.=20 > > * Under (3), the attack scenario of Eve compromising Alice (full stat= e + sig key), followed eventually* by removing Alice while adding herself, = is not dissimilar from the attack scenario of Eve compromising Alice full s= tate + sig key) followed eventually* by providing an impersonating update i= n Alice=E2=80=99s name. What has been shown so far is that this type of sce= nario can be limited by rotating signature keys. A important point that is = different in these scenarios is that under the first Alice knows she was re= moved (a plus) while under the second (currently possible) scenario the gro= up simply goes silent and Alice does not know if it was malicious or not. A= ll said, it could be worse. That does not consider other attack scenarios t= hough, for example when the attacker gains the signature key but not past s= tate/PSK.=20 > > =C2=A0 > > *I.e. after a potentially passive period, if we are to show how this be= haves in the PCS scenario. > > =C2=A0 > > This leads to an important question: does our current uniqueness of sig= key predicate limit the ability to rotate signature keys within a group? T= hat is our means of limiting the full state + sig key compromise scenario i= mpacts mentioned above, and therefore the means of limiting the drawbacks o= f (3). We should make sure that the limiting ability is feasible. If that h= indered in any way, then I would vote very strongly for (2) as it at least = bootstraps some of the authentication properties from the group state in th= e scenario that the sig key is compromised. > > =C2=A0 > > =C2=A0 > > All the best, > > =C2=A0 > > Britta > > =C2=A0 > > =C2=A0 > > =C2=A0 > > From:MLS on behalf of Richard Barnes > > Date:Monday, October 4, 2021 at 4:09 PM > > To:Messaging Layer Security WG > > Subject:[MLS] Resync archaeology + analysis + prognosis > > =C2=A0 > > OK, I think I have traced back some idea of why we removed the earlier = resync proposal. Here's a little essay on how we got here, a recap of the t= rade-offs, and my thoughts on where we should go. > > =C2=A0 > > tl;dr: Earlier decision not dispositive; we should do basically what's = in the PR now. > >=20 > > # History > > =20 > > The story starts all the way back at the January 2019 interim at Mozil= la / Mountain View. There was a discussion there of ACK/NACK and replay as = related issues [1]. That discussion seems to have led to agreement that a c= omplete error recovery system was a complex enough topic, and clearly enoug= h separated from the main protocol that it could be handled in a separate s= pecification. As a result, the issues that had been opened for ACK/NACK and= resync were closed [2][3]. When Britta and Konrad posted #336 [4] includin= g a resync mechanism, my review simply cited that earlier closed issue as a= reason for taking it out [5]. > > =20 > > One other note with regard to #336 -- It looks to me like the "resync"= mechanism in there was not really fleshed out enough to be implementable. = The state linked above was the last state before my review, and the word "r= esync" doesn't actually appear. Instead the PR talks about "recovering lost= group members" using Add and PSK, which could be elaborated to solve a ver= sion of this problem, but would require the assistance of a continuing memb= er rather than allowing the lost member to resync unilaterally. It would al= so have the same issues noted in terms of new joiners not having resync PSK= s. > > =20 > > Overall, though, reading this history doesn't seem to me like we reall= y made a principled decision not to do resync. We just punted after some di= scussion in the abstract, and that stuck. We have a more concrete question = now. > > =20 > > # Analysis > > =20 > > Since the discussion of #336 in 2020, we have added external commits i= n order to have groups you can join unilaterally. So regardless of the broa= der question of resync, we have to decide what proposals a joiner is allowe= d to originate in their Commit (sending them by value), in particular, whet= her an external Commit can contain a joiner-originated Remove proposal. We = have a spectrum of options here: > > =20 > > 1. Forbid Remove=20 > > 2. Allow Remove + require the (identity, endpoint_id) and signature ke= y to match the removed node + require resumption PSK > > 3. Allow Remove + require the (identity, endpoint_id) and signature ke= y to match the removed node > > 4. Allow Remove without restriction > > =20 > > Options (1) and (2) would block an attacker that has compromised a mem= ber's signature key from joining as that member and evicting the old appear= ance. Option (2) because of the PSK; option (1) because of the uniqueness r= equirements (as Raphael pointed out on the call). > > =20 > > Options (1) and (2) do not allow a client who has lost everything but = their signature key to resync. Option (1) would require a new endpoint_id a= nd signature key, which might not be feasible in all cases. Option (2) woul= d also need to have extra mechanism to account for recent joiners not havin= g the required resumption PSK. > > =20 > > Option (1) would also not allow for resync with just a signature key. = As Raphael pointed out, because we now require signature keys to be unique,= the member would have to mint a new signature key and get it authenticated= , or else their attempt to rejoin would be rejected as a duplicate entry. > > =20 > > Options (3) and (4) would allow a client who has lost everything but t= heir signature key to resync, at the risk that an attacker who has compromi= sed a member's signature key could abuse it to join as that member and evic= t the old, legitimate appearance. > > =20 > > # Prognosis > > =20 > > After this discussion and analysis, I continue to think that (3) above= is the right answer, with an optional upgade to (2). Proceeding by elimina= tion: > > =20 > > Option (4), while technically feasible, is clearly a little silly. The= re's no reason to allow joiners to do a remove in the same operation as the= y join; they could do this afterward. > > =20 > > Option (2) does not seem workable in general because of the recent-joi= ner problem. While mechanism could be designed to provide the PSK to recent= joiners, it would add a lot of complexity, and the recent joiners wouldn't= get any benefit from it, which dilutes the value of this mechanism. (It's = not impossible to arrive at the case where everyone besides the resync'ing = participant is new!)=20 > > =20 > > With option (1), you lose any notion of resync; I think the need for e= ndpoint_id rotation makes this unworkable in practice. And it has kind of a= n odd notion of security: You are protected against an attacker that has co= mpromised a current signature key but can't get a new one authenticated. Th= is is a problem for the authentication system to handle (e.g., with revocat= ion), not for the key exchange -- if you have valid credentials with compro= mised keys floating around, you have bigger problems to solve. So my person= al assessment is that (1) doesn't provide a big jump in security over (3), = assuming you have a functioning authentication system. > > =20 > > Two side notes about (3): First, if we do (3) but *allow* PSKs, then a= n application could opt in to (2). Second, this whole mechanism is opt-in f= or the application, since you can't do an external commit if a PublicGroupS= tate hasn't been published. > > =20 > > Concretely, my proposal here would be (3) + (2*) -- Allow Remove with = matching parameters, and allow PSKs so that applications can opt in to (2) = where they can make it work. That way, if an application opts in to externa= l Commits, they get the benefit of resync and the same signature-key-compro= mise bound on impersonation for resync as well as net-new joins. And if an = application can figure out how to make (2) work, they can require it. > > =20 > > Looking forward to others' thoughts here! > > =20 > > --RLB > > =20 > > =20 > > [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/mi= nutes.md#acks-and-nacks-jonm (https://nam10.safelinks.protection.outlook.co= m/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Fin= terim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=3D04%7C01%7Cbritta.ha= le%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578= 963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2BEprQ= MOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=3D0) > > [2] https://github.com/mlswg/mls-protocol/issues/92 (https://nam10.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls= -protocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30c= c44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898= 57931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ= BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoL= hzQ0fniz%2Fblmc%3D&reserved=3D0) > > [3] https://github.com/mlswg/mls-protocol/issues/93 (https://nam10.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls= -protocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30c= c44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898= 57931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ= BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz%2BeEwklYbp4NQmFcUeHBGm= Ah0jKBRC05CyVBs%3D&reserved=3D0) > > [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce0= 1dcedca7db2d05c57908a292202 (https://nam10.safelinks.protection.outlook.com= /?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffile= s%2F20145e49acce01dcedca7db2d05c57908a292202&data=3D04%7C01%7Cbritta.hale%4= 0nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f75789633= 78e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD= AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D0OgVddc%2BI= zju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=3D0) > > [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CF= SAE/ (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fm= ailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&dat= a=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d= 936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWF= pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C3000&sdata=3DmoUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved= =3D0) From nobody Wed Oct 6 08:20:13 2021 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 AF80C3A1D8B for ; Wed, 6 Oct 2021 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 5c5qoDCHpBQx for ; Wed, 6 Oct 2021 08:20:01 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 DE5753A1D88 for ; Wed, 6 Oct 2021 08:20:01 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id qe4-20020a17090b4f8400b0019f663cfcd1so4705919pjb.1 for ; Wed, 06 Oct 2021 08:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Z4IDpfBQ10eKti/QiBKPGkPvChT0PuhpT99OrZIA0w=; b=maOYfXrELb8do5/ZAWSblOycReWQ6iVPguf4rO7TFXYIkDx/3XPbScCRHRMc8WLM0b mtVnvSXhOK2E8QYzr5nHW8tzhNrOA1wA1V6Dz4VLntyIcog51Qr4I0nJntaybipMFKdl 3KCtpn5R7vm0G5VsDZTayvQiPj2Y6KuVONjCVrpbvEY2afZ0C4u6EF8grhwQBlvvs9i5 Q/0mbp6S2kdn/aTkaDuKV9IcWGxBJ0FdUGHk6I2vpr7mvm6QwBUsGA7u+ixwZFdZLLuY aImhgWeTR93HCwjZ8Nfr9dEYMwuypqUjJhoK1iS/ELxp4X2coIPvwyxNTMlyuSksSNq2 pnpQ== 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=3Z4IDpfBQ10eKti/QiBKPGkPvChT0PuhpT99OrZIA0w=; b=pkIc5xQYmAi1glG/qqLgi8jG02qEbhq8W+VqwuVyw7G894VX8X316qSR2MGEWzjpZP Qu48n46WiHsKyc/7aHAH2dXrt+3JrZr5O2E49YYYbDfoIT98V+A6vqwwXPjUQpvYuUco OGUyzLSgNJ7fY86X+yDIWJwlQ6AZAPHmDyfLFlHX09A5830iUzn2sUxAYRv/C0G/FtuZ rUgEpjKMzpveBhU9v9SejDwWFe7GG26QT5M15Vb5xaLkZCPKpVZfLLs5ijqwTdJnVoWo RDlrOPUiUs2B2vQgkHu7QOF11WICGOkaIBq0MfVpJCMvDxf9RIzTEVaFDFUz0gsrOEdj v2GA== X-Gm-Message-State: AOAM530nizzv1/VVLrcJQgOniAqqO9moVg8RbIZ9aNsSSkkYdDn/tOTB P6ZG329zoypYMOtVVEOVaTbsf2qyUNIoHko09UIiIQhQIEfzBbWb X-Google-Smtp-Source: ABdhPJxT6WqMpExUu115TfZ56tyCkz6cOE1z0YfWTM+W6UQqEIKufwdOtPw0iiD7ku8CV74jKw7HrKv+21LQD37BaSI= X-Received: by 2002:a17:902:7b85:b0:13d:cdc4:9531 with SMTP id w5-20020a1709027b8500b0013dcdc49531mr11651684pll.27.1633533601126; Wed, 06 Oct 2021 08:20:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rohan Mahy Date: Wed, 6 Oct 2021 08:19:50 -0700 Message-ID: To: Richard Barnes Cc: Dave Cridland , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000006338a05cdb0ae5d" Archived-At: Subject: Re: [MLS] solution to getting in a Commit fairly in a busy group X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 15:20:10 -0000 --00000000000006338a05cdb0ae5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Richard Barnes said: > What I'm saying is just that you could put the sequence number in whateve= r > framing you're using to send around MLS messages, and not touch the MLS a= t > all. > Yes, but then the sequence number is not synchronized to the state of the MLS group, which would cause timing/ordering problems for my proposal (and would also not be e2e authenticated). > Just to be clear about one aspect of this proposed solution: Consider the > case where a client receives CommitB with a higher sequence number, then > CommitA shows up. You might think that the client could apply CommitA, > then CommitB. That is not necessarily the case -- Commits are ordered > because they depend on the state established by the previous commit. If > both CommitB and CommitA were generated from the same epoch, they are in > conflict; the client would have to throw away CommitB instead of applying > it. > agreed > In general, there are kind of two broad classes of solution here that > people tend to come to: > 1. Locking: Designating one member is the only authorized committer for > some period of time > Yes. While you could think of this as a "soft-lock". It is specifically a precondition. Like HTTP Etags/If-Unmodified-Since/412 Precondition Failed behavior. Commit B has a precondition of no outstanding reserved Commits. Out of band you can request a commit sequence number from the delivery service. The delivery service would reply with the requested sequence number, its expiration time (ex: 30 seconds), and (if not yet expired) the expiration time of the previous sequence number issued. The delivery service would presumably have a policy to limit excessive simultaneous commit sequence number requests (by rate and number). Inside the group, an MLS client would have to wait for either a Commit using the previous sequence number, or the expiration time of that previous sequence number, whichever comes first, before issuing a Commit (which would include the newly requested sequence number). If we were worried about cheating, the sequence number could be a token for the requesting client, signed by the delivery service. 2. Tie-breakers: Queuing up Commits over some time period, and applying the > one that wins according to some tie-breaking function > Not what I was proposing. Again, this is something we can add later as an extension, now that we have required extensions. 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 On Mon, Oct 4, 2021 at 10:22 AM Richard Barnes wrote: > On Mon, Oct 4, 2021 at 11:58 AM Rohan Mahy wrote: > >> Hi Richard, >> >>> On the more general question: I don't think this is really a problem fo= r >>> the MLS protocol to solve, but rather a question of DS design / MLS >>> orchestration. As long as you have a centralized DS, it's pretty >>> straightforward to have the DS enforce some notion of fairness. For >>> example, in the Webex implementation, all Commits are generated by one >>> "leader" (with other participants generating only requests to join or >>> leave), which makes them non-rivalrous except for leader transitions. = You >>> could also have the DS implement a locking scheme of the type you descr= ibe, >>> but there's not really any need to tie that into the crypto protocol. >>> >> >> The relatively light-weight solution of DS orchestration I proposed, >> still required a place to put the "commit sequence number" inside MLS so >> all the clients could see it. To be clear, I think this would be an MLS >> extension and not part of the core protocol. >> > > What I'm saying is just that you could put the sequence number in whateve= r > framing you're using to send around MLS messages, and not touch the MLS a= t > all. > > Just to be clear about one aspect of this proposed solution: Consider the > case where a client receives CommitB with a higher sequence number, then > CommitA shows up. You might think that the client could apply CommitA, > then CommitB. That is not necessarily the case -- Commits are ordered > because they depend on the state established by the previous commit. If > both CommitB and CommitA were generated from the same epoch, they are in > conflict; the client would have to throw away CommitB instead of applying > it. > > In general, there are kind of two broad classes of solution here that > people tend to come to: > 1. Locking: Designating one member is the only authorized committer for > some period of time > 2. Tie-breakers: Queuing up Commits over some time period, and applying > the one that wins according to some tie-breaking function > > Your proposal is in the "tie-breaker" bucket, with "lowest sequence > number" as the tie-breaker. (You could also just do something like > "leftmost in the tree" or "smallest u64 derived from H(epoch || leaf > index)") Webex is in the "locking" bucket, with the leader holding the > lock. The two approaches have kind of complementary sets of trade-offs. > > --RLB > > >> 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 >> >> >> On Mon, Oct 4, 2021 at 6:50 AM Richard Barnes wrote: >> >>> To Dave's question: No, that's not possible, at least not as you >>> describe it. Any Commit causes the key schedule to move forward, so if= a >>> malicious client uses their Commits to block others' commits, they woul= d >>> still be ratcheting the key schedule forward. That's not to say that t= hey >>> don't have other objectives that would be accomplished that way, e.g., >>> preventing themselves being evicted by another participant. >>> >>> On the more general question: I don't think this is really a problem fo= r >>> the MLS protocol to solve, but rather a question of DS design / MLS >>> orchestration. As long as you have a centralized DS, it's pretty >>> straightforward to have the DS enforce some notion of fairness. For >>> example, in the Webex implementation, all Commits are generated by one >>> "leader" (with other participants generating only requests to join or >>> leave), which makes them non-rivalrous except for leader transitions. = You >>> could also have the DS implement a locking scheme of the type you descr= ibe, >>> but there's not really any need to tie that into the crypto protocol. >>> >>> If you were going to do something integrated with MLS, ISTM you would >>> basically want to tunnel some Byzantine fault-tolerant consensus protoc= ol >>> in Proposals (Paxos, Raft, etc.), using some Proposals designed for thi= s >>> purpose. But this would be a pretty complex extension. >>> >>> --RLB >>> >>> On Mon, Oct 4, 2021 at 9:21 AM Dave Cridland wrote: >>> >>>> >>>> >>>> On Mon, 4 Oct 2021 at 13:28, Rohan Mahy >>> 40wire.com@dmarc.ietf.org> wrote: >>>> >>>>> The protocol document describes a situation in large groups with >>>>> frequent adds and joins where a client (especially over a high latenc= y >>>>> connection) may be trying to issue a Commit, but other clients keep g= etting >>>>> their Commits in first. I think this could potentially yield unpredic= table >>>>> behavior. >>>>> >>>> >>>> Out of curiosity, could a malicious (or at least annoyingly contrary) >>>> client issue spurious commits to deliberately cause other clients' com= mits >>>> to fail, forcing them to (for example) continue using existing keying >>>> material? >>>> >>>> Dave. >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>> --00000000000006338a05cdb0ae5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard Barnes said:
What I'm saying is ju= st that you could put the sequence number in=20 whatever framing you're using to send around MLS messages, and not touc= h the MLS at all.
Yes, but then the sequence nu= mber is not synchronized to the state of the MLS group, which would cause t= iming/ordering problems for my proposal (and would also not be e2e authenti= cated).
=C2=A0
Just to be clear about one=20 aspect of this proposed solution: Consider the case where a client=20 receives CommitB with a higher sequence number, then CommitA shows up.=C2= =A0=20 You might think that the client could apply CommitA, then CommitB.=C2=A0 Th= at is not necessarily the case -- Commits are ordered because they depend=20 on the state established by the previous commit.=C2=A0 If both CommitB and= =20 CommitA were generated from the same epoch, they are in conflict; the=20 client would have to throw away CommitB instead of applying it.
agreed
=C2=A0
In general, = there are kind of two broad classes of solution here that people tend to co= me to:
1. Locking: Designating one member is the only authori= zed committer for some period of time
Yes.= While you could think of this as a "soft-lock". It is specifical= ly a precondition. Like HTTP Etags/If-Unmodified-Since/412 Precondition Fai= led behavior. Commit B has a precondition of no outstanding reserved Commit= s.

Out of band you can request a commit sequen= ce number from the delivery service. The delivery service would reply with = the requested sequence number, its expiration time (ex: 30 seconds), and (i= f not yet expired) the expiration time of the previous sequence number issu= ed. The delivery service would presumably have a policy to limit excessive = simultaneous commit sequence number requests (by rate and number).

Inside the group, an MLS client would have to wait for eit= her a Commit using the previous sequence number, or the expiration time of = that previous sequence number, whichever comes first, before issuing a Comm= it (which would include the newly requested sequence number).

If we= were worried about cheating, the sequence number could be a token for the = requesting client, signed by the delivery service.=C2=A0
<= div>
2. Tie-breakers: Queuing up Commits over some time period, and applying=20 the one that wins according to some tie-breaking function
Not what I was proposing.

Again, this = is something we can add later as an extension, now that we have required ex= tensions.

Thanks,
-rohan

Rohan Mahy=C2=A0 l=C2=A0 Vice President Engineering, Archi= tecture

Cha= t: @rohan_wire on=C2=A0Wire

= =C2=A0

Wire=C2=A0- Secure team messaging.

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

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

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE2= 88748675



On Mon, Oct 4, = 2021 at 10:22 AM Richard Barnes <rlb@ipv.s= x> wrote:
On Mon, Oct 4, 2021 at 11:58 AM Rohan Ma= hy <rohan.mahy@= wire.com> wrote:
Hi Richard,
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On the more general q= uestion: I don't think this is really a problem for the MLS protocol to solve, but rather a question of DS design / MLS=20 orchestration.=C2=A0 As long as you have a centralized DS, it's pretty= =20 straightforward to have the DS enforce some notion of fairness.=C2=A0 For= =20 example, in the Webex implementation, all Commits are generated by one=20 "leader" (with other participants generating only requests to joi= n or=20 leave), which makes them non-rivalrous except for leader transitions.=C2=A0= =20 You could also have the DS implement a locking scheme of the type you=20 describe, but there's not really any need to tie that into the crypto= =20 protocol.

The relatively light-weight= solution of DS orchestration I proposed, still required a place to put the= "commit sequence number" inside MLS so all the clients could see= it. To be clear, I think this would be an MLS extension and not part of th= e core protocol.

What I'm s= aying is just that you could put the sequence number in whatever framing yo= u're using to send around MLS messages, and not touch the MLS at all.

Just to be clear about one aspect of this proposed = solution: Consider the case where a client receives CommitB with a higher s= equence number, then CommitA shows up.=C2=A0 You might think that the clien= t could apply CommitA, then CommitB.=C2=A0 That is not necessarily the case= -- Commits are ordered because they depend on the state established by the= previous commit.=C2=A0 If both CommitB and CommitA were generated from the= same epoch, they are in conflict; the client would have to throw away Comm= itB instead of applying it.

In general, there = are kind of two broad classes of solution here that people tend to come to:=
1. Locking: Designating one member is the only authorized co= mmitter for some period of time
2. Tie-breakers: Queuing up C= ommits over some time period, and applying the one that wins according to s= ome tie-breaking function
=C2=A0
Your proposal is i= n the "tie-breaker" bucket, with "lowest sequence number&quo= t; as the tie-breaker.=C2=A0 (You could also just do something like "l= eftmost in the tree" or "smallest u64 derived from H(epoch || lea= f index)")=C2=A0 Webex is in the "locking" bucket, with the = leader holding the lock.=C2=A0 The two approaches have kind of complementar= y sets of trade-offs.

--RLB

=

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 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

HRB 14984= 7 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675=



On Mon, Oct 4, 2021 at 6= :50 AM Richard Barnes <r= lb@ipv.sx> wrote:
To Dave's question: No, that's not= possible, at least not as you describe it.=C2=A0 Any Commit causes the key= schedule to move forward, so if a malicious client uses their Commits to b= lock others' commits, they would still be ratcheting the key schedule f= orward.=C2=A0 That's not to say that they don't have other objectiv= es that would be accomplished that way, e.g., preventing themselves being e= victed by another participant.

On the more gen= eral question: I don't think this is really a problem for the MLS proto= col to solve, but rather a question of DS design / MLS orchestration.=C2=A0= As long as you have a centralized DS, it's pretty straightforward to h= ave the DS enforce some notion of fairness.=C2=A0 For example, in the Webex= implementation, all Commits are generated by one "leader" (with = other participants generating only requests to join or leave), which makes = them non-rivalrous except for leader transitions.=C2=A0 You could also have= the DS implement a locking scheme of the type you describe, but there'= s not really any need to tie that into the crypto protocol.

<= /div>
If you were going to do something integrated with MLS, ISTM you w= ould basically want to tunnel some Byzantine fault-tolerant consensus proto= col in Proposals (Paxos, Raft, etc.), using some Proposals designed for thi= s purpose.=C2=A0 But this would be a pretty complex extension.

--RLB

On Mon, Oct 4, 2021 at 9:21 AM Dave Cridlan= d <dave@cridland.= net> wrote:


On Mon, 4 Oct 2021 at 13:28, Rohan= Mahy <rohan.mahy=3D40wire.com@dmarc.ietf.org> wrote:
The protocol doc= ument describes a situation in large groups with frequent adds and joins wh= ere a client (especially over a high latency connection) may be trying to i= ssue a Commit, but other clients keep getting their Commits in first. I thi= nk this could potentially yield unpredictable behavior.

Out of curiosity, could a malicious (or at least a= nnoyingly contrary) client issue spurious commits to deliberately cause oth= er clients' commits to fail, forcing them to (for example) continue usi= ng existing keying material?

Dave.
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000006338a05cdb0ae5d-- From nobody Wed Oct 6 08:55:59 2021 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 A847F3A1E72 for ; Wed, 6 Oct 2021 08:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 MJvJCkIuhaLd for ; Wed, 6 Oct 2021 08:55:52 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042883A1E6E for ; Wed, 6 Oct 2021 08:55:51 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id p4so2970829qki.3 for ; Wed, 06 Oct 2021 08:55:51 -0700 (PDT) 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=rkcEYvs6BZW5tKK4GHXNxH8pmee5HmjMFVILy5Zo648=; b=chrmyPE6GAPmtY6b/g9v5Pd5vkLCs9i8tLKELGbeijoZINZ2+vN1inC3D//+8kp2JH lMxP2mWksP71HXJ0s0Vyy8YiIDUpSh7f9i8nbQkjzTOqNRwI13dVT87KnIE/6ps1aVQm o4q1jLJ/UCrywQQGrLk2oqbktsuw6RBTII+sSxmTO9isha3clG2vXYYKQMpVTWG+xSm7 ZVyeSnLtoeq8NZf4kO7yqIK6QofpPrbnQRvyW48KFe3I0hBBU4+3fNRw6HMqz6PF9W+Z 15zT7neXVjrF59NNKl7O8w8e7qkNFmfDvGLsNiqik2WS7GyM6ZeLJhlpNzMQLC1WWVqN tCZg== 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=rkcEYvs6BZW5tKK4GHXNxH8pmee5HmjMFVILy5Zo648=; b=MQSG4So3e+4LEhS933z/iRAKotglpmHlTgKP6TepmhX7Z7mDbeIK9w1XPNW4CGLz1x 8be6JmPH/kzZLpHX/BC5Rf70YhkgjySlfWUUW7aDi7aTOLeHECdiN0uJWe6oy4/dg1hY w0U7FY8d+74x4g7rmPi5UMODIm70+xiBL6dU2eZrzpsyd8puIZY9jKpFK+tndHsWmqqz 6mO2zov4Vj3jSm/Gxg/1Pv1gdYPBa0O/mUYAx3fOErUTCCjT/xO0z2iSfE1GSjmx52AS kppWY1wRjYFcJ/GwDCNztAE9gHewAch1ylWLLm9G8s5m82ZJxjBL6EXsSGyOvvXnWykS naYw== X-Gm-Message-State: AOAM532wgCJ8DMnLLxuoBv47RhGhv8z3V9eWz839kfvM/alwQY/lLx6n AuQKKRbUiIN2OHo3fIHTo36f2j1kPnM8Y5pQHZ8ATw== X-Google-Smtp-Source: ABdhPJyspX6ipR8xcQiSzLvIPUxYoShTiKtDXj60QEvmYYS0gy56Phoo/xt0knIoeT65ihgcj56btSvqoSUMoE0jo38= X-Received: by 2002:a37:63c2:: with SMTP id x185mr6788867qkb.223.1633535749673; Wed, 06 Oct 2021 08:55:49 -0700 (PDT) MIME-Version: 1.0 References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> <1698663123.17469.1633500322380@office.mailbox.org> In-Reply-To: <1698663123.17469.1633500322380@office.mailbox.org> From: Richard Barnes Date: Wed, 6 Oct 2021 11:55:38 -0400 Message-ID: To: Konrad Kohbrok Cc: "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000001665fd05cdb12eff" Archived-At: Subject: Re: [MLS] Resync archaeology + analysis + prognosis X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 15:55:58 -0000 --0000000000001665fd05cdb12eff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've updated the PR to do basically what Konrad proposes. Namely, allow Remove, but suggest that applications can apply additional constraints. https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746a7= e70cd2884037896defe03b3098bec976f79c994d22a604aR2873 Britta, does that work for you? On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok wrote: > Hi, > > If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 > for now) represent trade-offs in security guarantees and their > applicability depends on the specific deployment scenario. My understandi= ng > is that external joins will be subject to some sort of policy anyway. > Should we then be strict in the spec in terms of what we mandate the exac= t > policy w.r.t. PSKs is? > > Since I don't think either solution represents much of a foot-gun, I > propose we include the capability to include resync PSKs in the spec for > this purpose, but don't mandate them. Instead we relegate the policy > decision to the application layer and detail the security trade-offs in t= he > architecture document. I realize that delegating decisions to the > application layer is a bit of a cop-out solution, but I think in this cas= e > it makes sense to include the mechanism in the spec and then let the > application decide. > > Cheers, > Konrad > > > Richard Barnes hat am 05.10.2021 04:31 geschrieben: > > > > > > Hi Britta, > > > > Couple of responses inline... > > > > > > On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) > wrote: > > > [trimmed] > > > > > > To the present proposed options, I will note that the =E2=80=98new jo= iners in > interim=E2=80=99 case is likely a misleading focus point for the discussi= on, and we > should avoid tripping into that ditch for a number of reasons: > > > * Notably, if everyone except for the re-syncing participant is new= , > why not just require the re-syncing participant to be added as a new memb= er > themselves? It is, after all, practically a brand new group at that point= . > > > * It is true that a new member would not gain from a PSK guarantee, > but why should we reduce the guarantees for all other participants to tha= t > of the new joiner? From the view of the new joiner, all participants are > new in any case, so e.g. PCS does not have substantial meaning as of yet. > Existing members have more to lose and also have the more to gain from PS= K > use. I do not believe we want to adapt a stance of =E2=80=98if the new jo= iner > doesn=E2=80=99t get a security guarantee, no one should have the security > guarantee=E2=80=99 =E2=80=93 in fact, the tree structure, commit history,= and the like > provide insight to longer term members that a new joiner does not have. S= o > (2) offers a new joiner the benefits of (3) but to all others an even > stronger guarantee. > > > * As a nod to what a new joiner may gain, we can offer the > following: if a re-sync PSK fails, then whichever existing member checks > and notes the PSK failure should initiate a removal of the resyncing > member. If there is a new joiner, then by continued presence of the > re-syncing member they gain the guarantee that at least one other group > member has previously seen that member, or else would have ejected them > (assuming that the checker is online). > > I don't mean to over-rotate on this case, but software being software, > we need an algorithm to implement that covers all the cases. While the > "everyone is new" scenario is outlandish, it wouldn't be all that > surprising to have one or two new members, so it's a case that would need > addressing. The seemingly most obvious approach to addressing this proble= m > is to encrypt the PSK to new members, which requires you at least have > enough state to figure out who the new members are. > > > > It also occurs to me now that the PSK approach presumes that you know > when your state went bad, since you would want to use a PSK from before > that point. In Raphael's example where persistent storage is corrupted, a= ll > you know is that messages stopped decrypting, which gives you an upper > bound on the time of corruption, but not really a way to go back and figu= re > out what's good. > > > > > > > The security goal in the balance here is PCS. Adding a re-sync option > of any of the varieties (2)-(4) would break that to some degree, since > following a compromise and passive period the adversary is then enabled t= o > regain a foothold. The question is how much of a degree of loss are we > willing to tolerate. > > > > I'm not sure I would really characterize this as a PCS violation. PCS i= s > a guarantee that you get when you take a certain action. For example, whe= n > a member issue an Update or a Commit with a fresh HPKE key pair, you shou= ld > get PCS with regard to that participant's HPKE key pair; likewise with > rotating signature keys. Here, the signature key has not been rotated, so > there's no PCS boundary. > > > > It is worth considering whether this mechanism gives the attacker any > additional capabilities in the event that (1) the signature key is > compromised, and (2) the compromised member issues an Update or Commit > rotating the signature key. ISTM that you still get PCS there in option > (3), since the requirement that the signature keys match ensures that the > old, compromised signature key is not allowed to resync back into the > group. There's still a risk that the compromised key / credential could b= e > used for a fresh, non-resync join, but that's an inherent risk with > external Commit / freely joinable groups, and also an opportunity for the > AS's revocation/invalidation system to help. > > > > Will take a look at the remainder in the morning... > > > > --RLB > > > > > > > * I agree that (4) is an immediate discard. > > > * Under (2) a PSK use, the PSK use at least more limited due to the > proof of knowledge of a past state (e.g. notes above). This is a worthwhi= le > property to enforce in my view since it balances authentication across tw= o > vectors: the signature key and knowledge of group state. Adversary access > to only one or the other is insufficient for the adversary to eject Alice > and replace her in the group. > > > * Under (3), the attack scenario of Eve compromising Alice (full > state + sig key), followed eventually* by removing Alice while adding > herself, is not dissimilar from the attack scenario of Eve compromising > Alice full state + sig key) followed eventually* by providing an > impersonating update in Alice=E2=80=99s name. What has been shown so far = is that > this type of scenario can be limited by rotating signature keys. A > important point that is different in these scenarios is that under the > first Alice knows she was removed (a plus) while under the second > (currently possible) scenario the group simply goes silent and Alice does > not know if it was malicious or not. All said, it could be worse. That do= es > not consider other attack scenarios though, for example when the attacker > gains the signature key but not past state/PSK. > > > > > > *I.e. after a potentially passive period, if we are to show how this > behaves in the PCS scenario. > > > > > > This leads to an important question: does our current uniqueness of > sig key predicate limit the ability to rotate signature keys within a > group? That is our means of limiting the full state + sig key compromise > scenario impacts mentioned above, and therefore the means of limiting the > drawbacks of (3). We should make sure that the limiting ability is > feasible. If that hindered in any way, then I would vote very strongly fo= r > (2) as it at least bootstraps some of the authentication properties from > the group state in the scenario that the sig key is compromised. > > > > > > > > > All the best, > > > > > > Britta > > > > > > > > > > > > From:MLS on behalf of Richard Barnes < > rlb@ipv.sx> > > > Date:Monday, October 4, 2021 at 4:09 PM > > > To:Messaging Layer Security WG > > > Subject:[MLS] Resync archaeology + analysis + prognosis > > > > > > OK, I think I have traced back some idea of why we removed the earlie= r > resync proposal. Here's a little essay on how we got here, a recap of the > trade-offs, and my thoughts on where we should go. > > > > > > tl;dr: Earlier decision not dispositive; we should do basically what'= s > in the PR now. > > > > > > # History > > > > > > The story starts all the way back at the January 2019 interim at > Mozilla / Mountain View. There was a discussion there of ACK/NACK and > replay as related issues [1]. That discussion seems to have led to > agreement that a complete error recovery system was a complex enough topi= c, > and clearly enough separated from the main protocol that it could be > handled in a separate specification. As a result, the issues that had bee= n > opened for ACK/NACK and resync were closed [2][3]. When Britta and Konrad > posted #336 [4] including a resync mechanism, my review simply cited that > earlier closed issue as a reason for taking it out [5]. > > > > > > One other note with regard to #336 -- It looks to me like the > "resync" mechanism in there was not really fleshed out enough to be > implementable. The state linked above was the last state before my review= , > and the word "resync" doesn't actually appear. Instead the PR talks about > "recovering lost group members" using Add and PSK, which could be > elaborated to solve a version of this problem, but would require the > assistance of a continuing member rather than allowing the lost member to > resync unilaterally. It would also have the same issues noted in terms of > new joiners not having resync PSKs. > > > > > > Overall, though, reading this history doesn't seem to me like we > really made a principled decision not to do resync. We just punted after > some discussion in the abstract, and that stuck. We have a more concrete > question now. > > > > > > # Analysis > > > > > > Since the discussion of #336 in 2020, we have added external commits > in order to have groups you can join unilaterally. So regardless of the > broader question of resync, we have to decide what proposals a joiner is > allowed to originate in their Commit (sending them by value), in > particular, whether an external Commit can contain a joiner-originated > Remove proposal. We have a spectrum of options here: > > > > > > 1. Forbid Remove > > > 2. Allow Remove + require the (identity, endpoint_id) and signature > key to match the removed node + require resumption PSK > > > 3. Allow Remove + require the (identity, endpoint_id) and signature > key to match the removed node > > > 4. Allow Remove without restriction > > > > > > Options (1) and (2) would block an attacker that has compromised a > member's signature key from joining as that member and evicting the old > appearance. Option (2) because of the PSK; option (1) because of the > uniqueness requirements (as Raphael pointed out on the call). > > > > > > Options (1) and (2) do not allow a client who has lost everything bu= t > their signature key to resync. Option (1) would require a new endpoint_id > and signature key, which might not be feasible in all cases. Option (2) > would also need to have extra mechanism to account for recent joiners not > having the required resumption PSK. > > > > > > Option (1) would also not allow for resync with just a signature key= . > As Raphael pointed out, because we now require signature keys to be uniqu= e, > the member would have to mint a new signature key and get it authenticate= d, > or else their attempt to rejoin would be rejected as a duplicate entry. > > > > > > Options (3) and (4) would allow a client who has lost everything but > their signature key to resync, at the risk that an attacker who has > compromised a member's signature key could abuse it to join as that membe= r > and evict the old, legitimate appearance. > > > > > > # Prognosis > > > > > > After this discussion and analysis, I continue to think that (3) > above is the right answer, with an optional upgade to (2). Proceeding by > elimination: > > > > > > Option (4), while technically feasible, is clearly a little silly. > There's no reason to allow joiners to do a remove in the same operation a= s > they join; they could do this afterward. > > > > > > Option (2) does not seem workable in general because of the > recent-joiner problem. While mechanism could be designed to provide the P= SK > to recent joiners, it would add a lot of complexity, and the recent joine= rs > wouldn't get any benefit from it, which dilutes the value of this > mechanism. (It's not impossible to arrive at the case where everyone > besides the resync'ing participant is new!) > > > > > > With option (1), you lose any notion of resync; I think the need for > endpoint_id rotation makes this unworkable in practice. And it has kind o= f > an odd notion of security: You are protected against an attacker that has > compromised a current signature key but can't get a new one authenticated= . > This is a problem for the authentication system to handle (e.g., with > revocation), not for the key exchange -- if you have valid credentials wi= th > compromised keys floating around, you have bigger problems to solve. So m= y > personal assessment is that (1) doesn't provide a big jump in security ov= er > (3), assuming you have a functioning authentication system. > > > > > > Two side notes about (3): First, if we do (3) but *allow* PSKs, then > an application could opt in to (2). Second, this whole mechanism is opt-i= n > for the application, since you can't do an external commit if a > PublicGroupState hasn't been published. > > > > > > Concretely, my proposal here would be (3) + (2*) -- Allow Remove wit= h > matching parameters, and allow PSKs so that applications can opt in to (2= ) > where they can make it work. That way, if an application opts in to > external Commits, they get the benefit of resync and the same > signature-key-compromise bound on impersonation for resync as well as > net-new joins. And if an application can figure out how to make (2) work, > they can require it. > > > > > > Looking forward to others' thoughts here! > > > > > > --RLB > > > > > > > > > [1] > https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.m= d#acks-and-nacks-jonm > ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%2= 3acks-and-nacks-jonm&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44= fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898579= 31844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi= I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6t= CFvcAM3uopMFq4%3D&reserved=3D0 > ) > > > [2] https://github.com/mlswg/mls-protocol/issues/92 ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40n= ps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378= e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCGZlsH= z%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=3D0 > ) > > > [3] https://github.com/mlswg/mls-protocol/issues/93 ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40n= ps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378= e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz%2Be= EwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=3D0 > ) > > > [4] > https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca= 7db2d05c57908a292202 > ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db= 2d05c57908a292202&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc9= 6e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898579318= 64794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I= k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08C= kIgGm%2BQ%3D&reserved=3D0 > ) > > > [5] > https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmaila= rchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=3D= 04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d9362= 31a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3= 000&sdata=3DmoUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=3D0 > ) > --0000000000001665fd05cdb12eff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've updated the PR to do basically what Konrad p= roposes.=C2=A0 Namely, allow Remove, but suggest that applications can appl= y additional constraints.


Britta, does that work for = you?

On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok <konrad.kohbrok@datashrine.de> wrote= :
Hi,

If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 fo= r now) represent trade-offs in security guarantees and their applicability = depends on the specific deployment scenario. My understanding is that exter= nal joins will be subject to some sort of policy anyway. Should we then be = strict in the spec in terms of what we mandate the exact policy w.r.t. PSKs= is?

Since I don't think either solution represents much of a foot-gun, I pr= opose we include the capability to include resync PSKs in the spec for this= purpose, but don't mandate them. Instead we relegate the policy decisi= on to the application layer and detail the security trade-offs in the archi= tecture document. I realize that delegating decisions to the application la= yer is a bit of a cop-out solution, but I think in this case it makes sense= to include the mechanism in the spec and then let the application decide.<= br>
Cheers,
Konrad

> Richard Barnes <rlb= @ipv.sx> hat am 05.10.2021 04:31 geschrieben:
>
>
> Hi Britta,
>
> Couple of responses inline...
>
>
> On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:=
> > [trimmed]
> > =C2=A0
> > To the present proposed options, I will note that the =E2=80=98ne= w joiners in interim=E2=80=99 case is likely a misleading focus point for t= he discussion, and we should avoid tripping into that ditch for a number of= reasons:
> >=C2=A0 =C2=A0* Notably, if everyone except for the re-syncing part= icipant is new, why not just require the re-syncing participant to be added= as a new member themselves? It is, after all, practically a brand new grou= p at that point.
> >=C2=A0 =C2=A0* It is true that a new member would not gain from a = PSK guarantee, but why should we reduce the guarantees for all other partic= ipants to that of the new joiner? From the view of the new joiner, all part= icipants are new in any case, so e.g. PCS does not have substantial meaning= as of yet. Existing members have more to lose and also have the more to ga= in from PSK use. I do not believe we want to adapt a stance of =E2=80=98if = the new joiner doesn=E2=80=99t get a security guarantee, no one should have= the security guarantee=E2=80=99 =E2=80=93 in fact, the tree structure, com= mit history, and the like provide insight to longer term members that a new= joiner does not have. So (2) offers a new joiner the benefits of (3) but t= o all others an even stronger guarantee.
> >=C2=A0 =C2=A0* As a nod to what a new joiner may gain, we can offe= r the following: if a re-sync PSK fails, then whichever existing member che= cks and notes the PSK failure should initiate a removal of the resyncing me= mber. If there is a new joiner, then by continued presence of the re-syncin= g member they gain the guarantee that at least one other group member has p= reviously seen that member, or else would have ejected them (assuming that = the checker is online).
> I don't mean to over-rotate on this case, but software being softw= are, we need an algorithm to implement that covers all the cases. While the= "everyone is new" scenario is outlandish, it wouldn't be all= that surprising to have one or two new members, so it's a case that wo= uld need addressing. The seemingly most obvious approach to addressing this= problem is to encrypt the PSK to new members, which requires you at least = have enough state to figure out who the new members are.
>
> It also occurs to me now that the PSK approach presumes that you know = when your state went bad, since you would want to use a PSK from before tha= t point. In Raphael's example where persistent storage is corrupted, al= l you know is that messages stopped decrypting, which gives you an upper bo= und on the time of corruption, but not really a way to go back and figure o= ut what's good.
>
>
> > The security goal in the balance here is PCS. Adding a re-sync op= tion of any of the varieties (2)-(4) would break that to some degree, since= following a compromise and passive period the adversary is then enabled to= regain a foothold. The question is how much of a degree of loss are we wil= ling to tolerate.
>
> I'm not sure I would really characterize this as a PCS violation. = PCS is a guarantee that you get when you take a certain action. For example= , when a member issue an Update or a Commit with a fresh HPKE key pair, you= should get PCS with regard to that participant's HPKE key pair; likewi= se with rotating signature keys. Here, the signature key has not been rotat= ed, so there's no PCS boundary.
>
> It is worth considering whether this mechanism gives the attacker any = additional capabilities in the event that (1) the signature key is compromi= sed, and (2) the compromised member issues an Update or Commit rotating the= signature key. ISTM that you still get PCS there in option (3), since the = requirement that the signature keys match ensures that the old, compromised= signature key is not allowed to resync back into the group. There's st= ill a risk that the compromised key / credential could be used for a fresh,= non-resync join, but that's an inherent risk with external Commit / fr= eely joinable groups, and also an opportunity for the AS's revocation/i= nvalidation system to help.
>
> Will take a look at the remainder in the morning...
>
> --RLB
>
>
> >=C2=A0 =C2=A0* I agree that (4) is an immediate discard.
> >=C2=A0 =C2=A0* Under (2) a PSK use, the PSK use at least more limi= ted due to the proof of knowledge of a past state (e.g. notes above). This = is a worthwhile property to enforce in my view since it balances authentica= tion across two vectors: the signature key and knowledge of group state. Ad= versary access to only one or the other is insufficient for the adversary t= o eject Alice and replace her in the group.
> >=C2=A0 =C2=A0* Under (3), the attack scenario of Eve compromising = Alice (full state + sig key), followed eventually* by removing Alice while = adding herself, is not dissimilar from the attack scenario of Eve compromis= ing Alice full state + sig key) followed eventually* by providing an impers= onating update in Alice=E2=80=99s name. What has been shown so far is that = this type of scenario can be limited by rotating signature keys. A importan= t point that is different in these scenarios is that under the first Alice = knows she was removed (a plus) while under the second (currently possible) = scenario the group simply goes silent and Alice does not know if it was mal= icious or not. All said, it could be worse. That does not consider other at= tack scenarios though, for example when the attacker gains the signature ke= y but not past state/PSK.
> > =C2=A0
> > *I.e. after a potentially passive period, if we are to show how t= his behaves in the PCS scenario.
> > =C2=A0
> > This leads to an important question: does our current uniqueness = of sig key predicate limit the ability to rotate signature keys within a gr= oup? That is our means of limiting the full state + sig key compromise scen= ario impacts mentioned above, and therefore the means of limiting the drawb= acks of (3). We should make sure that the limiting ability is feasible. If = that hindered in any way, then I would vote very strongly for (2) as it at = least bootstraps some of the authentication properties from the group state= in the scenario that the sig key is compromised.
> > =C2=A0
> > =C2=A0
> > All the best,
> > =C2=A0
> > Britta
> > =C2=A0
> > =C2=A0
> > =C2=A0
> > From:MLS <mls-bounces@ietf.org> on behalf of Richard Barnes <rlb@ipv.sx>
> >=C2=A0 Date:Monday, October 4, 2021 at 4:09 PM
> >=C2=A0 To:Messaging Layer Security WG <mls@ietf.org>
> >=C2=A0 Subject:[MLS] Resync archaeology + analysis + prognosis
> > =C2=A0
> > OK, I think I have traced back some idea of why we removed the ea= rlier resync proposal. Here's a little essay on how we got here, a reca= p of the trade-offs, and my thoughts on where we should go.
> > =C2=A0
> > tl;dr: Earlier decision not dispositive; we should do basically w= hat's in the PR now.
> >
> >=C2=A0 # History
> >=C2=A0
> >=C2=A0 The story starts all the way back at the January 2019 inter= im at Mozilla / Mountain View. There was a discussion there of ACK/NACK and= replay as related issues [1]. That discussion seems to have led to agreeme= nt that a complete error recovery system was a complex enough topic, and cl= early enough separated from the main protocol that it could be handled in a= separate specification. As a result, the issues that had been opened for A= CK/NACK and resync were closed [2][3]. When Britta and Konrad posted #336 [= 4] including a resync mechanism, my review simply cited that earlier closed= issue as a reason for taking it out [5].
> >=C2=A0
> >=C2=A0 One other note with regard to #336 -- It looks to me like t= he "resync" mechanism in there was not really fleshed out enough = to be implementable. The state linked above was the last state before my re= view, and the word "resync" doesn't actually appear. Instead = the PR talks about "recovering lost group members" using Add and = PSK, which could be elaborated to solve a version of this problem, but woul= d require the assistance of a continuing member rather than allowing the lo= st member to resync unilaterally. It would also have the same issues noted = in terms of new joiners not having resync PSKs.
> >=C2=A0
> >=C2=A0 Overall, though, reading this history doesn't seem to m= e like we really made a principled decision not to do resync. We just punte= d after some discussion in the abstract, and that stuck. We have a more con= crete question now.
> >=C2=A0
> >=C2=A0 # Analysis
> >=C2=A0
> >=C2=A0 Since the discussion of #336 in 2020, we have added externa= l commits in order to have groups you can join unilaterally. So regardless = of the broader question of resync, we have to decide what proposals a joine= r is allowed to originate in their Commit (sending them by value), in parti= cular, whether an external Commit can contain a joiner-originated Remove pr= oposal. We have a spectrum of options here:
> >=C2=A0
> >=C2=A0 1. Forbid Remove
> >=C2=A0 2. Allow Remove + require the (identity, endpoint_id) and s= ignature key to match the removed node + require resumption PSK
> >=C2=A0 3. Allow Remove + require the (identity, endpoint_id) and s= ignature key to match the removed node
> >=C2=A0 4. Allow Remove without restriction
> >=C2=A0
> >=C2=A0 Options (1) and (2) would block an attacker that has compro= mised a member's signature key from joining as that member and evicting= the old appearance. Option (2) because of the PSK; option (1) because of t= he uniqueness requirements (as Raphael pointed out on the call).
> >=C2=A0
> >=C2=A0 Options (1) and (2) do not allow a client who has lost ever= ything but their signature key to resync. Option (1) would require a new en= dpoint_id and signature key, which might not be feasible in all cases. Opti= on (2) would also need to have extra mechanism to account for recent joiner= s not having the required resumption PSK.
> >=C2=A0
> >=C2=A0 Option (1) would also not allow for resync with just a sign= ature key. As Raphael pointed out, because we now require signature keys to= be unique, the member would have to mint a new signature key and get it au= thenticated, or else their attempt to rejoin would be rejected as a duplica= te entry.
> >=C2=A0
> >=C2=A0 Options (3) and (4) would allow a client who has lost every= thing but their signature key to resync, at the risk that an attacker who h= as compromised a member's signature key could abuse it to join as that = member and evict the old, legitimate appearance.
> >=C2=A0
> >=C2=A0 # Prognosis
> >=C2=A0
> >=C2=A0 After this discussion and analysis, I continue to think tha= t (3) above is the right answer, with an optional upgade to (2). Proceeding= by elimination:
> >=C2=A0
> >=C2=A0 Option (4), while technically feasible, is clearly a little= silly. There's no reason to allow joiners to do a remove in the same o= peration as they join; they could do this afterward.
> >=C2=A0
> >=C2=A0 Option (2) does not seem workable in general because of the= recent-joiner problem. While mechanism could be designed to provide the PS= K to recent joiners, it would add a lot of complexity, and the recent joine= rs wouldn't get any benefit from it, which dilutes the value of this me= chanism. (It's not impossible to arrive at the case where everyone besi= des the resync'ing participant is new!)
> >=C2=A0
> >=C2=A0 With option (1), you lose any notion of resync; I think the= need for endpoint_id rotation makes this unworkable in practice. And it ha= s kind of an odd notion of security: You are protected against an attacker = that has compromised a current signature key but can't get a new one au= thenticated. This is a problem for the authentication system to handle (e.g= ., with revocation), not for the key exchange -- if you have valid credenti= als with compromised keys floating around, you have bigger problems to solv= e. So my personal assessment is that (1) doesn't provide a big jump in = security over (3), assuming you have a functioning authentication system. > >=C2=A0
> >=C2=A0 Two side notes about (3): First, if we do (3) but *allow* P= SKs, then an application could opt in to (2). Second, this whole mechanism = is opt-in for the application, since you can't do an external commit if= a PublicGroupState hasn't been published.
> >=C2=A0
> >=C2=A0 Concretely, my proposal here would be (3) + (2*) -- Allow R= emove with matching parameters, and allow PSKs so that applications can opt= in to (2) where they can make it work. That way, if an application opts in= to external Commits, they get the benefit of resync and the same signature= -key-compromise bound on impersonation for resync as well as net-new joins.= And if an application can figure out how to make (2) work, they can requir= e it.
> >=C2=A0
> >=C2=A0 Looking forward to others' thoughts here!
> >=C2=A0
> >=C2=A0 --RLB
> >=C2=A0
> >=C2=A0
> >=C2=A0 [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-= 01/minutes.md#acks-and-nacks-jonm (https://nam10.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-mate= rials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&am= p;data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5= %7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%= 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C3000&sdata=3D%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%= 3D&reserved=3D0)
> >=C2=A0 [2] https://github.com/mlswg/mls-prot= ocol/issues/92 (https://nam10.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-pr= otocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30= cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689= 857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCGZlsHz%2BO2cVPG7eUT= UjzoLhzQ0fniz%2Fblmc%3D&reserved=3D0)
> >=C2=A0 [3] https://github.com/mlswg/mls-prot= ocol/issues/93 (https://nam10.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-pr= otocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30= cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689= 857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz%2BeEwklYbp4NQmFcU= eHBGmAh0jKBRC05CyVBs%3D&reserved=3D0)
> >=C2=A0 [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49a= cce01dcedca7db2d05c57908a292202 (https://nam10.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2= Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=3D0= 4%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d93623= 1a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZs= b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30= 00&sdata=3D0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reser= ved=3D0)
> >=C2=A0 [5] https://ma= ilarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ (https://nam10.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fm= sg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=3D04%7C01%7Cbritta.hale%= 40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963= 378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM= DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DmoUAZJ= 3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=3D0)
--0000000000001665fd05cdb12eff-- From nobody Wed Oct 6 10:59:44 2021 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 608963A091B for ; Wed, 6 Oct 2021 10:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=raphaelrobert.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 ogbhIBLdkJj5 for ; Wed, 6 Oct 2021 10:59:33 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 AD7DD3A090F for ; Wed, 6 Oct 2021 10:59:32 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id k7so11197745wrd.13 for ; Wed, 06 Oct 2021 10:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HVOmbW31KtoLw9ERisiKwPjujIGkCUmhfIOy63EVj8I=; b=Sowp293wUK0eBROlFFvOnmQ0l2P79erMhVz/pArI9gYmQQ/g9AYqZX4jy9OYAdYXrn fy+GpFb4T6CUT8o7LdXTlq/kyLjaxcL2tHYskLJouUAQGllWhv16VUlyZynsQCzLUwp/ acFNpzDuaH1gy6vzCWbHGdW2i761UDUKsYPRQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HVOmbW31KtoLw9ERisiKwPjujIGkCUmhfIOy63EVj8I=; b=PCPOfDLVMevfN1mnqsaNeWdcr9vXTMxKbS2pk7QV3qio6xzW22Fq3lZrTzOQL69Hyp Q1SyKCNZsyyk85pb9rB7ckoX01iKCzELISCCDEO1yNMvvA+Oj0HQQZLor8ub/gad+xjv UoS2CCch3z1yYTcb+IeRCGHDDoGj1U8qwo7snbwE3ZA5FHJclhDiONuYkPwRNWsvHIcu Ybd9H7aemk67rbCgZ/NKaoMSqRs40Gud8NOfWGpWs8gaj0mP8H5EMr/hEKQd9Kq6eoON mBqAWx8cJt1g2QrcGUeiYn9iZMBCMCR73FCUZVxfLgQMhxvlP8O1MVLy+CvO/esWxoGe VCzQ== X-Gm-Message-State: AOAM530CnICQAsK6cc35RUk5HPQ5CURAtLV4XG3SZy1Cq12J5LjbUeDO w1JWxM5C7NsZIauAMxJHUqd35pKpGCeylWtAHx4= X-Google-Smtp-Source: ABdhPJwQNV8mhxe/q9id86gY5CZ7lgr/l3idgHs1OHFQa3zzxTPPo1X31kbkHcODEYXuCtACKXkwuA== X-Received: by 2002:a7b:cc18:: with SMTP id f24mr11524597wmh.8.1633543169018; Wed, 06 Oct 2021 10:59:29 -0700 (PDT) Received: from smtpclient.apple (HSI-KBW-095-208-241-080.hsi5.kabel-badenwuerttemberg.de. [95.208.241.80]) by smtp.gmail.com with ESMTPSA id c18sm6139528wmb.27.2021.10.06.10.59.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Oct 2021 10:59:28 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_16CA025E-5F8D-4C8C-B989-00F84893234A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 6 Oct 2021 19:59:27 +0200 In-Reply-To: Cc: Konrad Kohbrok , "Hale, Britta (CIV)" , Messaging Layer Security WG To: Richard Barnes References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> <1698663123.17469.1633500322380@office.mailbox.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [MLS] Resync archaeology + analysis + prognosis X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 17:59:41 -0000 --Apple-Mail=_16CA025E-5F8D-4C8C-B989-00F84893234A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Richard for digging up all the past history! I think the options you listed indeed cover all possibilities and I = agree that (4) should be discarded right away. Option (1) would prohibit = any resync mechanism based on external commits, so it=E2=80=99s = obviously a non-starter for the discussion. Giving applications the = choice between (2) and (3) generally sounds reasonable. I would however like to point out that all of the options for = =E2=80=9Cresync=E2=80=9D are conditional on external commits being = allowed (remember that they are generally optional) and that therefore = the public group state needs to be available to clients at all times. = This only covers a subset of the possible MLS deployment scenarios and = therefore it is not a general resync mechanism. I want to emphasise = this, because I feel we have lost sight of this somehow. We can decide to leave it at that, bolstered by the sensible argument = that external commits is the only mechanism that works unilaterally = anyway. Alternatively, we could broaden the scope by also trying to = address the scenarios where external commits are not possible/allowed. = An argument in favour of it would be that if we don=E2=80=99t broaden = it, applications will have to solve it anyway =E2=80=93 possibly doing = so by not making the best decisions. In a scenario where external commits are not an option, members that are = out-of-sync have no choice but to send an out-of-band distress message = to the rest of the group and ask to be removed and subsequently re-added = again. This is where we could offer some guidance at least. PSKs might = still be an option here, additionally the distress message could be = encrypted to a group key from a previous epoch. I would be good to know how others feel about broadening the scope.=20 Thanks Raphael > On 6. Oct 2021, at 17:55, Richard Barnes wrote: >=20 > I've updated the PR to do basically what Konrad proposes. Namely, = allow Remove, but suggest that applications can apply additional = constraints. >=20 > = https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746a= 7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873 = >=20 > Britta, does that work for you? >=20 > On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok = > = wrote: > Hi, >=20 > If I understand correctly, the solutions (2) and (3) (discarding 1 and = 4 for now) represent trade-offs in security guarantees and their = applicability depends on the specific deployment scenario. My = understanding is that external joins will be subject to some sort of = policy anyway. Should we then be strict in the spec in terms of what we = mandate the exact policy w.r.t. PSKs is?=20 >=20 > Since I don't think either solution represents much of a foot-gun, I = propose we include the capability to include resync PSKs in the spec for = this purpose, but don't mandate them. Instead we relegate the policy = decision to the application layer and detail the security trade-offs in = the architecture document. I realize that delegating decisions to the = application layer is a bit of a cop-out solution, but I think in this = case it makes sense to include the mechanism in the spec and then let = the application decide. >=20 > Cheers, > Konrad >=20 > > Richard Barnes > hat am 05.10.2021 = 04:31 geschrieben: > >=20 > >=20 > > Hi Britta, > >=20 > > Couple of responses inline... > >=20 > >=20 > > On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) = > wrote: > > > [trimmed] > > > =20 > > > To the present proposed options, I will note that the =E2=80=98new = joiners in interim=E2=80=99 case is likely a misleading focus point for = the discussion, and we should avoid tripping into that ditch for a = number of reasons:=20 > > > * Notably, if everyone except for the re-syncing participant is = new, why not just require the re-syncing participant to be added as a = new member themselves? It is, after all, practically a brand new group = at that point.=20 > > > * It is true that a new member would not gain from a PSK = guarantee, but why should we reduce the guarantees for all other = participants to that of the new joiner? =46rom the view of the new = joiner, all participants are new in any case, so e.g. PCS does not have = substantial meaning as of yet. Existing members have more to lose and = also have the more to gain from PSK use. I do not believe we want to = adapt a stance of =E2=80=98if the new joiner doesn=E2=80=99t get a = security guarantee, no one should have the security guarantee=E2=80=99 = =E2=80=93 in fact, the tree structure, commit history, and the like = provide insight to longer term members that a new joiner does not have. = So (2) offers a new joiner the benefits of (3) but to all others an even = stronger guarantee.=20 > > > * As a nod to what a new joiner may gain, we can offer the = following: if a re-sync PSK fails, then whichever existing member checks = and notes the PSK failure should initiate a removal of the resyncing = member. If there is a new joiner, then by continued presence of the = re-syncing member they gain the guarantee that at least one other group = member has previously seen that member, or else would have ejected them = (assuming that the checker is online). > > I don't mean to over-rotate on this case, but software being = software, we need an algorithm to implement that covers all the cases. = While the "everyone is new" scenario is outlandish, it wouldn't be all = that surprising to have one or two new members, so it's a case that = would need addressing. The seemingly most obvious approach to addressing = this problem is to encrypt the PSK to new members, which requires you at = least have enough state to figure out who the new members are. > >=20 > > It also occurs to me now that the PSK approach presumes that you = know when your state went bad, since you would want to use a PSK from = before that point. In Raphael's example where persistent storage is = corrupted, all you know is that messages stopped decrypting, which gives = you an upper bound on the time of corruption, but not really a way to go = back and figure out what's good. > >=20 > >=20 > > > The security goal in the balance here is PCS. Adding a re-sync = option of any of the varieties (2)-(4) would break that to some degree, = since following a compromise and passive period the adversary is then = enabled to regain a foothold. The question is how much of a degree of = loss are we willing to tolerate.=20 > >=20 > > I'm not sure I would really characterize this as a PCS violation. = PCS is a guarantee that you get when you take a certain action. For = example, when a member issue an Update or a Commit with a fresh HPKE key = pair, you should get PCS with regard to that participant's HPKE key = pair; likewise with rotating signature keys. Here, the signature key has = not been rotated, so there's no PCS boundary. > >=20 > > It is worth considering whether this mechanism gives the attacker = any additional capabilities in the event that (1) the signature key is = compromised, and (2) the compromised member issues an Update or Commit = rotating the signature key. ISTM that you still get PCS there in option = (3), since the requirement that the signature keys match ensures that = the old, compromised signature key is not allowed to resync back into = the group. There's still a risk that the compromised key / credential = could be used for a fresh, non-resync join, but that's an inherent risk = with external Commit / freely joinable groups, and also an opportunity = for the AS's revocation/invalidation system to help. > >=20 > > Will take a look at the remainder in the morning... > >=20 > > --RLB > >=20 > >=20 > > > * I agree that (4) is an immediate discard. > > > * Under (2) a PSK use, the PSK use at least more limited due to = the proof of knowledge of a past state (e.g. notes above). This is a = worthwhile property to enforce in my view since it balances = authentication across two vectors: the signature key and knowledge of = group state. Adversary access to only one or the other is insufficient = for the adversary to eject Alice and replace her in the group.=20 > > > * Under (3), the attack scenario of Eve compromising Alice (full = state + sig key), followed eventually* by removing Alice while adding = herself, is not dissimilar from the attack scenario of Eve compromising = Alice full state + sig key) followed eventually* by providing an = impersonating update in Alice=E2=80=99s name. What has been shown so far = is that this type of scenario can be limited by rotating signature keys. = A important point that is different in these scenarios is that under the = first Alice knows she was removed (a plus) while under the second = (currently possible) scenario the group simply goes silent and Alice = does not know if it was malicious or not. All said, it could be worse. = That does not consider other attack scenarios though, for example when = the attacker gains the signature key but not past state/PSK.=20 > > > =20 > > > *I.e. after a potentially passive period, if we are to show how = this behaves in the PCS scenario. > > > =20 > > > This leads to an important question: does our current uniqueness = of sig key predicate limit the ability to rotate signature keys within a = group? That is our means of limiting the full state + sig key compromise = scenario impacts mentioned above, and therefore the means of limiting = the drawbacks of (3). We should make sure that the limiting ability is = feasible. If that hindered in any way, then I would vote very strongly = for (2) as it at least bootstraps some of the authentication properties = from the group state in the scenario that the sig key is compromised. > > > =20 > > > =20 > > > All the best, > > > =20 > > > Britta > > > =20 > > > =20 > > > =20 > > > From:MLS > on = behalf of Richard Barnes > > > > Date:Monday, October 4, 2021 at 4:09 PM > > > To:Messaging Layer Security WG > > > > Subject:[MLS] Resync archaeology + analysis + prognosis > > > =20 > > > OK, I think I have traced back some idea of why we removed the = earlier resync proposal. Here's a little essay on how we got here, a = recap of the trade-offs, and my thoughts on where we should go. > > > =20 > > > tl;dr: Earlier decision not dispositive; we should do basically = what's in the PR now. > > >=20 > > > # History > > > =20 > > > The story starts all the way back at the January 2019 interim at = Mozilla / Mountain View. There was a discussion there of ACK/NACK and = replay as related issues [1]. That discussion seems to have led to = agreement that a complete error recovery system was a complex enough = topic, and clearly enough separated from the main protocol that it could = be handled in a separate specification. As a result, the issues that had = been opened for ACK/NACK and resync were closed [2][3]. When Britta and = Konrad posted #336 [4] including a resync mechanism, my review simply = cited that earlier closed issue as a reason for taking it out [5]. > > > =20 > > > One other note with regard to #336 -- It looks to me like the = "resync" mechanism in there was not really fleshed out enough to be = implementable. The state linked above was the last state before my = review, and the word "resync" doesn't actually appear. Instead the PR = talks about "recovering lost group members" using Add and PSK, which = could be elaborated to solve a version of this problem, but would = require the assistance of a continuing member rather than allowing the = lost member to resync unilaterally. It would also have the same issues = noted in terms of new joiners not having resync PSKs. > > > =20 > > > Overall, though, reading this history doesn't seem to me like we = really made a principled decision not to do resync. We just punted after = some discussion in the abstract, and that stuck. We have a more concrete = question now. > > > =20 > > > # Analysis > > > =20 > > > Since the discussion of #336 in 2020, we have added external = commits in order to have groups you can join unilaterally. So regardless = of the broader question of resync, we have to decide what proposals a = joiner is allowed to originate in their Commit (sending them by value), = in particular, whether an external Commit can contain a = joiner-originated Remove proposal. We have a spectrum of options here: > > > =20 > > > 1. Forbid Remove=20 > > > 2. Allow Remove + require the (identity, endpoint_id) and = signature key to match the removed node + require resumption PSK > > > 3. Allow Remove + require the (identity, endpoint_id) and = signature key to match the removed node > > > 4. Allow Remove without restriction > > > =20 > > > Options (1) and (2) would block an attacker that has compromised = a member's signature key from joining as that member and evicting the = old appearance. Option (2) because of the PSK; option (1) because of the = uniqueness requirements (as Raphael pointed out on the call). > > > =20 > > > Options (1) and (2) do not allow a client who has lost everything = but their signature key to resync. Option (1) would require a new = endpoint_id and signature key, which might not be feasible in all cases. = Option (2) would also need to have extra mechanism to account for recent = joiners not having the required resumption PSK. > > > =20 > > > Option (1) would also not allow for resync with just a signature = key. As Raphael pointed out, because we now require signature keys to be = unique, the member would have to mint a new signature key and get it = authenticated, or else their attempt to rejoin would be rejected as a = duplicate entry. > > > =20 > > > Options (3) and (4) would allow a client who has lost everything = but their signature key to resync, at the risk that an attacker who has = compromised a member's signature key could abuse it to join as that = member and evict the old, legitimate appearance. > > > =20 > > > # Prognosis > > > =20 > > > After this discussion and analysis, I continue to think that (3) = above is the right answer, with an optional upgade to (2). Proceeding by = elimination: > > > =20 > > > Option (4), while technically feasible, is clearly a little = silly. There's no reason to allow joiners to do a remove in the same = operation as they join; they could do this afterward. > > > =20 > > > Option (2) does not seem workable in general because of the = recent-joiner problem. While mechanism could be designed to provide the = PSK to recent joiners, it would add a lot of complexity, and the recent = joiners wouldn't get any benefit from it, which dilutes the value of = this mechanism. (It's not impossible to arrive at the case where = everyone besides the resync'ing participant is new!)=20 > > > =20 > > > With option (1), you lose any notion of resync; I think the need = for endpoint_id rotation makes this unworkable in practice. And it has = kind of an odd notion of security: You are protected against an attacker = that has compromised a current signature key but can't get a new one = authenticated. This is a problem for the authentication system to handle = (e.g., with revocation), not for the key exchange -- if you have valid = credentials with compromised keys floating around, you have bigger = problems to solve. So my personal assessment is that (1) doesn't provide = a big jump in security over (3), assuming you have a functioning = authentication system. > > > =20 > > > Two side notes about (3): First, if we do (3) but *allow* PSKs, = then an application could opt in to (2). Second, this whole mechanism is = opt-in for the application, since you can't do an external commit if a = PublicGroupState hasn't been published. > > > =20 > > > Concretely, my proposal here would be (3) + (2*) -- Allow Remove = with matching parameters, and allow PSKs so that applications can opt in = to (2) where they can make it work. That way, if an application opts in = to external Commits, they get the benefit of resync and the same = signature-key-compromise bound on impersonation for resync as well as = net-new joins. And if an application can figure out how to make (2) = work, they can require it. > > > =20 > > > Looking forward to others' thoughts here! > > > =20 > > > --RLB > > > =20 > > > =20 > > > [1] = https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md= #acks-and-nacks-jonm = = (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%= 23acks-and-nacks-jonm&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc= 44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898= 57931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2BEprQMOVk%2BINhdtRxHL5JfGQ%2= FeP6tCFvcAM3uopMFq4%3D&reserved=3D0 = ) > > > [2] https://github.com/mlswg/mls-protocol/issues/92 = = (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40= nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f75789633= 78e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM= DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCG= ZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=3D0 = ) > > > [3] https://github.com/mlswg/mls-protocol/issues/93 = = (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40= nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f75789633= 78e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM= DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz= %2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=3D0 = ) > > > [4] = https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7= db2d05c57908a292202 = = (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7d= b2d05c57908a292202&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44f= c96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898579= 31864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT= iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D0OgVddc%2BIzju61MwfQFNiYjejZINtrI= qf08CkIgGm%2BQ%3D&reserved=3D0 = ) > > > [5] = https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ = = (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmaila= rchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=3D= 04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936= 231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%= 7C3000&sdata=3DmoUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=3D= 0 = ) > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_16CA025E-5F8D-4C8C-B989-00F84893234A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Richard for digging up all the past history!

I think the options you = listed indeed cover all possibilities and I agree that (4) should be = discarded right away. Option (1) would prohibit any resync mechanism = based on external commits, so it=E2=80=99s obviously a non-starter for = the discussion. Giving applications the choice between (2) and (3) = generally sounds reasonable.

I would however like to point out that = all of the options for =E2=80=9Cresync=E2=80=9D are conditional on = external commits being allowed (remember that they are generally = optional) and that therefore the public group state needs to be = available to clients at all times. This only covers a subset of the = possible MLS deployment scenarios and therefore it is not a general = resync mechanism. I want to emphasise this, because I feel we have lost = sight of this somehow.

We can decide to leave it at that, bolstered by the sensible = argument that external commits is the only mechanism that works = unilaterally anyway. Alternatively, we could broaden the scope by also = trying to address the scenarios where external commits are not = possible/allowed. An argument in favour of it would be that if we = don=E2=80=99t broaden it, applications will have to solve it anyway =E2=80= =93 possibly doing so by not making the best decisions.

In a scenario where = external commits are not an option, members that are out-of-sync have no = choice but to send an out-of-band distress message to the rest of the = group and ask to be removed and subsequently re-added again. This is = where we could offer some guidance at least. PSKs might still be an = option here, additionally the distress message could be encrypted to a = group key from a previous epoch.

I would be good to know how others feel = about broadening the scope. 

Thanks

Raphael

On 6. = Oct 2021, at 17:55, Richard Barnes <rlb@ipv.sx> wrote:

I've updated the PR to do basically what = Konrad proposes.  Namely, allow Remove, but suggest that = applications can apply additional constraints.

=

Britta, does that = work for you?

On Wed, Oct 6, 2021 at 2:05 AM Konrad = Kohbrok <konrad.kohbrok@datashrine.de> wrote:
Hi,

If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 = for now) represent trade-offs in security guarantees and their = applicability depends on the specific deployment scenario. My = understanding is that external joins will be subject to some sort of = policy anyway. Should we then be strict in the spec in terms of what we = mandate the exact policy w.r.t. PSKs is?

Since I don't think either solution represents much of a foot-gun, I = propose we include the capability to include resync PSKs in the spec for = this purpose, but don't mandate them. Instead we relegate the policy = decision to the application layer and detail the security trade-offs in = the architecture document. I realize that delegating decisions to the = application layer is a bit of a cop-out solution, but I think in this = case it makes sense to include the mechanism in the spec and then let = the application decide.

Cheers,
Konrad

> Richard Barnes <rlb@ipv.sx> hat am 05.10.2021 04:31 geschrieben:
>
>
> Hi Britta,
>
> Couple of responses inline...
>
>
> On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:
> > [trimmed]
> >  
> > To the present proposed options, I will note that the =E2=80=98n= ew joiners in interim=E2=80=99 case is likely a misleading focus point = for the discussion, and we should avoid tripping into that ditch for a = number of reasons:
> >   * Notably, if everyone except for the re-syncing = participant is new, why not just require the re-syncing participant to = be added as a new member themselves? It is, after all, practically a = brand new group at that point.
> >   * It is true that a new member would not gain from = a PSK guarantee, but why should we reduce the guarantees for all other = participants to that of the new joiner? =46rom the view of the new = joiner, all participants are new in any case, so e.g. PCS does not have = substantial meaning as of yet. Existing members have more to lose and = also have the more to gain from PSK use. I do not believe we want to = adapt a stance of =E2=80=98if the new joiner doesn=E2=80=99t get a = security guarantee, no one should have the security guarantee=E2=80=99 = =E2=80=93 in fact, the tree structure, commit history, and the like = provide insight to longer term members that a new joiner does not have. = So (2) offers a new joiner the benefits of (3) but to all others an even = stronger guarantee.
> >   * As a nod to what a new joiner may gain, we can = offer the following: if a re-sync PSK fails, then whichever existing = member checks and notes the PSK failure should initiate a removal of the = resyncing member. If there is a new joiner, then by continued presence = of the re-syncing member they gain the guarantee that at least one other = group member has previously seen that member, or else would have ejected = them (assuming that the checker is online).
> I don't mean to over-rotate on this case, but software being = software, we need an algorithm to implement that covers all the cases. = While the "everyone is new" scenario is outlandish, it wouldn't be all = that surprising to have one or two new members, so it's a case that = would need addressing. The seemingly most obvious approach to addressing = this problem is to encrypt the PSK to new members, which requires you at = least have enough state to figure out who the new members are.
>
> It also occurs to me now that the PSK approach presumes that you = know when your state went bad, since you would want to use a PSK from = before that point. In Raphael's example where persistent storage is = corrupted, all you know is that messages stopped decrypting, which gives = you an upper bound on the time of corruption, but not really a way to go = back and figure out what's good.
>
>
> > The security goal in the balance here is PCS. Adding a re-sync = option of any of the varieties (2)-(4) would break that to some degree, = since following a compromise and passive period the adversary is then = enabled to regain a foothold. The question is how much of a degree of = loss are we willing to tolerate.
>
> I'm not sure I would really characterize this as a PCS violation. = PCS is a guarantee that you get when you take a certain action. For = example, when a member issue an Update or a Commit with a fresh HPKE key = pair, you should get PCS with regard to that participant's HPKE key = pair; likewise with rotating signature keys. Here, the signature key has = not been rotated, so there's no PCS boundary.
>
> It is worth considering whether this mechanism gives the attacker = any additional capabilities in the event that (1) the signature key is = compromised, and (2) the compromised member issues an Update or Commit = rotating the signature key. ISTM that you still get PCS there in option = (3), since the requirement that the signature keys match ensures that = the old, compromised signature key is not allowed to resync back into = the group. There's still a risk that the compromised key / credential = could be used for a fresh, non-resync join, but that's an inherent risk = with external Commit / freely joinable groups, and also an opportunity = for the AS's revocation/invalidation system to help.
>
> Will take a look at the remainder in the morning...
>
> --RLB
>
>
> >   * I agree that (4) is an immediate discard.
> >   * Under (2) a PSK use, the PSK use at least more = limited due to the proof of knowledge of a past state (e.g. notes = above). This is a worthwhile property to enforce in my view since it = balances authentication across two vectors: the signature key and = knowledge of group state. Adversary access to only one or the other is = insufficient for the adversary to eject Alice and replace her in the = group.
> >   * Under (3), the attack scenario of Eve = compromising Alice (full state + sig key), followed eventually* by = removing Alice while adding herself, is not dissimilar from the attack = scenario of Eve compromising Alice full state + sig key) followed = eventually* by providing an impersonating update in Alice=E2=80=99s = name. What has been shown so far is that this type of scenario can be = limited by rotating signature keys. A important point that is different = in these scenarios is that under the first Alice knows she was removed = (a plus) while under the second (currently possible) scenario the group = simply goes silent and Alice does not know if it was malicious or not. = All said, it could be worse. That does not consider other attack = scenarios though, for example when the attacker gains the signature key = but not past state/PSK.
> >  
> > *I.e. after a potentially passive period, if we are to show = how this behaves in the PCS scenario.
> >  
> > This leads to an important question: does our current = uniqueness of sig key predicate limit the ability to rotate signature = keys within a group? That is our means of limiting the full state + sig = key compromise scenario impacts mentioned above, and therefore the means = of limiting the drawbacks of (3). We should make sure that the limiting = ability is feasible. If that hindered in any way, then I would vote very = strongly for (2) as it at least bootstraps some of the authentication = properties from the group state in the scenario that the sig key is = compromised.
> >  
> >  
> > All the best,
> >  
> > Britta
> >  
> >  
> >  
> > From:MLS <mls-bounces@ietf.org> on behalf of = Richard Barnes <rlb@ipv.sx>
> >  Date:Monday, October 4, 2021 at 4:09 PM
> >  To:Messaging Layer Security WG <mls@ietf.org>
> >  Subject:[MLS] Resync archaeology + analysis + = prognosis
> >  
> > OK, I think I have traced back some idea of why we removed the = earlier resync proposal. Here's a little essay on how we got here, a = recap of the trade-offs, and my thoughts on where we should go.
> >  
> > tl;dr: Earlier decision not dispositive; we should do = basically what's in the PR now.
> >
> >  # History
> > 
> >  The story starts all the way back at the January 2019 = interim at Mozilla / Mountain View. There was a discussion there of = ACK/NACK and replay as related issues [1]. That discussion seems to have = led to agreement that a complete error recovery system was a complex = enough topic, and clearly enough separated from the main protocol that = it could be handled in a separate specification. As a result, the issues = that had been opened for ACK/NACK and resync were closed [2][3]. When = Britta and Konrad posted #336 [4] including a resync mechanism, my = review simply cited that earlier closed issue as a reason for taking it = out [5].
> > 
> >  One other note with regard to #336 -- It looks to me = like the "resync" mechanism in there was not really fleshed out enough = to be implementable. The state linked above was the last state before my = review, and the word "resync" doesn't actually appear. Instead the PR = talks about "recovering lost group members" using Add and PSK, which = could be elaborated to solve a version of this problem, but would = require the assistance of a continuing member rather than allowing the = lost member to resync unilaterally. It would also have the same issues = noted in terms of new joiners not having resync PSKs.
> > 
> >  Overall, though, reading this history doesn't seem to me = like we really made a principled decision not to do resync. We just = punted after some discussion in the abstract, and that stuck. We have a = more concrete question now.
> > 
> >  # Analysis
> > 
> >  Since the discussion of #336 in 2020, we have added = external commits in order to have groups you can join unilaterally. So = regardless of the broader question of resync, we have to decide what = proposals a joiner is allowed to originate in their Commit (sending them = by value), in particular, whether an external Commit can contain a = joiner-originated Remove proposal. We have a spectrum of options = here:
> > 
> >  1. Forbid Remove
> >  2. Allow Remove + require the (identity, endpoint_id) = and signature key to match the removed node + require resumption PSK
> >  3. Allow Remove + require the (identity, endpoint_id) = and signature key to match the removed node
> >  4. Allow Remove without restriction
> > 
> >  Options (1) and (2) would block an attacker that has = compromised a member's signature key from joining as that member and = evicting the old appearance. Option (2) because of the PSK; option (1) = because of the uniqueness requirements (as Raphael pointed out on the = call).
> > 
> >  Options (1) and (2) do not allow a client who has lost = everything but their signature key to resync. Option (1) would require a = new endpoint_id and signature key, which might not be feasible in all = cases. Option (2) would also need to have extra mechanism to account for = recent joiners not having the required resumption PSK.
> > 
> >  Option (1) would also not allow for resync with just a = signature key. As Raphael pointed out, because we now require signature = keys to be unique, the member would have to mint a new signature key and = get it authenticated, or else their attempt to rejoin would be rejected = as a duplicate entry.
> > 
> >  Options (3) and (4) would allow a client who has lost = everything but their signature key to resync, at the risk that an = attacker who has compromised a member's signature key could abuse it to = join as that member and evict the old, legitimate appearance.
> > 
> >  # Prognosis
> > 
> >  After this discussion and analysis, I continue to think = that (3) above is the right answer, with an optional upgade to (2). = Proceeding by elimination:
> > 
> >  Option (4), while technically feasible, is clearly a = little silly. There's no reason to allow joiners to do a remove in the = same operation as they join; they could do this afterward.
> > 
> >  Option (2) does not seem workable in general because of = the recent-joiner problem. While mechanism could be designed to provide = the PSK to recent joiners, it would add a lot of complexity, and the = recent joiners wouldn't get any benefit from it, which dilutes the value = of this mechanism. (It's not impossible to arrive at the case where = everyone besides the resync'ing participant is new!)
> > 
> >  With option (1), you lose any notion of resync; I think = the need for endpoint_id rotation makes this unworkable in practice. And = it has kind of an odd notion of security: You are protected against an = attacker that has compromised a current signature key but can't get a = new one authenticated. This is a problem for the authentication system = to handle (e.g., with revocation), not for the key exchange -- if you = have valid credentials with compromised keys floating around, you have = bigger problems to solve. So my personal assessment is that (1) doesn't = provide a big jump in security over (3), assuming you have a functioning = authentication system.
> > 
> >  Two side notes about (3): First, if we do (3) but = *allow* PSKs, then an application could opt in to (2). Second, this = whole mechanism is opt-in for the application, since you can't do an = external commit if a PublicGroupState hasn't been published.
> > 
> >  Concretely, my proposal here would be (3) + (2*) -- = Allow Remove with matching parameters, and allow PSKs so that = applications can opt in to (2) where they can make it work. That way, if = an application opts in to external Commits, they get the benefit of = resync and the same signature-key-compromise bound on impersonation for = resync as well as net-new joins. And if an application can figure out = how to make (2) work, they can require it.
> > 
> >  Looking forward to others' thoughts here!
> > 
> >  --RLB
> > 
> > 
> >  [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01= /minutes.md#acks-and-nacks-jonm (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fm= inutes.md%23acks-and-nacks-jonm&data=3D04%7C01%7Cbritta.hale%40nps.edu= %7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0= %7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ= IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2BEprQMOVk%= 2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=3D0)
> >  [2] https://github.com/mlswg/mls-protocol/issues/92 (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=3D04%7C01%7C= britta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740e= a9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&= ;sdata=3DlFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=3D= 0)
> >  [3] https://github.com/mlswg/mls-protocol/issues/93 (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=3D04%7C01%7C= britta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740e= a9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&= ;sdata=3DzpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=3D= 0)
> >  [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49ac= ce01dcedca7db2d05c57908a292202 (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce= 01dcedca7db2d05c57908a292202&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C= 1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C= 0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D0OgVddc%2BIzju6= 1MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=3D0)
> >  [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu= 1CFSAE/ (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE= %2F&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d98= 78bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7C= Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi= LCJXVCI6Mn0%3D%7C3000&sdata=3DmoUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5= lDxC0%3D&reserved=3D0)
_______________________________________________
MLS = mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_16CA025E-5F8D-4C8C-B989-00F84893234A-- From nobody Thu Oct 7 10:22:46 2021 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 5CE2F3A0C94 for ; Thu, 7 Oct 2021 10:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 hAsiprgN7Q1S for ; Thu, 7 Oct 2021 10:22:39 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B904E3A0C8B for ; Thu, 7 Oct 2021 10:22:38 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id l7so6777255qkk.0 for ; Thu, 07 Oct 2021 10:22:38 -0700 (PDT) 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=enPu7XOyGZrUtdIXU1/TmXgBJabm70tY0rdHDqRYJN0=; b=cA3uva9MN64zC/1fpteIginvFkCM1pIZxrhQce2MGxWXwQ9MUJOrPbYs6Rqu4jGbvn vD9ql9EBrMvkZtS1c0CW5j1vrBBiB7ZfQ8x0T5Q19+LBSAF3A/s3JdYydIPqOYgbzsxc svtGWp9GF6B+YN9Zvr510dE/7skRcl9BCxSW6bpbZAyaqHLrsmqZ+SP2W5yo4mPC9MVV KgZHq+Txoto1KA/HelNJo39lebBAHkowdXhiEWbT48B862zS5D+cNh2UovRgzg/mI94i 0a+jPT81VV01P/xwWPK08MMKuR8cueskQZLFBU8dSbci1Zr2JeKP1ABgEolBVW8jpEhn Bpuw== 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=enPu7XOyGZrUtdIXU1/TmXgBJabm70tY0rdHDqRYJN0=; b=NZPUE1firWW7wH4QH784kVQUMegw+CMf8NVXFs7uz7QwmLzDCSepiypMMz2oZ+XwE3 +Vx2xktJhHy63RHTHEdjhwQpttySQNt4iqgp3lkdMD8y9QLxjhgUIIDOs3Iucdh7EvsN bflu7ENNeygSD50VgZArXhhLwv0b8qWejMXzPhGofxnzkuB5FGxI9wizim+5N44ZniJn paAxDwMD408nSVjqEeU+MCPq3Xh0syszrPQHeA0Jnzr1Tak4IhvRRYuY/5NNvRdqCWhE WhNggUfra0R0V8TjVTEstLFVjXqsQ58IGuaK69fro2GZ3d5mz+CRWt1DENJeuHAjNb0l I9iQ== X-Gm-Message-State: AOAM533tGLNhpJS/kyKEe0/P6Tf4dYG56QQcpmCL+BMZewTzIiNosoeN POL/rRmtYFz31K4d6Zhj7MYj5ZorhpQYooi49j+KAg== X-Google-Smtp-Source: ABdhPJwgy2c6Pxz11qTDlrIkhV9StMak+LTzltJk+pgyv4tadSyYQXqFbpocBG27LIvm+E5cR3INdem6gsfGKBkXvBg= X-Received: by 2002:a37:bb85:: with SMTP id l127mr3542460qkf.223.1633627357077; Thu, 07 Oct 2021 10:22:37 -0700 (PDT) MIME-Version: 1.0 References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> <1698663123.17469.1633500322380@office.mailbox.org> In-Reply-To: From: Richard Barnes Date: Thu, 7 Oct 2021 13:22:24 -0400 Message-ID: To: Raphael Robert Cc: Konrad Kohbrok , "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000005075d205cdc68211" Archived-At: Subject: Re: [MLS] Resync archaeology + analysis + prognosis 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, 07 Oct 2021 17:22:45 -0000 --0000000000005075d205cdc68211 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok, it sounds like folks are pretty much on the same "2-plus-optional-3" page. I'll wait another day or two before merging to give a chance for any more discussion. Re: broadening scope -- Let's not. Pretty much the only firm conclusion out of that history research was WG consensus that a full resync solution is a complex enough topic for another draft. (And IMO would benefit from some deployment experience with the base protocol.) All we're talking about here is how to cover a single resync case that is easily solved with external commit. That's not to say the problem isn't worth solving, just that it's beyond the scope of the core protocol. --RLB On Wed, Oct 6, 2021 at 1:59 PM Raphael Robert wrote: > Thanks Richard for digging up all the past history! > > I think the options you listed indeed cover all possibilities and I agree > that (4) should be discarded right away. Option (1) would prohibit any > resync mechanism based on external commits, so it=E2=80=99s obviously a n= on-starter > for the discussion. Giving applications the choice between (2) and (3) > generally sounds reasonable. > > I would however like to point out that all of the options for =E2=80=9Cre= sync=E2=80=9D are > conditional on external commits being allowed (remember that they are > generally optional) and that therefore the public group state needs to be > available to clients at all times. This only covers a subset of the > possible MLS deployment scenarios and therefore it is not a general resyn= c > mechanism. I want to emphasise this, because I feel we have lost sight of > this somehow. > > We can decide to leave it at that, bolstered by the sensible argument tha= t > external commits is the only mechanism that works unilaterally anyway. > Alternatively, we could broaden the scope by also trying to address the > scenarios where external commits are not possible/allowed. An argument in > favour of it would be that if we don=E2=80=99t broaden it, applications w= ill have > to solve it anyway =E2=80=93 possibly doing so by not making the best dec= isions. > > In a scenario where external commits are not an option, members that are > out-of-sync have no choice but to send an out-of-band distress message to > the rest of the group and ask to be removed and subsequently re-added > again. This is where we could offer some guidance at least. PSKs might > still be an option here, additionally the distress message could be > encrypted to a group key from a previous epoch. > > I would be good to know how others feel about broadening the scope. > > Thanks > > Raphael > > On 6. Oct 2021, at 17:55, Richard Barnes wrote: > > I've updated the PR to do basically what Konrad proposes. Namely, allow > Remove, but suggest that applications can apply additional constraints. > > > https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746= a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873 > > Britta, does that work for you? > > On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok < > konrad.kohbrok@datashrine.de> wrote: > >> Hi, >> >> If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 >> for now) represent trade-offs in security guarantees and their >> applicability depends on the specific deployment scenario. My understand= ing >> is that external joins will be subject to some sort of policy anyway. >> Should we then be strict in the spec in terms of what we mandate the exa= ct >> policy w.r.t. PSKs is? >> >> Since I don't think either solution represents much of a foot-gun, I >> propose we include the capability to include resync PSKs in the spec for >> this purpose, but don't mandate them. Instead we relegate the policy >> decision to the application layer and detail the security trade-offs in = the >> architecture document. I realize that delegating decisions to the >> application layer is a bit of a cop-out solution, but I think in this ca= se >> it makes sense to include the mechanism in the spec and then let the >> application decide. >> >> Cheers, >> Konrad >> >> > Richard Barnes hat am 05.10.2021 04:31 geschrieben: >> > >> > >> > Hi Britta, >> > >> > Couple of responses inline... >> > >> > >> > On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) >> wrote: >> > > [trimmed] >> > > >> > > To the present proposed options, I will note that the =E2=80=98new j= oiners in >> interim=E2=80=99 case is likely a misleading focus point for the discuss= ion, and we >> should avoid tripping into that ditch for a number of reasons: >> > > * Notably, if everyone except for the re-syncing participant is >> new, why not just require the re-syncing participant to be added as a ne= w >> member themselves? It is, after all, practically a brand new group at th= at >> point. >> > > * It is true that a new member would not gain from a PSK guarantee= , >> but why should we reduce the guarantees for all other participants to th= at >> of the new joiner? From the view of the new joiner, all participants are >> new in any case, so e.g. PCS does not have substantial meaning as of yet= . >> Existing members have more to lose and also have the more to gain from P= SK >> use. I do not believe we want to adapt a stance of =E2=80=98if the new j= oiner >> doesn=E2=80=99t get a security guarantee, no one should have the securit= y >> guarantee=E2=80=99 =E2=80=93 in fact, the tree structure, commit history= , and the like >> provide insight to longer term members that a new joiner does not have. = So >> (2) offers a new joiner the benefits of (3) but to all others an even >> stronger guarantee. >> > > * As a nod to what a new joiner may gain, we can offer the >> following: if a re-sync PSK fails, then whichever existing member checks >> and notes the PSK failure should initiate a removal of the resyncing >> member. If there is a new joiner, then by continued presence of the >> re-syncing member they gain the guarantee that at least one other group >> member has previously seen that member, or else would have ejected them >> (assuming that the checker is online). >> > I don't mean to over-rotate on this case, but software being software, >> we need an algorithm to implement that covers all the cases. While the >> "everyone is new" scenario is outlandish, it wouldn't be all that >> surprising to have one or two new members, so it's a case that would nee= d >> addressing. The seemingly most obvious approach to addressing this probl= em >> is to encrypt the PSK to new members, which requires you at least have >> enough state to figure out who the new members are. >> > >> > It also occurs to me now that the PSK approach presumes that you know >> when your state went bad, since you would want to use a PSK from before >> that point. In Raphael's example where persistent storage is corrupted, = all >> you know is that messages stopped decrypting, which gives you an upper >> bound on the time of corruption, but not really a way to go back and fig= ure >> out what's good. >> > >> > >> > > The security goal in the balance here is PCS. Adding a re-sync optio= n >> of any of the varieties (2)-(4) would break that to some degree, since >> following a compromise and passive period the adversary is then enabled = to >> regain a foothold. The question is how much of a degree of loss are we >> willing to tolerate. >> > >> > I'm not sure I would really characterize this as a PCS violation. PCS >> is a guarantee that you get when you take a certain action. For example, >> when a member issue an Update or a Commit with a fresh HPKE key pair, yo= u >> should get PCS with regard to that participant's HPKE key pair; likewise >> with rotating signature keys. Here, the signature key has not been rotat= ed, >> so there's no PCS boundary. >> > >> > It is worth considering whether this mechanism gives the attacker any >> additional capabilities in the event that (1) the signature key is >> compromised, and (2) the compromised member issues an Update or Commit >> rotating the signature key. ISTM that you still get PCS there in option >> (3), since the requirement that the signature keys match ensures that th= e >> old, compromised signature key is not allowed to resync back into the >> group. There's still a risk that the compromised key / credential could = be >> used for a fresh, non-resync join, but that's an inherent risk with >> external Commit / freely joinable groups, and also an opportunity for th= e >> AS's revocation/invalidation system to help. >> > >> > Will take a look at the remainder in the morning... >> > >> > --RLB >> > >> > >> > > * I agree that (4) is an immediate discard. >> > > * Under (2) a PSK use, the PSK use at least more limited due to th= e >> proof of knowledge of a past state (e.g. notes above). This is a worthwh= ile >> property to enforce in my view since it balances authentication across t= wo >> vectors: the signature key and knowledge of group state. Adversary acces= s >> to only one or the other is insufficient for the adversary to eject Alic= e >> and replace her in the group. >> > > * Under (3), the attack scenario of Eve compromising Alice (full >> state + sig key), followed eventually* by removing Alice while adding >> herself, is not dissimilar from the attack scenario of Eve compromising >> Alice full state + sig key) followed eventually* by providing an >> impersonating update in Alice=E2=80=99s name. What has been shown so far= is that >> this type of scenario can be limited by rotating signature keys. A >> important point that is different in these scenarios is that under the >> first Alice knows she was removed (a plus) while under the second >> (currently possible) scenario the group simply goes silent and Alice doe= s >> not know if it was malicious or not. All said, it could be worse. That d= oes >> not consider other attack scenarios though, for example when the attacke= r >> gains the signature key but not past state/PSK. >> > > >> > > *I.e. after a potentially passive period, if we are to show how this >> behaves in the PCS scenario. >> > > >> > > This leads to an important question: does our current uniqueness of >> sig key predicate limit the ability to rotate signature keys within a >> group? That is our means of limiting the full state + sig key compromise >> scenario impacts mentioned above, and therefore the means of limiting th= e >> drawbacks of (3). We should make sure that the limiting ability is >> feasible. If that hindered in any way, then I would vote very strongly f= or >> (2) as it at least bootstraps some of the authentication properties from >> the group state in the scenario that the sig key is compromised. >> > > >> > > >> > > All the best, >> > > >> > > Britta >> > > >> > > >> > > >> > > From:MLS on behalf of Richard Barnes < >> rlb@ipv.sx> >> > > Date:Monday, October 4, 2021 at 4:09 PM >> > > To:Messaging Layer Security WG >> > > Subject:[MLS] Resync archaeology + analysis + prognosis >> > > >> > > OK, I think I have traced back some idea of why we removed the >> earlier resync proposal. Here's a little essay on how we got here, a rec= ap >> of the trade-offs, and my thoughts on where we should go. >> > > >> > > tl;dr: Earlier decision not dispositive; we should do basically >> what's in the PR now. >> > > >> > > # History >> > > >> > > The story starts all the way back at the January 2019 interim at >> Mozilla / Mountain View. There was a discussion there of ACK/NACK and >> replay as related issues [1]. That discussion seems to have led to >> agreement that a complete error recovery system was a complex enough top= ic, >> and clearly enough separated from the main protocol that it could be >> handled in a separate specification. As a result, the issues that had be= en >> opened for ACK/NACK and resync were closed [2][3]. When Britta and Konra= d >> posted #336 [4] including a resync mechanism, my review simply cited tha= t >> earlier closed issue as a reason for taking it out [5]. >> > > >> > > One other note with regard to #336 -- It looks to me like the >> "resync" mechanism in there was not really fleshed out enough to be >> implementable. The state linked above was the last state before my revie= w, >> and the word "resync" doesn't actually appear. Instead the PR talks abou= t >> "recovering lost group members" using Add and PSK, which could be >> elaborated to solve a version of this problem, but would require the >> assistance of a continuing member rather than allowing the lost member t= o >> resync unilaterally. It would also have the same issues noted in terms o= f >> new joiners not having resync PSKs. >> > > >> > > Overall, though, reading this history doesn't seem to me like we >> really made a principled decision not to do resync. We just punted after >> some discussion in the abstract, and that stuck. We have a more concrete >> question now. >> > > >> > > # Analysis >> > > >> > > Since the discussion of #336 in 2020, we have added external commit= s >> in order to have groups you can join unilaterally. So regardless of the >> broader question of resync, we have to decide what proposals a joiner is >> allowed to originate in their Commit (sending them by value), in >> particular, whether an external Commit can contain a joiner-originated >> Remove proposal. We have a spectrum of options here: >> > > >> > > 1. Forbid Remove >> > > 2. Allow Remove + require the (identity, endpoint_id) and signature >> key to match the removed node + require resumption PSK >> > > 3. Allow Remove + require the (identity, endpoint_id) and signature >> key to match the removed node >> > > 4. Allow Remove without restriction >> > > >> > > Options (1) and (2) would block an attacker that has compromised a >> member's signature key from joining as that member and evicting the old >> appearance. Option (2) because of the PSK; option (1) because of the >> uniqueness requirements (as Raphael pointed out on the call). >> > > >> > > Options (1) and (2) do not allow a client who has lost everything >> but their signature key to resync. Option (1) would require a new >> endpoint_id and signature key, which might not be feasible in all cases. >> Option (2) would also need to have extra mechanism to account for recent >> joiners not having the required resumption PSK. >> > > >> > > Option (1) would also not allow for resync with just a signature >> key. As Raphael pointed out, because we now require signature keys to be >> unique, the member would have to mint a new signature key and get it >> authenticated, or else their attempt to rejoin would be rejected as a >> duplicate entry. >> > > >> > > Options (3) and (4) would allow a client who has lost everything bu= t >> their signature key to resync, at the risk that an attacker who has >> compromised a member's signature key could abuse it to join as that memb= er >> and evict the old, legitimate appearance. >> > > >> > > # Prognosis >> > > >> > > After this discussion and analysis, I continue to think that (3) >> above is the right answer, with an optional upgade to (2). Proceeding by >> elimination: >> > > >> > > Option (4), while technically feasible, is clearly a little silly. >> There's no reason to allow joiners to do a remove in the same operation = as >> they join; they could do this afterward. >> > > >> > > Option (2) does not seem workable in general because of the >> recent-joiner problem. While mechanism could be designed to provide the = PSK >> to recent joiners, it would add a lot of complexity, and the recent join= ers >> wouldn't get any benefit from it, which dilutes the value of this >> mechanism. (It's not impossible to arrive at the case where everyone >> besides the resync'ing participant is new!) >> > > >> > > With option (1), you lose any notion of resync; I think the need fo= r >> endpoint_id rotation makes this unworkable in practice. And it has kind = of >> an odd notion of security: You are protected against an attacker that ha= s >> compromised a current signature key but can't get a new one authenticate= d. >> This is a problem for the authentication system to handle (e.g., with >> revocation), not for the key exchange -- if you have valid credentials w= ith >> compromised keys floating around, you have bigger problems to solve. So = my >> personal assessment is that (1) doesn't provide a big jump in security o= ver >> (3), assuming you have a functioning authentication system. >> > > >> > > Two side notes about (3): First, if we do (3) but *allow* PSKs, the= n >> an application could opt in to (2). Second, this whole mechanism is opt-= in >> for the application, since you can't do an external commit if a >> PublicGroupState hasn't been published. >> > > >> > > Concretely, my proposal here would be (3) + (2*) -- Allow Remove >> with matching parameters, and allow PSKs so that applications can opt in= to >> (2) where they can make it work. That way, if an application opts in to >> external Commits, they get the benefit of resync and the same >> signature-key-compromise bound on impersonation for resync as well as >> net-new joins. And if an application can figure out how to make (2) work= , >> they can require it. >> > > >> > > Looking forward to others' thoughts here! >> > > >> > > --RLB >> > > >> > > >> > > [1] >> https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.= md#acks-and-nacks-jonm >> ( >> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgith= ub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%= 23acks-and-nacks-jonm&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc4= 4fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857= 931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT= iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6= tCFvcAM3uopMFq4%3D&reserved=3D0 >> ) >> > > [2] https://github.com/mlswg/mls-protocol/issues/92 ( >> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgith= ub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40= nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f757896337= 8e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA= iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCGZls= Hz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=3D0 >> ) >> > > [3] https://github.com/mlswg/mls-protocol/issues/93 ( >> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgith= ub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40= nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f757896337= 8e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA= iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz%2B= eEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=3D0 >> ) >> > > [4] >> https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedc= a7db2d05c57908a292202 >> ( >> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgith= ub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7d= b2d05c57908a292202&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc= 96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931= 864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6= Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08= CkIgGm%2BQ%3D&reserved=3D0 >> ) >> > > [5] >> https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ ( >> https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmail= archive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data= =3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d9= 36231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%= 7C3000&sdata=3DmoUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=3D= 0 >> ) >> > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > --0000000000005075d205cdc68211 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, it sounds like folks are pretty much on the same = "2-plus-optional-3" page.=C2=A0 I'll wait another day or two = before merging to give a chance for any more discussion.

Re: broadening scope -- Let's not.=C2=A0 Pretty much the only fi= rm conclusion out of that history research was WG consensus that a full res= ync solution is a complex enough topic for another draft.=C2=A0 (And IMO wo= uld benefit from some deployment experience with the base protocol.)=C2=A0 = All we're talking about here is how to cover a single resync case that = is easily solved with external commit.=C2=A0 That's not to say the prob= lem isn't worth solving, just that it's beyond the scope of the cor= e protocol.

--RLB

On Wed, Oct 6, 2021= at 1:59 PM Raphael Robert <ie= tf@raphaelrobert.com> wrote:
Thanks Richar= d for digging up all the past history!

I think the optio= ns you listed indeed cover all possibilities and I agree that (4) should be= discarded right away. Option (1) would prohibit any resync mechanism based= on external commits, so it=E2=80=99s obviously a non-starter for the discu= ssion. Giving applications the choice between (2) and (3) generally sounds = reasonable.

I would however like to point out that= all of the options for =E2=80=9Cresync=E2=80=9D are conditional on externa= l commits being allowed (remember that they are generally optional) and tha= t therefore the public group state needs to be available to clients at all = times. This only covers a subset of the possible MLS deployment scenarios a= nd therefore it is not a general resync mechanism. I want to emphasise this= , because I feel we have lost sight of this somehow.

We can decide to leave it at that, bolstered by the sensible argument th= at external commits is the only mechanism that works unilaterally anyway. A= lternatively, we could broaden the scope by also trying to address the scen= arios where external commits are not possible/allowed. An argument in favou= r of it would be that if we don=E2=80=99t broaden it, applications will hav= e to solve it anyway =E2=80=93 possibly doing so by not making the best dec= isions.

In a scenario where external commits are n= ot an option, members that are out-of-sync have no choice but to send an ou= t-of-band distress message to the rest of the group and ask to be removed a= nd subsequently re-added again. This is where we could offer some guidance = at least. PSKs might still be an option here, additionally the distress mes= sage could be encrypted to a group key from a previous epoch.
I would be good to know how others feel about broadening the sc= ope.=C2=A0

Thanks

Raphael=

On Wed, Oct 6, 2021= at 2:05 AM Konrad Kohbrok <konrad.kohbrok@datashrine.de> wrote:
=
Hi,

If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 fo= r now) represent trade-offs in security guarantees and their applicability = depends on the specific deployment scenario. My understanding is that exter= nal joins will be subject to some sort of policy anyway. Should we then be = strict in the spec in terms of what we mandate the exact policy w.r.t. PSKs= is?

Since I don't think either solution represents much of a foot-gun, I pr= opose we include the capability to include resync PSKs in the spec for this= purpose, but don't mandate them. Instead we relegate the policy decisi= on to the application layer and detail the security trade-offs in the archi= tecture document. I realize that delegating decisions to the application la= yer is a bit of a cop-out solution, but I think in this case it makes sense= to include the mechanism in the spec and then let the application decide.<= br>
Cheers,
Konrad

> Richard Barnes <rlb= @ipv.sx> hat am 05.10.2021 04:31 geschrieben:
>
>
> Hi Britta,
>
> Couple of responses inline...
>
>
> On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:=
> > [trimmed]
> > =C2=A0
> > To the present proposed options, I will note that the =E2=80=98ne= w joiners in interim=E2=80=99 case is likely a misleading focus point for t= he discussion, and we should avoid tripping into that ditch for a number of= reasons:
> >=C2=A0 =C2=A0* Notably, if everyone except for the re-syncing part= icipant is new, why not just require the re-syncing participant to be added= as a new member themselves? It is, after all, practically a brand new grou= p at that point.
> >=C2=A0 =C2=A0* It is true that a new member would not gain from a = PSK guarantee, but why should we reduce the guarantees for all other partic= ipants to that of the new joiner? From the view of the new joiner, all part= icipants are new in any case, so e.g. PCS does not have substantial meaning= as of yet. Existing members have more to lose and also have the more to ga= in from PSK use. I do not believe we want to adapt a stance of =E2=80=98if = the new joiner doesn=E2=80=99t get a security guarantee, no one should have= the security guarantee=E2=80=99 =E2=80=93 in fact, the tree structure, com= mit history, and the like provide insight to longer term members that a new= joiner does not have. So (2) offers a new joiner the benefits of (3) but t= o all others an even stronger guarantee.
> >=C2=A0 =C2=A0* As a nod to what a new joiner may gain, we can offe= r the following: if a re-sync PSK fails, then whichever existing member che= cks and notes the PSK failure should initiate a removal of the resyncing me= mber. If there is a new joiner, then by continued presence of the re-syncin= g member they gain the guarantee that at least one other group member has p= reviously seen that member, or else would have ejected them (assuming that = the checker is online).
> I don't mean to over-rotate on this case, but software being softw= are, we need an algorithm to implement that covers all the cases. While the= "everyone is new" scenario is outlandish, it wouldn't be all= that surprising to have one or two new members, so it's a case that wo= uld need addressing. The seemingly most obvious approach to addressing this= problem is to encrypt the PSK to new members, which requires you at least = have enough state to figure out who the new members are.
>
> It also occurs to me now that the PSK approach presumes that you know = when your state went bad, since you would want to use a PSK from before tha= t point. In Raphael's example where persistent storage is corrupted, al= l you know is that messages stopped decrypting, which gives you an upper bo= und on the time of corruption, but not really a way to go back and figure o= ut what's good.
>
>
> > The security goal in the balance here is PCS. Adding a re-sync op= tion of any of the varieties (2)-(4) would break that to some degree, since= following a compromise and passive period the adversary is then enabled to= regain a foothold. The question is how much of a degree of loss are we wil= ling to tolerate.
>
> I'm not sure I would really characterize this as a PCS violation. = PCS is a guarantee that you get when you take a certain action. For example= , when a member issue an Update or a Commit with a fresh HPKE key pair, you= should get PCS with regard to that participant's HPKE key pair; likewi= se with rotating signature keys. Here, the signature key has not been rotat= ed, so there's no PCS boundary.
>
> It is worth considering whether this mechanism gives the attacker any = additional capabilities in the event that (1) the signature key is compromi= sed, and (2) the compromised member issues an Update or Commit rotating the= signature key. ISTM that you still get PCS there in option (3), since the = requirement that the signature keys match ensures that the old, compromised= signature key is not allowed to resync back into the group. There's st= ill a risk that the compromised key / credential could be used for a fresh,= non-resync join, but that's an inherent risk with external Commit / fr= eely joinable groups, and also an opportunity for the AS's revocation/i= nvalidation system to help.
>
> Will take a look at the remainder in the morning...
>
> --RLB
>
>
> >=C2=A0 =C2=A0* I agree that (4) is an immediate discard.
> >=C2=A0 =C2=A0* Under (2) a PSK use, the PSK use at least more limi= ted due to the proof of knowledge of a past state (e.g. notes above). This = is a worthwhile property to enforce in my view since it balances authentica= tion across two vectors: the signature key and knowledge of group state. Ad= versary access to only one or the other is insufficient for the adversary t= o eject Alice and replace her in the group.
> >=C2=A0 =C2=A0* Under (3), the attack scenario of Eve compromising = Alice (full state + sig key), followed eventually* by removing Alice while = adding herself, is not dissimilar from the attack scenario of Eve compromis= ing Alice full state + sig key) followed eventually* by providing an impers= onating update in Alice=E2=80=99s name. What has been shown so far is that = this type of scenario can be limited by rotating signature keys. A importan= t point that is different in these scenarios is that under the first Alice = knows she was removed (a plus) while under the second (currently possible) = scenario the group simply goes silent and Alice does not know if it was mal= icious or not. All said, it could be worse. That does not consider other at= tack scenarios though, for example when the attacker gains the signature ke= y but not past state/PSK.
> > =C2=A0
> > *I.e. after a potentially passive period, if we are to show how t= his behaves in the PCS scenario.
> > =C2=A0
> > This leads to an important question: does our current uniqueness = of sig key predicate limit the ability to rotate signature keys within a gr= oup? That is our means of limiting the full state + sig key compromise scen= ario impacts mentioned above, and therefore the means of limiting the drawb= acks of (3). We should make sure that the limiting ability is feasible. If = that hindered in any way, then I would vote very strongly for (2) as it at = least bootstraps some of the authentication properties from the group state= in the scenario that the sig key is compromised.
> > =C2=A0
> > =C2=A0
> > All the best,
> > =C2=A0
> > Britta
> > =C2=A0
> > =C2=A0
> > =C2=A0
> > From:MLS <mls-bounces@ietf.org> on behalf of Richard Barnes <rlb@ipv.sx>
> >=C2=A0 Date:Monday, October 4, 2021 at 4:09 PM
> >=C2=A0 To:Messaging Layer Security WG <mls@ietf.org>
> >=C2=A0 Subject:[MLS] Resync archaeology + analysis + prognosis
> > =C2=A0
> > OK, I think I have traced back some idea of why we removed the ea= rlier resync proposal. Here's a little essay on how we got here, a reca= p of the trade-offs, and my thoughts on where we should go.
> > =C2=A0
> > tl;dr: Earlier decision not dispositive; we should do basically w= hat's in the PR now.
> >
> >=C2=A0 # History
> >=C2=A0
> >=C2=A0 The story starts all the way back at the January 2019 inter= im at Mozilla / Mountain View. There was a discussion there of ACK/NACK and= replay as related issues [1]. That discussion seems to have led to agreeme= nt that a complete error recovery system was a complex enough topic, and cl= early enough separated from the main protocol that it could be handled in a= separate specification. As a result, the issues that had been opened for A= CK/NACK and resync were closed [2][3]. When Britta and Konrad posted #336 [= 4] including a resync mechanism, my review simply cited that earlier closed= issue as a reason for taking it out [5].
> >=C2=A0
> >=C2=A0 One other note with regard to #336 -- It looks to me like t= he "resync" mechanism in there was not really fleshed out enough = to be implementable. The state linked above was the last state before my re= view, and the word "resync" doesn't actually appear. Instead = the PR talks about "recovering lost group members" using Add and = PSK, which could be elaborated to solve a version of this problem, but woul= d require the assistance of a continuing member rather than allowing the lo= st member to resync unilaterally. It would also have the same issues noted = in terms of new joiners not having resync PSKs.
> >=C2=A0
> >=C2=A0 Overall, though, reading this history doesn't seem to m= e like we really made a principled decision not to do resync. We just punte= d after some discussion in the abstract, and that stuck. We have a more con= crete question now.
> >=C2=A0
> >=C2=A0 # Analysis
> >=C2=A0
> >=C2=A0 Since the discussion of #336 in 2020, we have added externa= l commits in order to have groups you can join unilaterally. So regardless = of the broader question of resync, we have to decide what proposals a joine= r is allowed to originate in their Commit (sending them by value), in parti= cular, whether an external Commit can contain a joiner-originated Remove pr= oposal. We have a spectrum of options here:
> >=C2=A0
> >=C2=A0 1. Forbid Remove
> >=C2=A0 2. Allow Remove + require the (identity, endpoint_id) and s= ignature key to match the removed node + require resumption PSK
> >=C2=A0 3. Allow Remove + require the (identity, endpoint_id) and s= ignature key to match the removed node
> >=C2=A0 4. Allow Remove without restriction
> >=C2=A0
> >=C2=A0 Options (1) and (2) would block an attacker that has compro= mised a member's signature key from joining as that member and evicting= the old appearance. Option (2) because of the PSK; option (1) because of t= he uniqueness requirements (as Raphael pointed out on the call).
> >=C2=A0
> >=C2=A0 Options (1) and (2) do not allow a client who has lost ever= ything but their signature key to resync. Option (1) would require a new en= dpoint_id and signature key, which might not be feasible in all cases. Opti= on (2) would also need to have extra mechanism to account for recent joiner= s not having the required resumption PSK.
> >=C2=A0
> >=C2=A0 Option (1) would also not allow for resync with just a sign= ature key. As Raphael pointed out, because we now require signature keys to= be unique, the member would have to mint a new signature key and get it au= thenticated, or else their attempt to rejoin would be rejected as a duplica= te entry.
> >=C2=A0
> >=C2=A0 Options (3) and (4) would allow a client who has lost every= thing but their signature key to resync, at the risk that an attacker who h= as compromised a member's signature key could abuse it to join as that = member and evict the old, legitimate appearance.
> >=C2=A0
> >=C2=A0 # Prognosis
> >=C2=A0
> >=C2=A0 After this discussion and analysis, I continue to think tha= t (3) above is the right answer, with an optional upgade to (2). Proceeding= by elimination:
> >=C2=A0
> >=C2=A0 Option (4), while technically feasible, is clearly a little= silly. There's no reason to allow joiners to do a remove in the same o= peration as they join; they could do this afterward.
> >=C2=A0
> >=C2=A0 Option (2) does not seem workable in general because of the= recent-joiner problem. While mechanism could be designed to provide the PS= K to recent joiners, it would add a lot of complexity, and the recent joine= rs wouldn't get any benefit from it, which dilutes the value of this me= chanism. (It's not impossible to arrive at the case where everyone besi= des the resync'ing participant is new!)
> >=C2=A0
> >=C2=A0 With option (1), you lose any notion of resync; I think the= need for endpoint_id rotation makes this unworkable in practice. And it ha= s kind of an odd notion of security: You are protected against an attacker = that has compromised a current signature key but can't get a new one au= thenticated. This is a problem for the authentication system to handle (e.g= ., with revocation), not for the key exchange -- if you have valid credenti= als with compromised keys floating around, you have bigger problems to solv= e. So my personal assessment is that (1) doesn't provide a big jump in = security over (3), assuming you have a functioning authentication system. > >=C2=A0
> >=C2=A0 Two side notes about (3): First, if we do (3) but *allow* P= SKs, then an application could opt in to (2). Second, this whole mechanism = is opt-in for the application, since you can't do an external commit if= a PublicGroupState hasn't been published.
> >=C2=A0
> >=C2=A0 Concretely, my proposal here would be (3) + (2*) -- Allow R= emove with matching parameters, and allow PSKs so that applications can opt= in to (2) where they can make it work. That way, if an application opts in= to external Commits, they get the benefit of resync and the same signature= -key-compromise bound on impersonation for resync as well as net-new joins.= And if an application can figure out how to make (2) work, they can requir= e it.
> >=C2=A0
> >=C2=A0 Looking forward to others' thoughts here!
> >=C2=A0
> >=C2=A0 --RLB
> >=C2=A0
> >=C2=A0
> >=C2=A0 [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-= 01/minutes.md#acks-and-nacks-jonm (https://nam10.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-mate= rials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&am= p;data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5= %7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%= 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C3000&sdata=3D%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%= 3D&reserved=3D0)
> >=C2=A0 [2] https://github.com/mlswg/mls-prot= ocol/issues/92 (https://nam10.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-pr= otocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30= cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689= 857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCGZlsHz%2BO2cVPG7eUT= UjzoLhzQ0fniz%2Fblmc%3D&reserved=3D0)
> >=C2=A0 [3] https://github.com/mlswg/mls-prot= ocol/issues/93 (https://nam10.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-pr= otocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30= cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689= 857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC= JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz%2BeEwklYbp4NQmFcU= eHBGmAh0jKBRC05CyVBs%3D&reserved=3D0)
> >=C2=A0 [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49a= cce01dcedca7db2d05c57908a292202 (https://nam10.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2= Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=3D0= 4%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d93623= 1a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZs= b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30= 00&sdata=3D0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reser= ved=3D0)
> >=C2=A0 [5] https://ma= ilarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ (https://nam10.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fm= sg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=3D04%7C01%7Cbritta.hale%= 40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963= 378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM= DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DmoUAZJ= 3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=3D0)
_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

<= /div> --0000000000005075d205cdc68211-- From nobody Thu Oct 7 10:46:22 2021 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 EC9123A0CCD for ; Thu, 7 Oct 2021 10:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 ghCE2pnfZ3fe for ; Thu, 7 Oct 2021 10:46:11 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2089.outbound.protection.outlook.com [40.107.243.89]) (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 53ADD3A0CC3 for ; Thu, 7 Oct 2021 10:46:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oe2Vf0KX3V2FiWcWmT4IF07oDjR60nDmqkoPL+hA+O9ko4pMGFj+d4vcwCgs3SDUGSsM5Fd4ZcQY0GQGMJgRqm4h0da1D3Wj7AEo+ruNHVTbJSjQFLiNRoUEWJiiqNurzlCN8uN9TuS3dR4y2antz7Yl73bSfY9yGC38fNTluuf3CYvDtfc7Rry0z+rAwsXhtMitbqlTsNvMGD/ub1Wy7kj6rKKs2No2b2vmp8drnGZPk6lKTKuVNJFpL+dsYLPQauFIwe9hKQ/Xoj+2qbACVmJZW6meF3XIgnnbbWdHZAStJ/drxruzzS5cpPYSKlMaxjRVa5r1YBmeYf8K82+MxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SwB+J4RXUe0yG/bFpcCBhn7tIZb43PdvkL1FOxN33N8=; b=HG/ByhJ3BbykfsYCd/JOhUv8N2EQ1VUfw9dxm6bx8XDOtZLTtIOWMm6aKr+EKsjnA1cVuPVa5ZoqMlE6MWYY8coQfpMyDSXZjx2k1RFWNIkU7V3dz0ZC078RHvRttcbudu0WmC9kHmLzawRiR5adVHzY2MUh6NF95MTdrr5CirsQLt7rph0o/RSYH3M01YER1Y5dyQ6wqmb0Xeof1yqedLV78emoGQ2cC0pUWMBQSkQ8hEFKwFeo0fXJ3saDrlGoJ5WVjPsiUTNFOjv22c7KgZg0u1KF8wskVYMB8iSvjgGEGS+jUzX5/hQb/3tmX+Vd8xMljmZ4j2dq548zSS8XXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3348.namprd13.prod.outlook.com (2603:10b6:a03:1aa::23) by BYAPR13MB2565.namprd13.prod.outlook.com (2603:10b6:a02:cc::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.15; Thu, 7 Oct 2021 17:46:04 +0000 Received: from BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::d8e0:3c03:4413:3677]) by BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::d8e0:3c03:4413:3677%3]) with mapi id 15.20.4587.018; Thu, 7 Oct 2021 17:46:04 +0000 From: "Hale, Britta (CIV)" To: Richard Barnes , Konrad Kohbrok CC: Messaging Layer Security WG Thread-Topic: [MLS] Resync archaeology + analysis + prognosis Thread-Index: AQHXuXTwvWYe4kyU9EeV1eVric9LDqvDG2QAgACT6ICAAc4VAIAApOsAgAE71wA= Date: Thu, 7 Oct 2021 17:46:04 +0000 Message-ID: <62F15B75-6329-4EFC-91AD-31C963214DD5@nps.edu> References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> <1698663123.17469.1633500322380@office.mailbox.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=nps.edu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbe757c9-28ca-446c-1730-08d989ba55c4 x-ms-traffictypediagnostic: BYAPR13MB2565: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WjAWv0mep9blBjvUH06fuVK1SQ8icyHCfooOwGbo3F/cL+OmX/0NT7teNfveCpqsoVVfpSIgiFGB3J16cdd4neOtllu6OT38r0cLv2FKnugurNeNAetV7hdnc985311vEzp8r4skkJYIpUgjErNqpCvlGFROb6t/FW/26D6mhk/221EDX35Xs2fGCzlcmkKW/UaCeq8IibH/gDHxFAK6nXnrDBnkBei/6a5PcegDiksyXV7+wS+ki+cLq0Ll9HOyWSC9GbPjWyQ/SE8QqH90cCl3Er1Rsw8g127jffhSqYgagTJsGKWy8F/JZ7W6F2R2+Y45CCiLwoUEFhHEfnuMdM5dxFLB1Te1YHcNmmTa1KoClgyWXUic7b1uHnUHGRQWEKIlw9AcdsYDzxnR6T/bjt6TPmm3472hhuABSl29rGu9n1oWxz4G0FimcRf+eZqYMz80HGPvBWkoNmYCyILHaSc9r8WO2pJFXYlUpmFXZ6ZxtQdUq9V/d9kJzHNYMnI9/QqPbilhKWrU3zE+QjSYX7K85PQOQYf2MuTPsRqeKAeQJc2xi2eDsStbzS2AbWwSXZMQ3CTVkf+RExr4qZ7DkOjjgONPY1Ui0iSBz21EyUctXVrIsLHx9oKkIUuDqpPtdAFqKSe7kMxy6FgtsgSzd84+rggIP9YU1+nBX0S0RfctP6bIxXWpulBZyNgGpzL9+vOTnj3zm68OCJmTSPiGl9wDYhQOUSCV/LpccjkuTtOKz1j5f39jUCv2pOpMZi95G9g4Pa4K/sk8XNs7ZypCU4YJwtWzdm136o8EDa91OfcJDYTaUwIfA66Uy9022kEp3t5f012WnlbUaHvbViez7meP6hBwCW8nwOVTjLgb+sQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3348.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(966005)(2906002)(508600001)(6486002)(110136005)(45080400002)(86362001)(36756003)(8676002)(786003)(316002)(8936002)(33656002)(26005)(38100700002)(122000001)(30864003)(186003)(71200400001)(38070700005)(4326008)(166002)(2616005)(5660300002)(76116006)(91956017)(83380400001)(75432002)(6512007)(53546011)(6506007)(66556008)(66476007)(64756008)(66946007)(66446008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UysrMDdLQmloeGZwd3YvR3ZnVFpscVVLRFBpZWRZdGVybVJIeCsvNnZuVkRo?= =?utf-8?B?MHhRY3lBYisrd3NnUEw0UXhnT20ycEJLVWkzRzU2OUpSVjVWMmdOQlAvQmUr?= =?utf-8?B?cTlQdmc4elovVDIwS0JMeUJUd3JoTVRnTk50NlhqaFlCMUtJelYzLzZIc0hD?= =?utf-8?B?eEF1Um8ybGNNR2I4UE1Fb1dwckpWa2tBUmdMT1lmRWJQVE4ybkcvVnVTQkJy?= =?utf-8?B?SmtTMlBVUHNsMDJJYytUVEV2dWZ6SkhiMENWNzlySmlWdEE0Ukg3UldOVUFE?= =?utf-8?B?TFMzK2VqSW0zTmIwUmNzUnRrdkVHaVQ5TFNZRU9DZnhCVm9oQkxyN215VERl?= =?utf-8?B?N1ljTFpPbDFKZjVKSXlKVFNTeG1tMDhlL0RhdU8wa1d3cC9aUXR5TlI3eVEx?= =?utf-8?B?U0RZeTFTaWdlRnRUSTBRdUJXcmExdXQvUmxXSUs5RkIxeTlwOVFMUERDaVBs?= =?utf-8?B?ekxhaWRtQmtGdktYdU5MMlJJYVlnazhVMjVicHp0TjZROUlnRlNIZFFjb01i?= =?utf-8?B?Wm9TOTV1RGxuVmNrRUlXUGQrZ3EvM25XbWpLUVlpZEhIcVlEZzhYTW1WYnIv?= =?utf-8?B?ekF2VWJpMC9wM2twVmtNTGtBbDh5blZZL3pKdG44TFhnWDMyYXFGQi9LSEpK?= =?utf-8?B?SFlWaTNKWEJYNHB2M0o5SjJmMG5IK0RQLy92SnEwUjlzdjdQaUZVQkZIQlhE?= =?utf-8?B?N1BRaStzeGJqU0ZxZnpjT1R2eVhuYUl2RHlTTlp0ZllMbUN4NUVMT1dMNUF6?= =?utf-8?B?WHFuTUNaVGc5cHQydWwyQTJ3Q3VYOVY1WnJTMnh3Z0lnVk1XYStuclE5YkQ2?= =?utf-8?B?U01LeG1md2pUT1lyWHNmd3JLcWdza1pPekhKejNVcE1MZm1uM0ZrK1pxRytl?= =?utf-8?B?STZ0VzZuWEpiN3U5bWpIaWtxYkZMZFpKekNEbE1kUCt6eWtsbFozY1pid0ty?= =?utf-8?B?VkpYdCs1dWJUcU5mSDJqektxOE5PdjY1Ry9zR2paQVpoU0daSG5xdzdVOWE1?= =?utf-8?B?bjAwaGNlQ0JwdWNpTS9DS1RvNTFGMURPbWlSZ1dJQVAxdXdTbUI1SjdJYm1V?= =?utf-8?B?cVNIaG1tNERZQUtXZGJpMG1NeXQyaS9iMVF6bkpqMXNrRERtMmJJanNxRHRQ?= =?utf-8?B?Vjl6TkZEeW1VWG9xM0kzZ3ptYkV2UlJhQThOOGUrMVU4emZmMEFGK1htTmtJ?= =?utf-8?B?eEt1TXFMOFFyc2Z6UDU0L01Vb08yQnBpZ3dEQW5SL2ZsZWxQbURiUnBMSDh0?= =?utf-8?B?WFhxV1RMcEJrZUtreHVpUVp3NVdyN2NCU0RBVy8zSjdqd0NHd242bHJ0Z0tX?= =?utf-8?B?Q1JTWG0wT09KZDM5WkFNZkdTU1h5ZzRYUTRnT21EVVBXbk9hTXZjK1R6ZmVs?= =?utf-8?B?V2gyVk9mUStvYkMxdmNZSGtseC9IV214YjNud0RVOHA0dGJNQnAwNVM3VWpH?= =?utf-8?B?cmxxYWU3aS9iYkR3c0lmTVFZNnAwczZyVDA0ZXE0ZzZyYmhGWktsUUxubVNz?= =?utf-8?B?T3Z0R1Z1VjJJUmFwRGJ3MUFRYS95Tmp5NEJFaGFZNi9UT0x4RDBtVldINzBQ?= =?utf-8?B?c0RwdmpiZkluRVh4OXJvZlNQNTBBVlhzVkVla1d1SnExVkNJb0ZLSHRXK3Rw?= =?utf-8?B?bytuRVJsbDRmaHdkb2Q5L0xYUEM4M0pFdFMvVy91K2tiUzdjUzdYWnA1TmZK?= =?utf-8?B?K2xyRnFuNWEwZ0FnTkFPWmwyOEplT1dVRG1SWlJ5TXJwN2ZhLzRUTUc5MWN4?= =?utf-8?B?eXNBWTlLNGU1ZldJeTUyNzVjVnp2MUowSE1LTTJHTWYwUUpiYmRpSmJTWC81?= =?utf-8?B?OU1VU1hwenNZdXVQMlRhQT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_62F15B7563294EFC91AD31C963214DD5npsedu_" MIME-Version: 1.0 X-OriginatorOrg: nps.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbe757c9-28ca-446c-1730-08d989ba55c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 17:46:04.4892 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Lo05UaAqkD/M6aD0AcMDcSDmySDqgxsSQ9EPJn5ZCA3nZdLN1Rb/VTsc6scL7Uf6RAZsYHc+3w60BOzqc3mXnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2565 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 205.155.65.226 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: BYAPR13MB2565.namprd13.prod.outlook.com Archived-At: Subject: Re: [MLS] Resync archaeology + analysis + prognosis 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, 07 Oct 2021 17:46:17 -0000 --_000_62F15B7563294EFC91AD31C963214DD5npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBzb3VuZHMgcmVhc29uYWJsZSB0byBtZSBhcyBhIHdheSBmb3J3YXJkLg0KDQpUaGUgcXVl c3Rpb24gcG9zZWQgYmVmb3JlICjigJxUaGlzIGxlYWRzIHRvIGFuIGltcG9ydGFudCBxdWVzdGlv bjogZG9lcyBvdXIgY3VycmVudCB1bmlxdWVuZXNzIG9mIHNpZyBrZXkgcHJlZGljYXRlIGxpbWl0 IHRoZSBhYmlsaXR5IHRvIHJvdGF0ZSBzaWduYXR1cmUga2V5cyB3aXRoaW4gYSBncm91cD8gVGhh dCDigKYgW2lzIHdoYXQgbGltaXRzXSB0aGUgZHJhd2JhY2tzIG9mICgzKS7igJ0pIHN0aWxsIHN0 YW5kcy4gSSBkbyBub3QgdGhpbmsgdGhpcyBpbmhpYml0cyBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRo ZSBQUiwgYnV0IGl0IGlzIGltcG9ydGFudCB0byBhZGRyZXNzLiBJZiB0aGVyZSBpcyBhIHRyYWRl LW9mZiBiZXR3ZWVuIGFuIGltcGxlbWVudGF0aW9uIGFsbG93aW5nIHJlbW92ZStyZXN5bmMgYW5k IHJvdGF0aW5nIG91dCBzaWduYXR1cmUga2V5cywgdGhlbiB0aGF0IHNob3VsZCBiZSBub3RlZCBp biB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGlmIG5vdCB0aGUgcHJvdG9jb2wgc3BlYyBpdHNl bGYuIFdlIGFyZSBub3QgZ29pbmcgdG8gZ28gdGhyb3VnaCBhbGwgdGhlIHBvc3NpYmxlIG9wdGlv bnMgZm9yIGltcGxlbWVudGF0aW9uLCBidXQgd2hlbiB0aGVyZSBpcyBzaWduaWZpY2FudCBzcGFj ZSBpbiB0aGUgcHJvdG9jb2wgc3BlYyBkZXZvdGVkIHRvIGFuIG9wdGlvbmFsIGZ1bmN0aW9uYWxp dHkgKGUuZy4gZXh0ZXJuYWwgY29tbWl0cyBhbmQgcmVzeW5jKSB0aGVuIGl0IHdvdWxkIGJlIGdv b2QgdG8gbm90ZSB0cmFkZS1vZmZzIHRoYXQgd2lsbCBjb21lIHdpdGggaXQuIFdlIHdvdWxkIG5v dCBoYXZlIGEgd2VsbC13cml0dGVuIHNwZWNpZmljYXRpb24gaWYgaXQgY291bGQgcG90ZW50aWFs bHkgbGVhZCBhbiBpbXBsZW1lbnRvciBmYXIgZG93biBvbmUgb3B0aW9uYWwgcGF0aCB0aGF0IHBy ZWNsdWRlcyBkZXNpcmVkIHNlY3VyaXR5IGd1YXJhbnRlZXMsIGFuZCBnaXZlcyBubyBjb250ZXh0 IG9uIHRoYXQgKGkuZS4gbGV04oCZcyB0cnkgdG8gbWluaW1pemUgb2J2aW91cyBjYXNlcyBvZiDi gJxJIHdpc2ggSSBoYWQga25vd27igKbigJ0gZm9yIGltcGxlbWVudG9ycykuDQoNCkJyaXR0YQ0K DQoNCkZyb206IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KRGF0ZTogV2VkbmVzZGF5LCBP Y3RvYmVyIDYsIDIwMjEgYXQgODo1NSBBTQ0KVG86IEtvbnJhZCBLb2hicm9rIDxrb25yYWQua29o YnJva0BkYXRhc2hyaW5lLmRlPg0KQ2M6ICJIYWxlLCBCcml0dGEgKENJVikiIDxicml0dGEuaGFs ZUBucHMuZWR1PiwgTWVzc2FnaW5nIExheWVyIFNlY3VyaXR5IFdHIDxtbHNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW01MU10gUmVzeW5jIGFyY2hhZW9sb2d5ICsgYW5hbHlzaXMgKyBwcm9nbm9z aXMNCg0KDQpJJ3ZlIHVwZGF0ZWQgdGhlIFBSIHRvIGRvIGJhc2ljYWxseSB3aGF0IEtvbnJhZCBw cm9wb3Nlcy4gIE5hbWVseSwgYWxsb3cgUmVtb3ZlLCBidXQgc3VnZ2VzdCB0aGF0IGFwcGxpY2F0 aW9ucyBjYW4gYXBwbHkgYWRkaXRpb25hbCBjb25zdHJhaW50cy4NCg0KaHR0cHM6Ly9naXRodWIu Y29tL21sc3dnL21scy1wcm90b2NvbC9wdWxsLzQ4MS9maWxlcyNkaWZmLTdjMzY5Yjg1YjI2YTc0 NmE3ZTcwY2QyODg0MDM3ODk2ZGVmZTAzYjMwOThiZWM5NzZmNzljOTk0ZDIyYTYwNGFSMjg3Mzxo dHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wlMkZwdWxsJTJGNDgxJTJG ZmlsZXMlMjNkaWZmLTdjMzY5Yjg1YjI2YTc0NmE3ZTcwY2QyODg0MDM3ODk2ZGVmZTAzYjMwOThi ZWM5NzZmNzljOTk0ZDIyYTYwNGFSMjg3MyZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5w cy5lZHUlN0MwMGMzMGJjNWQ1ODc0NGNjMTk5MDA4ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQw ZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTEzMjU1NDkzMTk0ODMlN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRp STZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT0wMW10cTBLUzNGRG5aWjFKeXln RDhSWEtvOU42MUJ3ZGxVWXVxJTJGeE9zUW8lM0QmcmVzZXJ2ZWQ9MD4NCg0KQnJpdHRhLCBkb2Vz IHRoYXQgd29yayBmb3IgeW91Pw0KDQpPbiBXZWQsIE9jdCA2LCAyMDIxIGF0IDI6MDUgQU0gS29u cmFkIEtvaGJyb2sgPGtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU8bWFpbHRvOmtvbnJhZC5r b2hicm9rQGRhdGFzaHJpbmUuZGU+PiB3cm90ZToNCkhpLA0KDQpJZiBJIHVuZGVyc3RhbmQgY29y cmVjdGx5LCB0aGUgc29sdXRpb25zICgyKSBhbmQgKDMpIChkaXNjYXJkaW5nIDEgYW5kIDQgZm9y IG5vdykgcmVwcmVzZW50IHRyYWRlLW9mZnMgaW4gc2VjdXJpdHkgZ3VhcmFudGVlcyBhbmQgdGhl aXIgYXBwbGljYWJpbGl0eSBkZXBlbmRzIG9uIHRoZSBzcGVjaWZpYyBkZXBsb3ltZW50IHNjZW5h cmlvLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZXh0ZXJuYWwgam9pbnMgd2lsbCBiZSBzdWJq ZWN0IHRvIHNvbWUgc29ydCBvZiBwb2xpY3kgYW55d2F5LiBTaG91bGQgd2UgdGhlbiBiZSBzdHJp Y3QgaW4gdGhlIHNwZWMgaW4gdGVybXMgb2Ygd2hhdCB3ZSBtYW5kYXRlIHRoZSBleGFjdCBwb2xp Y3kgdy5yLnQuIFBTS3MgaXM/DQoNClNpbmNlIEkgZG9uJ3QgdGhpbmsgZWl0aGVyIHNvbHV0aW9u IHJlcHJlc2VudHMgbXVjaCBvZiBhIGZvb3QtZ3VuLCBJIHByb3Bvc2Ugd2UgaW5jbHVkZSB0aGUg Y2FwYWJpbGl0eSB0byBpbmNsdWRlIHJlc3luYyBQU0tzIGluIHRoZSBzcGVjIGZvciB0aGlzIHB1 cnBvc2UsIGJ1dCBkb24ndCBtYW5kYXRlIHRoZW0uIEluc3RlYWQgd2UgcmVsZWdhdGUgdGhlIHBv bGljeSBkZWNpc2lvbiB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYW5kIGRldGFpbCB0aGUgc2Vj dXJpdHkgdHJhZGUtb2ZmcyBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiBJIHJlYWxpemUg dGhhdCBkZWxlZ2F0aW5nIGRlY2lzaW9ucyB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIgaXMgYSBi aXQgb2YgYSBjb3Atb3V0IHNvbHV0aW9uLCBidXQgSSB0aGluayBpbiB0aGlzIGNhc2UgaXQgbWFr ZXMgc2Vuc2UgdG8gaW5jbHVkZSB0aGUgbWVjaGFuaXNtIGluIHRoZSBzcGVjIGFuZCB0aGVuIGxl dCB0aGUgYXBwbGljYXRpb24gZGVjaWRlLg0KDQpDaGVlcnMsDQpLb25yYWQNCg0KPiBSaWNoYXJk IEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86cmxiQGlwdi5zeD4+IGhhdCBhbSAwNS4xMC4yMDIx IDA0OjMxIGdlc2NocmllYmVuOg0KPg0KPg0KPiBIaSBCcml0dGEsDQo+DQo+IENvdXBsZSBvZiBy ZXNwb25zZXMgaW5saW5lLi4uDQo+DQo+DQo+IE9uIE1vbiwgT2N0IDQsIDIwMjEgYXQgODo0MiBQ TSBIYWxlLCBCcml0dGEgKENJVikgPGJyaXR0YS5oYWxlQG5wcy5lZHU8bWFpbHRvOmJyaXR0YS5o YWxlQG5wcy5lZHU+PiB3cm90ZToNCj4gPiBbdHJpbW1lZF0NCj4gPg0KPiA+IFRvIHRoZSBwcmVz ZW50IHByb3Bvc2VkIG9wdGlvbnMsIEkgd2lsbCBub3RlIHRoYXQgdGhlIOKAmG5ldyBqb2luZXJz IGluIGludGVyaW3igJkgY2FzZSBpcyBsaWtlbHkgYSBtaXNsZWFkaW5nIGZvY3VzIHBvaW50IGZv ciB0aGUgZGlzY3Vzc2lvbiwgYW5kIHdlIHNob3VsZCBhdm9pZCB0cmlwcGluZyBpbnRvIHRoYXQg ZGl0Y2ggZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnM6DQo+ID4gICAqIE5vdGFibHksIGlmIGV2ZXJ5 b25lIGV4Y2VwdCBmb3IgdGhlIHJlLXN5bmNpbmcgcGFydGljaXBhbnQgaXMgbmV3LCB3aHkgbm90 IGp1c3QgcmVxdWlyZSB0aGUgcmUtc3luY2luZyBwYXJ0aWNpcGFudCB0byBiZSBhZGRlZCBhcyBh IG5ldyBtZW1iZXIgdGhlbXNlbHZlcz8gSXQgaXMsIGFmdGVyIGFsbCwgcHJhY3RpY2FsbHkgYSBi cmFuZCBuZXcgZ3JvdXAgYXQgdGhhdCBwb2ludC4NCj4gPiAgICogSXQgaXMgdHJ1ZSB0aGF0IGEg bmV3IG1lbWJlciB3b3VsZCBub3QgZ2FpbiBmcm9tIGEgUFNLIGd1YXJhbnRlZSwgYnV0IHdoeSBz aG91bGQgd2UgcmVkdWNlIHRoZSBndWFyYW50ZWVzIGZvciBhbGwgb3RoZXIgcGFydGljaXBhbnRz IHRvIHRoYXQgb2YgdGhlIG5ldyBqb2luZXI/IEZyb20gdGhlIHZpZXcgb2YgdGhlIG5ldyBqb2lu ZXIsIGFsbCBwYXJ0aWNpcGFudHMgYXJlIG5ldyBpbiBhbnkgY2FzZSwgc28gZS5nLiBQQ1MgZG9l cyBub3QgaGF2ZSBzdWJzdGFudGlhbCBtZWFuaW5nIGFzIG9mIHlldC4gRXhpc3RpbmcgbWVtYmVy cyBoYXZlIG1vcmUgdG8gbG9zZSBhbmQgYWxzbyBoYXZlIHRoZSBtb3JlIHRvIGdhaW4gZnJvbSBQ U0sgdXNlLiBJIGRvIG5vdCBiZWxpZXZlIHdlIHdhbnQgdG8gYWRhcHQgYSBzdGFuY2Ugb2Yg4oCY aWYgdGhlIG5ldyBqb2luZXIgZG9lc27igJl0IGdldCBhIHNlY3VyaXR5IGd1YXJhbnRlZSwgbm8g b25lIHNob3VsZCBoYXZlIHRoZSBzZWN1cml0eSBndWFyYW50ZWXigJkg4oCTIGluIGZhY3QsIHRo ZSB0cmVlIHN0cnVjdHVyZSwgY29tbWl0IGhpc3RvcnksIGFuZCB0aGUgbGlrZSBwcm92aWRlIGlu c2lnaHQgdG8gbG9uZ2VyIHRlcm0gbWVtYmVycyB0aGF0IGEgbmV3IGpvaW5lciBkb2VzIG5vdCBo YXZlLiBTbyAoMikgb2ZmZXJzIGEgbmV3IGpvaW5lciB0aGUgYmVuZWZpdHMgb2YgKDMpIGJ1dCB0 byBhbGwgb3RoZXJzIGFuIGV2ZW4gc3Ryb25nZXIgZ3VhcmFudGVlLg0KPiA+ICAgKiBBcyBhIG5v ZCB0byB3aGF0IGEgbmV3IGpvaW5lciBtYXkgZ2Fpbiwgd2UgY2FuIG9mZmVyIHRoZSBmb2xsb3dp bmc6IGlmIGEgcmUtc3luYyBQU0sgZmFpbHMsIHRoZW4gd2hpY2hldmVyIGV4aXN0aW5nIG1lbWJl ciBjaGVja3MgYW5kIG5vdGVzIHRoZSBQU0sgZmFpbHVyZSBzaG91bGQgaW5pdGlhdGUgYSByZW1v dmFsIG9mIHRoZSByZXN5bmNpbmcgbWVtYmVyLiBJZiB0aGVyZSBpcyBhIG5ldyBqb2luZXIsIHRo ZW4gYnkgY29udGludWVkIHByZXNlbmNlIG9mIHRoZSByZS1zeW5jaW5nIG1lbWJlciB0aGV5IGdh aW4gdGhlIGd1YXJhbnRlZSB0aGF0IGF0IGxlYXN0IG9uZSBvdGhlciBncm91cCBtZW1iZXIgaGFz IHByZXZpb3VzbHkgc2VlbiB0aGF0IG1lbWJlciwgb3IgZWxzZSB3b3VsZCBoYXZlIGVqZWN0ZWQg dGhlbSAoYXNzdW1pbmcgdGhhdCB0aGUgY2hlY2tlciBpcyBvbmxpbmUpLg0KPiBJIGRvbid0IG1l YW4gdG8gb3Zlci1yb3RhdGUgb24gdGhpcyBjYXNlLCBidXQgc29mdHdhcmUgYmVpbmcgc29mdHdh cmUsIHdlIG5lZWQgYW4gYWxnb3JpdGhtIHRvIGltcGxlbWVudCB0aGF0IGNvdmVycyBhbGwgdGhl IGNhc2VzLiBXaGlsZSB0aGUgImV2ZXJ5b25lIGlzIG5ldyIgc2NlbmFyaW8gaXMgb3V0bGFuZGlz aCwgaXQgd291bGRuJ3QgYmUgYWxsIHRoYXQgc3VycHJpc2luZyB0byBoYXZlIG9uZSBvciB0d28g bmV3IG1lbWJlcnMsIHNvIGl0J3MgYSBjYXNlIHRoYXQgd291bGQgbmVlZCBhZGRyZXNzaW5nLiBU aGUgc2VlbWluZ2x5IG1vc3Qgb2J2aW91cyBhcHByb2FjaCB0byBhZGRyZXNzaW5nIHRoaXMgcHJv YmxlbSBpcyB0byBlbmNyeXB0IHRoZSBQU0sgdG8gbmV3IG1lbWJlcnMsIHdoaWNoIHJlcXVpcmVz IHlvdSBhdCBsZWFzdCBoYXZlIGVub3VnaCBzdGF0ZSB0byBmaWd1cmUgb3V0IHdobyB0aGUgbmV3 IG1lbWJlcnMgYXJlLg0KPg0KPiBJdCBhbHNvIG9jY3VycyB0byBtZSBub3cgdGhhdCB0aGUgUFNL IGFwcHJvYWNoIHByZXN1bWVzIHRoYXQgeW91IGtub3cgd2hlbiB5b3VyIHN0YXRlIHdlbnQgYmFk LCBzaW5jZSB5b3Ugd291bGQgd2FudCB0byB1c2UgYSBQU0sgZnJvbSBiZWZvcmUgdGhhdCBwb2lu dC4gSW4gUmFwaGFlbCdzIGV4YW1wbGUgd2hlcmUgcGVyc2lzdGVudCBzdG9yYWdlIGlzIGNvcnJ1 cHRlZCwgYWxsIHlvdSBrbm93IGlzIHRoYXQgbWVzc2FnZXMgc3RvcHBlZCBkZWNyeXB0aW5nLCB3 aGljaCBnaXZlcyB5b3UgYW4gdXBwZXIgYm91bmQgb24gdGhlIHRpbWUgb2YgY29ycnVwdGlvbiwg YnV0IG5vdCByZWFsbHkgYSB3YXkgdG8gZ28gYmFjayBhbmQgZmlndXJlIG91dCB3aGF0J3MgZ29v ZC4NCj4NCj4NCj4gPiBUaGUgc2VjdXJpdHkgZ29hbCBpbiB0aGUgYmFsYW5jZSBoZXJlIGlzIFBD Uy4gQWRkaW5nIGEgcmUtc3luYyBvcHRpb24gb2YgYW55IG9mIHRoZSB2YXJpZXRpZXMgKDIpLSg0 KSB3b3VsZCBicmVhayB0aGF0IHRvIHNvbWUgZGVncmVlLCBzaW5jZSBmb2xsb3dpbmcgYSBjb21w cm9taXNlIGFuZCBwYXNzaXZlIHBlcmlvZCB0aGUgYWR2ZXJzYXJ5IGlzIHRoZW4gZW5hYmxlZCB0 byByZWdhaW4gYSBmb290aG9sZC4gVGhlIHF1ZXN0aW9uIGlzIGhvdyBtdWNoIG9mIGEgZGVncmVl IG9mIGxvc3MgYXJlIHdlIHdpbGxpbmcgdG8gdG9sZXJhdGUuDQo+DQo+IEknbSBub3Qgc3VyZSBJ IHdvdWxkIHJlYWxseSBjaGFyYWN0ZXJpemUgdGhpcyBhcyBhIFBDUyB2aW9sYXRpb24uIFBDUyBp cyBhIGd1YXJhbnRlZSB0aGF0IHlvdSBnZXQgd2hlbiB5b3UgdGFrZSBhIGNlcnRhaW4gYWN0aW9u LiBGb3IgZXhhbXBsZSwgd2hlbiBhIG1lbWJlciBpc3N1ZSBhbiBVcGRhdGUgb3IgYSBDb21taXQg d2l0aCBhIGZyZXNoIEhQS0Uga2V5IHBhaXIsIHlvdSBzaG91bGQgZ2V0IFBDUyB3aXRoIHJlZ2Fy ZCB0byB0aGF0IHBhcnRpY2lwYW50J3MgSFBLRSBrZXkgcGFpcjsgbGlrZXdpc2Ugd2l0aCByb3Rh dGluZyBzaWduYXR1cmUga2V5cy4gSGVyZSwgdGhlIHNpZ25hdHVyZSBrZXkgaGFzIG5vdCBiZWVu IHJvdGF0ZWQsIHNvIHRoZXJlJ3Mgbm8gUENTIGJvdW5kYXJ5Lg0KPg0KPiBJdCBpcyB3b3J0aCBj b25zaWRlcmluZyB3aGV0aGVyIHRoaXMgbWVjaGFuaXNtIGdpdmVzIHRoZSBhdHRhY2tlciBhbnkg YWRkaXRpb25hbCBjYXBhYmlsaXRpZXMgaW4gdGhlIGV2ZW50IHRoYXQgKDEpIHRoZSBzaWduYXR1 cmUga2V5IGlzIGNvbXByb21pc2VkLCBhbmQgKDIpIHRoZSBjb21wcm9taXNlZCBtZW1iZXIgaXNz dWVzIGFuIFVwZGF0ZSBvciBDb21taXQgcm90YXRpbmcgdGhlIHNpZ25hdHVyZSBrZXkuIElTVE0g dGhhdCB5b3Ugc3RpbGwgZ2V0IFBDUyB0aGVyZSBpbiBvcHRpb24gKDMpLCBzaW5jZSB0aGUgcmVx dWlyZW1lbnQgdGhhdCB0aGUgc2lnbmF0dXJlIGtleXMgbWF0Y2ggZW5zdXJlcyB0aGF0IHRoZSBv bGQsIGNvbXByb21pc2VkIHNpZ25hdHVyZSBrZXkgaXMgbm90IGFsbG93ZWQgdG8gcmVzeW5jIGJh Y2sgaW50byB0aGUgZ3JvdXAuIFRoZXJlJ3Mgc3RpbGwgYSByaXNrIHRoYXQgdGhlIGNvbXByb21p c2VkIGtleSAvIGNyZWRlbnRpYWwgY291bGQgYmUgdXNlZCBmb3IgYSBmcmVzaCwgbm9uLXJlc3lu YyBqb2luLCBidXQgdGhhdCdzIGFuIGluaGVyZW50IHJpc2sgd2l0aCBleHRlcm5hbCBDb21taXQg LyBmcmVlbHkgam9pbmFibGUgZ3JvdXBzLCBhbmQgYWxzbyBhbiBvcHBvcnR1bml0eSBmb3IgdGhl IEFTJ3MgcmV2b2NhdGlvbi9pbnZhbGlkYXRpb24gc3lzdGVtIHRvIGhlbHAuDQo+DQo+IFdpbGwg dGFrZSBhIGxvb2sgYXQgdGhlIHJlbWFpbmRlciBpbiB0aGUgbW9ybmluZy4uLg0KPg0KPiAtLVJM Qg0KPg0KPg0KPiA+ICAgKiBJIGFncmVlIHRoYXQgKDQpIGlzIGFuIGltbWVkaWF0ZSBkaXNjYXJk Lg0KPiA+ICAgKiBVbmRlciAoMikgYSBQU0sgdXNlLCB0aGUgUFNLIHVzZSBhdCBsZWFzdCBtb3Jl IGxpbWl0ZWQgZHVlIHRvIHRoZSBwcm9vZiBvZiBrbm93bGVkZ2Ugb2YgYSBwYXN0IHN0YXRlIChl LmcuIG5vdGVzIGFib3ZlKS4gVGhpcyBpcyBhIHdvcnRod2hpbGUgcHJvcGVydHkgdG8gZW5mb3Jj ZSBpbiBteSB2aWV3IHNpbmNlIGl0IGJhbGFuY2VzIGF1dGhlbnRpY2F0aW9uIGFjcm9zcyB0d28g dmVjdG9yczogdGhlIHNpZ25hdHVyZSBrZXkgYW5kIGtub3dsZWRnZSBvZiBncm91cCBzdGF0ZS4g QWR2ZXJzYXJ5IGFjY2VzcyB0byBvbmx5IG9uZSBvciB0aGUgb3RoZXIgaXMgaW5zdWZmaWNpZW50 IGZvciB0aGUgYWR2ZXJzYXJ5IHRvIGVqZWN0IEFsaWNlIGFuZCByZXBsYWNlIGhlciBpbiB0aGUg Z3JvdXAuDQo+ID4gICAqIFVuZGVyICgzKSwgdGhlIGF0dGFjayBzY2VuYXJpbyBvZiBFdmUgY29t cHJvbWlzaW5nIEFsaWNlIChmdWxsIHN0YXRlICsgc2lnIGtleSksIGZvbGxvd2VkIGV2ZW50dWFs bHkqIGJ5IHJlbW92aW5nIEFsaWNlIHdoaWxlIGFkZGluZyBoZXJzZWxmLCBpcyBub3QgZGlzc2lt aWxhciBmcm9tIHRoZSBhdHRhY2sgc2NlbmFyaW8gb2YgRXZlIGNvbXByb21pc2luZyBBbGljZSBm dWxsIHN0YXRlICsgc2lnIGtleSkgZm9sbG93ZWQgZXZlbnR1YWxseSogYnkgcHJvdmlkaW5nIGFu IGltcGVyc29uYXRpbmcgdXBkYXRlIGluIEFsaWNl4oCZcyBuYW1lLiBXaGF0IGhhcyBiZWVuIHNo b3duIHNvIGZhciBpcyB0aGF0IHRoaXMgdHlwZSBvZiBzY2VuYXJpbyBjYW4gYmUgbGltaXRlZCBi eSByb3RhdGluZyBzaWduYXR1cmUga2V5cy4gQSBpbXBvcnRhbnQgcG9pbnQgdGhhdCBpcyBkaWZm ZXJlbnQgaW4gdGhlc2Ugc2NlbmFyaW9zIGlzIHRoYXQgdW5kZXIgdGhlIGZpcnN0IEFsaWNlIGtu b3dzIHNoZSB3YXMgcmVtb3ZlZCAoYSBwbHVzKSB3aGlsZSB1bmRlciB0aGUgc2Vjb25kIChjdXJy ZW50bHkgcG9zc2libGUpIHNjZW5hcmlvIHRoZSBncm91cCBzaW1wbHkgZ29lcyBzaWxlbnQgYW5k IEFsaWNlIGRvZXMgbm90IGtub3cgaWYgaXQgd2FzIG1hbGljaW91cyBvciBub3QuIEFsbCBzYWlk LCBpdCBjb3VsZCBiZSB3b3JzZS4gVGhhdCBkb2VzIG5vdCBjb25zaWRlciBvdGhlciBhdHRhY2sg c2NlbmFyaW9zIHRob3VnaCwgZm9yIGV4YW1wbGUgd2hlbiB0aGUgYXR0YWNrZXIgZ2FpbnMgdGhl IHNpZ25hdHVyZSBrZXkgYnV0IG5vdCBwYXN0IHN0YXRlL1BTSy4NCj4gPg0KPiA+ICpJLmUuIGFm dGVyIGEgcG90ZW50aWFsbHkgcGFzc2l2ZSBwZXJpb2QsIGlmIHdlIGFyZSB0byBzaG93IGhvdyB0 aGlzIGJlaGF2ZXMgaW4gdGhlIFBDUyBzY2VuYXJpby4NCj4gPg0KPiA+IFRoaXMgbGVhZHMgdG8g YW4gaW1wb3J0YW50IHF1ZXN0aW9uOiBkb2VzIG91ciBjdXJyZW50IHVuaXF1ZW5lc3Mgb2Ygc2ln IGtleSBwcmVkaWNhdGUgbGltaXQgdGhlIGFiaWxpdHkgdG8gcm90YXRlIHNpZ25hdHVyZSBrZXlz IHdpdGhpbiBhIGdyb3VwPyBUaGF0IGlzIG91ciBtZWFucyBvZiBsaW1pdGluZyB0aGUgZnVsbCBz dGF0ZSArIHNpZyBrZXkgY29tcHJvbWlzZSBzY2VuYXJpbyBpbXBhY3RzIG1lbnRpb25lZCBhYm92 ZSwgYW5kIHRoZXJlZm9yZSB0aGUgbWVhbnMgb2YgbGltaXRpbmcgdGhlIGRyYXdiYWNrcyBvZiAo MykuIFdlIHNob3VsZCBtYWtlIHN1cmUgdGhhdCB0aGUgbGltaXRpbmcgYWJpbGl0eSBpcyBmZWFz aWJsZS4gSWYgdGhhdCBoaW5kZXJlZCBpbiBhbnkgd2F5LCB0aGVuIEkgd291bGQgdm90ZSB2ZXJ5 IHN0cm9uZ2x5IGZvciAoMikgYXMgaXQgYXQgbGVhc3QgYm9vdHN0cmFwcyBzb21lIG9mIHRoZSBh dXRoZW50aWNhdGlvbiBwcm9wZXJ0aWVzIGZyb20gdGhlIGdyb3VwIHN0YXRlIGluIHRoZSBzY2Vu YXJpbyB0aGF0IHRoZSBzaWcga2V5IGlzIGNvbXByb21pc2VkLg0KPiA+DQo+ID4NCj4gPiBBbGwg dGhlIGJlc3QsDQo+ID4NCj4gPiBCcml0dGENCj4gPg0KPiA+DQo+ID4NCj4gPiBGcm9tOk1MUyA8 bWxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1scy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PG1haWx0bzpybGJAaXB2LnN4Pj4NCj4g PiAgRGF0ZTpNb25kYXksIE9jdG9iZXIgNCwgMjAyMSBhdCA0OjA5IFBNDQo+ID4gIFRvOk1lc3Nh Z2luZyBMYXllciBTZWN1cml0eSBXRyA8bWxzQGlldGYub3JnPG1haWx0bzptbHNAaWV0Zi5vcmc+ Pg0KPiA+ICBTdWJqZWN0OltNTFNdIFJlc3luYyBhcmNoYWVvbG9neSArIGFuYWx5c2lzICsgcHJv Z25vc2lzDQo+ID4NCj4gPiBPSywgSSB0aGluayBJIGhhdmUgdHJhY2VkIGJhY2sgc29tZSBpZGVh IG9mIHdoeSB3ZSByZW1vdmVkIHRoZSBlYXJsaWVyIHJlc3luYyBwcm9wb3NhbC4gSGVyZSdzIGEg bGl0dGxlIGVzc2F5IG9uIGhvdyB3ZSBnb3QgaGVyZSwgYSByZWNhcCBvZiB0aGUgdHJhZGUtb2Zm cywgYW5kIG15IHRob3VnaHRzIG9uIHdoZXJlIHdlIHNob3VsZCBnby4NCj4gPg0KPiA+IHRsO2Ry OiBFYXJsaWVyIGRlY2lzaW9uIG5vdCBkaXNwb3NpdGl2ZTsgd2Ugc2hvdWxkIGRvIGJhc2ljYWxs eSB3aGF0J3MgaW4gdGhlIFBSIG5vdy4NCj4gPg0KPiA+ICAjIEhpc3RvcnkNCj4gPg0KPiA+ICBU aGUgc3Rvcnkgc3RhcnRzIGFsbCB0aGUgd2F5IGJhY2sgYXQgdGhlIEphbnVhcnkgMjAxOSBpbnRl cmltIGF0IE1vemlsbGEgLyBNb3VudGFpbiBWaWV3LiBUaGVyZSB3YXMgYSBkaXNjdXNzaW9uIHRo ZXJlIG9mIEFDSy9OQUNLIGFuZCByZXBsYXkgYXMgcmVsYXRlZCBpc3N1ZXMgWzFdLiBUaGF0IGRp c2N1c3Npb24gc2VlbXMgdG8gaGF2ZSBsZWQgdG8gYWdyZWVtZW50IHRoYXQgYSBjb21wbGV0ZSBl cnJvciByZWNvdmVyeSBzeXN0ZW0gd2FzIGEgY29tcGxleCBlbm91Z2ggdG9waWMsIGFuZCBjbGVh cmx5IGVub3VnaCBzZXBhcmF0ZWQgZnJvbSB0aGUgbWFpbiBwcm90b2NvbCB0aGF0IGl0IGNvdWxk IGJlIGhhbmRsZWQgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLiBBcyBhIHJlc3VsdCwgdGhl IGlzc3VlcyB0aGF0IGhhZCBiZWVuIG9wZW5lZCBmb3IgQUNLL05BQ0sgYW5kIHJlc3luYyB3ZXJl IGNsb3NlZCBbMl1bM10uIFdoZW4gQnJpdHRhIGFuZCBLb25yYWQgcG9zdGVkICMzMzYgWzRdIGlu Y2x1ZGluZyBhIHJlc3luYyBtZWNoYW5pc20sIG15IHJldmlldyBzaW1wbHkgY2l0ZWQgdGhhdCBl YXJsaWVyIGNsb3NlZCBpc3N1ZSBhcyBhIHJlYXNvbiBmb3IgdGFraW5nIGl0IG91dCBbNV0uDQo+ ID4NCj4gPiAgT25lIG90aGVyIG5vdGUgd2l0aCByZWdhcmQgdG8gIzMzNiAtLSBJdCBsb29rcyB0 byBtZSBsaWtlIHRoZSAicmVzeW5jIiBtZWNoYW5pc20gaW4gdGhlcmUgd2FzIG5vdCByZWFsbHkg Zmxlc2hlZCBvdXQgZW5vdWdoIHRvIGJlIGltcGxlbWVudGFibGUuIFRoZSBzdGF0ZSBsaW5rZWQg YWJvdmUgd2FzIHRoZSBsYXN0IHN0YXRlIGJlZm9yZSBteSByZXZpZXcsIGFuZCB0aGUgd29yZCAi cmVzeW5jIiBkb2Vzbid0IGFjdHVhbGx5IGFwcGVhci4gSW5zdGVhZCB0aGUgUFIgdGFsa3MgYWJv dXQgInJlY292ZXJpbmcgbG9zdCBncm91cCBtZW1iZXJzIiB1c2luZyBBZGQgYW5kIFBTSywgd2hp Y2ggY291bGQgYmUgZWxhYm9yYXRlZCB0byBzb2x2ZSBhIHZlcnNpb24gb2YgdGhpcyBwcm9ibGVt LCBidXQgd291bGQgcmVxdWlyZSB0aGUgYXNzaXN0YW5jZSBvZiBhIGNvbnRpbnVpbmcgbWVtYmVy IHJhdGhlciB0aGFuIGFsbG93aW5nIHRoZSBsb3N0IG1lbWJlciB0byByZXN5bmMgdW5pbGF0ZXJh bGx5LiBJdCB3b3VsZCBhbHNvIGhhdmUgdGhlIHNhbWUgaXNzdWVzIG5vdGVkIGluIHRlcm1zIG9m IG5ldyBqb2luZXJzIG5vdCBoYXZpbmcgcmVzeW5jIFBTS3MuDQo+ID4NCj4gPiAgT3ZlcmFsbCwg dGhvdWdoLCByZWFkaW5nIHRoaXMgaGlzdG9yeSBkb2Vzbid0IHNlZW0gdG8gbWUgbGlrZSB3ZSBy ZWFsbHkgbWFkZSBhIHByaW5jaXBsZWQgZGVjaXNpb24gbm90IHRvIGRvIHJlc3luYy4gV2UganVz dCBwdW50ZWQgYWZ0ZXIgc29tZSBkaXNjdXNzaW9uIGluIHRoZSBhYnN0cmFjdCwgYW5kIHRoYXQg c3R1Y2suIFdlIGhhdmUgYSBtb3JlIGNvbmNyZXRlIHF1ZXN0aW9uIG5vdy4NCj4gPg0KPiA+ICAj IEFuYWx5c2lzDQo+ID4NCj4gPiAgU2luY2UgdGhlIGRpc2N1c3Npb24gb2YgIzMzNiBpbiAyMDIw LCB3ZSBoYXZlIGFkZGVkIGV4dGVybmFsIGNvbW1pdHMgaW4gb3JkZXIgdG8gaGF2ZSBncm91cHMg eW91IGNhbiBqb2luIHVuaWxhdGVyYWxseS4gU28gcmVnYXJkbGVzcyBvZiB0aGUgYnJvYWRlciBx dWVzdGlvbiBvZiByZXN5bmMsIHdlIGhhdmUgdG8gZGVjaWRlIHdoYXQgcHJvcG9zYWxzIGEgam9p bmVyIGlzIGFsbG93ZWQgdG8gb3JpZ2luYXRlIGluIHRoZWlyIENvbW1pdCAoc2VuZGluZyB0aGVt IGJ5IHZhbHVlKSwgaW4gcGFydGljdWxhciwgd2hldGhlciBhbiBleHRlcm5hbCBDb21taXQgY2Fu IGNvbnRhaW4gYSBqb2luZXItb3JpZ2luYXRlZCBSZW1vdmUgcHJvcG9zYWwuIFdlIGhhdmUgYSBz cGVjdHJ1bSBvZiBvcHRpb25zIGhlcmU6DQo+ID4NCj4gPiAgMS4gRm9yYmlkIFJlbW92ZQ0KPiA+ ICAyLiBBbGxvdyBSZW1vdmUgKyByZXF1aXJlIHRoZSAoaWRlbnRpdHksIGVuZHBvaW50X2lkKSBh bmQgc2lnbmF0dXJlIGtleSB0byBtYXRjaCB0aGUgcmVtb3ZlZCBub2RlICsgcmVxdWlyZSByZXN1 bXB0aW9uIFBTSw0KPiA+ICAzLiBBbGxvdyBSZW1vdmUgKyByZXF1aXJlIHRoZSAoaWRlbnRpdHks IGVuZHBvaW50X2lkKSBhbmQgc2lnbmF0dXJlIGtleSB0byBtYXRjaCB0aGUgcmVtb3ZlZCBub2Rl DQo+ID4gIDQuIEFsbG93IFJlbW92ZSB3aXRob3V0IHJlc3RyaWN0aW9uDQo+ID4NCj4gPiAgT3B0 aW9ucyAoMSkgYW5kICgyKSB3b3VsZCBibG9jayBhbiBhdHRhY2tlciB0aGF0IGhhcyBjb21wcm9t aXNlZCBhIG1lbWJlcidzIHNpZ25hdHVyZSBrZXkgZnJvbSBqb2luaW5nIGFzIHRoYXQgbWVtYmVy IGFuZCBldmljdGluZyB0aGUgb2xkIGFwcGVhcmFuY2UuIE9wdGlvbiAoMikgYmVjYXVzZSBvZiB0 aGUgUFNLOyBvcHRpb24gKDEpIGJlY2F1c2Ugb2YgdGhlIHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnRz IChhcyBSYXBoYWVsIHBvaW50ZWQgb3V0IG9uIHRoZSBjYWxsKS4NCj4gPg0KPiA+ICBPcHRpb25z ICgxKSBhbmQgKDIpIGRvIG5vdCBhbGxvdyBhIGNsaWVudCB3aG8gaGFzIGxvc3QgZXZlcnl0aGlu ZyBidXQgdGhlaXIgc2lnbmF0dXJlIGtleSB0byByZXN5bmMuIE9wdGlvbiAoMSkgd291bGQgcmVx dWlyZSBhIG5ldyBlbmRwb2ludF9pZCBhbmQgc2lnbmF0dXJlIGtleSwgd2hpY2ggbWlnaHQgbm90 IGJlIGZlYXNpYmxlIGluIGFsbCBjYXNlcy4gT3B0aW9uICgyKSB3b3VsZCBhbHNvIG5lZWQgdG8g aGF2ZSBleHRyYSBtZWNoYW5pc20gdG8gYWNjb3VudCBmb3IgcmVjZW50IGpvaW5lcnMgbm90IGhh dmluZyB0aGUgcmVxdWlyZWQgcmVzdW1wdGlvbiBQU0suDQo+ID4NCj4gPiAgT3B0aW9uICgxKSB3 b3VsZCBhbHNvIG5vdCBhbGxvdyBmb3IgcmVzeW5jIHdpdGgganVzdCBhIHNpZ25hdHVyZSBrZXku IEFzIFJhcGhhZWwgcG9pbnRlZCBvdXQsIGJlY2F1c2Ugd2Ugbm93IHJlcXVpcmUgc2lnbmF0dXJl IGtleXMgdG8gYmUgdW5pcXVlLCB0aGUgbWVtYmVyIHdvdWxkIGhhdmUgdG8gbWludCBhIG5ldyBz aWduYXR1cmUga2V5IGFuZCBnZXQgaXQgYXV0aGVudGljYXRlZCwgb3IgZWxzZSB0aGVpciBhdHRl bXB0IHRvIHJlam9pbiB3b3VsZCBiZSByZWplY3RlZCBhcyBhIGR1cGxpY2F0ZSBlbnRyeS4NCj4g Pg0KPiA+ICBPcHRpb25zICgzKSBhbmQgKDQpIHdvdWxkIGFsbG93IGEgY2xpZW50IHdobyBoYXMg bG9zdCBldmVyeXRoaW5nIGJ1dCB0aGVpciBzaWduYXR1cmUga2V5IHRvIHJlc3luYywgYXQgdGhl IHJpc2sgdGhhdCBhbiBhdHRhY2tlciB3aG8gaGFzIGNvbXByb21pc2VkIGEgbWVtYmVyJ3Mgc2ln bmF0dXJlIGtleSBjb3VsZCBhYnVzZSBpdCB0byBqb2luIGFzIHRoYXQgbWVtYmVyIGFuZCBldmlj dCB0aGUgb2xkLCBsZWdpdGltYXRlIGFwcGVhcmFuY2UuDQo+ID4NCj4gPiAgIyBQcm9nbm9zaXMN Cj4gPg0KPiA+ICBBZnRlciB0aGlzIGRpc2N1c3Npb24gYW5kIGFuYWx5c2lzLCBJIGNvbnRpbnVl IHRvIHRoaW5rIHRoYXQgKDMpIGFib3ZlIGlzIHRoZSByaWdodCBhbnN3ZXIsIHdpdGggYW4gb3B0 aW9uYWwgdXBnYWRlIHRvICgyKS4gUHJvY2VlZGluZyBieSBlbGltaW5hdGlvbjoNCj4gPg0KPiA+ ICBPcHRpb24gKDQpLCB3aGlsZSB0ZWNobmljYWxseSBmZWFzaWJsZSwgaXMgY2xlYXJseSBhIGxp dHRsZSBzaWxseS4gVGhlcmUncyBubyByZWFzb24gdG8gYWxsb3cgam9pbmVycyB0byBkbyBhIHJl bW92ZSBpbiB0aGUgc2FtZSBvcGVyYXRpb24gYXMgdGhleSBqb2luOyB0aGV5IGNvdWxkIGRvIHRo aXMgYWZ0ZXJ3YXJkLg0KPiA+DQo+ID4gIE9wdGlvbiAoMikgZG9lcyBub3Qgc2VlbSB3b3JrYWJs ZSBpbiBnZW5lcmFsIGJlY2F1c2Ugb2YgdGhlIHJlY2VudC1qb2luZXIgcHJvYmxlbS4gV2hpbGUg bWVjaGFuaXNtIGNvdWxkIGJlIGRlc2lnbmVkIHRvIHByb3ZpZGUgdGhlIFBTSyB0byByZWNlbnQg am9pbmVycywgaXQgd291bGQgYWRkIGEgbG90IG9mIGNvbXBsZXhpdHksIGFuZCB0aGUgcmVjZW50 IGpvaW5lcnMgd291bGRuJ3QgZ2V0IGFueSBiZW5lZml0IGZyb20gaXQsIHdoaWNoIGRpbHV0ZXMg dGhlIHZhbHVlIG9mIHRoaXMgbWVjaGFuaXNtLiAoSXQncyBub3QgaW1wb3NzaWJsZSB0byBhcnJp dmUgYXQgdGhlIGNhc2Ugd2hlcmUgZXZlcnlvbmUgYmVzaWRlcyB0aGUgcmVzeW5jJ2luZyBwYXJ0 aWNpcGFudCBpcyBuZXchKQ0KPiA+DQo+ID4gIFdpdGggb3B0aW9uICgxKSwgeW91IGxvc2UgYW55 IG5vdGlvbiBvZiByZXN5bmM7IEkgdGhpbmsgdGhlIG5lZWQgZm9yIGVuZHBvaW50X2lkIHJvdGF0 aW9uIG1ha2VzIHRoaXMgdW53b3JrYWJsZSBpbiBwcmFjdGljZS4gQW5kIGl0IGhhcyBraW5kIG9m IGFuIG9kZCBub3Rpb24gb2Ygc2VjdXJpdHk6IFlvdSBhcmUgcHJvdGVjdGVkIGFnYWluc3QgYW4g YXR0YWNrZXIgdGhhdCBoYXMgY29tcHJvbWlzZWQgYSBjdXJyZW50IHNpZ25hdHVyZSBrZXkgYnV0 IGNhbid0IGdldCBhIG5ldyBvbmUgYXV0aGVudGljYXRlZC4gVGhpcyBpcyBhIHByb2JsZW0gZm9y IHRoZSBhdXRoZW50aWNhdGlvbiBzeXN0ZW0gdG8gaGFuZGxlIChlLmcuLCB3aXRoIHJldm9jYXRp b24pLCBub3QgZm9yIHRoZSBrZXkgZXhjaGFuZ2UgLS0gaWYgeW91IGhhdmUgdmFsaWQgY3JlZGVu dGlhbHMgd2l0aCBjb21wcm9taXNlZCBrZXlzIGZsb2F0aW5nIGFyb3VuZCwgeW91IGhhdmUgYmln Z2VyIHByb2JsZW1zIHRvIHNvbHZlLiBTbyBteSBwZXJzb25hbCBhc3Nlc3NtZW50IGlzIHRoYXQg KDEpIGRvZXNuJ3QgcHJvdmlkZSBhIGJpZyBqdW1wIGluIHNlY3VyaXR5IG92ZXIgKDMpLCBhc3N1 bWluZyB5b3UgaGF2ZSBhIGZ1bmN0aW9uaW5nIGF1dGhlbnRpY2F0aW9uIHN5c3RlbS4NCj4gPg0K PiA+ICBUd28gc2lkZSBub3RlcyBhYm91dCAoMyk6IEZpcnN0LCBpZiB3ZSBkbyAoMykgYnV0ICph bGxvdyogUFNLcywgdGhlbiBhbiBhcHBsaWNhdGlvbiBjb3VsZCBvcHQgaW4gdG8gKDIpLiBTZWNv bmQsIHRoaXMgd2hvbGUgbWVjaGFuaXNtIGlzIG9wdC1pbiBmb3IgdGhlIGFwcGxpY2F0aW9uLCBz aW5jZSB5b3UgY2FuJ3QgZG8gYW4gZXh0ZXJuYWwgY29tbWl0IGlmIGEgUHVibGljR3JvdXBTdGF0 ZSBoYXNuJ3QgYmVlbiBwdWJsaXNoZWQuDQo+ID4NCj4gPiAgQ29uY3JldGVseSwgbXkgcHJvcG9z YWwgaGVyZSB3b3VsZCBiZSAoMykgKyAoMiopIC0tIEFsbG93IFJlbW92ZSB3aXRoIG1hdGNoaW5n IHBhcmFtZXRlcnMsIGFuZCBhbGxvdyBQU0tzIHNvIHRoYXQgYXBwbGljYXRpb25zIGNhbiBvcHQg aW4gdG8gKDIpIHdoZXJlIHRoZXkgY2FuIG1ha2UgaXQgd29yay4gVGhhdCB3YXksIGlmIGFuIGFw cGxpY2F0aW9uIG9wdHMgaW4gdG8gZXh0ZXJuYWwgQ29tbWl0cywgdGhleSBnZXQgdGhlIGJlbmVm aXQgb2YgcmVzeW5jIGFuZCB0aGUgc2FtZSBzaWduYXR1cmUta2V5LWNvbXByb21pc2UgYm91bmQg b24gaW1wZXJzb25hdGlvbiBmb3IgcmVzeW5jIGFzIHdlbGwgYXMgbmV0LW5ldyBqb2lucy4gQW5k IGlmIGFuIGFwcGxpY2F0aW9uIGNhbiBmaWd1cmUgb3V0IGhvdyB0byBtYWtlICgyKSB3b3JrLCB0 aGV5IGNhbiByZXF1aXJlIGl0Lg0KPiA+DQo+ID4gIExvb2tpbmcgZm9yd2FyZCB0byBvdGhlcnMn IHRob3VnaHRzIGhlcmUhDQo+ID4NCj4gPiAgLS1STEINCj4gPg0KPiA+DQo+ID4gIFsxXSBodHRw czovL2dpdGh1Yi5jb20vbWxzd2cvd2ctbWF0ZXJpYWxzL2Jsb2IvbWFpbi9pbnRlcmltLTIwMTkt MDEvbWludXRlcy5tZCNhY2tzLWFuZC1uYWNrcy1qb25tPGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZt bHN3ZyUyRndnLW1hdGVyaWFscyUyRmJsb2IlMkZtYWluJTJGaW50ZXJpbS0yMDE5LTAxJTJGbWlu dXRlcy5tZCUyM2Fja3MtYW5kLW5hY2tzLWpvbm0mZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUl NDBucHMuZWR1JTdDMDBjMzBiYzVkNTg3NDRjYzE5OTAwOGQ5ODhlMWM1MzMlN0M2ZDkzNjIzMWE1 MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkxMzI1NTQ5MzI5NDc3JTdDVW5r bm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxD SkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9V2t5WjVJY0I1S2Z0ZDRo SmpubmVXJTJGNFFFZ2MzellyZFA0bGVvZCUyQktZbUklM0QmcmVzZXJ2ZWQ9MD4gKGh0dHBzOi8v bmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmdpdGh1Yi5jb20lMkZtbHN3ZyUyRndnLW1hdGVyaWFscyUyRmJsb2IlMkZtYWluJTJGaW50ZXJp bS0yMDE5LTAxJTJGbWludXRlcy5tZCUyM2Fja3MtYW5kLW5hY2tzLWpvbm0mZGF0YT0wNCU3QzAx JTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMWViZjk2YzMwY2M0NGZjOTZlMWQwOGQ5ODc4YmI2 YjUlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3Njg5ODU3 OTMxODQ0ODA4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENK UUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9 JTJCRXByUU1PVmslMkJJTmhkdFJ4SEw1SmZHUSUyRmVQNnRDRnZjQU0zdW9wTUZxNCUzRCZyZXNl cnZlZD0wPGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRndnLW1hdGVyaWFscyUyRmJsb2Il MkZtYWluJTJGaW50ZXJpbS0yMDE5LTAxJTJGbWludXRlcy5tZCUyM2Fja3MtYW5kLW5hY2tzLWpv bm0mZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMDBjMzBiYzVkNTg3NDRj YzE5OTAwOGQ5ODhlMWM1MzMlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAl N0MwJTdDNjM3NjkxMzI1NTQ5MzM5NDc0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9p TUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUz RCU3QzEwMDAmc2RhdGE9ekNHcDB4UXNHUVBpWU45QnFzSEE5SkclMkZGOG1hUWhtNGVVT1VSQWZi R0hvJTNEJnJlc2VydmVkPTA+KQ0KPiA+ICBbMl0gaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21s cy1wcm90b2NvbC9pc3N1ZXMvOTI8aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXBy b3RvY29sJTJGaXNzdWVzJTJGOTImZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1 JTdDMDBjMzBiYzVkNTg3NDRjYzE5OTAwOGQ5ODhlMWM1MzMlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5 OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkxMzI1NTQ5MzM5NDc0JTdDVW5rbm93biU3Q1RX RnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsx aGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9enU1SkpqWEJLT1BycnhVNzc5eEZCSThw U1QxWG1Vc3g3a0JGZkJjRERuUSUzRCZyZXNlcnZlZD0wPiAoaHR0cHM6Ly9uYW0xMC5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUy Rm1sc3dnJTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTImZGF0YT0wNCU3QzAxJTdDYnJpdHRh LmhhbGUlNDBucHMuZWR1JTdDMWViZjk2YzMwY2M0NGZjOTZlMWQwOGQ5ODc4YmI2YjUlN0M2ZDkz NjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3Njg5ODU3OTMxODU0ODAw JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1 TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9bEZlWXd5SENH WmxzSHolMkJPMmNWUEc3ZVVUVWp6b0xoelEwZm5peiUyRmJsbWMlM0QmcmVzZXJ2ZWQ9MDxodHRw czovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wlMkZpc3N1ZXMlMkY5MiZkYXRh PTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MwMGMzMGJjNWQ1ODc0NGNjMTk5MDA4 ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2 Mzc2OTEzMjU1NDkzNDk0NjQlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpB d01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAw MCZzZGF0YT1aN0dkaUJWTjdiVUtVS0Y2Mlc2SzVvJTJGR01BWkxOeWVZTlN0QmV1c2s3alklM0Qm cmVzZXJ2ZWQ9MD4pDQo+ID4gIFszXSBodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3Rv Y29sL2lzc3Vlcy85MzxodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wl MkZpc3N1ZXMlMkY5MyZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MwMGMz MGJjNWQ1ODc0NGNjMTk5MDA4ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5 NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTEzMjU1NDkzNDk0NjQlN0NVbmtub3duJTdDVFdGcGJHWnNi M2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxD SlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT04QSUyQlc3WlZKaWt5SUZkQSUyQk9OVyUyQkp6OUIx ajVNOFd6MSUyRjRFR2IyTHdtUWMlM0QmcmVzZXJ2ZWQ9MD4gKGh0dHBzOi8vbmFtMTAuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20l MkZtbHN3ZyUyRm1scy1wcm90b2NvbCUyRmlzc3VlcyUyRjkzJmRhdGE9MDQlN0MwMSU3Q2JyaXR0 YS5oYWxlJTQwbnBzLmVkdSU3QzFlYmY5NmMzMGNjNDRmYzk2ZTFkMDhkOTg3OGJiNmI1JTdDNmQ5 MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY4OTg1NzkzMTg1NDgw MCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJs dU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJnNkYXRhPXpwVyUyQkNR eiUyQmVFd2tsWWJwNE5RbUZjVWVIQkdtQWgwaktCUkMwNUN5VkJzJTNEJnJlc2VydmVkPTA8aHR0 cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTMmZGF0 YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMDBjMzBiYzVkNTg3NDRjYzE5OTAw OGQ5ODhlMWM1MzMlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdD NjM3NjkxMzI1NTQ5MzU5NDYwJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEw MDAmc2RhdGE9NHMlMkZVZ1JWaUxQa1g2QlVjcUJIUHhCRGt1ZXRqRDdNdUxMRnk0am1CVm5VJTNE JnJlc2VydmVkPTA+KQ0KPiA+ICBbNF0gaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21scy1wcm90 b2NvbC9wdWxsLzMzNi9maWxlcy8yMDE0NWU0OWFjY2UwMWRjZWRjYTdkYjJkMDVjNTc5MDhhMjky MjAyPGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUyRnB1bGwlMkYz MzYlMkZmaWxlcyUyRjIwMTQ1ZTQ5YWNjZTAxZGNlZGNhN2RiMmQwNWM1NzkwOGEyOTIyMDImZGF0 YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMDBjMzBiYzVkNTg3NDRjYzE5OTAw OGQ5ODhlMWM1MzMlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdD NjM3NjkxMzI1NTQ5MzU5NDYwJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xq QXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEw MDAmc2RhdGE9MW5KeVZjQ2RxWEl6WEdvUUFVcFhoQnV4ZlElMkZqTUN3eEZhNmROU0IlMkI4ZEEl M0QmcmVzZXJ2ZWQ9MD4gKGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2Nv bCUyRnB1bGwlMkYzMzYlMkZmaWxlcyUyRjIwMTQ1ZTQ5YWNjZTAxZGNlZGNhN2RiMmQwNWM1Nzkw OGEyOTIyMDImZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMWViZjk2YzMw Y2M0NGZjOTZlMWQwOGQ5ODc4YmI2YjUlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4 ZSU3QzAlN0MwJTdDNjM3Njg5ODU3OTMxODY0Nzk0JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5 SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJ Nk1uMCUzRCU3QzMwMDAmc2RhdGE9ME9nVmRkYyUyQkl6anU2MU13ZlFGTmlZamVqWklOdHJJcWYw OENrSWdHbSUyQlElM0QmcmVzZXJ2ZWQ9MDxodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZt bHMtcHJvdG9jb2wlMkZwdWxsJTJGMzM2JTJGZmlsZXMlMkYyMDE0NWU0OWFjY2UwMWRjZWRjYTdk YjJkMDVjNTc5MDhhMjkyMjAyJmRhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3 QzAwYzMwYmM1ZDU4NzQ0Y2MxOTkwMDhkOTg4ZTFjNTMzJTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlm NzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MTMyNTU0OTM2OTQ1NiU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPXd2ZzlCRThRdWtzb0d1WVZac0QyNzlxenhH dWQ3MDZGaiUyQkxCUkFPMW5vQSUzRCZyZXNlcnZlZD0wPikNCj4gPiAgWzVdIGh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbWxzL0hzX25BWDNsdURqaVE0bUl3a2lLdTFDRlNB RS88aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZhcmNoJTJGbXNnJTJGbWxzJTJGSHNf bkFYM2x1RGppUTRtSXdraUt1MUNGU0FFJTJGJmRhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQw bnBzLmVkdSU3QzAwYzMwYmM1ZDU4NzQ0Y2MxOTkwMDhkOTg4ZTFjNTMzJTdDNmQ5MzYyMzFhNTE3 NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MTMyNTU0OTM2OTQ1NiU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPWVVd1ZtU3NzTmpBQUU5eHBK cXlndXFTYkhNN0NUaG1rSmh6OXlpN3dGVE0lM0QmcmVzZXJ2ZWQ9MD4gKGh0dHBzOi8vbmFtMTAu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxh cmNoaXZlLmlldGYub3JnJTJGYXJjaCUyRm1zZyUyRm1scyUyRkhzX25BWDNsdURqaVE0bUl3a2lL dTFDRlNBRSUyRiZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MxZWJmOTZj MzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMz NzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NzQ3ODklN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW Q0k2TW4wJTNEJTdDMzAwMCZzZGF0YT1tb1VBWkozdE9BaEZJJTJCTU1GcTk5QjExMXdKcHhCUkJ3 YlJQWXM1bER4QzAlM0QmcmVzZXJ2ZWQ9MDxodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZtYWlsYXJjaGl2ZS5pZXRmLm9yZyUy RmFyY2glMkZtc2clMkZtbHMlMkZIc19uQVgzbHVEamlRNG1Jd2tpS3UxQ0ZTQUUlMkYmZGF0YT0w NCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMDBjMzBiYzVkNTg3NDRjYzE5OTAwOGQ5 ODhlMWM1MzMlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3 NjkxMzI1NTQ5Mzc5NDQ1JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAm c2RhdGE9a1B4WjFoaUhmY3YlMkZUdFpzU0hrbmdhMnpLeG5hNkNna2JpNW02JTJCenZvRFklM0Qm cmVzZXJ2ZWQ9MD4pDQo= --_000_62F15B7563294EFC91AD31C963214DD5npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <2C49BFFC79D4994FA5CDFE3292F6CF55@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc291bmRzIHJlYXNvbmFibGUgdG8gbWUgYXMgYSB3YXkg Zm9yd2FyZC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVzdGlvbiBwb3NlZCBiZWZv cmUgKOKAnFRoaXMgbGVhZHMgdG8gYW4gaW1wb3J0YW50IHF1ZXN0aW9uOiBkb2VzIG91ciBjdXJy ZW50IHVuaXF1ZW5lc3Mgb2Ygc2lnIGtleSBwcmVkaWNhdGUgbGltaXQgdGhlIGFiaWxpdHkgdG8g cm90YXRlIHNpZ25hdHVyZSBrZXlzIHdpdGhpbiBhIGdyb3VwPyBUaGF0IOKApiBbaXMgd2hhdCBs aW1pdHNdIHRoZSBkcmF3YmFja3Mgb2YgKDMpLuKAnSkgc3RpbGwgc3RhbmRzLiBJDQogZG8gbm90 IHRoaW5rIHRoaXMgaW5oaWJpdHMgbW92aW5nIGZvcndhcmQgd2l0aCB0aGUgUFIsIGJ1dCBpdCBp cyBpbXBvcnRhbnQgdG8gYWRkcmVzcy4gSWYgdGhlcmUgaXMgYSB0cmFkZS1vZmYgYmV0d2VlbiBh biBpbXBsZW1lbnRhdGlvbiBhbGxvd2luZyByZW1vdmUrcmVzeW5jIGFuZCByb3RhdGluZyBvdXQg c2lnbmF0dXJlIGtleXMsIHRoZW4gdGhhdCBzaG91bGQgYmUgbm90ZWQgaW4gdGhlIGFyY2hpdGVj dHVyZSBkb2N1bWVudCBpZiBub3QgdGhlDQogcHJvdG9jb2wgc3BlYyBpdHNlbGYuIFdlIGFyZSBu b3QgZ29pbmcgdG8gZ28gdGhyb3VnaCBhbGwgdGhlIHBvc3NpYmxlIG9wdGlvbnMgZm9yIGltcGxl bWVudGF0aW9uLCBidXQgd2hlbiB0aGVyZSBpcyBzaWduaWZpY2FudCBzcGFjZSBpbiB0aGUgcHJv dG9jb2wgc3BlYyBkZXZvdGVkIHRvIGFuIG9wdGlvbmFsIGZ1bmN0aW9uYWxpdHkgKGUuZy4gZXh0 ZXJuYWwgY29tbWl0cyBhbmQgcmVzeW5jKSB0aGVuIGl0IHdvdWxkIGJlIGdvb2QgdG8gbm90ZQ0K IHRyYWRlLW9mZnMgdGhhdCB3aWxsIGNvbWUgd2l0aCBpdC4gV2Ugd291bGQgbm90IGhhdmUgYSB3 ZWxsLXdyaXR0ZW4gc3BlY2lmaWNhdGlvbiBpZiBpdCBjb3VsZCBwb3RlbnRpYWxseSBsZWFkIGFu IGltcGxlbWVudG9yIGZhciBkb3duIG9uZSBvcHRpb25hbCBwYXRoIHRoYXQgcHJlY2x1ZGVzIGRl c2lyZWQgc2VjdXJpdHkgZ3VhcmFudGVlcywgYW5kIGdpdmVzIG5vIGNvbnRleHQgb24gdGhhdCAo aS5lLiBsZXTigJlzIHRyeSB0byBtaW5pbWl6ZSBvYnZpb3VzDQogY2FzZXMgb2Yg4oCcSSB3aXNo IEkgaGFkIGtub3du4oCm4oCdIGZvciBpbXBsZW1lbnRvcnMpLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccml0dGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UmljaGFyZCBCYXJuZXMgJmx0O3JsYkBpcHYu c3gmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgT2N0b2JlciA2LCAyMDIxIGF0IDg6 NTUgQU08YnI+DQo8Yj5UbzogPC9iPktvbnJhZCBLb2hicm9rICZsdDtrb25yYWQua29oYnJva0Bk YXRhc2hyaW5lLmRlJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7SGFsZSwgQnJpdHRhIChDSVYp JnF1b3Q7ICZsdDticml0dGEuaGFsZUBucHMuZWR1Jmd0OywgTWVzc2FnaW5nIExheWVyIFNlY3Vy aXR5IFdHICZsdDttbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTUxT XSBSZXN5bmMgYXJjaGFlb2xvZ3kgKyBhbmFseXNpcyArIHByb2dub3NpczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUgdXBk YXRlZCB0aGUgUFIgdG8gZG8gYmFzaWNhbGx5IHdoYXQgS29ucmFkIHByb3Bvc2VzLiZuYnNwOyBO YW1lbHksIGFsbG93IFJlbW92ZSwgYnV0IHN1Z2dlc3QgdGhhdCBhcHBsaWNhdGlvbnMgY2FuIGFw cGx5IGFkZGl0aW9uYWwgY29uc3RyYWludHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZt bHN3ZyUyRm1scy1wcm90b2NvbCUyRnB1bGwlMkY0ODElMkZmaWxlcyUyM2RpZmYtN2MzNjliODVi MjZhNzQ2YTdlNzBjZDI4ODQwMzc4OTZkZWZlMDNiMzA5OGJlYzk3NmY3OWM5OTRkMjJhNjA0YVIy ODczJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MwMGMzMGJjNWQ1 ODc0NGNjMTk5MDA4ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhl JTdDMCU3QzAlN0M2Mzc2OTEzMjU1NDkzMTk0ODMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlK V0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2 TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9MDFtdHEwS1MzRkRuWloxSnl5Z0Q4UlhLbzlONjFCd2Rs VVl1cSUyRnhPc1FvJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL2dpdGh1Yi5jb20vbWxzd2cv bWxzLXByb3RvY29sL3B1bGwvNDgxL2ZpbGVzI2RpZmYtN2MzNjliODViMjZhNzQ2YTdlNzBjZDI4 ODQwMzc4OTZkZWZlMDNiMzA5OGJlYzk3NmY3OWM5OTRkMjJhNjA0YVIyODczPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccml0dGEsIGRv ZXMgdGhhdCB3b3JrIGZvciB5b3U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDYsIDIwMjEgYXQgMjowNSBBTSBLb25yYWQg S29oYnJvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGUi PmtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxi cj4NCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZSBzb2x1dGlvbnMgKDIpIGFuZCAoMykg KGRpc2NhcmRpbmcgMSBhbmQgNCBmb3Igbm93KSByZXByZXNlbnQgdHJhZGUtb2ZmcyBpbiBzZWN1 cml0eSBndWFyYW50ZWVzIGFuZCB0aGVpciBhcHBsaWNhYmlsaXR5IGRlcGVuZHMgb24gdGhlIHNw ZWNpZmljIGRlcGxveW1lbnQgc2NlbmFyaW8uIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBleHRl cm5hbCBqb2lucyB3aWxsIGJlIHN1YmplY3QgdG8gc29tZQ0KIHNvcnQgb2YgcG9saWN5IGFueXdh eS4gU2hvdWxkIHdlIHRoZW4gYmUgc3RyaWN0IGluIHRoZSBzcGVjIGluIHRlcm1zIG9mIHdoYXQg d2UgbWFuZGF0ZSB0aGUgZXhhY3QgcG9saWN5IHcuci50LiBQU0tzIGlzPw0KPGJyPg0KPGJyPg0K U2luY2UgSSBkb24ndCB0aGluayBlaXRoZXIgc29sdXRpb24gcmVwcmVzZW50cyBtdWNoIG9mIGEg Zm9vdC1ndW4sIEkgcHJvcG9zZSB3ZSBpbmNsdWRlIHRoZSBjYXBhYmlsaXR5IHRvIGluY2x1ZGUg cmVzeW5jIFBTS3MgaW4gdGhlIHNwZWMgZm9yIHRoaXMgcHVycG9zZSwgYnV0IGRvbid0IG1hbmRh dGUgdGhlbS4gSW5zdGVhZCB3ZSByZWxlZ2F0ZSB0aGUgcG9saWN5IGRlY2lzaW9uIHRvIHRoZSBh cHBsaWNhdGlvbiBsYXllciBhbmQgZGV0YWlsIHRoZQ0KIHNlY3VyaXR5IHRyYWRlLW9mZnMgaW4g dGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudC4gSSByZWFsaXplIHRoYXQgZGVsZWdhdGluZyBkZWNp c2lvbnMgdG8gdGhlIGFwcGxpY2F0aW9uIGxheWVyIGlzIGEgYml0IG9mIGEgY29wLW91dCBzb2x1 dGlvbiwgYnV0IEkgdGhpbmsgaW4gdGhpcyBjYXNlIGl0IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUg dGhlIG1lY2hhbmlzbSBpbiB0aGUgc3BlYyBhbmQgdGhlbiBsZXQgdGhlIGFwcGxpY2F0aW9uIGRl Y2lkZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KS29ucmFkPGJyPg0KPGJyPg0KJmd0OyBSaWNo YXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRhcmdldD0iX2JsYW5r Ij5ybGJAaXB2LnN4PC9hPiZndDsgaGF0IGFtIDA1LjEwLjIwMjEgMDQ6MzEgZ2VzY2hyaWViZW46 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgQnJpdHRhLDxicj4NCiZndDsgPGJy Pg0KJmd0OyBDb3VwbGUgb2YgcmVzcG9uc2VzIGlubGluZS4uLjxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IE9uIE1vbiwgT2N0IDQsIDIwMjEgYXQgODo0MiBQTSBIYWxlLCBCcml0dGEg KENJVikgJmx0OzxhIGhyZWY9Im1haWx0bzpicml0dGEuaGFsZUBucHMuZWR1IiB0YXJnZXQ9Il9i bGFuayI+YnJpdHRhLmhhbGVAbnBzLmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyBb dHJpbW1lZF08YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IFRvIHRoZSBwcmVz ZW50IHByb3Bvc2VkIG9wdGlvbnMsIEkgd2lsbCBub3RlIHRoYXQgdGhlIOKAmG5ldyBqb2luZXJz IGluIGludGVyaW3igJkgY2FzZSBpcyBsaWtlbHkgYSBtaXNsZWFkaW5nIGZvY3VzIHBvaW50IGZv ciB0aGUgZGlzY3Vzc2lvbiwgYW5kIHdlIHNob3VsZCBhdm9pZCB0cmlwcGluZyBpbnRvIHRoYXQg ZGl0Y2ggZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnM6DQo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5i c3A7KiBOb3RhYmx5LCBpZiBldmVyeW9uZSBleGNlcHQgZm9yIHRoZSByZS1zeW5jaW5nIHBhcnRp Y2lwYW50IGlzIG5ldywgd2h5IG5vdCBqdXN0IHJlcXVpcmUgdGhlIHJlLXN5bmNpbmcgcGFydGlj aXBhbnQgdG8gYmUgYWRkZWQgYXMgYSBuZXcgbWVtYmVyIHRoZW1zZWx2ZXM/IEl0IGlzLCBhZnRl ciBhbGwsIHByYWN0aWNhbGx5IGEgYnJhbmQgbmV3IGdyb3VwIGF0IHRoYXQgcG9pbnQuDQo8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7KiBJdCBpcyB0cnVlIHRoYXQgYSBuZXcgbWVtYmVyIHdv dWxkIG5vdCBnYWluIGZyb20gYSBQU0sgZ3VhcmFudGVlLCBidXQgd2h5IHNob3VsZCB3ZSByZWR1 Y2UgdGhlIGd1YXJhbnRlZXMgZm9yIGFsbCBvdGhlciBwYXJ0aWNpcGFudHMgdG8gdGhhdCBvZiB0 aGUgbmV3IGpvaW5lcj8gRnJvbSB0aGUgdmlldyBvZiB0aGUgbmV3IGpvaW5lciwgYWxsIHBhcnRp Y2lwYW50cyBhcmUgbmV3IGluIGFueSBjYXNlLCBzbyBlLmcuIFBDUyBkb2VzIG5vdA0KIGhhdmUg c3Vic3RhbnRpYWwgbWVhbmluZyBhcyBvZiB5ZXQuIEV4aXN0aW5nIG1lbWJlcnMgaGF2ZSBtb3Jl IHRvIGxvc2UgYW5kIGFsc28gaGF2ZSB0aGUgbW9yZSB0byBnYWluIGZyb20gUFNLIHVzZS4gSSBk byBub3QgYmVsaWV2ZSB3ZSB3YW50IHRvIGFkYXB0IGEgc3RhbmNlIG9mIOKAmGlmIHRoZSBuZXcg am9pbmVyIGRvZXNu4oCZdCBnZXQgYSBzZWN1cml0eSBndWFyYW50ZWUsIG5vIG9uZSBzaG91bGQg aGF2ZSB0aGUgc2VjdXJpdHkgZ3VhcmFudGVl4oCZDQog4oCTIGluIGZhY3QsIHRoZSB0cmVlIHN0 cnVjdHVyZSwgY29tbWl0IGhpc3RvcnksIGFuZCB0aGUgbGlrZSBwcm92aWRlIGluc2lnaHQgdG8g bG9uZ2VyIHRlcm0gbWVtYmVycyB0aGF0IGEgbmV3IGpvaW5lciBkb2VzIG5vdCBoYXZlLiBTbyAo Mikgb2ZmZXJzIGEgbmV3IGpvaW5lciB0aGUgYmVuZWZpdHMgb2YgKDMpIGJ1dCB0byBhbGwgb3Ro ZXJzIGFuIGV2ZW4gc3Ryb25nZXIgZ3VhcmFudGVlLg0KPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyogQXMgYSBub2QgdG8gd2hhdCBhIG5ldyBqb2luZXIgbWF5IGdhaW4sIHdlIGNhbiBvZmZl ciB0aGUgZm9sbG93aW5nOiBpZiBhIHJlLXN5bmMgUFNLIGZhaWxzLCB0aGVuIHdoaWNoZXZlciBl eGlzdGluZyBtZW1iZXIgY2hlY2tzIGFuZCBub3RlcyB0aGUgUFNLIGZhaWx1cmUgc2hvdWxkIGlu aXRpYXRlIGEgcmVtb3ZhbCBvZiB0aGUgcmVzeW5jaW5nIG1lbWJlci4gSWYgdGhlcmUgaXMgYSBu ZXcgam9pbmVyLCB0aGVuIGJ5IGNvbnRpbnVlZA0KIHByZXNlbmNlIG9mIHRoZSByZS1zeW5jaW5n IG1lbWJlciB0aGV5IGdhaW4gdGhlIGd1YXJhbnRlZSB0aGF0IGF0IGxlYXN0IG9uZSBvdGhlciBn cm91cCBtZW1iZXIgaGFzIHByZXZpb3VzbHkgc2VlbiB0aGF0IG1lbWJlciwgb3IgZWxzZSB3b3Vs ZCBoYXZlIGVqZWN0ZWQgdGhlbSAoYXNzdW1pbmcgdGhhdCB0aGUgY2hlY2tlciBpcyBvbmxpbmUp Ljxicj4NCiZndDsgSSBkb24ndCBtZWFuIHRvIG92ZXItcm90YXRlIG9uIHRoaXMgY2FzZSwgYnV0 IHNvZnR3YXJlIGJlaW5nIHNvZnR3YXJlLCB3ZSBuZWVkIGFuIGFsZ29yaXRobSB0byBpbXBsZW1l bnQgdGhhdCBjb3ZlcnMgYWxsIHRoZSBjYXNlcy4gV2hpbGUgdGhlICZxdW90O2V2ZXJ5b25lIGlz IG5ldyZxdW90OyBzY2VuYXJpbyBpcyBvdXRsYW5kaXNoLCBpdCB3b3VsZG4ndCBiZSBhbGwgdGhh dCBzdXJwcmlzaW5nIHRvIGhhdmUgb25lIG9yIHR3byBuZXcgbWVtYmVycywgc28gaXQncw0KIGEg Y2FzZSB0aGF0IHdvdWxkIG5lZWQgYWRkcmVzc2luZy4gVGhlIHNlZW1pbmdseSBtb3N0IG9idmlv dXMgYXBwcm9hY2ggdG8gYWRkcmVzc2luZyB0aGlzIHByb2JsZW0gaXMgdG8gZW5jcnlwdCB0aGUg UFNLIHRvIG5ldyBtZW1iZXJzLCB3aGljaCByZXF1aXJlcyB5b3UgYXQgbGVhc3QgaGF2ZSBlbm91 Z2ggc3RhdGUgdG8gZmlndXJlIG91dCB3aG8gdGhlIG5ldyBtZW1iZXJzIGFyZS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgSXQgYWxzbyBvY2N1cnMgdG8gbWUgbm93IHRoYXQgdGhlIFBTSyBhcHByb2Fj aCBwcmVzdW1lcyB0aGF0IHlvdSBrbm93IHdoZW4geW91ciBzdGF0ZSB3ZW50IGJhZCwgc2luY2Ug eW91IHdvdWxkIHdhbnQgdG8gdXNlIGEgUFNLIGZyb20gYmVmb3JlIHRoYXQgcG9pbnQuIEluIFJh cGhhZWwncyBleGFtcGxlIHdoZXJlIHBlcnNpc3RlbnQgc3RvcmFnZSBpcyBjb3JydXB0ZWQsIGFs bCB5b3Uga25vdyBpcyB0aGF0IG1lc3NhZ2VzIHN0b3BwZWQgZGVjcnlwdGluZywNCiB3aGljaCBn aXZlcyB5b3UgYW4gdXBwZXIgYm91bmQgb24gdGhlIHRpbWUgb2YgY29ycnVwdGlvbiwgYnV0IG5v dCByZWFsbHkgYSB3YXkgdG8gZ28gYmFjayBhbmQgZmlndXJlIG91dCB3aGF0J3MgZ29vZC48YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBzZWN1cml0eSBnb2FsIGluIHRo ZSBiYWxhbmNlIGhlcmUgaXMgUENTLiBBZGRpbmcgYSByZS1zeW5jIG9wdGlvbiBvZiBhbnkgb2Yg dGhlIHZhcmlldGllcyAoMiktKDQpIHdvdWxkIGJyZWFrIHRoYXQgdG8gc29tZSBkZWdyZWUsIHNp bmNlIGZvbGxvd2luZyBhIGNvbXByb21pc2UgYW5kIHBhc3NpdmUgcGVyaW9kIHRoZSBhZHZlcnNh cnkgaXMgdGhlbiBlbmFibGVkIHRvIHJlZ2FpbiBhIGZvb3Rob2xkLiBUaGUgcXVlc3Rpb24gaXMg aG93DQogbXVjaCBvZiBhIGRlZ3JlZSBvZiBsb3NzIGFyZSB3ZSB3aWxsaW5nIHRvIHRvbGVyYXRl LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdtIG5vdCBzdXJlIEkgd291bGQgcmVhbGx5IGNoYXJh Y3Rlcml6ZSB0aGlzIGFzIGEgUENTIHZpb2xhdGlvbi4gUENTIGlzIGEgZ3VhcmFudGVlIHRoYXQg eW91IGdldCB3aGVuIHlvdSB0YWtlIGEgY2VydGFpbiBhY3Rpb24uIEZvciBleGFtcGxlLCB3aGVu IGEgbWVtYmVyIGlzc3VlIGFuIFVwZGF0ZSBvciBhIENvbW1pdCB3aXRoIGEgZnJlc2ggSFBLRSBr ZXkgcGFpciwgeW91IHNob3VsZCBnZXQgUENTIHdpdGggcmVnYXJkIHRvIHRoYXQgcGFydGljaXBh bnQncw0KIEhQS0Uga2V5IHBhaXI7IGxpa2V3aXNlIHdpdGggcm90YXRpbmcgc2lnbmF0dXJlIGtl eXMuIEhlcmUsIHRoZSBzaWduYXR1cmUga2V5IGhhcyBub3QgYmVlbiByb3RhdGVkLCBzbyB0aGVy ZSdzIG5vIFBDUyBib3VuZGFyeS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgaXMgd29ydGggY29u c2lkZXJpbmcgd2hldGhlciB0aGlzIG1lY2hhbmlzbSBnaXZlcyB0aGUgYXR0YWNrZXIgYW55IGFk ZGl0aW9uYWwgY2FwYWJpbGl0aWVzIGluIHRoZSBldmVudCB0aGF0ICgxKSB0aGUgc2lnbmF0dXJl IGtleSBpcyBjb21wcm9taXNlZCwgYW5kICgyKSB0aGUgY29tcHJvbWlzZWQgbWVtYmVyIGlzc3Vl cyBhbiBVcGRhdGUgb3IgQ29tbWl0IHJvdGF0aW5nIHRoZSBzaWduYXR1cmUga2V5LiBJU1RNIHRo YXQgeW91IHN0aWxsDQogZ2V0IFBDUyB0aGVyZSBpbiBvcHRpb24gKDMpLCBzaW5jZSB0aGUgcmVx dWlyZW1lbnQgdGhhdCB0aGUgc2lnbmF0dXJlIGtleXMgbWF0Y2ggZW5zdXJlcyB0aGF0IHRoZSBv bGQsIGNvbXByb21pc2VkIHNpZ25hdHVyZSBrZXkgaXMgbm90IGFsbG93ZWQgdG8gcmVzeW5jIGJh Y2sgaW50byB0aGUgZ3JvdXAuIFRoZXJlJ3Mgc3RpbGwgYSByaXNrIHRoYXQgdGhlIGNvbXByb21p c2VkIGtleSAvIGNyZWRlbnRpYWwgY291bGQgYmUgdXNlZCBmb3IgYSBmcmVzaCwNCiBub24tcmVz eW5jIGpvaW4sIGJ1dCB0aGF0J3MgYW4gaW5oZXJlbnQgcmlzayB3aXRoIGV4dGVybmFsIENvbW1p dCAvIGZyZWVseSBqb2luYWJsZSBncm91cHMsIGFuZCBhbHNvIGFuIG9wcG9ydHVuaXR5IGZvciB0 aGUgQVMncyByZXZvY2F0aW9uL2ludmFsaWRhdGlvbiBzeXN0ZW0gdG8gaGVscC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgV2lsbCB0YWtlIGEgbG9vayBhdCB0aGUgcmVtYWluZGVyIGluIHRoZSBtb3Ju aW5nLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tUkxCPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsqIEkgYWdyZWUgdGhhdCAoNCkgaXMgYW4gaW1tZWRp YXRlIGRpc2NhcmQuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyogVW5kZXIgKDIpIGEgUFNL IHVzZSwgdGhlIFBTSyB1c2UgYXQgbGVhc3QgbW9yZSBsaW1pdGVkIGR1ZSB0byB0aGUgcHJvb2Yg b2Yga25vd2xlZGdlIG9mIGEgcGFzdCBzdGF0ZSAoZS5nLiBub3RlcyBhYm92ZSkuIFRoaXMgaXMg YSB3b3J0aHdoaWxlIHByb3BlcnR5IHRvIGVuZm9yY2UgaW4gbXkgdmlldyBzaW5jZSBpdCBiYWxh bmNlcyBhdXRoZW50aWNhdGlvbiBhY3Jvc3MgdHdvIHZlY3RvcnM6IHRoZSBzaWduYXR1cmUga2V5 IGFuZCBrbm93bGVkZ2UNCiBvZiBncm91cCBzdGF0ZS4gQWR2ZXJzYXJ5IGFjY2VzcyB0byBvbmx5 IG9uZSBvciB0aGUgb3RoZXIgaXMgaW5zdWZmaWNpZW50IGZvciB0aGUgYWR2ZXJzYXJ5IHRvIGVq ZWN0IEFsaWNlIGFuZCByZXBsYWNlIGhlciBpbiB0aGUgZ3JvdXAuDQo8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7KiBVbmRlciAoMyksIHRoZSBhdHRhY2sgc2NlbmFyaW8gb2YgRXZlIGNvbXBy b21pc2luZyBBbGljZSAoZnVsbCBzdGF0ZSArIHNpZyBrZXkpLCBmb2xsb3dlZCBldmVudHVhbGx5 KiBieSByZW1vdmluZyBBbGljZSB3aGlsZSBhZGRpbmcgaGVyc2VsZiwgaXMgbm90IGRpc3NpbWls YXIgZnJvbSB0aGUgYXR0YWNrIHNjZW5hcmlvIG9mIEV2ZSBjb21wcm9taXNpbmcgQWxpY2UgZnVs bCBzdGF0ZSArIHNpZyBrZXkpIGZvbGxvd2VkIGV2ZW50dWFsbHkqDQogYnkgcHJvdmlkaW5nIGFu IGltcGVyc29uYXRpbmcgdXBkYXRlIGluIEFsaWNl4oCZcyBuYW1lLiBXaGF0IGhhcyBiZWVuIHNo b3duIHNvIGZhciBpcyB0aGF0IHRoaXMgdHlwZSBvZiBzY2VuYXJpbyBjYW4gYmUgbGltaXRlZCBi eSByb3RhdGluZyBzaWduYXR1cmUga2V5cy4gQSBpbXBvcnRhbnQgcG9pbnQgdGhhdCBpcyBkaWZm ZXJlbnQgaW4gdGhlc2Ugc2NlbmFyaW9zIGlzIHRoYXQgdW5kZXIgdGhlIGZpcnN0IEFsaWNlIGtu b3dzIHNoZSB3YXMgcmVtb3ZlZA0KIChhIHBsdXMpIHdoaWxlIHVuZGVyIHRoZSBzZWNvbmQgKGN1 cnJlbnRseSBwb3NzaWJsZSkgc2NlbmFyaW8gdGhlIGdyb3VwIHNpbXBseSBnb2VzIHNpbGVudCBh bmQgQWxpY2UgZG9lcyBub3Qga25vdyBpZiBpdCB3YXMgbWFsaWNpb3VzIG9yIG5vdC4gQWxsIHNh aWQsIGl0IGNvdWxkIGJlIHdvcnNlLiBUaGF0IGRvZXMgbm90IGNvbnNpZGVyIG90aGVyIGF0dGFj ayBzY2VuYXJpb3MgdGhvdWdoLCBmb3IgZXhhbXBsZSB3aGVuIHRoZSBhdHRhY2tlcg0KIGdhaW5z IHRoZSBzaWduYXR1cmUga2V5IGJ1dCBub3QgcGFzdCBzdGF0ZS9QU0suIDxicj4NCiZndDsgJmd0 OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgKkkuZS4gYWZ0ZXIgYSBwb3RlbnRpYWxseSBwYXNzaXZl IHBlcmlvZCwgaWYgd2UgYXJlIHRvIHNob3cgaG93IHRoaXMgYmVoYXZlcyBpbiB0aGUgUENTIHNj ZW5hcmlvLjxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgVGhpcyBsZWFkcyB0 byBhbiBpbXBvcnRhbnQgcXVlc3Rpb246IGRvZXMgb3VyIGN1cnJlbnQgdW5pcXVlbmVzcyBvZiBz aWcga2V5IHByZWRpY2F0ZSBsaW1pdCB0aGUgYWJpbGl0eSB0byByb3RhdGUgc2lnbmF0dXJlIGtl eXMgd2l0aGluIGEgZ3JvdXA/IFRoYXQgaXMgb3VyIG1lYW5zIG9mIGxpbWl0aW5nIHRoZSBmdWxs IHN0YXRlICsgc2lnIGtleSBjb21wcm9taXNlIHNjZW5hcmlvIGltcGFjdHMgbWVudGlvbmVkIGFi b3ZlLCBhbmQgdGhlcmVmb3JlDQogdGhlIG1lYW5zIG9mIGxpbWl0aW5nIHRoZSBkcmF3YmFja3Mg b2YgKDMpLiBXZSBzaG91bGQgbWFrZSBzdXJlIHRoYXQgdGhlIGxpbWl0aW5nIGFiaWxpdHkgaXMg ZmVhc2libGUuIElmIHRoYXQgaGluZGVyZWQgaW4gYW55IHdheSwgdGhlbiBJIHdvdWxkIHZvdGUg dmVyeSBzdHJvbmdseSBmb3IgKDIpIGFzIGl0IGF0IGxlYXN0IGJvb3RzdHJhcHMgc29tZSBvZiB0 aGUgYXV0aGVudGljYXRpb24gcHJvcGVydGllcyBmcm9tIHRoZSBncm91cCBzdGF0ZQ0KIGluIHRo ZSBzY2VuYXJpbyB0aGF0IHRoZSBzaWcga2V5IGlzIGNvbXByb21pc2VkLjxicj4NCiZndDsgJmd0 OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IEFsbCB0aGUgYmVz dCw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IEJyaXR0YTxicj4NCiZndDsg Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxi cj4NCiZndDsgJmd0OyBGcm9tOk1MUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1scy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBi ZWhhbGYgb2YgUmljaGFyZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0 YXJnZXQ9Il9ibGFuayI+cmxiQGlwdi5zeDwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IERh dGU6TW9uZGF5LCBPY3RvYmVyIDQsIDIwMjEgYXQgNDowOSBQTTxicj4NCiZndDsgJmd0OyZuYnNw OyBUbzpNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzptbHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyBTdWJqZWN0OltNTFNdIFJlc3luYyBhcmNoYWVvbG9neSArIGFuYWx5c2lzICsg cHJvZ25vc2lzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsgJmd0OyBPSywgSSB0aGlu ayBJIGhhdmUgdHJhY2VkIGJhY2sgc29tZSBpZGVhIG9mIHdoeSB3ZSByZW1vdmVkIHRoZSBlYXJs aWVyIHJlc3luYyBwcm9wb3NhbC4gSGVyZSdzIGEgbGl0dGxlIGVzc2F5IG9uIGhvdyB3ZSBnb3Qg aGVyZSwgYSByZWNhcCBvZiB0aGUgdHJhZGUtb2ZmcywgYW5kIG15IHRob3VnaHRzIG9uIHdoZXJl IHdlIHNob3VsZCBnby48YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IHRsO2Ry OiBFYXJsaWVyIGRlY2lzaW9uIG5vdCBkaXNwb3NpdGl2ZTsgd2Ugc2hvdWxkIGRvIGJhc2ljYWxs eSB3aGF0J3MgaW4gdGhlIFBSIG5vdy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICMgSGlzdG9yeTxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsg VGhlIHN0b3J5IHN0YXJ0cyBhbGwgdGhlIHdheSBiYWNrIGF0IHRoZSBKYW51YXJ5IDIwMTkgaW50 ZXJpbSBhdCBNb3ppbGxhIC8gTW91bnRhaW4gVmlldy4gVGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiB0 aGVyZSBvZiBBQ0svTkFDSyBhbmQgcmVwbGF5IGFzIHJlbGF0ZWQgaXNzdWVzIFsxXS4gVGhhdCBk aXNjdXNzaW9uIHNlZW1zIHRvIGhhdmUgbGVkIHRvIGFncmVlbWVudCB0aGF0IGEgY29tcGxldGUg ZXJyb3IgcmVjb3Zlcnkgc3lzdGVtIHdhcw0KIGEgY29tcGxleCBlbm91Z2ggdG9waWMsIGFuZCBj bGVhcmx5IGVub3VnaCBzZXBhcmF0ZWQgZnJvbSB0aGUgbWFpbiBwcm90b2NvbCB0aGF0IGl0IGNv dWxkIGJlIGhhbmRsZWQgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uLiBBcyBhIHJlc3VsdCwg dGhlIGlzc3VlcyB0aGF0IGhhZCBiZWVuIG9wZW5lZCBmb3IgQUNLL05BQ0sgYW5kIHJlc3luYyB3 ZXJlIGNsb3NlZCBbMl1bM10uIFdoZW4gQnJpdHRhIGFuZCBLb25yYWQgcG9zdGVkICMzMzYgWzRd DQogaW5jbHVkaW5nIGEgcmVzeW5jIG1lY2hhbmlzbSwgbXkgcmV2aWV3IHNpbXBseSBjaXRlZCB0 aGF0IGVhcmxpZXIgY2xvc2VkIGlzc3VlIGFzIGEgcmVhc29uIGZvciB0YWtpbmcgaXQgb3V0IFs1 XS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IE9uZSBvdGhlciBu b3RlIHdpdGggcmVnYXJkIHRvICMzMzYgLS0gSXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgJnF1b3Q7 cmVzeW5jJnF1b3Q7IG1lY2hhbmlzbSBpbiB0aGVyZSB3YXMgbm90IHJlYWxseSBmbGVzaGVkIG91 dCBlbm91Z2ggdG8gYmUgaW1wbGVtZW50YWJsZS4gVGhlIHN0YXRlIGxpbmtlZCBhYm92ZSB3YXMg dGhlIGxhc3Qgc3RhdGUgYmVmb3JlIG15IHJldmlldywgYW5kIHRoZSB3b3JkICZxdW90O3Jlc3lu YyZxdW90OyBkb2Vzbid0IGFjdHVhbGx5IGFwcGVhci4NCiBJbnN0ZWFkIHRoZSBQUiB0YWxrcyBh Ym91dCAmcXVvdDtyZWNvdmVyaW5nIGxvc3QgZ3JvdXAgbWVtYmVycyZxdW90OyB1c2luZyBBZGQg YW5kIFBTSywgd2hpY2ggY291bGQgYmUgZWxhYm9yYXRlZCB0byBzb2x2ZSBhIHZlcnNpb24gb2Yg dGhpcyBwcm9ibGVtLCBidXQgd291bGQgcmVxdWlyZSB0aGUgYXNzaXN0YW5jZSBvZiBhIGNvbnRp bnVpbmcgbWVtYmVyIHJhdGhlciB0aGFuIGFsbG93aW5nIHRoZSBsb3N0IG1lbWJlciB0byByZXN5 bmMgdW5pbGF0ZXJhbGx5Lg0KIEl0IHdvdWxkIGFsc28gaGF2ZSB0aGUgc2FtZSBpc3N1ZXMgbm90 ZWQgaW4gdGVybXMgb2YgbmV3IGpvaW5lcnMgbm90IGhhdmluZyByZXN5bmMgUFNLcy48YnI+DQom Z3Q7ICZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IE92ZXJhbGwsIHRob3VnaCwgcmVh ZGluZyB0aGlzIGhpc3RvcnkgZG9lc24ndCBzZWVtIHRvIG1lIGxpa2Ugd2UgcmVhbGx5IG1hZGUg YSBwcmluY2lwbGVkIGRlY2lzaW9uIG5vdCB0byBkbyByZXN5bmMuIFdlIGp1c3QgcHVudGVkIGFm dGVyIHNvbWUgZGlzY3Vzc2lvbiBpbiB0aGUgYWJzdHJhY3QsIGFuZCB0aGF0IHN0dWNrLiBXZSBo YXZlIGEgbW9yZSBjb25jcmV0ZSBxdWVzdGlvbiBub3cuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxi cj4NCiZndDsgJmd0OyZuYnNwOyAjIEFuYWx5c2lzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4N CiZndDsgJmd0OyZuYnNwOyBTaW5jZSB0aGUgZGlzY3Vzc2lvbiBvZiAjMzM2IGluIDIwMjAsIHdl IGhhdmUgYWRkZWQgZXh0ZXJuYWwgY29tbWl0cyBpbiBvcmRlciB0byBoYXZlIGdyb3VwcyB5b3Ug Y2FuIGpvaW4gdW5pbGF0ZXJhbGx5LiBTbyByZWdhcmRsZXNzIG9mIHRoZSBicm9hZGVyIHF1ZXN0 aW9uIG9mIHJlc3luYywgd2UgaGF2ZSB0byBkZWNpZGUgd2hhdCBwcm9wb3NhbHMgYSBqb2luZXIg aXMgYWxsb3dlZCB0byBvcmlnaW5hdGUgaW4gdGhlaXIgQ29tbWl0IChzZW5kaW5nDQogdGhlbSBi eSB2YWx1ZSksIGluIHBhcnRpY3VsYXIsIHdoZXRoZXIgYW4gZXh0ZXJuYWwgQ29tbWl0IGNhbiBj b250YWluIGEgam9pbmVyLW9yaWdpbmF0ZWQgUmVtb3ZlIHByb3Bvc2FsLiBXZSBoYXZlIGEgc3Bl Y3RydW0gb2Ygb3B0aW9ucyBoZXJlOjxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgMS4gRm9yYmlkIFJlbW92ZSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgMi4gQWxsb3cg UmVtb3ZlICsgcmVxdWlyZSB0aGUgKGlkZW50aXR5LCBlbmRwb2ludF9pZCkgYW5kIHNpZ25hdHVy ZSBrZXkgdG8gbWF0Y2ggdGhlIHJlbW92ZWQgbm9kZSArIHJlcXVpcmUgcmVzdW1wdGlvbiBQU0s8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgMy4gQWxsb3cgUmVtb3ZlICsgcmVxdWlyZSB0aGUgKGlkZW50 aXR5LCBlbmRwb2ludF9pZCkgYW5kIHNpZ25hdHVyZSBrZXkgdG8gbWF0Y2ggdGhlIHJlbW92ZWQg bm9kZTxicj4NCiZndDsgJmd0OyZuYnNwOyA0LiBBbGxvdyBSZW1vdmUgd2l0aG91dCByZXN0cmlj dGlvbjxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgT3B0aW9ucyAo MSkgYW5kICgyKSB3b3VsZCBibG9jayBhbiBhdHRhY2tlciB0aGF0IGhhcyBjb21wcm9taXNlZCBh IG1lbWJlcidzIHNpZ25hdHVyZSBrZXkgZnJvbSBqb2luaW5nIGFzIHRoYXQgbWVtYmVyIGFuZCBl dmljdGluZyB0aGUgb2xkIGFwcGVhcmFuY2UuIE9wdGlvbiAoMikgYmVjYXVzZSBvZiB0aGUgUFNL OyBvcHRpb24gKDEpIGJlY2F1c2Ugb2YgdGhlIHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnRzIChhcyBS YXBoYWVsIHBvaW50ZWQNCiBvdXQgb24gdGhlIGNhbGwpLjxicj4NCiZndDsgJmd0OyZuYnNwOyA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgT3B0aW9ucyAoMSkgYW5kICgyKSBkbyBub3QgYWxsb3cgYSBj bGllbnQgd2hvIGhhcyBsb3N0IGV2ZXJ5dGhpbmcgYnV0IHRoZWlyIHNpZ25hdHVyZSBrZXkgdG8g cmVzeW5jLiBPcHRpb24gKDEpIHdvdWxkIHJlcXVpcmUgYSBuZXcgZW5kcG9pbnRfaWQgYW5kIHNp Z25hdHVyZSBrZXksIHdoaWNoIG1pZ2h0IG5vdCBiZSBmZWFzaWJsZSBpbiBhbGwgY2FzZXMuIE9w dGlvbiAoMikgd291bGQgYWxzbyBuZWVkIHRvIGhhdmUgZXh0cmEgbWVjaGFuaXNtDQogdG8gYWNj b3VudCBmb3IgcmVjZW50IGpvaW5lcnMgbm90IGhhdmluZyB0aGUgcmVxdWlyZWQgcmVzdW1wdGlv biBQU0suPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZuYnNwOyBPcHRpb24g KDEpIHdvdWxkIGFsc28gbm90IGFsbG93IGZvciByZXN5bmMgd2l0aCBqdXN0IGEgc2lnbmF0dXJl IGtleS4gQXMgUmFwaGFlbCBwb2ludGVkIG91dCwgYmVjYXVzZSB3ZSBub3cgcmVxdWlyZSBzaWdu YXR1cmUga2V5cyB0byBiZSB1bmlxdWUsIHRoZSBtZW1iZXIgd291bGQgaGF2ZSB0byBtaW50IGEg bmV3IHNpZ25hdHVyZSBrZXkgYW5kIGdldCBpdCBhdXRoZW50aWNhdGVkLCBvciBlbHNlIHRoZWly IGF0dGVtcHQgdG8gcmVqb2luDQogd291bGQgYmUgcmVqZWN0ZWQgYXMgYSBkdXBsaWNhdGUgZW50 cnkuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZuYnNwOyBPcHRpb25zICgz KSBhbmQgKDQpIHdvdWxkIGFsbG93IGEgY2xpZW50IHdobyBoYXMgbG9zdCBldmVyeXRoaW5nIGJ1 dCB0aGVpciBzaWduYXR1cmUga2V5IHRvIHJlc3luYywgYXQgdGhlIHJpc2sgdGhhdCBhbiBhdHRh Y2tlciB3aG8gaGFzIGNvbXByb21pc2VkIGEgbWVtYmVyJ3Mgc2lnbmF0dXJlIGtleSBjb3VsZCBh YnVzZSBpdCB0byBqb2luIGFzIHRoYXQgbWVtYmVyIGFuZCBldmljdCB0aGUgb2xkLCBsZWdpdGlt YXRlIGFwcGVhcmFuY2UuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZuYnNw OyAjIFByb2dub3Npczxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsg QWZ0ZXIgdGhpcyBkaXNjdXNzaW9uIGFuZCBhbmFseXNpcywgSSBjb250aW51ZSB0byB0aGluayB0 aGF0ICgzKSBhYm92ZSBpcyB0aGUgcmlnaHQgYW5zd2VyLCB3aXRoIGFuIG9wdGlvbmFsIHVwZ2Fk ZSB0byAoMikuIFByb2NlZWRpbmcgYnkgZWxpbWluYXRpb246PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 IDxicj4NCiZndDsgJmd0OyZuYnNwOyBPcHRpb24gKDQpLCB3aGlsZSB0ZWNobmljYWxseSBmZWFz aWJsZSwgaXMgY2xlYXJseSBhIGxpdHRsZSBzaWxseS4gVGhlcmUncyBubyByZWFzb24gdG8gYWxs b3cgam9pbmVycyB0byBkbyBhIHJlbW92ZSBpbiB0aGUgc2FtZSBvcGVyYXRpb24gYXMgdGhleSBq b2luOyB0aGV5IGNvdWxkIGRvIHRoaXMgYWZ0ZXJ3YXJkLjxicj4NCiZndDsgJmd0OyZuYnNwOyA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgT3B0aW9uICgyKSBkb2VzIG5vdCBzZWVtIHdvcmthYmxlIGlu IGdlbmVyYWwgYmVjYXVzZSBvZiB0aGUgcmVjZW50LWpvaW5lciBwcm9ibGVtLiBXaGlsZSBtZWNo YW5pc20gY291bGQgYmUgZGVzaWduZWQgdG8gcHJvdmlkZSB0aGUgUFNLIHRvIHJlY2VudCBqb2lu ZXJzLCBpdCB3b3VsZCBhZGQgYSBsb3Qgb2YgY29tcGxleGl0eSwgYW5kIHRoZSByZWNlbnQgam9p bmVycyB3b3VsZG4ndCBnZXQgYW55IGJlbmVmaXQgZnJvbSBpdCwgd2hpY2gNCiBkaWx1dGVzIHRo ZSB2YWx1ZSBvZiB0aGlzIG1lY2hhbmlzbS4gKEl0J3Mgbm90IGltcG9zc2libGUgdG8gYXJyaXZl IGF0IHRoZSBjYXNlIHdoZXJlIGV2ZXJ5b25lIGJlc2lkZXMgdGhlIHJlc3luYydpbmcgcGFydGlj aXBhbnQgaXMgbmV3ISkNCjxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJz cDsgV2l0aCBvcHRpb24gKDEpLCB5b3UgbG9zZSBhbnkgbm90aW9uIG9mIHJlc3luYzsgSSB0aGlu ayB0aGUgbmVlZCBmb3IgZW5kcG9pbnRfaWQgcm90YXRpb24gbWFrZXMgdGhpcyB1bndvcmthYmxl IGluIHByYWN0aWNlLiBBbmQgaXQgaGFzIGtpbmQgb2YgYW4gb2RkIG5vdGlvbiBvZiBzZWN1cml0 eTogWW91IGFyZSBwcm90ZWN0ZWQgYWdhaW5zdCBhbiBhdHRhY2tlciB0aGF0IGhhcyBjb21wcm9t aXNlZCBhIGN1cnJlbnQgc2lnbmF0dXJlIGtleQ0KIGJ1dCBjYW4ndCBnZXQgYSBuZXcgb25lIGF1 dGhlbnRpY2F0ZWQuIFRoaXMgaXMgYSBwcm9ibGVtIGZvciB0aGUgYXV0aGVudGljYXRpb24gc3lz dGVtIHRvIGhhbmRsZSAoZS5nLiwgd2l0aCByZXZvY2F0aW9uKSwgbm90IGZvciB0aGUga2V5IGV4 Y2hhbmdlIC0tIGlmIHlvdSBoYXZlIHZhbGlkIGNyZWRlbnRpYWxzIHdpdGggY29tcHJvbWlzZWQg a2V5cyBmbG9hdGluZyBhcm91bmQsIHlvdSBoYXZlIGJpZ2dlciBwcm9ibGVtcyB0byBzb2x2ZS4g U28NCiBteSBwZXJzb25hbCBhc3Nlc3NtZW50IGlzIHRoYXQgKDEpIGRvZXNuJ3QgcHJvdmlkZSBh IGJpZyBqdW1wIGluIHNlY3VyaXR5IG92ZXIgKDMpLCBhc3N1bWluZyB5b3UgaGF2ZSBhIGZ1bmN0 aW9uaW5nIGF1dGhlbnRpY2F0aW9uIHN5c3RlbS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7IFR3byBzaWRlIG5vdGVzIGFib3V0ICgzKTogRmlyc3QsIGlmIHdlIGRv ICgzKSBidXQgKmFsbG93KiBQU0tzLCB0aGVuIGFuIGFwcGxpY2F0aW9uIGNvdWxkIG9wdCBpbiB0 byAoMikuIFNlY29uZCwgdGhpcyB3aG9sZSBtZWNoYW5pc20gaXMgb3B0LWluIGZvciB0aGUgYXBw bGljYXRpb24sIHNpbmNlIHlvdSBjYW4ndCBkbyBhbiBleHRlcm5hbCBjb21taXQgaWYgYSBQdWJs aWNHcm91cFN0YXRlIGhhc24ndCBiZWVuIHB1Ymxpc2hlZC48YnI+DQomZ3Q7ICZndDsmbmJzcDsg PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IENvbmNyZXRlbHksIG15IHByb3Bvc2FsIGhlcmUgd291bGQg YmUgKDMpICsgKDIqKSAtLSBBbGxvdyBSZW1vdmUgd2l0aCBtYXRjaGluZyBwYXJhbWV0ZXJzLCBh bmQgYWxsb3cgUFNLcyBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gb3B0IGluIHRvICgyKSB3aGVy ZSB0aGV5IGNhbiBtYWtlIGl0IHdvcmsuIFRoYXQgd2F5LCBpZiBhbiBhcHBsaWNhdGlvbiBvcHRz IGluIHRvIGV4dGVybmFsIENvbW1pdHMsIHRoZXkgZ2V0IHRoZSBiZW5lZml0DQogb2YgcmVzeW5j IGFuZCB0aGUgc2FtZSBzaWduYXR1cmUta2V5LWNvbXByb21pc2UgYm91bmQgb24gaW1wZXJzb25h dGlvbiBmb3IgcmVzeW5jIGFzIHdlbGwgYXMgbmV0LW5ldyBqb2lucy4gQW5kIGlmIGFuIGFwcGxp Y2F0aW9uIGNhbiBmaWd1cmUgb3V0IGhvdyB0byBtYWtlICgyKSB3b3JrLCB0aGV5IGNhbiByZXF1 aXJlIGl0Ljxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgTG9va2lu ZyBmb3J3YXJkIHRvIG90aGVycycgdGhvdWdodHMgaGVyZSE8YnI+DQomZ3Q7ICZndDsmbmJzcDsg PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IC0tUkxCPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZn dDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgWzFdIDxhIGhyZWY9Imh0dHBzOi8v bmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmdpdGh1Yi5jb20lMkZtbHN3ZyUyRndnLW1hdGVyaWFscyUyRmJsb2IlMkZtYWluJTJGaW50ZXJp bS0yMDE5LTAxJTJGbWludXRlcy5tZCUyM2Fja3MtYW5kLW5hY2tzLWpvbm0mYW1wO2RhdGE9MDQl N0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzAwYzMwYmM1ZDU4NzQ0Y2MxOTkwMDhkOTg4 ZTFjNTMzJTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5 MTMyNTU0OTMyOTQ3NyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFt cDtzZGF0YT1Xa3laNUljQjVLZnRkNGhKam5uZVclMkY0UUVnYzN6WXJkUDRsZW9kJTJCS1ltSSUz RCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL21s c3dnL3dnLW1hdGVyaWFscy9ibG9iL21haW4vaW50ZXJpbS0yMDE5LTAxL21pbnV0ZXMubWQjYWNr cy1hbmQtbmFja3Mtam9ubTwvYT4gKDxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3 ZyUyRndnLW1hdGVyaWFscyUyRmJsb2IlMkZtYWluJTJGaW50ZXJpbS0yMDE5LTAxJTJGbWludXRl cy5tZCUyM2Fja3MtYW5kLW5hY2tzLWpvbm0mYW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxl JTQwbnBzLmVkdSU3QzAwYzMwYmM1ZDU4NzQ0Y2MxOTkwMDhkOTg4ZTFjNTMzJTdDNmQ5MzYyMzFh NTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MTMyNTU0OTMzOTQ3NCU3Q1Vu a25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlM Q0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT16Q0dwMHhRc0dR UGlZTjlCcXNIQTlKRyUyRkY4bWFRaG00ZVVPVVJBZmJHSG8lM0QmYW1wO3Jlc2VydmVkPTAiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZ3Zy1tYXRlcmlhbHMl MkZibG9iJTJGbWFpbiUyRmludGVyaW0tMjAxOS0wMSUyRm1pbnV0ZXMubWQlMjNhY2tzLWFuZC1u YWNrcy1qb25tJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MxZWJm OTZjMzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5 NjMzNzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NDQ4MDglN0NVbmtub3duJTdDVFdGcGJHWnNi M2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxD SlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9JTJCRXByUU1PVmslMkJJTmhkdFJ4SEw1SmZH USUyRmVQNnRDRnZjQU0zdW9wTUZxNCUzRCZhbXA7cmVzZXJ2ZWQ9MDwvYT4pPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7IFsyXSA8YSBocmVmPSJodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMt cHJvdG9jb2wlMkZpc3N1ZXMlMkY5MiZhbXA7ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBu cHMuZWR1JTdDMDBjMzBiYzVkNTg3NDRjYzE5OTAwOGQ5ODhlMWM1MzMlN0M2ZDkzNjIzMWE1MTc0 MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkxMzI1NTQ5MzM5NDc0JTdDVW5rbm93 biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJU aUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPXp1NUpKalhCS09QcnJ4 VTc3OXhGQkk4cFNUMVhtVXN4N2tCRmZCY0REblElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJvdG9jb2wvaXNzdWVzLzky PC9hPiAoPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3RvY29s JTJGaXNzdWVzJTJGOTImYW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3 QzAwYzMwYmM1ZDU4NzQ0Y2MxOTkwMDhkOTg4ZTFjNTMzJTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlm NzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MTMyNTU0OTM0OTQ2NCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1aN0dkaUJWTjdiVUtVS0Y2Mlc2SzVv JTJGR01BWkxOeWVZTlN0QmV1c2s3alklM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wlMkZpc3N1ZXMlMkY5 MiZhbXA7ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMWViZjk2YzMwY2M0 NGZjOTZlMWQwOGQ5ODc4YmI2YjUlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3 QzAlN0MwJTdDNjM3Njg5ODU3OTMxODU0ODAwJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJ am9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1u MCUzRCU3QzMwMDAmYW1wO3NkYXRhPWxGZVl3eUhDR1psc0h6JTJCTzJjVlBHN2VVVFVqem9MaHpR MGZuaXolMkZibG1jJTNEJmFtcDtyZXNlcnZlZD0wPC9hPik8YnI+DQomZ3Q7ICZndDsmbmJzcDsg WzNdIDxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUy Rmlzc3VlcyUyRjkzJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0Mw MGMzMGJjNWQ1ODc0NGNjMTk5MDA4ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1 Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTEzMjU1NDkzNDk0NjQlN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9OEElMkJXN1pWSmlreUlGZEElMkJPTlcl MkJKejlCMWo1TThXejElMkY0RUdiMkx3bVFjJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL2lzc3Vlcy85Mzwv YT4gKDxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUy Rmlzc3VlcyUyRjkzJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0Mw MGMzMGJjNWQ1ODc0NGNjMTk5MDA4ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1 Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTEzMjU1NDkzNTk0NjAlN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9NHMlMkZVZ1JWaUxQa1g2QlVjcUJIUHhC RGt1ZXRqRDdNdUxMRnk0am1CVm5VJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTMm YW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzFlYmY5NmMzMGNjNDRm Yzk2ZTFkMDhkOTg3OGJiNmI1JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0Mw JTdDMCU3QzYzNzY4OTg1NzkzMTg1NDgwMCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MzMDAwJmFtcDtzZGF0YT16cFclMkJDUXolMkJlRXdrbFlicDROUW1GY1VlSEJHbUFoMGpL QlJDMDVDeVZCcyUzRCZhbXA7cmVzZXJ2ZWQ9MDwvYT4pPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IFs0 XSA8YSBocmVmPSJodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wlMkZw dWxsJTJGMzM2JTJGZmlsZXMlMkYyMDE0NWU0OWFjY2UwMWRjZWRjYTdkYjJkMDVjNTc5MDhhMjky MjAyJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MwMGMzMGJjNWQ1 ODc0NGNjMTk5MDA4ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhl JTdDMCU3QzAlN0M2Mzc2OTEzMjU1NDkzNTk0NjAlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlK V0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2 TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9MW5KeVZjQ2RxWEl6WEdvUUFVcFhoQnV4ZlElMkZqTUN3 eEZhNmROU0IlMkI4ZEElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vZ2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJvdG9jb2wvcHVsbC8zMzYvZmlsZXMvMjAxNDVlNDlh Y2NlMDFkY2VkY2E3ZGIyZDA1YzU3OTA4YTI5MjIwMjwvYT4gKDxhIGhyZWY9Imh0dHBzOi8vbmFt MTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdp dGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUyRnB1bGwlMkYzMzYlMkZmaWxlcyUyRjIw MTQ1ZTQ5YWNjZTAxZGNlZGNhN2RiMmQwNWM1NzkwOGEyOTIyMDImYW1wO2RhdGE9MDQlN0MwMSU3 Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzAwYzMwYmM1ZDU4NzQ0Y2MxOTkwMDhkOTg4ZTFjNTMz JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MTMyNTU0 OTM2OTQ1NiU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJ am9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0 YT13dmc5QkU4UXVrc29HdVlWWnNEMjc5cXp4R3VkNzA2RmolMkJMQlJBTzFub0ElM0QmYW1wO3Jl c2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZt bHMtcHJvdG9jb2wlMkZwdWxsJTJGMzM2JTJGZmlsZXMlMkYyMDE0NWU0OWFjY2UwMWRjZWRjYTdk YjJkMDVjNTc5MDhhMjkyMjAyJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5l ZHUlN0MxZWJmOTZjMzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5 MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NjQ3OTQlN0NVbmtub3duJTdD VFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJ azFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9ME9nVmRkYyUyQkl6anU2MU13 ZlFGTmlZamVqWklOdHJJcWYwOENrSWdHbSUyQlElM0QmYW1wO3Jlc2VydmVkPTA8L2E+KTxicj4N CiZndDsgJmd0OyZuYnNwOyBbNV0gPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5v cmclMkZhcmNoJTJGbXNnJTJGbWxzJTJGSHNfbkFYM2x1RGppUTRtSXdraUt1MUNGU0FFJTJGJmFt cDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MwMGMzMGJjNWQ1ODc0NGNj MTk5MDA4ZDk4OGUxYzUzMyU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3 QzAlN0M2Mzc2OTEzMjU1NDkzNjk0NTYlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lN QzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNE JTdDMTAwMCZhbXA7c2RhdGE9ZVV3Vm1Tc3NOakFBRTl4cEpxeWd1cVNiSE03Q1RobWtKaHo5eWk3 d0ZUTSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9tbHMvSHNfbkFYM2x1RGppUTRtSXdraUt1MUNGU0FFLzwv YT4gKDxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZlLmlldGYub3JnJTJGYXJjaCUyRm1zZyUy Rm1scyUyRkhzX25BWDNsdURqaVE0bUl3a2lLdTFDRlNBRSUyRiZhbXA7ZGF0YT0wNCU3QzAxJTdD YnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMDBjMzBiYzVkNTg3NDRjYzE5OTAwOGQ5ODhlMWM1MzMl N0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkxMzI1NTQ5 Mzc5NDQ1JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRh PWtQeFoxaGlIZmN2JTJGVHRac1NIa25nYTJ6S3huYTZDZ2tiaTVtNiUyQnp2b0RZJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmcl MkZhcmNoJTJGbXNnJTJGbWxzJTJGSHNfbkFYM2x1RGppUTRtSXdraUt1MUNGU0FFJTJGJmFtcDtk YXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MxZWJmOTZjMzBjYzQ0ZmM5NmUx ZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAl N0M2Mzc2ODk4NTc5MzE4NzQ3ODklN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MzAwMCZhbXA7c2RhdGE9bW9VQVpKM3RPQWhGSSUyQk1NRnE5OUIxMTF3SnB4QlJCd2JSUFlzNWxE eEMwJTNEJmFtcDtyZXNlcnZlZD0wPC9hPik8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_62F15B7563294EFC91AD31C963214DD5npsedu_-- From nobody Thu Oct 7 10:58:07 2021 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 C9D473A0D70 for ; Thu, 7 Oct 2021 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 BaeHhf94yFj7 for ; Thu, 7 Oct 2021 10:57:49 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 52A003A0D3B for ; Thu, 7 Oct 2021 10:57:41 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id b65so6777706qkc.13 for ; Thu, 07 Oct 2021 10:57:41 -0700 (PDT) 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=Bl2rtuFojBvVirR7c0bgK7XQxUITycQ4HuVDfv5LGQQ=; b=O280STcdO307fm5Qd/LKYCKrVKy2wcFgRm8MnOQ5ERVKB7oguLb8vgIpMmvQDFsksh 6hjfCSKDuvdqv0y6adNUyj8YNr+x26L5QU4rUv0FeFm/PlAuS5T7CVoWbfpHKuxgTJKM SWuHafw1hHC7kheLxOBmJTbX3ulPJApnzhbxqhCHhhRyAZonuPtCI3RPRpFQQPdOCqDY UqTmn0QSs8wE41izVvLS90adqZVXQkv7T1IPSpDBFKw0PLck7+b2R7nfqd/j7JJCl5CY R/CYb1Nna/VNLxgYIEQ1ween8hEu5GCedeVRo0IqEnOU4SVa6ZtrYMwmQw7DhEmsp2g6 QrTA== 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=Bl2rtuFojBvVirR7c0bgK7XQxUITycQ4HuVDfv5LGQQ=; b=I204ePdE6DDNqrbGbrAbm+P7+w7h58CsccqsjEHZEdHVAyh3tUBhTn9Kl+8QLNgLdf kUNTHU1MDtLYZHenl2qSASCK6ypt8127U74cXcFn/F1rQvDhFrfpmG0GOqxf2vAFzC6Y dbQ35TCJUvVCeK6PWp7vSwoOVMpNw2LnlfqNFoRyCdpm4W3OQimFHj3+n+j3e1N1PZJT pLWs0+/Axt2i9HAW3R4xR8PlpsoxoFX61wnWZL4Aoi1pQSrChi6vFRFgaS3SJKrAx+uW dHJZsRvSxqWIaWy4WOF0wp/NOedhrMjXOJlEF6/lv4tJIuAKPIx4GwAkc8okyk7dOCH7 wYjg== X-Gm-Message-State: AOAM531Zw9t0L8q83dKp7StlFpdhGq/LaNPbcobuRdwTMTj37abTVI62 ytM+wSzhZxzRs2sfDPRx0uHabuH4LxA7H9Fw0Ukojw== X-Google-Smtp-Source: ABdhPJyJXu9Z+UBGpcTRAhkife7XZ65Ppf6uKF3d2tjVEjk+PNR/QTWOmT5ygXDNCeiiBPiC+jV4vny6L5wIav0ZNTA= X-Received: by 2002:a37:bb85:: with SMTP id l127mr3680170qkf.223.1633629459787; Thu, 07 Oct 2021 10:57:39 -0700 (PDT) MIME-Version: 1.0 References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> <1698663123.17469.1633500322380@office.mailbox.org> <62F15B75-6329-4EFC-91AD-31C963214DD5@nps.edu> In-Reply-To: <62F15B75-6329-4EFC-91AD-31C963214DD5@nps.edu> From: Richard Barnes Date: Thu, 7 Oct 2021 13:57:27 -0400 Message-ID: To: "Hale, Britta (CIV)" Cc: Konrad Kohbrok , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000a53f6105cdc6ffb1" Archived-At: Subject: [MLS] Signature key uniqueness and rotation (Re: Resync archaeology + analysis + prognosis) 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, 07 Oct 2021 17:58:02 -0000 --000000000000a53f6105cdc6ffb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Changing subject line because we're diverging a little...) Hi Britta, Could you explain a little more how you think the uniqueness requirements could make it more difficult to rotate signature keys? It doesn't seem to me like there's really any interaction between signature key rotation and either external commit or signature key uniqueness requirements. The only intersection is that the requirement that a resync operation have the same signature key means that you can't rotate the signature key at the same time that you resync. However, you could send a second commit rotating the signature key immediately after. --Richard On Thu, Oct 7, 2021 at 1:46 PM Hale, Britta (CIV) wrote: > That sounds reasonable to me as a way forward. > > > > The question posed before (=E2=80=9CThis leads to an important question: = does our > current uniqueness of sig key predicate limit the ability to rotate > signature keys within a group? That =E2=80=A6 [is what limits] the drawba= cks of > (3).=E2=80=9D) still stands. I do not think this inhibits moving forward = with the > PR, but it is important to address. If there is a trade-off between an > implementation allowing remove+resync and rotating out signature keys, th= en > that should be noted in the architecture document if not the protocol spe= c > itself. We are not going to go through all the possible options for > implementation, but when there is significant space in the protocol spec > devoted to an optional functionality (e.g. external commits and resync) > then it would be good to note trade-offs that will come with it. We would > not have a well-written specification if it could potentially lead an > implementor far down one optional path that precludes desired security > guarantees, and gives no context on that (i.e. let=E2=80=99s try to minim= ize > obvious cases of =E2=80=9CI wish I had known=E2=80=A6=E2=80=9D for implem= entors). > > > > Britta > > > > > > *From: *Richard Barnes > *Date: *Wednesday, October 6, 2021 at 8:55 AM > *To: *Konrad Kohbrok > *Cc: *"Hale, Britta (CIV)" , Messaging Layer > Security WG > *Subject: *Re: [MLS] Resync archaeology + analysis + prognosis > > > > > > I've updated the PR to do basically what Konrad proposes. Namely, allow > Remove, but suggest that applications can apply additional constraints. > > > > > https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746= a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873 > > > > > Britta, does that work for you? > > > > On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok < > konrad.kohbrok@datashrine.de> wrote: > > Hi, > > If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 > for now) represent trade-offs in security guarantees and their > applicability depends on the specific deployment scenario. My understandi= ng > is that external joins will be subject to some sort of policy anyway. > Should we then be strict in the spec in terms of what we mandate the exac= t > policy w.r.t. PSKs is? > > Since I don't think either solution represents much of a foot-gun, I > propose we include the capability to include resync PSKs in the spec for > this purpose, but don't mandate them. Instead we relegate the policy > decision to the application layer and detail the security trade-offs in t= he > architecture document. I realize that delegating decisions to the > application layer is a bit of a cop-out solution, but I think in this cas= e > it makes sense to include the mechanism in the spec and then let the > application decide. > > Cheers, > Konrad > > > Richard Barnes hat am 05.10.2021 04:31 geschrieben: > > > > > > Hi Britta, > > > > Couple of responses inline... > > > > > > On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) > wrote: > > > [trimmed] > > > > > > To the present proposed options, I will note that the =E2=80=98new jo= iners in > interim=E2=80=99 case is likely a misleading focus point for the discussi= on, and we > should avoid tripping into that ditch for a number of reasons: > > > * Notably, if everyone except for the re-syncing participant is new= , > why not just require the re-syncing participant to be added as a new memb= er > themselves? It is, after all, practically a brand new group at that point= . > > > * It is true that a new member would not gain from a PSK guarantee, > but why should we reduce the guarantees for all other participants to tha= t > of the new joiner? From the view of the new joiner, all participants are > new in any case, so e.g. PCS does not have substantial meaning as of yet. > Existing members have more to lose and also have the more to gain from PS= K > use. I do not believe we want to adapt a stance of =E2=80=98if the new jo= iner > doesn=E2=80=99t get a security guarantee, no one should have the security > guarantee=E2=80=99 =E2=80=93 in fact, the tree structure, commit history,= and the like > provide insight to longer term members that a new joiner does not have. S= o > (2) offers a new joiner the benefits of (3) but to all others an even > stronger guarantee. > > > * As a nod to what a new joiner may gain, we can offer the > following: if a re-sync PSK fails, then whichever existing member checks > and notes the PSK failure should initiate a removal of the resyncing > member. If there is a new joiner, then by continued presence of the > re-syncing member they gain the guarantee that at least one other group > member has previously seen that member, or else would have ejected them > (assuming that the checker is online). > > I don't mean to over-rotate on this case, but software being software, > we need an algorithm to implement that covers all the cases. While the > "everyone is new" scenario is outlandish, it wouldn't be all that > surprising to have one or two new members, so it's a case that would need > addressing. The seemingly most obvious approach to addressing this proble= m > is to encrypt the PSK to new members, which requires you at least have > enough state to figure out who the new members are. > > > > It also occurs to me now that the PSK approach presumes that you know > when your state went bad, since you would want to use a PSK from before > that point. In Raphael's example where persistent storage is corrupted, a= ll > you know is that messages stopped decrypting, which gives you an upper > bound on the time of corruption, but not really a way to go back and figu= re > out what's good. > > > > > > > The security goal in the balance here is PCS. Adding a re-sync option > of any of the varieties (2)-(4) would break that to some degree, since > following a compromise and passive period the adversary is then enabled t= o > regain a foothold. The question is how much of a degree of loss are we > willing to tolerate. > > > > I'm not sure I would really characterize this as a PCS violation. PCS i= s > a guarantee that you get when you take a certain action. For example, whe= n > a member issue an Update or a Commit with a fresh HPKE key pair, you shou= ld > get PCS with regard to that participant's HPKE key pair; likewise with > rotating signature keys. Here, the signature key has not been rotated, so > there's no PCS boundary. > > > > It is worth considering whether this mechanism gives the attacker any > additional capabilities in the event that (1) the signature key is > compromised, and (2) the compromised member issues an Update or Commit > rotating the signature key. ISTM that you still get PCS there in option > (3), since the requirement that the signature keys match ensures that the > old, compromised signature key is not allowed to resync back into the > group. There's still a risk that the compromised key / credential could b= e > used for a fresh, non-resync join, but that's an inherent risk with > external Commit / freely joinable groups, and also an opportunity for the > AS's revocation/invalidation system to help. > > > > Will take a look at the remainder in the morning... > > > > --RLB > > > > > > > * I agree that (4) is an immediate discard. > > > * Under (2) a PSK use, the PSK use at least more limited due to the > proof of knowledge of a past state (e.g. notes above). This is a worthwhi= le > property to enforce in my view since it balances authentication across tw= o > vectors: the signature key and knowledge of group state. Adversary access > to only one or the other is insufficient for the adversary to eject Alice > and replace her in the group. > > > * Under (3), the attack scenario of Eve compromising Alice (full > state + sig key), followed eventually* by removing Alice while adding > herself, is not dissimilar from the attack scenario of Eve compromising > Alice full state + sig key) followed eventually* by providing an > impersonating update in Alice=E2=80=99s name. What has been shown so far = is that > this type of scenario can be limited by rotating signature keys. A > important point that is different in these scenarios is that under the > first Alice knows she was removed (a plus) while under the second > (currently possible) scenario the group simply goes silent and Alice does > not know if it was malicious or not. All said, it could be worse. That do= es > not consider other attack scenarios though, for example when the attacker > gains the signature key but not past state/PSK. > > > > > > *I.e. after a potentially passive period, if we are to show how this > behaves in the PCS scenario. > > > > > > This leads to an important question: does our current uniqueness of > sig key predicate limit the ability to rotate signature keys within a > group? That is our means of limiting the full state + sig key compromise > scenario impacts mentioned above, and therefore the means of limiting the > drawbacks of (3). We should make sure that the limiting ability is > feasible. If that hindered in any way, then I would vote very strongly fo= r > (2) as it at least bootstraps some of the authentication properties from > the group state in the scenario that the sig key is compromised. > > > > > > > > > All the best, > > > > > > Britta > > > > > > > > > > > > From:MLS on behalf of Richard Barnes < > rlb@ipv.sx> > > > Date:Monday, October 4, 2021 at 4:09 PM > > > To:Messaging Layer Security WG > > > Subject:[MLS] Resync archaeology + analysis + prognosis > > > > > > OK, I think I have traced back some idea of why we removed the earlie= r > resync proposal. Here's a little essay on how we got here, a recap of the > trade-offs, and my thoughts on where we should go. > > > > > > tl;dr: Earlier decision not dispositive; we should do basically what'= s > in the PR now. > > > > > > # History > > > > > > The story starts all the way back at the January 2019 interim at > Mozilla / Mountain View. There was a discussion there of ACK/NACK and > replay as related issues [1]. That discussion seems to have led to > agreement that a complete error recovery system was a complex enough topi= c, > and clearly enough separated from the main protocol that it could be > handled in a separate specification. As a result, the issues that had bee= n > opened for ACK/NACK and resync were closed [2][3]. When Britta and Konrad > posted #336 [4] including a resync mechanism, my review simply cited that > earlier closed issue as a reason for taking it out [5]. > > > > > > One other note with regard to #336 -- It looks to me like the > "resync" mechanism in there was not really fleshed out enough to be > implementable. The state linked above was the last state before my review= , > and the word "resync" doesn't actually appear. Instead the PR talks about > "recovering lost group members" using Add and PSK, which could be > elaborated to solve a version of this problem, but would require the > assistance of a continuing member rather than allowing the lost member to > resync unilaterally. It would also have the same issues noted in terms of > new joiners not having resync PSKs. > > > > > > Overall, though, reading this history doesn't seem to me like we > really made a principled decision not to do resync. We just punted after > some discussion in the abstract, and that stuck. We have a more concrete > question now. > > > > > > # Analysis > > > > > > Since the discussion of #336 in 2020, we have added external commits > in order to have groups you can join unilaterally. So regardless of the > broader question of resync, we have to decide what proposals a joiner is > allowed to originate in their Commit (sending them by value), in > particular, whether an external Commit can contain a joiner-originated > Remove proposal. We have a spectrum of options here: > > > > > > 1. Forbid Remove > > > 2. Allow Remove + require the (identity, endpoint_id) and signature > key to match the removed node + require resumption PSK > > > 3. Allow Remove + require the (identity, endpoint_id) and signature > key to match the removed node > > > 4. Allow Remove without restriction > > > > > > Options (1) and (2) would block an attacker that has compromised a > member's signature key from joining as that member and evicting the old > appearance. Option (2) because of the PSK; option (1) because of the > uniqueness requirements (as Raphael pointed out on the call). > > > > > > Options (1) and (2) do not allow a client who has lost everything bu= t > their signature key to resync. Option (1) would require a new endpoint_id > and signature key, which might not be feasible in all cases. Option (2) > would also need to have extra mechanism to account for recent joiners not > having the required resumption PSK. > > > > > > Option (1) would also not allow for resync with just a signature key= . > As Raphael pointed out, because we now require signature keys to be uniqu= e, > the member would have to mint a new signature key and get it authenticate= d, > or else their attempt to rejoin would be rejected as a duplicate entry. > > > > > > Options (3) and (4) would allow a client who has lost everything but > their signature key to resync, at the risk that an attacker who has > compromised a member's signature key could abuse it to join as that membe= r > and evict the old, legitimate appearance. > > > > > > # Prognosis > > > > > > After this discussion and analysis, I continue to think that (3) > above is the right answer, with an optional upgade to (2). Proceeding by > elimination: > > > > > > Option (4), while technically feasible, is clearly a little silly. > There's no reason to allow joiners to do a remove in the same operation a= s > they join; they could do this afterward. > > > > > > Option (2) does not seem workable in general because of the > recent-joiner problem. While mechanism could be designed to provide the P= SK > to recent joiners, it would add a lot of complexity, and the recent joine= rs > wouldn't get any benefit from it, which dilutes the value of this > mechanism. (It's not impossible to arrive at the case where everyone > besides the resync'ing participant is new!) > > > > > > With option (1), you lose any notion of resync; I think the need for > endpoint_id rotation makes this unworkable in practice. And it has kind o= f > an odd notion of security: You are protected against an attacker that has > compromised a current signature key but can't get a new one authenticated= . > This is a problem for the authentication system to handle (e.g., with > revocation), not for the key exchange -- if you have valid credentials wi= th > compromised keys floating around, you have bigger problems to solve. So m= y > personal assessment is that (1) doesn't provide a big jump in security ov= er > (3), assuming you have a functioning authentication system. > > > > > > Two side notes about (3): First, if we do (3) but *allow* PSKs, then > an application could opt in to (2). Second, this whole mechanism is opt-i= n > for the application, since you can't do an external commit if a > PublicGroupState hasn't been published. > > > > > > Concretely, my proposal here would be (3) + (2*) -- Allow Remove wit= h > matching parameters, and allow PSKs so that applications can opt in to (2= ) > where they can make it work. That way, if an application opts in to > external Commits, they get the benefit of resync and the same > signature-key-compromise bound on impersonation for resync as well as > net-new joins. And if an application can figure out how to make (2) work, > they can require it. > > > > > > Looking forward to others' thoughts here! > > > > > > --RLB > > > > > > > > > [1] > https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.m= d#acks-and-nacks-jonm > > ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%2= 3acks-and-nacks-jonm&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44= fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898579= 31844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi= I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6t= CFvcAM3uopMFq4%3D&reserved=3D0 > > ) > > > [2] https://github.com/mlswg/mls-protocol/issues/92 > > ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40n= ps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378= e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCGZlsH= z%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=3D0 > > ) > > > [3] https://github.com/mlswg/mls-protocol/issues/93 > > ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40n= ps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378= e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi= LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz%2Be= EwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=3D0 > > ) > > > [4] > https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca= 7db2d05c57908a292202 > > ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu= b.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db= 2d05c57908a292202&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc9= 6e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C6376898579318= 64794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I= k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08C= kIgGm%2BQ%3D&reserved=3D0 > > ) > > > [5] > https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ > > ( > https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmaila= rchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=3D= 04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d9362= 31a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3= 000&sdata=3DmoUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=3D0 > > ) > > --000000000000a53f6105cdc6ffb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Changing subject line because we= 9;re diverging a little...)

Hi Britta,

Could you explain a little more how you think the uniquen= ess requirements could make it more difficult to rotate signature keys?

It doesn't seem to me like there's really any= interaction between signature key rotation and either external commit or s= ignature key uniqueness requirements.=C2=A0 The only intersection is that t= he requirement that a resync operation have the same signature key means th= at you can't rotate the signature key at the same time that you resync.= =C2=A0 However, you could send a second commit rotating the signature key i= mmediately after.

--Richard

=

On Thu, Oct 7, 2021 at 1:46 PM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:

That sounds reasonable to me as a way forward.

=C2=A0

The question posed before (=E2=80=9CThis leads to an= important question: does our current uniqueness of sig key predicate limit= the ability to rotate signature keys within a group? That =E2=80=A6 [is wh= at limits] the drawbacks of (3).=E2=80=9D) still stands. I do not think this inhibits moving forward with the PR, but it is important= to address. If there is a trade-off between an implementation allowing rem= ove+resync and rotating out signature keys, then that should be noted in th= e architecture document if not the protocol spec itself. We are not going to go through all the possible opti= ons for implementation, but when there is significant space in the protocol= spec devoted to an optional functionality (e.g. external commits and resyn= c) then it would be good to note trade-offs that will come with it. We would not have a well-written specif= ication if it could potentially lead an implementor far down one optional p= ath that precludes desired security guarantees, and gives no context on tha= t (i.e. let=E2=80=99s try to minimize obvious cases of =E2=80=9CI wish I had known=E2=80=A6=E2=80=9D for implementors).<= u>

=C2=A0

Britta

=C2=A0

=C2=A0

From: = Richard Barnes <rlb@ipv.sx>
Date: Wednesday, October 6, 2021 at 8:55 AM
To: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Cc: "Hale, Britta (CIV)" <britta.hale@nps.edu>, Messaging Layer Se= curity WG <mls@ietf.or= g>
Subject: Re: [MLS] Resync archaeology + analysis + prognosis<= u>

=C2=A0

=C2=A0

I've updated the PR to do basically what Konrad = proposes.=C2=A0 Namely, allow Remove, but suggest that applications can app= ly additional constraints.

=C2=A0

=C2=A0

Britta, does that work for you?

=C2=A0

On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok <konrad.kohb= rok@datashrine.de> wrote:

Hi,

If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 fo= r now) represent trade-offs in security guarantees and their applicability = depends on the specific deployment scenario. My understanding is that exter= nal joins will be subject to some sort of policy anyway. Should we then be strict in the spec in terms of wh= at we mandate the exact policy w.r.t. PSKs is?

Since I don't think either solution represents much of a foot-gun, I pr= opose we include the capability to include resync PSKs in the spec for this= purpose, but don't mandate them. Instead we relegate the policy decisi= on to the application layer and detail the security trade-offs in the architecture document. I realize that delegatin= g decisions to the application layer is a bit of a cop-out solution, but I = think in this case it makes sense to include the mechanism in the spec and = then let the application decide.

Cheers,
Konrad

> Richard Barnes <rlb= @ipv.sx> hat am 05.10.2021 04:31 geschrieben:
>
>
> Hi Britta,
>
> Couple of responses inline...
>
>
> On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:=
> > [trimmed]
> > =C2=A0
> > To the present proposed options, I will note that the =E2=80=98ne= w joiners in interim=E2=80=99 case is likely a misleading focus point for t= he discussion, and we should avoid tripping into that ditch for a number of= reasons:
> >=C2=A0 =C2=A0* Notably, if everyone except for the re-syncing part= icipant is new, why not just require the re-syncing participant to be added= as a new member themselves? It is, after all, practically a brand new grou= p at that point.
> >=C2=A0 =C2=A0* It is true that a new member would not gain from a = PSK guarantee, but why should we reduce the guarantees for all other partic= ipants to that of the new joiner? From the view of the new joiner, all part= icipants are new in any case, so e.g. PCS does not have substantial meaning as of yet. Existing members have more to lose and= also have the more to gain from PSK use. I do not believe we want to adapt= a stance of =E2=80=98if the new joiner doesn=E2=80=99t get a security guar= antee, no one should have the security guarantee=E2=80=99 =E2=80=93 in fact, the tree structure, commit history, and the like provid= e insight to longer term members that a new joiner does not have. So (2) of= fers a new joiner the benefits of (3) but to all others an even stronger gu= arantee.
> >=C2=A0 =C2=A0* As a nod to what a new joiner may gain, we can offe= r the following: if a re-sync PSK fails, then whichever existing member che= cks and notes the PSK failure should initiate a removal of the resyncing me= mber. If there is a new joiner, then by continued presence of the re-syncing member they gain the guarantee that at least on= e other group member has previously seen that member, or else would have ej= ected them (assuming that the checker is online).
> I don't mean to over-rotate on this case, but software being softw= are, we need an algorithm to implement that covers all the cases. While the= "everyone is new" scenario is outlandish, it wouldn't be all= that surprising to have one or two new members, so it's a case that would need addressing. The seemingly most obvious approach to = addressing this problem is to encrypt the PSK to new members, which require= s you at least have enough state to figure out who the new members are.
>
> It also occurs to me now that the PSK approach presumes that you know = when your state went bad, since you would want to use a PSK from before tha= t point. In Raphael's example where persistent storage is corrupted, al= l you know is that messages stopped decrypting, which gives you an upper bound on the time of corruption, but not really a= way to go back and figure out what's good.
>
>
> > The security goal in the balance here is PCS. Adding a re-sync op= tion of any of the varieties (2)-(4) would break that to some degree, since= following a compromise and passive period the adversary is then enabled to= regain a foothold. The question is how much of a degree of loss are we willing to tolerate.
>
> I'm not sure I would really characterize this as a PCS violation. = PCS is a guarantee that you get when you take a certain action. For example= , when a member issue an Update or a Commit with a fresh HPKE key pair, you= should get PCS with regard to that participant's HPKE key pair; likewise with rotating signature keys. Here, the signature = key has not been rotated, so there's no PCS boundary.
>
> It is worth considering whether this mechanism gives the attacker any = additional capabilities in the event that (1) the signature key is compromi= sed, and (2) the compromised member issues an Update or Commit rotating the= signature key. ISTM that you still get PCS there in option (3), since the requirement that the signature keys= match ensures that the old, compromised signature key is not allowed to re= sync back into the group. There's still a risk that the compromised key= / credential could be used for a fresh, non-resync join, but that's an inherent risk with external Commit / fr= eely joinable groups, and also an opportunity for the AS's revocation/i= nvalidation system to help.
>
> Will take a look at the remainder in the morning...
>
> --RLB
>
>
> >=C2=A0 =C2=A0* I agree that (4) is an immediate discard.
> >=C2=A0 =C2=A0* Under (2) a PSK use, the PSK use at least more limi= ted due to the proof of knowledge of a past state (e.g. notes above). This = is a worthwhile property to enforce in my view since it balances authentica= tion across two vectors: the signature key and knowledge of group state. Adversary access to only one or the other is insufficient = for the adversary to eject Alice and replace her in the group.
> >=C2=A0 =C2=A0* Under (3), the attack scenario of Eve compromising = Alice (full state + sig key), followed eventually* by removing Alice while = adding herself, is not dissimilar from the attack scenario of Eve compromis= ing Alice full state + sig key) followed eventually* by providing an impersonating update in Alice=E2=80=99s name. What has bee= n shown so far is that this type of scenario can be limited by rotating sig= nature keys. A important point that is different in these scenarios is that= under the first Alice knows she was removed (a plus) while under the second (currently possible) scenario the group si= mply goes silent and Alice does not know if it was malicious or not. All sa= id, it could be worse. That does not consider other attack scenarios though= , for example when the attacker gains the signature key but not past state/PSK.
> > =C2=A0
> > *I.e. after a potentially passive period, if we are to show how t= his behaves in the PCS scenario.
> > =C2=A0
> > This leads to an important question: does our current uniqueness = of sig key predicate limit the ability to rotate signature keys within a gr= oup? That is our means of limiting the full state + sig key compromise scen= ario impacts mentioned above, and therefore the means of limiting the drawbacks of (3). We should make sure that the l= imiting ability is feasible. If that hindered in any way, then I would vote= very strongly for (2) as it at least bootstraps some of the authentication= properties from the group state in the scenario that the sig key is compromised.
> > =C2=A0
> > =C2=A0
> > All the best,
> > =C2=A0
> > Britta
> > =C2=A0
> > =C2=A0
> > =C2=A0
> > From:MLS <mls-bounces@ietf.org> on behalf of Richard Barnes <rlb@ipv.sx>
> >=C2=A0 Date:Monday, October 4, 2021 at 4:09 PM
> >=C2=A0 To:Messaging Layer Security WG <mls@ietf.org>
> >=C2=A0 Subject:[MLS] Resync archaeology + analysis + prognosis
> > =C2=A0
> > OK, I think I have traced back some idea of why we removed the ea= rlier resync proposal. Here's a little essay on how we got here, a reca= p of the trade-offs, and my thoughts on where we should go.
> > =C2=A0
> > tl;dr: Earlier decision not dispositive; we should do basically w= hat's in the PR now.
> >
> >=C2=A0 # History
> >=C2=A0
> >=C2=A0 The story starts all the way back at the January 2019 inter= im at Mozilla / Mountain View. There was a discussion there of ACK/NACK and= replay as related issues [1]. That discussion seems to have led to agreeme= nt that a complete error recovery system was a complex enough topic, and clearly enough separated from the main protoco= l that it could be handled in a separate specification. As a result, the is= sues that had been opened for ACK/NACK and resync were closed [2][3]. When = Britta and Konrad posted #336 [4] including a resync mechanism, my review simply cited that earlier closed i= ssue as a reason for taking it out [5].
> >=C2=A0
> >=C2=A0 One other note with regard to #336 -- It looks to me like t= he "resync" mechanism in there was not really fleshed out enough = to be implementable. The state linked above was the last state before my re= view, and the word "resync" doesn't actually appear. Instead the PR talks about "recovering lost group members" using= Add and PSK, which could be elaborated to solve a version of this problem,= but would require the assistance of a continuing member rather than allowi= ng the lost member to resync unilaterally. It would also have the same issues noted in terms of new joiners not havin= g resync PSKs.
> >=C2=A0
> >=C2=A0 Overall, though, reading this history doesn't seem to m= e like we really made a principled decision not to do resync. We just punte= d after some discussion in the abstract, and that stuck. We have a more con= crete question now.
> >=C2=A0
> >=C2=A0 # Analysis
> >=C2=A0
> >=C2=A0 Since the discussion of #336 in 2020, we have added externa= l commits in order to have groups you can join unilaterally. So regardless = of the broader question of resync, we have to decide what proposals a joine= r is allowed to originate in their Commit (sending them by value), in particular, whether an external Commit can contain a jo= iner-originated Remove proposal. We have a spectrum of options here:
> >=C2=A0
> >=C2=A0 1. Forbid Remove
> >=C2=A0 2. Allow Remove + require the (identity, endpoint_id) and s= ignature key to match the removed node + require resumption PSK
> >=C2=A0 3. Allow Remove + require the (identity, endpoint_id) and s= ignature key to match the removed node
> >=C2=A0 4. Allow Remove without restriction
> >=C2=A0
> >=C2=A0 Options (1) and (2) would block an attacker that has compro= mised a member's signature key from joining as that member and evicting= the old appearance. Option (2) because of the PSK; option (1) because of t= he uniqueness requirements (as Raphael pointed out on the call).
> >=C2=A0
> >=C2=A0 Options (1) and (2) do not allow a client who has lost ever= ything but their signature key to resync. Option (1) would require a new en= dpoint_id and signature key, which might not be feasible in all cases. Opti= on (2) would also need to have extra mechanism to account for recent joiners not having the required resumption PSK.
> >=C2=A0
> >=C2=A0 Option (1) would also not allow for resync with just a sign= ature key. As Raphael pointed out, because we now require signature keys to= be unique, the member would have to mint a new signature key and get it au= thenticated, or else their attempt to rejoin would be rejected as a duplicate entry.
> >=C2=A0
> >=C2=A0 Options (3) and (4) would allow a client who has lost every= thing but their signature key to resync, at the risk that an attacker who h= as compromised a member's signature key could abuse it to join as that = member and evict the old, legitimate appearance.
> >=C2=A0
> >=C2=A0 # Prognosis
> >=C2=A0
> >=C2=A0 After this discussion and analysis, I continue to think tha= t (3) above is the right answer, with an optional upgade to (2). Proceeding= by elimination:
> >=C2=A0
> >=C2=A0 Option (4), while technically feasible, is clearly a little= silly. There's no reason to allow joiners to do a remove in the same o= peration as they join; they could do this afterward.
> >=C2=A0
> >=C2=A0 Option (2) does not seem workable in general because of the= recent-joiner problem. While mechanism could be designed to provide the PS= K to recent joiners, it would add a lot of complexity, and the recent joine= rs wouldn't get any benefit from it, which dilutes the value of this mechanism. (It's not impossible to arrive at= the case where everyone besides the resync'ing participant is new!)
> >=C2=A0
> >=C2=A0 With option (1), you lose any notion of resync; I think the= need for endpoint_id rotation makes this unworkable in practice. And it ha= s kind of an odd notion of security: You are protected against an attacker = that has compromised a current signature key but can't get a new one authenticated. This is a problem for the authe= ntication system to handle (e.g., with revocation), not for the key exchang= e -- if you have valid credentials with compromised keys floating around, y= ou have bigger problems to solve. So my personal assessment is that (1) doesn't provide a big jump in secur= ity over (3), assuming you have a functioning authentication system.
> >=C2=A0
> >=C2=A0 Two side notes about (3): First, if we do (3) but *allow* P= SKs, then an application could opt in to (2). Second, this whole mechanism = is opt-in for the application, since you can't do an external commit if= a PublicGroupState hasn't been published.
> >=C2=A0
> >=C2=A0 Concretely, my proposal here would be (3) + (2*) -- Allow R= emove with matching parameters, and allow PSKs so that applications can opt= in to (2) where they can make it work. That way, if an application opts in= to external Commits, they get the benefit of resync and the same signature-key-compromise bound on impersonation for= resync as well as net-new joins. And if an application can figure out how = to make (2) work, they can require it.
> >=C2=A0
> >=C2=A0 Looking forward to others' thoughts here!
> >=C2=A0
> >=C2=A0 --RLB
> >=C2=A0
> >=C2=A0
> >=C2=A0 [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#= acks-and-nacks-jonm (https://nam10.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01= %2Fminutes.md%23acks-and-nacks-jonm&data=3D04%7C01%7Cbritta.hale%40nps.= edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7= C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D%2BEprQMOVk%= 2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=3D0)
> >=C2=A0 [2] https://github.com/mlswg/mls-protocol/issues/92 (https://= nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fml= swg%2Fmls-protocol%2Fissues%2F92&data=3D04%7C01%7Cbritta.hale%40nps.edu= %7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%= 7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DlFeYwyHCGZlsHz%= 2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=3D0)
> >=C2=A0 [3] https://github.com/mlswg/mls-protocol/issues/93 (https://= nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fml= swg%2Fmls-protocol%2Fissues%2F93&data=3D04%7C01%7Cbritta.hale%40nps.edu= %7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%= 7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DzpW%2BCQz%2BeEw= klYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=3D0)
> >=C2=A0 [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7d= b2d05c57908a292202 (https://nam10.safelinks.protection.outlook.com/?url=3Dhttps%3A= %2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce= 01dcedca7db2d05c57908a292202&data=3D04%7C01%7Cbritta.hale%40nps.edu%7C1= ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%= 7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3D0OgVddc%2BIzju61Mwf= QFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=3D0)
> >=C2=A0 [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ = (https://nam10.safelinks.protectio= n.outlook.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%= 2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=3D04%7C01%7Cbritta.hale%40nps.edu= %7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%= 7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DmoUAZJ3tOAhFI%2= BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=3D0)

--000000000000a53f6105cdc6ffb1-- From nobody Thu Oct 7 11:02:54 2021 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 7001D3A0CF5 for ; Thu, 7 Oct 2021 11:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 IK-aFHvOyZAl for ; Thu, 7 Oct 2021 11:02:47 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 875D73A0CF6 for ; Thu, 7 Oct 2021 11:02:47 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id j10so4688495qvl.13 for ; Thu, 07 Oct 2021 11:02:47 -0700 (PDT) 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=IT8lz+12iPM29IgvJz4xvjsS4KwXNclx24HpMLxc+Ls=; b=08XE/S8ZnN/s2gMOitDoH0IrJMgs5bba3XGXSEwCJamiNj9OtellHyegMWlWb12Uxv vNxfQg8IBiVa4cPYLlv74uMMOybLo13XIBSpGG+IDXKqZne1ehNywiJ+vDqGo+Qq0GIG aM/pJGEgOsbHAWcX7TK6Xdl2rA2+ZbC6dw56nJZuwGyT6NN9Q1+4+hJtBHpJx3ZBqZC6 vYyFVA/b73wXLPVCHJV8eKk6rOX02u6eyalWTfUJSsUL3YZZi3A8lPdF2fJvxOFMLzDU 1fj9pq8hX3s9Fcnbh4rxKk2h0zBuoLHBL1iCgoOsQU2DFs1MiBjFGdRdhP8uPSdz2Ndu d02Q== 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=IT8lz+12iPM29IgvJz4xvjsS4KwXNclx24HpMLxc+Ls=; b=0kwQdj/SkWCVswkozhDnXSVAbUgbkIwsMt46q+1dsjpaUAu4uyR50JkSuEoeiIVHel ALmNrpxuqEEh8T+03WpJF5ewbl9QjGfPWxgi1vRSy1VA4L2HSxRF/KHMksQNXEimQ9oT bGvQNlT72Bpb93IxW0JEN1nm3C9lToZFigo4UuY5KkOmPOSiDNGavdewosD8hPUdQt7U 0XUMWVRZth+6SeZ36i6hopNjRLAlCkSlLln3hB2+ZZ06DR2lD1Gku68DM6KulUjBZw1g j7CLduLxjsxzEFvszL3yw278KZcY1cTMPaiiPRQ5gJLcbehimmLefgHpX+r+25ECj1Nu KC1g== X-Gm-Message-State: AOAM533LNSb48B3YTZ6uQjcz40b3IL6055k1c75euAwixZQlbfZc8Z8u 3rmWEYB2c5IvAAbX+d/sudLKo+jtd/x8Hqr9djc/uDasHx2Jsng/ X-Google-Smtp-Source: ABdhPJycL8uyN2b8yI8Q314SXs9Om9t42O6jBNpPxi7cuCNrWVKamg6lhzb3LV23RrC+ME3Q816YFEa+HY7NEQfnXfY= X-Received: by 2002:a05:6214:1022:: with SMTP id k2mr5651629qvr.14.1633629766020; Thu, 07 Oct 2021 11:02:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 7 Oct 2021 14:02:33 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000e6011405cdc711a6" Archived-At: Subject: Re: [MLS] Post-interim PRs 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, 07 Oct 2021 18:02:53 -0000 --000000000000e6011405cdc711a6 Content-Type: text/plain; charset="UTF-8" Hey all, One last request for comments before merging! Since these all already got discussion at the interim (and there's pretty clear resolution on #481 on the mailing list), I will plan to merge over the weekend if there's no further commentary. Note that a couple of new PRs have come up this week: #491 - Use key package hash to index clients in message structs https://github.com/mlswg/mls-protocol/pull/491 #494 - Require PublicGroupStateTBS for external init https://github.com/mlswg/mls-protocol/pull/494 We discussed #491 some on the interim, in the context of #487. #494 is resolving an implementation issue, and could use some eyes on it, since we are proposing to **not** **inject** some information that is currently injected into the key schedule. Thanks, --Richard On Mon, Oct 4, 2021 at 10:12 PM Richard Barnes wrote: > Hi all, > > Thanks for the good discussion on the interim call today. I have posted a > salvo of PRs capturing where I think we ended up. Given that these have > already had some discussion, if we could get some quick reviews, I think we > can go ahead and merge. Then once we resolve the rsync discussion one way > or another, we can cut a new draft and kick off WGLC. > > #487 - Remove the notion of a 'leaf index' > https://github.com/mlswg/mls-protocol/pull/487 > > #489 - Add RequiredCapabilities extension (implementing Rohan's suggestion) > https://github.com/mlswg/mls-protocol/pull/489 > > #490 - Use cascaded KDF instead of concatenation to consolidate PSKs > https://github.com/mlswg/mls-protocol/pull/490 > > Thanks a lot, > --Richard > --000000000000e6011405cdc711a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

One last request fo= r comments before merging!=C2=A0 Since these all already got discussion at = the interim (and there's pretty clear resolution on #481 on the mailing= list), I will plan to merge over the weekend if there's no further com= mentary.

Note that a couple of new PRs have co= me up this week:

#491 - Use key package hash to in= dex clients in message structs

#494 - Require PublicGroupStateTBS for external i= nit

W= e discussed #491 some on the interim, in the context of #487.=C2=A0 #494 is= resolving an implementation issue, and could use some eyes on it, since we= are proposing to **not** **inject** some information that is currently inj= ected into the key schedule.

Thanks,
--R= ichard

On Mon, Oct 4, 2021 at 10:12 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi all,
Thanks for the good discussion on the interim call today.=C2= =A0 I have posted a salvo of PRs capturing where I think we ended up.=C2=A0= Given that these have already had some discussion, if we could get some qu= ick reviews, I think we can go ahead and merge.=C2=A0 Then once we resolve = the rsync discussion one way or another, we can cut a new draft and kick of= f WGLC.

#487 - Remove the notion of a 'leaf in= dex'
https://github.com/mlswg/mls-protocol/pull/487

#489 - Add RequiredCapabilities extension (implementi= ng Rohan's suggestion)

#490 - Use cascaded KDF instead= of concatenation to consolidate PSKs

Thanks a lot,
= --Richard
--000000000000e6011405cdc711a6-- From nobody Sun Oct 10 00:56:08 2021 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 A641D3A080B for ; Sun, 10 Oct 2021 00:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_H2=-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=LHadwP/b; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i93SiakS 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 B_XjzqjcxJYk for ; Sun, 10 Oct 2021 00:55:55 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991FF3A0816 for ; Sun, 10 Oct 2021 00:55:55 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D76BD5C00F7 for ; Sun, 10 Oct 2021 03:38:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 10 Oct 2021 03:38:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=0bleag3rnkE nryzOwn31cT0sgeDNZXWmND7wpcE9SXY=; b=LHadwP/b4HqFiFBfn4jS4YvXqc1 o1EFl6sPqw/D1kd2nJVgm2T593A0NijrGY6M9txoNn6f32qeMS6KsxmjFrxPV0ry +Fz1qYle9W9SEWXepkNzXZAV8tsBifcagUWSFhvgeZvH5+caWWznWwo3Z6tBDYQv i59cuHU3Y+BFHLGiFmMEWLvjgjS3pDi9iycXt4ANLFVZA5jwQcRXNTBfOgy3NwCy Xswwr2TNo4yBvvLWheltAEytaruZS8rcrFMGt5rWuvN4kaINpDo0+H3Ao+rd7hch S/eDxJn3MLazQ9pqb32nTQmVBdTtD7VkDQi6ZnI/tQgK5cbF29TzuKlnCMQ== 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=0bleag3rnkEnryzOwn31cT0sgeDNZXWmND7wpcE9SXY=; b=i93SiakS G9EsdwqCPM7mS4vU6c9Vp+OPGU4PbdmGFWuqCJZZVxhh5RNdi1UQI5uhOImmUCWh tfB1+Cx2p3f0EHVguyYq26HasUMiSTQsgehwgbm1ZHaEQwjb0gfZUR/iUDncoqwt nbooNeZGio7YNYGwa433jwXvPLaAJuajcenj+u3jmKNPtryjtO+PgGVLIoa95K5h s799nkUeIP3vhlhwkrvEEO7zNqWYktdCXCoE1d84MB/NhtlS9p8zGwJ/irNiJvcF eU6Cu4Aoa9gqtqEEUgujx/37nU//SnD9UHzV8dmn0yBzn/rMv1T3RW9KRsAWhopt pwoisFlyF1NcMg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtfedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 10 Oct 2021 03:38:46 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0923299551080930430==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20211010075555.991FF3A0816@ietfa.amsl.com> Date: Sun, 10 Oct 2021 00:55:55 -0700 (PDT) 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, 10 Oct 2021 07:56:03 -0000 --===============0923299551080930430== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #71 Definition of a group member can be strengthened (1 by kkohbrok) https://github.com/mlswg/mls-architecture/issues/71 [editorial]=20 * mlswg/mls-protocol (+3/-3/=F0=9F=92=AC4) 3 issues created: - Key schedule text - figure mismatch (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/493=20 - Use `(identity, endpoint_id)` tuple instead of leaf indices in Message = structs (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/486=20 - Mandatory extension types? (by rohan-wire) https://github.com/mlswg/mls-protocol/issues/485=20 1 issues received 4 new comments: - #485 Mandatory extension types? (4 by bifurcation, rohan-wire, seanturn= er) https://github.com/mlswg/mls-protocol/issues/485=20 3 issues closed: - Mandatory extension types? https://github.com/mlswg/mls-protocol/issues= /485=20 - Extensions https://github.com/mlswg/mls-protocol/issues/473=20 - group_context is passed into HPKE's aad instead of info https://github.= com/mlswg/mls-protocol/issues/470=20 Pull requests ------------- * mlswg/mls-architecture (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Architecture Document Review=20 https://github.com/mlswg/mls-architecture/pull/82=20 * mlswg/mls-protocol (+8/-10/=F0=9F=92=AC19) 8 pull requests submitted: - Affiliation change (by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/495=20 - Require PublicGroupStateTBS for external init (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/494=20 - Add a 'reserved' field to WireFormat (by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/492=20 - Use identity and endpoint_id to index clients in message structs (by kk= ohbrok) https://github.com/mlswg/mls-protocol/pull/491=20 - Use cascaded KDF instead of concatenation to consolidate PSKs (by bifur= cation) https://github.com/mlswg/mls-protocol/pull/490=20 - Add RequiredCapabilities extension (by bifurcation) https://github.com/mlswg/mls-protocol/pull/489=20 - Add group_context_extensions proposal ID (by bifurcation) https://github.com/mlswg/mls-protocol/pull/488=20 - Remove the notion of a 'leaf index' (by bifurcation) https://github.com/mlswg/mls-protocol/pull/487=20 14 pull requests received 19 new comments: - #494 Require PublicGroupStateTBS for external init (2 by bifurcation, r= aphaelrobert) https://github.com/mlswg/mls-protocol/pull/494=20 - #491 Use identity and endpoint_id to index clients in message structs (= 1 by kkohbrok) https://github.com/mlswg/mls-protocol/pull/491=20 - #487 Remove the notion of a 'leaf index' (3 by bifurcation, rohan-wire) https://github.com/mlswg/mls-protocol/pull/487=20 - #484 Clarify node vs. leaf indices (2 by bifurcation, seanturner) https://github.com/mlswg/mls-protocol/pull/484=20 - #483 Remove OPEN ISSUEs and TODOs (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/483=20 - #481 Constrain proposal in External Commit (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/481=20 - #480 Improve extensibility of Proposals (2 by br-hale, seanturner) https://github.com/mlswg/mls-protocol/pull/480=20 - #479 Clarify extension handling and make extension updatable (1 by sean= turner) https://github.com/mlswg/mls-protocol/pull/479=20 - #478 Inject GroupContext as HPKE info instead of AAD (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/478=20 - #477 Signal the intended wire format for MLS messages (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/477=20 - #476 Revisit the notion of identity in MLS groups (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/476=20 - #463 Remove AppAck proposal. (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/463=20 - #462 Make ratchet tree section clearer. (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/462=20 - #454 more editorial changes (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/454=20 10 pull requests merged: - Affiliation change https://github.com/mlswg/mls-protocol/pull/495=20 - Add a 'reserved' field to WireFormat https://github.com/mlswg/mls-protocol/pull/492=20 - Add group_context_extensions proposal ID https://github.com/mlswg/mls-protocol/pull/488=20 - Clarify extension handling and make extension updatable https://github.com/mlswg/mls-protocol/pull/479=20 - Remove OPEN ISSUEs and TODOs https://github.com/mlswg/mls-protocol/pull/483=20 - Inject GroupContext as HPKE info instead of AAD https://github.com/mlswg/mls-protocol/pull/478=20 - Signal the intended wire format for MLS messages https://github.com/mlswg/mls-protocol/pull/477=20 - Revisit the notion of identity in MLS groups https://github.com/mlswg/mls-protocol/pull/476=20 - Make ratchet tree section clearer. https://github.com/mlswg/mls-protocol/pull/462=20 - more editorial changes https://github.com/mlswg/mls-protocol/pull/454=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============0923299551080930430== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 10, 2021

Issues

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

1 issues received 1 new comments:

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

3 issues created:

1 issues received 4 new comments:

3 issues closed:

Pull requests

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

1 pull requests merged:

mlswg/mls-protocol (+8/-10/=F0=9F=92=AC19)

8 pull requests submitted:

14 pull requests received 19 new comments:

10 pull requests merged:

Repositories tracked by this digest:

--===============0923299551080930430==-- From nobody Mon Oct 11 13:10:15 2021 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 DFE423A06E7; Mon, 11 Oct 2021 13:10:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <163398300580.17762.17251034263731367543@ietfa.amsl.com> Date: Mon, 11 Oct 2021 13:10:05 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-12.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2021 20:10:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Benjamin Beurdouche Raphael Robert Jon Millican Emad Omara Katriel Cohn-Gordon Filename : draft-ietf-mls-protocol-12.txt Pages : 97 Date : 2021-10-11 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-mls-protocol-12.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 12 06:34:06 2021 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 405173A0A3F for ; Tue, 12 Oct 2021 06:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 SjLPvmXWlamj for ; Tue, 12 Oct 2021 06:33:58 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 5B3533A1239 for ; Tue, 12 Oct 2021 06:33:58 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id ns7-20020a17090b250700b001a0937b87b7so1857306pjb.1 for ; Tue, 12 Oct 2021 06:33:58 -0700 (PDT) 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=5bCAuYvZlPunPzvx5BDyhaZ0Yqmz8Q9B4MvyTWMgwE8=; b=JI1VCF6K97NI58lqfML9QGPGYXoQgi+FKcRt+i/tOgeg9Y/IzEL71bXI/XIoybDrUL SXYG6fytAr4A218vFS9tW/vzKJMmLOzMnresMuKEDDewKQkqvBslbH9VQYJQEV3Qp67G /mQa0r7rw4q85l7SQRZotV1ve3AlhTukfEQqMn1UBT0KH1Du16D9rWq0Zh/ZSe894b8W f3BwhDhn+pCeFl9Q7L7SzJcVtfApitBeAK5cWOMo/yRXU0WgXVTfQUigw+h6GDLaHlXF Pd6FY3xLNTObirir8xTh0xqw1VmcpGq9vH0AqrdlDR0HnT3I0Nmc/dZI3DBZ7faUrHcO wlwA== 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=5bCAuYvZlPunPzvx5BDyhaZ0Yqmz8Q9B4MvyTWMgwE8=; b=0zdv7tpZqepCS7vfaPfx43+UK/wi/pjdbJNRQxqHOdBqyPyrROGxSuSLmfhaFJZv56 4M6wl9cSAUbJMWDoEuASupcdBpOOsHe77LgLbuDV2NNLD9M9dbkS71ZhQVPl9psTsNBX pPJlitTzkVfF4d+ltrrwlgHWhnLI7dOShUChhlBbE4Ls3ESbTjZwvx01piLQFEnUD1RH cA97hYhmuKpeBvSSwKiuYG5uhW0uqVE9BDZs0CgZJPzckW4QOyX9gwVA1NuGrOfj3hRq 4GsvKVTKT/tsVX57wB45fzPnclL1jUMyT8mfB62x4AZXCrVJ+eDSSI4GrdKDmQaexOWf ay3g== X-Gm-Message-State: AOAM530bJMJJ7qtKxSqNG8XuhKOJoUyCTodd0ERPEseDtCrVrAD4ejgC R/QBP2mq2T2ro/DQ+KKhbMPZXqBKEwdBHcxxBJLy5lc0K0B03Q== X-Google-Smtp-Source: ABdhPJyCHbOn7+UE8mAR2t7n1Rcf0SkbULR5hKmOhcFvza1MQ1FLm3Dyh0naW5R8L6sR7cq6uOAniGDK26Mv88EG1KA= X-Received: by 2002:a17:902:c942:b0:13f:d1c:819a with SMTP id i2-20020a170902c94200b0013f0d1c819amr26997589pla.64.1634045637254; Tue, 12 Oct 2021 06:33:57 -0700 (PDT) MIME-Version: 1.0 From: Rohan Mahy Date: Tue, 12 Oct 2021 06:33:46 -0700 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000c1751e05ce27e583" Archived-At: Subject: [MLS] Please resubmit draft-ietf-mls-federation 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, 12 Oct 2021 13:34:03 -0000 --000000000000c1751e05ce27e583 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think it is great that we can use github for pull requests on the MLS documents, but that shouldn't mean we let our drafts expire, or don't discuss things on the mailing list. Raphael or Emad, could one of you please, please, please resubmit draft-ietf-mls-federation? It has been expired for more than a month now. 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 --000000000000c1751e05ce27e583 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I think it is great that we can use git= hub for pull requests on the MLS documents, but that shouldn't mean we = let our drafts expire, or don't discuss things on the mailing list.

Raphael or Emad, could one of you please, please, ple= ase resubmit draft-ietf-mls-federation? It has been expired for more than a= month now.
Thanks,
-rohan

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

Chat: @rohan_wire o= n=C2=A0Wire

=C2=A0
<= /p>

Wire<= /a>=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

HRB 14984= 7 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675=

--000000000000c1751e05ce27e583-- From nobody Tue Oct 12 08:46:17 2021 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 7E4FA3A1187 for ; Tue, 12 Oct 2021 08:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f9y4ldl-e80 for ; Tue, 12 Oct 2021 08:46:09 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2078.outbound.protection.outlook.com [40.107.244.78]) (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 7FB243A08FC for ; Tue, 12 Oct 2021 08:46:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kKT9kv35HTexbceX5uHT+4BHiM0IOhY9P92innuIBzx968JQ7gnWdqnDS8zTYpEM7owgUWbNzbci+Mb+rRRDkES9rjZfXXZSrfmKViXMIhD2e1zwYQMeMOU/QtS2cdaC9pQNQB6tkQ7ayMZMAd3arMwvCzAWNXv8X8kH4wNuwwCny/S+K5UN+FrcQTdOvgNQ8tCaTIMqX7yXUSqd/ADSCjcqsHWQebhI0O/9qOBbLF45wpoDaZ9SI43OWJGpfriFsm3ujtdzJK71zCPikbCr9BIwCelPV8NJZ9nWo69zV3oXZqll7MDjLLn7y/QO3C2aYoN2k/+N/vrYa1EQAlR9fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QE/RnRyc5sOEuBln0NC5HJZJ9h30OwEnPsYWMveHsBE=; b=PtI7EJj5LyqfefrfjppsUzI7wjYiquXYAmU6Fgb9Gqw5q4JR68w6exRhV71BZPjsQXF+7G80Gr1uVswbZAmZTNU3ah5a3Cx1UdJvy4t6QOpUpHFGCsod9oA06Get2FbuhKfkThuxMgeuf0CWJcE5TufSC+menKxVRvwcKHG6gtPyfGwTOcWlqX+B7XgcivgjgJIf1C0cK6WAP40rzZaiwTh/Qhvq+4OBfH8S+uA/xaOynCsJuxYMrAHTZBWais6oHxo2WGjUiUix2BEigMqpXXoDpJJNf0ZW4e9G10liqe5SBr04G4UJiOLk+txTlf7AMiWBVhghqOA6jM+Rx8xQAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3348.namprd13.prod.outlook.com (2603:10b6:a03:1aa::23) by BYAPR13MB4358.namprd13.prod.outlook.com (2603:10b6:a03:108::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.13; Tue, 12 Oct 2021 15:46:03 +0000 Received: from BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::d8e0:3c03:4413:3677]) by BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::d8e0:3c03:4413:3677%3]) with mapi id 15.20.4608.014; Tue, 12 Oct 2021 15:46:02 +0000 From: "Hale, Britta (CIV)" To: Richard Barnes CC: Konrad Kohbrok , Messaging Layer Security WG Thread-Topic: Signature key uniqueness and rotation (Re: [MLS] Resync archaeology + analysis + prognosis) Thread-Index: AQHXu6TUUa4OeAvYjEKvT+r/TRq8j6vPE+IA Date: Tue, 12 Oct 2021 15:46:02 +0000 Message-ID: <484167A8-8363-42E9-816B-E968784B1595@nps.edu> References: <25D37E5C-F7C0-48C7-849E-28C8A54762D0@nps.edu> <1698663123.17469.1633500322380@office.mailbox.org> <62F15B75-6329-4EFC-91AD-31C963214DD5@nps.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.52.21080801 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=nps.edu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 00d37472-2aac-4dc9-06ac-08d98d97655d x-ms-traffictypediagnostic: BYAPR13MB4358: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NnGBBBAj6O0RKbujLOPlkVtBf0KNvQgyLBHMplJCi62sl8EbVA2YAe8yElHPtVFEqFw5fM0qJoikZjFPTT/PVv+9Ddz0tlm/3QYQM8DNFGUvXnfhUCtGzOXIIa0kGa8aodq9kXAg3FuCeNiF1vNdwsMtFHxVwA7AvMa+Rfnw2F7Hff+oIte/DQrywuKBz6RBJXkjTZOC4SsOiHie1gbUi4Rt4a5nl3o75Z416ETm81xizFUAF2hazaLiWimCM28nF7jkPRziDoSaZ9fLHxbtPp1aiOYTKjwM7/MxlOs76qYckWVxn0dau2ssrDmfIFJ5U4uG+f3EF0XTEoD9crmySduSaTSd9ro+vTbuaOTsULp7f/Xt0gODtDPNb23uHH4+07bxFe4AS1eHhCfl8FLZ2A6EIYgaJIAV7U/lqnC8tK8vgil3d20ULWtdmO/iHyTYJVQ3QaakplSIPDmw3VCLvO/s5cg2p6HOjtGBrXHfKwPuHg9Em+jhlI5xoCejWR91o5elOqbGQDJhzuGQ/JlksE/xVpr/kupKDSXhUHHd4CRhOi5+oZ9KdW6uOtuXldcCnrfWl6LtJuYlYnFesfZzkGEf3B++X7gwGOnYBCvoKKhwYSjGmkb1EsybHTCenOG2ODUy8B0uLev3QiIBrFQ5rdogGPoF06HGrgfHMNds4M/VGEwteUkb09w8pOf1BF4A8lTqafnV7dN7dkZBOLGyScdACRwTd3alb8bmh9dWckHav4BMwcxhd2VrHInLHZGTrP1d0q7Kx3aLb8hF8t9Ejxh2sUL2gt7T3ir/zrZeTFT5M05SnH7Lbq+Oa8h31xSVMv219vFgf4ZW7RWVU+4xUP09yNn1p6NgXH5CpvOp2ng= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3348.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(53546011)(66946007)(5660300002)(83380400001)(36756003)(6506007)(316002)(8676002)(786003)(66556008)(64756008)(66446008)(66476007)(38100700002)(45080400002)(122000001)(33656002)(38070700005)(26005)(966005)(76116006)(186003)(54906003)(75432002)(508600001)(2616005)(6486002)(166002)(2906002)(71200400001)(86362001)(6512007)(30864003)(6916009)(4326008)(8936002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZDV4Sk9JaXplWTNiT1FFejc3NzdJdVE0bUs4aVJNcW16dU9KZmEvYXRQSUh5?= =?utf-8?B?UHBwRGd5SGNwRVZNcEVlRldvS2tMcVpqeGtYV0Y5ZVBQa0RYQ2tVTkU4c0Zk?= =?utf-8?B?K0FvelNjcDhqMnk4NVNFc3ZaNE4zK25DL2R1NWE3Nll0Ym56V1dodDh4MzJy?= =?utf-8?B?a3VHSk42SHAydWJkd1N2cXdoa2ZzUUdwQ3lQMkw1M2pPWTVaNFJoR1hvN0t0?= =?utf-8?B?NDEvWlA5MEZvL0YyRHJPbmJlN2RGdEhNWTIwbS9xejlFZnd1RXZSUUxoQ1d6?= =?utf-8?B?eTVWUHp0S0dwK08yOW0yQ3liUjhZdDdSSHlWa0xsMU9OeURPeS8ydDI2clRl?= =?utf-8?B?RERwaEpOMzVVNDZkLyttOU1ndVU2amZvNFlOWFhYcTJKazQ1OUUxa21uaWQx?= =?utf-8?B?TnpHN2x0c3Y5SkxnWjZjMEp6ekVKajNPMWR4bVhwdjNld3lqbHJUM2RrL0ho?= =?utf-8?B?S3N0cjZIMEliQ3JmRnQ1cEhoTGRsdWpUbkIrTytqZ2JXdkpSRStiQTFxRE1L?= =?utf-8?B?dFo1NUtuSU9WVjFEZ1pBYkNSSm0wSWRPdzduc2o0cWpQN21zY25BTlJJOURl?= =?utf-8?B?cCt0ekJiOTZWM2xySWxwc3RqcmprMStwMGpUbzljUDlraTlueEtWMmhWejQ3?= =?utf-8?B?R21panlPRWg1aE1EQi9XeXczRUlpaVdVcXpZblJ2YjgwRGJ0a3BKUmI0amdo?= =?utf-8?B?bEFRaUtDRGN1QVR2ZHJYTjZDbzNWa08rQlQwdnlMWTFRWTRhYVo2WHNBRUhX?= =?utf-8?B?a1VzYVAwRVFUSkFidVdLTjE2d09VV2FCUjFNaVZFaVlnY2JTdVJrcVFzd2Fp?= =?utf-8?B?UVJnYmUzTkU0NnJIaURxdWpPYitSYzZ2QkhjanFuVlBJQ0VDKzFraUhxWGlP?= =?utf-8?B?YW03YjFrZjdQT2dpaEVMS0FjbXVzOXdrYXpQYmc0ak9SZDdmSm03WTNKdUtX?= =?utf-8?B?RWx6ZEplTTJHQ2dWQnhGOEo2SDlVdGt2ZDYyRVZQL1NoYnlTa2tGdENsTXpE?= =?utf-8?B?YWVJUXpRZUE2V3A4cTBsYnFadWpmRUpzVVUzZzcrczloa3pZNHhlUFZFcFNo?= =?utf-8?B?UTIrc0pLK044RVo0dHlpcU1sWWdsY2xxVVBoODBuQkFVYllHT2hHaUx4WXY3?= =?utf-8?B?bS9XNHkrMjdUY0labzVzLzIxTEFyazYxL1ZlUEJ4RE1VZElzdVFmczRKaFZO?= =?utf-8?B?dGhwVXBsUy95bDNIQlNRSFdoRjVJR1N2SnQ4Si9EZG5pZ01ETmpkaDBEVU8w?= =?utf-8?B?OVhrcWo4SkxCZ3k2eDRvcDk1cmhhNEJ4Qi9LYk0wNklaUFZvayt2Z0pmQmNw?= =?utf-8?B?WmNJQnFRTTVQcDdwU1BOMzVkWEo5Q2hXZjhmNnJ4eks1Nng1UG9pakRPME1t?= =?utf-8?B?OGtsbmZLdmU0WHcvcWlCYVltKytOUlNvY2h1b1ZmRFAxR2lhMVRNYU5lNmFL?= =?utf-8?B?bUZJNEhYS2J4Um1PMXRLUGVVdENmTkFHaU90Y0gzQXNCZXZjNWVBTnppWFBt?= =?utf-8?B?OU12NGhwbVJzVldFcGd5dldMR3UwOUpKbU5KTHBWWFhxNEFCazhoZmxLVE4v?= =?utf-8?B?K2lTYVVZTW5ROG5XVDBhSG1INDhLK3pzVTJPTGtueGdOSnBmNjdBN0N0WXhw?= =?utf-8?B?RDBsN1pheHpzNFFwQmZCdXE1OGd2M1VERXlKS0p4MUpZVDhwTmhvS2svaGhn?= =?utf-8?B?cklDTExiMkw3aTArR20zb3hZZEpOV2RmWEs1RWJJd2lQaWNhOVQvOEk2L3Er?= =?utf-8?B?dWhESUdHbkJ3NllNZkUySDVvNnU4NEpKUlZZdnRPU01qcmRHa3h3bUxxR2Vr?= =?utf-8?B?eTlhSmZSVWcvSFpPczJUUT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_484167A8836342E9816BE968784B1595npsedu_" MIME-Version: 1.0 X-OriginatorOrg: nps.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 00d37472-2aac-4dc9-06ac-08d98d97655d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 15:46:02.8419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zVMss1O0FpOL2G2Dt6Cqf04fQd0OoAbHf/kL0q6sySjoOqXiwfqopbaq3mvYbrYnYjIWNSLixtVpqS3NpdLuzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB4358 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com X-MS-Exchange-CrossPremises-TransportTrafficType: Email X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 205.155.65.226 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: BYAPR13MB4358.namprd13.prod.outlook.com Archived-At: Subject: Re: [MLS] Signature key uniqueness and rotation (Re: Resync archaeology + analysis + prognosis) 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, 12 Oct 2021 15:46:15 -0000 --_000_484167A8836342E9816BE968784B1595npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2VydGFpbmx5LCBSaWNoYXJkLg0KDQpUaGUgdW5pcXVlbmVzcyByZXF1aXJlbWVudCBsaW1pdHMg b25lIGtleSB0byBlYWNoIHVzZXIuIFVuZGVyIGFuIEFkZCwgdGhlIGNyZWRlbnRpYWwgaWRlbnRp dHkgKG5vdCBqdXN0IGNyZWRlbnRpYWwpIG11c3QgYmUgdW5pcXVlIGFuZCBkaWZmZXJlbnQgZnJv bSBvdGhlcnMgYWxyZWFkeSBpbiB0aGUgZ3JvdXAuIEV4dGVybmFsIENvbW1pdHMgYWxzbyBkaXNh bGxvdyBhIHJlbW92ZSthZGQgdW5kZXIgYSBkaWZmZXJlbnQgY3JlZGVudGlhbCAod2hpY2ggaXMg YSBnb29kIHRoaW5nKS4gVGhpcyBiZWdzIHRoZSBxdWVzdGlvbiB0aG91Z2ggb2YgaG93IHRvIHJv dGF0ZSBvdXQgc2lnbmF0dXJlIGtleXMuIEl0IHNlZW1zIHRoYXQgdGhlIHdheSB0byBkbyB0aGlz IHdvdWxkIGJlIGZvciB0aGUgbWVtYmVyIHRvIHByb3Bvc2UgdG8gcmVtb3ZlIHRoZW1zZWx2ZXMg YW5kIHJlLWFkZCAodXNpbmcgdGhlIHVwZGF0ZWQgY3JlZGVudGlhbCkgYXMgb25lIGFjdGlvbiDi gJMgb3RoZXJ3aXNlLCBpdCBpcyBub3QgY2xlYXIgaG93IHJvdGF0aW5nIHNpZ25hdHVyZSBrZXlz IGNhbiBiZSBzbW9vdGhseSBwZXJmb3JtZWQgd2hpbGUgbm90IGludGVyZmVyaW5nIHdpdGggdGhl IG90aGVyIHJlc3RyaWN0aW9ucy4NCg0KR2l2ZW4gdGhlIHZhcmlvdXMgZmVhdHVyZXMgdGhhdCBo YXZlIGJlZW4gYWRkZWQgZHVyaW5nIHJlY2VudCBjaGFuZ2VzIGFuZCBjcmVkZW50aWFsL2lkZW50 aXR5IHJlc3RyaWN0aW9ucyBvbiB0aGVtIChlLmcuIEV4dGVybmFsIENvbW1pdHMpLCBJIHByb3Bv c2UgdGhhdCB3ZSBjbGVhcmx5IGRlbGluZWF0ZSBpbiB0aGUgZHJhZnQgaG93IHJvbGxpbmcgYSBt ZW1iZXLigJlzIGNyZWRlbnRpYWwgbWF5IGJlIHBlcmZvcm1lZC4gVGhlIGRyYWZ0IGlzIGFwcHJv YWNoaW5nIHRoZSBwb2ludCB3aGVyZSBpdCBzdGF0ZXMgYSBtdWx0aXR1ZGUgb2Ygd2F5cyB0aGF0 IGFjdGlvbiBtYXkgbm90IGJlIGRvbmUsIGJ1dCBkb2VzIG5vdCBnaXZlIGRpcmVjdGlvbiBvbiBo b3cgaXQgbWF5IGJlIGRvbmUuDQoNCg0KQnJpdHRhDQoNCg0KRnJvbTogUmljaGFyZCBCYXJuZXMg PHJsYkBpcHYuc3g+DQpEYXRlOiBUaHVyc2RheSwgT2N0b2JlciA3LCAyMDIxIGF0IDEwOjU3IEFN DQpUbzogIkhhbGUsIEJyaXR0YSAoQ0lWKSIgPGJyaXR0YS5oYWxlQG5wcy5lZHU+DQpDYzogS29u cmFkIEtvaGJyb2sgPGtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU+LCBNZXNzYWdpbmcgTGF5 ZXIgU2VjdXJpdHkgV0cgPG1sc0BpZXRmLm9yZz4NClN1YmplY3Q6IFNpZ25hdHVyZSBrZXkgdW5p cXVlbmVzcyBhbmQgcm90YXRpb24gKFJlOiBbTUxTXSBSZXN5bmMgYXJjaGFlb2xvZ3kgKyBhbmFs eXNpcyArIHByb2dub3NpcykNCg0KKENoYW5naW5nIHN1YmplY3QgbGluZSBiZWNhdXNlIHdlJ3Jl IGRpdmVyZ2luZyBhIGxpdHRsZS4uLikNCg0KSGkgQnJpdHRhLA0KDQpDb3VsZCB5b3UgZXhwbGFp biBhIGxpdHRsZSBtb3JlIGhvdyB5b3UgdGhpbmsgdGhlIHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnRz IGNvdWxkIG1ha2UgaXQgbW9yZSBkaWZmaWN1bHQgdG8gcm90YXRlIHNpZ25hdHVyZSBrZXlzPw0K DQpJdCBkb2Vzbid0IHNlZW0gdG8gbWUgbGlrZSB0aGVyZSdzIHJlYWxseSBhbnkgaW50ZXJhY3Rp b24gYmV0d2VlbiBzaWduYXR1cmUga2V5IHJvdGF0aW9uIGFuZCBlaXRoZXIgZXh0ZXJuYWwgY29t bWl0IG9yIHNpZ25hdHVyZSBrZXkgdW5pcXVlbmVzcyByZXF1aXJlbWVudHMuICBUaGUgb25seSBp bnRlcnNlY3Rpb24gaXMgdGhhdCB0aGUgcmVxdWlyZW1lbnQgdGhhdCBhIHJlc3luYyBvcGVyYXRp b24gaGF2ZSB0aGUgc2FtZSBzaWduYXR1cmUga2V5IG1lYW5zIHRoYXQgeW91IGNhbid0IHJvdGF0 ZSB0aGUgc2lnbmF0dXJlIGtleSBhdCB0aGUgc2FtZSB0aW1lIHRoYXQgeW91IHJlc3luYy4gIEhv d2V2ZXIsIHlvdSBjb3VsZCBzZW5kIGEgc2Vjb25kIGNvbW1pdCByb3RhdGluZyB0aGUgc2lnbmF0 dXJlIGtleSBpbW1lZGlhdGVseSBhZnRlci4NCg0KLS1SaWNoYXJkDQoNCg0KT24gVGh1LCBPY3Qg NywgMjAyMSBhdCAxOjQ2IFBNIEhhbGUsIEJyaXR0YSAoQ0lWKSA8YnJpdHRhLmhhbGVAbnBzLmVk dTxtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdT4+IHdyb3RlOg0KVGhhdCBzb3VuZHMgcmVhc29u YWJsZSB0byBtZSBhcyBhIHdheSBmb3J3YXJkLg0KDQpUaGUgcXVlc3Rpb24gcG9zZWQgYmVmb3Jl ICjigJxUaGlzIGxlYWRzIHRvIGFuIGltcG9ydGFudCBxdWVzdGlvbjogZG9lcyBvdXIgY3VycmVu dCB1bmlxdWVuZXNzIG9mIHNpZyBrZXkgcHJlZGljYXRlIGxpbWl0IHRoZSBhYmlsaXR5IHRvIHJv dGF0ZSBzaWduYXR1cmUga2V5cyB3aXRoaW4gYSBncm91cD8gVGhhdCDigKYgW2lzIHdoYXQgbGlt aXRzXSB0aGUgZHJhd2JhY2tzIG9mICgzKS7igJ0pIHN0aWxsIHN0YW5kcy4gSSBkbyBub3QgdGhp bmsgdGhpcyBpbmhpYml0cyBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBQUiwgYnV0IGl0IGlzIGlt cG9ydGFudCB0byBhZGRyZXNzLiBJZiB0aGVyZSBpcyBhIHRyYWRlLW9mZiBiZXR3ZWVuIGFuIGlt cGxlbWVudGF0aW9uIGFsbG93aW5nIHJlbW92ZStyZXN5bmMgYW5kIHJvdGF0aW5nIG91dCBzaWdu YXR1cmUga2V5cywgdGhlbiB0aGF0IHNob3VsZCBiZSBub3RlZCBpbiB0aGUgYXJjaGl0ZWN0dXJl IGRvY3VtZW50IGlmIG5vdCB0aGUgcHJvdG9jb2wgc3BlYyBpdHNlbGYuIFdlIGFyZSBub3QgZ29p bmcgdG8gZ28gdGhyb3VnaCBhbGwgdGhlIHBvc3NpYmxlIG9wdGlvbnMgZm9yIGltcGxlbWVudGF0 aW9uLCBidXQgd2hlbiB0aGVyZSBpcyBzaWduaWZpY2FudCBzcGFjZSBpbiB0aGUgcHJvdG9jb2wg c3BlYyBkZXZvdGVkIHRvIGFuIG9wdGlvbmFsIGZ1bmN0aW9uYWxpdHkgKGUuZy4gZXh0ZXJuYWwg Y29tbWl0cyBhbmQgcmVzeW5jKSB0aGVuIGl0IHdvdWxkIGJlIGdvb2QgdG8gbm90ZSB0cmFkZS1v ZmZzIHRoYXQgd2lsbCBjb21lIHdpdGggaXQuIFdlIHdvdWxkIG5vdCBoYXZlIGEgd2VsbC13cml0 dGVuIHNwZWNpZmljYXRpb24gaWYgaXQgY291bGQgcG90ZW50aWFsbHkgbGVhZCBhbiBpbXBsZW1l bnRvciBmYXIgZG93biBvbmUgb3B0aW9uYWwgcGF0aCB0aGF0IHByZWNsdWRlcyBkZXNpcmVkIHNl Y3VyaXR5IGd1YXJhbnRlZXMsIGFuZCBnaXZlcyBubyBjb250ZXh0IG9uIHRoYXQgKGkuZS4gbGV0 4oCZcyB0cnkgdG8gbWluaW1pemUgb2J2aW91cyBjYXNlcyBvZiDigJxJIHdpc2ggSSBoYWQga25v d27igKbigJ0gZm9yIGltcGxlbWVudG9ycykuDQoNCkJyaXR0YQ0KDQoNCkZyb206IFJpY2hhcmQg QmFybmVzIDxybGJAaXB2LnN4PG1haWx0bzpybGJAaXB2LnN4Pj4NCkRhdGU6IFdlZG5lc2RheSwg T2N0b2JlciA2LCAyMDIxIGF0IDg6NTUgQU0NClRvOiBLb25yYWQgS29oYnJvayA8a29ucmFkLmtv aGJyb2tAZGF0YXNocmluZS5kZTxtYWlsdG86a29ucmFkLmtvaGJyb2tAZGF0YXNocmluZS5kZT4+ DQpDYzogIkhhbGUsIEJyaXR0YSAoQ0lWKSIgPGJyaXR0YS5oYWxlQG5wcy5lZHU8bWFpbHRvOmJy aXR0YS5oYWxlQG5wcy5lZHU+PiwgTWVzc2FnaW5nIExheWVyIFNlY3VyaXR5IFdHIDxtbHNAaWV0 Zi5vcmc8bWFpbHRvOm1sc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01MU10gUmVzeW5jIGFy Y2hhZW9sb2d5ICsgYW5hbHlzaXMgKyBwcm9nbm9zaXMNCg0KDQpJJ3ZlIHVwZGF0ZWQgdGhlIFBS IHRvIGRvIGJhc2ljYWxseSB3aGF0IEtvbnJhZCBwcm9wb3Nlcy4gIE5hbWVseSwgYWxsb3cgUmVt b3ZlLCBidXQgc3VnZ2VzdCB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gYXBwbHkgYWRkaXRpb25hbCBj b25zdHJhaW50cy4NCg0KaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21scy1wcm90b2NvbC9wdWxs LzQ4MS9maWxlcyNkaWZmLTdjMzY5Yjg1YjI2YTc0NmE3ZTcwY2QyODg0MDM3ODk2ZGVmZTAzYjMw OThiZWM5NzZmNzljOTk0ZDIyYTYwNGFSMjg3MzxodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2cl MkZtbHMtcHJvdG9jb2wlMkZwdWxsJTJGNDgxJTJGZmlsZXMlMjNkaWZmLTdjMzY5Yjg1YjI2YTc0 NmE3ZTcwY2QyODg0MDM3ODk2ZGVmZTAzYjMwOThiZWM5NzZmNzljOTk0ZDIyYTYwNGFSMjg3MyZk YXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0NmZjcyOWEwZTI1ZjI0YWY3Mjg1 YTA4ZDk4OWJiZjUwMiU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAl N0M2Mzc2OTIyNjI2Mzk3MDIyOTglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MTAwMCZzZGF0YT15TzA3Um8zNzVDdnRFVVA4MGZaTVYyMHlHZTk5WEp6MzN2U0ZjalY4Nlk0JTNE JnJlc2VydmVkPTA+DQoNCkJyaXR0YSwgZG9lcyB0aGF0IHdvcmsgZm9yIHlvdT8NCg0KT24gV2Vk LCBPY3QgNiwgMjAyMSBhdCAyOjA1IEFNIEtvbnJhZCBLb2hicm9rIDxrb25yYWQua29oYnJva0Bk YXRhc2hyaW5lLmRlPG1haWx0bzprb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPj4gd3JvdGU6 DQpIaSwNCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIHNvbHV0aW9ucyAoMikgYW5k ICgzKSAoZGlzY2FyZGluZyAxIGFuZCA0IGZvciBub3cpIHJlcHJlc2VudCB0cmFkZS1vZmZzIGlu IHNlY3VyaXR5IGd1YXJhbnRlZXMgYW5kIHRoZWlyIGFwcGxpY2FiaWxpdHkgZGVwZW5kcyBvbiB0 aGUgc3BlY2lmaWMgZGVwbG95bWVudCBzY2VuYXJpby4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IGV4dGVybmFsIGpvaW5zIHdpbGwgYmUgc3ViamVjdCB0byBzb21lIHNvcnQgb2YgcG9saWN5IGFu eXdheS4gU2hvdWxkIHdlIHRoZW4gYmUgc3RyaWN0IGluIHRoZSBzcGVjIGluIHRlcm1zIG9mIHdo YXQgd2UgbWFuZGF0ZSB0aGUgZXhhY3QgcG9saWN5IHcuci50LiBQU0tzIGlzPw0KDQpTaW5jZSBJ IGRvbid0IHRoaW5rIGVpdGhlciBzb2x1dGlvbiByZXByZXNlbnRzIG11Y2ggb2YgYSBmb290LWd1 biwgSSBwcm9wb3NlIHdlIGluY2x1ZGUgdGhlIGNhcGFiaWxpdHkgdG8gaW5jbHVkZSByZXN5bmMg UFNLcyBpbiB0aGUgc3BlYyBmb3IgdGhpcyBwdXJwb3NlLCBidXQgZG9uJ3QgbWFuZGF0ZSB0aGVt LiBJbnN0ZWFkIHdlIHJlbGVnYXRlIHRoZSBwb2xpY3kgZGVjaXNpb24gdG8gdGhlIGFwcGxpY2F0 aW9uIGxheWVyIGFuZCBkZXRhaWwgdGhlIHNlY3VyaXR5IHRyYWRlLW9mZnMgaW4gdGhlIGFyY2hp dGVjdHVyZSBkb2N1bWVudC4gSSByZWFsaXplIHRoYXQgZGVsZWdhdGluZyBkZWNpc2lvbnMgdG8g dGhlIGFwcGxpY2F0aW9uIGxheWVyIGlzIGEgYml0IG9mIGEgY29wLW91dCBzb2x1dGlvbiwgYnV0 IEkgdGhpbmsgaW4gdGhpcyBjYXNlIGl0IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUgdGhlIG1lY2hh bmlzbSBpbiB0aGUgc3BlYyBhbmQgdGhlbiBsZXQgdGhlIGFwcGxpY2F0aW9uIGRlY2lkZS4NCg0K Q2hlZXJzLA0KS29ucmFkDQoNCj4gUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJs YkBpcHYuc3g+PiBoYXQgYW0gMDUuMTAuMjAyMSAwNDozMSBnZXNjaHJpZWJlbjoNCj4NCj4NCj4g SGkgQnJpdHRhLA0KPg0KPiBDb3VwbGUgb2YgcmVzcG9uc2VzIGlubGluZS4uLg0KPg0KPg0KPiBP biBNb24sIE9jdCA0LCAyMDIxIGF0IDg6NDIgUE0gSGFsZSwgQnJpdHRhIChDSVYpIDxicml0dGEu aGFsZUBucHMuZWR1PG1haWx0bzpicml0dGEuaGFsZUBucHMuZWR1Pj4gd3JvdGU6DQo+ID4gW3Ry aW1tZWRdDQo+ID4NCj4gPiBUbyB0aGUgcHJlc2VudCBwcm9wb3NlZCBvcHRpb25zLCBJIHdpbGwg bm90ZSB0aGF0IHRoZSDigJhuZXcgam9pbmVycyBpbiBpbnRlcmlt4oCZIGNhc2UgaXMgbGlrZWx5 IGEgbWlzbGVhZGluZyBmb2N1cyBwb2ludCBmb3IgdGhlIGRpc2N1c3Npb24sIGFuZCB3ZSBzaG91 bGQgYXZvaWQgdHJpcHBpbmcgaW50byB0aGF0IGRpdGNoIGZvciBhIG51bWJlciBvZiByZWFzb25z Og0KPiA+ICAgKiBOb3RhYmx5LCBpZiBldmVyeW9uZSBleGNlcHQgZm9yIHRoZSByZS1zeW5jaW5n IHBhcnRpY2lwYW50IGlzIG5ldywgd2h5IG5vdCBqdXN0IHJlcXVpcmUgdGhlIHJlLXN5bmNpbmcg cGFydGljaXBhbnQgdG8gYmUgYWRkZWQgYXMgYSBuZXcgbWVtYmVyIHRoZW1zZWx2ZXM/IEl0IGlz LCBhZnRlciBhbGwsIHByYWN0aWNhbGx5IGEgYnJhbmQgbmV3IGdyb3VwIGF0IHRoYXQgcG9pbnQu DQo+ID4gICAqIEl0IGlzIHRydWUgdGhhdCBhIG5ldyBtZW1iZXIgd291bGQgbm90IGdhaW4gZnJv bSBhIFBTSyBndWFyYW50ZWUsIGJ1dCB3aHkgc2hvdWxkIHdlIHJlZHVjZSB0aGUgZ3VhcmFudGVl cyBmb3IgYWxsIG90aGVyIHBhcnRpY2lwYW50cyB0byB0aGF0IG9mIHRoZSBuZXcgam9pbmVyPyBG cm9tIHRoZSB2aWV3IG9mIHRoZSBuZXcgam9pbmVyLCBhbGwgcGFydGljaXBhbnRzIGFyZSBuZXcg aW4gYW55IGNhc2UsIHNvIGUuZy4gUENTIGRvZXMgbm90IGhhdmUgc3Vic3RhbnRpYWwgbWVhbmlu ZyBhcyBvZiB5ZXQuIEV4aXN0aW5nIG1lbWJlcnMgaGF2ZSBtb3JlIHRvIGxvc2UgYW5kIGFsc28g aGF2ZSB0aGUgbW9yZSB0byBnYWluIGZyb20gUFNLIHVzZS4gSSBkbyBub3QgYmVsaWV2ZSB3ZSB3 YW50IHRvIGFkYXB0IGEgc3RhbmNlIG9mIOKAmGlmIHRoZSBuZXcgam9pbmVyIGRvZXNu4oCZdCBn ZXQgYSBzZWN1cml0eSBndWFyYW50ZWUsIG5vIG9uZSBzaG91bGQgaGF2ZSB0aGUgc2VjdXJpdHkg Z3VhcmFudGVl4oCZIOKAkyBpbiBmYWN0LCB0aGUgdHJlZSBzdHJ1Y3R1cmUsIGNvbW1pdCBoaXN0 b3J5LCBhbmQgdGhlIGxpa2UgcHJvdmlkZSBpbnNpZ2h0IHRvIGxvbmdlciB0ZXJtIG1lbWJlcnMg dGhhdCBhIG5ldyBqb2luZXIgZG9lcyBub3QgaGF2ZS4gU28gKDIpIG9mZmVycyBhIG5ldyBqb2lu ZXIgdGhlIGJlbmVmaXRzIG9mICgzKSBidXQgdG8gYWxsIG90aGVycyBhbiBldmVuIHN0cm9uZ2Vy IGd1YXJhbnRlZS4NCj4gPiAgICogQXMgYSBub2QgdG8gd2hhdCBhIG5ldyBqb2luZXIgbWF5IGdh aW4sIHdlIGNhbiBvZmZlciB0aGUgZm9sbG93aW5nOiBpZiBhIHJlLXN5bmMgUFNLIGZhaWxzLCB0 aGVuIHdoaWNoZXZlciBleGlzdGluZyBtZW1iZXIgY2hlY2tzIGFuZCBub3RlcyB0aGUgUFNLIGZh aWx1cmUgc2hvdWxkIGluaXRpYXRlIGEgcmVtb3ZhbCBvZiB0aGUgcmVzeW5jaW5nIG1lbWJlci4g SWYgdGhlcmUgaXMgYSBuZXcgam9pbmVyLCB0aGVuIGJ5IGNvbnRpbnVlZCBwcmVzZW5jZSBvZiB0 aGUgcmUtc3luY2luZyBtZW1iZXIgdGhleSBnYWluIHRoZSBndWFyYW50ZWUgdGhhdCBhdCBsZWFz dCBvbmUgb3RoZXIgZ3JvdXAgbWVtYmVyIGhhcyBwcmV2aW91c2x5IHNlZW4gdGhhdCBtZW1iZXIs IG9yIGVsc2Ugd291bGQgaGF2ZSBlamVjdGVkIHRoZW0gKGFzc3VtaW5nIHRoYXQgdGhlIGNoZWNr ZXIgaXMgb25saW5lKS4NCj4gSSBkb24ndCBtZWFuIHRvIG92ZXItcm90YXRlIG9uIHRoaXMgY2Fz ZSwgYnV0IHNvZnR3YXJlIGJlaW5nIHNvZnR3YXJlLCB3ZSBuZWVkIGFuIGFsZ29yaXRobSB0byBp bXBsZW1lbnQgdGhhdCBjb3ZlcnMgYWxsIHRoZSBjYXNlcy4gV2hpbGUgdGhlICJldmVyeW9uZSBp cyBuZXciIHNjZW5hcmlvIGlzIG91dGxhbmRpc2gsIGl0IHdvdWxkbid0IGJlIGFsbCB0aGF0IHN1 cnByaXNpbmcgdG8gaGF2ZSBvbmUgb3IgdHdvIG5ldyBtZW1iZXJzLCBzbyBpdCdzIGEgY2FzZSB0 aGF0IHdvdWxkIG5lZWQgYWRkcmVzc2luZy4gVGhlIHNlZW1pbmdseSBtb3N0IG9idmlvdXMgYXBw cm9hY2ggdG8gYWRkcmVzc2luZyB0aGlzIHByb2JsZW0gaXMgdG8gZW5jcnlwdCB0aGUgUFNLIHRv IG5ldyBtZW1iZXJzLCB3aGljaCByZXF1aXJlcyB5b3UgYXQgbGVhc3QgaGF2ZSBlbm91Z2ggc3Rh dGUgdG8gZmlndXJlIG91dCB3aG8gdGhlIG5ldyBtZW1iZXJzIGFyZS4NCj4NCj4gSXQgYWxzbyBv Y2N1cnMgdG8gbWUgbm93IHRoYXQgdGhlIFBTSyBhcHByb2FjaCBwcmVzdW1lcyB0aGF0IHlvdSBr bm93IHdoZW4geW91ciBzdGF0ZSB3ZW50IGJhZCwgc2luY2UgeW91IHdvdWxkIHdhbnQgdG8gdXNl IGEgUFNLIGZyb20gYmVmb3JlIHRoYXQgcG9pbnQuIEluIFJhcGhhZWwncyBleGFtcGxlIHdoZXJl IHBlcnNpc3RlbnQgc3RvcmFnZSBpcyBjb3JydXB0ZWQsIGFsbCB5b3Uga25vdyBpcyB0aGF0IG1l c3NhZ2VzIHN0b3BwZWQgZGVjcnlwdGluZywgd2hpY2ggZ2l2ZXMgeW91IGFuIHVwcGVyIGJvdW5k IG9uIHRoZSB0aW1lIG9mIGNvcnJ1cHRpb24sIGJ1dCBub3QgcmVhbGx5IGEgd2F5IHRvIGdvIGJh Y2sgYW5kIGZpZ3VyZSBvdXQgd2hhdCdzIGdvb2QuDQo+DQo+DQo+ID4gVGhlIHNlY3VyaXR5IGdv YWwgaW4gdGhlIGJhbGFuY2UgaGVyZSBpcyBQQ1MuIEFkZGluZyBhIHJlLXN5bmMgb3B0aW9uIG9m IGFueSBvZiB0aGUgdmFyaWV0aWVzICgyKS0oNCkgd291bGQgYnJlYWsgdGhhdCB0byBzb21lIGRl Z3JlZSwgc2luY2UgZm9sbG93aW5nIGEgY29tcHJvbWlzZSBhbmQgcGFzc2l2ZSBwZXJpb2QgdGhl IGFkdmVyc2FyeSBpcyB0aGVuIGVuYWJsZWQgdG8gcmVnYWluIGEgZm9vdGhvbGQuIFRoZSBxdWVz dGlvbiBpcyBob3cgbXVjaCBvZiBhIGRlZ3JlZSBvZiBsb3NzIGFyZSB3ZSB3aWxsaW5nIHRvIHRv bGVyYXRlLg0KPg0KPiBJJ20gbm90IHN1cmUgSSB3b3VsZCByZWFsbHkgY2hhcmFjdGVyaXplIHRo aXMgYXMgYSBQQ1MgdmlvbGF0aW9uLiBQQ1MgaXMgYSBndWFyYW50ZWUgdGhhdCB5b3UgZ2V0IHdo ZW4geW91IHRha2UgYSBjZXJ0YWluIGFjdGlvbi4gRm9yIGV4YW1wbGUsIHdoZW4gYSBtZW1iZXIg aXNzdWUgYW4gVXBkYXRlIG9yIGEgQ29tbWl0IHdpdGggYSBmcmVzaCBIUEtFIGtleSBwYWlyLCB5 b3Ugc2hvdWxkIGdldCBQQ1Mgd2l0aCByZWdhcmQgdG8gdGhhdCBwYXJ0aWNpcGFudCdzIEhQS0Ug a2V5IHBhaXI7IGxpa2V3aXNlIHdpdGggcm90YXRpbmcgc2lnbmF0dXJlIGtleXMuIEhlcmUsIHRo ZSBzaWduYXR1cmUga2V5IGhhcyBub3QgYmVlbiByb3RhdGVkLCBzbyB0aGVyZSdzIG5vIFBDUyBi b3VuZGFyeS4NCj4NCj4gSXQgaXMgd29ydGggY29uc2lkZXJpbmcgd2hldGhlciB0aGlzIG1lY2hh bmlzbSBnaXZlcyB0aGUgYXR0YWNrZXIgYW55IGFkZGl0aW9uYWwgY2FwYWJpbGl0aWVzIGluIHRo ZSBldmVudCB0aGF0ICgxKSB0aGUgc2lnbmF0dXJlIGtleSBpcyBjb21wcm9taXNlZCwgYW5kICgy KSB0aGUgY29tcHJvbWlzZWQgbWVtYmVyIGlzc3VlcyBhbiBVcGRhdGUgb3IgQ29tbWl0IHJvdGF0 aW5nIHRoZSBzaWduYXR1cmUga2V5LiBJU1RNIHRoYXQgeW91IHN0aWxsIGdldCBQQ1MgdGhlcmUg aW4gb3B0aW9uICgzKSwgc2luY2UgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhlIHNpZ25hdHVyZSBr ZXlzIG1hdGNoIGVuc3VyZXMgdGhhdCB0aGUgb2xkLCBjb21wcm9taXNlZCBzaWduYXR1cmUga2V5 IGlzIG5vdCBhbGxvd2VkIHRvIHJlc3luYyBiYWNrIGludG8gdGhlIGdyb3VwLiBUaGVyZSdzIHN0 aWxsIGEgcmlzayB0aGF0IHRoZSBjb21wcm9taXNlZCBrZXkgLyBjcmVkZW50aWFsIGNvdWxkIGJl IHVzZWQgZm9yIGEgZnJlc2gsIG5vbi1yZXN5bmMgam9pbiwgYnV0IHRoYXQncyBhbiBpbmhlcmVu dCByaXNrIHdpdGggZXh0ZXJuYWwgQ29tbWl0IC8gZnJlZWx5IGpvaW5hYmxlIGdyb3VwcywgYW5k IGFsc28gYW4gb3Bwb3J0dW5pdHkgZm9yIHRoZSBBUydzIHJldm9jYXRpb24vaW52YWxpZGF0aW9u IHN5c3RlbSB0byBoZWxwLg0KPg0KPiBXaWxsIHRha2UgYSBsb29rIGF0IHRoZSByZW1haW5kZXIg aW4gdGhlIG1vcm5pbmcuLi4NCj4NCj4gLS1STEINCj4NCj4NCj4gPiAgICogSSBhZ3JlZSB0aGF0 ICg0KSBpcyBhbiBpbW1lZGlhdGUgZGlzY2FyZC4NCj4gPiAgICogVW5kZXIgKDIpIGEgUFNLIHVz ZSwgdGhlIFBTSyB1c2UgYXQgbGVhc3QgbW9yZSBsaW1pdGVkIGR1ZSB0byB0aGUgcHJvb2Ygb2Yg a25vd2xlZGdlIG9mIGEgcGFzdCBzdGF0ZSAoZS5nLiBub3RlcyBhYm92ZSkuIFRoaXMgaXMgYSB3 b3J0aHdoaWxlIHByb3BlcnR5IHRvIGVuZm9yY2UgaW4gbXkgdmlldyBzaW5jZSBpdCBiYWxhbmNl cyBhdXRoZW50aWNhdGlvbiBhY3Jvc3MgdHdvIHZlY3RvcnM6IHRoZSBzaWduYXR1cmUga2V5IGFu ZCBrbm93bGVkZ2Ugb2YgZ3JvdXAgc3RhdGUuIEFkdmVyc2FyeSBhY2Nlc3MgdG8gb25seSBvbmUg b3IgdGhlIG90aGVyIGlzIGluc3VmZmljaWVudCBmb3IgdGhlIGFkdmVyc2FyeSB0byBlamVjdCBB bGljZSBhbmQgcmVwbGFjZSBoZXIgaW4gdGhlIGdyb3VwLg0KPiA+ICAgKiBVbmRlciAoMyksIHRo ZSBhdHRhY2sgc2NlbmFyaW8gb2YgRXZlIGNvbXByb21pc2luZyBBbGljZSAoZnVsbCBzdGF0ZSAr IHNpZyBrZXkpLCBmb2xsb3dlZCBldmVudHVhbGx5KiBieSByZW1vdmluZyBBbGljZSB3aGlsZSBh ZGRpbmcgaGVyc2VsZiwgaXMgbm90IGRpc3NpbWlsYXIgZnJvbSB0aGUgYXR0YWNrIHNjZW5hcmlv IG9mIEV2ZSBjb21wcm9taXNpbmcgQWxpY2UgZnVsbCBzdGF0ZSArIHNpZyBrZXkpIGZvbGxvd2Vk IGV2ZW50dWFsbHkqIGJ5IHByb3ZpZGluZyBhbiBpbXBlcnNvbmF0aW5nIHVwZGF0ZSBpbiBBbGlj ZeKAmXMgbmFtZS4gV2hhdCBoYXMgYmVlbiBzaG93biBzbyBmYXIgaXMgdGhhdCB0aGlzIHR5cGUg b2Ygc2NlbmFyaW8gY2FuIGJlIGxpbWl0ZWQgYnkgcm90YXRpbmcgc2lnbmF0dXJlIGtleXMuIEEg aW1wb3J0YW50IHBvaW50IHRoYXQgaXMgZGlmZmVyZW50IGluIHRoZXNlIHNjZW5hcmlvcyBpcyB0 aGF0IHVuZGVyIHRoZSBmaXJzdCBBbGljZSBrbm93cyBzaGUgd2FzIHJlbW92ZWQgKGEgcGx1cykg d2hpbGUgdW5kZXIgdGhlIHNlY29uZCAoY3VycmVudGx5IHBvc3NpYmxlKSBzY2VuYXJpbyB0aGUg Z3JvdXAgc2ltcGx5IGdvZXMgc2lsZW50IGFuZCBBbGljZSBkb2VzIG5vdCBrbm93IGlmIGl0IHdh cyBtYWxpY2lvdXMgb3Igbm90LiBBbGwgc2FpZCwgaXQgY291bGQgYmUgd29yc2UuIFRoYXQgZG9l cyBub3QgY29uc2lkZXIgb3RoZXIgYXR0YWNrIHNjZW5hcmlvcyB0aG91Z2gsIGZvciBleGFtcGxl IHdoZW4gdGhlIGF0dGFja2VyIGdhaW5zIHRoZSBzaWduYXR1cmUga2V5IGJ1dCBub3QgcGFzdCBz dGF0ZS9QU0suDQo+ID4NCj4gPiAqSS5lLiBhZnRlciBhIHBvdGVudGlhbGx5IHBhc3NpdmUgcGVy aW9kLCBpZiB3ZSBhcmUgdG8gc2hvdyBob3cgdGhpcyBiZWhhdmVzIGluIHRoZSBQQ1Mgc2NlbmFy aW8uDQo+ID4NCj4gPiBUaGlzIGxlYWRzIHRvIGFuIGltcG9ydGFudCBxdWVzdGlvbjogZG9lcyBv dXIgY3VycmVudCB1bmlxdWVuZXNzIG9mIHNpZyBrZXkgcHJlZGljYXRlIGxpbWl0IHRoZSBhYmls aXR5IHRvIHJvdGF0ZSBzaWduYXR1cmUga2V5cyB3aXRoaW4gYSBncm91cD8gVGhhdCBpcyBvdXIg bWVhbnMgb2YgbGltaXRpbmcgdGhlIGZ1bGwgc3RhdGUgKyBzaWcga2V5IGNvbXByb21pc2Ugc2Nl bmFyaW8gaW1wYWN0cyBtZW50aW9uZWQgYWJvdmUsIGFuZCB0aGVyZWZvcmUgdGhlIG1lYW5zIG9m IGxpbWl0aW5nIHRoZSBkcmF3YmFja3Mgb2YgKDMpLiBXZSBzaG91bGQgbWFrZSBzdXJlIHRoYXQg dGhlIGxpbWl0aW5nIGFiaWxpdHkgaXMgZmVhc2libGUuIElmIHRoYXQgaGluZGVyZWQgaW4gYW55 IHdheSwgdGhlbiBJIHdvdWxkIHZvdGUgdmVyeSBzdHJvbmdseSBmb3IgKDIpIGFzIGl0IGF0IGxl YXN0IGJvb3RzdHJhcHMgc29tZSBvZiB0aGUgYXV0aGVudGljYXRpb24gcHJvcGVydGllcyBmcm9t IHRoZSBncm91cCBzdGF0ZSBpbiB0aGUgc2NlbmFyaW8gdGhhdCB0aGUgc2lnIGtleSBpcyBjb21w cm9taXNlZC4NCj4gPg0KPiA+DQo+ID4gQWxsIHRoZSBiZXN0LA0KPiA+DQo+ID4gQnJpdHRhDQo+ ID4NCj4gPg0KPiA+DQo+ID4gRnJvbTpNTFMgPG1scy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpt bHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlw di5zeDxtYWlsdG86cmxiQGlwdi5zeD4+DQo+ID4gIERhdGU6TW9uZGF5LCBPY3RvYmVyIDQsIDIw MjEgYXQgNDowOSBQTQ0KPiA+ICBUbzpNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgV0cgPG1sc0Bp ZXRmLm9yZzxtYWlsdG86bWxzQGlldGYub3JnPj4NCj4gPiAgU3ViamVjdDpbTUxTXSBSZXN5bmMg YXJjaGFlb2xvZ3kgKyBhbmFseXNpcyArIHByb2dub3Npcw0KPiA+DQo+ID4gT0ssIEkgdGhpbmsg SSBoYXZlIHRyYWNlZCBiYWNrIHNvbWUgaWRlYSBvZiB3aHkgd2UgcmVtb3ZlZCB0aGUgZWFybGll ciByZXN5bmMgcHJvcG9zYWwuIEhlcmUncyBhIGxpdHRsZSBlc3NheSBvbiBob3cgd2UgZ290IGhl cmUsIGEgcmVjYXAgb2YgdGhlIHRyYWRlLW9mZnMsIGFuZCBteSB0aG91Z2h0cyBvbiB3aGVyZSB3 ZSBzaG91bGQgZ28uDQo+ID4NCj4gPiB0bDtkcjogRWFybGllciBkZWNpc2lvbiBub3QgZGlzcG9z aXRpdmU7IHdlIHNob3VsZCBkbyBiYXNpY2FsbHkgd2hhdCdzIGluIHRoZSBQUiBub3cuDQo+ID4N Cj4gPiAgIyBIaXN0b3J5DQo+ID4NCj4gPiAgVGhlIHN0b3J5IHN0YXJ0cyBhbGwgdGhlIHdheSBi YWNrIGF0IHRoZSBKYW51YXJ5IDIwMTkgaW50ZXJpbSBhdCBNb3ppbGxhIC8gTW91bnRhaW4gVmll dy4gVGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiB0aGVyZSBvZiBBQ0svTkFDSyBhbmQgcmVwbGF5IGFz IHJlbGF0ZWQgaXNzdWVzIFsxXS4gVGhhdCBkaXNjdXNzaW9uIHNlZW1zIHRvIGhhdmUgbGVkIHRv IGFncmVlbWVudCB0aGF0IGEgY29tcGxldGUgZXJyb3IgcmVjb3Zlcnkgc3lzdGVtIHdhcyBhIGNv bXBsZXggZW5vdWdoIHRvcGljLCBhbmQgY2xlYXJseSBlbm91Z2ggc2VwYXJhdGVkIGZyb20gdGhl IG1haW4gcHJvdG9jb2wgdGhhdCBpdCBjb3VsZCBiZSBoYW5kbGVkIGluIGEgc2VwYXJhdGUgc3Bl Y2lmaWNhdGlvbi4gQXMgYSByZXN1bHQsIHRoZSBpc3N1ZXMgdGhhdCBoYWQgYmVlbiBvcGVuZWQg Zm9yIEFDSy9OQUNLIGFuZCByZXN5bmMgd2VyZSBjbG9zZWQgWzJdWzNdLiBXaGVuIEJyaXR0YSBh bmQgS29ucmFkIHBvc3RlZCAjMzM2IFs0XSBpbmNsdWRpbmcgYSByZXN5bmMgbWVjaGFuaXNtLCBt eSByZXZpZXcgc2ltcGx5IGNpdGVkIHRoYXQgZWFybGllciBjbG9zZWQgaXNzdWUgYXMgYSByZWFz b24gZm9yIHRha2luZyBpdCBvdXQgWzVdLg0KPiA+DQo+ID4gIE9uZSBvdGhlciBub3RlIHdpdGgg cmVnYXJkIHRvICMzMzYgLS0gSXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgInJlc3luYyIgbWVjaGFu aXNtIGluIHRoZXJlIHdhcyBub3QgcmVhbGx5IGZsZXNoZWQgb3V0IGVub3VnaCB0byBiZSBpbXBs ZW1lbnRhYmxlLiBUaGUgc3RhdGUgbGlua2VkIGFib3ZlIHdhcyB0aGUgbGFzdCBzdGF0ZSBiZWZv cmUgbXkgcmV2aWV3LCBhbmQgdGhlIHdvcmQgInJlc3luYyIgZG9lc24ndCBhY3R1YWxseSBhcHBl YXIuIEluc3RlYWQgdGhlIFBSIHRhbGtzIGFib3V0ICJyZWNvdmVyaW5nIGxvc3QgZ3JvdXAgbWVt YmVycyIgdXNpbmcgQWRkIGFuZCBQU0ssIHdoaWNoIGNvdWxkIGJlIGVsYWJvcmF0ZWQgdG8gc29s dmUgYSB2ZXJzaW9uIG9mIHRoaXMgcHJvYmxlbSwgYnV0IHdvdWxkIHJlcXVpcmUgdGhlIGFzc2lz dGFuY2Ugb2YgYSBjb250aW51aW5nIG1lbWJlciByYXRoZXIgdGhhbiBhbGxvd2luZyB0aGUgbG9z dCBtZW1iZXIgdG8gcmVzeW5jIHVuaWxhdGVyYWxseS4gSXQgd291bGQgYWxzbyBoYXZlIHRoZSBz YW1lIGlzc3VlcyBub3RlZCBpbiB0ZXJtcyBvZiBuZXcgam9pbmVycyBub3QgaGF2aW5nIHJlc3lu YyBQU0tzLg0KPiA+DQo+ID4gIE92ZXJhbGwsIHRob3VnaCwgcmVhZGluZyB0aGlzIGhpc3Rvcnkg ZG9lc24ndCBzZWVtIHRvIG1lIGxpa2Ugd2UgcmVhbGx5IG1hZGUgYSBwcmluY2lwbGVkIGRlY2lz aW9uIG5vdCB0byBkbyByZXN5bmMuIFdlIGp1c3QgcHVudGVkIGFmdGVyIHNvbWUgZGlzY3Vzc2lv biBpbiB0aGUgYWJzdHJhY3QsIGFuZCB0aGF0IHN0dWNrLiBXZSBoYXZlIGEgbW9yZSBjb25jcmV0 ZSBxdWVzdGlvbiBub3cuDQo+ID4NCj4gPiAgIyBBbmFseXNpcw0KPiA+DQo+ID4gIFNpbmNlIHRo ZSBkaXNjdXNzaW9uIG9mICMzMzYgaW4gMjAyMCwgd2UgaGF2ZSBhZGRlZCBleHRlcm5hbCBjb21t aXRzIGluIG9yZGVyIHRvIGhhdmUgZ3JvdXBzIHlvdSBjYW4gam9pbiB1bmlsYXRlcmFsbHkuIFNv IHJlZ2FyZGxlc3Mgb2YgdGhlIGJyb2FkZXIgcXVlc3Rpb24gb2YgcmVzeW5jLCB3ZSBoYXZlIHRv IGRlY2lkZSB3aGF0IHByb3Bvc2FscyBhIGpvaW5lciBpcyBhbGxvd2VkIHRvIG9yaWdpbmF0ZSBp biB0aGVpciBDb21taXQgKHNlbmRpbmcgdGhlbSBieSB2YWx1ZSksIGluIHBhcnRpY3VsYXIsIHdo ZXRoZXIgYW4gZXh0ZXJuYWwgQ29tbWl0IGNhbiBjb250YWluIGEgam9pbmVyLW9yaWdpbmF0ZWQg UmVtb3ZlIHByb3Bvc2FsLiBXZSBoYXZlIGEgc3BlY3RydW0gb2Ygb3B0aW9ucyBoZXJlOg0KPiA+ DQo+ID4gIDEuIEZvcmJpZCBSZW1vdmUNCj4gPiAgMi4gQWxsb3cgUmVtb3ZlICsgcmVxdWlyZSB0 aGUgKGlkZW50aXR5LCBlbmRwb2ludF9pZCkgYW5kIHNpZ25hdHVyZSBrZXkgdG8gbWF0Y2ggdGhl IHJlbW92ZWQgbm9kZSArIHJlcXVpcmUgcmVzdW1wdGlvbiBQU0sNCj4gPiAgMy4gQWxsb3cgUmVt b3ZlICsgcmVxdWlyZSB0aGUgKGlkZW50aXR5LCBlbmRwb2ludF9pZCkgYW5kIHNpZ25hdHVyZSBr ZXkgdG8gbWF0Y2ggdGhlIHJlbW92ZWQgbm9kZQ0KPiA+ICA0LiBBbGxvdyBSZW1vdmUgd2l0aG91 dCByZXN0cmljdGlvbg0KPiA+DQo+ID4gIE9wdGlvbnMgKDEpIGFuZCAoMikgd291bGQgYmxvY2sg YW4gYXR0YWNrZXIgdGhhdCBoYXMgY29tcHJvbWlzZWQgYSBtZW1iZXIncyBzaWduYXR1cmUga2V5 IGZyb20gam9pbmluZyBhcyB0aGF0IG1lbWJlciBhbmQgZXZpY3RpbmcgdGhlIG9sZCBhcHBlYXJh bmNlLiBPcHRpb24gKDIpIGJlY2F1c2Ugb2YgdGhlIFBTSzsgb3B0aW9uICgxKSBiZWNhdXNlIG9m IHRoZSB1bmlxdWVuZXNzIHJlcXVpcmVtZW50cyAoYXMgUmFwaGFlbCBwb2ludGVkIG91dCBvbiB0 aGUgY2FsbCkuDQo+ID4NCj4gPiAgT3B0aW9ucyAoMSkgYW5kICgyKSBkbyBub3QgYWxsb3cgYSBj bGllbnQgd2hvIGhhcyBsb3N0IGV2ZXJ5dGhpbmcgYnV0IHRoZWlyIHNpZ25hdHVyZSBrZXkgdG8g cmVzeW5jLiBPcHRpb24gKDEpIHdvdWxkIHJlcXVpcmUgYSBuZXcgZW5kcG9pbnRfaWQgYW5kIHNp Z25hdHVyZSBrZXksIHdoaWNoIG1pZ2h0IG5vdCBiZSBmZWFzaWJsZSBpbiBhbGwgY2FzZXMuIE9w dGlvbiAoMikgd291bGQgYWxzbyBuZWVkIHRvIGhhdmUgZXh0cmEgbWVjaGFuaXNtIHRvIGFjY291 bnQgZm9yIHJlY2VudCBqb2luZXJzIG5vdCBoYXZpbmcgdGhlIHJlcXVpcmVkIHJlc3VtcHRpb24g UFNLLg0KPiA+DQo+ID4gIE9wdGlvbiAoMSkgd291bGQgYWxzbyBub3QgYWxsb3cgZm9yIHJlc3lu YyB3aXRoIGp1c3QgYSBzaWduYXR1cmUga2V5LiBBcyBSYXBoYWVsIHBvaW50ZWQgb3V0LCBiZWNh dXNlIHdlIG5vdyByZXF1aXJlIHNpZ25hdHVyZSBrZXlzIHRvIGJlIHVuaXF1ZSwgdGhlIG1lbWJl ciB3b3VsZCBoYXZlIHRvIG1pbnQgYSBuZXcgc2lnbmF0dXJlIGtleSBhbmQgZ2V0IGl0IGF1dGhl bnRpY2F0ZWQsIG9yIGVsc2UgdGhlaXIgYXR0ZW1wdCB0byByZWpvaW4gd291bGQgYmUgcmVqZWN0 ZWQgYXMgYSBkdXBsaWNhdGUgZW50cnkuDQo+ID4NCj4gPiAgT3B0aW9ucyAoMykgYW5kICg0KSB3 b3VsZCBhbGxvdyBhIGNsaWVudCB3aG8gaGFzIGxvc3QgZXZlcnl0aGluZyBidXQgdGhlaXIgc2ln bmF0dXJlIGtleSB0byByZXN5bmMsIGF0IHRoZSByaXNrIHRoYXQgYW4gYXR0YWNrZXIgd2hvIGhh cyBjb21wcm9taXNlZCBhIG1lbWJlcidzIHNpZ25hdHVyZSBrZXkgY291bGQgYWJ1c2UgaXQgdG8g am9pbiBhcyB0aGF0IG1lbWJlciBhbmQgZXZpY3QgdGhlIG9sZCwgbGVnaXRpbWF0ZSBhcHBlYXJh bmNlLg0KPiA+DQo+ID4gICMgUHJvZ25vc2lzDQo+ID4NCj4gPiAgQWZ0ZXIgdGhpcyBkaXNjdXNz aW9uIGFuZCBhbmFseXNpcywgSSBjb250aW51ZSB0byB0aGluayB0aGF0ICgzKSBhYm92ZSBpcyB0 aGUgcmlnaHQgYW5zd2VyLCB3aXRoIGFuIG9wdGlvbmFsIHVwZ2FkZSB0byAoMikuIFByb2NlZWRp bmcgYnkgZWxpbWluYXRpb246DQo+ID4NCj4gPiAgT3B0aW9uICg0KSwgd2hpbGUgdGVjaG5pY2Fs bHkgZmVhc2libGUsIGlzIGNsZWFybHkgYSBsaXR0bGUgc2lsbHkuIFRoZXJlJ3Mgbm8gcmVhc29u IHRvIGFsbG93IGpvaW5lcnMgdG8gZG8gYSByZW1vdmUgaW4gdGhlIHNhbWUgb3BlcmF0aW9uIGFz IHRoZXkgam9pbjsgdGhleSBjb3VsZCBkbyB0aGlzIGFmdGVyd2FyZC4NCj4gPg0KPiA+ICBPcHRp b24gKDIpIGRvZXMgbm90IHNlZW0gd29ya2FibGUgaW4gZ2VuZXJhbCBiZWNhdXNlIG9mIHRoZSBy ZWNlbnQtam9pbmVyIHByb2JsZW0uIFdoaWxlIG1lY2hhbmlzbSBjb3VsZCBiZSBkZXNpZ25lZCB0 byBwcm92aWRlIHRoZSBQU0sgdG8gcmVjZW50IGpvaW5lcnMsIGl0IHdvdWxkIGFkZCBhIGxvdCBv ZiBjb21wbGV4aXR5LCBhbmQgdGhlIHJlY2VudCBqb2luZXJzIHdvdWxkbid0IGdldCBhbnkgYmVu ZWZpdCBmcm9tIGl0LCB3aGljaCBkaWx1dGVzIHRoZSB2YWx1ZSBvZiB0aGlzIG1lY2hhbmlzbS4g KEl0J3Mgbm90IGltcG9zc2libGUgdG8gYXJyaXZlIGF0IHRoZSBjYXNlIHdoZXJlIGV2ZXJ5b25l IGJlc2lkZXMgdGhlIHJlc3luYydpbmcgcGFydGljaXBhbnQgaXMgbmV3ISkNCj4gPg0KPiA+ICBX aXRoIG9wdGlvbiAoMSksIHlvdSBsb3NlIGFueSBub3Rpb24gb2YgcmVzeW5jOyBJIHRoaW5rIHRo ZSBuZWVkIGZvciBlbmRwb2ludF9pZCByb3RhdGlvbiBtYWtlcyB0aGlzIHVud29ya2FibGUgaW4g cHJhY3RpY2UuIEFuZCBpdCBoYXMga2luZCBvZiBhbiBvZGQgbm90aW9uIG9mIHNlY3VyaXR5OiBZ b3UgYXJlIHByb3RlY3RlZCBhZ2FpbnN0IGFuIGF0dGFja2VyIHRoYXQgaGFzIGNvbXByb21pc2Vk IGEgY3VycmVudCBzaWduYXR1cmUga2V5IGJ1dCBjYW4ndCBnZXQgYSBuZXcgb25lIGF1dGhlbnRp Y2F0ZWQuIFRoaXMgaXMgYSBwcm9ibGVtIGZvciB0aGUgYXV0aGVudGljYXRpb24gc3lzdGVtIHRv IGhhbmRsZSAoZS5nLiwgd2l0aCByZXZvY2F0aW9uKSwgbm90IGZvciB0aGUga2V5IGV4Y2hhbmdl IC0tIGlmIHlvdSBoYXZlIHZhbGlkIGNyZWRlbnRpYWxzIHdpdGggY29tcHJvbWlzZWQga2V5cyBm bG9hdGluZyBhcm91bmQsIHlvdSBoYXZlIGJpZ2dlciBwcm9ibGVtcyB0byBzb2x2ZS4gU28gbXkg cGVyc29uYWwgYXNzZXNzbWVudCBpcyB0aGF0ICgxKSBkb2Vzbid0IHByb3ZpZGUgYSBiaWcganVt cCBpbiBzZWN1cml0eSBvdmVyICgzKSwgYXNzdW1pbmcgeW91IGhhdmUgYSBmdW5jdGlvbmluZyBh dXRoZW50aWNhdGlvbiBzeXN0ZW0uDQo+ID4NCj4gPiAgVHdvIHNpZGUgbm90ZXMgYWJvdXQgKDMp OiBGaXJzdCwgaWYgd2UgZG8gKDMpIGJ1dCAqYWxsb3cqIFBTS3MsIHRoZW4gYW4gYXBwbGljYXRp b24gY291bGQgb3B0IGluIHRvICgyKS4gU2Vjb25kLCB0aGlzIHdob2xlIG1lY2hhbmlzbSBpcyBv cHQtaW4gZm9yIHRoZSBhcHBsaWNhdGlvbiwgc2luY2UgeW91IGNhbid0IGRvIGFuIGV4dGVybmFs IGNvbW1pdCBpZiBhIFB1YmxpY0dyb3VwU3RhdGUgaGFzbid0IGJlZW4gcHVibGlzaGVkLg0KPiA+ DQo+ID4gIENvbmNyZXRlbHksIG15IHByb3Bvc2FsIGhlcmUgd291bGQgYmUgKDMpICsgKDIqKSAt LSBBbGxvdyBSZW1vdmUgd2l0aCBtYXRjaGluZyBwYXJhbWV0ZXJzLCBhbmQgYWxsb3cgUFNLcyBz byB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gb3B0IGluIHRvICgyKSB3aGVyZSB0aGV5IGNhbiBtYWtl IGl0IHdvcmsuIFRoYXQgd2F5LCBpZiBhbiBhcHBsaWNhdGlvbiBvcHRzIGluIHRvIGV4dGVybmFs IENvbW1pdHMsIHRoZXkgZ2V0IHRoZSBiZW5lZml0IG9mIHJlc3luYyBhbmQgdGhlIHNhbWUgc2ln bmF0dXJlLWtleS1jb21wcm9taXNlIGJvdW5kIG9uIGltcGVyc29uYXRpb24gZm9yIHJlc3luYyBh cyB3ZWxsIGFzIG5ldC1uZXcgam9pbnMuIEFuZCBpZiBhbiBhcHBsaWNhdGlvbiBjYW4gZmlndXJl IG91dCBob3cgdG8gbWFrZSAoMikgd29yaywgdGhleSBjYW4gcmVxdWlyZSBpdC4NCj4gPg0KPiA+ ICBMb29raW5nIGZvcndhcmQgdG8gb3RoZXJzJyB0aG91Z2h0cyBoZXJlIQ0KPiA+DQo+ID4gIC0t UkxCDQo+ID4NCj4gPg0KPiA+ICBbMV0gaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL3dnLW1hdGVy aWFscy9ibG9iL21haW4vaW50ZXJpbS0yMDE5LTAxL21pbnV0ZXMubWQjYWNrcy1hbmQtbmFja3Mt am9ubTxodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZ3Zy1tYXRlcmlhbHMlMkZibG9iJTJG bWFpbiUyRmludGVyaW0tMjAxOS0wMSUyRm1pbnV0ZXMubWQlMjNhY2tzLWFuZC1uYWNrcy1qb25t JmRhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3Q2ZmNzI5YTBlMjVmMjRhZjcy ODVhMDhkOTg5YmJmNTAyJTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdD MCU3QzYzNzY5MjI2MjYzOTcwMjI5OCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1D NHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0Ql N0MxMDAwJnNkYXRhPTF1cGNCWFNJM3AzallNOHI0MHh1TjdPMmd2WVBjTDMlMkZWOFhGbkxxUVJC dyUzRCZyZXNlcnZlZD0wPiAoaHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGd2ctbWF0ZXJp YWxzJTJGYmxvYiUyRm1haW4lMkZpbnRlcmltLTIwMTktMDElMkZtaW51dGVzLm1kJTIzYWNrcy1h bmQtbmFja3Mtam9ubSZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MxZWJm OTZjMzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5 NjMzNzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NDQ4MDglN0NVbmtub3duJTdDVFdGcGJHWnNi M2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxD SlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT0lMkJFcHJRTU9WayUyQklOaGR0UnhITDVKZkdRJTJG ZVA2dENGdmNBTTN1b3BNRnE0JTNEJnJlc2VydmVkPTA8aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1s c3dnJTJGd2ctbWF0ZXJpYWxzJTJGYmxvYiUyRm1haW4lMkZpbnRlcmltLTIwMTktMDElMkZtaW51 dGVzLm1kJTIzYWNrcy1hbmQtbmFja3Mtam9ubSZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0 MG5wcy5lZHUlN0NmZjcyOWEwZTI1ZjI0YWY3Mjg1YTA4ZDk4OWJiZjUwMiU3QzZkOTM2MjMxYTUx NzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTIyNjI2Mzk3MTIyOTIlN0NVbmtu b3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENK QlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT1hRFU1Z0JRckx0NEtWSXZs OWdvWTBsN0M2eElNVzhCUzdCWXNPYkVyRm1RJTNEJnJlc2VydmVkPTA+KQ0KPiA+ICBbMl0gaHR0 cHM6Ly9naXRodWIuY29tL21sc3dnL21scy1wcm90b2NvbC9pc3N1ZXMvOTI8aHR0cHM6Ly9uYW0x MC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0 aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTImZGF0YT0wNCU3QzAx JTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDZmY3MjlhMGUyNWYyNGFmNzI4NWEwOGQ5ODliYmY1 MDIlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkyMjYy NjM5NzEyMjkyJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENK UUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9 JTJCbEw1Q0Z0YXdGSzNSQVRQWk53aEclMkZtbHNyRktNQ1dDMUJGb2JpbWtuQ28lM0QmcmVzZXJ2 ZWQ9MD4gKGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUyRmlzc3Vl cyUyRjkyJmRhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzFlYmY5NmMzMGNj NDRmYzk2ZTFkMDhkOTg3OGJiNmI1JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUl N0MwJTdDMCU3QzYzNzY4OTg1NzkzMTg1NDgwMCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpX SWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZN bjAlM0QlN0MzMDAwJnNkYXRhPWxGZVl3eUhDR1psc0h6JTJCTzJjVlBHN2VVVFVqem9MaHpRMGZu aXolMkZibG1jJTNEJnJlc2VydmVkPTA8aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxz LXByb3RvY29sJTJGaXNzdWVzJTJGOTImZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMu ZWR1JTdDZmY3MjlhMGUyNWYyNGFmNzI4NWEwOGQ5ODliYmY1MDIlN0M2ZDkzNjIzMWE1MTc0MGVh OTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkyMjYyNjM5NzIyMjc5JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9UGJFS2hKY2NSRDZ4ZG1PTW1JWUx2 cEVRb3RvdWI4ZmNDTlBSb1NEUmtVbyUzRCZyZXNlcnZlZD0wPikNCj4gPiAgWzNdIGh0dHBzOi8v Z2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJvdG9jb2wvaXNzdWVzLzkzPGh0dHBzOi8vbmFtMTAuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5j b20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUyRmlzc3VlcyUyRjkzJmRhdGE9MDQlN0MwMSU3Q2Jy aXR0YS5oYWxlJTQwbnBzLmVkdSU3Q2ZmNzI5YTBlMjVmMjRhZjcyODVhMDhkOTg5YmJmNTAyJTdD NmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MjI2MjYzOTcz MjI3NyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9p VjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPVk2TTBo ckh5UklwRlBKQ244dGJDeHVJS0tsSCUyRndNOElLVUliMkJUZjhVRSUzRCZyZXNlcnZlZD0wPiAo aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTMm ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDMWViZjk2YzMwY2M0NGZjOTZl MWQwOGQ5ODc4YmI2YjUlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0Mw JTdDNjM3Njg5ODU3OTMxODU0ODAwJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0 d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3 QzMwMDAmc2RhdGE9enBXJTJCQ1F6JTJCZUV3a2xZYnA0TlFtRmNVZUhCR21BaDBqS0JSQzA1Q3lW QnMlM0QmcmVzZXJ2ZWQ9MDxodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9j b2wlMkZpc3N1ZXMlMkY5MyZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0Nm ZjcyOWEwZTI1ZjI0YWY3Mjg1YTA4ZDk4OWJiZjUwMiU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1 Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTIyNjI2Mzk3MzIyNzclN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT1ZNk0waHJIeVJJcEZQSkNuOHRiQ3h1SUtLbEgl MkZ3TThJS1VJYjJCVGY4VUUlM0QmcmVzZXJ2ZWQ9MD4pDQo+ID4gIFs0XSBodHRwczovL2dpdGh1 Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwvMzM2L2ZpbGVzLzIwMTQ1ZTQ5YWNjZTAxZGNl ZGNhN2RiMmQwNWM1NzkwOGEyOTIyMDI8aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxz LXByb3RvY29sJTJGcHVsbCUyRjMzNiUyRmZpbGVzJTJGMjAxNDVlNDlhY2NlMDFkY2VkY2E3ZGIy ZDA1YzU3OTA4YTI5MjIwMiZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0Nm ZjcyOWEwZTI1ZjI0YWY3Mjg1YTA4ZDk4OWJiZjUwMiU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1 Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTIyNjI2Mzk3NDIyNjglN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT04WSUyQmx4aTE4TVhtdEJXVFlNSXE2eWRpZ1cz N2VLSkh1ZWwlMkJMNHppdnh3cyUzRCZyZXNlcnZlZD0wPiAoaHR0cHM6Ly9uYW0xMC5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUy Rm1sc3dnJTJGbWxzLXByb3RvY29sJTJGcHVsbCUyRjMzNiUyRmZpbGVzJTJGMjAxNDVlNDlhY2Nl MDFkY2VkY2E3ZGIyZDA1YzU3OTA4YTI5MjIwMiZkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0 MG5wcy5lZHUlN0MxZWJmOTZjMzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUx NzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NjQ3OTQlN0NVbmtu b3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENK QlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZzZGF0YT0wT2dWZGRjJTJCSXpqdTYx TXdmUUZOaVlqZWpaSU50cklxZjA4Q2tJZ0dtJTJCUSUzRCZyZXNlcnZlZD0wPGh0dHBzOi8vbmFt MTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdp dGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUyRnB1bGwlMkYzMzYlMkZmaWxlcyUyRjIw MTQ1ZTQ5YWNjZTAxZGNlZGNhN2RiMmQwNWM1NzkwOGEyOTIyMDImZGF0YT0wNCU3QzAxJTdDYnJp dHRhLmhhbGUlNDBucHMuZWR1JTdDZmY3MjlhMGUyNWYyNGFmNzI4NWEwOGQ5ODliYmY1MDIlN0M2 ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkyMjYyNjM5NzQy MjY4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lW Mmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9OFklMkJs eGkxOE1YbXRCV1RZTUlxNnlkaWdXMzdlS0pIdWVsJTJCTDR6aXZ4d3MlM0QmcmVzZXJ2ZWQ9MD4p DQo+ID4gIFs1XSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL21scy9Ic19u QVgzbHVEamlRNG1Jd2tpS3UxQ0ZTQUUvPGh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZlLmlldGYub3JnJTJG YXJjaCUyRm1zZyUyRm1scyUyRkhzX25BWDNsdURqaVE0bUl3a2lLdTFDRlNBRSUyRiZkYXRhPTA0 JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0NmZjcyOWEwZTI1ZjI0YWY3Mjg1YTA4ZDk4 OWJiZjUwMiU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2 OTIyNjI2Mzk3NTIyNzElN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01E QWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZz ZGF0YT1mSTc0UEpFVTEzV2UwOVJqQ3I1SFduSWM2ZmVZQzRpRkxCQjhqaEIyM2pnJTNEJnJlc2Vy dmVkPTA+IChodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZtYWlsYXJjaGl2ZS5pZXRmLm9yZyUyRmFyY2glMkZtc2clMkZtbHMl MkZIc19uQVgzbHVEamlRNG1Jd2tpS3UxQ0ZTQUUlMkYmZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhh bGUlNDBucHMuZWR1JTdDMWViZjk2YzMwY2M0NGZjOTZlMWQwOGQ5ODc4YmI2YjUlN0M2ZDkzNjIz MWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3Njg5ODU3OTMxODc0Nzg5JTdD VW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJ aUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzMwMDAmc2RhdGE9bW9VQVpKM3RPQWhG SSUyQk1NRnE5OUIxMTF3SnB4QlJCd2JSUFlzNWxEeEMwJTNEJnJlc2VydmVkPTA8aHR0cHM6Ly9u YW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG bWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZhcmNoJTJGbXNnJTJGbWxzJTJGSHNfbkFYM2x1RGppUTRt SXdraUt1MUNGU0FFJTJGJmRhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3Q2Zm NzI5YTBlMjVmMjRhZjcyODVhMDhkOTg5YmJmNTAyJTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3 ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MjI2MjYzOTc1MjI3MSU3Q1Vua25vd24lN0NUV0ZwYkda c2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dp TENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPWZJNzRQSkVVMTNXZTA5UmpDcjVIV25JYzZmZVlD NGlGTEJCOGpoQjIzamclM0QmcmVzZXJ2ZWQ9MD4pDQo= --_000_484167A8836342E9816BE968784B1595npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <43B819EEFBD94A47A703521003C44DD1@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNlcnRhaW5seSwgUmljaGFyZC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnQgbGltaXRzIG9uZSBrZXkgdG8gZWFjaCB1 c2VyLiBVbmRlciBhbiBBZGQsIHRoZSBjcmVkZW50aWFsIGlkZW50aXR5IChub3QganVzdCBjcmVk ZW50aWFsKSBtdXN0IGJlIHVuaXF1ZSBhbmQgZGlmZmVyZW50IGZyb20gb3RoZXJzIGFscmVhZHkg aW4gdGhlIGdyb3VwLiBFeHRlcm5hbCBDb21taXRzIGFsc28gZGlzYWxsb3cgYSByZW1vdmUrYWRk IHVuZGVyIGEgZGlmZmVyZW50DQogY3JlZGVudGlhbCAod2hpY2ggaXMgYSBnb29kIHRoaW5nKS4g VGhpcyBiZWdzIHRoZSBxdWVzdGlvbiB0aG91Z2ggb2YgaG93IHRvIHJvdGF0ZSBvdXQgc2lnbmF0 dXJlIGtleXMuIEl0IHNlZW1zIHRoYXQgdGhlIHdheSB0byBkbyB0aGlzIHdvdWxkIGJlIGZvciB0 aGUgbWVtYmVyIHRvIHByb3Bvc2UgdG8gcmVtb3ZlIHRoZW1zZWx2ZXMgYW5kIHJlLWFkZCAodXNp bmcgdGhlIHVwZGF0ZWQgY3JlZGVudGlhbCkgYXMgb25lIGFjdGlvbiDigJMgb3RoZXJ3aXNlLA0K IGl0IGlzIG5vdCBjbGVhciBob3cgcm90YXRpbmcgc2lnbmF0dXJlIGtleXMgY2FuIGJlIHNtb290 aGx5IHBlcmZvcm1lZCB3aGlsZSBub3QgaW50ZXJmZXJpbmcgd2l0aCB0aGUgb3RoZXIgcmVzdHJp Y3Rpb25zLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoZSB2YXJpb3VzIGZlYXR1 cmVzIHRoYXQgaGF2ZSBiZWVuIGFkZGVkIGR1cmluZyByZWNlbnQgY2hhbmdlcyBhbmQgY3JlZGVu dGlhbC9pZGVudGl0eSByZXN0cmljdGlvbnMgb24gdGhlbSAoZS5nLiBFeHRlcm5hbCBDb21taXRz KSwgSSBwcm9wb3NlIHRoYXQgd2UgY2xlYXJseSBkZWxpbmVhdGUgaW4gdGhlIGRyYWZ0IGhvdyBy b2xsaW5nIGEgbWVtYmVy4oCZcyBjcmVkZW50aWFsIG1heSBiZSBwZXJmb3JtZWQuDQogVGhlIGRy YWZ0IGlzIGFwcHJvYWNoaW5nIHRoZSBwb2ludCB3aGVyZSBpdCBzdGF0ZXMgYSBtdWx0aXR1ZGUg b2Ygd2F5cyB0aGF0IGFjdGlvbiBtYXkgbm90IGJlIGRvbmUsIGJ1dCBkb2VzIG5vdCBnaXZlIGRp cmVjdGlvbiBvbiBob3cgaXQgbWF5IGJlIGRvbmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QnJpdHRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPlJpY2hhcmQgQmFybmVzICZsdDtybGJAaXB2LnN4Jmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5UaHVyc2RheSwgT2N0b2JlciA3LCAyMDIxIGF0IDEwOjU3IEFNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDtIYWxlLCBCcml0dGEgKENJVikmcXVvdDsgJmx0O2JyaXR0YS5oYWxlQG5wcy5lZHUm Z3Q7PGJyPg0KPGI+Q2M6IDwvYj5Lb25yYWQgS29oYnJvayAmbHQ7a29ucmFkLmtvaGJyb2tAZGF0 YXNocmluZS5kZSZndDssIE1lc3NhZ2luZyBMYXllciBTZWN1cml0eSBXRyAmbHQ7bWxzQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5TaWduYXR1cmUga2V5IHVuaXF1ZW5lc3MgYW5k IHJvdGF0aW9uIChSZTogW01MU10gUmVzeW5jIGFyY2hhZW9sb2d5ICsgYW5hbHlzaXMgKyBwcm9n bm9zaXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4oQ2hhbmdpbmcgc3ViamVjdCBsaW5lIGJlY2F1c2Ugd2UncmUgZGl2 ZXJnaW5nIGEgbGl0dGxlLi4uKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBCcml0dGEsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvdWxkIHlvdSBleHBsYWluIGEgbGl0dGxlIG1vcmUg aG93IHlvdSB0aGluayB0aGUgdW5pcXVlbmVzcyByZXF1aXJlbWVudHMgY291bGQgbWFrZSBpdCBt b3JlIGRpZmZpY3VsdCB0byByb3RhdGUgc2lnbmF0dXJlIGtleXM/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGRvZXNuJ3Qgc2VlbSB0byBt ZSBsaWtlIHRoZXJlJ3MgcmVhbGx5IGFueSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHNpZ25hdHVyZSBr ZXkgcm90YXRpb24gYW5kIGVpdGhlciBleHRlcm5hbCBjb21taXQgb3Igc2lnbmF0dXJlIGtleSB1 bmlxdWVuZXNzIHJlcXVpcmVtZW50cy4mbmJzcDsgVGhlIG9ubHkgaW50ZXJzZWN0aW9uIGlzIHRo YXQgdGhlIHJlcXVpcmVtZW50IHRoYXQgYSByZXN5bmMgb3BlcmF0aW9uIGhhdmUgdGhlDQogc2Ft ZSBzaWduYXR1cmUga2V5IG1lYW5zIHRoYXQgeW91IGNhbid0IHJvdGF0ZSB0aGUgc2lnbmF0dXJl IGtleSBhdCB0aGUgc2FtZSB0aW1lIHRoYXQgeW91IHJlc3luYy4mbmJzcDsgSG93ZXZlciwgeW91 IGNvdWxkIHNlbmQgYSBzZWNvbmQgY29tbWl0IHJvdGF0aW5nIHRoZSBzaWduYXR1cmUga2V5IGlt bWVkaWF0ZWx5IGFmdGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLVJpY2hhcmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9jdCA3LCAyMDIxIGF0IDE6NDYgUE0gSGFs ZSwgQnJpdHRhIChDSVYpICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdSI+ YnJpdHRhLmhhbGVAbnBzLmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQg c291bmRzIHJlYXNvbmFibGUgdG8gbWUgYXMgYSB3YXkgZm9yd2FyZC4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhlIHF1ZXN0aW9uIHBvc2VkIGJlZm9yZSAo4oCcVGhpcyBsZWFkcyB0 byBhbiBpbXBvcnRhbnQgcXVlc3Rpb246IGRvZXMgb3VyIGN1cnJlbnQgdW5pcXVlbmVzcyBvZiBz aWcga2V5IHByZWRpY2F0ZSBsaW1pdCB0aGUgYWJpbGl0eSB0byByb3RhdGUgc2lnbmF0dXJlIGtl eXMgd2l0aGluIGEgZ3JvdXA/IFRoYXQNCiDigKYgW2lzIHdoYXQgbGltaXRzXSB0aGUgZHJhd2Jh Y2tzIG9mICgzKS7igJ0pIHN0aWxsIHN0YW5kcy4gSSBkbyBub3QgdGhpbmsgdGhpcyBpbmhpYml0 cyBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBQUiwgYnV0IGl0IGlzIGltcG9ydGFudCB0byBhZGRy ZXNzLiBJZiB0aGVyZSBpcyBhIHRyYWRlLW9mZiBiZXR3ZWVuIGFuIGltcGxlbWVudGF0aW9uIGFs bG93aW5nIHJlbW92ZStyZXN5bmMgYW5kIHJvdGF0aW5nIG91dCBzaWduYXR1cmUga2V5cywgdGhl bg0KIHRoYXQgc2hvdWxkIGJlIG5vdGVkIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaWYg bm90IHRoZSBwcm90b2NvbCBzcGVjIGl0c2VsZi4gV2UgYXJlIG5vdCBnb2luZyB0byBnbyB0aHJv dWdoIGFsbCB0aGUgcG9zc2libGUgb3B0aW9ucyBmb3IgaW1wbGVtZW50YXRpb24sIGJ1dCB3aGVu IHRoZXJlIGlzIHNpZ25pZmljYW50IHNwYWNlIGluIHRoZSBwcm90b2NvbCBzcGVjIGRldm90ZWQg dG8gYW4gb3B0aW9uYWwgZnVuY3Rpb25hbGl0eSAoZS5nLg0KIGV4dGVybmFsIGNvbW1pdHMgYW5k IHJlc3luYykgdGhlbiBpdCB3b3VsZCBiZSBnb29kIHRvIG5vdGUgdHJhZGUtb2ZmcyB0aGF0IHdp bGwgY29tZSB3aXRoIGl0LiBXZSB3b3VsZCBub3QgaGF2ZSBhIHdlbGwtd3JpdHRlbiBzcGVjaWZp Y2F0aW9uIGlmIGl0IGNvdWxkIHBvdGVudGlhbGx5IGxlYWQgYW4gaW1wbGVtZW50b3IgZmFyIGRv d24gb25lIG9wdGlvbmFsIHBhdGggdGhhdCBwcmVjbHVkZXMgZGVzaXJlZCBzZWN1cml0eSBndWFy YW50ZWVzLA0KIGFuZCBnaXZlcyBubyBjb250ZXh0IG9uIHRoYXQgKGkuZS4gbGV04oCZcyB0cnkg dG8gbWluaW1pemUgb2J2aW91cyBjYXNlcyBvZiDigJxJIHdpc2ggSSBoYWQga25vd27igKbigJ0g Zm9yIGltcGxlbWVudG9ycykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Ccml0dGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPlJpY2hhcmQgQmFybmVzICZsdDs8YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCIgdGFy Z2V0PSJfYmxhbmsiPnJsYkBpcHYuc3g8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNk YXksIE9jdG9iZXIgNiwgMjAyMSBhdCA4OjU1IEFNPGJyPg0KPGI+VG86IDwvYj5Lb25yYWQgS29o YnJvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGUiIHRh cmdldD0iX2JsYW5rIj5rb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90O0hhbGUsIEJyaXR0YSAoQ0lWKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJyaXR0YS5oYWxlQG5wcy5lZHUiIHRhcmdldD0iX2JsYW5rIj5icml0dGEuaGFsZUBucHMu ZWR1PC9hPiZndDssIE1lc3NhZ2luZyBMYXllciBTZWN1cml0eSBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1sc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1sc0BpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTUxTXSBSZXN5bmMgYXJjaGFlb2xvZ3kgKyBhbmFseXNp cyArIHByb2dub3Npczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkndmUgdXBkYXRlZCB0aGUgUFIgdG8gZG8gYmFzaWNh bGx5IHdoYXQgS29ucmFkIHByb3Bvc2VzLiZuYnNwOyBOYW1lbHksIGFsbG93IFJlbW92ZSwgYnV0 IHN1Z2dlc3QgdGhhdCBhcHBsaWNhdGlvbnMgY2FuIGFwcGx5IGFkZGl0aW9uYWwgY29uc3RyYWlu dHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48YSBocmVmPSJodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wl MkZwdWxsJTJGNDgxJTJGZmlsZXMlMjNkaWZmLTdjMzY5Yjg1YjI2YTc0NmE3ZTcwY2QyODg0MDM3 ODk2ZGVmZTAzYjMwOThiZWM5NzZmNzljOTk0ZDIyYTYwNGFSMjg3MyZhbXA7ZGF0YT0wNCU3QzAx JTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDZmY3MjlhMGUyNWYyNGFmNzI4NWEwOGQ5ODliYmY1 MDIlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkyMjYy NjM5NzAyMjk4JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENK UUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3Nk YXRhPXlPMDdSbzM3NUN2dEVVUDgwZlpNVjIweUdlOTlYSnozM3ZTRmNqVjg2WTQlM0QmYW1wO3Jl c2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXBy b3RvY29sL3B1bGwvNDgxL2ZpbGVzI2RpZmYtN2MzNjliODViMjZhNzQ2YTdlNzBjZDI4ODQwMzc4 OTZkZWZlMDNiMzA5OGJlYzk3NmY3OWM5OTRkMjJhNjA0YVIyODczPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnJpdHRhLCBkb2Vz IHRoYXQgd29yayBmb3IgeW91PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBPY3QgNiwgMjAyMSBhdCAyOjA1IEFNIEtvbnJh ZCBLb2hicm9rICZsdDs8YSBocmVmPSJtYWlsdG86a29ucmFkLmtvaGJyb2tAZGF0YXNocmluZS5k ZSIgdGFyZ2V0PSJfYmxhbmsiPmtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkhpLDxicj4NCjxicj4NCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHRoZSBzb2x1dGlv bnMgKDIpIGFuZCAoMykgKGRpc2NhcmRpbmcgMSBhbmQgNCBmb3Igbm93KSByZXByZXNlbnQgdHJh ZGUtb2ZmcyBpbiBzZWN1cml0eSBndWFyYW50ZWVzIGFuZCB0aGVpciBhcHBsaWNhYmlsaXR5IGRl cGVuZHMgb24gdGhlIHNwZWNpZmljIGRlcGxveW1lbnQgc2NlbmFyaW8uIE15IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCBleHRlcm5hbCBqb2lucyB3aWxsIGJlIHN1YmplY3QgdG8gc29tZQ0KIHNvcnQg b2YgcG9saWN5IGFueXdheS4gU2hvdWxkIHdlIHRoZW4gYmUgc3RyaWN0IGluIHRoZSBzcGVjIGlu IHRlcm1zIG9mIHdoYXQgd2UgbWFuZGF0ZSB0aGUgZXhhY3QgcG9saWN5IHcuci50LiBQU0tzIGlz Pw0KPGJyPg0KPGJyPg0KU2luY2UgSSBkb24ndCB0aGluayBlaXRoZXIgc29sdXRpb24gcmVwcmVz ZW50cyBtdWNoIG9mIGEgZm9vdC1ndW4sIEkgcHJvcG9zZSB3ZSBpbmNsdWRlIHRoZSBjYXBhYmls aXR5IHRvIGluY2x1ZGUgcmVzeW5jIFBTS3MgaW4gdGhlIHNwZWMgZm9yIHRoaXMgcHVycG9zZSwg YnV0IGRvbid0IG1hbmRhdGUgdGhlbS4gSW5zdGVhZCB3ZSByZWxlZ2F0ZSB0aGUgcG9saWN5IGRl Y2lzaW9uIHRvIHRoZSBhcHBsaWNhdGlvbiBsYXllciBhbmQgZGV0YWlsIHRoZQ0KIHNlY3VyaXR5 IHRyYWRlLW9mZnMgaW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudC4gSSByZWFsaXplIHRoYXQg ZGVsZWdhdGluZyBkZWNpc2lvbnMgdG8gdGhlIGFwcGxpY2F0aW9uIGxheWVyIGlzIGEgYml0IG9m IGEgY29wLW91dCBzb2x1dGlvbiwgYnV0IEkgdGhpbmsgaW4gdGhpcyBjYXNlIGl0IG1ha2VzIHNl bnNlIHRvIGluY2x1ZGUgdGhlIG1lY2hhbmlzbSBpbiB0aGUgc3BlYyBhbmQgdGhlbiBsZXQgdGhl IGFwcGxpY2F0aW9uIGRlY2lkZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KS29ucmFkPGJyPg0K PGJyPg0KJmd0OyBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3gi IHRhcmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgaGF0IGFtIDA1LjEwLjIwMjEgMDQ6 MzEgZ2VzY2hyaWViZW46PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgQnJpdHRh LDxicj4NCiZndDsgPGJyPg0KJmd0OyBDb3VwbGUgb2YgcmVzcG9uc2VzIGlubGluZS4uLjxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIE1vbiwgT2N0IDQsIDIwMjEgYXQgODo0MiBQ TSBIYWxlLCBCcml0dGEgKENJVikgJmx0OzxhIGhyZWY9Im1haWx0bzpicml0dGEuaGFsZUBucHMu ZWR1IiB0YXJnZXQ9Il9ibGFuayI+YnJpdHRhLmhhbGVAbnBzLmVkdTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDsgJmd0OyBbdHJpbW1lZF08YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAm Z3Q7IFRvIHRoZSBwcmVzZW50IHByb3Bvc2VkIG9wdGlvbnMsIEkgd2lsbCBub3RlIHRoYXQgdGhl IOKAmG5ldyBqb2luZXJzIGluIGludGVyaW3igJkgY2FzZSBpcyBsaWtlbHkgYSBtaXNsZWFkaW5n IGZvY3VzIHBvaW50IGZvciB0aGUgZGlzY3Vzc2lvbiwgYW5kIHdlIHNob3VsZCBhdm9pZCB0cmlw cGluZyBpbnRvIHRoYXQgZGl0Y2ggZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnM6DQo8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7KiBOb3RhYmx5LCBpZiBldmVyeW9uZSBleGNlcHQgZm9yIHRoZSBy ZS1zeW5jaW5nIHBhcnRpY2lwYW50IGlzIG5ldywgd2h5IG5vdCBqdXN0IHJlcXVpcmUgdGhlIHJl LXN5bmNpbmcgcGFydGljaXBhbnQgdG8gYmUgYWRkZWQgYXMgYSBuZXcgbWVtYmVyIHRoZW1zZWx2 ZXM/IEl0IGlzLCBhZnRlciBhbGwsIHByYWN0aWNhbGx5IGEgYnJhbmQgbmV3IGdyb3VwIGF0IHRo YXQgcG9pbnQuDQo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7KiBJdCBpcyB0cnVlIHRoYXQg YSBuZXcgbWVtYmVyIHdvdWxkIG5vdCBnYWluIGZyb20gYSBQU0sgZ3VhcmFudGVlLCBidXQgd2h5 IHNob3VsZCB3ZSByZWR1Y2UgdGhlIGd1YXJhbnRlZXMgZm9yIGFsbCBvdGhlciBwYXJ0aWNpcGFu dHMgdG8gdGhhdCBvZiB0aGUgbmV3IGpvaW5lcj8gRnJvbSB0aGUgdmlldyBvZiB0aGUgbmV3IGpv aW5lciwgYWxsIHBhcnRpY2lwYW50cyBhcmUgbmV3IGluIGFueSBjYXNlLCBzbyBlLmcuIFBDUyBk b2VzIG5vdA0KIGhhdmUgc3Vic3RhbnRpYWwgbWVhbmluZyBhcyBvZiB5ZXQuIEV4aXN0aW5nIG1l bWJlcnMgaGF2ZSBtb3JlIHRvIGxvc2UgYW5kIGFsc28gaGF2ZSB0aGUgbW9yZSB0byBnYWluIGZy b20gUFNLIHVzZS4gSSBkbyBub3QgYmVsaWV2ZSB3ZSB3YW50IHRvIGFkYXB0IGEgc3RhbmNlIG9m IOKAmGlmIHRoZSBuZXcgam9pbmVyIGRvZXNu4oCZdCBnZXQgYSBzZWN1cml0eSBndWFyYW50ZWUs IG5vIG9uZSBzaG91bGQgaGF2ZSB0aGUgc2VjdXJpdHkgZ3VhcmFudGVl4oCZDQog4oCTIGluIGZh Y3QsIHRoZSB0cmVlIHN0cnVjdHVyZSwgY29tbWl0IGhpc3RvcnksIGFuZCB0aGUgbGlrZSBwcm92 aWRlIGluc2lnaHQgdG8gbG9uZ2VyIHRlcm0gbWVtYmVycyB0aGF0IGEgbmV3IGpvaW5lciBkb2Vz IG5vdCBoYXZlLiBTbyAoMikgb2ZmZXJzIGEgbmV3IGpvaW5lciB0aGUgYmVuZWZpdHMgb2YgKDMp IGJ1dCB0byBhbGwgb3RoZXJzIGFuIGV2ZW4gc3Ryb25nZXIgZ3VhcmFudGVlLg0KPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyogQXMgYSBub2QgdG8gd2hhdCBhIG5ldyBqb2luZXIgbWF5IGdh aW4sIHdlIGNhbiBvZmZlciB0aGUgZm9sbG93aW5nOiBpZiBhIHJlLXN5bmMgUFNLIGZhaWxzLCB0 aGVuIHdoaWNoZXZlciBleGlzdGluZyBtZW1iZXIgY2hlY2tzIGFuZCBub3RlcyB0aGUgUFNLIGZh aWx1cmUgc2hvdWxkIGluaXRpYXRlIGEgcmVtb3ZhbCBvZiB0aGUgcmVzeW5jaW5nIG1lbWJlci4g SWYgdGhlcmUgaXMgYSBuZXcgam9pbmVyLCB0aGVuIGJ5IGNvbnRpbnVlZA0KIHByZXNlbmNlIG9m IHRoZSByZS1zeW5jaW5nIG1lbWJlciB0aGV5IGdhaW4gdGhlIGd1YXJhbnRlZSB0aGF0IGF0IGxl YXN0IG9uZSBvdGhlciBncm91cCBtZW1iZXIgaGFzIHByZXZpb3VzbHkgc2VlbiB0aGF0IG1lbWJl ciwgb3IgZWxzZSB3b3VsZCBoYXZlIGVqZWN0ZWQgdGhlbSAoYXNzdW1pbmcgdGhhdCB0aGUgY2hl Y2tlciBpcyBvbmxpbmUpLjxicj4NCiZndDsgSSBkb24ndCBtZWFuIHRvIG92ZXItcm90YXRlIG9u IHRoaXMgY2FzZSwgYnV0IHNvZnR3YXJlIGJlaW5nIHNvZnR3YXJlLCB3ZSBuZWVkIGFuIGFsZ29y aXRobSB0byBpbXBsZW1lbnQgdGhhdCBjb3ZlcnMgYWxsIHRoZSBjYXNlcy4gV2hpbGUgdGhlICZx dW90O2V2ZXJ5b25lIGlzIG5ldyZxdW90OyBzY2VuYXJpbyBpcyBvdXRsYW5kaXNoLCBpdCB3b3Vs ZG4ndCBiZSBhbGwgdGhhdCBzdXJwcmlzaW5nIHRvIGhhdmUgb25lIG9yIHR3byBuZXcgbWVtYmVy cywgc28gaXQncw0KIGEgY2FzZSB0aGF0IHdvdWxkIG5lZWQgYWRkcmVzc2luZy4gVGhlIHNlZW1p bmdseSBtb3N0IG9idmlvdXMgYXBwcm9hY2ggdG8gYWRkcmVzc2luZyB0aGlzIHByb2JsZW0gaXMg dG8gZW5jcnlwdCB0aGUgUFNLIHRvIG5ldyBtZW1iZXJzLCB3aGljaCByZXF1aXJlcyB5b3UgYXQg bGVhc3QgaGF2ZSBlbm91Z2ggc3RhdGUgdG8gZmlndXJlIG91dCB3aG8gdGhlIG5ldyBtZW1iZXJz IGFyZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXQgYWxzbyBvY2N1cnMgdG8gbWUgbm93IHRoYXQg dGhlIFBTSyBhcHByb2FjaCBwcmVzdW1lcyB0aGF0IHlvdSBrbm93IHdoZW4geW91ciBzdGF0ZSB3 ZW50IGJhZCwgc2luY2UgeW91IHdvdWxkIHdhbnQgdG8gdXNlIGEgUFNLIGZyb20gYmVmb3JlIHRo YXQgcG9pbnQuIEluIFJhcGhhZWwncyBleGFtcGxlIHdoZXJlIHBlcnNpc3RlbnQgc3RvcmFnZSBp cyBjb3JydXB0ZWQsIGFsbCB5b3Uga25vdyBpcyB0aGF0IG1lc3NhZ2VzIHN0b3BwZWQgZGVjcnlw dGluZywNCiB3aGljaCBnaXZlcyB5b3UgYW4gdXBwZXIgYm91bmQgb24gdGhlIHRpbWUgb2YgY29y cnVwdGlvbiwgYnV0IG5vdCByZWFsbHkgYSB3YXkgdG8gZ28gYmFjayBhbmQgZmlndXJlIG91dCB3 aGF0J3MgZ29vZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBzZWN1 cml0eSBnb2FsIGluIHRoZSBiYWxhbmNlIGhlcmUgaXMgUENTLiBBZGRpbmcgYSByZS1zeW5jIG9w dGlvbiBvZiBhbnkgb2YgdGhlIHZhcmlldGllcyAoMiktKDQpIHdvdWxkIGJyZWFrIHRoYXQgdG8g c29tZSBkZWdyZWUsIHNpbmNlIGZvbGxvd2luZyBhIGNvbXByb21pc2UgYW5kIHBhc3NpdmUgcGVy aW9kIHRoZSBhZHZlcnNhcnkgaXMgdGhlbiBlbmFibGVkIHRvIHJlZ2FpbiBhIGZvb3Rob2xkLiBU aGUgcXVlc3Rpb24gaXMgaG93DQogbXVjaCBvZiBhIGRlZ3JlZSBvZiBsb3NzIGFyZSB3ZSB3aWxs aW5nIHRvIHRvbGVyYXRlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdtIG5vdCBzdXJlIEkgd291 bGQgcmVhbGx5IGNoYXJhY3Rlcml6ZSB0aGlzIGFzIGEgUENTIHZpb2xhdGlvbi4gUENTIGlzIGEg Z3VhcmFudGVlIHRoYXQgeW91IGdldCB3aGVuIHlvdSB0YWtlIGEgY2VydGFpbiBhY3Rpb24uIEZv ciBleGFtcGxlLCB3aGVuIGEgbWVtYmVyIGlzc3VlIGFuIFVwZGF0ZSBvciBhIENvbW1pdCB3aXRo IGEgZnJlc2ggSFBLRSBrZXkgcGFpciwgeW91IHNob3VsZCBnZXQgUENTIHdpdGggcmVnYXJkIHRv IHRoYXQgcGFydGljaXBhbnQncw0KIEhQS0Uga2V5IHBhaXI7IGxpa2V3aXNlIHdpdGggcm90YXRp bmcgc2lnbmF0dXJlIGtleXMuIEhlcmUsIHRoZSBzaWduYXR1cmUga2V5IGhhcyBub3QgYmVlbiBy b3RhdGVkLCBzbyB0aGVyZSdzIG5vIFBDUyBib3VuZGFyeS48YnI+DQomZ3Q7IDxicj4NCiZndDsg SXQgaXMgd29ydGggY29uc2lkZXJpbmcgd2hldGhlciB0aGlzIG1lY2hhbmlzbSBnaXZlcyB0aGUg YXR0YWNrZXIgYW55IGFkZGl0aW9uYWwgY2FwYWJpbGl0aWVzIGluIHRoZSBldmVudCB0aGF0ICgx KSB0aGUgc2lnbmF0dXJlIGtleSBpcyBjb21wcm9taXNlZCwgYW5kICgyKSB0aGUgY29tcHJvbWlz ZWQgbWVtYmVyIGlzc3VlcyBhbiBVcGRhdGUgb3IgQ29tbWl0IHJvdGF0aW5nIHRoZSBzaWduYXR1 cmUga2V5LiBJU1RNIHRoYXQgeW91IHN0aWxsDQogZ2V0IFBDUyB0aGVyZSBpbiBvcHRpb24gKDMp LCBzaW5jZSB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUgc2lnbmF0dXJlIGtleXMgbWF0Y2ggZW5z dXJlcyB0aGF0IHRoZSBvbGQsIGNvbXByb21pc2VkIHNpZ25hdHVyZSBrZXkgaXMgbm90IGFsbG93 ZWQgdG8gcmVzeW5jIGJhY2sgaW50byB0aGUgZ3JvdXAuIFRoZXJlJ3Mgc3RpbGwgYSByaXNrIHRo YXQgdGhlIGNvbXByb21pc2VkIGtleSAvIGNyZWRlbnRpYWwgY291bGQgYmUgdXNlZCBmb3IgYSBm cmVzaCwNCiBub24tcmVzeW5jIGpvaW4sIGJ1dCB0aGF0J3MgYW4gaW5oZXJlbnQgcmlzayB3aXRo IGV4dGVybmFsIENvbW1pdCAvIGZyZWVseSBqb2luYWJsZSBncm91cHMsIGFuZCBhbHNvIGFuIG9w cG9ydHVuaXR5IGZvciB0aGUgQVMncyByZXZvY2F0aW9uL2ludmFsaWRhdGlvbiBzeXN0ZW0gdG8g aGVscC48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2lsbCB0YWtlIGEgbG9vayBhdCB0aGUgcmVtYWlu ZGVyIGluIHRoZSBtb3JuaW5nLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tUkxCPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsqIEkgYWdyZWUgdGhhdCAo NCkgaXMgYW4gaW1tZWRpYXRlIGRpc2NhcmQuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyog VW5kZXIgKDIpIGEgUFNLIHVzZSwgdGhlIFBTSyB1c2UgYXQgbGVhc3QgbW9yZSBsaW1pdGVkIGR1 ZSB0byB0aGUgcHJvb2Ygb2Yga25vd2xlZGdlIG9mIGEgcGFzdCBzdGF0ZSAoZS5nLiBub3RlcyBh Ym92ZSkuIFRoaXMgaXMgYSB3b3J0aHdoaWxlIHByb3BlcnR5IHRvIGVuZm9yY2UgaW4gbXkgdmll dyBzaW5jZSBpdCBiYWxhbmNlcyBhdXRoZW50aWNhdGlvbiBhY3Jvc3MgdHdvIHZlY3RvcnM6IHRo ZSBzaWduYXR1cmUga2V5IGFuZCBrbm93bGVkZ2UNCiBvZiBncm91cCBzdGF0ZS4gQWR2ZXJzYXJ5 IGFjY2VzcyB0byBvbmx5IG9uZSBvciB0aGUgb3RoZXIgaXMgaW5zdWZmaWNpZW50IGZvciB0aGUg YWR2ZXJzYXJ5IHRvIGVqZWN0IEFsaWNlIGFuZCByZXBsYWNlIGhlciBpbiB0aGUgZ3JvdXAuDQo8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7KiBVbmRlciAoMyksIHRoZSBhdHRhY2sgc2NlbmFy aW8gb2YgRXZlIGNvbXByb21pc2luZyBBbGljZSAoZnVsbCBzdGF0ZSArIHNpZyBrZXkpLCBmb2xs b3dlZCBldmVudHVhbGx5KiBieSByZW1vdmluZyBBbGljZSB3aGlsZSBhZGRpbmcgaGVyc2VsZiwg aXMgbm90IGRpc3NpbWlsYXIgZnJvbSB0aGUgYXR0YWNrIHNjZW5hcmlvIG9mIEV2ZSBjb21wcm9t aXNpbmcgQWxpY2UgZnVsbCBzdGF0ZSArIHNpZyBrZXkpIGZvbGxvd2VkIGV2ZW50dWFsbHkqDQog YnkgcHJvdmlkaW5nIGFuIGltcGVyc29uYXRpbmcgdXBkYXRlIGluIEFsaWNl4oCZcyBuYW1lLiBX aGF0IGhhcyBiZWVuIHNob3duIHNvIGZhciBpcyB0aGF0IHRoaXMgdHlwZSBvZiBzY2VuYXJpbyBj YW4gYmUgbGltaXRlZCBieSByb3RhdGluZyBzaWduYXR1cmUga2V5cy4gQSBpbXBvcnRhbnQgcG9p bnQgdGhhdCBpcyBkaWZmZXJlbnQgaW4gdGhlc2Ugc2NlbmFyaW9zIGlzIHRoYXQgdW5kZXIgdGhl IGZpcnN0IEFsaWNlIGtub3dzIHNoZSB3YXMgcmVtb3ZlZA0KIChhIHBsdXMpIHdoaWxlIHVuZGVy IHRoZSBzZWNvbmQgKGN1cnJlbnRseSBwb3NzaWJsZSkgc2NlbmFyaW8gdGhlIGdyb3VwIHNpbXBs eSBnb2VzIHNpbGVudCBhbmQgQWxpY2UgZG9lcyBub3Qga25vdyBpZiBpdCB3YXMgbWFsaWNpb3Vz IG9yIG5vdC4gQWxsIHNhaWQsIGl0IGNvdWxkIGJlIHdvcnNlLiBUaGF0IGRvZXMgbm90IGNvbnNp ZGVyIG90aGVyIGF0dGFjayBzY2VuYXJpb3MgdGhvdWdoLCBmb3IgZXhhbXBsZSB3aGVuIHRoZSBh dHRhY2tlcg0KIGdhaW5zIHRoZSBzaWduYXR1cmUga2V5IGJ1dCBub3QgcGFzdCBzdGF0ZS9QU0su IDxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgKkkuZS4gYWZ0ZXIgYSBwb3Rl bnRpYWxseSBwYXNzaXZlIHBlcmlvZCwgaWYgd2UgYXJlIHRvIHNob3cgaG93IHRoaXMgYmVoYXZl cyBpbiB0aGUgUENTIHNjZW5hcmlvLjxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZn dDsgVGhpcyBsZWFkcyB0byBhbiBpbXBvcnRhbnQgcXVlc3Rpb246IGRvZXMgb3VyIGN1cnJlbnQg dW5pcXVlbmVzcyBvZiBzaWcga2V5IHByZWRpY2F0ZSBsaW1pdCB0aGUgYWJpbGl0eSB0byByb3Rh dGUgc2lnbmF0dXJlIGtleXMgd2l0aGluIGEgZ3JvdXA/IFRoYXQgaXMgb3VyIG1lYW5zIG9mIGxp bWl0aW5nIHRoZSBmdWxsIHN0YXRlICsgc2lnIGtleSBjb21wcm9taXNlIHNjZW5hcmlvIGltcGFj dHMgbWVudGlvbmVkIGFib3ZlLCBhbmQgdGhlcmVmb3JlDQogdGhlIG1lYW5zIG9mIGxpbWl0aW5n IHRoZSBkcmF3YmFja3Mgb2YgKDMpLiBXZSBzaG91bGQgbWFrZSBzdXJlIHRoYXQgdGhlIGxpbWl0 aW5nIGFiaWxpdHkgaXMgZmVhc2libGUuIElmIHRoYXQgaGluZGVyZWQgaW4gYW55IHdheSwgdGhl biBJIHdvdWxkIHZvdGUgdmVyeSBzdHJvbmdseSBmb3IgKDIpIGFzIGl0IGF0IGxlYXN0IGJvb3Rz dHJhcHMgc29tZSBvZiB0aGUgYXV0aGVudGljYXRpb24gcHJvcGVydGllcyBmcm9tIHRoZSBncm91 cCBzdGF0ZQ0KIGluIHRoZSBzY2VuYXJpbyB0aGF0IHRoZSBzaWcga2V5IGlzIGNvbXByb21pc2Vk Ljxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAm Z3Q7IEFsbCB0aGUgYmVzdCw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IEJy aXR0YTxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsgJmd0OyBGcm9tOk1MUyAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1scy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWxzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgUmljaGFyZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0 bzpybGJAaXB2LnN4IiB0YXJnZXQ9Il9ibGFuayI+cmxiQGlwdi5zeDwvYT4mZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7IERhdGU6TW9uZGF5LCBPY3RvYmVyIDQsIDIwMjEgYXQgNDowOSBQTTxicj4N CiZndDsgJmd0OyZuYnNwOyBUbzpNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgV0cgJmx0OzxhIGhy ZWY9Im1haWx0bzptbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyBTdWJqZWN0OltNTFNdIFJlc3luYyBhcmNoYWVvbG9n eSArIGFuYWx5c2lzICsgcHJvZ25vc2lzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsg Jmd0OyBPSywgSSB0aGluayBJIGhhdmUgdHJhY2VkIGJhY2sgc29tZSBpZGVhIG9mIHdoeSB3ZSBy ZW1vdmVkIHRoZSBlYXJsaWVyIHJlc3luYyBwcm9wb3NhbC4gSGVyZSdzIGEgbGl0dGxlIGVzc2F5 IG9uIGhvdyB3ZSBnb3QgaGVyZSwgYSByZWNhcCBvZiB0aGUgdHJhZGUtb2ZmcywgYW5kIG15IHRo b3VnaHRzIG9uIHdoZXJlIHdlIHNob3VsZCBnby48YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0K Jmd0OyAmZ3Q7IHRsO2RyOiBFYXJsaWVyIGRlY2lzaW9uIG5vdCBkaXNwb3NpdGl2ZTsgd2Ugc2hv dWxkIGRvIGJhc2ljYWxseSB3aGF0J3MgaW4gdGhlIFBSIG5vdy48YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICMgSGlzdG9yeTxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQom Z3Q7ICZndDsmbmJzcDsgVGhlIHN0b3J5IHN0YXJ0cyBhbGwgdGhlIHdheSBiYWNrIGF0IHRoZSBK YW51YXJ5IDIwMTkgaW50ZXJpbSBhdCBNb3ppbGxhIC8gTW91bnRhaW4gVmlldy4gVGhlcmUgd2Fz IGEgZGlzY3Vzc2lvbiB0aGVyZSBvZiBBQ0svTkFDSyBhbmQgcmVwbGF5IGFzIHJlbGF0ZWQgaXNz dWVzIFsxXS4gVGhhdCBkaXNjdXNzaW9uIHNlZW1zIHRvIGhhdmUgbGVkIHRvIGFncmVlbWVudCB0 aGF0IGEgY29tcGxldGUgZXJyb3IgcmVjb3Zlcnkgc3lzdGVtIHdhcw0KIGEgY29tcGxleCBlbm91 Z2ggdG9waWMsIGFuZCBjbGVhcmx5IGVub3VnaCBzZXBhcmF0ZWQgZnJvbSB0aGUgbWFpbiBwcm90 b2NvbCB0aGF0IGl0IGNvdWxkIGJlIGhhbmRsZWQgaW4gYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9u LiBBcyBhIHJlc3VsdCwgdGhlIGlzc3VlcyB0aGF0IGhhZCBiZWVuIG9wZW5lZCBmb3IgQUNLL05B Q0sgYW5kIHJlc3luYyB3ZXJlIGNsb3NlZCBbMl1bM10uIFdoZW4gQnJpdHRhIGFuZCBLb25yYWQg cG9zdGVkICMzMzYgWzRdDQogaW5jbHVkaW5nIGEgcmVzeW5jIG1lY2hhbmlzbSwgbXkgcmV2aWV3 IHNpbXBseSBjaXRlZCB0aGF0IGVhcmxpZXIgY2xvc2VkIGlzc3VlIGFzIGEgcmVhc29uIGZvciB0 YWtpbmcgaXQgb3V0IFs1XS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7IE9uZSBvdGhlciBub3RlIHdpdGggcmVnYXJkIHRvICMzMzYgLS0gSXQgbG9va3MgdG8gbWUg bGlrZSB0aGUgJnF1b3Q7cmVzeW5jJnF1b3Q7IG1lY2hhbmlzbSBpbiB0aGVyZSB3YXMgbm90IHJl YWxseSBmbGVzaGVkIG91dCBlbm91Z2ggdG8gYmUgaW1wbGVtZW50YWJsZS4gVGhlIHN0YXRlIGxp bmtlZCBhYm92ZSB3YXMgdGhlIGxhc3Qgc3RhdGUgYmVmb3JlIG15IHJldmlldywgYW5kIHRoZSB3 b3JkICZxdW90O3Jlc3luYyZxdW90OyBkb2Vzbid0IGFjdHVhbGx5IGFwcGVhci4NCiBJbnN0ZWFk IHRoZSBQUiB0YWxrcyBhYm91dCAmcXVvdDtyZWNvdmVyaW5nIGxvc3QgZ3JvdXAgbWVtYmVycyZx dW90OyB1c2luZyBBZGQgYW5kIFBTSywgd2hpY2ggY291bGQgYmUgZWxhYm9yYXRlZCB0byBzb2x2 ZSBhIHZlcnNpb24gb2YgdGhpcyBwcm9ibGVtLCBidXQgd291bGQgcmVxdWlyZSB0aGUgYXNzaXN0 YW5jZSBvZiBhIGNvbnRpbnVpbmcgbWVtYmVyIHJhdGhlciB0aGFuIGFsbG93aW5nIHRoZSBsb3N0 IG1lbWJlciB0byByZXN5bmMgdW5pbGF0ZXJhbGx5Lg0KIEl0IHdvdWxkIGFsc28gaGF2ZSB0aGUg c2FtZSBpc3N1ZXMgbm90ZWQgaW4gdGVybXMgb2YgbmV3IGpvaW5lcnMgbm90IGhhdmluZyByZXN5 bmMgUFNLcy48YnI+DQomZ3Q7ICZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IE92ZXJh bGwsIHRob3VnaCwgcmVhZGluZyB0aGlzIGhpc3RvcnkgZG9lc24ndCBzZWVtIHRvIG1lIGxpa2Ug d2UgcmVhbGx5IG1hZGUgYSBwcmluY2lwbGVkIGRlY2lzaW9uIG5vdCB0byBkbyByZXN5bmMuIFdl IGp1c3QgcHVudGVkIGFmdGVyIHNvbWUgZGlzY3Vzc2lvbiBpbiB0aGUgYWJzdHJhY3QsIGFuZCB0 aGF0IHN0dWNrLiBXZSBoYXZlIGEgbW9yZSBjb25jcmV0ZSBxdWVzdGlvbiBub3cuPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAjIEFuYWx5c2lzPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZuYnNwOyBTaW5jZSB0aGUgZGlzY3Vzc2lvbiBvZiAj MzM2IGluIDIwMjAsIHdlIGhhdmUgYWRkZWQgZXh0ZXJuYWwgY29tbWl0cyBpbiBvcmRlciB0byBo YXZlIGdyb3VwcyB5b3UgY2FuIGpvaW4gdW5pbGF0ZXJhbGx5LiBTbyByZWdhcmRsZXNzIG9mIHRo ZSBicm9hZGVyIHF1ZXN0aW9uIG9mIHJlc3luYywgd2UgaGF2ZSB0byBkZWNpZGUgd2hhdCBwcm9w b3NhbHMgYSBqb2luZXIgaXMgYWxsb3dlZCB0byBvcmlnaW5hdGUgaW4gdGhlaXIgQ29tbWl0IChz ZW5kaW5nDQogdGhlbSBieSB2YWx1ZSksIGluIHBhcnRpY3VsYXIsIHdoZXRoZXIgYW4gZXh0ZXJu YWwgQ29tbWl0IGNhbiBjb250YWluIGEgam9pbmVyLW9yaWdpbmF0ZWQgUmVtb3ZlIHByb3Bvc2Fs LiBXZSBoYXZlIGEgc3BlY3RydW0gb2Ygb3B0aW9ucyBoZXJlOjxicj4NCiZndDsgJmd0OyZuYnNw OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgMS4gRm9yYmlkIFJlbW92ZSA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgMi4gQWxsb3cgUmVtb3ZlICsgcmVxdWlyZSB0aGUgKGlkZW50aXR5LCBlbmRwb2ludF9p ZCkgYW5kIHNpZ25hdHVyZSBrZXkgdG8gbWF0Y2ggdGhlIHJlbW92ZWQgbm9kZSArIHJlcXVpcmUg cmVzdW1wdGlvbiBQU0s8YnI+DQomZ3Q7ICZndDsmbmJzcDsgMy4gQWxsb3cgUmVtb3ZlICsgcmVx dWlyZSB0aGUgKGlkZW50aXR5LCBlbmRwb2ludF9pZCkgYW5kIHNpZ25hdHVyZSBrZXkgdG8gbWF0 Y2ggdGhlIHJlbW92ZWQgbm9kZTxicj4NCiZndDsgJmd0OyZuYnNwOyA0LiBBbGxvdyBSZW1vdmUg d2l0aG91dCByZXN0cmljdGlvbjxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgT3B0aW9ucyAoMSkgYW5kICgyKSB3b3VsZCBibG9jayBhbiBhdHRhY2tlciB0aGF0IGhh cyBjb21wcm9taXNlZCBhIG1lbWJlcidzIHNpZ25hdHVyZSBrZXkgZnJvbSBqb2luaW5nIGFzIHRo YXQgbWVtYmVyIGFuZCBldmljdGluZyB0aGUgb2xkIGFwcGVhcmFuY2UuIE9wdGlvbiAoMikgYmVj YXVzZSBvZiB0aGUgUFNLOyBvcHRpb24gKDEpIGJlY2F1c2Ugb2YgdGhlIHVuaXF1ZW5lc3MgcmVx dWlyZW1lbnRzIChhcyBSYXBoYWVsIHBvaW50ZWQNCiBvdXQgb24gdGhlIGNhbGwpLjxicj4NCiZn dDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgT3B0aW9ucyAoMSkgYW5kICgyKSBk byBub3QgYWxsb3cgYSBjbGllbnQgd2hvIGhhcyBsb3N0IGV2ZXJ5dGhpbmcgYnV0IHRoZWlyIHNp Z25hdHVyZSBrZXkgdG8gcmVzeW5jLiBPcHRpb24gKDEpIHdvdWxkIHJlcXVpcmUgYSBuZXcgZW5k cG9pbnRfaWQgYW5kIHNpZ25hdHVyZSBrZXksIHdoaWNoIG1pZ2h0IG5vdCBiZSBmZWFzaWJsZSBp biBhbGwgY2FzZXMuIE9wdGlvbiAoMikgd291bGQgYWxzbyBuZWVkIHRvIGhhdmUgZXh0cmEgbWVj aGFuaXNtDQogdG8gYWNjb3VudCBmb3IgcmVjZW50IGpvaW5lcnMgbm90IGhhdmluZyB0aGUgcmVx dWlyZWQgcmVzdW1wdGlvbiBQU0suPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0 OyZuYnNwOyBPcHRpb24gKDEpIHdvdWxkIGFsc28gbm90IGFsbG93IGZvciByZXN5bmMgd2l0aCBq dXN0IGEgc2lnbmF0dXJlIGtleS4gQXMgUmFwaGFlbCBwb2ludGVkIG91dCwgYmVjYXVzZSB3ZSBu b3cgcmVxdWlyZSBzaWduYXR1cmUga2V5cyB0byBiZSB1bmlxdWUsIHRoZSBtZW1iZXIgd291bGQg aGF2ZSB0byBtaW50IGEgbmV3IHNpZ25hdHVyZSBrZXkgYW5kIGdldCBpdCBhdXRoZW50aWNhdGVk LCBvciBlbHNlIHRoZWlyIGF0dGVtcHQgdG8gcmVqb2luDQogd291bGQgYmUgcmVqZWN0ZWQgYXMg YSBkdXBsaWNhdGUgZW50cnkuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZu YnNwOyBPcHRpb25zICgzKSBhbmQgKDQpIHdvdWxkIGFsbG93IGEgY2xpZW50IHdobyBoYXMgbG9z dCBldmVyeXRoaW5nIGJ1dCB0aGVpciBzaWduYXR1cmUga2V5IHRvIHJlc3luYywgYXQgdGhlIHJp c2sgdGhhdCBhbiBhdHRhY2tlciB3aG8gaGFzIGNvbXByb21pc2VkIGEgbWVtYmVyJ3Mgc2lnbmF0 dXJlIGtleSBjb3VsZCBhYnVzZSBpdCB0byBqb2luIGFzIHRoYXQgbWVtYmVyIGFuZCBldmljdCB0 aGUgb2xkLCBsZWdpdGltYXRlIGFwcGVhcmFuY2UuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4N CiZndDsgJmd0OyZuYnNwOyAjIFByb2dub3Npczxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQom Z3Q7ICZndDsmbmJzcDsgQWZ0ZXIgdGhpcyBkaXNjdXNzaW9uIGFuZCBhbmFseXNpcywgSSBjb250 aW51ZSB0byB0aGluayB0aGF0ICgzKSBhYm92ZSBpcyB0aGUgcmlnaHQgYW5zd2VyLCB3aXRoIGFu IG9wdGlvbmFsIHVwZ2FkZSB0byAoMikuIFByb2NlZWRpbmcgYnkgZWxpbWluYXRpb246PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZuYnNwOyBPcHRpb24gKDQpLCB3aGlsZSB0 ZWNobmljYWxseSBmZWFzaWJsZSwgaXMgY2xlYXJseSBhIGxpdHRsZSBzaWxseS4gVGhlcmUncyBu byByZWFzb24gdG8gYWxsb3cgam9pbmVycyB0byBkbyBhIHJlbW92ZSBpbiB0aGUgc2FtZSBvcGVy YXRpb24gYXMgdGhleSBqb2luOyB0aGV5IGNvdWxkIGRvIHRoaXMgYWZ0ZXJ3YXJkLjxicj4NCiZn dDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgT3B0aW9uICgyKSBkb2VzIG5vdCBz ZWVtIHdvcmthYmxlIGluIGdlbmVyYWwgYmVjYXVzZSBvZiB0aGUgcmVjZW50LWpvaW5lciBwcm9i bGVtLiBXaGlsZSBtZWNoYW5pc20gY291bGQgYmUgZGVzaWduZWQgdG8gcHJvdmlkZSB0aGUgUFNL IHRvIHJlY2VudCBqb2luZXJzLCBpdCB3b3VsZCBhZGQgYSBsb3Qgb2YgY29tcGxleGl0eSwgYW5k IHRoZSByZWNlbnQgam9pbmVycyB3b3VsZG4ndCBnZXQgYW55IGJlbmVmaXQgZnJvbSBpdCwgd2hp Y2gNCiBkaWx1dGVzIHRoZSB2YWx1ZSBvZiB0aGlzIG1lY2hhbmlzbS4gKEl0J3Mgbm90IGltcG9z c2libGUgdG8gYXJyaXZlIGF0IHRoZSBjYXNlIHdoZXJlIGV2ZXJ5b25lIGJlc2lkZXMgdGhlIHJl c3luYydpbmcgcGFydGljaXBhbnQgaXMgbmV3ISkNCjxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgV2l0aCBvcHRpb24gKDEpLCB5b3UgbG9zZSBhbnkgbm90aW9uIG9m IHJlc3luYzsgSSB0aGluayB0aGUgbmVlZCBmb3IgZW5kcG9pbnRfaWQgcm90YXRpb24gbWFrZXMg dGhpcyB1bndvcmthYmxlIGluIHByYWN0aWNlLiBBbmQgaXQgaGFzIGtpbmQgb2YgYW4gb2RkIG5v dGlvbiBvZiBzZWN1cml0eTogWW91IGFyZSBwcm90ZWN0ZWQgYWdhaW5zdCBhbiBhdHRhY2tlciB0 aGF0IGhhcyBjb21wcm9taXNlZCBhIGN1cnJlbnQgc2lnbmF0dXJlIGtleQ0KIGJ1dCBjYW4ndCBn ZXQgYSBuZXcgb25lIGF1dGhlbnRpY2F0ZWQuIFRoaXMgaXMgYSBwcm9ibGVtIGZvciB0aGUgYXV0 aGVudGljYXRpb24gc3lzdGVtIHRvIGhhbmRsZSAoZS5nLiwgd2l0aCByZXZvY2F0aW9uKSwgbm90 IGZvciB0aGUga2V5IGV4Y2hhbmdlIC0tIGlmIHlvdSBoYXZlIHZhbGlkIGNyZWRlbnRpYWxzIHdp dGggY29tcHJvbWlzZWQga2V5cyBmbG9hdGluZyBhcm91bmQsIHlvdSBoYXZlIGJpZ2dlciBwcm9i bGVtcyB0byBzb2x2ZS4gU28NCiBteSBwZXJzb25hbCBhc3Nlc3NtZW50IGlzIHRoYXQgKDEpIGRv ZXNuJ3QgcHJvdmlkZSBhIGJpZyBqdW1wIGluIHNlY3VyaXR5IG92ZXIgKDMpLCBhc3N1bWluZyB5 b3UgaGF2ZSBhIGZ1bmN0aW9uaW5nIGF1dGhlbnRpY2F0aW9uIHN5c3RlbS48YnI+DQomZ3Q7ICZn dDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IFR3byBzaWRlIG5vdGVzIGFib3V0ICgzKTog Rmlyc3QsIGlmIHdlIGRvICgzKSBidXQgKmFsbG93KiBQU0tzLCB0aGVuIGFuIGFwcGxpY2F0aW9u IGNvdWxkIG9wdCBpbiB0byAoMikuIFNlY29uZCwgdGhpcyB3aG9sZSBtZWNoYW5pc20gaXMgb3B0 LWluIGZvciB0aGUgYXBwbGljYXRpb24sIHNpbmNlIHlvdSBjYW4ndCBkbyBhbiBleHRlcm5hbCBj b21taXQgaWYgYSBQdWJsaWNHcm91cFN0YXRlIGhhc24ndCBiZWVuIHB1Ymxpc2hlZC48YnI+DQom Z3Q7ICZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IENvbmNyZXRlbHksIG15IHByb3Bv c2FsIGhlcmUgd291bGQgYmUgKDMpICsgKDIqKSAtLSBBbGxvdyBSZW1vdmUgd2l0aCBtYXRjaGlu ZyBwYXJhbWV0ZXJzLCBhbmQgYWxsb3cgUFNLcyBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gb3B0 IGluIHRvICgyKSB3aGVyZSB0aGV5IGNhbiBtYWtlIGl0IHdvcmsuIFRoYXQgd2F5LCBpZiBhbiBh cHBsaWNhdGlvbiBvcHRzIGluIHRvIGV4dGVybmFsIENvbW1pdHMsIHRoZXkgZ2V0IHRoZSBiZW5l Zml0DQogb2YgcmVzeW5jIGFuZCB0aGUgc2FtZSBzaWduYXR1cmUta2V5LWNvbXByb21pc2UgYm91 bmQgb24gaW1wZXJzb25hdGlvbiBmb3IgcmVzeW5jIGFzIHdlbGwgYXMgbmV0LW5ldyBqb2lucy4g QW5kIGlmIGFuIGFwcGxpY2F0aW9uIGNhbiBmaWd1cmUgb3V0IGhvdyB0byBtYWtlICgyKSB3b3Jr LCB0aGV5IGNhbiByZXF1aXJlIGl0Ljxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgTG9va2luZyBmb3J3YXJkIHRvIG90aGVycycgdGhvdWdodHMgaGVyZSE8YnI+DQom Z3Q7ICZndDsmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IC0tUkxCPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7IDxicj4NCiZndDsgJmd0OyZuYnNwOyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgWzFdIDxh IGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRndnLW1hdGVyaWFscyUyRmJsb2Il MkZtYWluJTJGaW50ZXJpbS0yMDE5LTAxJTJGbWludXRlcy5tZCUyM2Fja3MtYW5kLW5hY2tzLWpv bm0mYW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3Q2ZmNzI5YTBlMjVm MjRhZjcyODVhMDhkOTg5YmJmNTAyJTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUl N0MwJTdDMCU3QzYzNzY5MjI2MjYzOTcwMjI5OCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpX SWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZN bjAlM0QlN0MxMDAwJmFtcDtzZGF0YT0xdXBjQlhTSTNwM2pZTThyNDB4dU43TzJndllQY0wzJTJG VjhYRm5McVFSQnclM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v Z2l0aHViLmNvbS9tbHN3Zy93Zy1tYXRlcmlhbHMvYmxvYi9tYWluL2ludGVyaW0tMjAxOS0wMS9t aW51dGVzLm1kI2Fja3MtYW5kLW5hY2tzLWpvbm08L2E+ICg8YSBocmVmPSJodHRwczovL25hbTEw LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRo dWIuY29tJTJGbWxzd2clMkZ3Zy1tYXRlcmlhbHMlMkZibG9iJTJGbWFpbiUyRmludGVyaW0tMjAx OS0wMSUyRm1pbnV0ZXMubWQlMjNhY2tzLWFuZC1uYWNrcy1qb25tJmFtcDtkYXRhPTA0JTdDMDEl N0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0NmZjcyOWEwZTI1ZjI0YWY3Mjg1YTA4ZDk4OWJiZjUw MiU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTIyNjI2 Mzk3MTIyOTIlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pR SWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2Rh dGE9YURVNWdCUXJMdDRLVkl2bDlnb1kwbDdDNnhJTVc4QlM3QllzT2JFckZtUSUzRCZhbXA7cmVz ZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRndn LW1hdGVyaWFscyUyRmJsb2IlMkZtYWluJTJGaW50ZXJpbS0yMDE5LTAxJTJGbWludXRlcy5tZCUy M2Fja3MtYW5kLW5hY2tzLWpvbm0mYW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBz LmVkdSU3QzFlYmY5NmMzMGNjNDRmYzk2ZTFkMDhkOTg3OGJiNmI1JTdDNmQ5MzYyMzFhNTE3NDBl YTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY4OTg1NzkzMTg0NDgwOCU3Q1Vua25vd24l N0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJ NklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT0lMkJFcHJRTU9WayUyQklO aGR0UnhITDVKZkdRJTJGZVA2dENGdmNBTTN1b3BNRnE0JTNEJmFtcDtyZXNlcnZlZD0wPC9hPik8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgWzJdIDxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZt bHN3ZyUyRm1scy1wcm90b2NvbCUyRmlzc3VlcyUyRjkyJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0 dGEuaGFsZSU0MG5wcy5lZHUlN0NmZjcyOWEwZTI1ZjI0YWY3Mjg1YTA4ZDk4OWJiZjUwMiU3QzZk OTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2OTIyNjI2Mzk3MTIy OTIlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYy bHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9JTJC bEw1Q0Z0YXdGSzNSQVRQWk53aEclMkZtbHNyRktNQ1dDMUJGb2JpbWtuQ28lM0QmYW1wO3Jlc2Vy dmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJv dG9jb2wvaXNzdWVzLzkyPC9hPiAoPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dn JTJGbWxzLXByb3RvY29sJTJGaXNzdWVzJTJGOTImYW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5o YWxlJTQwbnBzLmVkdSU3Q2ZmNzI5YTBlMjVmMjRhZjcyODVhMDhkOTg5YmJmNTAyJTdDNmQ5MzYy MzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY5MjI2MjYzOTcyMjI3OSU3 Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16 SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1QYkVLaEpj Y1JENnhkbU9NbUlZTHZwRVFvdG91YjhmY0NOUFJvU0RSa1VvJTNEJmFtcDtyZXNlcnZlZD0wIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3RvY29s JTJGaXNzdWVzJTJGOTImYW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3 QzFlYmY5NmMzMGNjNDRmYzk2ZTFkMDhkOTg3OGJiNmI1JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlm NzU3ODk2MzM3OGUlN0MwJTdDMCU3QzYzNzY4OTg1NzkzMTg1NDgwMCU3Q1Vua25vd24lN0NUV0Zw Ykdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhh V3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzZGF0YT1sRmVZd3lIQ0dabHNIeiUyQk8yY1ZQ RzdlVVRVanpvTGh6UTBmbml6JTJGYmxtYyUzRCZhbXA7cmVzZXJ2ZWQ9MDwvYT4pPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7IFszXSA8YSBocmVmPSJodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZt bHMtcHJvdG9jb2wlMkZpc3N1ZXMlMkY5MyZhbXA7ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUl NDBucHMuZWR1JTdDZmY3MjlhMGUyNWYyNGFmNzI4NWEwOGQ5ODliYmY1MDIlN0M2ZDkzNjIzMWE1 MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkyMjYyNjM5NzMyMjc3JTdDVW5r bm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxD SkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPVk2TTBockh5Uklw RlBKQ244dGJDeHVJS0tsSCUyRndNOElLVUliMkJUZjhVRSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21scy1wcm90b2NvbC9pc3N1 ZXMvOTM8L2E+ICg8YSBocmVmPSJodHRwczovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJv dG9jb2wlMkZpc3N1ZXMlMkY5MyZhbXA7ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMu ZWR1JTdDZmY3MjlhMGUyNWYyNGFmNzI4NWEwOGQ5ODliYmY1MDIlN0M2ZDkzNjIzMWE1MTc0MGVh OTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkyMjYyNjM5NzMyMjc3JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPVk2TTBockh5UklwRlBKQ244 dGJDeHVJS0tsSCUyRndNOElLVUliMkJUZjhVRSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtbHN3ZyUyRm1scy1wcm90b2NvbCUyRmlzc3Vl cyUyRjkzJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0MxZWJmOTZj MzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMz NzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NTQ4MDAlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW Q0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9enBXJTJCQ1F6JTJCZUV3a2xZYnA0TlFtRmNVZUhC R21BaDBqS0JSQzA1Q3lWQnMlM0QmYW1wO3Jlc2VydmVkPTA8L2E+KTxicj4NCiZndDsgJmd0OyZu YnNwOyBbNF0gPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRm1sc3dnJTJGbWxzLXByb3Rv Y29sJTJGcHVsbCUyRjMzNiUyRmZpbGVzJTJGMjAxNDVlNDlhY2NlMDFkY2VkY2E3ZGIyZDA1YzU3 OTA4YTI5MjIwMiZhbXA7ZGF0YT0wNCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDZmY3 MjlhMGUyNWYyNGFmNzI4NWEwOGQ5ODliYmY1MDIlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4 OTYzMzc4ZSU3QzAlN0MwJTdDNjM3NjkyMjYyNjM5NzQyMjY4JTdDVW5rbm93biU3Q1RXRnBiR1pz YjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lM Q0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPThZJTJCbHhpMThNWG10QldUWU1JcTZ5ZGln VzM3ZUtKSHVlbCUyQkw0eml2eHdzJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwvMzM2L2ZpbGVzLzIw MTQ1ZTQ5YWNjZTAxZGNlZGNhN2RiMmQwNWM1NzkwOGEyOTIyMDI8L2E+ICg8YSBocmVmPSJodHRw czovL25hbTEwLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZnaXRodWIuY29tJTJGbWxzd2clMkZtbHMtcHJvdG9jb2wlMkZwdWxsJTJGMzM2JTJGZmls ZXMlMkYyMDE0NWU0OWFjY2UwMWRjZWRjYTdkYjJkMDVjNTc5MDhhMjkyMjAyJmFtcDtkYXRhPTA0 JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0NmZjcyOWEwZTI1ZjI0YWY3Mjg1YTA4ZDk4 OWJiZjUwMiU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2 OTIyNjI2Mzk3NDIyNjglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01E QWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZh bXA7c2RhdGE9OFklMkJseGkxOE1YbXRCV1RZTUlxNnlkaWdXMzdlS0pIdWVsJTJCTDR6aXZ4d3Ml M0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL25hbTEwLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJG bWxzd2clMkZtbHMtcHJvdG9jb2wlMkZwdWxsJTJGMzM2JTJGZmlsZXMlMkYyMDE0NWU0OWFjY2Uw MWRjZWRjYTdkYjJkMDVjNTc5MDhhMjkyMjAyJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFs ZSU0MG5wcy5lZHUlN0MxZWJmOTZjMzBjYzQ0ZmM5NmUxZDA4ZDk4NzhiYjZiNSU3QzZkOTM2MjMx YTUxNzQwZWE5MTk5Zjc1Nzg5NjMzNzhlJTdDMCU3QzAlN0M2Mzc2ODk4NTc5MzE4NjQ3OTQlN0NV bmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp TENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9ME9nVmRkYyUy Qkl6anU2MU13ZlFGTmlZamVqWklOdHJJcWYwOENrSWdHbSUyQlElM0QmYW1wO3Jlc2VydmVkPTA8 L2E+KTxicj4NCiZndDsgJmd0OyZuYnNwOyBbNV0gPGEgaHJlZj0iaHR0cHM6Ly9uYW0xMC5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGbWFpbGFyY2hp dmUuaWV0Zi5vcmclMkZhcmNoJTJGbXNnJTJGbWxzJTJGSHNfbkFYM2x1RGppUTRtSXdraUt1MUNG U0FFJTJGJmFtcDtkYXRhPTA0JTdDMDElN0Nicml0dGEuaGFsZSU0MG5wcy5lZHUlN0NmZjcyOWEw ZTI1ZjI0YWY3Mjg1YTA4ZDk4OWJiZjUwMiU3QzZkOTM2MjMxYTUxNzQwZWE5MTk5Zjc1Nzg5NjMz NzhlJTdDMCU3QzAlN0M2Mzc2OTIyNjI2Mzk3NTIyNzElN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4 ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhW Q0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9Zkk3NFBKRVUxM1dlMDlSakNyNUhXbkljNmZlWUM0 aUZMQkI4amhCMjNqZyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9tbHMvSHNfbkFYM2x1RGppUTRtSXdraUt1 MUNGU0FFLzwvYT4gKDxhIGhyZWY9Imh0dHBzOi8vbmFtMTAuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRm1haWxhcmNoaXZlLmlldGYub3JnJTJGYXJj aCUyRm1zZyUyRm1scyUyRkhzX25BWDNsdURqaVE0bUl3a2lLdTFDRlNBRSUyRiZhbXA7ZGF0YT0w NCU3QzAxJTdDYnJpdHRhLmhhbGUlNDBucHMuZWR1JTdDZmY3MjlhMGUyNWYyNGFmNzI4NWEwOGQ5 ODliYmY1MDIlN0M2ZDkzNjIzMWE1MTc0MGVhOTE5OWY3NTc4OTYzMzc4ZSU3QzAlN0MwJTdDNjM3 NjkyMjYyNjM5NzUyMjcxJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAm YW1wO3NkYXRhPWZJNzRQSkVVMTNXZTA5UmpDcjVIV25JYzZmZVlDNGlGTEJCOGpoQjIzamclM0Qm YW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL25hbTEwLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZtYWlsYXJjaGl2ZS5pZXRm Lm9yZyUyRmFyY2glMkZtc2clMkZtbHMlMkZIc19uQVgzbHVEamlRNG1Jd2tpS3UxQ0ZTQUUlMkYm YW1wO2RhdGE9MDQlN0MwMSU3Q2JyaXR0YS5oYWxlJTQwbnBzLmVkdSU3QzFlYmY5NmMzMGNjNDRm Yzk2ZTFkMDhkOTg3OGJiNmI1JTdDNmQ5MzYyMzFhNTE3NDBlYTkxOTlmNzU3ODk2MzM3OGUlN0Mw JTdDMCU3QzYzNzY4OTg1NzkzMTg3NDc4OSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MzMDAwJmFtcDtzZGF0YT1tb1VBWkozdE9BaEZJJTJCTU1GcTk5QjExMXdKcHhCUkJ3YlJQ WXM1bER4QzAlM0QmYW1wO3Jlc2VydmVkPTA8L2E+KTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_484167A8836342E9816BE968784B1595npsedu_-- From nobody Tue Oct 12 09:09:47 2021 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 CEBAB3A167D for ; Tue, 12 Oct 2021 09:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=raphaelrobert.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 X_EXnLvekuxl for ; Tue, 12 Oct 2021 09:09:21 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 CFE3B3A1642 for ; Tue, 12 Oct 2021 09:09:20 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id v17so68398626wrv.9 for ; Tue, 12 Oct 2021 09:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sv6qJ0ABylhDlhzLEDqHqH3OAtlzWeRpL1XetLzYTfw=; b=nYX8i8cOkWDPBabpdc6h6n7NszwIssp010pZxLUv2zCLv/NFe0Ji8v+M49AJQvmP4r 6LCGoXk7x8cjkTXQysFLwGvxMuJGd6gbl7UhLdnE8GzNX50kajutiv9+WETYUWAmaEFl C4SKBtgKkRsfz8eYuPM7MWZz4XXnT0ZAk6FwI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sv6qJ0ABylhDlhzLEDqHqH3OAtlzWeRpL1XetLzYTfw=; b=rPj+asR+37316s4wmoCPJ+IQcDnvD2rTB3y4L9QFCx2q2FRYIclFxuaf7psU3tyoiD GbSnapS9Qd9IoVXQLquMoeB0oISnTI0+NaHURV93oKyOMsCOfqp5EnVDVeL9rTI5DeVV RDbHXhIiiIFBmUwcMqhh6OHqcSR7aMg7SMqnIU25MtT3JSNg26QdeldrJq4cls97PsIY JSwHMcS1myzSA6gJJQ99Yxqtw/XHwsyW4adFvfYyZYd3OIcAfaopm/S0UTogs6IYnBHP A30O1c3mexlx2Dn7uZ8dqZyWWgn6kxZP/cU/ZgfIuDe54CXyYRzvjOTgaRfwcCAhpmdu O7MA== X-Gm-Message-State: AOAM530eILEad1n+vvliGgjOlXqHlkS+XgjhQxqNsPt9HLtOWTpD6CA7 P5Wm41apXXpi99HH6Bg65Y6CFVNOeZ29f3wa X-Google-Smtp-Source: ABdhPJysQpcoooByFnkwXIK6BloGI76IVfVn8+oiayaB6APBC4pUY107veKhCsjbvN77z70MWYa+jQ== X-Received: by 2002:adf:aa92:: with SMTP id h18mr32372714wrc.372.1634054956820; Tue, 12 Oct 2021 09:09:16 -0700 (PDT) Received: from smtpclient.apple (HSI-KBW-095-208-241-080.hsi5.kabel-badenwuerttemberg.de. [95.208.241.80]) by smtp.gmail.com with ESMTPSA id a127sm2709330wme.40.2021.10.12.09.09.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Oct 2021 09:09:16 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CAF1E169-A872-48BB-B91C-485E99FADD44" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 12 Oct 2021 18:09:15 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Rohan Mahy References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [MLS] Please resubmit draft-ietf-mls-federation 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, 12 Oct 2021 16:09:36 -0000 --Apple-Mail=_CAF1E169-A872-48BB-B91C-485E99FADD44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the federation draft has been expired for quite a while. It has = also not been updated with the latest changes of the protocol draft. We always said we would tackle this after WGLC and I think that still = makes sense. If there is some urgency to resubmit it =E2=80=9Cas is=E2=80=9D= I=E2=80=99m happy to look into it if the chairs agree with the fact = that there won=E2=80=99t be any changes. Raphael > On 12. Oct 2021, at 15:33, Rohan Mahy = wrote: >=20 > Hi, > I think it is great that we can use github for pull requests on the = MLS documents, but that shouldn't mean we let our drafts expire, or = don't discuss things on the mailing list. >=20 > Raphael or Emad, could one of you please, please, please resubmit = draft-ietf-mls-federation? It has been expired for more than a month = now. > Thanks, > -rohan >=20 >=20 > Rohan Mahy l Vice President Engineering, Architecture >=20 > Chat: @rohan_wire on Wire >=20 > =20 >=20 > Wire - Secure team messaging. >=20 > Zeta Project Germany GmbH l Rosenthaler Stra=C3=9Fe 40,=C2=A0 = 10178 Berlin,=C2=A0 = Germany = >=20 > Gesch=C3=A4ftsf=C3=BChrer/Managing Director: Morten J. Broegger=20 >=20 >=20 > HRB 149847 beim Handelsregister Charlottenburg, Berlin >=20 > VAT-ID DE288748675 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_CAF1E169-A872-48BB-B91C-485E99FADD44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the federation draft has been expired for quite a while. It has = also not been updated with the latest changes of the protocol draft.

We always said we would = tackle this after WGLC and I think that still makes sense. If there is = some urgency to resubmit it =E2=80=9Cas is=E2=80=9D I=E2=80=99m happy to = look into it if the chairs agree with the fact that there won=E2=80=99t = be any changes.

Raphael

On 12. Oct 2021, at 15:33, = Rohan Mahy <rohan.mahy=3D40wire.com@dmarc.ietf.org> = wrote:

Hi,
I think = it is great that we can use github for pull requests on the MLS = documents, but that shouldn't mean we let our drafts expire, or don't = discuss things on the mailing list.

Raphael or Emad, could one of you = please, please, please resubmit draft-ietf-mls-federation? It has been = expired for more than a month now.
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

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

= --Apple-Mail=_CAF1E169-A872-48BB-B91C-485E99FADD44-- From nobody Tue Oct 12 12:02:31 2021 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 241873A07DA for ; Tue, 12 Oct 2021 12:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 QPdyYCKaMQv6 for ; Tue, 12 Oct 2021 12:02:24 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 483233A0CD4 for ; Tue, 12 Oct 2021 12:01:39 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id np13so353659pjb.4 for ; Tue, 12 Oct 2021 12:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lWeonj8rJHpQmnuMOMdUw9u+nP1TcNP1kcFlQBpCWV4=; b=ERlRH8ymZxCfDO5doNyvOvWqSgF0nHilyVGhjOZklFPccWkVCWbbJxR0Hr0NDrG7NN A0IRXHTr1cdf4cJfJGRlziRdYbEIULsc2tKrumskh+KA4c3FACm5JXHQPw2MUWb11F85 aG+WCkBXaUhn5KKnPBXKoSjkRy6JVuv5Ylc2NfrB3xG1qmaXTKc/Upb3JB7QL1PVfaNz kuTKlC33gt9ioLgOsDHpxkLkwxpcZTh+iXws76rGQMZ6c1IjC9q6dtIIqXZpEC5I8oqI NocLbntLmCd/1tGcKjrOdpkKewNk7St9Gth26X0wSuH4KBGYd+jm8dY3/MMgfRSo1TRX oJQw== 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=lWeonj8rJHpQmnuMOMdUw9u+nP1TcNP1kcFlQBpCWV4=; b=Tp/LZqfwVN6v/Ii9rm+zgHvK9DObvezt4z3poNhsE/sjp+ek5/CjEfhS68AfoWBnRL fnpLfU+hqMMjfecOKeOXAFZTVIoknf4qur0ukH73coyel5gGgeXi811nac4/62FQoUBp oLlcTGodKOeifsmM2tGmyI3eDZmypEtaqrOszCrBjP0o/HZ3A2/J2hUgmELCCU1gWGKa NuprmdZNKlSMDdpopniqLHmxQeTEqbo8/N8hbrik4wsNRqblFV51epgWGhygaO0Pgpul hkcEUrtByZMp+s/HoFDrUvuNXj3n719M4REYSdZYAXM+wSuuCdr/NjuuEQ9W5BlWG8/i 1QTA== X-Gm-Message-State: AOAM530aMcbTdQa94TUkTUcwknGBokFQman+8pS28OLKSEHsAxUskhJP RP7Fze6j2JQ1ubdYXyoHNLHb2pqHM4uLpveK0nFl2R+HzMDDng== X-Google-Smtp-Source: ABdhPJyfs/p/ypHEWZAouVpIgw0UmFvm9HCXifti/Bs+CrcFoWbpFCBAsFpGL2Cr58b36LvybnmxaU5UUqFk2j8VLvA= X-Received: by 2002:a17:90a:a581:: with SMTP id b1mr7891577pjq.21.1634065297800; Tue, 12 Oct 2021 12:01:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rohan Mahy Date: Tue, 12 Oct 2021 12:01:26 -0700 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000009d972005ce2c79a0" Archived-At: Subject: Re: [MLS] Please resubmit draft-ietf-mls-federation 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, 12 Oct 2021 19:02:30 -0000 --0000000000009d972005ce2c79a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think it is fine to resubmit it basically as-is with a short disclaimer saying it needs to be updated to reflect the changes in the protocol document. 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 On Tue, Oct 12, 2021 at 9:09 AM Raphael Robert wrote: > I think the federation draft has been expired for quite a while. It has > also not been updated with the latest changes of the protocol draft. > > We always said we would tackle this after WGLC and I think that still > makes sense. If there is some urgency to resubmit it =E2=80=9Cas is=E2=80= =9D I=E2=80=99m happy to > look into it if the chairs agree with the fact that there won=E2=80=99t b= e any > changes. > > Raphael > > On 12. Oct 2021, at 15:33, Rohan Mahy < > rohan.mahy=3D40wire.com@dmarc.ietf.org> wrote: > > Hi, > I think it is great that we can use github for pull requests on the MLS > documents, but that shouldn't mean we let our drafts expire, or don't > discuss things on the mailing list. > > Raphael or Emad, could one of you please, please, please resubmit > draft-ietf-mls-federation? It has been expired for more than a month now. > 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 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > --0000000000009d972005ce2c79a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I think it is fine to resubmit it basic= ally as-is with a short disclaimer saying it needs to be updated to reflect= the changes in the protocol document.
Thanks,
-rohan


Rohan Mahy=C2=A0 <= span style=3D"font-family:Arial,sans-serif">l=C2=A0 Vice President Engineer= ing, Architecture

Chat: @rohan_wire on=C2=A0Wire

=C2=A0

Wire=C2=A0- Secure team messaging.

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

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

HRB 149847 beim Handelsregister Charlottenburg, Berlin=

VA= T-ID DE288748675


<= /div>
I think the federation draft has been = expired for quite a while. It has also not been updated with the latest cha= nges of the protocol draft.

We always said we would tack= le this after WGLC and I think that still makes sense. If there is some urg= ency to resubmit it =E2=80=9Cas is=E2=80=9D I=E2=80=99m happy to look into = it if the chairs agree with the fact that there won=E2=80=99t be any change= s.

Raphael

<= div>On 12. Oct 2021, at 15:33, Rohan Mahy <rohan.mahy=3D40wire.com@dma= rc.ietf.org> wrote:

Hi,
I think it is great that we can use github for pull requests on the MLS d= ocuments, but that shouldn't mean we let our drafts expire, or don'= t discuss things on the mailing list.

Raphael or E= mad, could one of you please, please, please resubmit draft-ietf-mls-federa= tion? It has been expired for more than a month now.
Thanks,
-rohan


=

<= b>Rohan Mahy=C2=A0 = l=C2=A0 Vice President Enginee= ring, Architecture

Chat: @rohan_wire o= n=C2=A0Wire

=C2=A0

<= span style=3D"font-size:9.5pt">Wire=C2=A0- Secure team messaging.

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


<= span style=3D"color:rgb(204,204,204);font-size:9.5pt">Gesch=C3=A4ftsf=C3=BC= hrer/Managing Director: Morten J. Broegger=C2=A0


HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675

<= /div>
_______________________________________________
MLS mailing list
MLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mls

<= /div>
--0000000000009d972005ce2c79a0-- From nobody Sun Oct 17 01:36:39 2021 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 9B1683A0AFE for ; Sun, 17 Oct 2021 01:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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_DNSWL_LOW=-0.7, 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=Xiu2+YYH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U0+pn/y3 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 Y9Z7v4FaNR-6 for ; Sun, 17 Oct 2021 01:35:52 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF613A0AD7 for ; Sun, 17 Oct 2021 01:35:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6ABD65C0083 for ; Sun, 17 Oct 2021 03:38:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 17 Oct 2021 03:38:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=Du8LNRcCpRc gmAo2UZHLZn2TrTXLFXZnjSvJTD86C5Q=; b=Xiu2+YYHDF8P4PQtL/RmdVPZZS6 VaRmgSwja1aKvLIExAq6CN5xXlCQh1nwRzT+Jw64n6LqBtro+qUDCPCzOH4xKxPf FAf1BuPDcuyqpLOdaNVJZvHvlXNyyz63hK+U7GKDwucw/ouxMiAUGVw1Of0XVEOK 8Zs1meMUvPafWDIgrP6fF6eu8Gedr8UVIjefhw/ksvVL4I+fuHpjy8XiyBt2Hn1h +NErxOxQPZ7MWnZHI4hc1vH4BNci0MtdHsMQlJ5PJTCuc0j87iQm3nxxIwKEk0dw 5FYAefkRv2SZ3JdZUGytaW1TEFYO/KFolS1O/aF8oRzuV8xyph7oZ9SzeDw== 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=Du8LNRcCpRcgmAo2UZHLZn2TrTXLFXZnjSvJTD86C5Q=; b=U0+pn/y3 ClAGhWYfNMb0uXpZA/ZokTlOoq0zguTss90LPuazvYIKs/sU1comBwUP37FWVVey UlhgI8kiUOe8b1nUcSvsQ16b+CMDPTzdAMU4KG3WHTJtp6uoN9SH6KtyGseNTQ9S lTdboovnn1FDJ9PZw//Do+rUkCcxkTnQ6A2G1m3ik01fiEX67PzwF2hQf7lpQDLr 0V8zQXmqwaYBxrPi8oCD91s9luw3CFetmYv04PJGNeuIKrb0dLXEplBQ76Y90fVn A9IHs7uwXky3Q7Yh/BqPebUFW2ntdPGXptl4DS+efW7ZLo/9k1U4Q49gssCOIVg7 ZoLtcqxCI0mT6w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddujedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 17 Oct 2021 03:38:43 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7316878030019887636==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20211017083552.9FF613A0AD7@ietfa.amsl.com> Date: Sun, 17 Oct 2021 01:35:52 -0700 (PDT) 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, 17 Oct 2021 08:35:58 -0000 --===============7316878030019887636== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-4/=F0=9F=92=AC1) 1 issues received 1 new comments: - #493 Key schedule text - figure mismatch (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/493=20 4 issues closed: - Key schedule text - figure mismatch https://github.com/mlswg/mls-protoc= ol/issues/493=20 - External commit for resync used with PSK https://github.com/mlswg/mls-p= rotocol/issues/443=20 - Use `(identity, endpoint_id)` tuple instead of leaf indices in Message = structs https://github.com/mlswg/mls-protocol/issues/486=20 - Ensure no ambiguity between leaf and node indices https://github.com/ml= swg/mls-protocol/issues/432=20 Pull requests ------------- * mlswg/mls-protocol (+2/-8/=F0=9F=92=AC1) 2 pull requests submitted: - Add changelog for draft-12 (by bifurcation) https://github.com/mlswg/mls-protocol/pull/497=20 - Normalize the description of the zero vector (by bifurcation) https://github.com/mlswg/mls-protocol/pull/496=20 1 pull requests received 1 new comments: - #490 Use cascaded KDF instead of concatenation to consolidate PSKs (1 b= y bifurcation) https://github.com/mlswg/mls-protocol/pull/490=20 8 pull requests merged: - Add changelog for draft-12 https://github.com/mlswg/mls-protocol/pull/497=20 - Normalize the description of the zero vector https://github.com/mlswg/mls-protocol/pull/496=20 - Constrain proposal in External Commit https://github.com/mlswg/mls-protocol/pull/481=20 - Add RequiredCapabilities extension https://github.com/mlswg/mls-protocol/pull/489=20 - Use key package hash to index clients in message structs https://github.com/mlswg/mls-protocol/pull/491=20 - Remove the notion of a 'leaf index' https://github.com/mlswg/mls-protocol/pull/487=20 - Don't require PublicGroupState for external init https://github.com/mlswg/mls-protocol/pull/494=20 - Use cascaded KDF instead of concatenation to consolidate PSKs https://github.com/mlswg/mls-protocol/pull/490=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============7316878030019887636== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 17, 2021

Issues

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

1 issues received 1 new comments:

4 issues closed:

Pull requests

mlswg/mls-protocol (+2/-8/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

8 pull requests merged:

Repositories tracked by this digest:

--===============7316878030019887636==-- From nobody Thu Oct 21 10:35:10 2021 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 9DB6B3A08D9 for ; Thu, 21 Oct 2021 10:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqpBPDnWbbJS for ; Thu, 21 Oct 2021 10:35:03 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 E0B8F3A087D for ; Thu, 21 Oct 2021 10:35:02 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id h20so2033141qko.13 for ; Thu, 21 Oct 2021 10:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=quo+A7m8F5PBngwZ627S66ri21QYUn2o7j1gdjtznUo=; b=E3FRwnJK+1BDzBXm0Hu5hgq0DAUf06Zv7V0cSL9gKj/Z3WiQQ3yAfVnP2FFAgPX/ie GeSJxuQ6I3y+Yqncx3KXB0ofiderK/zJTxa64YAPm4gN12sEJnjMwxti0OvXqM2U7IYK 7qHWG5B8omXhgXDk3S6muOt5/RzwS18DXLVc8= 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=quo+A7m8F5PBngwZ627S66ri21QYUn2o7j1gdjtznUo=; b=aLGV66IO1bisF4fvwN+jTTHCKIyc5kKMGuf6PdCF2NjbO1RtDcTRG/sPTugSGGvMJB KVeWGqkG8oLRjM8356vt02Z4eqmUIraMshg+MUmhUeiYsyD/7O3pZK/rPQazBzp+pV6z ATs2eSqQkQ8+OdViZFSzkPPOe06zvByaBPHg36ZqrR24Fk33QBm0+Q9lCQQsRyg5XAaa piXxyZsec5Tv1YLJVtI3gUNDtnM8xOFS37oVjJI93RCz03YS3AQjjXqgwzjm2LyalT+/ vBhEKYf8tGEJEKWy6SQhqLLwWyDQnD+0ZU93gu7iRMtoGoPKcyITs0T1BmdAdiAD8dGh zzRg== X-Gm-Message-State: AOAM532/ml4SFPzsz8yL8GphztN93lNrDZSKlIu13ku2nDXdqMb5EN4H ceqYNdbvLxq7xWKIPP5uxHiSLCvV+bnTFw== X-Google-Smtp-Source: ABdhPJwvabj1oFEYo78lqmsSxvgF8hKC8kcF0reiulospo+tL/VNAFTV+g9BlrY6AGThctHmhXPGLw== X-Received: by 2002:a37:a853:: with SMTP id r80mr5577891qke.275.1634837699174; Thu, 21 Oct 2021 10:34:59 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id k9sm2864165qkj.75.2021.10.21.10.34.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Oct 2021 10:34:58 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: Date: Thu, 21 Oct 2021 13:34:55 -0400 To: MLS List X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [MLS] December 2021 Interim? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 17:35:08 -0000 Hi! There are still a couple of outstanding issues and new PRs since -12 on = -protocol. I would like to suggest that we schedule an interim for = sometime in early December to deal with anything new that crops up. We = can schedule it and if not needed we can always cancel it. Thoughts? Cheers spt= From nobody Thu Oct 21 10:35:29 2021 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 B0E5B3A087D for ; Thu, 21 Oct 2021 10:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLx7nqu53OPx for ; Thu, 21 Oct 2021 10:35:14 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 4BF343A093B for ; Thu, 21 Oct 2021 10:35:14 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id k29so888693qve.6 for ; Thu, 21 Oct 2021 10:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B5n/t39Fz1vOWpFITYwZdAn0WwMJ+9kftzRhAyyMBMI=; b=lFbaHl/Rw/Vqh1yKhzr94mtjH5Iy40RhLXEaFk/oodSM5AI/COrV8JkGRJDZl0mdx0 537fB/d5KhThr+9JHhF4ErUXNf8KkNVWEGUytXOoyX6ItBRblZ3bqBPXc38U0pi3/sSf TlG2C+FGTAzb7zNECccNNcSUvcux2/A+0lV3E= 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=B5n/t39Fz1vOWpFITYwZdAn0WwMJ+9kftzRhAyyMBMI=; b=b5bOL+YoGdw9jRz8IPfagQgq4JUF7BQ2sx8ngO7LAYMINUYyiWucQMF1wNmbll0Wm4 8o3/o5T6h2qTsEfss741FGYEmg7yxhyHrtEfLOCBNwQBtX681mDZ7rzOfWIYyOVzlp2P u6TEVxnhS04s0PkMhzaPFgAQwJP7SEtxiFndRYhg/Ke5io3P2NBD0bG5GWMMANclrsB+ +rVEcSvM2XlVQHmRG+wL3peToX0+IpiUn+psVtoXg7UCl+c/AQZ1rsfBhpbEetN0MswI aN+VPi1n/Zvj3MTdhbvWa1bTxgZ2j8MBn3iTBM67sBd7BQOV76NwJCpSycFzQclYi0nL m7PA== X-Gm-Message-State: AOAM531Iq84hIov7p4ACdHi3T6VZbYOfwrKail3c9V71PS9mySkrivm3 wFNgZai9KDXx+wylE059+5T9rTjO1PfnCQ== X-Google-Smtp-Source: ABdhPJy+sVxFY8xPJmYrOlFg7I6u12MiWK+aZbBzxhlAU7JNmG+8LnRzTp15D8ipBm1Nde3IlIIhHw== X-Received: by 2002:a05:6214:240d:: with SMTP id fv13mr4850417qvb.19.1634837711674; Thu, 21 Oct 2021 10:35:11 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id k9sm2864165qkj.75.2021.10.21.10.35.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Oct 2021 10:35:11 -0700 (PDT) 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, 21 Oct 2021 13:35:10 -0400 Cc: MLS List Content-Transfer-Encoding: quoted-printable Message-Id: <14D267FE-AE03-43F7-8D52-138A4802CF07@sn3rd.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [MLS] Post-interim PRs X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 17:35:21 -0000 Richard, Thanks for keeping on top of these and for getting the -12 version out. spt > On Oct 7, 2021, at 14:02, Richard Barnes wrote: >=20 > Hey all, >=20 > One last request for comments before merging! Since these all already = got discussion at the interim (and there's pretty clear resolution on = #481 on the mailing list), I will plan to merge over the weekend if = there's no further commentary. >=20 > Note that a couple of new PRs have come up this week: >=20 > #491 - Use key package hash to index clients in message structs > https://github.com/mlswg/mls-protocol/pull/491 >=20 > #494 - Require PublicGroupStateTBS for external init > https://github.com/mlswg/mls-protocol/pull/494 >=20 > We discussed #491 some on the interim, in the context of #487. #494 = is resolving an implementation issue, and could use some eyes on it, = since we are proposing to **not** **inject** some information that is = currently injected into the key schedule. >=20 > Thanks, > --Richard >=20 > On Mon, Oct 4, 2021 at 10:12 PM Richard Barnes wrote: > Hi all, >=20 > Thanks for the good discussion on the interim call today. I have = posted a salvo of PRs capturing where I think we ended up. Given that = these have already had some discussion, if we could get some quick = reviews, I think we can go ahead and merge. Then once we resolve the = rsync discussion one way or another, we can cut a new draft and kick off = WGLC. >=20 > #487 - Remove the notion of a 'leaf index' > https://github.com/mlswg/mls-protocol/pull/487 >=20 > #489 - Add RequiredCapabilities extension (implementing Rohan's = suggestion) > https://github.com/mlswg/mls-protocol/pull/489 >=20 > #490 - Use cascaded KDF instead of concatenation to consolidate PSKs > https://github.com/mlswg/mls-protocol/pull/490 >=20 > Thanks a lot, > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Thu Oct 21 11:52:52 2021 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 3477E3A0881 for ; Thu, 21 Oct 2021 11:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 CBjbYjFRoAiv for ; Thu, 21 Oct 2021 11:52:19 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CF63A0863 for ; Thu, 21 Oct 2021 11:52:18 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id d6so1035565qvb.3 for ; Thu, 21 Oct 2021 11:52:18 -0700 (PDT) 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=ErgaDTPDajnwXLubOg1ydQxEEwE06mnx1v7sQfdDch8=; b=yNoUB3p9Tbe1/srcoNgk3vKMOix5IgUXdFtuSuBT18OUdrA37pDVUngXVc0QcQQioZ pquj34U+FfBrf8mSvEzL6GHb6Ei/JMH8AKEccy0/kP7BsFgARAqdD8WdO6/mWybz1lIQ l2DCvKccvKBhDEHdAR1fDaShbVb+POzK9VgtWtSUDyoyIY5vZOCtawHIO85Jvu/oQUm2 CxZ4BpL0/pzGiX0aAhukW1x2N4a3P0VGI+YgMWgiWzNU+7BPFS6V8VXCdGMNwIgUG4FT xRyyScJC8WINssvy3j9m2YJCuK5Kw5hxsHbKn44cMuZxuJ8Tl9QVDlej2IiUzyjp1jgo dtXw== 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=ErgaDTPDajnwXLubOg1ydQxEEwE06mnx1v7sQfdDch8=; b=lm6DIKCRUVsZk4Zxm05VoUue1fAlMajgNe0OtQ4em1cUksP0uxhE1obxLnBXGP2gPx JKATpaWpH/vE/PP61ArDjvXBYIzb0lGOCPrYZARS9KV9GYiC7ozZeTURNW2InN0/E96h rdmBZa+hNf5KrQs1frsLTusXWi8Gn0AZAQuHfhD6E8QdQprjqRDnMN0K98PxFgmwBk9o hBmLUwnbkU1fShsJqGAq+NTiLYsprC3w+Kn/bpe+hmzT4DQMArJHHGm+Q6+yg7sh9ZYd bZnFX2r2yjSlstyFqcgmdI3QaSvpiTOuuYDr2hmkO2kT+gXjD0XyC1j2x9AKi/UYl1vP WiuA== X-Gm-Message-State: AOAM530fqSgKxv/uqVGKpn6Oi8RhVrPt4CYkchE7yicyJRjcon+2KlHu 0RIfqR8x6olEgvFls4AuHNRL0FRyxus3qWQG3V3pzUA1DI6glA== X-Google-Smtp-Source: ABdhPJyLHA7bEpJiJ6+nL9kDR0jHTt6MC6vEFdm42W2YlLctLYeRHLA9wz/vogTHiuX+oFYf4UPfUj5WU/pWPzmK6Xg= X-Received: by 2002:a0c:bf49:: with SMTP id b9mr4887593qvj.53.1634842336570; Thu, 21 Oct 2021 11:52:16 -0700 (PDT) MIME-Version: 1.0 References: <14D267FE-AE03-43F7-8D52-138A4802CF07@sn3rd.com> In-Reply-To: <14D267FE-AE03-43F7-8D52-138A4802CF07@sn3rd.com> From: Richard Barnes Date: Thu, 21 Oct 2021 14:52:04 -0400 Message-ID: To: Sean Turner Cc: MLS List Content-Type: multipart/alternative; boundary="000000000000bc3efe05cee164cd" Archived-At: Subject: Re: [MLS] Post-interim PRs X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 18:52:26 -0000 --000000000000bc3efe05cee164cd Content-Type: text/plain; charset="UTF-8" No problem! I look forward to the WGLC announcement :) On Thu, Oct 21, 2021 at 1:35 PM Sean Turner wrote: > Richard, > > Thanks for keeping on top of these and for getting the -12 version out. > > spt > > > On Oct 7, 2021, at 14:02, Richard Barnes wrote: > > > > Hey all, > > > > One last request for comments before merging! Since these all already > got discussion at the interim (and there's pretty clear resolution on #481 > on the mailing list), I will plan to merge over the weekend if there's no > further commentary. > > > > Note that a couple of new PRs have come up this week: > > > > #491 - Use key package hash to index clients in message structs > > https://github.com/mlswg/mls-protocol/pull/491 > > > > #494 - Require PublicGroupStateTBS for external init > > https://github.com/mlswg/mls-protocol/pull/494 > > > > We discussed #491 some on the interim, in the context of #487. #494 is > resolving an implementation issue, and could use some eyes on it, since we > are proposing to **not** **inject** some information that is currently > injected into the key schedule. > > > > Thanks, > > --Richard > > > > On Mon, Oct 4, 2021 at 10:12 PM Richard Barnes wrote: > > Hi all, > > > > Thanks for the good discussion on the interim call today. I have posted > a salvo of PRs capturing where I think we ended up. Given that these have > already had some discussion, if we could get some quick reviews, I think we > can go ahead and merge. Then once we resolve the rsync discussion one way > or another, we can cut a new draft and kick off WGLC. > > > > #487 - Remove the notion of a 'leaf index' > > https://github.com/mlswg/mls-protocol/pull/487 > > > > #489 - Add RequiredCapabilities extension (implementing Rohan's > suggestion) > > https://github.com/mlswg/mls-protocol/pull/489 > > > > #490 - Use cascaded KDF instead of concatenation to consolidate PSKs > > https://github.com/mlswg/mls-protocol/pull/490 > > > > Thanks a lot, > > --Richard > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > --000000000000bc3efe05cee164cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No problem! I look forward to the WGLC announcement :)
=

= On Thu, Oct 21, 2021 at 1:35 PM Sean Turner <sean@sn3rd.com> wrote:
Richard,

Thanks for keeping on top of these and for getting the -12 version out.

spt

> On Oct 7, 2021, at 14:02, Richard Barnes <rlb@ipv.sx> wrote:
>
> Hey all,
>
> One last request for comments before merging!=C2=A0 Since these all al= ready got discussion at the interim (and there's pretty clear resolutio= n on #481 on the mailing list), I will plan to merge over the weekend if th= ere's no further commentary.
>
> Note that a couple of new PRs have come up this week:
>
> #491 - Use key package hash to index clients in message structs
> https://github.com/mlswg/mls-protocol/pull/491
>
> #494 - Require PublicGroupStateTBS for external init
>
https://github.com/mlswg/mls-protocol/pull/494
>
> We discussed #491 some on the interim, in the context of #487.=C2=A0 #= 494 is resolving an implementation issue, and could use some eyes on it, si= nce we are proposing to **not** **inject** some information that is current= ly injected into the key schedule.
>
> Thanks,
> --Richard
>
> On Mon, Oct 4, 2021 at 10:12 PM Richard Barnes <
rlb@ipv.sx> wrote:
> Hi all,
>
> Thanks for the good discussion on the interim call today.=C2=A0 I have= posted a salvo of PRs capturing where I think we ended up.=C2=A0 Given tha= t these have already had some discussion, if we could get some quick review= s, I think we can go ahead and merge.=C2=A0 Then once we resolve the rsync = discussion one way or another, we can cut a new draft and kick off WGLC. >
> #487 - Remove the notion of a 'leaf index'
> https://github.com/mlswg/mls-protocol/pull/487
>
> #489 - Add RequiredCapabilities extension (implementing Rohan's su= ggestion)
>
https://github.com/mlswg/mls-protocol/pull/489
>
> #490 - Use cascaded KDF instead of concatenation to consolidate PSKs >
https://github.com/mlswg/mls-protocol/pull/490
>
> Thanks a lot,
> --Richard
> _______________________________________________
> MLS mailing list
>
MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

--000000000000bc3efe05cee164cd-- From nobody Thu Oct 21 11:53:12 2021 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 719023A088C for ; Thu, 21 Oct 2021 11:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 GtbIoE_7UD-J for ; Thu, 21 Oct 2021 11:53:03 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 954B03A088A for ; Thu, 21 Oct 2021 11:53:03 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id k29so1032268qve.6 for ; Thu, 21 Oct 2021 11:53:03 -0700 (PDT) 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=nKpmMJgsM086CRpIgKZrBzPD7E5ZvTKv/9IdkRNPaaQ=; b=KjIydSTIQ3dscrf2O7xMrgkpLl8ym2NEL3fcjYov63eCZhXFA7SlHvPzpiOOUl4T+W Su6SylEOG8dtN/lCtz0I6R0Czuo/JGnlBjfYej+qwCeod+akjUqFbEEY0vmuRZU2FHrk 05nYLMfotYj5InKlNrteMCMvnPCm/jKFeiB5I2knZzgQij8bXzAVE3cLJwvN2HnMXSU0 w/m1f2HOl8+UKAzQWBz+eHI0KMhnuueinVlrnBTeeb6StOZ25OotE8rrPInYlPqfL7Ah AVZDDwMo3I+vLfw9HKD6IPqGTJO8NLHANzn9oBV1GwCDci/gsqCeIsScsLj+PWGcXsqM Bwpw== 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=nKpmMJgsM086CRpIgKZrBzPD7E5ZvTKv/9IdkRNPaaQ=; b=cf5tLDiWLJia0zymc1BHETzrCRhjX0QXS4wFqAfla2vHVE8ROcL0l+xUDAKQKc+VCI /Oij9coJ+JtbM9nkaZC6on9lX2+Fh00MF1RMpyLTRp/bPKOcd2piYNDZu2sjjeR2mNOJ rmgoX1lmoUrawf1x7+iO2LudxqxECsAuU8EwIlPzUz52ui8ETbXY1jzPDcZW0PJHm3PY 7FNQTi1jIHSpdoLgRjhvMZ3FkGyWYCQQbc+0K/HUf69qJqAr/kdDiC6h/Xi2ONgN5MnT xNP20PCAlFwXtkGVqhFvtL4TURT7uz7xbcYHkj6hoo8Wzo4iRmQhsBITW+Vw7Nd8lYY/ 4rsw== X-Gm-Message-State: AOAM533JmQDbZr7HQvSDnOVxwEebt8BJwHQCKWLX26kssfUtCaGaqfOH OqNItr+fZGT9HUJE/jpWhHKIvDVv4E0otusHW8r6tFd9X1m2nQ== X-Google-Smtp-Source: ABdhPJye3z2Yr4nbbIK9+kHjq8g0xRhqTtB7WKpeZAvI35CcDVywJ6tKLz3KGuuDonNsgSUawn5//ByrKu77g0NXx30= X-Received: by 2002:a05:6214:e84:: with SMTP id hf4mr3793212qvb.38.1634842381421; Thu, 21 Oct 2021 11:53:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 21 Oct 2021 14:52:49 -0400 Message-ID: To: Sean Turner Cc: MLS List Content-Type: multipart/alternative; boundary="000000000000689d2105cee167bb" Archived-At: Subject: Re: [MLS] December 2021 Interim? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 18:53:10 -0000 --000000000000689d2105cee167bb Content-Type: text/plain; charset="UTF-8" Seems like a fine idea. If we go ahead and run a WGLC, we could also use that to handle any LC comments. --RLB On Thu, Oct 21, 2021 at 1:35 PM Sean Turner wrote: > Hi! > > There are still a couple of outstanding issues and new PRs since -12 on > -protocol. I would like to suggest that we schedule an interim for sometime > in early December to deal with anything new that crops up. We can schedule > it and if not needed we can always cancel it. Thoughts? > > Cheers > spt > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000689d2105cee167bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seems like a fine idea.=C2=A0 If we go ahead and run = a WGLC, we could also use that to handle any LC comments.
--RLB

On Thu, Oct 21, 2021 at 1:35 PM Sean Turner <sean@sn3rd.com> wrote:
Hi!

There are still a couple of outstanding issues and new PRs since -12 on -pr= otocol. I would like to suggest that we schedule an interim for sometime in= early December to deal with anything new that crops up. We can schedule it= and if not needed we can always cancel it. Thoughts?

Cheers
spt
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000689d2105cee167bb-- From nobody Sun Oct 24 04:31:11 2021 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 509E33A09E9 for ; Sun, 24 Oct 2021 04:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=GuoZgRaq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ILD08gIE 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 p3_Bc8wctTTS for ; Sun, 24 Oct 2021 04:30:47 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C6C3A09CE for ; Sun, 24 Oct 2021 04:30:47 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id ED9C25C0784 for ; Sun, 24 Oct 2021 03:38:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 24 Oct 2021 03:38:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=Y6YHp1TfBAG IRMF3YZys1HUjyYW3A+VSxKbnONb2D4s=; b=GuoZgRaqcazN5zlFPIcLxgSh/J0 3JZAFyIA8GCOQp1Y29aBnTD2/DXYgHrx/wqMTkkBIxe/+RG99SqEck2tqSPhrkuU 748QtSncpzs5f8LmJCN+d+pDU4fpfHf7ZuKkdN1Co5iUbNmBTfy6UK2MVkemtPUY hi1H1CInenOnSGRRAhK33M3+F0ows/w+xvnYMon7sAVKf6aqAmIL8Ku1l1AhVGua 8p1T0ySFCw+bU81De++2Ja7L73hWFjvB2ty6ZcKZ+LaGujHK4NWIJZJN+HU6/EtC pWCo6nUjYGJs5EQYGMfbAaH3Z9BxoT8qWHz64vY4/NZxJtYYU704/QPcZFQ== 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=Y6YHp1TfBAGIRMF3YZys1HUjyYW3A+VSxKbnONb2D4s=; b=ILD08gIE HDAdnO9TlI3QHbGzHA4/+a0HGbFaE2jH2GWCFhmMWVSmXWBpQuXTzBdxldJJ40aU vrqjwFg1w6BQ+Y8ogOSL9NZLy4hu+iREgYhfwtvoW8w5y/HWfupbf3GJQXKeMBND lr55cAoWXA8otkpwG8sXJo6KyAMW//hiCONLXu3OmVjHfFngt9m/7dSw3jbbv4YQ Xc/ROK2GetwfrsTDEJK8nnEZhc/i3TORao6CsLKlxMz+BgAMpI4Z6VLu7AGVxc7H ge9eIS3xhtP5NvtkUR3xtuNoUxzaiB09FrBhOaszKVhJQwk5k7WJ4L+46QGDlVST KajXoB+DQ09cOw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefvddgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 24 Oct 2021 03:38:56 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============1209985498810951900==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20211024113047.71C6C3A09CE@ietfa.amsl.com> Date: Sun, 24 Oct 2021 04:30:47 -0700 (PDT) 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, 24 Oct 2021 11:30:52 -0000 --===============1209985498810951900== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+3/-0/=F0=9F=92=AC3) 3 issues created: - Update HPKE requirement to latest draft (by bifurcation) https://github.com/mlswg/mls-protocol/issues/500=20 - `typed` struct definition (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/499=20 - `Ciphersuite` should be part of `PublicGroupStateTbs` (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/498=20 2 issues received 3 new comments: - #499 `typed` struct definition (2 by bifurcation, kkohbrok) https://github.com/mlswg/mls-protocol/issues/499=20 - #498 `Ciphersuite` should be part of `PublicGroupStateTbs` (1 by bifurc= ation) https://github.com/mlswg/mls-protocol/issues/498=20 Pull requests ------------- * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Add ciphersuite field to `PublicGroupStateTBS` (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/501=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============1209985498810951900== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 24, 2021

Issues

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

3 issues created:

2 issues received 3 new comments:

Pull requests

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

1 pull requests submitted:

Repositories tracked by this digest:

--===============1209985498810951900==-- From nobody Sun Oct 31 00:57:02 2021 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 ADED23A0646 for ; Sun, 31 Oct 2021 00:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_H2=-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=R88Zbvhq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E1TYsJXI 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 u42_HnEyIenf for ; Sun, 31 Oct 2021 00:56:55 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EFF3A0691 for ; Sun, 31 Oct 2021 00:56:55 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5EC5D5C00CE for ; Sun, 31 Oct 2021 03:39:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 31 Oct 2021 03:39:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=AYYCY9BVvk8 JJ6N3wV2jDyCVUFMiZfNf5MpM5mHxFfA=; b=R88ZbvhqIsPIpNbGH0ZhdOFVfmj 4ye2r3HBlSZDTAhp5sPz7uDrjBCSgKACo07SNT6ZZSvmx0cneKdAkps6MyGCXUA2 zaOiweD3UOQnr39vMCsnimTm4CJ3QO9WGq55SbU3TVB42LXYcTbh901iLtRsvdPf R6FsanoWnC6U4gw8Chbvi94MEzt7ImYUyu6tVI39BwrE4KyIP+YOQYya/EhVGszm 0rXUBhkYk9P5FgAVMr5MqBY96blCbcJJQ8OVhW7+z5EIx2JLVGGrnqK4N1P6DCN1 UzMa6Afxi9+pQswAA4PKx4jIT6wThLge2gnCTK4ip++zr+TkR4ztbugg5Uw== 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=AYYCY9BVvk8JJ6N3wV2jDyCVUFMiZfNf5MpM5mHxFfA=; b=E1TYsJXI 3L5BtwSXeyUExuP1NA08ShycSkwOjVM+x2VfeF+88xcE/YlCcpOpPBUiLWnR/31a L9aTxcpxwvIc0BN2rFkwFdUAbW5+ZOCD3PGDepOxb/vzqfUoArQ7NNlcIsVXrykl Gym4Wnsb+ZrBkwLTS0fizUxrMT8sR836WUvyRIDkMHMst86PA3PcWiZo4Z2k1DNa d81/8RSYCRtl48wuQeRHNhWlp/IQwlfUOkWb+D0jC0MWjN7Bff5+c99nMhaKlG0W T17dcyyq+jtWWI3TzU+pP/gsBSXTdbKzFxCyee8A5psB/cDCOQokPoxapH7Iic58 +P2vduEeS5qTPA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdegledgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 31 Oct 2021 03:39:07 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3883312595443493672==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20211031075655.60EFF3A0691@ietfa.amsl.com> Date: Sun, 31 Oct 2021 00:56:55 -0700 (PDT) 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, 31 Oct 2021 07:57:00 -0000 --===============3883312595443493672== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #447 Motivate Ratchet Trees (2 by psyoptix, yaronf) https://github.com/mlswg/mls-protocol/issues/447 [editorial]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============3883312595443493672== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 31, 2021

Issues

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

1 issues received 2 new comments:

Repositories tracked by this digest:

--===============3883312595443493672==--