From nobody Sat Feb 1 23:41:04 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFF7120045 for ; Sat, 1 Feb 2020 23:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=uIFdGivj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X+U4m29k 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 vE6DWwGTKZbb for ; Sat, 1 Feb 2020 23:40:57 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759E6120019 for ; Sat, 1 Feb 2020 23:40:57 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8305C3DB for ; Sun, 2 Feb 2020 02:32:36 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 02 Feb 2020 02:32:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=MJBRgTA5vUdVzmY6/2WQHO2Y4hgVlcRoHBn/3yaAh7U=; b=uIFdGivj eWEZZ0dzx54UE6giPpXbm8T0DC88lOZOzY/8fqDmDOtf4kNk1O/oGA0RBIcnjhkg NOlLCuOaJlRLCmxNR50W3/70oVB0jm/4nZlzb25W9G38LWm1CJPa1I/VivhMxG9j m2/lmvZ1afgZnggLtGnsrbdsVGZdFsDyzFHd1SVfoOCExjca2D1FnnIpCpryrAPc gBxiRpfL2AtkfBm8WHMBM/W9WPiZoV5e78M6H4fviFTirTI7ry4SWK4FpBrXxQvv 1yLmNmQCAEbWFgaYK09RMPDA2GFQhKsOdRLemQP4pwrHzhbUB1yW7yqydhIV7W7u 1yaN6MA3cVLfPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=MJBRgTA5vUdVzmY6/2WQHO2Y4hgVl cRoHBn/3yaAh7U=; b=X+U4m29kCHaFvrdvA3Lq+iA+E+hDRbDdMdXGeyCVeFf2u zaA1h0azQeRT4ei4JQPQXkMTp0aIbA2vGzzS7/Gfq7e48fWHtVO1for2Sh7khE2l +sEo47Yum3WwVZRWQcusWXNuSZwRNXysqsvjOGLFzC/AxWw7uAIno2izAXv0T3+w IBSkUeVy5XPa/7ZMSE77sdBCYEFltuWo69OS5H3dc8RB5UKkj2VvSnvO9wxaA/mm RdmBqOd9HXjRkaDFw0Ej2UEC33efJSvuv2dte1RB/zZ8blok4uRX2q+veTwF+A4f kxMF4XPRugVYrR5Ktmqpu2GI1/c8w7YhdgeHhiO9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgeeggdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeegtddruddujedrvdefjedrvdegudenucevlhhushht vghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.117.237.241]) by mail.messagingengine.com (Postfix) with ESMTPA id E5F3A3280059 for ; Sun, 2 Feb 2020 02:32:35 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8282808999450106467==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200202073235.E5F3A3280059@mailuser.nyi.internal> Date: Sun, 2 Feb 2020 02:32:35 -0500 (EST) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2020 07:41:01 -0000 --===============8282808999450106467== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-6/=F0=9F=92=AC10) 1 issues created: - How to derive group_info_key from the init_secret (by ericcornelissen) https://github.com/mlswg/mls-protocol/issues/293=20 7 issues received 10 new comments: - #293 How to derive group_info_key from the init_secret (4 by beurdouche= , bifurcation) https://github.com/mlswg/mls-protocol/issues/293 [bug] [editorial] [sec= urity]=20 - #277 Add/Welcome message should send the epoch secret and not init+comm= it secrets (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/277 [bug] [security] [work= in progress]=20 - #266 Relax default policy of adding from left to right (1 by bifurcatio= n) https://github.com/mlswg/mls-protocol/issues/266 [performance] [privacy= ]=20 - #228 Re-randomize TreeKEM keys (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/228 [performance] [securit= y]=20 - #93 State resync (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/93 [enhancement] [security= ] [work in progress]=20 - #92 ACK / NACK (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/92 [enhancement]=20 - #76 Retry considerations (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/76 [enhancement] [performa= nce] [recommendation]=20 6 issues closed: - State resync https://github.com/mlswg/mls-protocol/issues/93 [enhanceme= nt] [security] [work in progress]=20 - Retry considerations https://github.com/mlswg/mls-protocol/issues/76 [e= nhancement] [performance] [recommendation]=20 - Re-randomize TreeKEM keys https://github.com/mlswg/mls-protocol/issues/= 228 [performance] [security]=20 - ACK / NACK https://github.com/mlswg/mls-protocol/issues/92 [enhancement= ]=20 - Add/Welcome message should send the epoch secret and not init+commit se= crets https://github.com/mlswg/mls-protocol/issues/277 [bug] [security] [wo= rk in progress]=20 - How to derive group_info_key from the init_secret https://github.com/ml= swg/mls-protocol/issues/293 [bug] [editorial] [security]=20 Pull requests ------------- * mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - Small fixes (by Flowdalic) https://github.com/mlswg/mls-architecture/pull/60=20 1 pull requests received 1 new comments: - #60 Small fixes (1 by beurdouche) https://github.com/mlswg/mls-architecture/pull/60=20 1 pull requests merged: - Small fixes https://github.com/mlswg/mls-architecture/pull/60=20 * mlswg/mls-protocol (+2/-2/=F0=9F=92=AC11) 2 pull requests submitted: - Use path secret instead of full DirectPath (by bifurcation) https://github.com/mlswg/mls-protocol/pull/295=20 - Re-define direct path to not include the leaf. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/294=20 8 pull requests received 11 new comments: - #295 Use path secret instead of full DirectPath (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/295=20 - #287 Switch to signing strategy using one signature per leaf. (2 by bif= urcation, raphaelrobert) https://github.com/mlswg/mls-protocol/pull/287 [discussion] [enhancemen= t] [performance] [security] [today! (?)]=20 - #285 Get rid of ignored proposals. (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/285 [? invalid] [discussion]= [security]=20 - #283 Use the same ratchet for Handshake and Application keys (1 by bifu= rcation) https://github.com/mlswg/mls-protocol/pull/283 [discussion] [privacy] [= security] [today! (?)]=20 - #281 Extend the epoch with a commit hash (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/281 [discussion] [functional= ity]=20 - #247 Welcome confirmation and key derivation (3 by beurdouche, bifurcat= ion) https://github.com/mlswg/mls-protocol/pull/247 [enhancement] [security]= =20 - #246 Bugfixes in ClientInitKey, Commit, and Welcome (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/246 [today! (?)]=20 - #245 Unpredictable epochs (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/245 [privacy] [work in progr= ess]=20 2 pull requests merged: - Welcome confirmation and key derivation https://github.com/mlswg/mls-protocol/pull/247 [enhancement] [security]= =20 - Bugfixes in ClientInitKey, Commit, and Welcome https://github.com/mlswg/mls-protocol/pull/246 [today! (?)]=20 * mlswg/mls-federation (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - Spelling fixes in various sections. (by GaPhil) https://github.com/mlswg/mls-federation/pull/4=20 1 pull requests received 1 new comments: - #3 Spelling fixes in various sections. (1 by GaPhil) https://github.com/mlswg/mls-federation/pull/3=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============8282808999450106467== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday February 02, 2020

Issues

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

1 issues created:

7 issues received 10 new comments:

6 issues closed:

Pull requests

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

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

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

2 pull requests submitted:

8 pull requests received 11 new comments:

2 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============8282808999450106467==-- From nobody Tue Feb 4 02:21:22 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6BC120802 for ; Tue, 4 Feb 2020 02:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GYkMt0Cvgjt for ; Tue, 4 Feb 2020 02:21:19 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 41CCC12026E for ; Tue, 4 Feb 2020 02:21:19 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id j20so17333877qka.10 for ; Tue, 04 Feb 2020 02:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=bM4qzaQJERp7cahmrCab+9zHvRgtsdNBmbFZgAjXTFE=; b=Y6gMW9yD+BN+01MfKPUkjBs1Q8bv07Row+XbX41AKQp4iootV3jreXWe502qJuDhnV +dmui7O9UHZg8V1whzjIuNKhA588uXDul7BOjfbJiPtQjB+sAzZDn/cKkcHo/ls1ulj7 dbLvk1fEEeiyTqcVoW+4ePbQIS3RG6Vw6SP9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=bM4qzaQJERp7cahmrCab+9zHvRgtsdNBmbFZgAjXTFE=; b=V0KuZK3MD3ILjLBV8gdnrWUcukVPXhXyPc+QYd1p5hQVBR9nQg47gHKfGTzN7uMzV4 dcZcf/xfwa55hqSKx+j2U6hFsedMMQE0WUH8NyuTFp+0PMNxSjiUn4Q8fsOJAeb2iI65 BoC5K1HSnrQ6Q/1wvG6Z/reCKhrG/A8z26eDMIsURx2/h7+h3lQEUjF1hklL3IYkQ5RH mSIaBiTizn2IvVgk/3VW14xblQS/Yb4n3prUDEmFZ2tf5ib8Dm5VoeS4gsveSaA4BOJQ 6rG0BzrJ+qetI4OyeGG/ZiIOhWvpWXbypyr2ofN8YuHJk0QbbRBoUcjYMxVucBzsMgLx O4OA== X-Gm-Message-State: APjAAAWqSiDE4PcD6XadNv7TaD6RNMlK6sv1S/aNbmkUNdL2L90LfnA+ ortCrliOMTArb+TsBkeJvuaU9k5U19tLPQ== X-Google-Smtp-Source: APXvYqynonx9DxWSX9WL/ndEu+5upT3oajQzTeg9fNglfCkDoW8U1OQjAkmkn1lhp/VzFX8gfWJmOA== X-Received: by 2002:a37:496:: with SMTP id 144mr27870704qke.338.1580811678075; Tue, 04 Feb 2020 02:21:18 -0800 (PST) Received: from [5.5.33.207] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id 65sm11723941qtf.95.2020.02.04.02.21.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Feb 2020 02:21:17 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 4 Feb 2020 11:21:14 +0100 References: To: Messaging Layer Security WG In-Reply-To: Message-Id: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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, 04 Feb 2020 10:21:21 -0000 As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. spt > On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >=20 > As a reminder, the recurring virtual interim is tomorrow. Here's the = meeting information: >=20 > Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= > Meeting number: 647 391 156 > Password: ve2i8niw >=20 > = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >=20 > Nick & Sean >=20 > On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: > It looks like Wednesday at 1400-1500 GMT is the least bad time. >=20 > These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >=20 > Here's the proposed schedule (subject to AD approval): > Time: 1400-1500 GMT on Wednesdays > Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >=20 > Links to the conference calls are forthcoming. >=20 > Nick & Sean >=20 > On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes wrote: > Also: Note that despite this poll listing specific dates, the intent = is to set up a weekly recurring meeting. In fact, these dates will = definitely not be the dates when the calls happen, because IETF requires = one week notice. >=20 > On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes wrote: > I would like to have some weekly calls to make faster progress on our = outstanding PRs. Here's a Doodle to find a good time: >=20 > https://doodle.com/poll/bg2q65phrvfip5zb >=20 > I believe these will need to be official Virtual Interims per IETF = process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >=20 > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Feb 4 02:45:14 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 097EA1200B8; Tue, 4 Feb 2020 02:45:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mls-chairs@ietf.org, mls@ietf.org, kaduk@mit.edu, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158081311300.15789.12162810192407292883.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 02:45:13 -0800 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 107 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: Tue, 04 Feb 2020 10:45:13 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack Key Participant Conflict: acme artarea dispatch perc People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: Chair Conflict: Privacy Pass BOF --------------------------------------------------------- From nobody Tue Feb 4 06:49:07 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 545671200CD; Tue, 4 Feb 2020 06:49:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082774312.15751.17900557711809243682@ietfa.amsl.com> Date: Tue, 04 Feb 2020 06:49:03 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-02-05 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: Tue, 04 Feb 2020 14:49:04 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-02-05 from 14:00 to 15:00 UTC. Agenda: https://github.com/mlswg/mls-protocol/issues Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc28a32b8935538c4da2de0587e4c4810 From nobody Tue Feb 4 06:49:33 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43350120142; Tue, 4 Feb 2020 06:49:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082776323.15811.816375655554041703@ietfa.amsl.com> Date: Tue, 04 Feb 2020 06:49:23 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-02-12 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: Tue, 04 Feb 2020 14:49:29 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-02-12 from 14:00 to 15:00 UTC. Agenda: https://github.com/mlswg/mls-protocol/issues Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc28a32b8935538c4da2de0587e4c4810 From nobody Tue Feb 4 06:52:32 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBAD120105; Tue, 4 Feb 2020 06:52:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082794697.15768.1774469128727806044@ietfa.amsl.com> Date: Tue, 04 Feb 2020 06:52:27 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-02-19 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: Tue, 04 Feb 2020 14:52:27 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-02-19 from 14:00 to 15:00 UTC. Agenda: https://github.com/mlswg/mls-protocol/issues Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc28a32b8935538c4da2de0587e4c4810 From nobody Tue Feb 4 06:52:51 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C01207FF; Tue, 4 Feb 2020 06:52:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082796049.15772.7228535781786473683@ietfa.amsl.com> Date: Tue, 04 Feb 2020 06:52:40 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-02-26 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: Tue, 04 Feb 2020 14:52:47 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-02-26 from 14:00 to 15:00 UTC. Agenda: https://github.com/mlswg/mls-protocol/issues Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc28a32b8935538c4da2de0587e4c4810 From nobody Tue Feb 4 06:52:59 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE481201C6; Tue, 4 Feb 2020 06:52:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082797075.15828.11706642423272528785@ietfa.amsl.com> Date: Tue, 04 Feb 2020 06:52:50 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-03-04 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: Tue, 04 Feb 2020 14:52:57 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-03-04 from 14:00 to 15:00 UTC. Agenda: https://github.com/mlswg/mls-protocol/issues Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc28a32b8935538c4da2de0587e4c4810 From nobody Tue Feb 4 06:53:10 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1F9120232; Tue, 4 Feb 2020 06:53:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082798042.15730.549332319790591656@ietfa.amsl.com> Date: Tue, 04 Feb 2020 06:53:00 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-03-11 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 14:53:07 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-03-11 from 14:00 to 15:00 UTC. Agenda: https://github.com/mlswg/mls-protocol/issues Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc28a32b8935538c4da2de0587e4c4810 From nobody Tue Feb 4 06:53:32 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA7120829; Tue, 4 Feb 2020 06:53:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158082799509.15702.17160079324013869954@ietfa.amsl.com> Date: Tue, 04 Feb 2020 06:53:15 -0800 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-03-18 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: Tue, 04 Feb 2020 14:53:21 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-03-18 from 14:00 to 15:00 UTC. Agenda: https://github.com/mlswg/mls-protocol/issues Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc28a32b8935538c4da2de0587e4c4810 From nobody Tue Feb 4 07:57:46 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 536FD12012E; Tue, 4 Feb 2020 07:57:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: mls@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158083186232.15681.15549333790336509264@ietfa.amsl.com> Date: Tue, 04 Feb 2020 07:57:42 -0800 Archived-At: Subject: [MLS] IPR Disclosure Sean Turner's Statement about IPR related to draft-ietf-mls-protocol belonging to Qrypt Inc 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: Tue, 04 Feb 2020 15:57:43 -0000 Dear Richard Barnes, Benjamin Beurdouche, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert: An IPR disclosure that pertains to your Internet-Draft entitled "The Messaging Layer Security (MLS) Protocol" (draft-ietf-mls-protocol) was submitted to the IETF Secretariat on 2020-02-04 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4015/). The title of the IPR disclosure is "Sean Turner's Statement about IPR related to draft-ietf-mls-protocol belonging to Qrypt Inc" Thank you IETF Secretariat From nobody Wed Feb 5 07:07:10 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4F1200C7 for ; Wed, 5 Feb 2020 07:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Gs0FTsRU-dy1 for ; Wed, 5 Feb 2020 07:07:06 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888D61200F6 for ; Wed, 5 Feb 2020 07:07:06 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id b7so2107823qkl.7 for ; Wed, 05 Feb 2020 07:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=eBc2CHms9fwbRVG53PTZVjWwocU/96upcoV7iikCjWg=; b=dQhB4ok456c4D+boTLEyBljgGgM/qERd7eLuezA6/argU7Upyqo/Igo4MXbWIvOXgK T+cOVPPPmES8R5npViBs+e1qDI3twF/vhqqb3noaCDI33pjq5aR3M09Y0djiQZRqaUKs VQFZxZ3JyNGZuM12RZ21UkSjHC44D8gup65tQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=eBc2CHms9fwbRVG53PTZVjWwocU/96upcoV7iikCjWg=; b=cq+wnZRx4+ahsHx1CUM9cHWCdZaiEJrfbZ4h6ojFwuDeJqlEA/x2ZLCi7p0nNxojrx CBhtF56DzXCurmbMTuqb+oTiVLA/NuWlCwSeeAtslc6886f+rc4o2fBAA6/dHuzDDdXP UeNo2kyC25Id3J37CVZyMjzDs4v4pXqmWnyv+W2kbirBbr5MbQFLVaZtFnsgJBCIrTSV MaDgtldFoybY0pnZdZ/xhVELcsWBpN1UCYiYxlrqCTU/6eQa63Gjuz6JW+Dz4X0FcQ+L 5xGv2HQrTn0DLDymjp6HGuSM0x9QivTfa5twyNAqC+Jt75jyzkTK/4Dj5FPOuavk3a38 alZw== X-Gm-Message-State: APjAAAW/k6/zg0MiyIdIoLqgY0K6bGRIEB66o/OvrIlj9I0ngCAdk1Rp 3fQ1gHPMX4yat+nv26zKKcUZ16+VIAes14YY X-Google-Smtp-Source: APXvYqzKfehJtIPbrLIbp07gHSLCQZLQ9rMcdaOTI5H/hQ/3RPhSeYmxTj9ISzlZI0654n2igyUroQ== X-Received: by 2002:a37:a915:: with SMTP id s21mr17115594qke.112.1580915225475; Wed, 05 Feb 2020 07:07:05 -0800 (PST) Received: from [5.5.33.179] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id h3sm4982511qkk.104.2020.02.05.07.07.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Feb 2020 07:07:05 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 5 Feb 2020 16:07:02 +0100 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> Message-Id: <3EC63318-2829-4694-A885-E471A7AC70DF@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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: Wed, 05 Feb 2020 15:07:09 -0000 Thanks to Richard, Britta, Raphael, and Brandon for dialing in. We = reviewed the following PRs: - https://github.com/mlswg/mls-protocol/pull/279 - https://github.com/mlswg/mls-protocol/pull/285 - https://github.com/mlswg/mls-protocol/pull/286 - https://github.com/mlswg/mls-protocol/pull/294 - https://github.com/mlswg/mls-protocol/pull/295 More info once the minutes pop out (thanks Richard). spt > On Feb 4, 2020, at 11:21, Sean Turner wrote: >=20 > As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >=20 > spt >=20 >> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>=20 >> As a reminder, the recurring virtual interim is tomorrow. Here's the = meeting information: >>=20 >> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >> Meeting number: 647 391 156 >> Password: ve2i8niw >>=20 >> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>=20 >> Nick & Sean >>=20 >> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>=20 >> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>=20 >> Here's the proposed schedule (subject to AD approval): >> Time: 1400-1500 GMT on Wednesdays >> Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >>=20 >> Links to the conference calls are forthcoming. >>=20 >> Nick & Sean >>=20 >> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes wrote: >> Also: Note that despite this poll listing specific dates, the intent = is to set up a weekly recurring meeting. In fact, these dates will = definitely not be the dates when the calls happen, because IETF requires = one week notice. >>=20 >> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes wrote: >> I would like to have some weekly calls to make faster progress on our = outstanding PRs. Here's a Doodle to find a good time: >>=20 >> https://doodle.com/poll/bg2q65phrvfip5zb >>=20 >> I believe these will need to be official Virtual Interims per IETF = process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>=20 >> --Richard >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Wed Feb 5 09:14:19 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE0C12085D for ; Wed, 5 Feb 2020 09:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRVVuO34yE8w for ; Wed, 5 Feb 2020 09:14:14 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0209120860 for ; Wed, 5 Feb 2020 09:14:13 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id g3so2592573qka.1 for ; Wed, 05 Feb 2020 09:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RRmfedsYZaIIhvWB4Iy+fMFgH7AAVq3YngzM3OYyCG8=; b=Y2bOAjqiN+oIYyz9C0tF4t+OiqlDd/QM4m2W4F7jQzOOCg2Kev+pxGUaYq95d+BROy fsPJD/7zwaSF6LmIQpMnUCjwrdyw7vXM98V5u+8MEHFJ3x/m7UqFR5VOzPRl/jQUeepY P83yxysACrU2MR3dQ0UvrdxrR1/4FrypDNyWp8B1daPMENesNmkPAmYZSd1KdNEwKNuY BHzufv0Gxq+K5NhIpXEMx2zP88V/FCYw5Ku87dH9pt8VmO6kk8VyZYOCFE27BFY5Kcg4 uZ1e9cneyBH0Oa40bK/i3GS3S/bTVFSh83dD+O1SyX/2xjwxwRh10VUdnkhHNQfGghyY YzJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RRmfedsYZaIIhvWB4Iy+fMFgH7AAVq3YngzM3OYyCG8=; b=rcqcdOX/bajCCD0rHoW2lQby4iNLj2E/Bs86rfCX7/IMjfy+mT+oSU0S5MZaysvC3K MnmKq60WDiX0doCrfypSm2OLxR5agepV7qr/T09a98XyUPZTMuV0NIhzR8XC+Fb9Gf79 af4yj8IPIXtXmUw4KZkiogub9mWMurzu8A3ns+y5fDY1OJz6GZIWHnBsR9blgQyruqaV 2w2peJOcQYdsFcZXOuiv26NlwaxMPLa8/y+PA24G/rqDn07Ty9Cj3D88grz5D4Yh/pIS gmBVaGNI/uwJkDiVFbJviF98BFjHUwaGAm4qvOqyAFKlE/P2Tq50QRCUDZUU0MCEIcVa a+vQ== X-Gm-Message-State: APjAAAWrYAdkXNCCgwZ9uBaiC+z5WDvEnglTntVEkxZro1Jy9mJP+95V 6G1DczP0bd6hQJ0SMMqHK8mG8/5pyiWgzWgUb6wzhUmaQjrD0g== X-Google-Smtp-Source: APXvYqx7FAJzqhX6tbGOrQaIOR90KioFBo2tuENZeuZ9lnYejkGD6/diaiLLo+1QZwPXWIwgwDOigoG4T6wE1ZnEh/k= X-Received: by 2002:a37:e308:: with SMTP id y8mr33933165qki.347.1580922852278; Wed, 05 Feb 2020 09:14:12 -0800 (PST) MIME-Version: 1.0 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> <3EC63318-2829-4694-A885-E471A7AC70DF@sn3rd.com> In-Reply-To: <3EC63318-2829-4694-A885-E471A7AC70DF@sn3rd.com> From: Richard Barnes Date: Wed, 5 Feb 2020 12:13:43 -0500 Message-ID: To: Sean Turner Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000071a50059dd7495e" Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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: Wed, 05 Feb 2020 17:14:17 -0000 --000000000000071a50059dd7495e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here are my notes from today: * Attendees: * Richard Barnes * Sean Turner * Brendan McMillion * Britta Hale * Raphael Robert * #287 [ Path-hash ] * Brendan will add OPEN ISSUE * RLB will check with Benjamin that he=E2=80=99s OK with merging with t= he OPEN ISSUE there * #279 [ Ciphersuites ] * Raphael will address the requirements that sig scheme is fixed * Sean will send text about recommending conservatism * Raphael will reserve private space * #285 [ Ignored proposals ] * Brendan to change SHOULDs to MUSTs * #286 [ Committer update ] * Brendan to change Update to ClientInitKey * #294 [ DirectPath does not cover leaf ] * Brendan to make minor changes noted in PR * #295 [ Path -> PathSecret ] * OK to merge * AOB: * Raphael: Mechanism to send targeted messages within a group * Not broadcast, send to subgroup * E.g., read receipts want to go just to sender * RLB: Some issues that could use discussion / PRs On Wed, Feb 5, 2020 at 10:07 AM Sean Turner wrote: > Thanks to Richard, Britta, Raphael, and Brandon for dialing in. We > reviewed the following PRs: > > - https://github.com/mlswg/mls-protocol/pull/279 > - https://github.com/mlswg/mls-protocol/pull/285 > - https://github.com/mlswg/mls-protocol/pull/286 > - https://github.com/mlswg/mls-protocol/pull/294 > - https://github.com/mlswg/mls-protocol/pull/295 > > More info once the minutes pop out (thanks Richard). > > spt > > > On Feb 4, 2020, at 11:21, Sean Turner wrote: > > > > As a reminder, the recurring virtual interim is tomorrow. The > information is the same as last week. > > > > spt > > > >> On Jan 28, 2020, at 23:52, Nick Sullivan 40cloudflare.com@dmarc.ietf.org> wrote: > >> > >> As a reminder, the recurring virtual interim is tomorrow. Here's the > meeting information: > >> > >> Meeting link: > https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc= 6 > >> Meeting number: 647 391 156 > >> Password: ve2i8niw > >> > >> > https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurri= ng > >> > >> Nick & Sean > >> > >> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan > wrote: > >> It looks like Wednesday at 1400-1500 GMT is the least bad time. > >> > >> These calls will be recurring virtual interims, and as such are covere= d > by the note well. As a reminder, decisions made at interim meetings are n= ot > final and must be confirmed on the list. > >> > >> Here's the proposed schedule (subject to AD approval): > >> Time: 1400-1500 GMT on Wednesdays > >> Agenda: the set of active PRs for the active documents on Github ( > https://github.com/mlswg). > >> > >> Links to the conference calls are forthcoming. > >> > >> Nick & Sean > >> > >> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes wrote: > >> Also: Note that despite this poll listing specific dates, the intent i= s > to set up a weekly recurring meeting. In fact, these dates will definite= ly > not be the dates when the calls happen, because IETF requires one week > notice. > >> > >> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes wrote: > >> I would like to have some weekly calls to make faster progress on our > outstanding PRs. Here's a Doodle to find a good time: > >> > >> https://doodle.com/poll/bg2q65phrvfip5zb > >> > >> I believe these will need to be official Virtual Interims per IETF > process. Chairs, I assume you can do whatever announcements are necessar= y > once we pick a time. > >> > >> --Richard > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000071a50059dd7495e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are my notes from today:

* Attendees:
=C2=A0 =C2=A0 * Richard Barnes
=C2=A0 =C2=A0 * Sean Tu= rner
=C2=A0 =C2=A0 * Brendan McMillion
=C2=A0 =C2=A0 * Britta Hale=C2=A0 =C2=A0 * Raphael Robert
* #287 [ Path-hash ]
=C2=A0 =C2=A0 * = Brendan will add OPEN ISSUE
=C2=A0 =C2=A0 * RLB will check with Benjamin= that he=E2=80=99s OK with merging with the OPEN ISSUE there
* #279 [ Ci= phersuites ]
=C2=A0 =C2=A0 * Raphael will address the requirements that = sig scheme is fixed
=C2=A0 =C2=A0 * Sean will send text about recommendi= ng conservatism
=C2=A0 =C2=A0 * Raphael will reserve private space
* = #285 [ Ignored proposals ]
=C2=A0 =C2=A0 * Brendan to change SHOULDs to = MUSTs
* #286 [ Committer update ]
=C2=A0 =C2=A0 * Brendan to change U= pdate to ClientInitKey
* #294 [ DirectPath does not cover leaf ]
=C2= =A0 =C2=A0 * Brendan to make minor changes noted in PR
* #295 [ Path -&g= t; PathSecret ]
=C2=A0 =C2=A0 * OK to merge
* AOB:
=C2=A0 =C2=A0 = * Raphael: Mechanism to send targeted messages within a group
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 * Not broadcast, send to subgroup
=C2=A0 =C2=A0 =C2=A0= =C2=A0 * E.g., read receipts want to go just to sender
=C2=A0 =C2=A0 * = RLB: Some issues that could use discussion / PRs

On Wed, Feb 5, 20= 20 at 10:07 AM Sean Turner <sean@sn3rd= .com> wrote:
Thanks to Richard, Britta, Raphael, and Brandon for dialing in. We revi= ewed the following PRs:

- https://github.com/mlswg/mls-protocol/pull/279 - https://github.com/mlswg/mls-protocol/pull/285 - https://github.com/mlswg/mls-protocol/pull/286 - https://github.com/mlswg/mls-protocol/pull/294 - https://github.com/mlswg/mls-protocol/pull/295
More info once the minutes pop out (thanks Richard).

spt

> On Feb 4, 2020, at 11:21, Sean Turner <sean@sn3rd.com> wrote:
>
> As a reminder, the recurring virtual interim is tomorrow. The informat= ion is the same as last week.
>
> spt
>
>> On Jan 28, 2020, at 23:52, Nick Sullivan <nick=3D40cloudflare.com@dma= rc.ietf.org> wrote:
>>
>> As a reminder, the recurring virtual interim is tomorrow. Here'= ;s the meeting information:
>>
>> Meeting link: htt= ps://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6=
>> Meeting number: 647 391 156
>> Password: ve2i8niw
>>
>> https://github.c= om/mlswg/wg-materials/tree/master/virtual-interim-recurring
>>
>> Nick & Sean
>>
>> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan <nick@cloudflare.com> wrote= :
>> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>
>> These calls will be recurring virtual interims, and as such are co= vered by the note well. As a reminder, decisions made at interim meetings a= re not final and must be confirmed on the list.
>>
>> Here's the proposed schedule (subject to AD approval):
>> Time: 1400-1500 GMT on Wednesdays
>> Agenda: the set of active PRs for the active documents on Github (= h= ttps://github.com/mlswg).
>>
>> Links to the conference calls are forthcoming.
>>
>> Nick & Sean
>>
>> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes <rlb@ipv.sx> = wrote:
>> Also: Note that despite this poll listing specific dates, the inte= nt is to set up a weekly recurring meeting.=C2=A0 In fact, these dates will= definitely not be the dates when the calls happen, because IETF requires o= ne week notice.
>>
>> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes <rlb@ipv.sx> = wrote:
>> I would like to have some weekly calls to make faster progress on = our outstanding PRs.=C2=A0 Here's a Doodle to find a good time:
>>
>> https://doodle.com/poll/bg2q65phrvfip5zb
>>
>> I believe these will need to be official Virtual Interims per IETF= process.=C2=A0 Chairs, I assume you can do whatever announcements are nece= ssary once we pick a time.
>>
>> --Richard
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org=
>> https://www.ietf.org/mailman/listinfo/mls
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org=
>> https://www.ietf.org/mailman/listinfo/mls
>

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000071a50059dd7495e-- From nobody Thu Feb 6 08:08:10 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA82120921 for ; Thu, 6 Feb 2020 08:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 7k3t6MK3KjGJ for ; Thu, 6 Feb 2020 08:08:06 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B66B12089F for ; Thu, 6 Feb 2020 08:08:06 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id b7so6032068qkl.7 for ; Thu, 06 Feb 2020 08:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=+EQyUSB/Qqso8vtBMyhpEKcSGPyGQvaXvD7IaqSAlsw=; b=SPAEWtK2Hul5cud2XCV/kVKGAH7I1iGcsc+YN6i8sIDoVfU1InmeM1O/Zwv6rqj+YY BeZCNjHLygwWfCAWj1N1ezcB2h2W76JMjRZ/ZA90OlXvAdfJ1w2+AqrnKyhWL2T4sX9H UcLOmSxhGqAWj6UTr+moBYhqALRL42u40FbD0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=+EQyUSB/Qqso8vtBMyhpEKcSGPyGQvaXvD7IaqSAlsw=; b=ZQMOkY+J/AgWYBNvLWeMB85Ntbdkr80/hvS/4EM5kNpF/38I/TpzPJ76U9PUxRNA2i zwUYp1IrNnaPnDxmkMJQaqf2D73LuLA89JgOzFCXh7AJBXtKYHEE68pJEe/hAw8HUnek eY9BE3es4prQc1A4PtNsfCIGvwoUTKWVLKA84MytTdvuwng9xDGIvlxAWckYkNkOMgAx 0UrhPtWWplWFxZbinpRcxT2wCCDuLkUzFvjzhbeaGuKlDo3yXnN2V9hDAAbq5MRk2xeH ilr65OyQS8ITXb+y4ZOlsGkpTYkGPK1x/aql2cc9V3Z4Lsat2JjFpEShXAQbNFxY0syS IgCw== X-Gm-Message-State: APjAAAVdJPhISJeRlTlGwK5x96BmN4AUk2ZEoTpwgYAgmMfzkJ3QVgaK EC4pCDr0a9RjuXqewC8kAkHkv2PD7iibJr52 X-Google-Smtp-Source: APXvYqxHrJk8QSdHiYpyjoUnfXNNRElCyr75lmD14dBfwLREWQzEEiZeFrtacuR8ODgdYQxYEVPXSg== X-Received: by 2002:a37:a03:: with SMTP id 3mr3173744qkk.336.1581005284984; Thu, 06 Feb 2020 08:08:04 -0800 (PST) Received: from [5.5.33.193] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id h3sm1609375qkk.104.2020.02.06.08.08.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 08:08:04 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 6 Feb 2020 17:08:00 +0100 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] confirming cipher suites decisions 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, 06 Feb 2020 16:08:09 -0000 Hi! tl;dr: confirming MTI suite selections and rationale for avoiding = proliferation During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. There was rough agreement that there should be one signature scheme per = group and that should be driven by the cipher suite. There are, at = least, three things to consider: 1) if a potential group member does not = support the algorithm, then they will not become a member or the group = will need to downgrade; 2) when the group needs/wants to update, it is a = flag day; and, 3) the cipher suites will have a similar combinatorial = issues as the TLS cipher suites prior to TLS 1.3. The agreement was = =E2=80=9Crough=E2=80=9D because 1) likely has some important = implications. The MLS cipher suites defined were as follows:=20 - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 At the interim, the consensus was to make the non-NIST suites the MTI. = The rationale was that those implementation that need to be NIST = compliant will do so regardless of the choice made by the WG. In looking at the actual cipher suites, it was noted that the 256-bit = schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 = is SHA-512 cut in half, so just do SHA-512 because it is one less = operation. To avoid the proliferation of cipher suites, guidance will be provided = to be conservative about allocating new code points. The consensus at = the interim was that the suites provided were minimal and provided good = coverage for the known use cases: - (X25519, AES-GCM, Ed25519) - Good for desktop - (P-256, AES-GCM, P-256) - Compliance - (X25519, ChachaPoly, Ed25519) - Good for mobile The chairs need to confirm the interim=E2=80=99s consensus on list, so = please let the WG know by 2359 UTC 20 February whether you disagree with = these choices and why. NOTE: The final text will obviously be reviewed, but is being composed = as part of the following PR: https://github.com/mlswg/mls-protocol/pull/279 NOTE: We combined these cipher suite related consensus points, but if we = only come to consensus on some of these we can still incorporate what we = do agree on. Cheers, Nick and Sean= From nobody Thu Feb 6 08:08:14 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B312089F for ; Thu, 6 Feb 2020 08:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 azSbUlzWRJfb for ; Thu, 6 Feb 2020 08:08:09 -0800 (PST) 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 EC049120918 for ; Thu, 6 Feb 2020 08:08:08 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id v195so6010393qkb.11 for ; Thu, 06 Feb 2020 08:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=42frJD93M66fujJ4nT+L8k9z/N2MmXd+sPT7SYqC9gw=; b=eG2gwfc++2UjlF+hOaJrsexVBsVu3yy8IqUQikM0hM4l7YEtYRs5wdIupahV+IijGE OCFFEtosrHmys2kJmKV6tczK+x1c2QwGGFcTS9nEB/LNZwFHzCH3rumjRwUe6OHE+i5W b/eF1hiGAGORkNRmCLXT0ylMllpFAxYFdL8mQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=42frJD93M66fujJ4nT+L8k9z/N2MmXd+sPT7SYqC9gw=; b=TDgpWYyMTkfEgl1T7H/vtcxXuciLJQ1EAxPH4yp1yt2n/IkZ9FW3a+z4n4p5axfNbv ZPwlzeIlMnk0GeKIL9U4s3dS+ByDyyFUjlLbBI6ScQqwIR6K/zPECB7vkcjudo49p+WQ qfzoOo3vyZhFogSlN85ajS/hHzXEq8qKpn2aVCfdXfOeUAEkXhZR2IAsWdvGgLVFmcpj 1z9KMbx6WSEo9sm93EezbIJf4D9I2VwdtXklE3ofjaJn49G/0+uHCEnd2pXo2qoZfkv/ JGuapAyK1KeJZRgUrKvjtxHVqAVjpamG4HFEhQtsFnwUwInxPtsTJbcdRtYzTg7z5fLu xeBA== X-Gm-Message-State: APjAAAWCgBfpb94C1zuYakY9M0NNoOJxPAmoa03KlDgd+ZzUGGjjoYG/ J8ZJeZNUFmK12QEUdCLR1o1xc09oZjFm6voa X-Google-Smtp-Source: APXvYqyVuultLT6rhEpVrMJHJjEujN9HwEuyOoOr0CzrKJu8n0kppUG+JjW4fB65YZAfZpaNPf2Vpg== X-Received: by 2002:a37:8e45:: with SMTP id q66mr1065946qkd.129.1581005286785; Thu, 06 Feb 2020 08:08:06 -0800 (PST) Received: from [5.5.33.193] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id h3sm1609375qkk.104.2020.02.06.08.08.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 08:08:05 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 6 Feb 2020 17:08:04 +0100 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] confirming server assist way forward 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, 06 Feb 2020 16:08:13 -0000 Hi! tl;dr: confirming new individual draft to describe server assist. During the F2F Interim in January, the WG had a lengthy discussion about = server assist. We wrestled with the tussle between privacy and the = desire to support very large groups, which just about everybody, if not = everybody, believes requires some type of server assist because adding a = new member to a large group requires sending megabytes of data in the = Welcome message and this can be too much for some devices. Normally, the = AS and DS is split and maybe these functions are collapsed in IRL, but = Benjamin suggested that we split the functionality up a bit more to talk = more fine-grained about the guarantees we want. The functional split = suggested was as follows [0]: - AS: Authentication Service (Signature Keys) - DS: Delivery Service -- CS: Credential Retrieval Service (CIKs) -- IDS: Message Reception Service (Input) --- IDS is responsible for message ordering. -- ODS: Message Delivery Service (Output) --- IDS and ODS may be combined. - SDS: Storage Delivery Service (Welcome+Backup) -- SDS is optional. Likewise, they suggested that we switch from a model where there is one = queue per group, to one queue per recipient. The consensus at the interim was that it is important to support server = assist and that it was equally important to provide truth in = advertising, i.e., those that implement the functionality need to = understand the security guarantees that are available. There was also consensus to produce an individual draft that describes = server assist. After this draft is published, the WG can review it and = decide whether it should be accepted as a workable starting point and = potential WG item. The chairs need to confirm the interim=E2=80=99s consensus on list, so = please let the WG know by 2359 UTC 20 February whether you disagree with = the way forward and why. FYI: Benjamin and Raphael volunteered to write this draft. Cheers, Nick and Sean [0] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/04-archi= tecture.pdf [1] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/minutes.= md= From nobody Thu Feb 6 08:08:20 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8250E120952 for ; Thu, 6 Feb 2020 08:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Z6hfXShXuwce for ; Thu, 6 Feb 2020 08:08:10 -0800 (PST) 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 0F21F120921 for ; Thu, 6 Feb 2020 08:08:10 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id db9so3103236qvb.3 for ; Thu, 06 Feb 2020 08:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=B8/ySKe8xCa1F+ZKWx7wu77POMi3PKHXhrQZg5GFsbA=; b=j1nCC8nUKrSB/zMbGTxI26DmR2mDE7meds8EGw538bg+VDfbEy9nMGJrdWUq9rUhqp Ia4hzm1y2sud/4M7Q1YYOrLdFgD/Ddv43IO5t35v9IE6xSAmK4u4pWew8Qqdsbf9/zKe M2hr25p/3fAwBq1pIgwPJyycXGfNZBb3AZj/o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=B8/ySKe8xCa1F+ZKWx7wu77POMi3PKHXhrQZg5GFsbA=; b=UFhuwbGRva9y315ei/rpk8yuwDYv9KeibdX2F+1U/KISogLlK2bKawS4oAlvZ7QOVE 6YOii6te7JfatJ3yEn6dpJ99lZ22hOtvO2TrKl0c6Nhwsq6lo01Ik3/b9y74qZ8goxVf PRO4u3JlSXChxWG0grRB9DbxHYCYPm/hipXR5akJhraTXrRRfvlPlrVMLyjbiriqmHVG K7YpJwICcQ0nVmW9FDHCJpwE6MCuVXlXJejL+BaGOL4Q47JOIbKkZjyLopqJ/Xi8xIuQ gIxP1M8YhRHYYlQbqYPFpyiSa/fGttw/V/mv40hFTwavcOQde03EvtpQcv62Fq89VGff eEUw== X-Gm-Message-State: APjAAAXtIm77PxEiwbdXMAgQVqCWeoUfXNmd1PeE71jC3ZoGPwnh6HLe NorJjOYC/e9gdMmbZE0hleSjkh8oRBQgQ0LZ X-Google-Smtp-Source: APXvYqxd9iPCK3qSjrXyaIP6UKgcWeHGn3vVn/b68w0XSCOnwA4MYbpdUSchrcrYicBxFAWgZOOI+A== X-Received: by 2002:a05:6214:94b:: with SMTP id dn11mr2891905qvb.12.1581005288492; Thu, 06 Feb 2020 08:08:08 -0800 (PST) Received: from [5.5.33.193] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id h3sm1609375qkk.104.2020.02.06.08.08.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 08:08:07 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 6 Feb 2020 17:08:06 +0100 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] confirming state recovery way forward 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, 06 Feb 2020 16:08:15 -0000 Hi! tl;dr: confirming new individual draft that describes state recovery = (i.e., the need for ACKs/NACKs). During the F2F Interim in January, the WG discussed how to address state = recovery. One reason you might want ACKs/NACKS is if you sent a Commit = and then some data, and the Commit is lost. In this case, your data = didn=E2=80=99t get sent and the data needs to be resent. There are = obvious implications because messages shouldn=E2=80=99t just be re-sent = to the group after many months. After a lengthy discussion about this = and other synchronization issues, the consensus at the interim was that = an individual draft is needed to describe state recovery-related issues. = After this draft is published, the WG can review it and decide whether = it should be accepted as a workable starting point and potential WG item = or be merged into an existing draft. The chairs need to confirm the interim=E2=80=99s consensus on list, so = please let the WG know by 2359 UTC 20 February whether you disagree with = the way forward and why. FYI: Jon and Emad volunteered to write this draft. Cheers, Nick and Sean= From nobody Fri Feb 7 05:52:25 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9BE120879 for ; Fri, 7 Feb 2020 05:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=bW9sw/pE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ikhFUIXz 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 10Yfc_7p6Db1 for ; Fri, 7 Feb 2020 05:52:22 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DD5120859 for ; Fri, 7 Feb 2020 05:52:21 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 142B721903; Fri, 7 Feb 2020 08:52:21 -0500 (EST) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Fri, 07 Feb 2020 08:52:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=mesmtp; bh=fG Ryk0aybwKGMjg++uEE/JmEF71tyHekiSTpJ7s1uco=; b=bW9sw/pEEFYlDBycwA h8DUKpir5cQp7CyQ9awXAVQEcGl4SRqkeGF4PHfwegn3zkjr+oRUzgQjb/gX6A+3 hrKxIUI9w4Gx3ofNJ+va1qk7q6JBGgE5A+iFDiIIJhx7BY8IjjsrYWc8d/T6gNhS Xi6WF8V/EyAReEA4A0OkJmjFs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=fGRyk0aybwKGMjg++uEE/JmEF71tyHekiSTpJ7s1u co=; b=ikhFUIXzKXDX6fsEQYgVbUBW7Ivne6M/6rcOHNTFvrXkWCRYy6i4o7k2K 3XRWhuw/JGv2KJcuHAzl7dOgEKuRxZ/HRzYCXRI/cC0RA+CtrRrCaedK1zhtf8+k d0+rr7aI/+nd79Q9BG0ph6VkDh2O1Q9KzDGTs5RQ6CKzAegNIAEMIade2fB9TogF wA2/huoJ6JVFbWUmZqOJK8HYAPQFGvHxb/+IAuVtNC9mYsGR1CxGWISjopnVkdNK THzXHt9Y/Pn8jE2/iKh9aT1leiTntua1fm5IAineBCrx+jzoLlWRkcTJqrm2lz18 4ZMlS+KbGL6qzZvwyM0bEpszpHF0Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheehgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfmrght rhhivghlucevohhhnhdqifhorhguohhnfdcuoehmvgeskhgrthhrihgvlhdrtghordhukh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmvgeskhgrthhrihgvlhdrtghordhukh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0C92F14C00F5; Fri, 7 Feb 2020 08:52:19 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <5302114f-dd8d-46e9-a345-d5f8110dab28@www.fastmail.com> In-Reply-To: References: Date: Fri, 07 Feb 2020 13:51:59 +0000 From: "Katriel Cohn-Gordon" To: "Sean Turner" , "Messaging Layer Security WG" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] confirming state recovery way forward X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 13:52:24 -0000 I support this effort: this is one of the places where the gap between a= nalysis and implementation is quite large, because all reliable messagin= g systems have a form of state recovery. While we can't necessarily fix = all the issues, writing them up with a goal of at least making sure peop= le are aware of them seems like a very good idea to me. On Thu, 6 Feb 2020, at 4:08 PM, Sean Turner wrote: > Hi! >=20 > tl;dr: confirming new individual draft that describes state recovery=20= > (i.e., the need for ACKs/NACKs). >=20 > During the F2F Interim in January, the WG discussed how to address=20 > state recovery. One reason you might want ACKs/NACKS is if you sent a=20= > Commit and then some data, and the Commit is lost. In this case, your=20= > data didn=E2=80=99t get sent and the data needs to be resent. There ar= e obvious=20 > implications because messages shouldn=E2=80=99t just be re-sent to the= group=20 > after many months. After a lengthy discussion about this and other=20 > synchronization issues, the consensus at the interim was that an=20 > individual draft is needed to describe state recovery-related issues.=20= > After this draft is published, the WG can review it and decide whether= =20 > it should be accepted as a workable starting point and potential WG=20= > item or be merged into an existing draft. >=20 > The chairs need to confirm the interim=E2=80=99s consensus on list, so= please=20 > let the WG know by 2359 UTC 20 February whether you disagree with the=20= > way forward and why. >=20 > FYI: Jon and Emad volunteered to write this draft. >=20 > Cheers, > Nick and Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Fri Feb 7 05:55:25 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A809A120859 for ; Fri, 7 Feb 2020 05:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4zyXIlDRJGd for ; Fri, 7 Feb 2020 05:55:21 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340B4120048 for ; Fri, 7 Feb 2020 05:55:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,413,1574118000"; d="scan'208";a="434949973" Received: from corp-nat.untrust.par2.mozilla.com (HELO [10.235.30.91]) ([185.155.183.198]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2020 14:55:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Benjamin Beurdouche In-Reply-To: <5302114f-dd8d-46e9-a345-d5f8110dab28@www.fastmail.com> Date: Fri, 7 Feb 2020 14:55:18 +0100 Cc: Sean Turner , ML Messaging Layer Security Content-Transfer-Encoding: quoted-printable Message-Id: <1EBA4C86-C99F-4154-B83E-C21F99F67A8E@inria.fr> References: <5302114f-dd8d-46e9-a345-d5f8110dab28@www.fastmail.com> To: Katriel Cohn-Gordon X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming state recovery way forward X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 13:55:24 -0000 I agree with Katriel and support this effort, writing down requirements and explore possible solutions to determine possible impact on the security goals feels like a good way to make progress=E2=80=A6 B. > On 7 Feb 2020, at 14:51, Katriel Cohn-Gordon wrote: >=20 > I support this effort: this is one of the places where the gap between = analysis and implementation is quite large, because all reliable = messaging systems have a form of state recovery. While we can't = necessarily fix all the issues, writing them up with a goal of at least = making sure people are aware of them seems like a very good idea to me. >=20 > On Thu, 6 Feb 2020, at 4:08 PM, Sean Turner wrote: >> Hi! >>=20 >> tl;dr: confirming new individual draft that describes state recovery=20= >> (i.e., the need for ACKs/NACKs). >>=20 >> During the F2F Interim in January, the WG discussed how to address=20 >> state recovery. One reason you might want ACKs/NACKS is if you sent a=20= >> Commit and then some data, and the Commit is lost. In this case, your=20= >> data didn=E2=80=99t get sent and the data needs to be resent. There = are obvious=20 >> implications because messages shouldn=E2=80=99t just be re-sent to = the group=20 >> after many months. After a lengthy discussion about this and other=20 >> synchronization issues, the consensus at the interim was that an=20 >> individual draft is needed to describe state recovery-related issues.=20= >> After this draft is published, the WG can review it and decide = whether=20 >> it should be accepted as a workable starting point and potential WG=20= >> item or be merged into an existing draft. >>=20 >> The chairs need to confirm the interim=E2=80=99s consensus on list, = so please=20 >> let the WG know by 2359 UTC 20 February whether you disagree with the=20= >> way forward and why. >>=20 >> FYI: Jon and Emad volunteered to write this draft. >>=20 >> Cheers, >> Nick and Sean >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Feb 7 06:04:45 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1CF120086 for ; Fri, 7 Feb 2020 06:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2E-NnGS4sho for ; Fri, 7 Feb 2020 06:04:41 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C88120048 for ; Fri, 7 Feb 2020 06:04:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,413,1574118000"; d="scan'208";a="434952452" Received: from corp-nat.untrust.par2.mozilla.com (HELO [10.235.30.91]) ([185.155.183.198]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2020 15:04:39 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Benjamin Beurdouche In-Reply-To: Date: Fri, 7 Feb 2020 15:04:39 +0100 Cc: ML Messaging Layer Security Content-Transfer-Encoding: quoted-printable Message-Id: <7518041D-619D-47CC-8A17-DEBC1C5B9F02@inria.fr> References: To: Sean Turner X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming server assist way forward X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 14:04:44 -0000 Obviously I support this effort. I just want to remind the WG that the intent of that document is to = describe what we think are the main constraints and establish where the places where not only security but also privacy can be affected by a=20 server-assist feature. We will illustrate these places and recommend possible solutions. Again, the goal is not to mandate solutions. If all goes well, this effort will confort the fact that the = server-assist features do not affect the core security guarantees we expect from the protocol. B. > On 6 Feb 2020, at 17:08, Sean Turner wrote: >=20 > Hi! >=20 > tl;dr: confirming new individual draft to describe server assist. >=20 > During the F2F Interim in January, the WG had a lengthy discussion = about server assist. We wrestled with the tussle between privacy and the = desire to support very large groups, which just about everybody, if not = everybody, believes requires some type of server assist because adding a = new member to a large group requires sending megabytes of data in the = Welcome message and this can be too much for some devices. Normally, the = AS and DS is split and maybe these functions are collapsed in IRL, but = Benjamin suggested that we split the functionality up a bit more to talk = more fine-grained about the guarantees we want. The functional split = suggested was as follows [0]: >=20 > - AS: Authentication Service (Signature Keys) > - DS: Delivery Service > -- CS: Credential Retrieval Service (CIKs) > -- IDS: Message Reception Service (Input) > --- IDS is responsible for message ordering. > -- ODS: Message Delivery Service (Output) > --- IDS and ODS may be combined. > - SDS: Storage Delivery Service (Welcome+Backup) > -- SDS is optional. >=20 > Likewise, they suggested that we switch from a model where there is = one queue per group, to one queue per recipient. >=20 > The consensus at the interim was that it is important to support = server assist and that it was equally important to provide truth in = advertising, i.e., those that implement the functionality need to = understand the security guarantees that are available. >=20 > There was also consensus to produce an individual draft that describes = server assist. After this draft is published, the WG can review it and = decide whether it should be accepted as a workable starting point and = potential WG item. >=20 > The chairs need to confirm the interim=E2=80=99s consensus on list, so = please let the WG know by 2359 UTC 20 February whether you disagree with = the way forward and why. >=20 > FYI: Benjamin and Raphael volunteered to write this draft. >=20 > Cheers, >=20 > Nick and Sean >=20 > [0] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/04-archi= tecture.pdf > [1] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/minutes.= md > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Feb 7 08:14:41 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB19A12094D for ; Fri, 7 Feb 2020 08:14:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr7x26RL6hEL for ; Fri, 7 Feb 2020 08:14:37 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 D9D91120940 for ; Fri, 7 Feb 2020 08:14:31 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id c9so3337308wrw.8 for ; Fri, 07 Feb 2020 08:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sNreh1qZGwjzMjVXk/lCP4mxQX+Avi6tn9AEaFj+mmY=; b=JUYIXBZ1lQvQ3CKQ9rAELNsjmRrMOlkvSwAUJLXJrqwpHuOm8Parft6+FvHYbGZmm4 nf7of7jvexdQvBm7lvMtMtF2qSg9kJUbQOSvy7j7pTMlRtoOXInQZ/hNpcO8RSw2XoOt zm8MlCQwemTPtB1YpTWn1zzTBSxfX1TwSx9fXdlS9mBm4DMyialYzw0q3w7H/rvONA3b doJPi7bRosUMSRsBYgiV1XFE6FhjKSJUk4oZvf/hx5zpp0iwFvO3qQkam4KkJ27O/dAc NMEUoz19imwIBXOWMqsQep6JbVLqrPEFmXY3XscLrc8ui7eSMxJf5P9ogITOmfw1GJY8 i5uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sNreh1qZGwjzMjVXk/lCP4mxQX+Avi6tn9AEaFj+mmY=; b=hA+v1tiHD1t5OZGP5mENX3S0/OdC+rh/86Tla0epssz+pIZpwozE3p/foqRn8kgH7w ZzqlE6KsCEoY2JSAZHApVeqfMfheHghBjFooCLupvU4XrOTg+AgPuBzyEuWNpcYBWdIO o7uCMzVyw28OXqhASWBcC+1arAOhSY6nxKVhiF+FYYv55Zn0ePr1U6jA32I+WSeB7kLu MDE+b0le7okay4WnotJuMlUoikzCH7hbzDVlNwVQkOGcGaWpsoiZbMrvSw0XW1yr9tu2 59EXr5fsQa6JQzUivpWhvlbptd5Jgwk3sUCpGd2nlGLvYOUwgo3Wxc/C3Oj2e5ffi5Xi jWYQ== X-Gm-Message-State: APjAAAVdEAlAl+NGCrGXnnu3DF91xI9f1y1OGBIaApW8quTzhhHXB8rS kd3hg2MfHjoagaYYgRkGKXztdg== X-Google-Smtp-Source: APXvYqzDIBl8YV2LpFab0+CNa7YPxRyV3qmxp3mo4LiqdTNy90ytiSvfyaEMxUuoYsiT4z9p96oRPg== X-Received: by 2002:a5d:438c:: with SMTP id i12mr5319009wrq.51.1581092070238; Fri, 07 Feb 2020 08:14:30 -0800 (PST) Received: from [10.54.170.200] ([88.128.88.49]) by smtp.gmail.com with ESMTPSA id l131sm3954191wmf.31.2020.02.07.08.14.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 08:14:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Raphael Robert In-Reply-To: <1EBA4C86-C99F-4154-B83E-C21F99F67A8E@inria.fr> Date: Fri, 7 Feb 2020 17:14:28 +0100 Cc: Katriel Cohn-Gordon , ML Messaging Layer Security , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: References: <5302114f-dd8d-46e9-a345-d5f8110dab28@www.fastmail.com> <1EBA4C86-C99F-4154-B83E-C21F99F67A8E@inria.fr> To: Benjamin Beurdouche X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] confirming state recovery way forward X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 16:14:40 -0000 I also agree with this for all the reasons mentioned above. Raphael > On 7 Feb 2020, at 14:55, Benjamin Beurdouche = wrote: >=20 > I agree with Katriel and support this effort, writing down = requirements > and explore possible solutions to determine possible impact on the > security goals feels like a good way to make progress=E2=80=A6 >=20 > B. >=20 >> On 7 Feb 2020, at 14:51, Katriel Cohn-Gordon = wrote: >>=20 >> I support this effort: this is one of the places where the gap = between analysis and implementation is quite large, because all reliable = messaging systems have a form of state recovery. While we can't = necessarily fix all the issues, writing them up with a goal of at least = making sure people are aware of them seems like a very good idea to me. >>=20 >> On Thu, 6 Feb 2020, at 4:08 PM, Sean Turner wrote: >>> Hi! >>>=20 >>> tl;dr: confirming new individual draft that describes state recovery=20= >>> (i.e., the need for ACKs/NACKs). >>>=20 >>> During the F2F Interim in January, the WG discussed how to address=20= >>> state recovery. One reason you might want ACKs/NACKS is if you sent = a=20 >>> Commit and then some data, and the Commit is lost. In this case, = your=20 >>> data didn=E2=80=99t get sent and the data needs to be resent. There = are obvious=20 >>> implications because messages shouldn=E2=80=99t just be re-sent to = the group=20 >>> after many months. After a lengthy discussion about this and other=20= >>> synchronization issues, the consensus at the interim was that an=20 >>> individual draft is needed to describe state recovery-related = issues.=20 >>> After this draft is published, the WG can review it and decide = whether=20 >>> it should be accepted as a workable starting point and potential WG=20= >>> item or be merged into an existing draft. >>>=20 >>> The chairs need to confirm the interim=E2=80=99s consensus on list, = so please=20 >>> let the WG know by 2359 UTC 20 February whether you disagree with = the=20 >>> way forward and why. >>>=20 >>> FYI: Jon and Emad volunteered to write this draft. >>>=20 >>> Cheers, >>> Nick and Sean >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>>=20 >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Feb 7 08:17:22 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9038120965 for ; Fri, 7 Feb 2020 08:17:18 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUBlDX6421Hf for ; Fri, 7 Feb 2020 08:17:16 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 4EF0B120939 for ; Fri, 7 Feb 2020 08:17:16 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id t14so3375528wmi.5 for ; Fri, 07 Feb 2020 08:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ados+WSy1uts/7zycOaTtAt3xJlpgcZiHqIASbkSDGg=; b=ewe7SrfS7GoUS/H+20yjjAYTmGazNUvHhapKuq8I0KF+x3Eavq9HpRVdLBA5/vMX9y cIoRj7KWEu3of478j/Y4Ro3ueMAn1a3+ea0+9kBtX7KuNXOKAEldxA4qqQDFAC8S057s 9w9NRvYIBdfYSBF14jNQxzleYSIRx10KM3rc4N605BpXamETPBaw25e8q7eleogqstDc VU+X9d04EdFKh1eDs9SGViULGF23qQJjoFEDUA8r/JigX77dSdqHk5UphtGKM31/DosY QpcyHcsDZpKqIQLoNYGyDmrUHW5yDpoht5WwE7VBzmBf1vOATd9DbSNrpPqn3Br++F1c K/mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ados+WSy1uts/7zycOaTtAt3xJlpgcZiHqIASbkSDGg=; b=k88WWzGyHvdI4kWl/M1oT7v3c5G7/3p3jp5vW30LfgQmkEjzYYwgqWYDB0SDiFP1Tn 4O5mP7KmlIfzxsRIyJ7ogTpMWf0pk/Dyz7CqJYuQfOCAOzjdpnTinGfCwXs02JBAYvxL 8W1TlvYS1mJWvWS68C0vOhkGohenWf7Itfjy6C70cFhPynlWh2ZEKZCAWsratbTzePgs FO4B9RQqDayvPkZHWBeQjDDbX7fZZhjBBbHZVuXsq5PmCaPV8e0PdZiLVqjfni+eg6Aw vNFXF3njm/YEfZHwHNiGtR+9mCF3xMgv0ujvnT6Ln4wAIPAcz4skpdmbriYChuMo7zJa CQ6g== X-Gm-Message-State: APjAAAWbI9lRZJ7kr9ruerB2ZInmT2cNhnBFPI+Db7bBy+mFBUJs/wbB K1pYXZ0PjDZQmsTwgYVQnBLjPANNrzo43w== X-Google-Smtp-Source: APXvYqzQsy2M6LkUTjWkxSf71ScxPpsbPopfWA2YsFHy9gGgJTNbev0AKjjxzpAa8tThxTvRKcJo/g== X-Received: by 2002:a1c:4d03:: with SMTP id o3mr4923659wmh.164.1581092234665; Fri, 07 Feb 2020 08:17:14 -0800 (PST) Received: from [10.54.170.200] ([88.128.88.49]) by smtp.gmail.com with ESMTPSA id f14sm3927611wrt.7.2020.02.07.08.17.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 08:17:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Raphael Robert In-Reply-To: <7518041D-619D-47CC-8A17-DEBC1C5B9F02@inria.fr> Date: Fri, 7 Feb 2020 17:17:13 +0100 Cc: Sean Turner , ML Messaging Layer Security Content-Transfer-Encoding: quoted-printable Message-Id: References: <7518041D-619D-47CC-8A17-DEBC1C5B9F02@inria.fr> To: Benjamin Beurdouche X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] confirming server assist way forward X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 16:17:19 -0000 I also support this effort. Like Benjamin said, the goal is not to = propose a mandatory concept but rather work o something that could be = useful in a number of scenarios and that can be extended if need be. Raphael > On 7 Feb 2020, at 15:04, Benjamin Beurdouche = wrote: >=20 > Obviously I support this effort. >=20 > I just want to remind the WG that the intent of that document is to = describe > what we think are the main constraints and establish where the > places where not only security but also privacy can be affected by a=20= > server-assist feature. We will illustrate these places and recommend > possible solutions. Again, the goal is not to mandate solutions. >=20 > If all goes well, this effort will confort the fact that the = server-assist features > do not affect the core security guarantees we expect from the = protocol. >=20 > B. >=20 >> On 6 Feb 2020, at 17:08, Sean Turner wrote: >>=20 >> Hi! >>=20 >> tl;dr: confirming new individual draft to describe server assist. >>=20 >> During the F2F Interim in January, the WG had a lengthy discussion = about server assist. We wrestled with the tussle between privacy and the = desire to support very large groups, which just about everybody, if not = everybody, believes requires some type of server assist because adding a = new member to a large group requires sending megabytes of data in the = Welcome message and this can be too much for some devices. Normally, the = AS and DS is split and maybe these functions are collapsed in IRL, but = Benjamin suggested that we split the functionality up a bit more to talk = more fine-grained about the guarantees we want. The functional split = suggested was as follows [0]: >>=20 >> - AS: Authentication Service (Signature Keys) >> - DS: Delivery Service >> -- CS: Credential Retrieval Service (CIKs) >> -- IDS: Message Reception Service (Input) >> --- IDS is responsible for message ordering. >> -- ODS: Message Delivery Service (Output) >> --- IDS and ODS may be combined. >> - SDS: Storage Delivery Service (Welcome+Backup) >> -- SDS is optional. >>=20 >> Likewise, they suggested that we switch from a model where there is = one queue per group, to one queue per recipient. >>=20 >> The consensus at the interim was that it is important to support = server assist and that it was equally important to provide truth in = advertising, i.e., those that implement the functionality need to = understand the security guarantees that are available. >>=20 >> There was also consensus to produce an individual draft that = describes server assist. After this draft is published, the WG can = review it and decide whether it should be accepted as a workable = starting point and potential WG item. >>=20 >> The chairs need to confirm the interim=E2=80=99s consensus on list, = so please let the WG know by 2359 UTC 20 February whether you disagree = with the way forward and why. >>=20 >> FYI: Benjamin and Raphael volunteered to write this draft. >>=20 >> Cheers, >>=20 >> Nick and Sean >>=20 >> [0] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/04-archi= tecture.pdf >> [1] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/minutes.= md >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Sat Feb 8 23:41:44 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C91200B3 for ; Sat, 8 Feb 2020 23:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=b0UwOvFe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DvtZS8IV 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 DZIwYknFeHty for ; Sat, 8 Feb 2020 23:41:38 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A381200CD for ; Sat, 8 Feb 2020 23:41:38 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DFF8021E5B for ; Sun, 9 Feb 2020 02:32:40 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 09 Feb 2020 02:32:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=kR6pQWiG0vv4eD1aqia5+V091eDzQlUKvT61HTGDAJk=; b=b0UwOvFe sDdDAbbHlL3T5tQ18wCkRUOxAsYQsKkE5rpI20xFkKZDw0S7EyYP6M6sb9XoXmfU L2k0SoffAsGinzek8W0pnIcu6+4Ig2q6Smf8XMdaEB0n3FaR5IAoEnSe6KqJkaXH TtlJuIuRAXCbgEZhmX+Y0XF/0hjbtcQNsl5PrDkEPv2iBVHsTERswM2TVVJQV8hn csFMrbC4NHC9fPrm4y4KvRJ/oJ5Dzv5OLBhDh8cU8eSDAe2SfOmHu52I5iLbJxCr 2LjEg1Dyk+K0gXhYgpgvhTd5af7dsKvNBc9BC2AtElEn4AyoMXPpDrUA97LMY4wA O7z4/J8WqxZ04w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=kR6pQWiG0vv4eD1aqia5+V091eDzQ lUKvT61HTGDAJk=; b=DvtZS8IVL3P5hOwL7x6H3NYrq5MdjYnDHAw++k968cVCZ +lrfAaydIrxt6scmYltVdCHMrrHjp2ixr465vlLIIimrhtEBMMw0c6q+j6yF3qIk XRz46xa4UbS3pJDD3vDwRZGd0MU6O3YRdAsYPueN4ecV4DX3s+6vF6BovZEyFhyw bmnJN3ev14iCZ1Hkwq/RM79/k6M3ZbRr+2/KitzBcIYFWGvygu+ykJRlIu7+BfuM /4WDSkIdWyBPY6YdWutudEkxcUD0HDXC/tHxZ1pZZmQRPS8WYeB+Qc8531nHNsx2 EPs5Eey1qAmGiSsY3BMHjT8NdRoSLbe+jpAHaIhhg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheekgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdplhgvrghfrdhtohgurgihnecukfhppeegtddruddvuddrudei iedrieefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.121.166.63]) by mail.messagingengine.com (Postfix) with ESMTPA id A77E03060272 for ; Sun, 9 Feb 2020 02:32:40 -0500 (EST) Content-Type: multipart/alternative; boundary="===============0789376550508261641==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200209073240.A77E03060272@mailuser.nyi.internal> Date: Sun, 9 Feb 2020 02:32:40 -0500 (EST) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 07:41:40 -0000 --===============0789376550508261641== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+6/-0/=F0=9F=92=AC5) 6 issues created: - Use masking instead of AES-GCM for sender data (by bifurcation) https://github.com/mlswg/mls-protocol/issues/302 [enhancement] [securit= y]=20 - Targeted message (by raphaelrobert) https://github.com/mlswg/mls-protocol/issues/301 [discussion] [function= ality] [privacy]=20 - Order in which proposals should be applied is a little bit vague (by er= iccornelissen) https://github.com/mlswg/mls-protocol/issues/300=20 - Allow indirection of credentials (by bifurcation) https://github.com/mlswg/mls-protocol/issues/299 [enhancement] [perform= ance]=20 - Varints (by bifurcation) https://github.com/mlswg/mls-protocol/issues/298=20 - Restart (by bifurcation) https://github.com/mlswg/mls-protocol/issues/297 [enhancement] [questio= n]=20 2 issues received 5 new comments: - #301 Targeted message (4 by burdges, raphaelrobert) https://github.com/mlswg/mls-protocol/issues/301 [discussion] [function= ality] [privacy]=20 - #272 Redundant information in MLSPlaintextCommitContent (1 by bifurcati= on) https://github.com/mlswg/mls-protocol/issues/272 [discussion] [performa= nce]=20 Pull requests ------------- * mlswg/mls-protocol (+3/-5/=F0=9F=92=AC20) 3 pull requests submitted: - Use HKDF to derive key pairs (by bifurcation) https://github.com/mlswg/mls-protocol/pull/304=20 - Add some per-message entropy (by bifurcation) https://github.com/mlswg/mls-protocol/pull/303=20 - Flesh out the extensions story (by bifurcation) https://github.com/mlswg/mls-protocol/pull/296=20 5 pull requests received 20 new comments: - #303 Add some per-message entropy (13 by Bren2010, beurdouche, bifurcat= ion) https://github.com/mlswg/mls-protocol/pull/303=20 - #296 Flesh out the extensions story (1 by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/296=20 - #294 Re-define direct path to not include the leaf. (2 by bifurcation) https://github.com/mlswg/mls-protocol/pull/294 [today! (?)]=20 - #287 Switch to signing strategy using one signature per leaf. (1 by bif= urcation) https://github.com/mlswg/mls-protocol/pull/287 [discussion] [enhancemen= t] [performance] [security] [today! (?)]=20 - #285 Get rid of ignored proposals. (3 by Bren2010, bifurcation) https://github.com/mlswg/mls-protocol/pull/285 [security] [today! (?)] = 5 pull requests merged: - Use path secret instead of full DirectPath https://github.com/mlswg/mls-protocol/pull/295 [today! (?)]=20 - Re-define direct path to not include the leaf. https://github.com/mlswg/mls-protocol/pull/294 [today! (?)]=20 - Switch to signing strategy using one signature per leaf. https://github.com/mlswg/mls-protocol/pull/287 [discussion] [enhancemen= t] [performance] [ready to merge] [security]=20 - Editorial: Unclear that Commits always include an Update/refreshes the = CIK for the committer. https://github.com/mlswg/mls-protocol/pull/286 [editorial] [today! (?)]= =20 - Get rid of ignored proposals. https://github.com/mlswg/mls-protocol/pull/285 [security] [today! (?)] = Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============0789376550508261641== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday February 09, 2020

Issues

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

6 issues created:

2 issues received 5 new comments:

Pull requests

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

3 pull requests submitted:

5 pull requests received 20 new comments:

5 pull requests merged:

Repositories tracked by this digest:

--===============0789376550508261641==-- From nobody Tue Feb 11 13:53:27 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE79812081F for ; Tue, 11 Feb 2020 13:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 2OrJjdnd-_66 for ; Tue, 11 Feb 2020 13:53:22 -0800 (PST) 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 BC0B3120018 for ; Tue, 11 Feb 2020 13:53:22 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id q15so35930qke.9 for ; Tue, 11 Feb 2020 13:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=a5JnQupOJeQlCJqSMlKNuLxyRiFHuxs4lPGpe82a+x8=; b=kzZNssemyplpASXCnYu675q/jSypkJo1wVb4n3zJvsCUTSz7ZZ3Nzd0YlAa6YJbYBA DX6XcwLo3ov0tcKW8c/bPSEebOZoa9Oidw6osHynWPmM7KaJDhLLjTLMidydDOeR5Lly iZKKd9Roax13hUu3leqmkJbLqRwsGuq7AeDjk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=a5JnQupOJeQlCJqSMlKNuLxyRiFHuxs4lPGpe82a+x8=; b=LeMzrwQ8sC0+llCU+wXJ4qgdtO3oIozD7rONqTb8U3WOJyBOkwp8KMtsL/fvGgallj rsESPClrhBaWclTQ9zwyipszGtVC/dV8cMw/8pW7cpoV4d8D+NQrcwYfi29qpo/owTUs 7YrHNsk7tnrWCQrBPPgycG+xWfsL8cro/aKSYfVXiv3741h+Bh3zS1rFVG1FYeJwUE+H khSZyOOmVfcJXViblbCEOIp3bbGOwYPLpfUEaoaJYowUkoUqITcIplA3v2UW0bWOL/wH S5TNMBe3siuxVL8KivrOF6vrYnaaa0v+pT/PhOsZ4X0lJ6QfkjmZquQqqi6T6G6uavmo 6RoQ== X-Gm-Message-State: APjAAAUpTAefScitP8wgL1+yw2lLoy0URN0bgKCpz6MQRmZ8/t/E0QgR pVOnjzdHtprjGMFIANlHs3z8t1IkTkg= X-Google-Smtp-Source: APXvYqxppIQFLTPI1ZuZaPQOxP40qftGHUr5Pxi6ZkAxlVgYv10dMSkTH2Ue1x/oYgM2cDyVDt7fSg== X-Received: by 2002:a05:620a:15cf:: with SMTP id o15mr8239740qkm.140.1581458001532; Tue, 11 Feb 2020 13:53:21 -0800 (PST) Received: from ?IPv6:2001:579:a008:90:404c:5588:365c:9538? ([2001:579:a008:90:404c:5588:365c:9538]) by smtp.gmail.com with ESMTPSA id c17sm2735286qko.134.2020.02.11.13.53.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 13:53:21 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Feb 2020 16:53:20 -0500 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> Message-Id: <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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, 11 Feb 2020 21:53:25 -0000 As a reminder there is another virtual interim. This is the call = information: Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= Meeting number: 647 391 156 Password: ve2i8niw = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g spt > On Feb 4, 2020, at 05:21, Sean Turner wrote: >=20 > As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >=20 > spt >=20 >> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>=20 >> As a reminder, the recurring virtual interim is tomorrow. Here's the = meeting information: >>=20 >> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >> Meeting number: 647 391 156 >> Password: ve2i8niw >>=20 >> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>=20 >> Nick & Sean >>=20 >> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>=20 >> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>=20 >> Here's the proposed schedule (subject to AD approval): >> Time: 1400-1500 GMT on Wednesdays >> Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >>=20 >> Links to the conference calls are forthcoming. >>=20 >> Nick & Sean >>=20 >> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes wrote: >> Also: Note that despite this poll listing specific dates, the intent = is to set up a weekly recurring meeting. In fact, these dates will = definitely not be the dates when the calls happen, because IETF requires = one week notice. >>=20 >> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes wrote: >> I would like to have some weekly calls to make faster progress on our = outstanding PRs. Here's a Doodle to find a good time: >>=20 >> https://doodle.com/poll/bg2q65phrvfip5zb >>=20 >> I believe these will need to be official Virtual Interims per IETF = process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>=20 >> --Richard >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Tue Feb 11 18:11:45 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB81200C1 for ; Tue, 11 Feb 2020 18:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3OfRsIJZd66 for ; Tue, 11 Feb 2020 18:11:41 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E449212009C for ; Tue, 11 Feb 2020 18:11:40 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id d5so495230qto.0 for ; Tue, 11 Feb 2020 18:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Psoik/PtWZSPTBkd/1NFYYYC62+eu6eWP2qK1KaXSUI=; b=msezvF0QSjSziP8II0/Bva3IJI+NP5Q2/6lisaZmDvf8evx8Rpc/s0vz/drWOgwthi ELyVjKiDcalyxWDXzOaWJ3ndM2oFOVF8pVdP4fM4lJ+KW3pqi7/avuIsKxSJQk0eCG2Y jK0OcV/gg+Kgds9v9zpg3ibfIfYJJmHHa0fK0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Psoik/PtWZSPTBkd/1NFYYYC62+eu6eWP2qK1KaXSUI=; b=hopt2FA/0whXm6pK9ZBwpu6lHb/Y2xCVPyY0YLNo+pJJjzto+V0Qef2qfhP75jphjS L12+uWyxLF1R9yoKGHaA6aDnHPHPgT/DiQxcaReOHP+PFRV+nbFOkfZhkVc2/r85MF2u 5AElVb1vP3M7CFaHGBWODMPvidwuztfzWLtX6HpVjzH/w7csE5RxyyXLjVdxAYUUOYE8 v/xXssjkgvyGuk9J9E/gcK8pjCrrnh5sYdpAINJ+ytI8C1AgLvIT2RsXpWonSl9CumfK woTvUme8yyHS0ZbHmfpt5zPCfeluh8CCFhDtKl3h36JrmDzK1n2Kj1mQyA1qS1G72bTV EeRQ== X-Gm-Message-State: APjAAAWYakV3nt5RQBfz7Eim2U+jFyxB2vY/6+GdR+jU5GsNQosD/p9z kyF+IC6JqSx6iMXkB+1v5bUf4324N213xA== X-Google-Smtp-Source: APXvYqxjW9TBiDx2+1oLeSOsdfrULpZfeP2RAXaFyZWnXpCnyA9kw3R8rxOyXPieeoIv8s6D4uC5cg== X-Received: by 2002:ac8:7415:: with SMTP id p21mr17660454qtq.122.1581473499594; Tue, 11 Feb 2020 18:11:39 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id 205sm2956191qkd.61.2020.02.11.18.11.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 18:11:39 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Feb 2020 21:11:38 -0500 References: To: Messaging Layer Security WG In-Reply-To: Message-Id: <0BE71DF7-0BAB-4F90-8925-DFFE8D2B82E4@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Virtual Interim minutes 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, 12 Feb 2020 02:11:44 -0000 MLSWG, Revised minutes from the first virtual interim posted at the link below. = If you find an issue, submit a PR to Github: = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/01-29-2020.md In one week, I will post the final minutes to the IETF site. Draft minutes for the second virtual interim posted at the link below. = If you find an issue, submit a PR to Github: = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-05-2020.md spt > On Jan 29, 2020, at 16:38, Nick Sullivan = wrote: >=20 > MLSWG, >=20 > Draft minutes from the productive first virtual interim posted below. = If you find an issue, submit a PR to Github: > = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/01-29-2020.md >=20 > Nick & Sean >=20 > >>> > Attendees: > Joel Alwen, Richard Barnes, Raphael Robert, Britta Hale, Brendan = McMillion, Nick Sullivan >=20 > #247 - Welcome confirmation and key derivation > * Fixes bugs RLB found in the last draft while implementing > * OK to merge after rebase / conflict resolution >=20 > #246 - Bugfixes in ClientInitKey, Commit, and Welcome > * Derives the Welcome encryption key instead of generating fresh > * ... under the general theory about not requiring freshness when not = necessary > * OK to merge after rebase / conflict resolution >=20 > #283 - Use the same ratchet for Handshake and Application keys > * There's no point to FS for Proposals because clients have to cache = the plaintext anyway > * Given that, the "flat derivation" approach should be fine > * We should have separate keys per sender to it easier to avoid nonce = collisions > * RLB and RR to decide whether we should derive nonces on a hash = ratchet or just use a counter >=20 > #287 - Switch to signing strategy using one signature per leaf. > * There was agreement among those on the call to proceed with this = strategy (tree-hash-covers-parent-hash) > * ... given the deniability concerns and unclear benefit of the = alternative (parent-hash-covers-tree-hash) > * If further considerations come to light from analysis, we can = revisit later > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 12 08:00:09 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961CE120013 for ; Wed, 12 Feb 2020 08:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU45aNMMZFQ1 for ; Wed, 12 Feb 2020 08:00:04 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9CB12012C for ; Wed, 12 Feb 2020 07:59:57 -0800 (PST) X-ASG-Debug-ID: 1581523195-0e3945496549bc0001-bGA3T6 Received: from mail.nps.edu (synergos.ern.nps.edu [172.20.4.116]) by mule.nps.edu with ESMTP id 3qUiZzJF4U9ztC6o; Wed, 12 Feb 2020 07:59:55 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Wed, 12 Feb 2020 07:59:55 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Wed, 12 Feb 2020 07:59:55 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M69FMsb1fdzHA11E5KfYtbqv5xLQf0YRzxYBDYDc8hK1vZLTowygo52oZhXU+uiV+tF8y/d2imdHVstoZFBMz8O2QgW1OuFoVfAQKL7w6aGcwgY4Rrp/Oc4AQI5lii6e7r2pnKWy7GfVuZcw+hfewGxJWVMG74EZnBriXINt06rvxBaaeXeDDG3lhnghIhllsJ6YIxg/rbKmDEmF8Mb4MCf07cGebCD1lWwc6pH+sFVgLrofpFroaI2DWwv8vbFFNKudwcrsHK2M0F32V94osi7nsU8RbLLcU3wyg0mJ81NfmP/dtvplrd4GEgqDquFe21fscs+W/fOIgfQLbQOiOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lezsopZ9EQ2N+srnhi2/9cx5WzKZYe/PT5IbS/d7sIk=; b=LzQ0Bi244XtNcuN+PscaPtOgVrFrZ7yoffDZmvqS/wKGaevJCGCcZO26UaXs1oMjG2QS652FYCug+UOeP4RWbpdCrmI92oTZh2kQOw7lMX+hEGgkb3yuTvkFxBKH9oNBn1YkHMkPtUsJnKaHpvV3FCGyoGLvkIpKSduJv169BmpOFz+UfaocO4vZuN22b0j08JJq0c9jhB6cbXd/SecYP4Xdov2+Pca18vxINglB8QdJISYs2xBrX8SDJBDDIje6h6lHDwXF6lied1m7FJy71Y9RBwyShvQZZCdnw/uni4NQR3T5q+Cl7JWLC3WakK2GzcGxJFNY5PuIgcGfwhZWfQ== 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 BYAPR13MB2533.namprd13.prod.outlook.com (52.135.228.150) by BYAPR13MB2630.namprd13.prod.outlook.com (20.178.239.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.18; Wed, 12 Feb 2020 15:59:53 +0000 Received: from BYAPR13MB2533.namprd13.prod.outlook.com ([fe80::f1dc:b7b6:2d4a:f8c3]) by BYAPR13MB2533.namprd13.prod.outlook.com ([fe80::f1dc:b7b6:2d4a:f8c3%7]) with mapi id 15.20.2729.021; Wed, 12 Feb 2020 15:59:53 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[20.178.239.205] X-Barracuda-Apparent-Source-IP: 20.178.239.205 From: "Hale, Britta (CIV)" To: Sean Turner , Messaging Layer Security WG Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8A Date: Wed, 12 Feb 2020 15:59:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [96.95.219.17] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7dd4559e-8013-477c-9cde-08d7afd49933 x-ms-traffictypediagnostic: BYAPR13MB2630: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(136003)(396003)(39850400004)(199004)(189003)(75432002)(5660300002)(33656002)(81166006)(81156014)(186003)(36756003)(2906002)(316002)(6486002)(8676002)(786003)(26005)(2616005)(86362001)(110136005)(76116006)(966005)(66476007)(6506007)(478600001)(64756008)(66556008)(66446008)(71200400001)(6512007)(8936002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR13MB2630; H:BYAPR13MB2533.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3P+KrBM0p655LneBXtVDG+dA3PvYPaeC95HeEV3I/B63berdHfokB6uD7EIEgpMCG8fn82w4MBgwu8VijoeMGWs+z8DZBIbIyee2Oi5QDxUmJZGIycy1/n/mF8HItCU+YVkbbqtXVneYvRG4YGecU35DsI2j/+VVZ8pCk9W7ahtdcjW2SAv5i+f17kj5ry0Zb5heSv7ah4Nv1XFyobCkxjd+Fp7DYaduSEvzDTo9PFMJdxGmVPuRgtddcjzwfb+eH2DpL5QcbO0sxx7nxAc56ERX2JDdm9X8jLipBORybkhpRyeB87erKG+CZYkSAMD9IBPRae1rFPF1y3vAC5aRT0nyYalgGvdlXlvEBe4ZHG3k2xoSMVRRWB3VIZf2tD7fNim8RgE0GwDmjNj02IM/875h/vo8FlwDFl+2MJOhykkt9RizuxdJyjyO2ljBPAusaQ0bXbQ+v2UGCLH/VZHvWCTzrizyTo4U2JyKoaum4xEIkqnq6CzAcmVUza2ZJ1EoF+dJUW4sq872kO/cqRypug== x-ms-exchange-antispam-messagedata: aDz7eiOuQ6ibheUSh3hY5R8INAoUfvAGcuynynx05Y1Lpz2LN5MYYWWx5wIK8pz33Q0fXKheoShVnEMcKLUbD3xxVs07phImGMSUse7kxim0JV3yO2g2fNmFnKlVmdSjc9ucup6iOX8IIyU9XySpUw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <827AFB6DFC8D0446BC671B0C16742026@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7dd4559e-8013-477c-9cde-08d7afd49933 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 15:59:53.2309 (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: t9gr65dBhhf4OsTNQThaK07EytwbCE6XI6bSz+5wtlvjVGky5yCeoiLtk5E8+0NnS4UChToL7p+7yNkdMimPyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2630 X-OriginatorOrg: nps.edu X-Barracuda-Connect: synergos.ern.nps.edu[172.20.4.116] X-Barracuda-Start-Time: 1581523195 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 3804 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.79953 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 12 Feb 2020 16:00:07 -0000 SGksDQoNCkNvbmNlcm5pbmcgdGhlIHVzZSBvZiBhIHNpbmdsZSBncm91cCBzaWduYXR1cmUgc2No ZW1lIG9yIGluZGl2aWR1YWwgc2lnbmF0dXJlIHNjaGVtZXMsIGl0IGlzIHByb2JhYmx5IHdvcnRo d2hpbGUgdG8gZXhwYW5kIG9uIHRoZSBjb25zaWRlcmF0aW9uIHBvaW50cyBhbmQgY2xhcmlmeSB3 aGF0IHNlY3VyaXR5IGltcGxpY2F0aW9ucyB3ZSBhcmUgYWNjZXB0aW5nIC0gaW4gZWl0aGVyIGNh c2UuIEkgaGF2ZSBsaXN0ZWQgb3V0IHNvbWUgaXNzdWVzIGluIHRoZSBmb2xsb3dpbmcgR29vZ2xl IGRvYzoNCg0KaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xWkRzNEtHcDBfNmtw UVpwUkpfdDRrVmxtZ0E5NF9wTXRkU2lsSWRGS3cxNC9lZGl0P3VzcD1zaGFyaW5nDQoNCkkgYW0g bm90IG1ha2luZyBhbiBhcmd1bWVudCBmb3IgZWl0aGVyIGNhc2UgYXQgdGhpcyBwb2ludCwgYnV0 IHB1c2hpbmcgdGhpcyBvdXQgZm9yIGRpc2N1c3Npb24gYW5kIHRvIGhlbHAgdXMgYWNoaWV2ZSBt b3JlIGNsYXJpdHkgYXMgdG8gdGhlIGJlbmVmaXRzIGFuZCBjb25zZXF1ZW5jZXMgb2YgZWl0aGVy IGNob2ljZS4gVGhlcmUgYXJlIGNlcnRhaW5seSBtb3JlIGlzc3VlcyB0byBjb25zaWRlciAoZS5n LiBlYXNlIG9mIGltcGxlbWVudGF0aW9uLCBlZmZpY2llbmN5LCBldGMuIGluIGFkZGl0aW9uIHRv IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zKSBhbmQgb3RoZXIgdmlld3MgLSBmZWVsIGZyZWUgdG8g YWRkIHRoZW0gb3IgZGlzY3VzcyBvbiB0aGUgbWFpbGluZyBsaXN0LiANCg0KQWxsIHRoZSBiZXN0 LA0KIA0KQnJpdHRhIA0KIA0KDQrvu79PbiAyLzYvMjAsIDg6MTEgQU0sICJNTFMgb24gYmVoYWxm IG9mIFNlYW4gVHVybmVyIiA8bWxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNlYW5A c24zcmQuY29tPiB3cm90ZToNCg0KICAgIEhpIQ0KICAgIA0KICAgIHRsO2RyOiBjb25maXJtaW5n IE1USSBzdWl0ZSBzZWxlY3Rpb25zIGFuZCByYXRpb25hbGUgZm9yIGF2b2lkaW5nIHByb2xpZmVy YXRpb24NCiAgICANCiAgICBEdXJpbmcgdGhlIEYyRiBJbnRlcmltIGluIEphbnVhcnksIHRoZSBX RyBkaXNjdXNzZWQgY2lwaGVyIHN1aXRlcy1yZWxhdGVkIGlzc3Vlcy4gTmFtZWx5LCB3aGV0aGVy IGEgcGVyLWdyb3VwIHNpZ25hdHVyZSBzY2hlbWUgc2hvdWxkIGJlIGRyaXZlbiBieSB0aGUgY2hv c2VuIGNpcGhlciBzdWl0ZSwgd2hhdCB3ZXJlIHRoZSBNVEkgKE1hbmRhdG9yeSBUbyBJbXBsZW1l bnQpIGNpcGhlciBzdWl0ZXMsIGFuZCB3aGF0IHRoZSBhY3R1YWwgYWxnb3JpdGhtIHNob3VsZCBi ZS4NCiAgICANCiAgICBUaGVyZSB3YXMgcm91Z2ggYWdyZWVtZW50IHRoYXQgdGhlcmUgc2hvdWxk IGJlIG9uZSBzaWduYXR1cmUgc2NoZW1lIHBlciBncm91cCBhbmQgdGhhdCBzaG91bGQgYmUgZHJp dmVuIGJ5IHRoZSBjaXBoZXIgc3VpdGUuIFRoZXJlIGFyZSwgYXQgbGVhc3QsIHRocmVlIHRoaW5n cyB0byBjb25zaWRlcjogMSkgaWYgYSBwb3RlbnRpYWwgZ3JvdXAgbWVtYmVyIGRvZXMgbm90IHN1 cHBvcnQgdGhlIGFsZ29yaXRobSwgdGhlbiB0aGV5IHdpbGwgbm90IGJlY29tZSBhIG1lbWJlciBv ciB0aGUgZ3JvdXAgd2lsbCBuZWVkIHRvIGRvd25ncmFkZTsgMikgd2hlbiB0aGUgZ3JvdXAgbmVl ZHMvd2FudHMgdG8gdXBkYXRlLCBpdCBpcyBhIGZsYWcgZGF5OyBhbmQsIDMpIHRoZSBjaXBoZXIg c3VpdGVzIHdpbGwgaGF2ZSBhIHNpbWlsYXIgY29tYmluYXRvcmlhbCBpc3N1ZXMgYXMgdGhlIFRM UyBjaXBoZXIgc3VpdGVzIHByaW9yIHRvIFRMUyAxLjMuIFRoZSBhZ3JlZW1lbnQgd2FzIOKAnHJv dWdo4oCdIGJlY2F1c2UgMSkgbGlrZWx5IGhhcyBzb21lIGltcG9ydGFudCBpbXBsaWNhdGlvbnMu DQogICAgDQogICAgVGhlIE1MUyBjaXBoZXIgc3VpdGVzIGRlZmluZWQgd2VyZSBhcyBmb2xsb3dz OiANCiAgICAtIE1MUzEwXzEyOF9IUEtFWDI1NTE5X0FFUzEyOEdDTV9TSEEyNTZfRWQyNTUxOQ0K ICAgIC0gTUxTMTBfMTI4X0hQS0VQMjU2X0FFUzEyOEdDTV9TSEEyNTZfUDI1Ng0KICAgIC0gTUxT MTBfMTI4X0hQS0VYMjU1MTlfQ0hBQ0hBMjBQT0xZMTMwNV9TSEEyNTZfRWQyNTUxOQ0KICAgIC0g TUxTMTBfMjU2X0hQS0VYNDQ4X0FFUzI1NkdDTV9TSEEzODRfRWQ0NDgNCiAgICAtIE1MUzEwXzI1 Nl9IUEtFUDUyMV9BRVMyNTZHQ01fU0hBMzg0X1A1MjENCiAgICAtIE1MUzEwXzI1Nl9IUEtFWDQ0 OF9DSEFDSEEyMFBPTFkxMzA1X1NIQTM4NF9FZDQ0OA0KICAgIA0KICAgIEF0IHRoZSBpbnRlcmlt LCB0aGUgY29uc2Vuc3VzIHdhcyB0byBtYWtlIHRoZSBub24tTklTVCBzdWl0ZXMgdGhlIE1USS4g IFRoZSByYXRpb25hbGUgd2FzIHRoYXQgdGhvc2UgaW1wbGVtZW50YXRpb24gdGhhdCBuZWVkIHRv IGJlIE5JU1QgY29tcGxpYW50IHdpbGwgZG8gc28gcmVnYXJkbGVzcyBvZiB0aGUgY2hvaWNlIG1h ZGUgYnkgdGhlIFdHLg0KICAgIA0KICAgIEluIGxvb2tpbmcgYXQgdGhlIGFjdHVhbCBjaXBoZXIg c3VpdGVzLCBpdCB3YXMgbm90ZWQgdGhhdCB0aGUgMjU2LWJpdCBzY2hlbWVzIHRoZSBTSEEgc2hv dWxkIGJlIFNIQS01MTIuIFRoZSByYXRpb25hbGUgYWdyZWVkIHdhcyB0aGF0IFNIQS0zODQgaXMg U0hBLTUxMiBjdXQgaW4gaGFsZiwgc28ganVzdCBkbyBTSEEtNTEyIGJlY2F1c2UgaXQgaXMgb25l IGxlc3Mgb3BlcmF0aW9uLg0KICAgIA0KICAgIFRvIGF2b2lkIHRoZSBwcm9saWZlcmF0aW9uIG9m IGNpcGhlciBzdWl0ZXMsIGd1aWRhbmNlIHdpbGwgYmUgcHJvdmlkZWQgdG8gYmUgY29uc2VydmF0 aXZlIGFib3V0IGFsbG9jYXRpbmcgbmV3IGNvZGUgcG9pbnRzLiBUaGUgY29uc2Vuc3VzIGF0IHRo ZSBpbnRlcmltIHdhcyB0aGF0IHRoZSBzdWl0ZXMgcHJvdmlkZWQgd2VyZSBtaW5pbWFsIGFuZCBw cm92aWRlZCBnb29kIGNvdmVyYWdlIGZvciB0aGUga25vd24gdXNlIGNhc2VzOg0KICAgIC0gKFgy NTUxOSwgQUVTLUdDTSwgRWQyNTUxOSkgLSBHb29kIGZvciBkZXNrdG9wDQogICAgLSAoUC0yNTYs IEFFUy1HQ00sIFAtMjU2KSAtIENvbXBsaWFuY2UNCiAgICAtIChYMjU1MTksIENoYWNoYVBvbHks IEVkMjU1MTkpIC0gR29vZCBmb3IgbW9iaWxlDQogICAgDQogICAgVGhlIGNoYWlycyBuZWVkIHRv IGNvbmZpcm0gdGhlIGludGVyaW3igJlzIGNvbnNlbnN1cyBvbiBsaXN0LCBzbyBwbGVhc2UgbGV0 IHRoZSBXRyBrbm93IGJ5IDIzNTkgVVRDIDIwIEZlYnJ1YXJ5IHdoZXRoZXIgeW91IGRpc2FncmVl IHdpdGggdGhlc2UgY2hvaWNlcyBhbmQgd2h5Lg0KICAgIA0KICAgIE5PVEU6IFRoZSBmaW5hbCB0 ZXh0IHdpbGwgb2J2aW91c2x5IGJlIHJldmlld2VkLCBidXQgaXMgYmVpbmcgY29tcG9zZWQgYXMg cGFydCBvZiB0aGUgZm9sbG93aW5nIFBSOg0KICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3Zy9t bHMtcHJvdG9jb2wvcHVsbC8yNzkNCiAgICANCiAgICBOT1RFOiBXZSBjb21iaW5lZCB0aGVzZSBj aXBoZXIgc3VpdGUgcmVsYXRlZCBjb25zZW5zdXMgcG9pbnRzLCBidXQgaWYgd2Ugb25seSBjb21l IHRvIGNvbnNlbnN1cyBvbiBzb21lIG9mIHRoZXNlIHdlIGNhbiBzdGlsbCBpbmNvcnBvcmF0ZSB3 aGF0IHdlIGRvIGFncmVlIG9uLg0KICAgIA0KICAgIENoZWVycywNCiAgICANCiAgICBOaWNrIGFu ZCBTZWFuDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBNTFMgbWFpbGluZyBsaXN0DQogICAgTUxTQGlldGYub3JnDQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAgICANCg0K From nobody Wed Feb 12 09:04:36 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC291201DC for ; Wed, 12 Feb 2020 09:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUX8PNfHL2RK for ; Wed, 12 Feb 2020 09:04:31 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A7012080F for ; Wed, 12 Feb 2020 09:04:31 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id dc14so1237736qvb.9 for ; Wed, 12 Feb 2020 09:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sqSnQIeC3cay3Xm2mSZNO4itVvDvzjWfrDdwN84MEnk=; b=zrflGt29PlN0o8FwtXd9yo0XgIZw237NFqWwtpvounlczuzNXpLuOV/fzdlJu0NmCa 7lS9+dWj/N4DgaBZAYhrjZQoztYNKH7G47RHesW7jEYjZzMud0hpwqky5QW/+axLnivB wgVm4Ap+lsW7W/HHCEF9w18iYSKdzjAyCeE4RaPG1JZa3XINKM61GedcDlnYabqt1O00 NA6wl6YQm8tSi6I0027lOWlWKAkDdzVwID18q2sEY/B1Qo2cnW3DiSWB7riIYODcnkEp bZ96rWb8P+xJCPzRYED63B07nQn1B8CBD9E0w3o4m4oVSldY2zn4H3e4CwhOAEBnXkpK csUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sqSnQIeC3cay3Xm2mSZNO4itVvDvzjWfrDdwN84MEnk=; b=Hs5TIOKU2cduzJkjtuh/wFwh8zBQq6LQaFCeLo5X6QPBhgVzVPQdDdCj4Qpriq6RG4 dqtA8h/KotC0NAJNjzlmWjR141WfXTpuNstun2FGZRyzpZO2qqXN7f5C4X89P6Dp1bHS xLmeQJiGWaDwf20B0UEJX/MJlpI+TwEBefhpEa3lAZSl12fm7UjUwqM0eWPL0By0wagx cAZj8WgqiXBmMqATbO/ae8AmhUW8S6iI3kLVbqeTFdspv0GNI1sGq0QoiZhHBt/LlysV aZ7piTgk3T9RDfzZHU9BxQS2lf0uVGuNxG1d6xNITFtTbp1a/GsZUx3wvzfAW20M1BiR GDlA== X-Gm-Message-State: APjAAAWFXBljabDnqXOE79uj4cGgS1a6FGX1a8ca/55jRaoDPSJblf4O nRgJZ6C7rtdnHGLW0urVN/+J9TyxFcGXRFmv5GzQxg== X-Google-Smtp-Source: APXvYqwNoE/Gpo+sgGex15BzjBI67k3TxeYjmr0YHk+LK5VPl9gSWKVn7M9xF3fZXIJUbeD1aQLdRGk15Lafs53CisA= X-Received: by 2002:a05:6214:13ef:: with SMTP id ch15mr20516448qvb.183.1581527070507; Wed, 12 Feb 2020 09:04:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 12 Feb 2020 12:04:15 -0500 Message-ID: To: "Hale, Britta (CIV)" Cc: Sean Turner , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000003d9e68059e63f7e9" Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 12 Feb 2020 17:04:35 -0000 --0000000000003d9e68059e63f7e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that these considerations are good to get documented, but at least given the current state of thinking, it seems fine to proceed with the strategy in the current PR. On Wed, Feb 12, 2020 at 11:00 AM Hale, Britta (CIV) wrote: > Hi, > > Concerning the use of a single group signature scheme or individual > signature schemes, it is probably worthwhile to expand on the considerati= on > points and clarify what security implications we are accepting - in eithe= r > case. I have listed out some issues in the following Google doc: > > > https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilI= dFKw14/edit?usp=3Dsharing > > I am not making an argument for either case at this point, but pushing > this out for discussion and to help us achieve more clarity as to the > benefits and consequences of either choice. There are certainly more issu= es > to consider (e.g. ease of implementation, efficiency, etc. in addition to > security considerations) and other views - feel free to add them or discu= ss > on the mailing list. > > All the best, > > Britta > > > =EF=BB=BFOn 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" on behalf of sean@sn3rd.com> wrote: > > Hi! > > tl;dr: confirming MTI suite selections and rationale for avoiding > proliferation > > During the F2F Interim in January, the WG discussed cipher > suites-related issues. Namely, whether a per-group signature scheme shoul= d > be driven by the chosen cipher suite, what were the MTI (Mandatory To > Implement) cipher suites, and what the actual algorithm should be. > > There was rough agreement that there should be one signature scheme > per group and that should be driven by the cipher suite. There are, at > least, three things to consider: 1) if a potential group member does not > support the algorithm, then they will not become a member or the group wi= ll > need to downgrade; 2) when the group needs/wants to update, it is a flag > day; and, 3) the cipher suites will have a similar combinatorial issues a= s > the TLS cipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough= =E2=80=9D because > 1) likely has some important implications. > > The MLS cipher suites defined were as follows: > - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > > At the interim, the consensus was to make the non-NIST suites the > MTI. The rationale was that those implementation that need to be NIST > compliant will do so regardless of the choice made by the WG. > > In looking at the actual cipher suites, it was noted that the 256-bit > schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 = is > SHA-512 cut in half, so just do SHA-512 because it is one less operation. > > To avoid the proliferation of cipher suites, guidance will be provide= d > to be conservative about allocating new code points. The consensus at the > interim was that the suites provided were minimal and provided good > coverage for the known use cases: > - (X25519, AES-GCM, Ed25519) - Good for desktop > - (P-256, AES-GCM, P-256) - Compliance > - (X25519, ChachaPoly, Ed25519) - Good for mobile > > The chairs need to confirm the interim=E2=80=99s consensus on list, s= o please > let the WG know by 2359 UTC 20 February whether you disagree with these > choices and why. > > NOTE: The final text will obviously be reviewed, but is being compose= d > as part of the following PR: > https://github.com/mlswg/mls-protocol/pull/279 > > NOTE: We combined these cipher suite related consensus points, but if > we only come to consensus on some of these we can still incorporate what = we > do agree on. > > Cheers, > > Nick and Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000003d9e68059e63f7e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that these considerations are good to get document= ed, but at least given the current state of thinking, it seems fine to proc= eed with the strategy in the current PR.

On Wed, Feb 12, 2020 at 11:00 A= M Hale, Britta (CIV) <britta.hale= @nps.edu> wrote:
Hi,

Concerning the use of a single group signature scheme or individual signatu= re schemes, it is probably worthwhile to expand on the consideration points= and clarify what security implications we are accepting - in either case. = I have listed out some issues in the following Google doc:

ht= tps://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw= 14/edit?usp=3Dsharing

I am not making an argument for either case at this point, but pushing this= out for discussion and to help us achieve more clarity as to the benefits = and consequences of either choice. There are certainly more issues to consi= der (e.g. ease of implementation, efficiency, etc. in addition to security = considerations) and other views - feel free to add them or discuss on the m= ailing list.

All the best,

Britta


=EF=BB=BFOn 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" <<= a href=3D"mailto:mls-bounces@ietf.org" target=3D"_blank">mls-bounces@ietf.o= rg on behalf of sea= n@sn3rd.com> wrote:

=C2=A0 =C2=A0 Hi!

=C2=A0 =C2=A0 tl;dr: confirming MTI suite selections and rationale for avoi= ding proliferation

=C2=A0 =C2=A0 During the F2F Interim in January, the WG discussed cipher su= ites-related issues. Namely, whether a per-group signature scheme should be= driven by the chosen cipher suite, what were the MTI (Mandatory To Impleme= nt) cipher suites, and what the actual algorithm should be.

=C2=A0 =C2=A0 There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There are, = at least, three things to consider: 1) if a potential group member does not= support the algorithm, then they will not become a member or the group wil= l need to downgrade; 2) when the group needs/wants to update, it is a flag = day; and, 3) the cipher suites will have a similar combinatorial issues as = the TLS cipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough=E2= =80=9D because 1) likely has some important implications.

=C2=A0 =C2=A0 The MLS cipher suites defined were as follows:
=C2=A0 =C2=A0 - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519
=C2=A0 =C2=A0 - MLS10_128_HPKEP256_AES128GCM_SHA256_P256
=C2=A0 =C2=A0 - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519
=C2=A0 =C2=A0 - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448
=C2=A0 =C2=A0 - MLS10_256_HPKEP521_AES256GCM_SHA384_P521
=C2=A0 =C2=A0 - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448

=C2=A0 =C2=A0 At the interim, the consensus was to make the non-NIST suites= the MTI.=C2=A0 The rationale was that those implementation that need to be= NIST compliant will do so regardless of the choice made by the WG.

=C2=A0 =C2=A0 In looking at the actual cipher suites, it was noted that the= 256-bit schemes the SHA should be SHA-512. The rationale agreed was that S= HA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less op= eration.

=C2=A0 =C2=A0 To avoid the proliferation of cipher suites, guidance will be= provided to be conservative about allocating new code points. The consensu= s at the interim was that the suites provided were minimal and provided goo= d coverage for the known use cases:
=C2=A0 =C2=A0 - (X25519, AES-GCM, Ed25519) - Good for desktop
=C2=A0 =C2=A0 - (P-256, AES-GCM, P-256) - Compliance
=C2=A0 =C2=A0 - (X25519, ChachaPoly, Ed25519) - Good for mobile

=C2=A0 =C2=A0 The chairs need to confirm the interim=E2=80=99s consensus on= list, so please let the WG know by 2359 UTC 20 February whether you disagr= ee with these choices and why.

=C2=A0 =C2=A0 NOTE: The final text will obviously be reviewed, but is being= composed as part of the following PR:
=C2=A0 =C2=A0 https://github.com/mlswg/mls-protocol/pu= ll/279

=C2=A0 =C2=A0 NOTE: We combined these cipher suite related consensus points= , but if we only come to consensus on some of these we can still incorporat= e what we do agree on.

=C2=A0 =C2=A0 Cheers,

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


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000003d9e68059e63f7e9-- From nobody Wed Feb 12 09:10:11 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF89120823 for ; Wed, 12 Feb 2020 09:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dObEs6wkSXs5 for ; Wed, 12 Feb 2020 09:10:06 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3562812080F for ; Wed, 12 Feb 2020 09:10:06 -0800 (PST) X-ASG-Debug-ID: 1581527405-0e394549644a650001-bGA3T6 Received: from mail.nps.edu (synergos.ern.nps.edu [172.20.4.116]) by mule.nps.edu with ESMTP id 5AFTfNwsDsNZ8AXT; Wed, 12 Feb 2020 09:10:05 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from skywalker.ern.nps.edu (172.20.4.117) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Wed, 12 Feb 2020 09:10:05 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.109) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Wed, 12 Feb 2020 09:10:05 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XjVOfoQq1Na1xf8OqP907JtEZ8tSXFah4E1SKlmbY1oatTuVD8KDVXlE1E8i+81oL8PBP4EFznEVMmjr5jB6PzlWZ0iLNj9iz6C59l2nbYeJ8Rtw5L/h+x+qwwtnH4FBPQprA5opA5HeKad/YJo5OBcqwfDVl86d38LDVItdKYxZN9INoPcYkCLQNulNpuXozuRJHuzZTDtQi/zofFeZfuWR4OOPrP4YYH1W9XlsNdd8CEisat/ZLQENANtpsUHIkzB28z/TF/rkI/wQZCsebej+U/xhobi9gvT1FtC2wE9CMOw4ulV40fr6uopemhHszEULNHRorKrJB/JWcF0GWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8FyAN3FQtAs8rZDQ/VkIi8y1fZYQ6bKrJVnyAkWzQ8A=; b=nLHVBdoT+hejwvtWspDsS5INUYJArP+7f5QTUD/bohFpKPsQiVWcJXVp09KcuD1s5SGpBMcIBMOzTfDg+8+CC3McppSdWrYM5jKaToW+xtFDoIfJD1CTH175YanZ8YBdx5oCnAG4yK2XaNKqzo1cMln0O2n1X3lPsosIIAWNJOjTt0p5ReoNBeXu74PM+j+O289UnpkiSiuHvhNJ5ydWHFPfSyVsFQ8iGrqNcfVoK1OzQ41DX+WYjEmcNBF/WzZTY64uV49P6kpb5SuA9MexprinQmjdjtUZLoN5+/NAi5wczE9/lEg6l+FzVlfltdAKSBuqQj/JzvKQrfifMPQ7Mw== 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 BYAPR13MB2533.namprd13.prod.outlook.com (52.135.228.150) by BYAPR13MB2774.namprd13.prod.outlook.com (20.178.238.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.14; Wed, 12 Feb 2020 17:10:03 +0000 Received: from BYAPR13MB2533.namprd13.prod.outlook.com ([fe80::f1dc:b7b6:2d4a:f8c3]) by BYAPR13MB2533.namprd13.prod.outlook.com ([fe80::f1dc:b7b6:2d4a:f8c3%7]) with mapi id 15.20.2729.021; Wed, 12 Feb 2020 17:10:03 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[20.178.238.87] X-Barracuda-Apparent-Source-IP: 20.178.238.87 From: "Hale, Britta (CIV)" To: Richard Barnes CC: Sean Turner , Messaging Layer Security WG Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgACYGYCAAACotA== Date: Wed, 12 Feb 2020 17:10:03 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [96.95.219.17] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4dcde2d9-0581-4428-eea3-08d7afde66bb x-ms-traffictypediagnostic: BYAPR13MB2774: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39850400004)(376002)(366004)(136003)(199004)(189003)(8936002)(8676002)(66476007)(66556008)(64756008)(66446008)(7696005)(66946007)(86362001)(71200400001)(81156014)(81166006)(76116006)(91956017)(2906002)(6916009)(4326008)(55016002)(5660300002)(52536014)(33656002)(75432002)(54906003)(53546011)(6506007)(316002)(786003)(9686003)(966005)(26005)(186003)(45080400002)(478600001)(15940465004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR13MB2774; H:BYAPR13MB2533.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mimPzrWcXxHUOr3x7JY3+A2r5XouFtjxbhYQ/kdyoEsNh4DJPhwjuGd2veilw3cM05ItOOonIXQLgQSRvHCeoyOCMQJJdo07YGNH+zw5Fx9sWS7jrIoobS0KDcMcowbIcsU52BYnmvZkjsJ5A4cxNmlTFqaHz363o39USSfmOG6NCA6ZqEuP8GeJQat9wZ6RCZOSYsMGwgyTim84YSd7ROQ4Ea2e03ghfedWWE8GLKYTJd3wNRi+yu/tfH+yDMs9EHyU2m1CtpqHBsIkGbLy7SeeGe3KFozr8dTnMidJ19MOnIXJ02P7Gs1B/xDeFYBJPJaM25px8cz/YzvOfu/jn2RSfpeDpPuyVPX3FQxs9ZQP8npvO6GqS3fOjL2Ar1XnaRSmNExOF3/UUJc8bU0nR4HzutlMDCScgxZiuGvRPNkBOy9tJGrRTy8iQ/i8MBfWESEamwyHdpwCKWaCRXdxAkh5jIT+c/DogxEH0hiAFqZOFSNtiasLlW57fU1z/f0C5asdGXzapi/qkgNii1JdnZGjdEEfb0soToxTKf9lAg4ODgR9uIr/BXhVX//I8JaJ x-ms-exchange-antispam-messagedata: 94ePiEYLbA76SiQj+l8qGrJbL05S7vHsG/391acCieidnwg37MriBg09IqOo6CXSqNyWBBaTdatm2SKSO/Zv1OFjXZLQXmZYKUhsIzAXIsZtxH+YkFcgNv61qSraQ8emYSJp3ivTFewjqHL7QCdnoA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR13MB253357288B93591626BF4026FB1B0BYAPR13MB2533namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4dcde2d9-0581-4428-eea3-08d7afde66bb X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 17:10:03.6937 (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: ndtHM5epIzg234XQBCMnlve9Cqrklabw2Y8MaZYJYmqwtYJmTaLik5xd1T9mDdeHrG5jun2JyqD2EbJeV7Grjg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2774 X-OriginatorOrg: nps.edu X-Barracuda-Connect: synergos.ern.nps.edu[172.20.4.116] X-Barracuda-Start-Time: 1581527405 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 11884 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.79953 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 12 Feb 2020 17:10:09 -0000 --_000_BYAPR13MB253357288B93591626BF4026FB1B0BYAPR13MB2533namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgbm90IGNsZWFyIHdob3NlIGN1cnJlbnQgc3RhdGUgb2YgdGhpbmtpbmcgeW91IGFyZSBy ZWZlcnJpbmcgdG8sIFJpY2hhcmQsIGJ1dCBwZXJoYXBzIHdlIHNob3VsZCBnaXZlIGEgd2VlayB0 byBTZWFuJ3Mgb3JpZ2luYWwgMjB0aCBvZiBGZWJydWFyeSB0aW1lbGluZSBzbyB0aGF0IHRoZSB3 b3JraW5nIGdyb3VwIG1lbWJlcnMgaGF2ZSB0aGUgb3Bwb3J0dW5pdHkgdG8gZGlzY3VzcyBhbmQg c3BlYWsgZm9yIHRoZW1zZWx2ZXMuDQoNCkdldCBPdXRsb29rIGZvciBBbmRyb2lkPGh0dHBzOi8v YWthLm1zL2doZWkzNj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206 IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4Pg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAx MiwgMjAyMCA5OjA0OjE1IEFNDQpUbzogSGFsZSwgQnJpdHRhIChDSVYpIDxicml0dGEuaGFsZUBu cHMuZWR1Pg0KQ2M6IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT47IE1lc3NhZ2luZyBMYXll ciBTZWN1cml0eSBXRyA8bWxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTFNdIGNvbmZpcm1p bmcgY2lwaGVyIHN1aXRlcyBkZWNpc2lvbnMNCg0KSSBhZ3JlZSB0aGF0IHRoZXNlIGNvbnNpZGVy YXRpb25zIGFyZSBnb29kIHRvIGdldCBkb2N1bWVudGVkLCBidXQgYXQgbGVhc3QgZ2l2ZW4gdGhl IGN1cnJlbnQgc3RhdGUgb2YgdGhpbmtpbmcsIGl0IHNlZW1zIGZpbmUgdG8gcHJvY2VlZCB3aXRo IHRoZSBzdHJhdGVneSBpbiB0aGUgY3VycmVudCBQUi4NCg0KT24gV2VkLCBGZWIgMTIsIDIwMjAg YXQgMTE6MDAgQU0gSGFsZSwgQnJpdHRhIChDSVYpIDxicml0dGEuaGFsZUBucHMuZWR1PG1haWx0 bzpicml0dGEuaGFsZUBucHMuZWR1Pj4gd3JvdGU6DQpIaSwNCg0KQ29uY2VybmluZyB0aGUgdXNl IG9mIGEgc2luZ2xlIGdyb3VwIHNpZ25hdHVyZSBzY2hlbWUgb3IgaW5kaXZpZHVhbCBzaWduYXR1 cmUgc2NoZW1lcywgaXQgaXMgcHJvYmFibHkgd29ydGh3aGlsZSB0byBleHBhbmQgb24gdGhlIGNv bnNpZGVyYXRpb24gcG9pbnRzIGFuZCBjbGFyaWZ5IHdoYXQgc2VjdXJpdHkgaW1wbGljYXRpb25z IHdlIGFyZSBhY2NlcHRpbmcgLSBpbiBlaXRoZXIgY2FzZS4gSSBoYXZlIGxpc3RlZCBvdXQgc29t ZSBpc3N1ZXMgaW4gdGhlIGZvbGxvd2luZyBHb29nbGUgZG9jOg0KDQpodHRwczovL2RvY3MuZ29v Z2xlLmNvbS9kb2N1bWVudC9kLzFaRHM0S0dwMF82a3BRWnBSSl90NGtWbG1nQTk0X3BNdGRTaWxJ ZEZLdzE0L2VkaXQ/dXNwPXNoYXJpbmcNCg0KSSBhbSBub3QgbWFraW5nIGFuIGFyZ3VtZW50IGZv ciBlaXRoZXIgY2FzZSBhdCB0aGlzIHBvaW50LCBidXQgcHVzaGluZyB0aGlzIG91dCBmb3IgZGlz Y3Vzc2lvbiBhbmQgdG8gaGVscCB1cyBhY2hpZXZlIG1vcmUgY2xhcml0eSBhcyB0byB0aGUgYmVu ZWZpdHMgYW5kIGNvbnNlcXVlbmNlcyBvZiBlaXRoZXIgY2hvaWNlLiBUaGVyZSBhcmUgY2VydGFp bmx5IG1vcmUgaXNzdWVzIHRvIGNvbnNpZGVyIChlLmcuIGVhc2Ugb2YgaW1wbGVtZW50YXRpb24s IGVmZmljaWVuY3ksIGV0Yy4gaW4gYWRkaXRpb24gdG8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMp IGFuZCBvdGhlciB2aWV3cyAtIGZlZWwgZnJlZSB0byBhZGQgdGhlbSBvciBkaXNjdXNzIG9uIHRo ZSBtYWlsaW5nIGxpc3QuDQoNCkFsbCB0aGUgYmVzdCwNCg0KQnJpdHRhDQoNCg0K77u/T24gMi82 LzIwLCA4OjExIEFNLCAiTUxTIG9uIGJlaGFsZiBvZiBTZWFuIFR1cm5lciIgPG1scy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHNlYW5A c24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdyb3RlOg0KDQogICAgSGkhDQoNCiAg ICB0bDtkcjogY29uZmlybWluZyBNVEkgc3VpdGUgc2VsZWN0aW9ucyBhbmQgcmF0aW9uYWxlIGZv ciBhdm9pZGluZyBwcm9saWZlcmF0aW9uDQoNCiAgICBEdXJpbmcgdGhlIEYyRiBJbnRlcmltIGlu IEphbnVhcnksIHRoZSBXRyBkaXNjdXNzZWQgY2lwaGVyIHN1aXRlcy1yZWxhdGVkIGlzc3Vlcy4g TmFtZWx5LCB3aGV0aGVyIGEgcGVyLWdyb3VwIHNpZ25hdHVyZSBzY2hlbWUgc2hvdWxkIGJlIGRy aXZlbiBieSB0aGUgY2hvc2VuIGNpcGhlciBzdWl0ZSwgd2hhdCB3ZXJlIHRoZSBNVEkgKE1hbmRh dG9yeSBUbyBJbXBsZW1lbnQpIGNpcGhlciBzdWl0ZXMsIGFuZCB3aGF0IHRoZSBhY3R1YWwgYWxn b3JpdGhtIHNob3VsZCBiZS4NCg0KICAgIFRoZXJlIHdhcyByb3VnaCBhZ3JlZW1lbnQgdGhhdCB0 aGVyZSBzaG91bGQgYmUgb25lIHNpZ25hdHVyZSBzY2hlbWUgcGVyIGdyb3VwIGFuZCB0aGF0IHNo b3VsZCBiZSBkcml2ZW4gYnkgdGhlIGNpcGhlciBzdWl0ZS4gVGhlcmUgYXJlLCBhdCBsZWFzdCwg dGhyZWUgdGhpbmdzIHRvIGNvbnNpZGVyOiAxKSBpZiBhIHBvdGVudGlhbCBncm91cCBtZW1iZXIg ZG9lcyBub3Qgc3VwcG9ydCB0aGUgYWxnb3JpdGhtLCB0aGVuIHRoZXkgd2lsbCBub3QgYmVjb21l IGEgbWVtYmVyIG9yIHRoZSBncm91cCB3aWxsIG5lZWQgdG8gZG93bmdyYWRlOyAyKSB3aGVuIHRo ZSBncm91cCBuZWVkcy93YW50cyB0byB1cGRhdGUsIGl0IGlzIGEgZmxhZyBkYXk7IGFuZCwgMykg dGhlIGNpcGhlciBzdWl0ZXMgd2lsbCBoYXZlIGEgc2ltaWxhciBjb21iaW5hdG9yaWFsIGlzc3Vl cyBhcyB0aGUgVExTIGNpcGhlciBzdWl0ZXMgcHJpb3IgdG8gVExTIDEuMy4gVGhlIGFncmVlbWVu dCB3YXMg4oCccm91Z2jigJ0gYmVjYXVzZSAxKSBsaWtlbHkgaGFzIHNvbWUgaW1wb3J0YW50IGlt cGxpY2F0aW9ucy4NCg0KICAgIFRoZSBNTFMgY2lwaGVyIHN1aXRlcyBkZWZpbmVkIHdlcmUgYXMg Zm9sbG93czoNCiAgICAtIE1MUzEwXzEyOF9IUEtFWDI1NTE5X0FFUzEyOEdDTV9TSEEyNTZfRWQy NTUxOQ0KICAgIC0gTUxTMTBfMTI4X0hQS0VQMjU2X0FFUzEyOEdDTV9TSEEyNTZfUDI1Ng0KICAg IC0gTUxTMTBfMTI4X0hQS0VYMjU1MTlfQ0hBQ0hBMjBQT0xZMTMwNV9TSEEyNTZfRWQyNTUxOQ0K ICAgIC0gTUxTMTBfMjU2X0hQS0VYNDQ4X0FFUzI1NkdDTV9TSEEzODRfRWQ0NDgNCiAgICAtIE1M UzEwXzI1Nl9IUEtFUDUyMV9BRVMyNTZHQ01fU0hBMzg0X1A1MjENCiAgICAtIE1MUzEwXzI1Nl9I UEtFWDQ0OF9DSEFDSEEyMFBPTFkxMzA1X1NIQTM4NF9FZDQ0OA0KDQogICAgQXQgdGhlIGludGVy aW0sIHRoZSBjb25zZW5zdXMgd2FzIHRvIG1ha2UgdGhlIG5vbi1OSVNUIHN1aXRlcyB0aGUgTVRJ LiAgVGhlIHJhdGlvbmFsZSB3YXMgdGhhdCB0aG9zZSBpbXBsZW1lbnRhdGlvbiB0aGF0IG5lZWQg dG8gYmUgTklTVCBjb21wbGlhbnQgd2lsbCBkbyBzbyByZWdhcmRsZXNzIG9mIHRoZSBjaG9pY2Ug bWFkZSBieSB0aGUgV0cuDQoNCiAgICBJbiBsb29raW5nIGF0IHRoZSBhY3R1YWwgY2lwaGVyIHN1 aXRlcywgaXQgd2FzIG5vdGVkIHRoYXQgdGhlIDI1Ni1iaXQgc2NoZW1lcyB0aGUgU0hBIHNob3Vs ZCBiZSBTSEEtNTEyLiBUaGUgcmF0aW9uYWxlIGFncmVlZCB3YXMgdGhhdCBTSEEtMzg0IGlzIFNI QS01MTIgY3V0IGluIGhhbGYsIHNvIGp1c3QgZG8gU0hBLTUxMiBiZWNhdXNlIGl0IGlzIG9uZSBs ZXNzIG9wZXJhdGlvbi4NCg0KICAgIFRvIGF2b2lkIHRoZSBwcm9saWZlcmF0aW9uIG9mIGNpcGhl ciBzdWl0ZXMsIGd1aWRhbmNlIHdpbGwgYmUgcHJvdmlkZWQgdG8gYmUgY29uc2VydmF0aXZlIGFi b3V0IGFsbG9jYXRpbmcgbmV3IGNvZGUgcG9pbnRzLiBUaGUgY29uc2Vuc3VzIGF0IHRoZSBpbnRl cmltIHdhcyB0aGF0IHRoZSBzdWl0ZXMgcHJvdmlkZWQgd2VyZSBtaW5pbWFsIGFuZCBwcm92aWRl ZCBnb29kIGNvdmVyYWdlIGZvciB0aGUga25vd24gdXNlIGNhc2VzOg0KICAgIC0gKFgyNTUxOSwg QUVTLUdDTSwgRWQyNTUxOSkgLSBHb29kIGZvciBkZXNrdG9wDQogICAgLSAoUC0yNTYsIEFFUy1H Q00sIFAtMjU2KSAtIENvbXBsaWFuY2UNCiAgICAtIChYMjU1MTksIENoYWNoYVBvbHksIEVkMjU1 MTkpIC0gR29vZCBmb3IgbW9iaWxlDQoNCiAgICBUaGUgY2hhaXJzIG5lZWQgdG8gY29uZmlybSB0 aGUgaW50ZXJpbeKAmXMgY29uc2Vuc3VzIG9uIGxpc3QsIHNvIHBsZWFzZSBsZXQgdGhlIFdHIGtu b3cgYnkgMjM1OSBVVEMgMjAgRmVicnVhcnkgd2hldGhlciB5b3UgZGlzYWdyZWUgd2l0aCB0aGVz ZSBjaG9pY2VzIGFuZCB3aHkuDQoNCiAgICBOT1RFOiBUaGUgZmluYWwgdGV4dCB3aWxsIG9idmlv dXNseSBiZSByZXZpZXdlZCwgYnV0IGlzIGJlaW5nIGNvbXBvc2VkIGFzIHBhcnQgb2YgdGhlIGZv bGxvd2luZyBQUjoNCiAgICBodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1 bGwvMjc5DQoNCiAgICBOT1RFOiBXZSBjb21iaW5lZCB0aGVzZSBjaXBoZXIgc3VpdGUgcmVsYXRl ZCBjb25zZW5zdXMgcG9pbnRzLCBidXQgaWYgd2Ugb25seSBjb21lIHRvIGNvbnNlbnN1cyBvbiBz b21lIG9mIHRoZXNlIHdlIGNhbiBzdGlsbCBpbmNvcnBvcmF0ZSB3aGF0IHdlIGRvIGFncmVlIG9u Lg0KDQogICAgQ2hlZXJzLA0KDQogICAgTmljayBhbmQgU2Vhbg0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgTUxTIG1haWxpbmcgbGlzdA0K ICAgIE1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxpc3QNCk1MU0BpZXRmLm9yZzxt YWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbHMNCg== --_000_BYAPR13MB253357288B93591626BF4026FB1B0BYAPR13MB2533namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iIHN0eWxlPSJkaXJlY3Rpb246IGx0cjsgbWFyZ2luOiAwOyBwYWRkaW5nOiAwOyBmb250LWZh bWlseTogc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjogYmxhY2s7ICI+DQpJdCBp cyBub3QgY2xlYXIgd2hvc2UgY3VycmVudCBzdGF0ZSBvZiB0aGlua2luZyB5b3UgYXJlIHJlZmVy cmluZyB0bywgUmljaGFyZCwgYnV0IHBlcmhhcHMgd2Ugc2hvdWxkIGdpdmUgYSB3ZWVrIHRvIFNl YW4ncyBvcmlnaW5hbCAyMHRoIG9mIEZlYnJ1YXJ5IHRpbWVsaW5lIHNvIHRoYXQgdGhlIHdvcmtp bmcgZ3JvdXAgbWVtYmVycyBoYXZlIHRoZSBvcHBvcnR1bml0eSB0byBkaXNjdXNzIGFuZCBzcGVh ayBmb3IgdGhlbXNlbHZlcy4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIHN0 eWxlPSJkaXJlY3Rpb246IGx0cjsgbWFyZ2luOiAwOyBwYWRkaW5nOiAwOyBmb250LWZhbWlseTog c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjogYmxhY2s7ICI+DQo8c3BhbiBpZD0i T3V0bG9va1NpZ25hdHVyZSI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjogbHRy OyBtYXJnaW46IDA7IHBhZGRpbmc6IDA7IGZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyBmb250LXNp emU6IDExcHQ7IGNvbG9yOiBibGFjazsgIj4NCkdldCA8YSBocmVmPSJodHRwczovL2FrYS5tcy9n aGVpMzYiPk91dGxvb2sgZm9yIEFuZHJvaWQ8L2E+PC9kaXY+DQo8L3NwYW4+PGJyPg0KPC9kaXY+ DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrO3dpZHRoOjk4JSIgdGFiaW5kZXg9Ii0x Ij4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJp LCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQiIGNvbG9yPSIjMDAwMDAwIj48Yj5G cm9tOjwvYj4gUmljaGFyZCBCYXJuZXMgJmx0O3JsYkBpcHYuc3gmZ3Q7PGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMjAgOTowNDoxNSBBTTxicj4NCjxiPlRvOjwv Yj4gSGFsZSwgQnJpdHRhIChDSVYpICZsdDticml0dGEuaGFsZUBucHMuZWR1Jmd0Ozxicj4NCjxi PkNjOjwvYj4gU2VhbiBUdXJuZXIgJmx0O3NlYW5Ac24zcmQuY29tJmd0OzsgTWVzc2FnaW5nIExh eWVyIFNlY3VyaXR5IFdHICZsdDttbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbTUxTXSBjb25maXJtaW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zPC9mb250Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkkgYWdyZWUgdGhh dCB0aGVzZSBjb25zaWRlcmF0aW9ucyBhcmUgZ29vZCB0byBnZXQgZG9jdW1lbnRlZCwgYnV0IGF0 IGxlYXN0IGdpdmVuIHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoaW5raW5nLCBpdCBzZWVtcyBmaW5l IHRvIHByb2NlZWQgd2l0aCB0aGUgc3RyYXRlZ3kgaW4gdGhlIGN1cnJlbnQgUFIuPGJyPg0KPC9k aXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJ4X2dtYWlsX2F0dHIiPk9uIFdlZCwgRmViIDEyLCAyMDIwIGF0IDExOjAwIEFNIEhhbGUs IEJyaXR0YSAoQ0lWKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaXR0YS5oYWxlQG5wcy5lZHUiPmJy aXR0YS5oYWxlQG5wcy5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBi b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTsgcGFkZGluZy1sZWZ0OjFleCI+ DQpIaSw8YnI+DQo8YnI+DQpDb25jZXJuaW5nIHRoZSB1c2Ugb2YgYSBzaW5nbGUgZ3JvdXAgc2ln bmF0dXJlIHNjaGVtZSBvciBpbmRpdmlkdWFsIHNpZ25hdHVyZSBzY2hlbWVzLCBpdCBpcyBwcm9i YWJseSB3b3J0aHdoaWxlIHRvIGV4cGFuZCBvbiB0aGUgY29uc2lkZXJhdGlvbiBwb2ludHMgYW5k IGNsYXJpZnkgd2hhdCBzZWN1cml0eSBpbXBsaWNhdGlvbnMgd2UgYXJlIGFjY2VwdGluZyAtIGlu IGVpdGhlciBjYXNlLiBJIGhhdmUgbGlzdGVkIG91dCBzb21lIGlzc3VlcyBpbg0KIHRoZSBmb2xs b3dpbmcgR29vZ2xlIGRvYzo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL2RvY3MuZ29vZ2xl LmNvbS9kb2N1bWVudC9kLzFaRHM0S0dwMF82a3BRWnBSSl90NGtWbG1nQTk0X3BNdGRTaWxJZEZL dzE0L2VkaXQ/dXNwPXNoYXJpbmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2QvMVpEczRLR3AwXzZrcFFacFJKX3Q0a1Zs bWdBOTRfcE10ZFNpbElkRkt3MTQvZWRpdD91c3A9c2hhcmluZzwvYT48YnI+DQo8YnI+DQpJIGFt IG5vdCBtYWtpbmcgYW4gYXJndW1lbnQgZm9yIGVpdGhlciBjYXNlIGF0IHRoaXMgcG9pbnQsIGJ1 dCBwdXNoaW5nIHRoaXMgb3V0IGZvciBkaXNjdXNzaW9uIGFuZCB0byBoZWxwIHVzIGFjaGlldmUg bW9yZSBjbGFyaXR5IGFzIHRvIHRoZSBiZW5lZml0cyBhbmQgY29uc2VxdWVuY2VzIG9mIGVpdGhl ciBjaG9pY2UuIFRoZXJlIGFyZSBjZXJ0YWlubHkgbW9yZSBpc3N1ZXMgdG8gY29uc2lkZXIgKGUu Zy4gZWFzZSBvZiBpbXBsZW1lbnRhdGlvbiwNCiBlZmZpY2llbmN5LCBldGMuIGluIGFkZGl0aW9u IHRvIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zKSBhbmQgb3RoZXIgdmlld3MgLSBmZWVsIGZyZWUg dG8gYWRkIHRoZW0gb3IgZGlzY3VzcyBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KPGJyPg0KPGJyPg0K QWxsIHRoZSBiZXN0LDxicj4NCjxicj4NCkJyaXR0YSA8YnI+DQo8YnI+DQo8YnI+DQrvu79PbiAy LzYvMjAsIDg6MTEgQU0sICZxdW90O01MUyBvbiBiZWhhbGYgb2YgU2VhbiBUdXJuZXImcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1scy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpz ZWFuQHNuM3JkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNlYW5Ac24zcmQuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBIaSE8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IHRsO2RyOiBjb25maXJtaW5nIE1USSBzdWl0ZSBzZWxlY3Rpb25zIGFuZCByYXRpb25hbGUgZm9y IGF2b2lkaW5nIHByb2xpZmVyYXRpb248YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IER1cmluZyB0 aGUgRjJGIEludGVyaW0gaW4gSmFudWFyeSwgdGhlIFdHIGRpc2N1c3NlZCBjaXBoZXIgc3VpdGVz LXJlbGF0ZWQgaXNzdWVzLiBOYW1lbHksIHdoZXRoZXIgYSBwZXItZ3JvdXAgc2lnbmF0dXJlIHNj aGVtZSBzaG91bGQgYmUgZHJpdmVuIGJ5IHRoZSBjaG9zZW4gY2lwaGVyIHN1aXRlLCB3aGF0IHdl cmUgdGhlIE1USSAoTWFuZGF0b3J5IFRvIEltcGxlbWVudCkgY2lwaGVyIHN1aXRlcywgYW5kIHdo YXQgdGhlIGFjdHVhbCBhbGdvcml0aG0NCiBzaG91bGQgYmUuPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBUaGVyZSB3YXMgcm91Z2ggYWdyZWVtZW50IHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSBz aWduYXR1cmUgc2NoZW1lIHBlciBncm91cCBhbmQgdGhhdCBzaG91bGQgYmUgZHJpdmVuIGJ5IHRo ZSBjaXBoZXIgc3VpdGUuIFRoZXJlIGFyZSwgYXQgbGVhc3QsIHRocmVlIHRoaW5ncyB0byBjb25z aWRlcjogMSkgaWYgYSBwb3RlbnRpYWwgZ3JvdXAgbWVtYmVyIGRvZXMgbm90IHN1cHBvcnQgdGhl IGFsZ29yaXRobSwgdGhlbiB0aGV5IHdpbGwgbm90DQogYmVjb21lIGEgbWVtYmVyIG9yIHRoZSBn cm91cCB3aWxsIG5lZWQgdG8gZG93bmdyYWRlOyAyKSB3aGVuIHRoZSBncm91cCBuZWVkcy93YW50 cyB0byB1cGRhdGUsIGl0IGlzIGEgZmxhZyBkYXk7IGFuZCwgMykgdGhlIGNpcGhlciBzdWl0ZXMg d2lsbCBoYXZlIGEgc2ltaWxhciBjb21iaW5hdG9yaWFsIGlzc3VlcyBhcyB0aGUgVExTIGNpcGhl ciBzdWl0ZXMgcHJpb3IgdG8gVExTIDEuMy4gVGhlIGFncmVlbWVudCB3YXMg4oCccm91Z2jigJ0g YmVjYXVzZQ0KIDEpIGxpa2VseSBoYXMgc29tZSBpbXBvcnRhbnQgaW1wbGljYXRpb25zLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlIE1MUyBjaXBoZXIgc3VpdGVzIGRlZmluZWQgd2VyZSBh cyBmb2xsb3dzOiA8YnI+DQombmJzcDsgJm5ic3A7IC0gTUxTMTBfMTI4X0hQS0VYMjU1MTlfQUVT MTI4R0NNX1NIQTI1Nl9FZDI1NTE5PGJyPg0KJm5ic3A7ICZuYnNwOyAtIE1MUzEwXzEyOF9IUEtF UDI1Nl9BRVMxMjhHQ01fU0hBMjU2X1AyNTY8YnI+DQombmJzcDsgJm5ic3A7IC0gTUxTMTBfMTI4 X0hQS0VYMjU1MTlfQ0hBQ0hBMjBQT0xZMTMwNV9TSEEyNTZfRWQyNTUxOTxicj4NCiZuYnNwOyAm bmJzcDsgLSBNTFMxMF8yNTZfSFBLRVg0NDhfQUVTMjU2R0NNX1NIQTM4NF9FZDQ0ODxicj4NCiZu YnNwOyAmbmJzcDsgLSBNTFMxMF8yNTZfSFBLRVA1MjFfQUVTMjU2R0NNX1NIQTM4NF9QNTIxPGJy Pg0KJm5ic3A7ICZuYnNwOyAtIE1MUzEwXzI1Nl9IUEtFWDQ0OF9DSEFDSEEyMFBPTFkxMzA1X1NI QTM4NF9FZDQ0ODxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQXQgdGhlIGludGVyaW0sIHRoZSBj b25zZW5zdXMgd2FzIHRvIG1ha2UgdGhlIG5vbi1OSVNUIHN1aXRlcyB0aGUgTVRJLiZuYnNwOyBU aGUgcmF0aW9uYWxlIHdhcyB0aGF0IHRob3NlIGltcGxlbWVudGF0aW9uIHRoYXQgbmVlZCB0byBi ZSBOSVNUIGNvbXBsaWFudCB3aWxsIGRvIHNvIHJlZ2FyZGxlc3Mgb2YgdGhlIGNob2ljZSBtYWRl IGJ5IHRoZSBXRy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEluIGxvb2tpbmcgYXQgdGhlIGFj dHVhbCBjaXBoZXIgc3VpdGVzLCBpdCB3YXMgbm90ZWQgdGhhdCB0aGUgMjU2LWJpdCBzY2hlbWVz IHRoZSBTSEEgc2hvdWxkIGJlIFNIQS01MTIuIFRoZSByYXRpb25hbGUgYWdyZWVkIHdhcyB0aGF0 IFNIQS0zODQgaXMgU0hBLTUxMiBjdXQgaW4gaGFsZiwgc28ganVzdCBkbyBTSEEtNTEyIGJlY2F1 c2UgaXQgaXMgb25lIGxlc3Mgb3BlcmF0aW9uLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVG8g YXZvaWQgdGhlIHByb2xpZmVyYXRpb24gb2YgY2lwaGVyIHN1aXRlcywgZ3VpZGFuY2Ugd2lsbCBi ZSBwcm92aWRlZCB0byBiZSBjb25zZXJ2YXRpdmUgYWJvdXQgYWxsb2NhdGluZyBuZXcgY29kZSBw b2ludHMuIFRoZSBjb25zZW5zdXMgYXQgdGhlIGludGVyaW0gd2FzIHRoYXQgdGhlIHN1aXRlcyBw cm92aWRlZCB3ZXJlIG1pbmltYWwgYW5kIHByb3ZpZGVkIGdvb2QgY292ZXJhZ2UgZm9yIHRoZSBr bm93biB1c2UgY2FzZXM6PGJyPg0KJm5ic3A7ICZuYnNwOyAtIChYMjU1MTksIEFFUy1HQ00sIEVk MjU1MTkpIC0gR29vZCBmb3IgZGVza3RvcDxicj4NCiZuYnNwOyAmbmJzcDsgLSAoUC0yNTYsIEFF Uy1HQ00sIFAtMjU2KSAtIENvbXBsaWFuY2U8YnI+DQombmJzcDsgJm5ic3A7IC0gKFgyNTUxOSwg Q2hhY2hhUG9seSwgRWQyNTUxOSkgLSBHb29kIGZvciBtb2JpbGU8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7IFRoZSBjaGFpcnMgbmVlZCB0byBjb25maXJtIHRoZSBpbnRlcmlt4oCZcyBjb25zZW5z dXMgb24gbGlzdCwgc28gcGxlYXNlIGxldCB0aGUgV0cga25vdyBieSAyMzU5IFVUQyAyMCBGZWJy dWFyeSB3aGV0aGVyIHlvdSBkaXNhZ3JlZSB3aXRoIHRoZXNlIGNob2ljZXMgYW5kIHdoeS48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7IE5PVEU6IFRoZSBmaW5hbCB0ZXh0IHdpbGwgb2J2aW91c2x5 IGJlIHJldmlld2VkLCBidXQgaXMgYmVpbmcgY29tcG9zZWQgYXMgcGFydCBvZiB0aGUgZm9sbG93 aW5nIFBSOjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL21s c3dnL21scy1wcm90b2NvbC9wdWxsLzI3OSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwvMjc5PC9hPjxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgTk9URTogV2UgY29tYmluZWQgdGhlc2UgY2lwaGVyIHN1 aXRlIHJlbGF0ZWQgY29uc2Vuc3VzIHBvaW50cywgYnV0IGlmIHdlIG9ubHkgY29tZSB0byBjb25z ZW5zdXMgb24gc29tZSBvZiB0aGVzZSB3ZSBjYW4gc3RpbGwgaW5jb3Jwb3JhdGUgd2hhdCB3ZSBk byBhZ3JlZSBvbi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IENoZWVycyw8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IE5pY2sgYW5kIFNlYW48YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBN TFMgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86TUxTQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TUxTQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAmbmJz cDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbHM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpNTFMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk1MU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1MU0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21scyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbHM8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR13MB253357288B93591626BF4026FB1B0BYAPR13MB2533namp_-- From nobody Wed Feb 12 17:59:28 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93095120071 for ; Wed, 12 Feb 2020 17:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 9rvMfDNpIJMO for ; Wed, 12 Feb 2020 17:59:24 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DBE12006D for ; Wed, 12 Feb 2020 17:59:24 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id p7so4187533qkh.10 for ; Wed, 12 Feb 2020 17:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=D4FCr93izJcaejbKIATxvig6GFcLpvp5Bcx9OtjyFHQ=; b=mZkwt1wHvhbM4BOUNyxvKoZ3SkQdQS2OnpSRTxD7EYp4ydFjmlIZ/2w9rlJ1OineLF ujDSoeF5P+8K8V0aAw4qO3AEOsBODjcEYvB+dQP1JaPztsnCa0MFQLFhAHl6zQuyzLyX 1htcyP9LbsDJNhpbO0plggvjl3cIFT3kr/9Fo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=D4FCr93izJcaejbKIATxvig6GFcLpvp5Bcx9OtjyFHQ=; b=C1zs279jpxJyNMh5dUup9mux4JglHjoFzFNWDFWMblK3bl/OCb6bbw8NONE87R0LTZ okSYvV/U+DgOTnaMjsNSR6R2zhKchGSJ4LLlmYXKKEX1338Rrlsfps7HAafMBY8ezObb 6rUvF/pIUdenG4sknJotH167ehrzGwGxP8hMy7J2BOjGEPW28QrsXJCL5+jS3o86ha/6 pIJYUhePXnEedGm2ZA24uIZhwvD5lg297eluMknR9N0PQaGb0Lcqervx97njLqJp36M3 PKYji2W/aSSqfpzjONlpma8FvB7btIGax6GXZ0PZ5r47buMs8df/QZbF8UUO6k4yM5Nq QDgA== X-Gm-Message-State: APjAAAXk4twt1ZN9LKIq5lMKw5EpsJ/KzXTYzUtTfC5eCvo690TAaf+Q ta5r3WqHiHREcRDDzOGQF9LuuSxk0pFrAw== X-Google-Smtp-Source: APXvYqzwGjmOk7A6ERjPkXcLVM3TJVJ+NBrH36Zvg7y2VcFB6ghscP5k6EyPILdfNCMelcJVHRu+Dw== X-Received: by 2002:a37:e109:: with SMTP id c9mr12490290qkm.366.1581559162759; Wed, 12 Feb 2020 17:59:22 -0800 (PST) Received: from [5.5.33.144] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id a145sm450916qkg.128.2020.02.12.17.59.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Feb 2020 17:59:21 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 12 Feb 2020 20:59:20 -0500 References: <0BE71DF7-0BAB-4F90-8925-DFFE8D2B82E4@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <0BE71DF7-0BAB-4F90-8925-DFFE8D2B82E4@sn3rd.com> Message-Id: <34771848-5C49-4F86-BC45-36C6CCB25AD8@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Virtual Interim minutes 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, 13 Feb 2020 01:59:27 -0000 MLSWG, Draft minutes* available for the 3rd virtual interim at the link below. = As before, if you find an issue please submit a PR to Github: = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-12-2020.md spt * Thanks to rlb. > On Feb 11, 2020, at 21:11, Sean Turner wrote: >=20 > MLSWG, >=20 > Revised minutes from the first virtual interim posted at the link = below. If you find an issue, submit a PR to Github: > = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/01-29-2020.md > In one week, I will post the final minutes to the IETF site. >=20 > Draft minutes for the second virtual interim posted at the link below. = If you find an issue, submit a PR to Github: > = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-05-2020.md >=20 > spt >=20 >> On Jan 29, 2020, at 16:38, Nick Sullivan = wrote: >>=20 >> MLSWG, >>=20 >> Draft minutes from the productive first virtual interim posted below. = If you find an issue, submit a PR to Github: >> = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/01-29-2020.md >>=20 >> Nick & Sean >>=20 >>>>>=20 >> Attendees: >> Joel Alwen, Richard Barnes, Raphael Robert, Britta Hale, Brendan = McMillion, Nick Sullivan >>=20 >> #247 - Welcome confirmation and key derivation >> * Fixes bugs RLB found in the last draft while implementing >> * OK to merge after rebase / conflict resolution >>=20 >> #246 - Bugfixes in ClientInitKey, Commit, and Welcome >> * Derives the Welcome encryption key instead of generating fresh >> * ... under the general theory about not requiring freshness when not = necessary >> * OK to merge after rebase / conflict resolution >>=20 >> #283 - Use the same ratchet for Handshake and Application keys >> * There's no point to FS for Proposals because clients have to cache = the plaintext anyway >> * Given that, the "flat derivation" approach should be fine >> * We should have separate keys per sender to it easier to avoid nonce = collisions >> * RLB and RR to decide whether we should derive nonces on a hash = ratchet or just use a counter >>=20 >> #287 - Switch to signing strategy using one signature per leaf. >> * There was agreement among those on the call to proceed with this = strategy (tree-hash-covers-parent-hash) >> * ... given the deniability concerns and unclear benefit of the = alternative (parent-hash-covers-tree-hash) >> * If further considerations come to light from analysis, we can = revisit later >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Thu Feb 13 06:40:18 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43371200E0 for ; Thu, 13 Feb 2020 06:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 U69NJliQum1W for ; Thu, 13 Feb 2020 06:40:15 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AB3120013 for ; Thu, 13 Feb 2020 06:40:15 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id p2so2684816qvo.10 for ; Thu, 13 Feb 2020 06:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=/lSVUtiZ17wVwxQH7JahJR5h0IG/Jn1GpkmB6ReGoZQ=; b=a0PyYRQal9mykpn79gN0KNmblBwOHQ3cMGoKHxcmrScCRkkn+hvxMU4QxRyvbyI6QP BYaFrIndkKEs1LQSvMBGEE03J2QvGdv7TWIAOEshtvQHOTIkEpOSWp39JDa/6D5/gGVA w9YFsVVjNHjkUgazpEQiis3Z4TXphxdz2sgrg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=/lSVUtiZ17wVwxQH7JahJR5h0IG/Jn1GpkmB6ReGoZQ=; b=AeVx7h2DC6Bju09nvjWyfTdWms6lBFIwwTC1XXVkv6fUpvWloPVVGP5QqfNNG41XiK IwO/4wZdIXFYmcCxyywA2C7vq6cd+ZLyP/3Ap1jU5YyGVEKi7yt1erpjOyu/wxLe/ZeY dQAxqofLUehW/LZ19svpIG5XgvdHgtIyg13ccbaIApAM4jCFR/LtQZrT9LG/evhOtxS/ FBDoDQo8d0ROnhEhrb2AdTbKOMDwVrIZ5fPv1njNe07tPUHzCigZkFk4EcZCbQHHHEvD ipcrfzbigDqRlhnMHAZwVSlNvAH6GZuGB/wDddl7IMJWm51/mV6Cjz6iaujB2o8NcYXP uaQA== X-Gm-Message-State: APjAAAV+QkXIZXdLYdk6PPaDxHWpE58TEFlVazQHWTnIm5mcD1s6RQtj ALSigug+GnaYQXj63AU9zuU42SXeJRoRmQ== X-Google-Smtp-Source: APXvYqy7j5fJZZsvgubSrxKpu00RsB1+n8jFyWD0AJY+rY2AstII4cdzYq1NAuqBDSKODzBScriV9A== X-Received: by 2002:a0c:ffc4:: with SMTP id h4mr11731207qvv.233.1581604814032; Thu, 13 Feb 2020 06:40:14 -0800 (PST) Received: from [5.5.33.83] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id v82sm1434863qka.51.2020.02.13.06.40.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 06:40:13 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <2B99776C-FB2D-4336-A15B-CF703623F591@sn3rd.com> Date: Thu, 13 Feb 2020 09:40:12 -0500 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] Paper (Evaluation of the MessagingLayer Security Protocol--A Performance and Usability Study) 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, 13 Feb 2020 14:40:17 -0000 (no hat) (shared with permission) Just an FYI, here=E2=80=99s a paper by Silas Lenz that looks at the = usability and performance of MLS compared to current solutions:=20 https://liu.diva-portal.org/smash/get/diva2:1388449/FULLTEXT01.pdf spt= From nobody Thu Feb 13 06:49:24 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F6312011D for ; Thu, 13 Feb 2020 06:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 CebnJovT_eNh for ; Thu, 13 Feb 2020 06:49:21 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277831200E0 for ; Thu, 13 Feb 2020 06:49:21 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id w15so5883432qkf.6 for ; Thu, 13 Feb 2020 06:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=fvq5Zf0hF/2HCX29qbkkzaAdgpwTSH3T7hbkSVKZXOo=; b=DBgfcfYq5/XWcXxna11o2frEm81BmdOw+EDXXEhhci3vlqxsQwbYAEdB0grRU15IIS KKVosx0Df1GGHTsTJEsnS22Mj8tRPeCc47Su1cQxh93Gltw+E3sOPdk0jCvpffb6prgO Dxc4MN+JcLOTg1kCTYak58mwdNCobNWKPOWNQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=fvq5Zf0hF/2HCX29qbkkzaAdgpwTSH3T7hbkSVKZXOo=; b=nmAMEPw8felSJT/TcpSlpasBMo7XAbUFbxFS0zh2vzDmZqB4XmP/u+c1ejxmCroUdF uYM/NoDvPsFimP11/K2piItXnZHNziHeXPXZifTgVt0IypBVFUWhMInVixArkyXA8vXd 1E+dU+RXscd6C33WOLiYhNoH+/E2+Qj7vdySmVD68BYhFVNqQbmd7jaHV0G9MZmanBsO 8kaz7tkurmi9UvcSYKujJcKNwPGGyhGa3jprQIsi4sgwFy5cI+mFCi9vq7Amsur15tWZ hm6S00z6R/o82kWuN6AfaTfQhpHJdDAwnwVIUMzkHd6WBqy3SgH5M53iXP9mMFM8FUgr phfA== X-Gm-Message-State: APjAAAVsndwe13exROXzyQJoI6OFnQYBPidvAgP/tMNeVKsTii/AcmUU u+aPPQiKQhJQqAOfCq1V8iPJ8wcaPHEfEw== X-Google-Smtp-Source: APXvYqxbOrocg890tRRxTO+XIxDSz+9fbmr6YIpkiMFD53wS3fjnNBcNrKvbAdrcpRNjQOYXtB+3ZQ== X-Received: by 2002:a37:a958:: with SMTP id s85mr12171374qke.243.1581605360037; Thu, 13 Feb 2020 06:49:20 -0800 (PST) Received: from [5.5.33.83] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id v10sm1484554qtq.58.2020.02.13.06.49.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 06:49:19 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 13 Feb 2020 09:49:18 -0500 References: To: Messaging Layer Security WG In-Reply-To: Message-Id: <9DE50F4A-DDBD-400E-8EA4-2D40A75CE028@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 13 Feb 2020 14:49:23 -0000 > On Feb 6, 2020, at 11:08, Sean Turner wrote: >=20 > Hi! >=20 > tl;dr: confirming MTI suite selections and rationale for avoiding = proliferation >=20 > During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. >=20 > There was rough agreement that there should be one signature scheme = per group and that should be driven by the cipher suite. There are, at = least, three things to consider: 1) if a potential group member does not = support the algorithm, then they will not become a member or the group = will need to downgrade; 2) when the group needs/wants to update, it is a = flag day; and, 3) the cipher suites will have a similar combinatorial = issues as the TLS cipher suites prior to TLS 1.3. The agreement was = =E2=80=9Crough=E2=80=9D because 1) likely has some important = implications. >=20 > The MLS cipher suites defined were as follows:=20 > - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >=20 > At the interim, the consensus was to make the non-NIST suites the MTI. = The rationale was that those implementation that need to be NIST = compliant will do so regardless of the choice made by the WG. >=20 > In looking at the actual cipher suites, it was noted that the 256-bit = schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 = is SHA-512 cut in half, so just do SHA-512 because it is one less = operation. >=20 > To avoid the proliferation of cipher suites, guidance will be provided = to be conservative about allocating new code points. The consensus at = the interim was that the suites provided were minimal and provided good = coverage for the known use cases: > - (X25519, AES-GCM, Ed25519) - Good for desktop > - (P-256, AES-GCM, P-256) - Compliance > - (X25519, ChachaPoly, Ed25519) - Good for mobile >=20 > The chairs need to confirm the interim=E2=80=99s consensus on list, so = please let the WG know by 2359 UTC 20 February whether you disagree with = these choices and why. >=20 > NOTE: The final text will obviously be reviewed, but is being composed = as part of the following PR: > https://github.com/mlswg/mls-protocol/pull/279 >=20 > NOTE: We combined these cipher suite related consensus points, but if = we only come to consensus on some of these we can still incorporate what = we do agree on. I finally got around to doing my homework related to PR279. My bit was = the more procedural bits that instructs IANA to establish/use a = Designated Expert pool: https://github.com/mlswg/mls-protocol/pull/307 spt= From nobody Fri Feb 14 12:48:16 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09041201E3 for ; Fri, 14 Feb 2020 12:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cornell.edu 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 yKBnsUovqYxv for ; Fri, 14 Feb 2020 12:48:11 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3141201DC for ; Fri, 14 Feb 2020 12:48:10 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id r5so7865510qtt.9 for ; Fri, 14 Feb 2020 12:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=g.20171207; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RvOybXE87jaEdl5s0dwFWbURUIy5+OLhlgeNnCZ84DE=; b=Yj4T6jrNEDGMcG1kZHoNJ3tSoj3N+96yjTm/b0l+wEIchUS3kf27k8mutoqJKlA1vx S/94IwxMEpBoBJYG+XENIvGV3phbKiruD6klF48pTbd6hWTKX52CgeERxjdyACh/6zmb yOABtRSXb80AAw1PH1h/FIvT0Hl7MhNIlB5nYBw6B3eDwlQ26Vfn0RbxMbqKiilyA6aR l2M0p+CIHYV6Sl33EgxxNR0NAJIJMhZeIZFUVO3RVwpCr5gq9QleDxD4UaU78CyCyH8J xr6zEJDTe3Q6h9eGFAtx7iNDg6AF/wq7IURzoZLFtOde9+TSxQMn3BBkw5hOfu49TRhc t93g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RvOybXE87jaEdl5s0dwFWbURUIy5+OLhlgeNnCZ84DE=; b=cPFDOOqtB8CituR5V0ytvZfOlgo+3c+yao6UO8Xf98mr8aOQvcVrMQbpwDwEsOJADx 5u/JD/hS2k10XIIaV5lJ3oPcohYyt9wc609C/6AzttiyqXJvtIQvKIONrb6eNP+Afy2j vcF2eG/3fnHcgrNqeOzShBap10JYcsq1bLpITNqvs8cmPUaMnwykAkkMkFmxaXxmFurF CXTFJKBG5fH+AmdBdavjK6ocLJ6bO1NNYID3BDo3dPh5ncfzE5/KAnsvuqQXuO6FGhkc EzQ+jchmHXfJ452HVgMrJioJ/zKbea+lHfKUjby3TwTx+LD9ncbdFJ9xSDsOYfb8G4wL myQw== X-Gm-Message-State: APjAAAXUj3i7NqcTq8+b1M/7+V5BXlNUlFhkedOi1YgFRlXGZJKN3tYz ya6UxVDd0CsLAb2RIhFgHmEZizs1ZOY1wE3Du0UuJw== X-Google-Smtp-Source: APXvYqydUenQocoutKgi5sLAi7iBV2rvXB8V9V4nL7rcCAJi4KAaSGxIcdeZsWFgIv2VusE/O1NIyKmpBpRRWKwouEQ= X-Received: by 2002:ac8:4419:: with SMTP id j25mr4121674qtn.378.1581713289371; Fri, 14 Feb 2020 12:48:09 -0800 (PST) MIME-Version: 1.0 References: <9DE50F4A-DDBD-400E-8EA4-2D40A75CE028@sn3rd.com> In-Reply-To: <9DE50F4A-DDBD-400E-8EA4-2D40A75CE028@sn3rd.com> From: Paul Grubbs Date: Fri, 14 Feb 2020 15:47:58 -0500 Message-ID: To: Sean Turner Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000bffca0059e8f52f7" Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 20:48:14 -0000 --000000000000bffca0059e8f52f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, quick question - all the AE schemes used in these cipher suites are non-committing (meaning they misbehave in weird ways when keys may be adversarially known or chosen). Not including a cipher suite which uses a committing AE (cAE) scheme may make reasoning about the protocol's behavior difficult in some settings. Since the latency increase of committing AE would not be terribly high (one such scheme is AES128-CTR-then-HMAC-SHA384 with HKDF-derived encryption and authentication keys, which is reasonably close to what Signal uses), might the inclusion of a cAE cipher suite be worth discussing? On Thu, Feb 13, 2020 at 9:49 AM Sean Turner wrote: > > > > On Feb 6, 2020, at 11:08, Sean Turner wrote: > > > > Hi! > > > > tl;dr: confirming MTI suite selections and rationale for avoiding > proliferation > > > > During the F2F Interim in January, the WG discussed cipher > suites-related issues. Namely, whether a per-group signature scheme shoul= d > be driven by the chosen cipher suite, what were the MTI (Mandatory To > Implement) cipher suites, and what the actual algorithm should be. > > > > There was rough agreement that there should be one signature scheme per > group and that should be driven by the cipher suite. There are, at least, > three things to consider: 1) if a potential group member does not support > the algorithm, then they will not become a member or the group will need = to > downgrade; 2) when the group needs/wants to update, it is a flag day; and= , > 3) the cipher suites will have a similar combinatorial issues as the TLS > cipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough=E2=80=9D= because 1) likely > has some important implications. > > > > The MLS cipher suites defined were as follows: > > - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > > - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > > - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > > - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > > - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > > - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > > > > At the interim, the consensus was to make the non-NIST suites the MTI. > The rationale was that those implementation that need to be NIST complian= t > will do so regardless of the choice made by the WG. > > > > In looking at the actual cipher suites, it was noted that the 256-bit > schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 = is > SHA-512 cut in half, so just do SHA-512 because it is one less operation. > > > > To avoid the proliferation of cipher suites, guidance will be provided > to be conservative about allocating new code points. The consensus at the > interim was that the suites provided were minimal and provided good > coverage for the known use cases: > > - (X25519, AES-GCM, Ed25519) - Good for desktop > > - (P-256, AES-GCM, P-256) - Compliance > > - (X25519, ChachaPoly, Ed25519) - Good for mobile > > > > The chairs need to confirm the interim=E2=80=99s consensus on list, so = please > let the WG know by 2359 UTC 20 February whether you disagree with these > choices and why. > > > > NOTE: The final text will obviously be reviewed, but is being composed > as part of the following PR: > > https://github.com/mlswg/mls-protocol/pull/279 > > > > NOTE: We combined these cipher suite related consensus points, but if w= e > only come to consensus on some of these we can still incorporate what we = do > agree on. > > I finally got around to doing my homework related to PR279. My bit was th= e > more procedural bits that instructs IANA to establish/use a Designated > Expert pool: > https://github.com/mlswg/mls-protocol/pull/307 > > spt > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000bffca0059e8f52f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all, quick question - all the AE schemes used in these= cipher suites are non-committing (meaning they misbehave in weird ways whe= n keys may be adversarially known or chosen). Not including a cipher suite = which uses a committing AE (cAE) scheme may make reasoning about the protoc= ol's behavior difficult in some settings. Since the latency increase of= committing AE would not be terribly high (one such scheme is AES128-CTR-th= en-HMAC-SHA384 with HKDF-derived encryption and authentication keys, which = is reasonably close to what Signal uses), might the inclusion of a cAE ciph= er suite be worth discussing?

On Thu, Feb 13, 2020 at 9:49 AM Sean Turner &= lt;sean@sn3rd.com> wrote:


> On Feb 6, 2020, at 11:08, Sean Turner <sean@sn3rd.com> wrote:
>
> Hi!
>
> tl;dr: confirming MTI suite selections and rationale for avoiding prol= iferation
>
> During the F2F Interim in January, the WG discussed cipher suites-rela= ted issues. Namely, whether a per-group signature scheme should be driven b= y the chosen cipher suite, what were the MTI (Mandatory To Implement) ciphe= r suites, and what the actual algorithm should be.
>
> There was rough agreement that there should be one signature scheme pe= r group and that should be driven by the cipher suite. There are, at least,= three things to consider: 1) if a potential group member does not support = the algorithm, then they will not become a member or the group will need to= downgrade; 2) when the group needs/wants to update, it is a flag day; and,= 3) the cipher suites will have a similar combinatorial issues as the TLS c= ipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough=E2=80=9D be= cause 1) likely has some important implications.
>
> The MLS cipher suites defined were as follows:
> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519
> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256
> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519
> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448
> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521
> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448
>
> At the interim, the consensus was to make the non-NIST suites the MTI.= =C2=A0 The rationale was that those implementation that need to be NIST com= pliant will do so regardless of the choice made by the WG.
>
> In looking at the actual cipher suites, it was noted that the 256-bit = schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 is= SHA-512 cut in half, so just do SHA-512 because it is one less operation.<= br> >
> To avoid the proliferation of cipher suites, guidance will be provided= to be conservative about allocating new code points. The consensus at the = interim was that the suites provided were minimal and provided good coverag= e for the known use cases:
> - (X25519, AES-GCM, Ed25519) - Good for desktop
> - (P-256, AES-GCM, P-256) - Compliance
> - (X25519, ChachaPoly, Ed25519) - Good for mobile
>
> The chairs need to confirm the interim=E2=80=99s consensus on list, so= please let the WG know by 2359 UTC 20 February whether you disagree with t= hese choices and why.
>
> NOTE: The final text will obviously be reviewed, but is being composed= as part of the following PR:
> https://github.com/mlswg/mls-protocol/pull/279
>
> NOTE: We combined these cipher suite related consensus points, but if = we only come to consensus on some of these we can still incorporate what we= do agree on.

I finally got around to doing my homework related to PR279. My bit was the = more procedural bits that instructs IANA to establish/use a Designated Expe= rt pool:
https://github.com/mlswg/mls-protocol/pull/307

spt
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000bffca0059e8f52f7-- From nobody Sat Feb 15 00:20:03 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D47120044 for ; Sat, 15 Feb 2020 00:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9U1rLOL7mid for ; Sat, 15 Feb 2020 00:19:58 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A07712001B for ; Sat, 15 Feb 2020 00:19:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,443,1574118000"; d="scan'208,217";a="436135529" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.49]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 15 Feb 2020 09:19:43 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-C49FB91F-C4A1-455C-A164-B9474F216911 Content-Transfer-Encoding: 7bit From: Benjamin Beurdouche Mime-Version: 1.0 (1.0) Date: Sat, 15 Feb 2020 09:19:43 +0100 Message-Id: <4AA9B7B2-60EC-4AB4-85CA-FA5EA9F64D3F@inria.fr> References: Cc: Sean Turner , Messaging Layer Security WG In-Reply-To: To: Paul Grubbs X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 08:20:01 -0000 --Apple-Mail-C49FB91F-C4A1-455C-A164-B9474F216911 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, Yes, thanks for reminding us of this. This is something we need to think abo= ut seriously indeed... My intuition is that since we also have signatures we should be safe. But I a= gree that we have to evaluate carefully the differences between the committi= ng and non-committing modes. B. > On Feb 14, 2020, at 9:48 PM, Paul Grubbs wrote: >=20 > =EF=BB=BF > Hey all, quick question - all the AE schemes used in these cipher suites a= re non-committing (meaning they misbehave in weird ways when keys may be adv= ersarially known or chosen). Not including a cipher suite which uses a commi= tting AE (cAE) scheme may make reasoning about the protocol's behavior diffi= cult in some settings. Since the latency increase of committing AE would not= be terribly high (one such scheme is AES128-CTR-then-HMAC-SHA384 with HKDF-= derived encryption and authentication keys, which is reasonably close to wha= t Signal uses), might the inclusion of a cAE cipher suite be worth discussin= g? >=20 >> On Thu, Feb 13, 2020 at 9:49 AM Sean Turner wrote: >>=20 >>=20 >> > On Feb 6, 2020, at 11:08, Sean Turner wrote: >> >=20 >> > Hi! >> >=20 >> > tl;dr: confirming MTI suite selections and rationale for avoiding proli= feration >> >=20 >> > During the F2F Interim in January, the WG discussed cipher suites-relat= ed issues. Namely, whether a per-group signature scheme should be driven by t= he chosen cipher suite, what were the MTI (Mandatory To Implement) cipher su= ites, and what the actual algorithm should be. >> >=20 >> > There was rough agreement that there should be one signature scheme per= group and that should be driven by the cipher suite. There are, at least, t= hree things to consider: 1) if a potential group member does not support the= algorithm, then they will not become a member or the group will need to dow= ngrade; 2) when the group needs/wants to update, it is a flag day; and, 3) t= he cipher suites will have a similar combinatorial issues as the TLS cipher s= uites prior to TLS 1.3. The agreement was =E2=80=9Crough=E2=80=9D because 1)= likely has some important implications. >> >=20 >> > The MLS cipher suites defined were as follows:=20 >> > - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >> > - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >> > - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >> > - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >> > - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >> > - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >> >=20 >> > At the interim, the consensus was to make the non-NIST suites the MTI. = The rationale was that those implementation that need to be NIST compliant w= ill do so regardless of the choice made by the WG. >> >=20 >> > In looking at the actual cipher suites, it was noted that the 256-bit s= chemes the SHA should be SHA-512. The rationale agreed was that SHA-384 is S= HA-512 cut in half, so just do SHA-512 because it is one less operation. >> >=20 >> > To avoid the proliferation of cipher suites, guidance will be provided t= o be conservative about allocating new code points. The consensus at the int= erim was that the suites provided were minimal and provided good coverage fo= r the known use cases: >> > - (X25519, AES-GCM, Ed25519) - Good for desktop >> > - (P-256, AES-GCM, P-256) - Compliance >> > - (X25519, ChachaPoly, Ed25519) - Good for mobile >> >=20 >> > The chairs need to confirm the interim=E2=80=99s consensus on list, so p= lease let the WG know by 2359 UTC 20 February whether you disagree with thes= e choices and why. >> >=20 >> > NOTE: The final text will obviously be reviewed, but is being composed a= s part of the following PR: >> > https://github.com/mlswg/mls-protocol/pull/279 >> >=20 >> > NOTE: We combined these cipher suite related consensus points, but if w= e only come to consensus on some of these we can still incorporate what we d= o agree on. >>=20 >> I finally got around to doing my homework related to PR279. My bit was th= e more procedural bits that instructs IANA to establish/use a Designated Exp= ert pool: >> https://github.com/mlswg/mls-protocol/pull/307 >>=20 >> spt >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail-C49FB91F-C4A1-455C-A164-B9474F216911 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Yes, thanks for reminding us of this. This i= s something we need to think about seriously indeed...

My intuition is that since we also have signatur= es we should be safe. But I agree that we have to evaluate carefully the dif= ferences between the committing and non-committing modes.

B.


On Fe= b 14, 2020, at 9:48 PM, Paul Grubbs <pag225@cornell.edu> wrote:
=EF=BB=BFHey all, quick question - all the AE schemes used in these ciph= er suites are non-committing (meaning they misbehave in weird ways when keys= may be adversarially known or chosen). Not including a cipher suite which u= ses a committing AE (cAE) scheme may make reasoning about the protocol's beh= avior difficult in some settings. Since the latency increase of committing A= E would not be terribly high (one such scheme is AES128-CTR-then-HMAC-SHA384= with HKDF-derived encryption and authentication keys, which is reasonably c= lose to what Signal uses), might the inclusion of a cAE cipher suite be wort= h discussing?

On Thu, Feb 13, 2020 at 9:49 AM Sean Turner <sean@sn3rd.com> wrote:


> On Feb 6, 2020, at 11:08, Sean Turner <sean@sn3rd.com> wrote:
>
> Hi!
>
> tl;dr: confirming MTI suite selections and rationale for avoiding proli= feration
>
> During the F2F Interim in January, the WG discussed cipher suites-relat= ed issues. Namely, whether a per-group signature scheme should be driven by t= he chosen cipher suite, what were the MTI (Mandatory To Implement) cipher su= ites, and what the actual algorithm should be.
>
> There was rough agreement that there should be one signature scheme per= group and that should be driven by the cipher suite. There are, at least, t= hree things to consider: 1) if a potential group member does not support the= algorithm, then they will not become a member or the group will need to dow= ngrade; 2) when the group needs/wants to update, it is a flag day; and, 3) t= he cipher suites will have a similar combinatorial issues as the TLS cipher s= uites prior to TLS 1.3. The agreement was =E2=80=9Crough=E2=80=9D because 1)= likely has some important implications.
>
> The MLS cipher suites defined were as follows:
> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519
> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256
> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519
> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448
> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521
> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448
>
> At the interim, the consensus was to make the non-NIST suites the MTI.&= nbsp; The rationale was that those implementation that need to be NIST compl= iant will do so regardless of the choice made by the WG.
>
> In looking at the actual cipher suites, it was noted that the 256-bit s= chemes the SHA should be SHA-512. The rationale agreed was that SHA-384 is S= HA-512 cut in half, so just do SHA-512 because it is one less operation.
= >
> To avoid the proliferation of cipher suites, guidance will be provided t= o be conservative about allocating new code points. The consensus at the int= erim was that the suites provided were minimal and provided good coverage fo= r the known use cases:
> - (X25519, AES-GCM, Ed25519) - Good for desktop
> - (P-256, AES-GCM, P-256) - Compliance
> - (X25519, ChachaPoly, Ed25519) - Good for mobile
>
> The chairs need to confirm the interim=E2=80=99s consensus on list, so p= lease let the WG know by 2359 UTC 20 February whether you disagree with thes= e choices and why.
>
> NOTE: The final text will obviously be reviewed, but is being composed a= s part of the following PR:
> https://github.com/mlswg/mls-protocol/pull/279<= br> >
> NOTE: We combined these cipher suite related consensus points, but if w= e only come to consensus on some of these we can still incorporate what we d= o agree on.

I finally got around to doing my homework related to PR279. My bit was the m= ore procedural bits that instructs IANA to establish/use a Designated Expert= pool:
https://github.com/mlswg/mls-protocol/pull/307

spt
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS ma= iling list
MLS@ietf.org
https://www.ietf.org= /mailman/listinfo/mls
= --Apple-Mail-C49FB91F-C4A1-455C-A164-B9474F216911-- From nobody Sat Feb 15 04:27:14 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CAC120045 for ; Sat, 15 Feb 2020 04:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc9NlIeH_7EQ for ; Sat, 15 Feb 2020 04:27:10 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) (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 D14A7120048 for ; Sat, 15 Feb 2020 04:27:09 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1j2wXM-00048Z-q5 for mls@ietf.org; Sat, 15 Feb 2020 12:27:08 +0000 Received: from 61.ip-51-38-113.eu ([51.38.113.61] helo=[192.168.2.2]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1j2wXL-000278-Fd for mls@ietf.org; Sat, 15 Feb 2020 12:27:07 +0000 To: mls@ietf.org References: <4AA9B7B2-60EC-4AB4-85CA-FA5EA9F64D3F@inria.fr> From: Dennis Jackson Autocrypt: addr=dennis.jackson@cs.ox.ac.uk; prefer-encrypt=mutual; keydata= xsFNBFbAmb8BEADCLixsrAJyvknI95ZIZNVeDJbYvldeXpw7iyhrdUdRK69USU5S9EESulYh k1KlxDB5VfG8CCA/WzG1IonONdXmgLFa1NcmdVvkFjbXf5mbGYG+9pTkieM+UHikniAizIOi ibdTWEEc2opOAvpVypek4SSsfCoXfXqj0j5AXSapHiVzhhWuaXhKVuFdLtYwJDU/x0FXgStm erFMIOeZ5FLFnjkkNyEa1t3XCcf7bfgw8J86UmWzgkVLmtBYbDK0ZAFjtFep5Kps11iTDIa3 xYXzuqgkWwkg7b1mhn5gQUl/kKZqQbuG+Sk+BydjH8e1PJkO6p2eAprO0AoucRuuBl1pmg/F bf/WJC6/XD3AV87ERAdXbb9cH+vrRT8GpiNX5r+7OuXavc3/LNU9stqsdshXwdZlDyPyDIG2 Llj6hB4eS0tEpat3otcPDkXUjXjyOUQ6jKTNSZ+xTBtVTXznflDCGdn9GV0q+4ZbdRZ5tfXM DXM+uMqVxjvh2IjCrka7zf1rRWg1WZu+NrzAUrvPMPddDJfd8JNrIcvV+DIBxPVsUTJLEGt9 PW8LkQb5FrG7T6a813JYNoAtL4w7296UYmUpV1Kvv8otO+uH860x5Ci83ZCXb7gKr9Rankn5 Jcg+shWnDFgSq6uM/u3MmyRV2iw7aCSgcgfy4EPTojJdy3KjzQARAQABzS9EZW5uaXMgSmFj a3NvbiA8ZGVubmlzLmphY2tzb25AZXhldGVyLm94LmFjLnVrPsLBfwQQAQgAKQUCVsCZxQYL CQgHAwIJEGEFp3WM0kasBBUIAgoDFgIBAhkBAhsDAh4BAAoJEGEFp3WM0kasrt0QAIRAaRXL CZHIuU6UUIra1F7zYupS6w32AEC3FGPZ/a6e4Gsllbx0+6FuStAVUsvXRF0x+qE4akZb7+3c oE4V5SASZ36SI6HYT8cxbV2qe2k+wr94E9Nx8TihiLQXImFDH6b4LghqwSn+dKyZjITbbhlj F7/B7Sg5c53afx9oyRBgOyzhY64RSJwJOFpZ4txouPkdJ88FpQggHmvyfIfcnhdR3kbUTyck T9K3xMYpvfT37bj9dS0W635IRcmb+HxacGHyATUyMCIFv95A3kwXjtZGltQ8sSy3rJrCFvxt Q4O34/+B8TxYPZ+vNuKwA7DdkMNXmv2+aJ1kFemXuOv4+WjKs/QFpSmO/ca/Bl3AXi8S90ok 18IXy9507t2KH4EcipC43nqVE0rwXks+toJWp+l/+uYOeKNfU7l6Om3Svwz8pNYO64PCDla9 y+uycGtD+CqQA/CVr2FLd2D5fHZwC4G7o2i5wBJsQ10n6Jhln0MGf5HCjGOLqX3hGEHKv8/b 6u74yaQSKdbXpX+/kQVQzcmvSi2Ah60fI3ZXC8XJjDpJ9/0hBqnnxygdMLHzfzuLftTMBIuI MpNydfNBhvr0iBOQzrNK5MWJZ432kXbH8KkeofrhDmMQj4MCYPLmLGYnnJsWf7Y2rdFuN24j IHXdrjSE8zVkabpeyzRaXt6b1EfPzsFNBFbAmb8BEADgQ9QZjcuxVm6YPU5tznzDQv8i7Ohu 65NzhcOwYaYx1x0rBIHuPB27z5X3UfWmwNXJm4GEexMmjmr9bPboFOxLQwnCvMx2XGlIN4Av hXY7J5CEApH/9xytrMXGwUq5F9lLto47n72btdIP2mr5ArkxyFImAB4UFOZApESOzWL1yCpm j2Nipt2CFSedMfuBpRP1lWZPMB6b4rMQyJwYqM4lIwCKk7dGrebRNTm2ZLJdnjRzQsJaNeVh NoSiGAriSm+e8AgSmjiqP4EsP8jdg19x2lPzxfvKwopJCg4Rw63nxcBpKgX98x5ay4hyK/jj VWfIvXcTMoOUxEcY3d72eIWvu/HK/BvNxwvJUgRKT2JqHlOCfL1n/JIwZWotFJs8mURd0nmZ apXcaO8yYWKt8SLAxilbkgp+vNk3KBLEeVkv2Y3NGaB/2CKXVcvBUbuOXSdiFMx1crMzHzVi qG+2bEPSQl4l8qZiBerreZsL/HXQjHRuiXab4NX69HKAATWyUq1DPLhRJXZkRaQXWzcecUgi YzaPkLkxzl1rjt/xhUZrsfP5Fk5Xxd/nb339j8NwihDaMrIHDn5WEoXIzr/9N7EOgH8U5tiZ 4eXaiUqFZz1qXA8j6p95OM6GVtCEqqKyPMnoSW309wtCeYhF++XPLyVn1FIyIcjtAqR8QEzV t490MQARAQABwsFpBBgBCAATBQJWwJnHCRBhBad1jNJGrAIbDAAKCRBhBad1jNJGrPwmEAC2 RRYwuOvVFhNIw+uZOnc0Zl81JuW/QYYe0vtO9PWQXB1P+Gzb0aOuPQV99kTpEoMQaWz0Avot j+DfADlZCxdorTCrBvwwF4g9a8U+9VBuquJ83cBum6ROXg4IE7AlsdL8Y7VXcDBouXiXdT/6 TNHtSyezNaziSLMT2UEnQBgVvEHTFs8XqIjfYKYreess9+RcFfDbFfTWc4vFPH0Tth1Wk/dF 7Vz3poFN+WbgIAZR9NnnGBAxbquAnwUFzegtyS30xPSoHleSYoYjWSRHKk3uEgVEFw/F6B47 xLd+kFQ6inkXR6XbhNXHoolOS2kuaUh9SwRDQvEKo21STW/d4wKgqZ6TLxZsVxQCtFXgMpcM ArV7cLymgxp6FGB+XyyPPpK4fVVekIws0+k0y1kQrgVT4LSMaAnIdL03VRmOrxBrwWdgqu7I +BOkoQCyqWjm8HonymGJopfGet6fweoh/NB2u3zcz6tpdzv4WqKzilhLj298inFTNyq8pSJK AMYp6aozD3D1Tl0ERB4s1bTy44pKPIQ1Th7U5v8iKKYikQ8DksQiFJ84/0I31Ny6Uaq+jSDX ZecH6DkAC2bWiEyRvfdPXshHesqSGW8ghO5jWqJ9nPs6AZteHgbmhQdc0E6FcdqpEjNAIJFs FQUDT07IkEtYAYfodwz8N4zQjs2Dnm4yXw== Message-ID: Date: Sat, 15 Feb 2020 12:27:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <4AA9B7B2-60EC-4AB4-85CA-FA5EA9F64D3F@inria.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Oxford-Username: exet4027 Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 12:27:12 -0000 Hi Benjamin, Signatures are not committing (in general) [1]. E.g. with Ed25519, you can pick a public key such that you can produce a signature which is valid for any message. Best, Dennis [1] https://eprint.iacr.org/2019/779 On 15/02/2020 08:19, Benjamin Beurdouche wrote: > Hi Paul, > > Yes, thanks for reminding us of this. This is something we need to think > about seriously indeed... > > My intuition is that since we also have signatures we should be safe. > But I agree that we have to evaluate carefully the differences between > the committing and non-committing modes. > > B. > > >> On Feb 14, 2020, at 9:48 PM, Paul Grubbs wrote: >> >>  >> Hey all, quick question - all the AE schemes used in these cipher >> suites are non-committing (meaning they misbehave in weird ways when >> keys may be adversarially known or chosen). Not including a cipher >> suite which uses a committing AE (cAE) scheme may make reasoning about >> the protocol's behavior difficult in some settings. Since the latency >> increase of committing AE would not be terribly high (one such scheme >> is AES128-CTR-then-HMAC-SHA384 with HKDF-derived encryption and >> authentication keys, which is reasonably close to what Signal uses), >> might the inclusion of a cAE cipher suite be worth discussing? >> >> On Thu, Feb 13, 2020 at 9:49 AM Sean Turner > > wrote: >> >> >> >> > On Feb 6, 2020, at 11:08, Sean Turner > > wrote: >> > >> > Hi! >> > >> > tl;dr: confirming MTI suite selections and rationale for >> avoiding proliferation >> > >> > During the F2F Interim in January, the WG discussed cipher >> suites-related issues. Namely, whether a per-group signature >> scheme should be driven by the chosen cipher suite, what were the >> MTI (Mandatory To Implement) cipher suites, and what the actual >> algorithm should be. >> > >> > There was rough agreement that there should be one signature >> scheme per group and that should be driven by the cipher suite. >> There are, at least, three things to consider: 1) if a potential >> group member does not support the algorithm, then they will not >> become a member or the group will need to downgrade; 2) when the >> group needs/wants to update, it is a flag day; and, 3) the cipher >> suites will have a similar combinatorial issues as the TLS cipher >> suites prior to TLS 1.3. The agreement was “rough” because 1) >> likely has some important implications. >> > >> > The MLS cipher suites defined were as follows: >> > - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >> > - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >> > - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >> > - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >> > - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >> > - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >> > >> > At the interim, the consensus was to make the non-NIST suites >> the MTI.  The rationale was that those implementation that need to >> be NIST compliant will do so regardless of the choice made by the WG. >> > >> > In looking at the actual cipher suites, it was noted that the >> 256-bit schemes the SHA should be SHA-512. The rationale agreed >> was that SHA-384 is SHA-512 cut in half, so just do SHA-512 >> because it is one less operation. >> > >> > To avoid the proliferation of cipher suites, guidance will be >> provided to be conservative about allocating new code points. The >> consensus at the interim was that the suites provided were minimal >> and provided good coverage for the known use cases: >> > - (X25519, AES-GCM, Ed25519) - Good for desktop >> > - (P-256, AES-GCM, P-256) - Compliance >> > - (X25519, ChachaPoly, Ed25519) - Good for mobile >> > >> > The chairs need to confirm the interim’s consensus on list, so >> please let the WG know by 2359 UTC 20 February whether you >> disagree with these choices and why. >> > >> > NOTE: The final text will obviously be reviewed, but is being >> composed as part of the following PR: >> > https://github.com/mlswg/mls-protocol/pull/279 >> > >> > NOTE: We combined these cipher suite related consensus points, >> but if we only come to consensus on some of these we can still >> incorporate what we do agree on. >> >> I finally got around to doing my homework related to PR279. My bit >> was the more procedural bits that instructs IANA to establish/use >> a Designated Expert pool: >> https://github.com/mlswg/mls-protocol/pull/307 >> >> spt >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Sat Feb 15 23:41:19 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07899120013 for ; Sat, 15 Feb 2020 23:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=eJ/dpBUy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WfLEC3zn 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 duCdXrTEZvxn for ; Sat, 15 Feb 2020 23:41:14 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F41120019 for ; Sat, 15 Feb 2020 23:41:14 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A915060F for ; Sun, 16 Feb 2020 02:32:36 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 16 Feb 2020 02:32:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=8gg5YumonT1uVEZ/TtgVSXQyGIwoj4Awh5TtGOp73p4=; b=eJ/dpBUy E0korFL0F9O9gfK/FL8OHaMn3/uu5iCRKxG+AMKgJAr1iEndY29zoHT3G+nCwc8C bKz2WXQNj9cWzgB/Q2vQMDX/LRVBlQ6xb6EE3A/I23OLNGMPQSP9TsxGQDh63wVD SRz4VB49Vr0phw54dbarGHwzzydGtr9IhyazOOFBlFqdLVUs7fpaYMy+qmagHiiW Bg4BKWHmReNOM5oThbyc8NZ+1XsBf2bnomoOLjHSC2MOhufEEHisJFvV1cBnGAN1 QkOE3Ui7rJD8GZxlYTtIJ4Ei26BQtoo5Uz2ExOOhlwUoKkSx6AipwZtq+7Citu7V D/b28Yvh3MTAyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=8gg5YumonT1uVEZ/TtgVSXQyGIwoj 4Awh5TtGOp73p4=; b=WfLEC3znCyGfeqAhF6TyhjHV2bu1C0iFWs3bXGzJ5Xz4/ FtD1FVV1cIOFShMwltv1b/AIg3BCTXKP4v7MlY8+ZwxAMW16INXka1r2ssdiMFSD /caH/RGsuMMwlzlo9QPtGka1BLt1nSbPKtc8b52GX2aOQs1iJkNbaipyjt5kw8MW jU0SOCdBqC747+skgD66N+FNtwJquOypwkGTmRkZAS/l2tbhQ1la1kJWw/sq+JfL 4bYRJLeegQ+ynw1FKK4C5Ln5Czh9180ifY4aHH3ElFylhSPFFJGYTMns9okwjW2S 0JT2K/rs8feK8x48NiiPTcm84Krc0galdXumhNmaA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeefgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepudeikedriedurdegjedruddtjeenucevlhhushht vghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [168.61.47.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A8F03280062 for ; Sun, 16 Feb 2020 02:32:36 -0500 (EST) Content-Type: multipart/alternative; boundary="===============5814373449262995838==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200216073236.1A8F03280062@mailuser.nyi.internal> Date: Sun, 16 Feb 2020 02:32:36 -0500 (EST) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 07:41:17 -0000 --===============5814373449262995838== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - Update draft-ietf-mls-architecture.md (by balthorium) https://github.com/mlswg/mls-architecture/pull/61=20 1 pull requests received 1 new comments: - #61 Update draft-ietf-mls-architecture.md (1 by beurdouche) https://github.com/mlswg/mls-architecture/pull/61=20 1 pull requests merged: - Update draft-ietf-mls-architecture.md https://github.com/mlswg/mls-architecture/pull/61=20 * mlswg/mls-protocol (+3/-2/=F0=9F=92=AC8) 3 pull requests submitted: - DE-related text (by seanturner) https://github.com/mlswg/mls-protocol/pull/307=20 - Typos (by GaPhil) https://github.com/mlswg/mls-protocol/pull/306=20 - Update HKDFLabel variable to match naming conventions (by GaPhil) https://github.com/mlswg/mls-protocol/pull/305=20 4 pull requests received 8 new comments: - #306 Typos (1 by beurdouche) https://github.com/mlswg/mls-protocol/pull/306 [editorial]=20 - #305 Update HKDFLabel variable to match naming conventions (5 by GaPhil= , beurdouche, bifurcation) https://github.com/mlswg/mls-protocol/pull/305 [? invalid] [editorial] = - #304 Use HKDF to derive key pairs (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/304 [ready to merge]=20 - #279 Bring back more ciphersuites (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/279 [enhancement] [ready to = merge]=20 2 pull requests merged: - Update HKDFLabel variable to match naming conventions https://github.com/mlswg/mls-protocol/pull/305 [? invalid] [editorial] = - Typos https://github.com/mlswg/mls-protocol/pull/306 [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 --===============5814373449262995838== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday February 16, 2020

Pull requests

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

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

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

3 pull requests submitted:

4 pull requests received 8 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============5814373449262995838==-- From nobody Tue Feb 18 12:01:02 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFA1120913 for ; Tue, 18 Feb 2020 12:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctUNnkw3w842 for ; Tue, 18 Feb 2020 12:00:52 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 8BABA1208FC for ; Tue, 18 Feb 2020 12:00:52 -0800 (PST) X-ASG-Debug-ID: 1582056050-0e394549647f430001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id p5ghIi6zukUnXuyW for ; Tue, 18 Feb 2020 12:00:50 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Tue, 18 Feb 2020 12:00:50 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.168) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Tue, 18 Feb 2020 12:00:50 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dnphi8ClUuqUtGLkDdiZiPq8CI/7OeYZHRAINAjGa7JhItpiP4xA4kmUxVeiVvjtbFBxtG//ZJho77mjOGM71+ijuylkeO20+Nv93b8dAngUbLcMLB73SDEF5siFdO8HP/XHxOTlCVhjDaKF92w5wFMDxZf/0rwPJ3w4vBEyuMw4QcFAJSjKZ1owbi4y0PUnE3lSf4onyoTas6TbaQWUqRA51LKpffkhSxbilZ8wCFankyQACfXdgBVWTA95yZQ4wRRWhWyn8+tG9IGQpDBnb4RaB0BqOptqr/Equ/DnBxeQHEiBPGDaNyI89Buom4uIvE/DCbW24zOWh8OaH8W6Dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0Zk5bZs2O74VxbfznRcOU8CbrTUahIuUIROe7bkOvEk=; b=Xf8h1sMebB9NkjXV2MZ0L4fkooNgrBm2+Ycxpij21vK2iX1/79rIbxbB0eNPZuJOoEcZa4gYKRwAB/fdIe2GBC396qiS6L0ZvULN/o6bUYyqKZKYt0Q21BJJTn76SWkbhxTuF3DZ1llo1jWrcPpFUulyfAaXXZl6SVQgjZdRsrKIJ4idBeWtDtc/Ze1YlLAgTOm1SjiEO8sLA8z30j/yAVtnxmflxPlfQL2Us06nWK9N9WxO/94kEYjHIE/jzZ26pdkXBNqKCXXgA8Ep3El+I8ZS7xh3Kq8mqfO2FPm372zzOCwRDhdhBxrJX8MPW8iOzY6ac+fO6giSL9Pg4OxSGQ== 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 BYAPR13MB2533.namprd13.prod.outlook.com (52.135.228.150) by BYAPR13MB2775.namprd13.prod.outlook.com (20.178.239.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.6; Tue, 18 Feb 2020 20:00:49 +0000 Received: from BYAPR13MB2533.namprd13.prod.outlook.com ([fe80::f1dc:b7b6:2d4a:f8c3]) by BYAPR13MB2533.namprd13.prod.outlook.com ([fe80::f1dc:b7b6:2d4a:f8c3%7]) with mapi id 15.20.2750.016; Tue, 18 Feb 2020 20:00:49 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[20.178.239.91] X-Barracuda-Apparent-Source-IP: 20.178.239.91 From: "Hale, Britta (CIV)" To: Messaging Layer Security WG Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwA= Date: Tue, 18 Feb 2020 20:00:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [69.226.214.149] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca3ba6ef-a3bb-4ed9-df33-08d7b4ad4012 x-ms-traffictypediagnostic: BYAPR13MB2775: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 031763BCAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(39850400004)(396003)(346002)(199004)(189003)(66476007)(478600001)(53546011)(71200400001)(6512007)(66556008)(64756008)(66946007)(66446008)(2906002)(6506007)(76116006)(33656002)(6916009)(86362001)(8936002)(786003)(36756003)(26005)(2616005)(75432002)(186003)(316002)(8676002)(966005)(81166006)(81156014)(6486002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR13MB2775; H:BYAPR13MB2533.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9uRhsdvFGRB9Z0nU5gwM6huRrwjUMgAPoEbTre65A3lPE8DKXQpz1bPdRek9gaPsQXeNGDzk0NoHW3lYwLerO/5OZtR5Fk81IhEFxp1t3OQtzX4YlMGXF1iyd1wHrJfJTv2fBx4z3vo0TUBzrbb/+MsTiD6188zwkx1qOWMf392daPd6wGH85XWDn6OZCczTGsINl37i5PFn/rrW5Dh2s/BljYnonN4Hic3EjdrxqIUsfxTMTF2EVb+dmQ+irlfaOy4+jIyRBXBzDFNFWSnb+8Wxd9FGqmP/1Nby/kFRHR7jh2lHMzJSSZxgPZ91iYFp2sUErZdDz2C967jxpMsAVlzPVNpwzn19vQZB3dtS4n0pFV9heMtUgROTXodMdclr3/R30sU+aZiUUZf41uXnFYl1i5wadpt4kVGuH6UcpwRJB/dNBohdNs8otJW/g02GQUIH75Nygr9K/A2dTl8VMaexQdTH8+6BojCKI6HS5goeoXrySKdBPNoKYhIUCpQsk+q2vxz8PyHCocndG2uERA== x-ms-exchange-antispam-messagedata: dJO5uncIiJMotHbkoeYK8dwqbcxYJpASCXjfSBdKAY28BGYgwd5E/W5KqYlJSgvMj22Furl8VHr/SEFN85JUSyXxKcsurLoqr1vb1/mTlppKOKB5cfgqpb6DRpGqjHRvZbAuJarcloyI7Ru2cj+2Ow== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4EC88BEA2FA58743833353D72C200557@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ca3ba6ef-a3bb-4ed9-df33-08d7b4ad4012 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 20:00:49.1586 (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: Lqu+g/W+hUw8a2fMAZRZG3ITImFjo0BIwL6vcLDS9ZQggNJdzuSHEhKoVLNYEuiHGdFFea+xFj1MmHef6QZ5Eg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2775 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1582056050 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 7017 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80098 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 20:01:01 -0000 VW5kZXIgdGhlIHRvcGljIG9mIGluZGl2aWR1YWwvc2luZ2xlIHNpZ25hdHVyZSBzY2hlbWVzIHRo ZXJlIGlzIHRoZSBmaW5hbCBpc3N1ZSBvZiBmZWRlcmF0aW9uLiBJbiBhIGZlZGVyYXRlZCBjb250 ZXh0LCBncm91cHMgYXJlIG5vIGxvbmdlciB1bmRlciB0aGUgY29udHJvbCBvZiBhIHNpbmdsZSBh cHBsaWNhdGlvbiwgbWVhbmluZyB0aGF0IHdlIHdvdWxkIGxvc2Ugc29tZSBjb250cm9sIGluIGZv cmNpbmcgZ29vZCBjaXBoZXJzdWl0ZSBjaG9pY2VzLiBUaGlzIGNvdWxkIGxlYWQgdG8gdHdvIGlz c3VlczoNCg0KMSkgTUxTIHdvdWxkIG1vdmUgY2xvc2VyIHRvIGZhY2luZyB0aGUgVExTIHByb2Js ZW0gb2YgaGF2aW5nIG9sZCBzdWl0ZXMgc3VwcG9ydGVkIGJ5IGVkZ2UgY2FzZXMsIHdoaWNoIGlu IHR1cm4gd2Vha2VuIHRoZSBlbnRpcmUgZ3JvdXAncyBzZWN1cml0eS4gVGhlcmUgaXMgYWx3YXlz IHRoZSBhcmd1bWVudCB0aGF0IGdyb3VwcyB3b3VsZCBzaW1wbHkgcmVmdXNlIGpvaW5lcnMgdGhh dCBkbyBub3Qgc3VwcG9ydCB0aGUgY3VycmVudCBncm91cCBjaXBoZXIsIGJ1dCB0aGlzIGlzIG5v dCB2ZXJ5IHByYWN0aWNhbCBmcm9tIGEgdXNhYmlsaXR5IHZpZXcuIEUuZy4gaWYgZXZlcnlvbmUg dXNpbmcgYXBwbGljYXRpb24gWCByZWZ1c2VkIGdyb3VwIG1lbWJlcnMgd2hvIHdlcmUgdXNpbmcg YXBwbGljYXRpb24gWSwgdGhlbiB0aGUgcG9pbnQgb2YgZmVkZXJhdGlvbiB3b3VsZCBiZSBsYXJn ZWx5IGRlZmVhdGVkLiBTbywgZWl0aGVyIHNvbWUgZm9ybSBvZiByZW5lZ290aWF0aW9uIGlzIGFs bG93ZWQgKGUuZy4gZXhwb3J0IHBzaykgYW5kIGRvd25ncmFkZSBiZWNvbWVzIG1vcmUgbGlrZWx5 LCBvciBmZWRlcmF0aW9uIGRvZXMgbm90IHdvcmsgcmVsaWFibHkuIA0KDQoyKSBIZWFsaW5nIHdv dWxkIHRha2UgbG9uZ2VyLiBTaW5jZSBubyBvbmUgYXBwbGljYXRpb24gaGFzIGEgbWFzdGVyIHZp ZXcgYW5kIGNvbnRyb2wgb3ZlciBjaXBoZXJzdWl0ZXMsIHVwZ3JhZGluZyBsb25nLWxpdmVkIGdy b3VwcyB1c2luZyBxdWVzdGlvbmFibGUgY2lwaGVycyBjb3VsZCB0YWtlIGEgc2lnbmlmaWNhbnQg YW1vdW50IG9mIHRpbWUgKGFsbCBhcHBsaWNhdGlvbnMgd291bGQgbmVlZCB0byBkbyBzbyBpbiBv cmRlciBmb3IgdGhlIGdyb3VwIHRvIHVwZ3JhZGUpIG9yIGFsdGVybmF0aXZlbHkgcmVzdWx0IGlu IGtpY2tpbmcgZ3JvdXAgbWVtYmVycyBvdXQgb2YgdGhlIGdyb3VwIChhZ2FpbiwgcG9zc2libGUs IGJ1dCBxdWVzdGlvbmFibGUgZm9yIHVzYWJpbGl0eSBleGNlcHQgaW4gZXh0cmVtZSBjYXNlcyku IFVuZGVyIGFuIGluZGl2aWR1YWwgY2lwaGVyIGNob2ljZSwgYW55IG9uZSBtZW1iZXIgY2FuIGNo b29zZS91cGdyYWRlIHRoZWlyIHNjaGVtZSwgYWxsb3dpbmcgZm9yIGZhc3RlciBhZGFwdGFiaWxp dHkgYW5kIHBvdGVudGlhbCBiZW5lZml0cyB0byBQQ1MuIA0KDQpGcm9tIHRoZSBhYm92ZSwgaXQg c2VlbXMgdGhhdCBhIHNpbmdsZSBncm91cCBjaXBoZXIgbWFrZXMgZmVkZXJhdGlvbiBoYXJkZXIv c2xvd2VyL2xlc3Mgc2VjdXJlLCBidXQgSSBtYXkgbm90IGhhdmUgYSBjbGVhciB2aWV3IG9uIGhv dyBmZWRlcmF0aW9uIHdvdWxkIHdvcmsgaW4gdGhpcyBjb250ZXh0LiBEb2VzIGFueW9uZSBrbm93 IHdoZXRoZXIgdGhlIGFib3ZlIGFyZSByZWFsbHkgY29uY2VybnMgb3Igbm90IHJlbGV2YW50IGR1 ZSB0byBvdGhlciByZWFzb25zPyANCg0KKE5vdGUgdGhhdCB0aGlzIGlzIHRoaW5raW5nIGluIHRo ZSBsb25nLXRlcm0gY29udGV4dC4gT2J2aW91c2x5IHdlIGRvIG5vdCB3YW50IHRvIHN0YW5kYXJk aXplIGFueSBjaXBoZXIgY2hvaWNlIHRoYXQgaXMgc3ViLW9wdGltYWw7IGhvd2V2ZXIgYW55IG51 bWJlciBvZiB0aGluZ3MgbWF5IGhhcHBlbiB3aXRoIHByb3RvY29sIHZlcnNpb25pbmcgYW5kIGNp cGhlciBicmVha3Mgb3ZlciB0aGUgc3BhbiBvZiBzZXZlcmFsIHllYXJzLikNCg0KVW5kZXIgYWxs IHRoZSBjb25zaWRlcmF0aW9ucyB0aGF0IEkgaGF2ZSBzZWVuIHNvIGZhciwgdGhlIHByb3MgYW5k IGNvbnMgb24gYm90aCBzaWRlcyBwbGFjZSB0aGUgaW5kaXZpZHVhbCBzaWduYXR1cmUgY2lwaGVy IG9wdGlvbiBpbiB0aGUgbGVhZC4gSG93ZXZlciB0aGF0IGxlYWQgaXMgc21hbGwsIGhlbmNlIHdo eSBJIGhhdmUgbm90IGJlZW4gYXJndWluZyBmb3IgaXQuIFRoZSBpc3N1ZSBvZiBmZWRlcmF0aW9u IGNvdWxkIGJlIGEgZGVjaWRpbmcgZmFjdG9yLiBJZiB3ZSB3YW50IGZlZGVyYXRpb24gaW4gdGhl IGZ1dHVyZSBpdCBpcyBvZiBjb3Vyc2UgYmV0dGVyIG5vdCB0byBidWlsZCBpbmhpYml0aW5nIGZh Y3RvcnMgaW50byBNTFMgbm93IHRoYXQgY291bGQgdW5kZXJtaW5lIGVpdGhlciB1c2FiaWxpdHkg b3Igc2VjdXJpdHkgaW4gc3VjaCBjb250ZXh0cy4gVG8gbWFrZSBhIGNhc2UgdG8gcHJvY2VlZCB3 aXRoIHRoZSBzaW5nbGUgZ3JvdXAgY2lwaGVyIG9wdGlvbiwgaXQgd291bGQgYmUgZ3JlYXQgaWYg c29tZW9uZSBjb3VsZCBwcm92aWRlIGEgY29udmluY2luZyBhcmd1bWVudCBhcyB0byB3aHkgaXQg d291bGQgYmUgdGhlIGJlc3Qgb3B0aW9uIGZvciB1c2FiaWxpdHkgYW5kIHNlY3VyaXR5IGluIHRo ZSBmZWRlcmF0ZWQgZW52aXJvbm1lbnQgKG9yIHByZWNsdWRlIGEgZmVkZXJhdGVkIHVzZS1jYXNl IGFsdG9nZXRoZXIpLg0KDQotLS0NCg0KQnJpdHRhIA0KDQoNCu+7v09uIDIvMTIvMjAsIDg6MDEg QU0sICJNTFMgb24gYmVoYWxmIG9mIEhhbGUsIEJyaXR0YSAoQ0lWKSIgPG1scy1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBicml0dGEuaGFsZUBucHMuZWR1PiB3cm90ZToNCg0KICAgIEhp LA0KICAgIA0KICAgIENvbmNlcm5pbmcgdGhlIHVzZSBvZiBhIHNpbmdsZSBncm91cCBzaWduYXR1 cmUgc2NoZW1lIG9yIGluZGl2aWR1YWwgc2lnbmF0dXJlIHNjaGVtZXMsIGl0IGlzIHByb2JhYmx5 IHdvcnRod2hpbGUgdG8gZXhwYW5kIG9uIHRoZSBjb25zaWRlcmF0aW9uIHBvaW50cyBhbmQgY2xh cmlmeSB3aGF0IHNlY3VyaXR5IGltcGxpY2F0aW9ucyB3ZSBhcmUgYWNjZXB0aW5nIC0gaW4gZWl0 aGVyIGNhc2UuIEkgaGF2ZSBsaXN0ZWQgb3V0IHNvbWUgaXNzdWVzIGluIHRoZSBmb2xsb3dpbmcg R29vZ2xlIGRvYzoNCiAgICANCiAgICBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9k LzFaRHM0S0dwMF82a3BRWnBSSl90NGtWbG1nQTk0X3BNdGRTaWxJZEZLdzE0L2VkaXQ/dXNwPXNo YXJpbmcNCiAgICANCiAgICBJIGFtIG5vdCBtYWtpbmcgYW4gYXJndW1lbnQgZm9yIGVpdGhlciBj YXNlIGF0IHRoaXMgcG9pbnQsIGJ1dCBwdXNoaW5nIHRoaXMgb3V0IGZvciBkaXNjdXNzaW9uIGFu ZCB0byBoZWxwIHVzIGFjaGlldmUgbW9yZSBjbGFyaXR5IGFzIHRvIHRoZSBiZW5lZml0cyBhbmQg Y29uc2VxdWVuY2VzIG9mIGVpdGhlciBjaG9pY2UuIFRoZXJlIGFyZSBjZXJ0YWlubHkgbW9yZSBp c3N1ZXMgdG8gY29uc2lkZXIgKGUuZy4gZWFzZSBvZiBpbXBsZW1lbnRhdGlvbiwgZWZmaWNpZW5j eSwgZXRjLiBpbiBhZGRpdGlvbiB0byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucykgYW5kIG90aGVy IHZpZXdzIC0gZmVlbCBmcmVlIHRvIGFkZCB0aGVtIG9yIGRpc2N1c3Mgb24gdGhlIG1haWxpbmcg bGlzdC4gDQogICAgDQogICAgQWxsIHRoZSBiZXN0LA0KICAgICANCiAgICBCcml0dGEgDQogICAg IA0KICAgIA0KICAgIE9uIDIvNi8yMCwgODoxMSBBTSwgIk1MUyBvbiBiZWhhbGYgb2YgU2VhbiBU dXJuZXIiIDxtbHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc2VhbkBzbjNyZC5jb20+ IHdyb3RlOg0KICAgIA0KICAgICAgICBIaSENCiAgICAgICAgDQogICAgICAgIHRsO2RyOiBjb25m aXJtaW5nIE1USSBzdWl0ZSBzZWxlY3Rpb25zIGFuZCByYXRpb25hbGUgZm9yIGF2b2lkaW5nIHBy b2xpZmVyYXRpb24NCiAgICAgICAgDQogICAgICAgIER1cmluZyB0aGUgRjJGIEludGVyaW0gaW4g SmFudWFyeSwgdGhlIFdHIGRpc2N1c3NlZCBjaXBoZXIgc3VpdGVzLXJlbGF0ZWQgaXNzdWVzLiBO YW1lbHksIHdoZXRoZXIgYSBwZXItZ3JvdXAgc2lnbmF0dXJlIHNjaGVtZSBzaG91bGQgYmUgZHJp dmVuIGJ5IHRoZSBjaG9zZW4gY2lwaGVyIHN1aXRlLCB3aGF0IHdlcmUgdGhlIE1USSAoTWFuZGF0 b3J5IFRvIEltcGxlbWVudCkgY2lwaGVyIHN1aXRlcywgYW5kIHdoYXQgdGhlIGFjdHVhbCBhbGdv cml0aG0gc2hvdWxkIGJlLg0KICAgICAgICANCiAgICAgICAgVGhlcmUgd2FzIHJvdWdoIGFncmVl bWVudCB0aGF0IHRoZXJlIHNob3VsZCBiZSBvbmUgc2lnbmF0dXJlIHNjaGVtZSBwZXIgZ3JvdXAg YW5kIHRoYXQgc2hvdWxkIGJlIGRyaXZlbiBieSB0aGUgY2lwaGVyIHN1aXRlLiBUaGVyZSBhcmUs IGF0IGxlYXN0LCB0aHJlZSB0aGluZ3MgdG8gY29uc2lkZXI6IDEpIGlmIGEgcG90ZW50aWFsIGdy b3VwIG1lbWJlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBhbGdvcml0aG0sIHRoZW4gdGhleSB3aWxs IG5vdCBiZWNvbWUgYSBtZW1iZXIgb3IgdGhlIGdyb3VwIHdpbGwgbmVlZCB0byBkb3duZ3JhZGU7 IDIpIHdoZW4gdGhlIGdyb3VwIG5lZWRzL3dhbnRzIHRvIHVwZGF0ZSwgaXQgaXMgYSBmbGFnIGRh eTsgYW5kLCAzKSB0aGUgY2lwaGVyIHN1aXRlcyB3aWxsIGhhdmUgYSBzaW1pbGFyIGNvbWJpbmF0 b3JpYWwgaXNzdWVzIGFzIHRoZSBUTFMgY2lwaGVyIHN1aXRlcyBwcmlvciB0byBUTFMgMS4zLiBU aGUgYWdyZWVtZW50IHdhcyDigJxyb3VnaOKAnSBiZWNhdXNlIDEpIGxpa2VseSBoYXMgc29tZSBp bXBvcnRhbnQgaW1wbGljYXRpb25zLg0KICAgICAgICANCiAgICAgICAgVGhlIE1MUyBjaXBoZXIg c3VpdGVzIGRlZmluZWQgd2VyZSBhcyBmb2xsb3dzOiANCiAgICAgICAgLSBNTFMxMF8xMjhfSFBL RVgyNTUxOV9BRVMxMjhHQ01fU0hBMjU2X0VkMjU1MTkNCiAgICAgICAgLSBNTFMxMF8xMjhfSFBL RVAyNTZfQUVTMTI4R0NNX1NIQTI1Nl9QMjU2DQogICAgICAgIC0gTUxTMTBfMTI4X0hQS0VYMjU1 MTlfQ0hBQ0hBMjBQT0xZMTMwNV9TSEEyNTZfRWQyNTUxOQ0KICAgICAgICAtIE1MUzEwXzI1Nl9I UEtFWDQ0OF9BRVMyNTZHQ01fU0hBMzg0X0VkNDQ4DQogICAgICAgIC0gTUxTMTBfMjU2X0hQS0VQ NTIxX0FFUzI1NkdDTV9TSEEzODRfUDUyMQ0KICAgICAgICAtIE1MUzEwXzI1Nl9IUEtFWDQ0OF9D SEFDSEEyMFBPTFkxMzA1X1NIQTM4NF9FZDQ0OA0KICAgICAgICANCiAgICAgICAgQXQgdGhlIGlu dGVyaW0sIHRoZSBjb25zZW5zdXMgd2FzIHRvIG1ha2UgdGhlIG5vbi1OSVNUIHN1aXRlcyB0aGUg TVRJLiAgVGhlIHJhdGlvbmFsZSB3YXMgdGhhdCB0aG9zZSBpbXBsZW1lbnRhdGlvbiB0aGF0IG5l ZWQgdG8gYmUgTklTVCBjb21wbGlhbnQgd2lsbCBkbyBzbyByZWdhcmRsZXNzIG9mIHRoZSBjaG9p Y2UgbWFkZSBieSB0aGUgV0cuDQogICAgICAgIA0KICAgICAgICBJbiBsb29raW5nIGF0IHRoZSBh Y3R1YWwgY2lwaGVyIHN1aXRlcywgaXQgd2FzIG5vdGVkIHRoYXQgdGhlIDI1Ni1iaXQgc2NoZW1l cyB0aGUgU0hBIHNob3VsZCBiZSBTSEEtNTEyLiBUaGUgcmF0aW9uYWxlIGFncmVlZCB3YXMgdGhh dCBTSEEtMzg0IGlzIFNIQS01MTIgY3V0IGluIGhhbGYsIHNvIGp1c3QgZG8gU0hBLTUxMiBiZWNh dXNlIGl0IGlzIG9uZSBsZXNzIG9wZXJhdGlvbi4NCiAgICAgICAgDQogICAgICAgIFRvIGF2b2lk IHRoZSBwcm9saWZlcmF0aW9uIG9mIGNpcGhlciBzdWl0ZXMsIGd1aWRhbmNlIHdpbGwgYmUgcHJv dmlkZWQgdG8gYmUgY29uc2VydmF0aXZlIGFib3V0IGFsbG9jYXRpbmcgbmV3IGNvZGUgcG9pbnRz LiBUaGUgY29uc2Vuc3VzIGF0IHRoZSBpbnRlcmltIHdhcyB0aGF0IHRoZSBzdWl0ZXMgcHJvdmlk ZWQgd2VyZSBtaW5pbWFsIGFuZCBwcm92aWRlZCBnb29kIGNvdmVyYWdlIGZvciB0aGUga25vd24g dXNlIGNhc2VzOg0KICAgICAgICAtIChYMjU1MTksIEFFUy1HQ00sIEVkMjU1MTkpIC0gR29vZCBm b3IgZGVza3RvcA0KICAgICAgICAtIChQLTI1NiwgQUVTLUdDTSwgUC0yNTYpIC0gQ29tcGxpYW5j ZQ0KICAgICAgICAtIChYMjU1MTksIENoYWNoYVBvbHksIEVkMjU1MTkpIC0gR29vZCBmb3IgbW9i aWxlDQogICAgICAgIA0KICAgICAgICBUaGUgY2hhaXJzIG5lZWQgdG8gY29uZmlybSB0aGUgaW50 ZXJpbeKAmXMgY29uc2Vuc3VzIG9uIGxpc3QsIHNvIHBsZWFzZSBsZXQgdGhlIFdHIGtub3cgYnkg MjM1OSBVVEMgMjAgRmVicnVhcnkgd2hldGhlciB5b3UgZGlzYWdyZWUgd2l0aCB0aGVzZSBjaG9p Y2VzIGFuZCB3aHkuDQogICAgICAgIA0KICAgICAgICBOT1RFOiBUaGUgZmluYWwgdGV4dCB3aWxs IG9idmlvdXNseSBiZSByZXZpZXdlZCwgYnV0IGlzIGJlaW5nIGNvbXBvc2VkIGFzIHBhcnQgb2Yg dGhlIGZvbGxvd2luZyBQUjoNCiAgICAgICAgaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21scy1w cm90b2NvbC9wdWxsLzI3OQ0KICAgICAgICANCiAgICAgICAgTk9URTogV2UgY29tYmluZWQgdGhl c2UgY2lwaGVyIHN1aXRlIHJlbGF0ZWQgY29uc2Vuc3VzIHBvaW50cywgYnV0IGlmIHdlIG9ubHkg Y29tZSB0byBjb25zZW5zdXMgb24gc29tZSBvZiB0aGVzZSB3ZSBjYW4gc3RpbGwgaW5jb3Jwb3Jh dGUgd2hhdCB3ZSBkbyBhZ3JlZSBvbi4NCiAgICAgICAgDQogICAgICAgIENoZWVycywNCiAgICAg ICAgDQogICAgICAgIE5pY2sgYW5kIFNlYW4NCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgTUxTIG1haWxpbmcgbGlzdA0KICAg ICAgICBNTFNAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbHMNCiAgICAgICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgICBNTFMgbWFpbGluZyBsaXN0DQogICAgTUxTQGll dGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAg ICANCg0K From nobody Tue Feb 18 16:56:58 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60075120852 for ; Tue, 18 Feb 2020 16:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5QJOqG1M_njB for ; Tue, 18 Feb 2020 16:56:53 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 4F56F120832 for ; Tue, 18 Feb 2020 16:56:53 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id c188so21505435qkg.4 for ; Tue, 18 Feb 2020 16:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=WpUztaPWCtJw6vVu57MpElonIMCRWTI3GGS/1HxdmJ4=; b=Izan+5Xpa0A+9BriCJIV9yNpM0tTNH5tHEcPBCH4drQSLH3kkzu9/7vqW7vViB43b/ L10iIBeB+G+8In1/ipPs/6GvqxQfagqpJPOYmUvYeL8WdZXhbbBcMsDlTo8xWz8hG7hZ FEQ9/d1rOZnGXNweh0YomztEFMDiT6fC4xusU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=WpUztaPWCtJw6vVu57MpElonIMCRWTI3GGS/1HxdmJ4=; b=cOIiKvsWp0CmP+e+bMGFn8g3InDuc7EwqrpyNkYzXhYoc4vV/uPlCZDF12RaZPZv9k 7HguOGMOeWsY4ODli1Z3BmOh9PGhW3b9yvtJoRqbw2fBmjtnwiLSPEeUWWpWHquVj/iq qKeEkIAXsiQB/jGiRiCShW+kgUBm8S0Rh5qlMvJTSTgWTzzAHMaogvy2F7G5866+K0xn FXMcejc1fbvByjIc6n8G7OshCdmsbTqgX/A1nOSCUTzZC/UXI8kfoBcfroo5uIMRMej4 vsSMb9Db8Or35Wib0WigTXQc7TpQ82ggfc0dX53Pl3p5KVfFPaL1DFtuAXvtb6OH1Q08 aAmQ== X-Gm-Message-State: APjAAAUs57eSemcJaY3buh+QgThMQMaAdTO9Md6B5nVDDIcjZxYiR8Hv gXEUS8CcEqy0ReRBaudywgO47qIlkNTpOg== X-Google-Smtp-Source: APXvYqzfawzkiWRWw8Shcjx5P7eJA9LSEfk5LV9uSlI5Bh/inBW1O1qUa/PRD/V03rofrjzGp0sFoA== X-Received: by 2002:a05:620a:6c1:: with SMTP id 1mr21006508qky.419.1582073812091; Tue, 18 Feb 2020 16:56:52 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id 138sm208511qke.57.2020.02.18.16.56.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Feb 2020 16:56:51 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 18 Feb 2020 19:56:49 -0500 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> Message-Id: <18A288AF-9CFD-4EB4-96EF-C77463CF2555@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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: Wed, 19 Feb 2020 00:56:56 -0000 Apologies for the late reminder, but there is yet another virtual = interim scheduled for tomorrow. The call information is the same as last = week: Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= Meeting number: 647 391 156 Password: ve2i8niw = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g spt > On Feb 11, 2020, at 16:53, Sean Turner wrote: >=20 > As a reminder there is another virtual interim. This is the call = information: >=20 > Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= > Meeting number: 647 391 156 > Password: ve2i8niw >=20 > = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >=20 > spt >=20 >> On Feb 4, 2020, at 05:21, Sean Turner wrote: >>=20 >> As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >>=20 >> spt >>=20 >>> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>>=20 >>> As a reminder, the recurring virtual interim is tomorrow. Here's the = meeting information: >>>=20 >>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>> Meeting number: 647 391 156 >>> Password: ve2i8niw >>>=20 >>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>=20 >>> Nick & Sean >>>=20 >>> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >>> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>>=20 >>> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>>=20 >>> Here's the proposed schedule (subject to AD approval): >>> Time: 1400-1500 GMT on Wednesdays >>> Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >>>=20 >>> Links to the conference calls are forthcoming. >>>=20 >>> Nick & Sean >>>=20 >>> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes wrote: >>> Also: Note that despite this poll listing specific dates, the intent = is to set up a weekly recurring meeting. In fact, these dates will = definitely not be the dates when the calls happen, because IETF requires = one week notice. >>>=20 >>> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes wrote: >>> I would like to have some weekly calls to make faster progress on = our outstanding PRs. Here's a Doodle to find a good time: >>>=20 >>> https://doodle.com/poll/bg2q65phrvfip5zb >>>=20 >>> I believe these will need to be official Virtual Interims per IETF = process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>>=20 >>> --Richard >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 From nobody Tue Feb 18 16:58:27 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9543A120855 for ; Tue, 18 Feb 2020 16:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 J8saQcsRUmdu for ; Tue, 18 Feb 2020 16:58:20 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC56120832 for ; Tue, 18 Feb 2020 16:58:20 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id h4so21558022qkm.0 for ; Tue, 18 Feb 2020 16:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=SfaW1PJZb06cOJiiOab9OsXc8PXS9QEEuE/b4CNYICY=; b=ag/PJB2xBtReAYOlYMlKWE60R6eic3cJhZXWgJfCoemTkXEQsk+D2q/xhQ/f7USE/8 muDBLAS1PvsMezr0opjA8LBpW7mXH5tlI3hBQT5/lMosm119lFDX7DLvTIXsyg+vDlMu rZ32PgP+GFAdYx2pna8UgNKuhz8MRp/BoHFqU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=SfaW1PJZb06cOJiiOab9OsXc8PXS9QEEuE/b4CNYICY=; b=VQOE9txOuBh4H+BzRFeBdmJS345bXleB3jH+b3cIclpNaioHGYO9T7lDI73Nv2o32L 8gWcI/rD+h4hDU5mwWmZpNKR98cf9AN9jF56sdk1HS+VyFSyEyGNR7bv8J+Jgo+dBIq2 HSbnD0GKB0C5j/jnsWffcLEaug1/zQYEr0e2pGsIZ8PZ+W6ysfTnG8znK4SR2aMkHp/J 3uV9yRvionlB8SL8NB348fPNyMMrfVvZuebYWafd6AL8IhhfU+tUyBVW+4DMqufmGClC 0rTTkpY0EuMZvoG2PoA8gUg6e3YEoGhR5s19xUZ4L2QL1dchStqLL9bkecND7IKrlrVB iwRA== X-Gm-Message-State: APjAAAWjOvZWSBWKEvdVjXdHvwwwYkT8e3WyCvr6Yyvj7SJQ+r/tVCFM tv1y3kRrD0FAGz4bJZm+hBdHWyGMLSdMmw== X-Google-Smtp-Source: APXvYqxkAn4+GIWKtyK62Ar7uhcJ4dmEAP6n6+cCn8N5xzMMMNkpSvY+NB4sdzZW4938D9gqnt8SvQ== X-Received: by 2002:a37:8c1:: with SMTP id 184mr5049491qki.179.1582073899197; Tue, 18 Feb 2020 16:58:19 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id u12sm195610qke.67.2020.02.18.16.58.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Feb 2020 16:58:18 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 18 Feb 2020 19:58:18 -0500 References: <0BE71DF7-0BAB-4F90-8925-DFFE8D2B82E4@sn3rd.com> <34771848-5C49-4F86-BC45-36C6CCB25AD8@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <34771848-5C49-4F86-BC45-36C6CCB25AD8@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Virtual Interim minutes 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, 19 Feb 2020 00:58:24 -0000 I have upload the 1st 3 interim virtual meeting minutes to the IETF = datatrack. spt > On Feb 12, 2020, at 20:59, Sean Turner wrote: >=20 > MLSWG, >=20 > Draft minutes* available for the 3rd virtual interim at the link = below. As before, if you find an issue please submit a PR to Github: > = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-12-2020.md >=20 > spt >=20 > * Thanks to rlb. >=20 >> On Feb 11, 2020, at 21:11, Sean Turner wrote: >>=20 >> MLSWG, >>=20 >> Revised minutes from the first virtual interim posted at the link = below. If you find an issue, submit a PR to Github: >> = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/01-29-2020.md >> In one week, I will post the final minutes to the IETF site. >>=20 >> Draft minutes for the second virtual interim posted at the link = below. If you find an issue, submit a PR to Github: >> = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-05-2020.md >>=20 >> spt >>=20 >>> On Jan 29, 2020, at 16:38, Nick Sullivan = wrote: >>>=20 >>> MLSWG, >>>=20 >>> Draft minutes from the productive first virtual interim posted = below. If you find an issue, submit a PR to Github: >>> = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/01-29-2020.md >>>=20 >>> Nick & Sean >>>=20 >>>>>>=20 >>> Attendees: >>> Joel Alwen, Richard Barnes, Raphael Robert, Britta Hale, Brendan = McMillion, Nick Sullivan >>>=20 >>> #247 - Welcome confirmation and key derivation >>> * Fixes bugs RLB found in the last draft while implementing >>> * OK to merge after rebase / conflict resolution >>>=20 >>> #246 - Bugfixes in ClientInitKey, Commit, and Welcome >>> * Derives the Welcome encryption key instead of generating fresh >>> * ... under the general theory about not requiring freshness when = not necessary >>> * OK to merge after rebase / conflict resolution >>>=20 >>> #283 - Use the same ratchet for Handshake and Application keys >>> * There's no point to FS for Proposals because clients have to cache = the plaintext anyway >>> * Given that, the "flat derivation" approach should be fine >>> * We should have separate keys per sender to it easier to avoid = nonce collisions >>> * RLB and RR to decide whether we should derive nonces on a hash = ratchet or just use a counter >>>=20 >>> #287 - Switch to signing strategy using one signature per leaf. >>> * There was agreement among those on the call to proceed with this = strategy (tree-hash-covers-parent-hash) >>> * ... given the deniability concerns and unclear benefit of the = alternative (parent-hash-covers-tree-hash) >>> * If further considerations come to light from analysis, we can = revisit later >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 From nobody Tue Feb 18 22:09:54 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44701208A3 for ; Tue, 18 Feb 2020 22:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 pAzKLxwUb-9q for ; Tue, 18 Feb 2020 22:09:49 -0800 (PST) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (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 09C6F120091 for ; Tue, 18 Feb 2020 22:09:48 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 48MnPP1P2lzKmVC for ; Wed, 19 Feb 2020 07:09:45 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id cO0OUtxqNqJi for ; Wed, 19 Feb 2020 07:09:41 +0100 (CET) To: mls@ietf.org References: From: Konrad Kohbrok Message-ID: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> Date: Wed, 19 Feb 2020 07:09:09 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 19 Feb 2020 06:09:53 -0000 Hi Britta, I think you sum it up very nicely. There is one (albeit somewhat speculative) argument why a single ciphersuite per group might actually be beneficial in a federation context. In the event that there is "global concensus" that a ciphersuite needs to be deprecated, my expectation would be that a majority of the federation nodes/application providers would move to ban those ciphersuits, excluding anyone who would use _exclusively_ that ciphersuite. That would in turn be a motivation for all other nodes/application providers to catch up as well. This also means that nodes can't be made (by whatever authority) to use weak ciphersuites exclusively and still expect to federate with other nodes that have more sensible policies. That's mostly my guess of how the dynamics in such a federated environment _could_ work, though. Anyone here with some actual experience/expertise they can share of what the dynamics could be? Overall, I think I'm in favor of one-ciphersuite-per-group. It just seems a lot simpler and even in the context of federation, I think that most nodes/application providers would allow several ciphersuites to begin with, where not all of them are weak, meaning no one would really be excluded too quickly. Cheers, Konrad On 18.02.20 21:00, Hale, Britta (CIV) wrote: > Under the topic of individual/single signature schemes there is the final issue of federation. In a federated context, groups are no longer under the control of a single application, meaning that we would lose some control in forcing good ciphersuite choices. This could lead to two issues: > > 1) MLS would move closer to facing the TLS problem of having old suites supported by edge cases, which in turn weaken the entire group's security. There is always the argument that groups would simply refuse joiners that do not support the current group cipher, but this is not very practical from a usability view. E.g. if everyone using application X refused group members who were using application Y, then the point of federation would be largely defeated. So, either some form of renegotiation is allowed (e.g. export psk) and downgrade becomes more likely, or federation does not work reliably. > > 2) Healing would take longer. Since no one application has a master view and control over ciphersuites, upgrading long-lived groups using questionable ciphers could take a significant amount of time (all applications would need to do so in order for the group to upgrade) or alternatively result in kicking group members out of the group (again, possible, but questionable for usability except in extreme cases). Under an individual cipher choice, any one member can choose/upgrade their scheme, allowing for faster adaptability and potential benefits to PCS. > > From the above, it seems that a single group cipher makes federation harder/slower/less secure, but I may not have a clear view on how federation would work in this context. Does anyone know whether the above are really concerns or not relevant due to other reasons? > > (Note that this is thinking in the long-term context. Obviously we do not want to standardize any cipher choice that is sub-optimal; however any number of things may happen with protocol versioning and cipher breaks over the span of several years.) > > Under all the considerations that I have seen so far, the pros and cons on both sides place the individual signature cipher option in the lead. However that lead is small, hence why I have not been arguing for it. The issue of federation could be a deciding factor. If we want federation in the future it is of course better not to build inhibiting factors into MLS now that could undermine either usability or security in such contexts. To make a case to proceed with the single group cipher option, it would be great if someone could provide a convincing argument as to why it would be the best option for usability and security in the federated environment (or preclude a federated use-case altogether). > > --- > > Britta > > > On 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" wrote: > > Hi, > > Concerning the use of a single group signature scheme or individual signature schemes, it is probably worthwhile to expand on the consideration points and clarify what security implications we are accepting - in either case. I have listed out some issues in the following Google doc: > > https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing > > I am not making an argument for either case at this point, but pushing this out for discussion and to help us achieve more clarity as to the benefits and consequences of either choice. There are certainly more issues to consider (e.g. ease of implementation, efficiency, etc. in addition to security considerations) and other views - feel free to add them or discuss on the mailing list. > > All the best, > > Britta > > > On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" wrote: > > Hi! > > tl;dr: confirming MTI suite selections and rationale for avoiding proliferation > > During the F2F Interim in January, the WG discussed cipher suites-related issues. Namely, whether a per-group signature scheme should be driven by the chosen cipher suite, what were the MTI (Mandatory To Implement) cipher suites, and what the actual algorithm should be. > > There was rough agreement that there should be one signature scheme per group and that should be driven by the cipher suite. There are, at least, three things to consider: 1) if a potential group member does not support the algorithm, then they will not become a member or the group will need to downgrade; 2) when the group needs/wants to update, it is a flag day; and, 3) the cipher suites will have a similar combinatorial issues as the TLS cipher suites prior to TLS 1.3. The agreement was “rough” because 1) likely has some important implications. > > The MLS cipher suites defined were as follows: > - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > > At the interim, the consensus was to make the non-NIST suites the MTI. The rationale was that those implementation that need to be NIST compliant will do so regardless of the choice made by the WG. > > In looking at the actual cipher suites, it was noted that the 256-bit schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less operation. > > To avoid the proliferation of cipher suites, guidance will be provided to be conservative about allocating new code points. The consensus at the interim was that the suites provided were minimal and provided good coverage for the known use cases: > - (X25519, AES-GCM, Ed25519) - Good for desktop > - (P-256, AES-GCM, P-256) - Compliance > - (X25519, ChachaPoly, Ed25519) - Good for mobile > > The chairs need to confirm the interim’s consensus on list, so please let the WG know by 2359 UTC 20 February whether you disagree with these choices and why. > > NOTE: The final text will obviously be reviewed, but is being composed as part of the following PR: > https://github.com/mlswg/mls-protocol/pull/279 > > NOTE: We combined these cipher suite related consensus points, but if we only come to consensus on some of these we can still incorporate what we do agree on. > > Cheers, > > Nick and Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Sat Feb 22 23:41:28 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB06E3A0FCD for ; Sat, 22 Feb 2020 23:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=LWQ/LzNc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Az+XK9Tp 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 h8ijlJgR_jrq for ; Sat, 22 Feb 2020 23:41:23 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB263A0FC1 for ; Sat, 22 Feb 2020 23:41:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EFAE8218C1 for ; Sun, 23 Feb 2020 02:32:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 23 Feb 2020 02:32:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=BDxY8FE6E2rQD+e9tFCoZYBwBrGYDpL06d+L4/yZlWE=; b=LWQ/LzNc 6ZJWlkbKH1Q2mU6TX6jHNP8WFDOQ5a0PKtNNp/nFrYugbsYa+6L6XdRRpf1fXYmx MAzwldpd8W8txtdytd2zWWUG60MyzdC3N094qDKXuAiXTFMfuw6KgvaH00b88NBg J13rcgcs4qaQ/wvnLuBm5dlBOy1G8CMqj3ez+Ba1oJ9Zvb4wrqIfqtib3d+tCwZB jSKRFu8A4EbJ3V11yFsB+PBjbahgzivvmVHZaKAKT1H5pEGZFHrOCejcBCqGFTdR AHJjf0UGP/j08YF64TLeO5S8MUfWAsuBDjQ3GSMVKM93nwlIxgSFWdVbqkJ2gpA/ La3feIWV6re3cw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=BDxY8FE6E2rQD+e9tFCoZYBwBrGYD pL06d+L4/yZlWE=; b=Az+XK9TpQzF2qw2Qqwx+BkPJTZUVGafmgthFq6l8yQQJf kYn+6RoP6+2lFUItNEx7+GtIiYf2vUpnBAG1L2dO2OlmBv107sncYAlijFeL0pDV gP5vHcR77fd3TRt46YRu4+4ND9h1zqcYrdjVb9yBhTUtVmr1IlYFJg2pdYrDLwey WmT6gUIGdpX0wea8fSlPapJSG8kW+QweuVg+dQ8ioup2j1IXBO+Pg8Hl6GUJnNfk lJrvcYDYjOL1lYNNOcpTTyA8JIVlLypEwG6QIubERRS3IxKHPycK5+bv4R0jDNqd w2IlJc41Ig2gcAQ73wOQ23iSGsamPcYc1KvZJgeLw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeejgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepudefrdeikedrvddvtddrudejvdenucevlhhushht vghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [13.68.220.172]) by mail.messagingengine.com (Postfix) with ESMTPA id BAE023060D1A for ; Sun, 23 Feb 2020 02:32:28 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6105163664177643672==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200223073228.BAE023060D1A@mailuser.nyi.internal> Date: Sun, 23 Feb 2020 02:32:28 -0500 (EST) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2020 07:41:26 -0000 --===============6105163664177643672== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC0) 1 issues closed: - Address risk of re-using nonces after state loss https://github.com/mls= wg/mls-protocol/issues/216 [security] [work in progress]=20 Pull requests ------------- * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC2) 1 pull requests received 2 new comments: - #303 Add some per-message entropy (2 by beurdouche, bifurcation) https://github.com/mlswg/mls-protocol/pull/303=20 1 pull requests merged: - Add some per-message entropy https://github.com/mlswg/mls-protocol/pull/303=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============6105163664177643672== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday February 23, 2020

Issues

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

1 issues closed:

Pull requests

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

1 pull requests received 2 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============6105163664177643672==-- From nobody Tue Feb 25 09:20:29 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B203A1121 for ; Tue, 25 Feb 2020 09:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 94LvR-8pkIPs for ; Tue, 25 Feb 2020 09:20:27 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 21A4F3A1114 for ; Tue, 25 Feb 2020 09:20:27 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id p7so12575478qkh.10 for ; Tue, 25 Feb 2020 09:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=D7I8Deh8d/SAHMfHtjm+FEKQ0W7eTMOem/clIiCjVxc=; b=CE2o+WEEegTsScjYCBwE+9ls0Wy6wk3fn9k227W42ku85/3o3L3LZZABaWAO50kIAw pg5IDumyftGGuzXzVC7gKeOG5Q1WU7RIe2Ue/znxPeZYd9Ke7YczErOEXs1fVWnOhTRc C4b9J8DVoRgHMqv/NE6HvFslLk9VkDFwFhmIc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=D7I8Deh8d/SAHMfHtjm+FEKQ0W7eTMOem/clIiCjVxc=; b=Ar66ByX972mcUDI7lxYXhpjU8T1xlHEMgjWwHnPddn2qfXWLGXVcrvexDSNl0yOADG H9ClsIOQC+nsgK70Gs3S81ReBsWwI+iAqEESCmqSRKqkJCtul7P+zPbp1394YNIkUsgq LALDLcgjOLD7JreOSFP8FxWBCCFsk4psnigJ6EuUENmppVUw2CiZwHWa/ZOm7AgL5RFa 1nqQQOdiIEQSlYIP+l/Tz+dkVjXW29retbAgRM7V8GXEIVEY+vGhB2L7Rk2i18SaYqxI IPLAX80LE5m1gT6GVFCO2lKBfVa1WkbluNhixQt1OXf0I1czXzrMOiybko/VTuKCZIfm OPaA== X-Gm-Message-State: APjAAAWpJQ6CWcJSHJsw+yE1cJgkLJsY1h6y5ZkjlfMQgIKYTh3iE4V+ b8O0DGPmLvyh3E0jqJwyOffmODR8TAo= X-Google-Smtp-Source: APXvYqwJ6RsPumqNikNp8gG39Th7TYTVNokGatNi6h6TRVbZlgdYGT6iu2pjXiJA5ce6AMNRf94YaA== X-Received: by 2002:a37:670b:: with SMTP id b11mr8850433qkc.381.1582651225846; Tue, 25 Feb 2020 09:20:25 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id z6sm7647839qka.34.2020.02.25.09.20.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 09:20:25 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Feb 2020 12:20:24 -0500 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> <18A288AF-9CFD-4EB4-96EF-C77463CF2555@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <18A288AF-9CFD-4EB4-96EF-C77463CF2555@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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, 25 Feb 2020 17:20:29 -0000 Please note that there is another meeting tomorrow. Same time, place, = and details: Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= Meeting number: 647 391 156 Password: ve2i8niw spt > On Feb 18, 2020, at 19:56, Sean Turner wrote: >=20 > Apologies for the late reminder, but there is yet another virtual = interim scheduled for tomorrow. The call information is the same as last = week: >=20 > Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= > Meeting number: 647 391 156 > Password: ve2i8niw >=20 > = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >=20 > spt >=20 >> On Feb 11, 2020, at 16:53, Sean Turner wrote: >>=20 >> As a reminder there is another virtual interim. This is the call = information: >>=20 >> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >> Meeting number: 647 391 156 >> Password: ve2i8niw >>=20 >> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>=20 >> spt >>=20 >>> On Feb 4, 2020, at 05:21, Sean Turner wrote: >>>=20 >>> As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >>>=20 >>> spt >>>=20 >>>> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>>>=20 >>>> As a reminder, the recurring virtual interim is tomorrow. Here's = the meeting information: >>>>=20 >>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>> Meeting number: 647 391 156 >>>> Password: ve2i8niw >>>>=20 >>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>=20 >>>> Nick & Sean >>>>=20 >>>> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >>>> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>>>=20 >>>> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>>>=20 >>>> Here's the proposed schedule (subject to AD approval): >>>> Time: 1400-1500 GMT on Wednesdays >>>> Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >>>>=20 >>>> Links to the conference calls are forthcoming. >>>>=20 >>>> Nick & Sean >>>>=20 >>>> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes wrote: >>>> Also: Note that despite this poll listing specific dates, the = intent is to set up a weekly recurring meeting. In fact, these dates = will definitely not be the dates when the calls happen, because IETF = requires one week notice. >>>>=20 >>>> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes wrote: >>>> I would like to have some weekly calls to make faster progress on = our outstanding PRs. Here's a Doodle to find a good time: >>>>=20 >>>> https://doodle.com/poll/bg2q65phrvfip5zb >>>>=20 >>>> I believe these will need to be official Virtual Interims per IETF = process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>>>=20 >>>> --Richard >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>=20 >>=20 >=20 From nobody Tue Feb 25 09:28:29 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F0E3A110B for ; Tue, 25 Feb 2020 09:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 EY55zfqzw6rx for ; Tue, 25 Feb 2020 09:28:25 -0800 (PST) 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 7B9053A110A for ; Tue, 25 Feb 2020 09:28:25 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id l16so225131qtq.1 for ; Tue, 25 Feb 2020 09:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=DFKFUQXFBTFnNRjIvntqrc3Mj3vOGZqv/oqB5OSFzqg=; b=NQjLWjrimsm0rFI6RV2isASSkpZ3GYVlFHFp/n+Jvf8+KghXgcsqbnH4vUlPRtZDjY E9yOYPs4HCFOB93/IRsIr32kjsW+j7DHouOxo7QT1xZ9g0aHct/9AKIcav+Gw+Ekg9yv gYG3HJ6qLS/WM7liOq8Z+OQdxsMvOMn4/7BmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=DFKFUQXFBTFnNRjIvntqrc3Mj3vOGZqv/oqB5OSFzqg=; b=YU3/wR9JwfnvXEdn6cVEMrLTzAl7+fNvxhh7oFzcAfIoZkQKXuysI8W8EBQb7IXaZ5 wDwnt4CSyr5wPIvwvuIS2m6rzDq0Pb+r9Jgopfj22liWcJCU8UtCrU5JhoA7igcFM763 V9QXVDbSvMPp0PV492fXl2CZiI5nxM4N9Jk4jxEEd7apu+MRPPf1oQg3K/op+X+KQWnu /SJCAf69P2Tt9tbSc2WxXzp2Ox+jnEcfHwQzIJ+601E8PXS4kaHyLAWFpi8Jc1aootXo /GY4H1LGFuxu3PCWdhfkYRVHJuDw7+j7WOhmw3LLfStpOg28+APIdvRpc/FMg3Btoivm 2NtA== X-Gm-Message-State: APjAAAVxdr6sJcb6ZA63t0bF/9kHvFmxJcJzpa8z4btf422Y5HQkT8kS jMC7nTgorAzJHlf2gv5QyNAwAtxp7H8= X-Google-Smtp-Source: APXvYqzXJxIJgk9HvKlxKqkDGF5l7DhyeU8qp7lvMsZVF82u9AVVaFAfsW/UtJfv9g7+HGytDCUcFg== X-Received: by 2002:ac8:741a:: with SMTP id p26mr53694675qtq.76.1582651704209; Tue, 25 Feb 2020 09:28:24 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id i5sm7849611qtq.12.2020.02.25.09.28.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 09:28:23 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Feb 2020 12:28:22 -0500 References: To: Messaging Layer Security WG In-Reply-To: Message-Id: <9CBDE5F7-9D74-43C7-863E-7F1E1DED4AE8@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming state recovery way forward 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, 25 Feb 2020 17:28:27 -0000 Hi! I am going to go ahead and confirm that WG=E2=80=99s consensus for the = plan outlined below. I also confirmed with Emad and Jon that they are = still willing to start the individual draft. The WG will then consider = whether it is a good starting point. Hoping that we can review the draft = at IETF 107. NOTE: 2020-03-09 UTC 23:59 is the submission deadline for IETF 107. Cheers, spt > On Feb 6, 2020, at 11:08, Sean Turner wrote: >=20 > Hi! >=20 > tl;dr: confirming new individual draft that describes state recovery = (i.e., the need for ACKs/NACKs). >=20 > During the F2F Interim in January, the WG discussed how to address = state recovery. One reason you might want ACKs/NACKS is if you sent a = Commit and then some data, and the Commit is lost. In this case, your = data didn=E2=80=99t get sent and the data needs to be resent. There are = obvious implications because messages shouldn=E2=80=99t just be re-sent = to the group after many months. After a lengthy discussion about this = and other synchronization issues, the consensus at the interim was that = an individual draft is needed to describe state recovery-related issues. = After this draft is published, the WG can review it and decide whether = it should be accepted as a workable starting point and potential WG item = or be merged into an existing draft. >=20 > The chairs need to confirm the interim=E2=80=99s consensus on list, so = please let the WG know by 2359 UTC 20 February whether you disagree with = the way forward and why. >=20 > FYI: Jon and Emad volunteered to write this draft. >=20 > Cheers, > Nick and Sean From nobody Tue Feb 25 09:28:40 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D553A1110 for ; Tue, 25 Feb 2020 09:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 dhFodhhzu4Um for ; Tue, 25 Feb 2020 09:28:37 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A553A1181 for ; Tue, 25 Feb 2020 09:28:37 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id j23so176104qtr.11 for ; Tue, 25 Feb 2020 09:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=3e68LEk8pBKc34uvGyFKz7N81pa2GSYMi8ZjgQdo4xs=; b=nB9QLNejV8xntE1ckbTV5Mq3yZF74HqfV9xP+URXgj/9ZBZTmhCdEW8DiFWag0i61W 9m4kmLcv9cCq0WmGWYlvDORitlScElXqEqIHPZiT+y5QuXYe64kL6cWtfI2A5pzczZBP 8dFBK2ZiFnNd7CIjUfSfd+ZaiqotI7ch/l35c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=3e68LEk8pBKc34uvGyFKz7N81pa2GSYMi8ZjgQdo4xs=; b=bnGDc3GUbTSIn/y/dPcUuDx5wz9ZBfQiXJEDKyWWNaZ3rh7GKjBgOikZ1bmW4mcbJI U58FgMIe7Ku6eAR6kjcShAJQgs+btg4jP2NS0c3xLshccywWF0yqtpLGJWY9N8IptGCT d3pmtGzHqOpvK8ykmzS59elOp6A2qpKGHMwn4N+QYzy5/RLuho3BrrXDA1/ytP2NLjb1 E8LaDXgzj4rpPtORdvV8/SgXlagaXZX6QmS2eS1LXwAM1bFPngo/KY1pLhk5evDhOaoG Xo6tUVMs6QJtuXT1KIBl8RHI9pm9MqIAPag6NiKCaIATjljvqEvSVOU/3UMblCF+t3VY QX1g== X-Gm-Message-State: APjAAAX2hzHSeXxlr2lB02VEAj8aivn5UzD5PJXbrezeXejyxWLIrZpL GrIwLW+HJChJ0da4l35zc3s3WnB0V0s= X-Google-Smtp-Source: APXvYqzg5SDVbHY9HSqhUz8ihy5lQFVXubsKJHQF0d+FyqOB+ybYcByXaHjHR655oXSs/VN+tJRVAQ== X-Received: by 2002:ac8:83d:: with SMTP id u58mr53417609qth.60.1582651716188; Tue, 25 Feb 2020 09:28:36 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id i5sm7849611qtq.12.2020.02.25.09.28.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 09:28:35 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Feb 2020 12:28:35 -0500 References: To: Messaging Layer Security WG In-Reply-To: Message-Id: <37975132-D4D8-48BB-97E0-13995E5CB0F8@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming server assist way forward 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, 25 Feb 2020 17:28:39 -0000 Hi! I am going to go ahead and confirm that WG=E2=80=99s consensus for the = plan outlined below. I also confirmed with Raphael and Benjamin that = they are still willing to start the individual draft (in fact I think = they already have a repo). The WG will then consider whether it is a = good starting point. Hoping that we can review the draft at IETF 107. NOTE: 2020-03-09 UTC 23:59 is the submission deadline for IETF 107. Cheers, spt > On Feb 6, 2020, at 11:08, Sean Turner wrote: >=20 > Hi! >=20 > tl;dr: confirming new individual draft to describe server assist. >=20 > During the F2F Interim in January, the WG had a lengthy discussion = about server assist. We wrestled with the tussle between privacy and the = desire to support very large groups, which just about everybody, if not = everybody, believes requires some type of server assist because adding a = new member to a large group requires sending megabytes of data in the = Welcome message and this can be too much for some devices. Normally, the = AS and DS is split and maybe these functions are collapsed in IRL, but = Benjamin suggested that we split the functionality up a bit more to talk = more fine-grained about the guarantees we want. The functional split = suggested was as follows [0]: >=20 > - AS: Authentication Service (Signature Keys) > - DS: Delivery Service > -- CS: Credential Retrieval Service (CIKs) > -- IDS: Message Reception Service (Input) > --- IDS is responsible for message ordering. > -- ODS: Message Delivery Service (Output) > --- IDS and ODS may be combined. > - SDS: Storage Delivery Service (Welcome+Backup) > -- SDS is optional. >=20 > Likewise, they suggested that we switch from a model where there is = one queue per group, to one queue per recipient. >=20 > The consensus at the interim was that it is important to support = server assist and that it was equally important to provide truth in = advertising, i.e., those that implement the functionality need to = understand the security guarantees that are available. >=20 > There was also consensus to produce an individual draft that describes = server assist. After this draft is published, the WG can review it and = decide whether it should be accepted as a workable starting point and = potential WG item. >=20 > The chairs need to confirm the interim=E2=80=99s consensus on list, so = please let the WG know by 2359 UTC 20 February whether you disagree with = the way forward and why. >=20 > FYI: Benjamin and Raphael volunteered to write this draft. >=20 > Cheers, >=20 > Nick and Sean >=20 > [0] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/04-archi= tecture.pdf > [1] = https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/minutes.= md From nobody Tue Feb 25 09:29:11 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31013A1146 for ; Tue, 25 Feb 2020 09:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 868TtYe1ndmz for ; Tue, 25 Feb 2020 09:29:08 -0800 (PST) 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 AD2873A112D for ; Tue, 25 Feb 2020 09:29:08 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id y2so5639qvu.13 for ; Tue, 25 Feb 2020 09:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=UsKGQ4NmT6lC50sRXu9YJruQj5qo5W3dtcN2kQR8zSk=; b=CLZhu38hM0jMPi7UcHTRmbd2UpsWyihLxux0vG5l7KUjcJem8rzVSbjygESxakffJ/ vX3nL3VnaTO4MEiXlZqAt1iZyq8F5SrCwl0RwczWIRg3G+tVokRLNxhqhoXwHqujwAvn HPO8clqHXQITh9qpM98zmziW2yNkDSObKjDJU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=UsKGQ4NmT6lC50sRXu9YJruQj5qo5W3dtcN2kQR8zSk=; b=ViVeVCJskd+k9g9V9HI3kZG9guUxcAT7/zvfa8q4wRGuHWJ0/lBmLAIzuK/KECH0A2 wLLfZwXJtOCbP4LhxG7iXkPsvi1yeUcoHy5VStEFIVzNZALxIEOLtAazZaIj6Bdr6wiw hsVVdL2NgdyrvlYwoa4h5gxuc6yyQFEFxKPrBzeZ2zzkjoad90mJl/snPGQ9mh8E5rSb bbo1exd2jLOsAbbiEbDPJVzDfmUPBmMW1RD3OeXBJQWsjTf4y6vq+SR1NQCJkPOnvIzJ hAin2R6cXg1agfdPZQt10+9FPQwkFCzeBgKmtCOPYgbIxYcgYVuOIot03Xv3S7onx++e sSRg== X-Gm-Message-State: APjAAAVR1QBzgk2RDRgrbSdlt1k3nSpPx+VSYbgBVwSshtp4JMwMWxvC tgd7TbJZ4FgcgjFi+TholYmT8qeW+Kk= X-Google-Smtp-Source: APXvYqwYEWPEMrFD/5ovmDCNd8uJoAOWrgTSCKwTFDgFRMxRu+56amjB7hWxmCXSDj9Mj+iZ40MQ+Q== X-Received: by 2002:a05:6214:524:: with SMTP id x4mr52319695qvw.4.1582651747617; Tue, 25 Feb 2020 09:29:07 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id i5sm7849611qtq.12.2020.02.25.09.29.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 09:29:07 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <101134CD-4B65-4172-9F82-C9466AE0B021@sn3rd.com> Date: Tue, 25 Feb 2020 12:29:06 -0500 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] confirming merge for 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, 25 Feb 2020 17:29:10 -0000 All, The following PRs were 1st discussed at the 5-Feb virtual interim. The = WG discussed them again on the 1-Feb call and the editors believe these = are ready to merge. If have any objections to merging these please = provide your input by 2359 UTC 28-Feb otherwise we will declare = consensus and the will ask the editors to merge the PRs. #283 Use the same ratchet for Handshake and Application keys https://github.com/mlswg/mls-protocol/pull/283 #296 Flesh out the extensions story https://github.com/mlswg/mls-protocol/pull/296 #304 Use HKDF to derive key pairs https://github.com/mlswg/mls-protocol/pull/304 Cheers, spt From nobody Tue Feb 25 09:43:41 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11043A120D for ; Tue, 25 Feb 2020 09:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 KCkEYA2JzpDD for ; Tue, 25 Feb 2020 09:43:37 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95523A1215 for ; Tue, 25 Feb 2020 09:43:36 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id 145so13269qkl.2 for ; Tue, 25 Feb 2020 09:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=oIylCQgEBkraCvP1kc2spl3kOqB7wCmaCxeQ1lvW6vA=; b=ZoB3o2WUprvepPjVcmC66Q3Fi/PMMjuV5+n0/JU3Omtx2a2yLPsm4pvmHpmR6uExAM UVLHcrX3CIrhQhbA4Fqr9XBLh+PJ7BiFDvTbx2It663OCGdWRtlLne/BKIV/kKgFjYiu 1C2nx3woealE5hwVivkhAIx3gOnguj9IP6xU4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=oIylCQgEBkraCvP1kc2spl3kOqB7wCmaCxeQ1lvW6vA=; b=R+jaAWVpq1VZJkKJGOWnx2v0RG2en+8/tdTDPsBt6vzMvrR4ceHqeuBB/7bD5dXJ4x uVUT7vKqCQawa7hKrNM2mpNv6eP4HYaMF3sEuR7XVs//YiW7ol70z/VK1orTcQtdYJ+0 ECKwsbuNsU13vJRzncA0JjiFdmgPRc/QXoeSZKcbLr+mFV9meewd97dZdCRRGIrFzm0Y oGYKPSJMx02W7t4FAUN+xLypAfKgZGjMqsGQDVPzndGVVUzdgwlP4vzC5LLfflG5UI82 pcc6YKK7HFV/199rC6xNaObouf0WvIngamA48H2wLcydDd8uzGWhd38JCLMRN3zreDYR uLcg== X-Gm-Message-State: APjAAAUuGdT1pTgyN/T8vYPenxfDuc4DLpuSuV/dqB11Bv6IY6o2Uqd4 7V5rsitnkJRYMDW+8cQIq6w+jdqabBY= X-Google-Smtp-Source: APXvYqwFliNWjnelwEKHMrWRve3ksZ3AEL+ATIvJVcWhEH3zZSyqhrHMS1nUQTgbOtCcn1F7uQ3J+g== X-Received: by 2002:a05:620a:5:: with SMTP id j5mr18348650qki.197.1582652615160; Tue, 25 Feb 2020 09:43:35 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id h9sm7870095qtq.61.2020.02.25.09.43.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 09:43:34 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 25 Feb 2020 12:43:33 -0500 References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> To: Messaging Layer Security WG In-Reply-To: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> Message-Id: <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 25 Feb 2020 17:43:40 -0000 Note that the main point of the telecon tomorrow is to address the = cipher suite issue. Please take the time to review: - the related PRs: https://github.com/mlswg/mls-protocol/pull/279 https://github.com/mlswg/mls-protocol/pull/307 - the messages in this thread - the issues Britta outlined: = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing We would like to close this issue out tomorrow. Cheers, spt > On Feb 19, 2020, at 01:09, Konrad Kohbrok = wrote: >=20 > Hi Britta, >=20 > I think you sum it up very nicely. There is one (albeit somewhat = speculative) > argument why a single ciphersuite per group might actually be = beneficial in a > federation context. In the event that there is "global concensus" that = a > ciphersuite needs to be deprecated, my expectation would be that a = majority of > the federation nodes/application providers would move to ban those = ciphersuits, > excluding anyone who would use _exclusively_ that ciphersuite. That = would in > turn be a motivation for all other nodes/application providers to = catch up as > well. This also means that nodes can't be made (by whatever authority) = to use > weak ciphersuites exclusively and still expect to federate with other = nodes that > have more sensible policies. >=20 > That's mostly my guess of how the dynamics in such a federated = environment > _could_ work, though. Anyone here with some actual = experience/expertise they can > share of what the dynamics could be? >=20 > Overall, I think I'm in favor of one-ciphersuite-per-group. It just = seems a lot > simpler and even in the context of federation, I think that most > nodes/application providers would allow several ciphersuites to begin = with, > where not all of them are weak, meaning no one would really be = excluded too quickly. >=20 > Cheers, > Konrad >=20 >=20 > On 18.02.20 21:00, Hale, Britta (CIV) wrote: >> Under the topic of individual/single signature schemes there is the = final issue of federation. In a federated context, groups are no longer = under the control of a single application, meaning that we would lose = some control in forcing good ciphersuite choices. This could lead to two = issues: >>=20 >> 1) MLS would move closer to facing the TLS problem of having old = suites supported by edge cases, which in turn weaken the entire group's = security. There is always the argument that groups would simply refuse = joiners that do not support the current group cipher, but this is not = very practical from a usability view. E.g. if everyone using application = X refused group members who were using application Y, then the point of = federation would be largely defeated. So, either some form of = renegotiation is allowed (e.g. export psk) and downgrade becomes more = likely, or federation does not work reliably.=20 >>=20 >> 2) Healing would take longer. Since no one application has a master = view and control over ciphersuites, upgrading long-lived groups using = questionable ciphers could take a significant amount of time (all = applications would need to do so in order for the group to upgrade) or = alternatively result in kicking group members out of the group (again, = possible, but questionable for usability except in extreme cases). Under = an individual cipher choice, any one member can choose/upgrade their = scheme, allowing for faster adaptability and potential benefits to PCS.=20= >>=20 >> =46rom the above, it seems that a single group cipher makes = federation harder/slower/less secure, but I may not have a clear view on = how federation would work in this context. Does anyone know whether the = above are really concerns or not relevant due to other reasons?=20 >>=20 >> (Note that this is thinking in the long-term context. Obviously we do = not want to standardize any cipher choice that is sub-optimal; however = any number of things may happen with protocol versioning and cipher = breaks over the span of several years.) >>=20 >> Under all the considerations that I have seen so far, the pros and = cons on both sides place the individual signature cipher option in the = lead. However that lead is small, hence why I have not been arguing for = it. The issue of federation could be a deciding factor. If we want = federation in the future it is of course better not to build inhibiting = factors into MLS now that could undermine either usability or security = in such contexts. To make a case to proceed with the single group cipher = option, it would be great if someone could provide a convincing argument = as to why it would be the best option for usability and security in the = federated environment (or preclude a federated use-case altogether). >>=20 >> --- >>=20 >> Britta=20 >>=20 >>=20 >> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" = wrote: >>=20 >> Hi, >>=20 >> Concerning the use of a single group signature scheme or = individual signature schemes, it is probably worthwhile to expand on the = consideration points and clarify what security implications we are = accepting - in either case. I have listed out some issues in the = following Google doc: >>=20 >> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>=20 >> I am not making an argument for either case at this point, but = pushing this out for discussion and to help us achieve more clarity as = to the benefits and consequences of either choice. There are certainly = more issues to consider (e.g. ease of implementation, efficiency, etc. = in addition to security considerations) and other views - feel free to = add them or discuss on the mailing list.=20 >>=20 >> All the best, >>=20 >> Britta=20 >>=20 >>=20 >> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" = wrote: >>=20 >> Hi! >>=20 >> tl;dr: confirming MTI suite selections and rationale for = avoiding proliferation >>=20 >> During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. >>=20 >> There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There = are, at least, three things to consider: 1) if a potential group member = does not support the algorithm, then they will not become a member or = the group will need to downgrade; 2) when the group needs/wants to = update, it is a flag day; and, 3) the cipher suites will have a similar = combinatorial issues as the TLS cipher suites prior to TLS 1.3. The = agreement was =E2=80=9Crough=E2=80=9D because 1) likely has some = important implications. >>=20 >> The MLS cipher suites defined were as follows:=20 >> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >>=20 >> At the interim, the consensus was to make the non-NIST suites = the MTI. The rationale was that those implementation that need to be = NIST compliant will do so regardless of the choice made by the WG. >>=20 >> In looking at the actual cipher suites, it was noted that the = 256-bit schemes the SHA should be SHA-512. The rationale agreed was that = SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one = less operation. >>=20 >> To avoid the proliferation of cipher suites, guidance will be = provided to be conservative about allocating new code points. The = consensus at the interim was that the suites provided were minimal and = provided good coverage for the known use cases: >> - (X25519, AES-GCM, Ed25519) - Good for desktop >> - (P-256, AES-GCM, P-256) - Compliance >> - (X25519, ChachaPoly, Ed25519) - Good for mobile >>=20 >> The chairs need to confirm the interim=E2=80=99s consensus on = list, so please let the WG know by 2359 UTC 20 February whether you = disagree with these choices and why. >>=20 >> NOTE: The final text will obviously be reviewed, but is being = composed as part of the following PR: >> https://github.com/mlswg/mls-protocol/pull/279 >>=20 >> NOTE: We combined these cipher suite related consensus points, = but if we only come to consensus on some of these we can still = incorporate what we do agree on. >>=20 >> Cheers, >>=20 >> Nick and Sean >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >>=20 >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >>=20 >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Feb 25 10:24:33 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684243A125A for ; Tue, 25 Feb 2020 10:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 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, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-JnJwts2HQO for ; Tue, 25 Feb 2020 10:24:28 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 15B9C3A0FA5 for ; Tue, 25 Feb 2020 10:24:23 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id l16so354738qtq.1 for ; Tue, 25 Feb 2020 10:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q2SL+VXTIOGXK4P3L0m4NzIk4wFT+y3TZvbLcCxgGfY=; b=X5yVhfcL+tesym3pOtu5KepCn+EbfRoJJPhX51APzlVdSI+pZ1Q/xBSJiRyrKSzFOL 9cIYief/9bN/aDCCsxm0yRFxsrClfQ6BkLstLQkSwxtnAvPyY17D7DKlwdrPttN8JohK 9SkV7N3Gw5wG5lRrzTGgc9j+YSBU7FW4Ikbg66Nxdphf9c4RaU/LgjX4MF+wOyrjc/Rz xbTrN8tV76mmxr5dPdPCFBemCJmUOh2RjDvWyrhem1CbtQwXEABY2jqC5Ru7dwoSq3iq wyyL1g8C8lo4zkUs1I68tjt1fjPWvolo9qttxsYLUvMsOvqnw6OpQt5Y3XQRgREu8iV2 PTKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q2SL+VXTIOGXK4P3L0m4NzIk4wFT+y3TZvbLcCxgGfY=; b=LjdkcFlYKxdLhhLGf8NrkZSQ3OQ6S8YxVynStqwiX8lehXhEmrNLxjKkFdXwmaJxIS wEzYLHnui4VpaVN23bxcEXCMtMoIRi1xSZk+ycoAvosXf5NujuEpsudAv/jXZArfsqjS 7MqTyinUQj6sKlUCrHk3ImwM3XjXFXLYFADhb3zUpF6LCa06jD+8zVcCpYyy93EbgWoX s/6zYdM1ProkY7KfRcHALQfU6caQb22QfRWoxCsOdh9y4InqxNlsfcGxkbjX4haCrwrF skAUxaos7dYWvblDliXSWDQplDXcwB5rhC6WNgo25+3aw+BWYcwE5f7uB1Gtp4g34Kmy v5Ow== X-Gm-Message-State: APjAAAVwvjyQ8oNJB2q+ajbw8LG8SFmRyB4t0GvrKMbkLC9egbXjs5jL RcIeodu+3IFJpTO5y2XkajYY3Zdli2/1QLAmCt7dv2U/fmw= X-Google-Smtp-Source: APXvYqyYFjplFtnU5EH9QUpuvIDahvCr9K2XFuv2dbyOt8BIWDspqeOgPEKU3zUxGYmQYDHA8Hc9MSNE+ui7FIUuy00= X-Received: by 2002:ac8:1e90:: with SMTP id c16mr54632746qtm.265.1582655062750; Tue, 25 Feb 2020 10:24:22 -0800 (PST) MIME-Version: 1.0 References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> In-Reply-To: <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> From: Richard Barnes Date: Tue, 25 Feb 2020 13:24:07 -0500 Message-ID: To: Sean Turner Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d14c13059f6a9822" Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 25 Feb 2020 18:24:31 -0000 --000000000000d14c13059f6a9822 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I will not be able to make the call tomorrow, so to summarize my opinion on this: * I am OK with merging the current PR * I have a slight preference for *not* including the sig alg in the ciphersuite * The simplicity case for including it seems reasonable, but not dispositive * In any case, I don't care strongly one way or another; I care more about progress * This is an easy change to revert if we change our minds later * Credentials are going to indicate the signature algorithm anyway * So the only difference in spec is whether endpoints check Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: > Note that the main point of the telecon tomorrow is to address the cipher > suite issue. Please take the time to review: > - the related PRs: > https://github.com/mlswg/mls-protocol/pull/279 > https://github.com/mlswg/mls-protocol/pull/307 > - the messages in this thread > - the issues Britta outlined: > > https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilI= dFKw14/edit?usp=3Dsharing > > We would like to close this issue out tomorrow. > > Cheers, > > spt > > > On Feb 19, 2020, at 01:09, Konrad Kohbrok > wrote: > > > > Hi Britta, > > > > I think you sum it up very nicely. There is one (albeit somewhat > speculative) > > argument why a single ciphersuite per group might actually be beneficia= l > in a > > federation context. In the event that there is "global concensus" that = a > > ciphersuite needs to be deprecated, my expectation would be that a > majority of > > the federation nodes/application providers would move to ban those > ciphersuits, > > excluding anyone who would use _exclusively_ that ciphersuite. That > would in > > turn be a motivation for all other nodes/application providers to catch > up as > > well. This also means that nodes can't be made (by whatever authority) > to use > > weak ciphersuites exclusively and still expect to federate with other > nodes that > > have more sensible policies. > > > > That's mostly my guess of how the dynamics in such a federated > environment > > _could_ work, though. Anyone here with some actual experience/expertise > they can > > share of what the dynamics could be? > > > > Overall, I think I'm in favor of one-ciphersuite-per-group. It just > seems a lot > > simpler and even in the context of federation, I think that most > > nodes/application providers would allow several ciphersuites to begin > with, > > where not all of them are weak, meaning no one would really be excluded > too quickly. > > > > Cheers, > > Konrad > > > > > > On 18.02.20 21:00, Hale, Britta (CIV) wrote: > >> Under the topic of individual/single signature schemes there is the > final issue of federation. In a federated context, groups are no longer > under the control of a single application, meaning that we would lose som= e > control in forcing good ciphersuite choices. This could lead to two issue= s: > >> > >> 1) MLS would move closer to facing the TLS problem of having old suite= s > supported by edge cases, which in turn weaken the entire group's security= . > There is always the argument that groups would simply refuse joiners that > do not support the current group cipher, but this is not very practical > from a usability view. E.g. if everyone using application X refused group > members who were using application Y, then the point of federation would = be > largely defeated. So, either some form of renegotiation is allowed (e.g. > export psk) and downgrade becomes more likely, or federation does not wor= k > reliably. > >> > >> 2) Healing would take longer. Since no one application has a master > view and control over ciphersuites, upgrading long-lived groups using > questionable ciphers could take a significant amount of time (all > applications would need to do so in order for the group to upgrade) or > alternatively result in kicking group members out of the group (again, > possible, but questionable for usability except in extreme cases). Under = an > individual cipher choice, any one member can choose/upgrade their scheme, > allowing for faster adaptability and potential benefits to PCS. > >> > >> From the above, it seems that a single group cipher makes federation > harder/slower/less secure, but I may not have a clear view on how > federation would work in this context. Does anyone know whether the above > are really concerns or not relevant due to other reasons? > >> > >> (Note that this is thinking in the long-term context. Obviously we do > not want to standardize any cipher choice that is sub-optimal; however an= y > number of things may happen with protocol versioning and cipher breaks ov= er > the span of several years.) > >> > >> Under all the considerations that I have seen so far, the pros and con= s > on both sides place the individual signature cipher option in the lead. > However that lead is small, hence why I have not been arguing for it. The > issue of federation could be a deciding factor. If we want federation in > the future it is of course better not to build inhibiting factors into ML= S > now that could undermine either usability or security in such contexts. T= o > make a case to proceed with the single group cipher option, it would be > great if someone could provide a convincing argument as to why it would b= e > the best option for usability and security in the federated environment (= or > preclude a federated use-case altogether). > >> > >> --- > >> > >> Britta > >> > >> > >> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" < > mls-bounces@ietf.org on behalf of britta.hale@nps.edu> wrote: > >> > >> Hi, > >> > >> Concerning the use of a single group signature scheme or individual > signature schemes, it is probably worthwhile to expand on the considerati= on > points and clarify what security implications we are accepting - in eithe= r > case. I have listed out some issues in the following Google doc: > >> > >> > https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilI= dFKw14/edit?usp=3Dsharing > >> > >> I am not making an argument for either case at this point, but > pushing this out for discussion and to help us achieve more clarity as to > the benefits and consequences of either choice. There are certainly more > issues to consider (e.g. ease of implementation, efficiency, etc. in > addition to security considerations) and other views - feel free to add > them or discuss on the mailing list. > >> > >> All the best, > >> > >> Britta > >> > >> > >> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" < > mls-bounces@ietf.org on behalf of sean@sn3rd.com> wrote: > >> > >> Hi! > >> > >> tl;dr: confirming MTI suite selections and rationale for > avoiding proliferation > >> > >> During the F2F Interim in January, the WG discussed cipher > suites-related issues. Namely, whether a per-group signature scheme shoul= d > be driven by the chosen cipher suite, what were the MTI (Mandatory To > Implement) cipher suites, and what the actual algorithm should be. > >> > >> There was rough agreement that there should be one signature > scheme per group and that should be driven by the cipher suite. There are= , > at least, three things to consider: 1) if a potential group member does n= ot > support the algorithm, then they will not become a member or the group wi= ll > need to downgrade; 2) when the group needs/wants to update, it is a flag > day; and, 3) the cipher suites will have a similar combinatorial issues a= s > the TLS cipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough= =E2=80=9D because > 1) likely has some important implications. > >> > >> The MLS cipher suites defined were as follows: > >> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > >> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > >> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > >> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > >> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > >> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > >> > >> At the interim, the consensus was to make the non-NIST suites > the MTI. The rationale was that those implementation that need to be NIS= T > compliant will do so regardless of the choice made by the WG. > >> > >> In looking at the actual cipher suites, it was noted that the > 256-bit schemes the SHA should be SHA-512. The rationale agreed was that > SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less > operation. > >> > >> To avoid the proliferation of cipher suites, guidance will be > provided to be conservative about allocating new code points. The consens= us > at the interim was that the suites provided were minimal and provided goo= d > coverage for the known use cases: > >> - (X25519, AES-GCM, Ed25519) - Good for desktop > >> - (P-256, AES-GCM, P-256) - Compliance > >> - (X25519, ChachaPoly, Ed25519) - Good for mobile > >> > >> The chairs need to confirm the interim=E2=80=99s consensus on l= ist, so > please let the WG know by 2359 UTC 20 February whether you disagree with > these choices and why. > >> > >> NOTE: The final text will obviously be reviewed, but is being > composed as part of the following PR: > >> https://github.com/mlswg/mls-protocol/pull/279 > >> > >> NOTE: We combined these cipher suite related consensus points, > but if we only come to consensus on some of these we can still incorporat= e > what we do agree on. > >> > >> Cheers, > >> > >> Nick and Sean > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >> > >> > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >> > >> > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >> > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d14c13059f6a9822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I will not be able to make the call tomorrow, so to s= ummarize my opinion on this:

* I am OK with mergin= g the current PR
=C2=A0 * I have a slight preference for *not* in= cluding the sig alg in the ciphersuite
=C2=A0 * The simplicit= y case for including it seems reasonable, but not dispositive
=C2=A0 * In any case, I don't care strongly one way or another; I care= more about progress
* This is an easy change to revert if we= change our minds later
=C2=A0 * Credentials are going to indicat= e the signature algorithm anyway
=C2=A0 * So the only difference = in spec is whether endpoints check Credential.SigAlgorithm =3D=3D CipherSui= te.SigAlgorithm


On Tue, Feb 25, 2020 at 12:43 PM Sean T= urner <sean@sn3rd.com> wrote:
Note that the mai= n point of the telecon tomorrow is to address the cipher suite issue.=C2=A0= Please take the time to review:
- the related PRs:
=C2=A0https://github.com/mlswg/mls-protocol/pull/279
=C2=A0https://github.com/mlswg/mls-protocol/pull/307
- the messages in this thread
- the issues Britta outlined:
ht= tps://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw= 14/edit?usp=3Dsharing

We would like to close this issue out tomorrow.

Cheers,

spt

> On Feb 19, 2020, at 01:09, Konrad Kohbrok <konrad.kohbrok@datashrine.de&= gt; wrote:
>
> Hi Britta,
>
> I think you sum it up very nicely. There is one (albeit somewhat specu= lative)
> argument why a single ciphersuite per group might actually be benefici= al in a
> federation context. In the event that there is "global concensus&= quot; that a
> ciphersuite needs to be deprecated, my expectation would be that a maj= ority of
> the federation nodes/application providers would move to ban those cip= hersuits,
> excluding anyone who would use _exclusively_ that ciphersuite. That wo= uld in
> turn be a motivation for all other nodes/application providers to catc= h up as
> well. This also means that nodes can't be made (by whatever author= ity) to use
> weak ciphersuites exclusively and still expect to federate with other = nodes that
> have more sensible policies.
>
> That's mostly my guess of how the dynamics in such a federated env= ironment
> _could_ work, though. Anyone here with some actual experience/expertis= e they can
> share of what the dynamics could be?
>
> Overall, I think I'm in favor of one-ciphersuite-per-group. It jus= t seems a lot
> simpler and even in the context of federation, I think that most
> nodes/application providers would allow several ciphersuites to begin = with,
> where not all of them are weak, meaning no one would really be exclude= d too quickly.
>
> Cheers,
> Konrad
>
>
> On 18.02.20 21:00, Hale, Britta (CIV) wrote:
>> Under the topic of individual/single signature schemes there is th= e final issue of federation. In a federated context, groups are no longer u= nder the control of a single application, meaning that we would lose some c= ontrol in forcing good ciphersuite choices. This could lead to two issues:<= br> >>
>> 1) MLS would move closer to facing the TLS problem of having old s= uites supported by edge cases, which in turn weaken the entire group's = security. There is always the argument that groups would simply refuse join= ers that do not support the current group cipher, but this is not very prac= tical from a usability view. E.g. if everyone using application X refused g= roup members who were using application Y, then the point of federation wou= ld be largely defeated. So, either some form of renegotiation is allowed (e= .g. export psk) and downgrade becomes more likely, or federation does not w= ork reliably.
>>
>> 2) Healing would take longer. Since no one application has a maste= r view and control over ciphersuites, upgrading long-lived groups using que= stionable ciphers could take a significant amount of time (all applications= would need to do so in order for the group to upgrade) or alternatively re= sult in kicking group members out of the group (again, possible, but questi= onable for usability except in extreme cases). Under an individual cipher c= hoice, any one member can choose/upgrade their scheme, allowing for faster = adaptability and potential benefits to PCS.
>>
>> From the above, it seems that a single group cipher makes federati= on harder/slower/less secure, but I may not have a clear view on how federa= tion would work in this context. Does anyone know whether the above are rea= lly concerns or not relevant due to other reasons?
>>
>> (Note that this is thinking in the long-term context. Obviously we= do not want to standardize any cipher choice that is sub-optimal; however = any number of things may happen with protocol versioning and cipher breaks = over the span of several years.)
>>
>> Under all the considerations that I have seen so far, the pros and= cons on both sides place the individual signature cipher option in the lea= d. However that lead is small, hence why I have not been arguing for it. Th= e issue of federation could be a deciding factor. If we want federation in = the future it is of course better not to build inhibiting factors into MLS = now that could undermine either usability or security in such contexts. To = make a case to proceed with the single group cipher option, it would be gre= at if someone could provide a convincing argument as to why it would be the= best option for usability and security in the federated environment (or pr= eclude a federated use-case altogether).
>>
>> ---
>>
>> Britta
>>
>>
>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta = (CIV)" <m= ls-bounces@ietf.org on behalf of britta.hale@nps.edu> wrote:
>>
>>=C2=A0 =C2=A0 Hi,
>>
>>=C2=A0 =C2=A0 Concerning the use of a single group signature scheme= or individual signature schemes, it is probably worthwhile to expand on th= e consideration points and clarify what security implications we are accept= ing - in either case. I have listed out some issues in the following Google= doc:
>>
>>=C2=A0 =C2=A0 https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t= 4kVlmgA94_pMtdSilIdFKw14/edit?usp=3Dsharing
>>
>>=C2=A0 =C2=A0 I am not making an argument for either case at this p= oint, but pushing this out for discussion and to help us achieve more clari= ty as to the benefits and consequences of either choice. There are certainl= y more issues to consider (e.g. ease of implementation, efficiency, etc. in= addition to security considerations) and other views - feel free to add th= em or discuss on the mailing list.
>>
>>=C2=A0 =C2=A0 All the best,
>>
>>=C2=A0 =C2=A0 Britta
>>
>>
>>=C2=A0 =C2=A0 On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turne= r" <mls-b= ounces@ietf.org on behalf of sean@sn3rd.com> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi!
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tl;dr: confirming MTI suite selections = and rationale for avoiding proliferation
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 During the F2F Interim in January, the = WG discussed cipher suites-related issues. Namely, whether a per-group sign= ature scheme should be driven by the chosen cipher suite, what were the MTI= (Mandatory To Implement) cipher suites, and what the actual algorithm shou= ld be.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 There was rough agreement that there sh= ould be one signature scheme per group and that should be driven by the cip= her suite. There are, at least, three things to consider: 1) if a potential= group member does not support the algorithm, then they will not become a m= ember or the group will need to downgrade; 2) when the group needs/wants to= update, it is a flag day; and, 3) the cipher suites will have a similar co= mbinatorial issues as the TLS cipher suites prior to TLS 1.3. The agreement= was =E2=80=9Crough=E2=80=9D because 1) likely has some important implicati= ons.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The MLS cipher suites defined were as f= ollows:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - MLS10_128_HPKEX25519_AES128GCM_SHA256= _Ed25519
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - MLS10_128_HPKEP256_AES128GCM_SHA256_P= 256
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - MLS10_128_HPKEX25519_CHACHA20POLY1305= _SHA256_Ed25519
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - MLS10_256_HPKEX448_AES256GCM_SHA384_E= d448
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - MLS10_256_HPKEP521_AES256GCM_SHA384_P= 521
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - MLS10_256_HPKEX448_CHACHA20POLY1305_S= HA384_Ed448
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 At the interim, the consensus was to ma= ke the non-NIST suites the MTI.=C2=A0 The rationale was that those implemen= tation that need to be NIST compliant will do so regardless of the choice m= ade by the WG.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 In looking at the actual cipher suites,= it was noted that the 256-bit schemes the SHA should be SHA-512. The ratio= nale agreed was that SHA-384 is SHA-512 cut in half, so just do SHA-512 bec= ause it is one less operation.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 To avoid the proliferation of cipher su= ites, guidance will be provided to be conservative about allocating new cod= e points. The consensus at the interim was that the suites provided were mi= nimal and provided good coverage for the known use cases:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - (X25519, AES-GCM, Ed25519) - Good for= desktop
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - (P-256, AES-GCM, P-256) - Compliance<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - (X25519, ChachaPoly, Ed25519) - Good = for mobile
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The chairs need to confirm the interim= =E2=80=99s consensus on list, so please let the WG know by 2359 UTC 20 Febr= uary whether you disagree with these choices and why.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 NOTE: The final text will obviously be = reviewed, but is being composed as part of the following PR:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com= /mlswg/mls-protocol/pull/279
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 NOTE: We combined these cipher suite re= lated consensus points, but if we only come to consensus on some of these w= e can still incorporate what we do agree on.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nick and Sean
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________= ________
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 MLS mailing list
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 MLS@ietf.org
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/mls
>>
>>
>>=C2=A0 =C2=A0 _______________________________________________
>>=C2=A0 =C2=A0 MLS mailing list
>>=C2=A0 =C2=A0 MLS= @ietf.org
>>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo= /mls
>>
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org=
>> https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d14c13059f6a9822-- From nobody Wed Feb 26 08:27:53 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DE63A0ACD for ; Wed, 26 Feb 2020 08:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 pj6Pv84UPzov for ; Wed, 26 Feb 2020 08:27:47 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 72FC43A0A01 for ; Wed, 26 Feb 2020 08:27:47 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id u124so3148457qkh.13 for ; Wed, 26 Feb 2020 08:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Ge/QQkWLdmFhGLdiqd637/fXKnvg2gBbvGhx4k4ucMM=; b=MSTeRwLLMNvhog2IwHGClgmRBtCmDPhm2XwVRyHxeFZA2zAwyH6OWQueEBaWq54xoR 7QSdZPOy4zuo7KB205Pb815ewBaAWDdiRlcGB+B8PMtf21t9d4jnMfGpKJV3OQ2nlDps pSmDcxN7UGCrIzgJ89FQo0/lEVpqrHLp7QxWQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Ge/QQkWLdmFhGLdiqd637/fXKnvg2gBbvGhx4k4ucMM=; b=X/Jb5X468b1innBS7Vp4IRHeE2/AIEkSG+KK9J0aFmPzgs6TNFh3juUOOowcJRxw5a AXMQLgZEcUp7StLcleFw3xTrDV29RKvAS/GiDYOXbpX6emXrLSKM174TNzlp0qNYdjO9 5Ai2lEy5kDTN8LU2eqOxRlYB0FNanvOwRm4ltKF8ClnVmbHq2ThkwE5CS8+6bzEAshBX LZ9BpFEGvSl+mL41CUUJ6QQdzZzhqgi7tpw4RIe9T9Ve99e8iXIRSSzgJNQPEq/O8ojP RHx9ZMXj3+GPIasGCGRcTt7wlBOw4t0LH7jVhwZko8hGmd5A5UX8dfaxsDrxVZFo4sjK 2CFw== X-Gm-Message-State: APjAAAVfV9vVIdl6kGJv9iSOXK3pmaOv4ngs3WT/JTwT499SU6V5JM/9 irILTpl/tOmc2x9qiDN4OOtSnKE9RmU= X-Google-Smtp-Source: APXvYqx8i18HBDjM3KTH6J8G+DCz2Pp5+jYGz2SwDgIuZy+ezNjjEQvamL5pCjQyoUkbY6aVdr6Hug== X-Received: by 2002:a05:620a:39a:: with SMTP id q26mr6511149qkm.475.1582734466246; Wed, 26 Feb 2020 08:27:46 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id p19sm1339397qte.81.2020.02.26.08.27.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 08:27:45 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Feb 2020 11:27:45 -0500 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> <18A288AF-9CFD-4EB4-96EF-C77463CF2555@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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: Wed, 26 Feb 2020 16:27:52 -0000 Thanks to Brendan, Britta, and Ray for calling in today. You=E2=80=99ll see some emails about the two topics we discussed = shortly. spt > On Feb 25, 2020, at 12:20, Sean Turner wrote: >=20 > Please note that there is another meeting tomorrow. Same time, place, = and details: >=20 > Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= > Meeting number: 647 391 156 > Password: ve2i8niw >=20 > spt >=20 >> On Feb 18, 2020, at 19:56, Sean Turner wrote: >>=20 >> Apologies for the late reminder, but there is yet another virtual = interim scheduled for tomorrow. The call information is the same as last = week: >>=20 >> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >> Meeting number: 647 391 156 >> Password: ve2i8niw >>=20 >> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>=20 >> spt >>=20 >>> On Feb 11, 2020, at 16:53, Sean Turner wrote: >>>=20 >>> As a reminder there is another virtual interim. This is the call = information: >>>=20 >>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>> Meeting number: 647 391 156 >>> Password: ve2i8niw >>>=20 >>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>=20 >>> spt >>>=20 >>>> On Feb 4, 2020, at 05:21, Sean Turner wrote: >>>>=20 >>>> As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >>>>=20 >>>> spt >>>>=20 >>>>> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>>>>=20 >>>>> As a reminder, the recurring virtual interim is tomorrow. Here's = the meeting information: >>>>>=20 >>>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>>> Meeting number: 647 391 156 >>>>> Password: ve2i8niw >>>>>=20 >>>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>>=20 >>>>> Nick & Sean >>>>>=20 >>>>> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >>>>> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>>>>=20 >>>>> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>>>>=20 >>>>> Here's the proposed schedule (subject to AD approval): >>>>> Time: 1400-1500 GMT on Wednesdays >>>>> Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >>>>>=20 >>>>> Links to the conference calls are forthcoming. >>>>>=20 >>>>> Nick & Sean >>>>>=20 >>>>> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes wrote: >>>>> Also: Note that despite this poll listing specific dates, the = intent is to set up a weekly recurring meeting. In fact, these dates = will definitely not be the dates when the calls happen, because IETF = requires one week notice. >>>>>=20 >>>>> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes wrote: >>>>> I would like to have some weekly calls to make faster progress on = our outstanding PRs. Here's a Doodle to find a good time: >>>>>=20 >>>>> https://doodle.com/poll/bg2q65phrvfip5zb >>>>>=20 >>>>> I believe these will need to be official Virtual Interims per IETF = process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>>>>=20 >>>>> --Richard >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>=20 >>=20 >=20 From nobody Wed Feb 26 08:28:28 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282C03A0AD1 for ; Wed, 26 Feb 2020 08:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 fqJZsNREfKNB for ; Wed, 26 Feb 2020 08:28:23 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D6C3A0A01 for ; Wed, 26 Feb 2020 08:28:23 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id u124so3150531qkh.13 for ; Wed, 26 Feb 2020 08:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=T8r3p7uZr+TwEu6D+Csul5+PkfQm38WWiOAgl2I8QcU=; b=QvMsuJG+kSXQyLkmh2m788KNe7jOzXaXzwUb7ftojWJeYuqCeJ17Fem8I2h87OiqnA 1N4RZeRvFwYmuFFZOhVVcYSRXFU7kLKjf2sxojSdzNSPEbDCecniJ4WrpUz0VRR9Qnyn 3Bc5pSIdFPc10WhG6pBYywm0xdDbqnmq4Rq6g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=T8r3p7uZr+TwEu6D+Csul5+PkfQm38WWiOAgl2I8QcU=; b=OBy/9qmsQtQnd6iuZnUKKJWlKgCPRyqqJrK3A9AGGYlJY5pP+1WshLGDW+HMQXlYuw GJDy0tDLgD+V5GE8CaLJSE4DazDnE9CG0pjSOFHRDNbKir4QXQ/LgcpoweMrQhmKSA3m E3lv31Bv5ihaV7SeqLkaQ9PWlzTVEsENMvbc9WfDoZ8XCY8cR6M+0PqgWh7MTLVlEGsy sI91lXrmTIdpTvIUOSaTI6+U/+dGhRWeVvlqJ9lEL7pMlFvkVUtBja75OuL9VZ97C/bJ THTzWdP/vqssfljPr6jXHWWTCpBaB3Wutpr9jZ1+84FbPRKOnWYObcLb6LAyitaAYZUX wotw== X-Gm-Message-State: APjAAAXEpMUU7Vmz+7erKEuwaprxXOB3+pICOyHrMWAsor0SZKWSYEB2 3UICaBH69rdFAo/Uy3FNOZJWzcg0zfA= X-Google-Smtp-Source: APXvYqwXsO6D7MKHus1wd1dvrrJhpVRVWdjyfyjLNkNro8MrbZpybJiRQ4Z+ESsDuOx0LEjFCRW/FA== X-Received: by 2002:a37:4c7:: with SMTP id 190mr6497337qke.367.1582734501882; Wed, 26 Feb 2020 08:28:21 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id p19sm1339397qte.81.2020.02.26.08.28.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 08:28:21 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Feb 2020 11:28:20 -0500 References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: Message-Id: <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 16:28:28 -0000 There seems to be rough consensus (stressing the rough) to go with one = scheme per group. By rough consensus, I mean there seems to be a = willingness by the group to live with this decision and nobody is super = bent out of shape about it. Technically, that=E2=80=99s all we need to = move forward, but there are some concerns concerns that since it=E2=80=99s= such a small group and there are so few strong voices for the choice = that we should give it just a bit more time. So, I am extending this = call until 2359 UTC 2 March (i.e., Monday night). Also, there are really three ciphersuite-related decisions being made, = as noted in the email below. spt > On Feb 25, 2020, at 13:24, Richard Barnes wrote: >=20 > I will not be able to make the call tomorrow, so to summarize my = opinion on this: >=20 > * I am OK with merging the current PR > * I have a slight preference for *not* including the sig alg in the = ciphersuite > * The simplicity case for including it seems reasonable, but not = dispositive > * In any case, I don't care strongly one way or another; I care more = about progress > * This is an easy change to revert if we change our minds later > * Credentials are going to indicate the signature algorithm anyway > * So the only difference in spec is whether endpoints check = Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm >=20 >=20 > On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: > Note that the main point of the telecon tomorrow is to address the = cipher suite issue. Please take the time to review: > - the related PRs: > https://github.com/mlswg/mls-protocol/pull/279 > https://github.com/mlswg/mls-protocol/pull/307 > - the messages in this thread > - the issues Britta outlined: > = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >=20 > We would like to close this issue out tomorrow. >=20 > Cheers, >=20 > spt >=20 > > On Feb 19, 2020, at 01:09, Konrad Kohbrok = wrote: > >=20 > > Hi Britta, > >=20 > > I think you sum it up very nicely. There is one (albeit somewhat = speculative) > > argument why a single ciphersuite per group might actually be = beneficial in a > > federation context. In the event that there is "global concensus" = that a > > ciphersuite needs to be deprecated, my expectation would be that a = majority of > > the federation nodes/application providers would move to ban those = ciphersuits, > > excluding anyone who would use _exclusively_ that ciphersuite. That = would in > > turn be a motivation for all other nodes/application providers to = catch up as > > well. This also means that nodes can't be made (by whatever = authority) to use > > weak ciphersuites exclusively and still expect to federate with = other nodes that > > have more sensible policies. > >=20 > > That's mostly my guess of how the dynamics in such a federated = environment > > _could_ work, though. Anyone here with some actual = experience/expertise they can > > share of what the dynamics could be? > >=20 > > Overall, I think I'm in favor of one-ciphersuite-per-group. It just = seems a lot > > simpler and even in the context of federation, I think that most > > nodes/application providers would allow several ciphersuites to = begin with, > > where not all of them are weak, meaning no one would really be = excluded too quickly. > >=20 > > Cheers, > > Konrad > >=20 > >=20 > > On 18.02.20 21:00, Hale, Britta (CIV) wrote: > >> Under the topic of individual/single signature schemes there is the = final issue of federation. In a federated context, groups are no longer = under the control of a single application, meaning that we would lose = some control in forcing good ciphersuite choices. This could lead to two = issues: > >>=20 > >> 1) MLS would move closer to facing the TLS problem of having old = suites supported by edge cases, which in turn weaken the entire group's = security. There is always the argument that groups would simply refuse = joiners that do not support the current group cipher, but this is not = very practical from a usability view. E.g. if everyone using application = X refused group members who were using application Y, then the point of = federation would be largely defeated. So, either some form of = renegotiation is allowed (e.g. export psk) and downgrade becomes more = likely, or federation does not work reliably.=20 > >>=20 > >> 2) Healing would take longer. Since no one application has a master = view and control over ciphersuites, upgrading long-lived groups using = questionable ciphers could take a significant amount of time (all = applications would need to do so in order for the group to upgrade) or = alternatively result in kicking group members out of the group (again, = possible, but questionable for usability except in extreme cases). Under = an individual cipher choice, any one member can choose/upgrade their = scheme, allowing for faster adaptability and potential benefits to PCS.=20= > >>=20 > >> =46rom the above, it seems that a single group cipher makes = federation harder/slower/less secure, but I may not have a clear view on = how federation would work in this context. Does anyone know whether the = above are really concerns or not relevant due to other reasons?=20 > >>=20 > >> (Note that this is thinking in the long-term context. Obviously we = do not want to standardize any cipher choice that is sub-optimal; = however any number of things may happen with protocol versioning and = cipher breaks over the span of several years.) > >>=20 > >> Under all the considerations that I have seen so far, the pros and = cons on both sides place the individual signature cipher option in the = lead. However that lead is small, hence why I have not been arguing for = it. The issue of federation could be a deciding factor. If we want = federation in the future it is of course better not to build inhibiting = factors into MLS now that could undermine either usability or security = in such contexts. To make a case to proceed with the single group cipher = option, it would be great if someone could provide a convincing argument = as to why it would be the best option for usability and security in the = federated environment (or preclude a federated use-case altogether). > >>=20 > >> --- > >>=20 > >> Britta=20 > >>=20 > >>=20 > >> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" = wrote: > >>=20 > >> Hi, > >>=20 > >> Concerning the use of a single group signature scheme or = individual signature schemes, it is probably worthwhile to expand on the = consideration points and clarify what security implications we are = accepting - in either case. I have listed out some issues in the = following Google doc: > >>=20 > >> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing > >>=20 > >> I am not making an argument for either case at this point, but = pushing this out for discussion and to help us achieve more clarity as = to the benefits and consequences of either choice. There are certainly = more issues to consider (e.g. ease of implementation, efficiency, etc. = in addition to security considerations) and other views - feel free to = add them or discuss on the mailing list.=20 > >>=20 > >> All the best, > >>=20 > >> Britta=20 > >>=20 > >>=20 > >> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" = wrote: > >>=20 > >> Hi! > >>=20 > >> tl;dr: confirming MTI suite selections and rationale for = avoiding proliferation > >>=20 > >> During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. > >>=20 > >> There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There = are, at least, three things to consider: 1) if a potential group member = does not support the algorithm, then they will not become a member or = the group will need to downgrade; 2) when the group needs/wants to = update, it is a flag day; and, 3) the cipher suites will have a similar = combinatorial issues as the TLS cipher suites prior to TLS 1.3. The = agreement was =E2=80=9Crough=E2=80=9D because 1) likely has some = important implications. > >>=20 > >> The MLS cipher suites defined were as follows:=20 > >> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > >> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > >> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > >> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > >> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > >> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > >>=20 > >> At the interim, the consensus was to make the non-NIST = suites the MTI. The rationale was that those implementation that need = to be NIST compliant will do so regardless of the choice made by the WG. > >>=20 > >> In looking at the actual cipher suites, it was noted that = the 256-bit schemes the SHA should be SHA-512. The rationale agreed was = that SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is = one less operation. > >>=20 > >> To avoid the proliferation of cipher suites, guidance will = be provided to be conservative about allocating new code points. The = consensus at the interim was that the suites provided were minimal and = provided good coverage for the known use cases: > >> - (X25519, AES-GCM, Ed25519) - Good for desktop > >> - (P-256, AES-GCM, P-256) - Compliance > >> - (X25519, ChachaPoly, Ed25519) - Good for mobile > >>=20 > >> The chairs need to confirm the interim=E2=80=99s consensus = on list, so please let the WG know by 2359 UTC 20 February whether you = disagree with these choices and why. > >>=20 > >> NOTE: The final text will obviously be reviewed, but is = being composed as part of the following PR: > >> https://github.com/mlswg/mls-protocol/pull/279 > >>=20 > >> NOTE: We combined these cipher suite related consensus = points, but if we only come to consensus on some of these we can still = incorporate what we do agree on. > >>=20 > >> Cheers, > >>=20 > >> Nick and Sean > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >>=20 > >>=20 > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >>=20 > >>=20 > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >>=20 > >=20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 26 08:28:40 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE313A0ADB for ; Wed, 26 Feb 2020 08:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 8mfhKxZdXh32 for ; Wed, 26 Feb 2020 08:28:30 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 09DEB3A0B00 for ; Wed, 26 Feb 2020 08:28:30 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id y2so12722qvu.13 for ; Wed, 26 Feb 2020 08:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=UGo9yoxif0pUZA9T+bm/nRB1TtN4ZwSRIxXq2lfrWyg=; b=W2jKUfIeIZPTiO07bs2SnoAh014fiNY5KSCU2AYp825r1g+uCXcGhXL1l4gHnmAjqf heBmnfRLgQlBEBLLRPv6fouXb9Zh6qsVHidtsTFncK6zmVu0Mq9ISDmTju6voAVPC2B6 3/yMoTsDtl01qYzSdmva1m2Nm3Adg7zFOAYVc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=UGo9yoxif0pUZA9T+bm/nRB1TtN4ZwSRIxXq2lfrWyg=; b=E94JnR8t6iSzoG1P7PmRcyUdANtFXInJLlwwld9JmPvVDJi1MdlFf+wplSRYmOdoZo jNS3VDouP9J9CMwa2aZPnKCzmK07BIdABeR+OxtMdfbJ0t6fXENi2w34jTkcMs3iQBbN pYZjgyaBEl2u0aMgLdovgZiRYOERjRjOJ/QyrBwmL46LkNsGtA7FRXsEX+JspDbSqMnR MV453UHhRIjuWXWOe4vbPgVrzv7pDqKEhx6Noxcfmfltt4kiYnQMSsCMYPTk3tfZ4ci0 jIzwhEYXLMCucYnjSCANJVZQRb8nhH41/6/4Ndxwzke6m2YSp+bIPINchWR9XqHcviGZ 4cmA== X-Gm-Message-State: APjAAAX+981vVx9LUAYIBdvMK9L15dezjNW5e8I/24htaaNDrCJ1mNf6 b4q1G+s3lCV1Gh3rHfIXWS/s3Y15fvQ= X-Google-Smtp-Source: APXvYqxeN+bozdFqCqJcBjHgklLHGmQTH35jtrb1vIBNEkRaiKx7YsSvmHRtXLIJQX87vrOdPXmU5A== X-Received: by 2002:ad4:57c7:: with SMTP id y7mr5347625qvx.174.1582734508830; Wed, 26 Feb 2020 08:28:28 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id p19sm1339397qte.81.2020.02.26.08.28.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 08:28:28 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Feb 2020 11:28:27 -0500 References: <101134CD-4B65-4172-9F82-C9466AE0B021@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: <101134CD-4B65-4172-9F82-C9466AE0B021@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] confirming merge for 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: Wed, 26 Feb 2020 16:28:39 -0000 Hi! Brendan noted on the call that he thought that we needed some more = discussion on #296. I see that he=E2=80=99s submitted a comment on the = PR. If we cannot come to closure on this on list, then we can discuss it = next week. spt > On Feb 25, 2020, at 12:29, Sean Turner wrote: >=20 > All, >=20 > The following PRs were 1st discussed at the 5-Feb virtual interim. The = WG discussed them again on the 1-Feb call and the editors believe these = are ready to merge. If have any objections to merging these please = provide your input by 2359 UTC 28-Feb otherwise we will declare = consensus and the will ask the editors to merge the PRs. >=20 > #283 Use the same ratchet for Handshake and Application keys > https://github.com/mlswg/mls-protocol/pull/283 >=20 > #296 Flesh out the extensions story > https://github.com/mlswg/mls-protocol/pull/296 >=20 > #304 Use HKDF to derive key pairs > https://github.com/mlswg/mls-protocol/pull/304 >=20 > Cheers, >=20 > spt >=20 From nobody Wed Feb 26 08:40:29 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237163A0B4D for ; Wed, 26 Feb 2020 08:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u79RdMwEw7OR for ; Wed, 26 Feb 2020 08:40:24 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 BE1563A0B48 for ; Wed, 26 Feb 2020 08:40:24 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id i6so57914pfc.1 for ; Wed, 26 Feb 2020 08:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AJRISEzRJskVsCmRP7dlMyhgRzV0ky0jKeNpA/Fhpxs=; b=v9RWxoInE5nghteSflmnJCV3FNLg5m43tjVw2V/nPcTeQ+s0jaeBLOqvoyrSXdRf+C EsVj6SLI0XRQbbt7lX+jPQz+sKwR0y0imaDKlwPCQlDwxISimlmke4Ljzis3arsG6kE7 U61TmXdeeq/h5PG3XuNvyEe7/uhnqcPUJmli8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AJRISEzRJskVsCmRP7dlMyhgRzV0ky0jKeNpA/Fhpxs=; b=s5WS7gYQuodyDpvfv27ab5XQbUXlqqFqweibuO7FVPAv53U0419ekZ3qOF2inRhZOK nFs7x3T3jgVc0ZxEZ0uWHqkQsUhJpmXVRkWcx+vdSu4lC6/3kCJLOIJltra57EjVminn MFJZfZquC5cU78QtIcivLOAHEklQEDagpXXlfnm4wf/upbtrQVPMVGOYHZTDBrJyC/29 gKLxB49n2RbX2kFBjQPNp6c6fuxtCBc7P3hyNLiOgJHcqbFpakr/gBnS6s8MfhqNuFhq xBRQJWn/w8RWSO7J8bDPhDAjrT3zA1lzuEF11XJ8/ViSE+hfLZwZpQyEHrDIqZGQbi/y 6Erw== X-Gm-Message-State: APjAAAWBNS2XGQDTsMwwK8LRMpzj37YjV6DgoMafJq/O9Ft4JSmFY4t7 QrNsuiIcgGWPAnn7I8PSXfXHEQ== X-Google-Smtp-Source: APXvYqyHGK2lNSVvu4HPKP8MapX8U1SFafdARjbT4C/WmxBIuujkjhPRkM2Pc7HBma2ot0B/yZMZsw== X-Received: by 2002:a63:d441:: with SMTP id i1mr4882989pgj.426.1582735224032; Wed, 26 Feb 2020 08:40:24 -0800 (PST) Received: from [192.168.7.29] (c-73-15-208-167.hsd1.ca.comcast.net. [73.15.208.167]) by smtp.gmail.com with ESMTPSA id z10sm3303163pgf.35.2020.02.26.08.40.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 08:40:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Brendan McMillion In-Reply-To: Date: Wed, 26 Feb 2020 08:40:21 -0800 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <101134CD-4B65-4172-9F82-C9466AE0B021@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming merge for 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: Wed, 26 Feb 2020 16:40:26 -0000 Hi all My comment on the current PR is just pointing out that, if an extension = is used in a group=E2=80=99s config, then it seems like it's mandatory = for all clients to understand that extension. There are some cases where = it might be desirable for a group to =E2=80=9Chave=E2=80=9D an extension = without call clients needing to understand it, including: - Extensions that improve efficiency without wire changes - Extensions that create out-of-band channels - GREASE extensions So, this is an argument for distinguishing between mandatory and = optional extensions. > On Feb 26, 2020, at 8:28 AM, Sean Turner wrote: >=20 > Hi! >=20 > Brendan noted on the call that he thought that we needed some more = discussion on #296. I see that he=E2=80=99s submitted a comment on the = PR. If we cannot come to closure on this on list, then we can discuss it = next week. >=20 > spt >=20 >> On Feb 25, 2020, at 12:29, Sean Turner wrote: >>=20 >> All, >>=20 >> The following PRs were 1st discussed at the 5-Feb virtual interim. = The WG discussed them again on the 1-Feb call and the editors believe = these are ready to merge. If have any objections to merging these please = provide your input by 2359 UTC 28-Feb otherwise we will declare = consensus and the will ask the editors to merge the PRs. >>=20 >> #283 Use the same ratchet for Handshake and Application keys >> https://github.com/mlswg/mls-protocol/pull/283 >>=20 >> #296 Flesh out the extensions story >> https://github.com/mlswg/mls-protocol/pull/296 >>=20 >> #304 Use HKDF to derive key pairs >> https://github.com/mlswg/mls-protocol/pull/304 >>=20 >> Cheers, >>=20 >> spt >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 26 09:19:38 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8903A0CBF for ; Wed, 26 Feb 2020 09:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 dT_v8z7C8jTN for ; Wed, 26 Feb 2020 09:19:36 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 017063A0CB6 for ; Wed, 26 Feb 2020 09:19:35 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id e16so148696qkl.6 for ; Wed, 26 Feb 2020 09:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=cpo7CjcJQherezSD9QazYWxH3XX3LPyIJzEj65LEhSI=; b=VXcFu/hCk/5TIIWC4OQ8iGfE03REXjd6XkEmdoG36DED2Xl7STDJTyKJP4GvM4ql6W VFmsBMILHwI8V7S3PrEHgyN0Q71hblxspvlNSk/rkyZy5NBfxoz8329aSjQ3dzp0QsHJ 08N+Yiyh4Cc0YJ95Qi0Cmk8+jxoD2qDCR9y3g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=cpo7CjcJQherezSD9QazYWxH3XX3LPyIJzEj65LEhSI=; b=ctgVINqxn8kR6L0UC6RjFp3DVOQxiBSWPKYu1i8d/zWojZM5dGcCImowokrrppTN3v qGl+2XZqUyPiFw5N2KB3fU7eJvL+FjZMokz19biBng47jKia7VbYWIzNa5Dmp2TsKYMY UkrJH3NbNVX/kN5G+5EuWrmM5SNSJv81aOo5t6r8AJE3QFiKnotrg15icx4oj+g9x3ji L70eNf+zrnJKYXlJeYIgBc/BTVSLIYtfvg01meOZJIA2j6V7SE6AHG/sElJ0ixIY37sF d34bQ8Egx9qn0XDrLm8E50X3/hFsyP22q4kbGZMpSoWisTZDkYGtQnpOIec506taPy2z zNgg== X-Gm-Message-State: APjAAAV14tM8Vs95DOFnd0fGEF/ftsOXTcNsxAQyxYlKkq+0b80hBAmO yT6OPGAXEBnHN/jIRo6QriUF7os/c5c= X-Google-Smtp-Source: APXvYqwkpCt95LzqVQGrwaG20oCKTw16JmyjYImiB61gxA0+sql2gNk3pg/+j/LtAvuSOvTOZxT0Ug== X-Received: by 2002:a05:620a:1641:: with SMTP id c1mr124325qko.69.1582737574725; Wed, 26 Feb 2020 09:19:34 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id t29sm1504836qtt.20.2020.02.26.09.19.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 09:19:34 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <6F786342-D04D-457C-A440-6E70EF0C8547@sn3rd.com> Date: Wed, 26 Feb 2020 12:19:26 -0500 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] mls@IETF107 Important Dates 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, 26 Feb 2020 17:19:37 -0000 Just an FYI, but the draft submission deadline for IETF 107 is: 2020-03-09 (Monday): I-D submission cut-off by UTC 23:59 Other dates can be found here: https://datatracker.ietf.org/meeting/important-dates/ Cheers, spt From nobody Wed Feb 26 09:25:02 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4573A0DD8 for ; Wed, 26 Feb 2020 09:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] 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 hf6DIFZEyahy for ; Wed, 26 Feb 2020 09:24:52 -0800 (PST) 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 42C473A0DBA for ; Wed, 26 Feb 2020 09:24:52 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id o28so144927qkj.9 for ; Wed, 26 Feb 2020 09:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=eRzeUCb9Ka8Q3+8Q/VSq9WLeRYML1DpP5TikGDOyqiQ=; b=J70CebIqOALVPromxxSiJWcQZ8m6vjYtbpCr8jV2UAuYHwBJs3HvfFHJ2d5kPUhWyt qeO0/AO6X1eFEhj9X6jM3HVwj7z6ZYfDlaGAT/xmvPt/0SsVAAldjT/J0XLwYxQdlT/v 4VpFbLlWNHgs9AgLlvphpp878wi4eKDD7OYoM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=eRzeUCb9Ka8Q3+8Q/VSq9WLeRYML1DpP5TikGDOyqiQ=; b=ms1XC2a6xBk0LH5G8lrwX0Bk3NHzsvWIVczodV1yBTItPoEMSK32YeK8PoZgKEIywb i6U5w9KuMH5tSP6LUI7Gwdu9tAaiNejtMkH0Nmx5PcMrhZAmoaqM6n1I7GTR3zx0e/mL f6UwFb53ohx9JCElv3y6oBspSrMjs4kAWaVH3voyHvfNRc0QeZ3ZC5MOOxAwpnwXS7GI PXOjDOlUe5NFUaNomxr9K+GGdqbT49S7ZgcTfMlSiOioaAAMeAj7Gz/YQLg/j/EImZmt 5h31R29qdnr0HWgEH33xhOSWe7ptfJJBLzMfFpnIHKIoQKlajzxx5qeLLBYc9WHw+xdC +tUg== X-Gm-Message-State: APjAAAX5xOW/r+1TEqkEmUwcgutrsymE7121L/xX8WuImmGTWnzt24E9 tXxxZJkx2udVUP1k8x80YiEIrDQDiw4= X-Google-Smtp-Source: APXvYqzVlvISSTA9RwdH5ol8BGQXhIgAkFoIaw9eGOIMEpZjbYW0SDvpR3sMiHMh5eVbbaK2vApRzg== X-Received: by 2002:a37:ad18:: with SMTP id f24mr154694qkm.41.1582737891070; Wed, 26 Feb 2020 09:24:51 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id t4sm1468827qkm.82.2020.02.26.09.24.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 09:24:50 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Feb 2020 12:24:50 -0500 References: <59FD2B38-E231-4F4F-9C9B-3875133A264C@sn3rd.com> <3E04E4AB-DD2F-4747-A276-80450EFAEE40@sn3rd.com> <18A288AF-9CFD-4EB4-96EF-C77463CF2555@sn3rd.com> To: Messaging Layer Security WG In-Reply-To: Message-Id: <72CD15F5-A839-4023-9CAF-0D8145966578@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Calls to resolve MLS 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: Wed, 26 Feb 2020 17:25:00 -0000 Minutes for 2/19 (thanks Richard) and 2/26 meetings available now at = github: = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-19-2020.md = https://github.com/mlswg/wg-materials/blob/master/virtual-interim-recurrin= g/02-26-2020.md spt > On Feb 26, 2020, at 11:27, Sean Turner wrote: >=20 > Thanks to Brendan, Britta, and Ray for calling in today. >=20 > You=E2=80=99ll see some emails about the two topics we discussed = shortly. >=20 > spt >=20 >> On Feb 25, 2020, at 12:20, Sean Turner wrote: >>=20 >> Please note that there is another meeting tomorrow. Same time, place, = and details: >>=20 >> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >> Meeting number: 647 391 156 >> Password: ve2i8niw >>=20 >> spt >>=20 >>> On Feb 18, 2020, at 19:56, Sean Turner wrote: >>>=20 >>> Apologies for the late reminder, but there is yet another virtual = interim scheduled for tomorrow. The call information is the same as last = week: >>>=20 >>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>> Meeting number: 647 391 156 >>> Password: ve2i8niw >>>=20 >>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>=20 >>> spt >>>=20 >>>> On Feb 11, 2020, at 16:53, Sean Turner wrote: >>>>=20 >>>> As a reminder there is another virtual interim. This is the call = information: >>>>=20 >>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>> Meeting number: 647 391 156 >>>> Password: ve2i8niw >>>>=20 >>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>=20 >>>> spt >>>>=20 >>>>> On Feb 4, 2020, at 05:21, Sean Turner wrote: >>>>>=20 >>>>> As a reminder, the recurring virtual interim is tomorrow. The = information is the same as last week. >>>>>=20 >>>>> spt >>>>>=20 >>>>>> On Jan 28, 2020, at 23:52, Nick Sullivan = wrote: >>>>>>=20 >>>>>> As a reminder, the recurring virtual interim is tomorrow. Here's = the meeting information: >>>>>>=20 >>>>>> Meeting link: = https://ietf.webex.com/ietf/j.php?MTID=3Dm2e0d1a76482036fdb38c7d1f5fdd3cc6= >>>>>> Meeting number: 647 391 156 >>>>>> Password: ve2i8niw >>>>>>=20 >>>>>> = https://github.com/mlswg/wg-materials/tree/master/virtual-interim-recurrin= g >>>>>>=20 >>>>>> Nick & Sean >>>>>>=20 >>>>>> On Wed, Jan 22, 2020 at 11:04 AM Nick Sullivan = wrote: >>>>>> It looks like Wednesday at 1400-1500 GMT is the least bad time. >>>>>>=20 >>>>>> These calls will be recurring virtual interims, and as such are = covered by the note well. As a reminder, decisions made at interim = meetings are not final and must be confirmed on the list. >>>>>>=20 >>>>>> Here's the proposed schedule (subject to AD approval): >>>>>> Time: 1400-1500 GMT on Wednesdays >>>>>> Agenda: the set of active PRs for the active documents on Github = (https://github.com/mlswg). >>>>>>=20 >>>>>> Links to the conference calls are forthcoming. >>>>>>=20 >>>>>> Nick & Sean >>>>>>=20 >>>>>> On Mon, Jan 13, 2020 at 8:51 AM Richard Barnes = wrote: >>>>>> Also: Note that despite this poll listing specific dates, the = intent is to set up a weekly recurring meeting. In fact, these dates = will definitely not be the dates when the calls happen, because IETF = requires one week notice. >>>>>>=20 >>>>>> On Sun, Jan 12, 2020 at 6:05 PM Richard Barnes = wrote: >>>>>> I would like to have some weekly calls to make faster progress on = our outstanding PRs. Here's a Doodle to find a good time: >>>>>>=20 >>>>>> https://doodle.com/poll/bg2q65phrvfip5zb >>>>>>=20 >>>>>> I believe these will need to be official Virtual Interims per = IETF process. Chairs, I assume you can do whatever announcements are = necessary once we pick a time. >>>>>>=20 >>>>>> --Richard >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Wed Feb 26 09:36:20 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0188E3A0E52 for ; Wed, 26 Feb 2020 09:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN859HP5lI23 for ; Wed, 26 Feb 2020 09:36:17 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4533A0E57 for ; Wed, 26 Feb 2020 09:36:16 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id u124so165640qkh.13 for ; Wed, 26 Feb 2020 09:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bANw9Q10UXtd0pVeoGuTF349gtsBLyz3gyNjxi3RDtk=; b=lOHYC7Lb2HKNwvsSgMnqovE7nCUzHI4qT08r39IN0mzOpAtCeUftfNtxu+StBJPcB1 jxTR863dwmZ1cBnU5z9TSXJaqp8hI0whMD6HnSIBFhaeuyQVn7hVsyaR5+gV2oYYgjd8 6uT7HrP/aPelwJUP+TiCJesQNcLBGY0eV2Z6rg66AOW93FyyP1Xfso2ZpW3g+/Uw6mgB MoVmL6HLrAjaJw4AirGpC/lnrFVjys5QKeKeYHuX0gyTeBRqxaPmIBG1hGUlGbFknHXb bh2vyDRDbCsNWpO5OuBrD0DqxhU0nYD8twqBeAVLoMasLyS4m0IiAgGT1I1cWhLsn78q b4SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bANw9Q10UXtd0pVeoGuTF349gtsBLyz3gyNjxi3RDtk=; b=eXdBIL7a+ybC3NsdBiR5fnyxqPEqUWlYlv98a1mLAAq4zf3XfUln9dso0Pe8fGzdQN hSQ83iAFuYkh9F2c9WpnHslEHYVv4pC3gTLxcwekKu1tbomztYO+Ep0DuBEEXYvC4kr+ jESu34imG2J9dnFMSeLeOqRrIuXPWn8mKqXW52IWEfcyjOmph6ZsqHqaH1+vr1SOkHr5 WJ3I2clM8Sx76WPO2MMyZEd/K2sJWmlEViKzqqE2mLyh+GxTU7ImJC5OWRlRHMF5ROcc /DDwvY1VB2CplP+w3X0NyAtGTBGLUZxULZnsY7Hi3uhEyJvAB0sBBI6JeAV4AF+YAuFX XVYA== X-Gm-Message-State: APjAAAVLplGveyNMWIiTDzTcz3zS/753E2Qf9nDRNAEVm0NTdzTp5DvU GUhwtZsJWmZPXtAs9oPKWUrze3i8DbgObg6oFHnesw== X-Google-Smtp-Source: APXvYqzRKH66dtQ4hXdbDESzrKNUNkcQkK6TXCwKqMD082twsUrhTLo9BboSEXHly0XzC94mbhszFahPkOSyT5iJ6V8= X-Received: by 2002:a05:620a:989:: with SMTP id x9mr187980qkx.371.1582738575767; Wed, 26 Feb 2020 09:36:15 -0800 (PST) MIME-Version: 1.0 References: <101134CD-4B65-4172-9F82-C9466AE0B021@sn3rd.com> In-Reply-To: From: Richard Barnes Date: Wed, 26 Feb 2020 12:35:59 -0500 Message-ID: To: Brendan McMillion Cc: Sean Turner , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000094cd40059f7e0afe" Archived-At: Subject: Re: [MLS] confirming merge for 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: Wed, 26 Feb 2020 17:36:19 -0000 --00000000000094cd40059f7e0afe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Minor note: The usual terminology here is "critical" / "non-critical", cf. X.509, JWE/JWS. You observation here is correct -- much like in TLS, the server's selection of extensions governs for the session, the group creator's selection of extensions governs here. As a corollary, the group extensions MUST be a subset of the CIK extensions (just like server extensions are a subset of client extensions). I thought I had elaborated this, but I'm happy to make it clearer. I'm not sure that your examples really make the case for non-critical extensions: - If extensions change processing, even if they don't change the wire image, everyone needs to do them. See, e.g., RTreeKEM. - GREASE extensions should be ignored, but only if the client *knows* they're to be ignored, in which case the client supports them. Note that even in TLS (where the need is more acute), GREASE doesn't change who offers and who chooses. Not sure what you're envisioning for OOB; maybe there's a case there. In any case, if you have an all-critical extension mechanism, you could use it to opt into an optional-criticality extension mechanism, since everyone would need to support the concept of non-critical extensions. Or if it was really important, adding support is just a matter of adding a criticality flag. I'm not finding a compelling reason for non-critical extensions at this point, though, so I'm inclined to land the PR as it is (possibly with some clarifications), and pivot later if we really need non-critical extensions. --RLB On Wed, Feb 26, 2020 at 11:40 AM Brendan McMillion wrote: > Hi all > > My comment on the current PR is just pointing out that, if an extension i= s > used in a group=E2=80=99s config, then it seems like it's mandatory for a= ll clients > to understand that extension. There are some cases where it might be > desirable for a group to =E2=80=9Chave=E2=80=9D an extension without call= clients needing > to understand it, including: > > - Extensions that improve efficiency without wire changes > - Extensions that create out-of-band channels > - GREASE extensions > > So, this is an argument for distinguishing between mandatory and optional > extensions. > > > On Feb 26, 2020, at 8:28 AM, Sean Turner wrote: > > > > Hi! > > > > Brendan noted on the call that he thought that we needed some more > discussion on #296. I see that he=E2=80=99s submitted a comment on the PR= . If we > cannot come to closure on this on list, then we can discuss it next week. > > > > spt > > > >> On Feb 25, 2020, at 12:29, Sean Turner wrote: > >> > >> All, > >> > >> The following PRs were 1st discussed at the 5-Feb virtual interim. The > WG discussed them again on the 1-Feb call and the editors believe these a= re > ready to merge. If have any objections to merging these please provide yo= ur > input by 2359 UTC 28-Feb otherwise we will declare consensus and the will > ask the editors to merge the PRs. > >> > >> #283 Use the same ratchet for Handshake and Application keys > >> https://github.com/mlswg/mls-protocol/pull/283 > >> > >> #296 Flesh out the extensions story > >> https://github.com/mlswg/mls-protocol/pull/296 > >> > >> #304 Use HKDF to derive key pairs > >> https://github.com/mlswg/mls-protocol/pull/304 > >> > >> Cheers, > >> > >> spt > >> > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000094cd40059f7e0afe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Minor note: The usual terminology here is "criti= cal" / "non-critical", cf. X.509, JWE/JWS.
You observation here is correct -- much like in TLS, the server= 's selection of extensions governs for the session, the group creator&#= 39;s selection of extensions governs here.=C2=A0 As a corollary, the group = extensions MUST be a subset of the CIK extensions (just like server extensi= ons are a subset of client extensions).=C2=A0 I thought I had elaborated th= is, but I'm happy to make it clearer.

I'm = not sure that your examples really make the case for non-critical extension= s:

- If extensions change processing, even if they= don't change the wire image, everyone needs to do them.=C2=A0 See, e.g= ., RTreeKEM.
- GREASE extensions should be ignored, but only if t= he client *knows* they're to be ignored, in which case the client suppo= rts them.=C2=A0 Note that even in TLS (where the need is more acute), GREAS= E doesn't change who offers and who chooses.

N= ot sure what you're envisioning for OOB; maybe there's a case there= .

In any case, if you have an all-critical extensi= on mechanism, you could use it to opt into an optional-criticality extensio= n mechanism, since everyone would need to support the concept of non-critic= al extensions.=C2=A0 Or if it was really important, adding support is just = a matter of adding a criticality flag.

I'm not= finding a compelling reason for non-critical extensions at this point, tho= ugh, so I'm inclined to land the PR as it is (possibly with some clarif= ications), and pivot later if we really need non-critical extensions.

--RLB

On Wed, Feb 26, 2020 at 11:40 AM Bre= ndan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:
Hi all

My comment on the current PR is just pointing out that, if an extension is = used in a group=E2=80=99s config, then it seems like it's mandatory for= all clients to understand that extension. There are some cases where it mi= ght be desirable for a group to =E2=80=9Chave=E2=80=9D an extension without= call clients needing to understand it, including:

- Extensions that improve efficiency without wire changes
- Extensions that create out-of-band channels
- GREASE extensions

So, this is an argument for distinguishing between mandatory and optional e= xtensions.

> On Feb 26, 2020, at 8:28 AM, Sean Turner <sean@sn3rd.com> wrote:
>
> Hi!
>
> Brendan noted on the call that he thought that we needed some more dis= cussion on #296. I see that he=E2=80=99s submitted a comment on the PR. If = we cannot come to closure on this on list, then we can discuss it next week= .
>
> spt
>
>> On Feb 25, 2020, at 12:29, Sean Turner <sean@sn3rd.com> wrote:
>>
>> All,
>>
>> The following PRs were 1st discussed at the 5-Feb virtual interim.= The WG discussed them again on the 1-Feb call and the editors believe thes= e are ready to merge. If have any objections to merging these please provid= e your input by 2359 UTC 28-Feb otherwise we will declare consensus and the= will ask the editors to merge the PRs.
>>
>> #283 Use the same ratchet for Handshake and Application keys
>> https://github.com/mlswg/mls-protocol/pull/28= 3
>>
>> #296 Flesh out the extensions story
>> https://github.com/mlswg/mls-protocol/pull/29= 6
>>
>> #304 Use HKDF to derive key pairs
>> https://github.com/mlswg/mls-protocol/pull/30= 4
>>
>> Cheers,
>>
>> spt
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000094cd40059f7e0afe-- From nobody Wed Feb 26 10:25:01 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A523A0EE5 for ; Wed, 26 Feb 2020 10:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCVcQpLjnyB7 for ; Wed, 26 Feb 2020 10:24:56 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDD13A0F51 for ; Wed, 26 Feb 2020 10:24:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,489,1574118000"; d="scan'208";a="437791449" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 19:24:33 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Benjamin Beurdouche In-Reply-To: <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> Date: Wed, 26 Feb 2020 19:24:33 +0100 Cc: ML Messaging Layer Security Content-Transfer-Encoding: quoted-printable Message-Id: <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 18:24:59 -0000 I would strongly prefer one signature scheme for the lifetime of the = group. B. > On 26 Feb 2020, at 17:28, Sean Turner wrote: >=20 > There seems to be rough consensus (stressing the rough) to go with one = scheme per group. By rough consensus, I mean there seems to be a = willingness by the group to live with this decision and nobody is super = bent out of shape about it. Technically, that=E2=80=99s all we need to = move forward, but there are some concerns concerns that since it=E2=80=99s= such a small group and there are so few strong voices for the choice = that we should give it just a bit more time. So, I am extending this = call until 2359 UTC 2 March (i.e., Monday night). >=20 > Also, there are really three ciphersuite-related decisions being made, = as noted in the email below. >=20 > spt >=20 >> On Feb 25, 2020, at 13:24, Richard Barnes wrote: >>=20 >> I will not be able to make the call tomorrow, so to summarize my = opinion on this: >>=20 >> * I am OK with merging the current PR >> * I have a slight preference for *not* including the sig alg in the = ciphersuite >> * The simplicity case for including it seems reasonable, but not = dispositive >> * In any case, I don't care strongly one way or another; I care more = about progress >> * This is an easy change to revert if we change our minds later >> * Credentials are going to indicate the signature algorithm anyway >> * So the only difference in spec is whether endpoints check = Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm >>=20 >>=20 >> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: >> Note that the main point of the telecon tomorrow is to address the = cipher suite issue. Please take the time to review: >> - the related PRs: >> https://github.com/mlswg/mls-protocol/pull/279 >> https://github.com/mlswg/mls-protocol/pull/307 >> - the messages in this thread >> - the issues Britta outlined: >> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>=20 >> We would like to close this issue out tomorrow. >>=20 >> Cheers, >>=20 >> spt >>=20 >>> On Feb 19, 2020, at 01:09, Konrad Kohbrok = wrote: >>>=20 >>> Hi Britta, >>>=20 >>> I think you sum it up very nicely. There is one (albeit somewhat = speculative) >>> argument why a single ciphersuite per group might actually be = beneficial in a >>> federation context. In the event that there is "global concensus" = that a >>> ciphersuite needs to be deprecated, my expectation would be that a = majority of >>> the federation nodes/application providers would move to ban those = ciphersuits, >>> excluding anyone who would use _exclusively_ that ciphersuite. That = would in >>> turn be a motivation for all other nodes/application providers to = catch up as >>> well. This also means that nodes can't be made (by whatever = authority) to use >>> weak ciphersuites exclusively and still expect to federate with = other nodes that >>> have more sensible policies. >>>=20 >>> That's mostly my guess of how the dynamics in such a federated = environment >>> _could_ work, though. Anyone here with some actual = experience/expertise they can >>> share of what the dynamics could be? >>>=20 >>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just = seems a lot >>> simpler and even in the context of federation, I think that most >>> nodes/application providers would allow several ciphersuites to = begin with, >>> where not all of them are weak, meaning no one would really be = excluded too quickly. >>>=20 >>> Cheers, >>> Konrad >>>=20 >>>=20 >>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: >>>> Under the topic of individual/single signature schemes there is the = final issue of federation. In a federated context, groups are no longer = under the control of a single application, meaning that we would lose = some control in forcing good ciphersuite choices. This could lead to two = issues: >>>>=20 >>>> 1) MLS would move closer to facing the TLS problem of having old = suites supported by edge cases, which in turn weaken the entire group's = security. There is always the argument that groups would simply refuse = joiners that do not support the current group cipher, but this is not = very practical from a usability view. E.g. if everyone using application = X refused group members who were using application Y, then the point of = federation would be largely defeated. So, either some form of = renegotiation is allowed (e.g. export psk) and downgrade becomes more = likely, or federation does not work reliably.=20 >>>>=20 >>>> 2) Healing would take longer. Since no one application has a master = view and control over ciphersuites, upgrading long-lived groups using = questionable ciphers could take a significant amount of time (all = applications would need to do so in order for the group to upgrade) or = alternatively result in kicking group members out of the group (again, = possible, but questionable for usability except in extreme cases). Under = an individual cipher choice, any one member can choose/upgrade their = scheme, allowing for faster adaptability and potential benefits to PCS.=20= >>>>=20 >>>> =46rom the above, it seems that a single group cipher makes = federation harder/slower/less secure, but I may not have a clear view on = how federation would work in this context. Does anyone know whether the = above are really concerns or not relevant due to other reasons?=20 >>>>=20 >>>> (Note that this is thinking in the long-term context. Obviously we = do not want to standardize any cipher choice that is sub-optimal; = however any number of things may happen with protocol versioning and = cipher breaks over the span of several years.) >>>>=20 >>>> Under all the considerations that I have seen so far, the pros and = cons on both sides place the individual signature cipher option in the = lead. However that lead is small, hence why I have not been arguing for = it. The issue of federation could be a deciding factor. If we want = federation in the future it is of course better not to build inhibiting = factors into MLS now that could undermine either usability or security = in such contexts. To make a case to proceed with the single group cipher = option, it would be great if someone could provide a convincing argument = as to why it would be the best option for usability and security in the = federated environment (or preclude a federated use-case altogether). >>>>=20 >>>> --- >>>>=20 >>>> Britta=20 >>>>=20 >>>>=20 >>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Concerning the use of a single group signature scheme or = individual signature schemes, it is probably worthwhile to expand on the = consideration points and clarify what security implications we are = accepting - in either case. I have listed out some issues in the = following Google doc: >>>>=20 >>>> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>>>=20 >>>> I am not making an argument for either case at this point, but = pushing this out for discussion and to help us achieve more clarity as = to the benefits and consequences of either choice. There are certainly = more issues to consider (e.g. ease of implementation, efficiency, etc. = in addition to security considerations) and other views - feel free to = add them or discuss on the mailing list.=20 >>>>=20 >>>> All the best, >>>>=20 >>>> Britta=20 >>>>=20 >>>>=20 >>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" = wrote: >>>>=20 >>>> Hi! >>>>=20 >>>> tl;dr: confirming MTI suite selections and rationale for = avoiding proliferation >>>>=20 >>>> During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. >>>>=20 >>>> There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There = are, at least, three things to consider: 1) if a potential group member = does not support the algorithm, then they will not become a member or = the group will need to downgrade; 2) when the group needs/wants to = update, it is a flag day; and, 3) the cipher suites will have a similar = combinatorial issues as the TLS cipher suites prior to TLS 1.3. The = agreement was =E2=80=9Crough=E2=80=9D because 1) likely has some = important implications. >>>>=20 >>>> The MLS cipher suites defined were as follows:=20 >>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >>>>=20 >>>> At the interim, the consensus was to make the non-NIST suites = the MTI. The rationale was that those implementation that need to be = NIST compliant will do so regardless of the choice made by the WG. >>>>=20 >>>> In looking at the actual cipher suites, it was noted that the = 256-bit schemes the SHA should be SHA-512. The rationale agreed was that = SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one = less operation. >>>>=20 >>>> To avoid the proliferation of cipher suites, guidance will be = provided to be conservative about allocating new code points. The = consensus at the interim was that the suites provided were minimal and = provided good coverage for the known use cases: >>>> - (X25519, AES-GCM, Ed25519) - Good for desktop >>>> - (P-256, AES-GCM, P-256) - Compliance >>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile >>>>=20 >>>> The chairs need to confirm the interim=E2=80=99s consensus on = list, so please let the WG know by 2359 UTC 20 February whether you = disagree with these choices and why. >>>>=20 >>>> NOTE: The final text will obviously be reviewed, but is being = composed as part of the following PR: >>>> https://github.com/mlswg/mls-protocol/pull/279 >>>>=20 >>>> NOTE: We combined these cipher suite related consensus = points, but if we only come to consensus on some of these we can still = incorporate what we do agree on. >>>>=20 >>>> Cheers, >>>>=20 >>>> Nick and Sean >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 26 10:48:56 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880D23A1107 for ; Wed, 26 Feb 2020 10:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, FREEMAIL_FROM=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHYyqSoUawvq for ; Wed, 26 Feb 2020 10:48:44 -0800 (PST) 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 EFE593A10EC for ; Wed, 26 Feb 2020 10:48:36 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id c13so3661812wrq.10 for ; Wed, 26 Feb 2020 10:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yKDshBSN0Y8BnWkVN7JBM5kbLbg9DhfRmeHi6v7WG0w=; b=Zn9KP00Ig4J3ySRm14M7b+6TKHzL+hnddl4fl4JGfa73hXH/8Fax/uAXx58awEpsye vpVR1fwldxZX6I4ZQRUfz3x+45j59v76R4CAq3NivzADlmT+c7jwJi84M3bI/hHtOVSM kH5Ff7Oeiwz30jFxKakwPB+Jyv/dTv3xuISZEBoh3zTzZkqAp23tm5csupTItxNJMaJg LWsXug0PFsRr2gLE4dCVKKEmBhj+T2aG6dldSTS6FObg4jMy6n3KKmJwtmuSEpnOxobS YtI9qpFc36b9R1ff0GWEkL8zsihSMNqlUcqmC6IiJGVkii+AowkmJHFvAiYvxkjeexuy GLhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yKDshBSN0Y8BnWkVN7JBM5kbLbg9DhfRmeHi6v7WG0w=; b=P4KOvESM79ObFoS77XFUecU9QAXBKU2N5z8JTLQPaxR2E5hXwjF8pF1nc3/GHWqVMq a8/KIf0lsNvGO4mR7pn02thhDAQL/8jZ2kWhAb7V+qgX5OKo7vzfc9XpYU4GPjv027RO 79SpIxBdVdhux8T4b7TXkPS86eUPpSmJhfRSsNAR41JRepRFTMrzzzM9Z3BNvRuNILuC BL7SunpxXHGqAgl/n0J2roji7PoX0HxxV6hO+SzjbhIMKeRFFL9F2Btow0weWvSGGNwh EIYdtPKwL+Zp0W4iGJRrfqVGz9AoUhSGMrVCEaS4bswM11uBzGeFcGdf57P4XbxjrmF+ Pb6Q== X-Gm-Message-State: APjAAAUH4R2dj8aGocvkhDl4kH8Vjwi1arehqLd7oH0G5o7iILEaz0qw MP9i9AhCIWV/zh6yIxxibkS0Jhg6 X-Google-Smtp-Source: APXvYqw/TJ9ZAXDYG6uI3j1LOPh4DJsS/t29yddA9G6bAcJm+7a6zud9pVYiVoQtkhbN+CqItTdMpg== X-Received: by 2002:a5d:6191:: with SMTP id j17mr4537wru.427.1582742912724; Wed, 26 Feb 2020 10:48:32 -0800 (PST) Received: from ?IPv6:2a02:810c:c1c0:542e:59f5:8c32:7743:205a? ([2a02:810c:c1c0:542e:59f5:8c32:7743:205a]) by smtp.gmail.com with ESMTPSA id q6sm4341138wrf.67.2020.02.26.10.48.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Feb 2020 10:48:32 -0800 (PST) To: mls@ietf.org References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> From: Cas Cremers Autocrypt: addr=cas.cremers@gmail.com; keydata= mQGNBFyjFJQBDADNlXG/t7Nd15sfLSf+jaDMUZJvnz59PW5OYoubAWqqNGQBK6A6ahPb6ebX epYdBp/ilE+n1KP/evaV8dMaktooeptOB7D3neOvRox73o2JEjNTC+8OU90dNmGo9UxAVPS9 HuEuJsmvvssiWg97hZBeaPf2F/Hfg2U+RlAKIpR+c+wdc2lTRMqhQXN8OskzQZzlEP8LrMER 1ZT9q22/bdN7nKnpsXSEB8hj8y1dErZHA3+6m73srG7Q7Muw5Kr6zCF4OTXrXsajHHsEyZFj L7qm9BYyrWQ9yXb0l0vWb+i1tzTEK20NoSJiapk3/0prU54dgK3FqQM8SRm7R1wd5mFGN+4x c8pMd/CvHZfJmN4WT581dxaKFMsTFRXMefMKrzbKTgYLsa6tjpFL/sVf06PSkihk/Tc6qrf0 0nxs6pmGHycfC70zwqqqgFdyYQqTUqMforH5cLpms55O4ONCJ6fk+r0fuQO4qXSRK2z00Rpz mJi0WcKyfiHbB/guH5Rqdc8AEQEAAbQjQ2FzIENyZW1lcnMgPGNhcy5jcmVtZXJzQGdtYWls LmNvbT6JAdQEEwEIAD4WIQRIa4Hi/W0N8sfSgzj/8IKxn6kiTQUCXKMUlgIbAwUJAeEzgAUL CQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD/8IKxn6kiTZlWDACFkJBQwDlyCwbp8/hoo4MM awQiLC43SZs8YcTYhX11JVBYvFX3JaphqNdzO8rabtEurHY+R3HOXtHOmMrh+dvDqHIt9q9F dW2B0b7Cs2ayvsI/wRjjS6YTMv8ufGDyLc+DvPvabiEMhCHCA1JQ/qBbzIM9D6DqcJqySR1V /nZjWWAgODQ6BN5xaDXZ8IZGv3s0BIvoCV4E0G5oTQY+3I2pxK40A/0yQERkG+P3xYx71QXQ EPQNOTou/JdWtoehpS5WK8z1PEhWTyVfhin0VXr29cCnKi/d7GIVMmniiEBH9R7QqYPqyJEb DvyUifwaS3HkJtjt1zFURBzeHW+usFza+5cN70qeHVyljjeNrMUAFa0aV1MuCDi4NQOMWkYu 3kjNEqELH+YCi16helZLy1X+AgYjiuzy58/O+WqgqOpnOVWTSBy79XX59ca47vS7BBrmGZTr 5ZvVIXGBHFmSHm0Lkn7TOeszR3L+TZUt8vv50M/+7b0mh+jl6J4i4vb1LsS5AY0EXKMUlQEM AMnddlUgDeoW5jU0pmylA2jtexsT/0EiY+Z0h1cBjP4vWcPJua9K/dBJwPujfshRBSYw97+W Z8h9CoFyK8nWVhRLtALwa9PrlpJ0T2PKbspnb1FTu+eTMEM05YxRD5y0eTY7Q/vdauZ/r1x8 CCOimBZ63Djh5xBogXBUUOm+aLArWaL0/Y/3OUdu00ztrL/IRUF3bDvJch58D6vxvw6IDGMG TzUWGcV0WDyYleUZ1qBEYRsa7JTJ71uJLLRc8NRnaEsD2XkHDhcwHoqk+DIwhuWAdo+i0TGJ fmTcqT2U+3X3WCkEh2Oj4PTA1eb1suEDoicueFGm1tcJ5q9dVuY3weZVDycfMmpzHl3bPhP4 EVkfXvOjUgO0E5UnIo24NnmugBBslEW3+DEd38IUZPjmzYFU8v+OMShJ8siVS7+BTL/na3/g lBhrvNjFNG9p5Wxe+572lZuNa+7tphVb+ipnt2h+3RH/I83fekUODm/+CeVhwYMAhKRfLWhi sfpHogOkNQARAQABiQG8BBgBCAAmFiEESGuB4v1tDfLH0oM4//CCsZ+pIk0FAlyjFJUCGwwF CQHhM4AACgkQ//CCsZ+pIk0YGgv/YENZhZTtgBRVP9FeGTnpJ+YHwzfIXXExj/kbV0c/pSdQ j4vhKclmDRd/rX/IpEpvipfPNgJMfAbiq0uPYgmmoIlGecOQAzYWJxsMPNs5Coz0xDU2hRx+ OnY1ueusLvJN/msxxhdT0lnnQiaGKw5dntnu8dUjdG1vvESd2Mg5rmXalo3MfERF465PYz4r ewIyELT8oaCyqldDrNyNxn64fsDqoYx/md8yQQJJl//LHuVXTy7ylN/NiuF9FWO8z19Ttc/E JeHwCASU24+S4o5gj0A2HgUoxNDzhpxtUGfRH3shGnJ1KeqsRtgxwocd6XL8kaXzYmVOgOyW CN6pu6PpISxW82HogdcblVhvudLoZdO5enwHoWwxfqH6lc0O2jZ86eZb8NiFPi5hxXjEzm9d UBBj4bryCnq9z3UtBX+WUW1bkCCjjrtGVI/peZWP3TyNkgZ6Xwt/tj2Vpqf/2ujnDnWPnztB hoF/x6+xCfXBkpKQD8RbIoBO1sJ6VEDwpIks Message-ID: <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> Date: Wed, 26 Feb 2020 19:48:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 18:48:55 -0000 Hi, This is a tricky one. I think allowing multiple signature schemes per group can improve security in subtle ways, especially in large groups with potentially diverse clients. I understand part of the "one scheme per group is simpler" argument, but I am not sure it is simpler in practice, since it puts more weight on the choice of the initiators of the group, and might complicate adding group members afterwards. I don't think it is a blocking factor for any analysis either. So I have *a slight preference for allowing multiple signature schemes per group*, from the perspective of facilitating large diverse groups in the future, and the potential local security benefits. But I definitely agree with Richard that this can be a small change later, and doesn't seem to be some fundamental design choice that cannot be reverted/relaxed/tightened later; I also care about progress, so let's pick something for now. Best, Cas On 2/26/20 7:24 PM, Benjamin Beurdouche wrote: > I would strongly prefer one signature scheme for the lifetime of the group. > B. > >> On 26 Feb 2020, at 17:28, Sean Turner wrote: >> >> There seems to be rough consensus (stressing the rough) to go with one scheme per group. By rough consensus, I mean there seems to be a willingness by the group to live with this decision and nobody is super bent out of shape about it. Technically, that’s all we need to move forward, but there are some concerns concerns that since it’s such a small group and there are so few strong voices for the choice that we should give it just a bit more time. So, I am extending this call until 2359 UTC 2 March (i.e., Monday night). >> >> Also, there are really three ciphersuite-related decisions being made, as noted in the email below. >> >> spt >> >>> On Feb 25, 2020, at 13:24, Richard Barnes wrote: >>> >>> I will not be able to make the call tomorrow, so to summarize my opinion on this: >>> >>> * I am OK with merging the current PR >>> * I have a slight preference for *not* including the sig alg in the ciphersuite >>> * The simplicity case for including it seems reasonable, but not dispositive >>> * In any case, I don't care strongly one way or another; I care more about progress >>> * This is an easy change to revert if we change our minds later >>> * Credentials are going to indicate the signature algorithm anyway >>> * So the only difference in spec is whether endpoints check Credential.SigAlgorithm == CipherSuite.SigAlgorithm >>> >>> >>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: >>> Note that the main point of the telecon tomorrow is to address the cipher suite issue. Please take the time to review: >>> - the related PRs: >>> https://github.com/mlswg/mls-protocol/pull/279 >>> https://github.com/mlswg/mls-protocol/pull/307 >>> - the messages in this thread >>> - the issues Britta outlined: >>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing >>> >>> We would like to close this issue out tomorrow. >>> >>> Cheers, >>> >>> spt >>> >>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok wrote: >>>> >>>> Hi Britta, >>>> >>>> I think you sum it up very nicely. There is one (albeit somewhat speculative) >>>> argument why a single ciphersuite per group might actually be beneficial in a >>>> federation context. In the event that there is "global concensus" that a >>>> ciphersuite needs to be deprecated, my expectation would be that a majority of >>>> the federation nodes/application providers would move to ban those ciphersuits, >>>> excluding anyone who would use _exclusively_ that ciphersuite. That would in >>>> turn be a motivation for all other nodes/application providers to catch up as >>>> well. This also means that nodes can't be made (by whatever authority) to use >>>> weak ciphersuites exclusively and still expect to federate with other nodes that >>>> have more sensible policies. >>>> >>>> That's mostly my guess of how the dynamics in such a federated environment >>>> _could_ work, though. Anyone here with some actual experience/expertise they can >>>> share of what the dynamics could be? >>>> >>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just seems a lot >>>> simpler and even in the context of federation, I think that most >>>> nodes/application providers would allow several ciphersuites to begin with, >>>> where not all of them are weak, meaning no one would really be excluded too quickly. >>>> >>>> Cheers, >>>> Konrad >>>> >>>> >>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: >>>>> Under the topic of individual/single signature schemes there is the final issue of federation. In a federated context, groups are no longer under the control of a single application, meaning that we would lose some control in forcing good ciphersuite choices. This could lead to two issues: >>>>> >>>>> 1) MLS would move closer to facing the TLS problem of having old suites supported by edge cases, which in turn weaken the entire group's security. There is always the argument that groups would simply refuse joiners that do not support the current group cipher, but this is not very practical from a usability view. E.g. if everyone using application X refused group members who were using application Y, then the point of federation would be largely defeated. So, either some form of renegotiation is allowed (e.g. export psk) and downgrade becomes more likely, or federation does not work reliably. >>>>> >>>>> 2) Healing would take longer. Since no one application has a master view and control over ciphersuites, upgrading long-lived groups using questionable ciphers could take a significant amount of time (all applications would need to do so in order for the group to upgrade) or alternatively result in kicking group members out of the group (again, possible, but questionable for usability except in extreme cases). Under an individual cipher choice, any one member can choose/upgrade their scheme, allowing for faster adaptability and potential benefits to PCS. >>>>> >>>>> From the above, it seems that a single group cipher makes federation harder/slower/less secure, but I may not have a clear view on how federation would work in this context. Does anyone know whether the above are really concerns or not relevant due to other reasons? >>>>> >>>>> (Note that this is thinking in the long-term context. Obviously we do not want to standardize any cipher choice that is sub-optimal; however any number of things may happen with protocol versioning and cipher breaks over the span of several years.) >>>>> >>>>> Under all the considerations that I have seen so far, the pros and cons on both sides place the individual signature cipher option in the lead. However that lead is small, hence why I have not been arguing for it. The issue of federation could be a deciding factor. If we want federation in the future it is of course better not to build inhibiting factors into MLS now that could undermine either usability or security in such contexts. To make a case to proceed with the single group cipher option, it would be great if someone could provide a convincing argument as to why it would be the best option for usability and security in the federated environment (or preclude a federated use-case altogether). >>>>> >>>>> --- >>>>> >>>>> Britta >>>>> >>>>> >>>>> On 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" wrote: >>>>> >>>>> Hi, >>>>> >>>>> Concerning the use of a single group signature scheme or individual signature schemes, it is probably worthwhile to expand on the consideration points and clarify what security implications we are accepting - in either case. I have listed out some issues in the following Google doc: >>>>> >>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing >>>>> >>>>> I am not making an argument for either case at this point, but pushing this out for discussion and to help us achieve more clarity as to the benefits and consequences of either choice. There are certainly more issues to consider (e.g. ease of implementation, efficiency, etc. in addition to security considerations) and other views - feel free to add them or discuss on the mailing list. >>>>> >>>>> All the best, >>>>> >>>>> Britta >>>>> >>>>> >>>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" wrote: >>>>> >>>>> Hi! >>>>> >>>>> tl;dr: confirming MTI suite selections and rationale for avoiding proliferation >>>>> >>>>> During the F2F Interim in January, the WG discussed cipher suites-related issues. Namely, whether a per-group signature scheme should be driven by the chosen cipher suite, what were the MTI (Mandatory To Implement) cipher suites, and what the actual algorithm should be. >>>>> >>>>> There was rough agreement that there should be one signature scheme per group and that should be driven by the cipher suite. There are, at least, three things to consider: 1) if a potential group member does not support the algorithm, then they will not become a member or the group will need to downgrade; 2) when the group needs/wants to update, it is a flag day; and, 3) the cipher suites will have a similar combinatorial issues as the TLS cipher suites prior to TLS 1.3. The agreement was “rough” because 1) likely has some important implications. >>>>> >>>>> The MLS cipher suites defined were as follows: >>>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >>>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >>>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >>>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >>>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >>>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >>>>> >>>>> At the interim, the consensus was to make the non-NIST suites the MTI. The rationale was that those implementation that need to be NIST compliant will do so regardless of the choice made by the WG. >>>>> >>>>> In looking at the actual cipher suites, it was noted that the 256-bit schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less operation. >>>>> >>>>> To avoid the proliferation of cipher suites, guidance will be provided to be conservative about allocating new code points. The consensus at the interim was that the suites provided were minimal and provided good coverage for the known use cases: >>>>> - (X25519, AES-GCM, Ed25519) - Good for desktop >>>>> - (P-256, AES-GCM, P-256) - Compliance >>>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile >>>>> >>>>> The chairs need to confirm the interim’s consensus on list, so please let the WG know by 2359 UTC 20 February whether you disagree with these choices and why. >>>>> >>>>> NOTE: The final text will obviously be reviewed, but is being composed as part of the following PR: >>>>> https://github.com/mlswg/mls-protocol/pull/279 >>>>> >>>>> NOTE: We combined these cipher suite related consensus points, but if we only come to consensus on some of these we can still incorporate what we do agree on. >>>>> >>>>> Cheers, >>>>> >>>>> Nick and Sean >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> >>>>> >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> >>>>> >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> >>>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Feb 26 10:51:56 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C1C3A1129 for ; Wed, 26 Feb 2020 10:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D9PVegX5MSV for ; Wed, 26 Feb 2020 10:51:45 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id AA30A3A1130 for ; Wed, 26 Feb 2020 10:51:40 -0800 (PST) X-ASG-Debug-ID: 1582743096-0e39454965adb00001-bGA3T6 Received: from mail.nps.edu (synergos.ern.nps.edu [172.20.4.116]) by mule.nps.edu with ESMTP id VlhOC8oRaqSjKmw4; Wed, 26 Feb 2020 10:51:36 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Wed, 26 Feb 2020 10:51:36 -0800 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.56) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Wed, 26 Feb 2020 10:51:36 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EMItBOPg7r3dRYO38FwgXva0HksxnUn/W7GEi2y9DdQ3HVtS2CGwAO69hLkzTwCUT8DCsY+OTIidSHZs1qLDy9EN3A0kSqAI2A07XAe4upHCLtcT9LJjd8pZj+2C7wrXOcSdGoAueXWviLI9nU7BBhkKZnq6lwKj4T2+6L5eS4BAgBc9zCVZR1yRHTf1vB13j83I/R2m5CJZVP93hB3TxY4eJCY8qnKPFdBbhfzbWArNKIjVBdayG/Tk0FnbY1QwlBNC1vsKkOWNtykhsp/kWhMItfl7vxviTIRyh0qfmj/G2smvwfi0PgucD9G0ztJZxQ4etctwEcPdPGCU3nyYNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yu8O1YrjQ6fZ5bFV0S8C55J5HQIf9YrcIUZxpEWyDog=; b=YuV648rmdPvggAtYQ5RUcx3OHyn0vhTYwZj3hpiBv2aSdp4N+oA7o3zrs/Tgc+OfVV8f8M3LF9dckCWlAJfYMpKd44MpSHMU8SqKT67NF5uXELOtDT2/MxoPwvJqYvpY/dTCO+6/pjnXAwTjQYMQtRmJSFBSm+VDqqHvkk5m4jyI7G1JwBzCVOixx6nKF/fVQtpZNcyzDKzbTGX4VsWRdnESMAtko//YLilmlpK2q9Vj3aXJtQ8kjnRPcmBFMTNxToIZcuzhzUYwpJe8wGxy83ZYI600IGgulFDXsJ7gDRATMPd6nVqvWadtfhw7Mbe6rJ2NEI4jPRBJ5kjgV3DI4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3110.namprd13.prod.outlook.com (2603:10b6:a03:187::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.11; Wed, 26 Feb 2020 18:51:33 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 18:51:33 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:187::21] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:187::21 From: "Hale, Britta (CIV)" To: Benjamin Beurdouche CC: ML Messaging Layer Security Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiA//+BbgA= Date: Wed, 26 Feb 2020 18:51:33 +0000 Message-ID: <13647581-208F-449C-9FE3-59FA4B22B58F@nps.edu> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> In-Reply-To: <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [88.203.39.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba76b5d2-285a-4517-c9e6-08d7baece653 x-ms-traffictypediagnostic: BY5PR13MB3110: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(376002)(136003)(366004)(39850400004)(199004)(189003)(4326008)(53546011)(6506007)(2616005)(26005)(966005)(6486002)(6916009)(5660300002)(6512007)(86362001)(478600001)(316002)(786003)(36756003)(66446008)(64756008)(66556008)(66476007)(91956017)(76116006)(186003)(71200400001)(75432002)(66946007)(8676002)(30864003)(81166006)(81156014)(2906002)(33656002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3110; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KhBpm40bom81Fmw3xgXnTZljbtJ4uk6UreOSQ1hlJXUhL0sNXlTmUDmVMJE0D3gHpQyy8WMxzUGohuDz6tW+iy8jbour5Y5j0kD5pHiJfSdBbpgWEjoBhDMzDEJLoZYx9Z//RNvQjzch7nf35AMP3MJpzI4SV4O437WIqbtANWK23XYm5vocIDDH12xMgkzjPuKDc6apKuhYS0ZIwE/JO8/tPvcxmyadu4xW3pv1KVMIY64II8EQ7BWrlw/HvK5c/mShRbz1okaNoy9cETbNSVkaA7L6Zej3Mr+QfmJ86Y0yuoWtpIUhNPrsIGHYGJWIdxolBmQYBHTCWjxfXwZiUM67jb0qnsdy74xMjjxf7tRryrFXhzy5ZSLWXCQ/2Ff7PG4LqHKEGWZPDHJN+kc/5ugcLgpBqBGkCO5ESaYDAadMF874xAmroXWuylySaXclE7j7zuq+Ic3a+d2R6bhYTdpgvlxT+lDT7iZpefQ9au+35rKKVDV1cQOHWgEoyz7+ASi2rYAtTh6zF1bGpyWidg== x-ms-exchange-antispam-messagedata: F9BEAYeqlmyGvAQv1d2lZQ++R91NQ9CHs5kJ4w9eQGnaYE7CJ2e38X8fq3PTfIujvYd3G7N4QYD0b7AMOoKA1ZILwEIZpbE2cf02S319HusPr2UcMh7y0XXIcUSBL4RmkJVn98BhopRX2jS5Iup/5A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9AB83B899597F946943568D48944CC0D@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ba76b5d2-285a-4517-c9e6-08d7baece653 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 18:51:33.3524 (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: 1o/nszUaPaqpqh60dy6uqXyxUSbr7DCKhkvk0P05iU9UEd8/jv0V8Q01DNNEL8kLnK6VG5qZP/QN4eCDTjgvMw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3110 X-OriginatorOrg: nps.edu X-Barracuda-Connect: synergos.ern.nps.edu[172.20.4.116] X-Barracuda-Start-Time: 1582743096 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 13581 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80277 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 18:51:55 -0000 VGhhbmsgeW91IEJlbmphbWluIGZvciBzcGVha2luZyB1cC4gSWYgd2UgZ28gZm9yd2FyZCB3aXRo IGVpdGhlciBvcHRpb24gaXQgaXMgZ29vZCB0byBoYXZlIGEgZG9jdW1lbnRlZCBiYXNpcyBmb3Ig ZG9pbmcgc28gb24gdGhlIG1haWxpbmdsaXN0LCBhbmQgdW50aWwgbm93IHdlIGhhdmUgYXJndW1l bnRzIHdoaWNoIHN1cHBvcnQgaW5kaXZpZHVhbCBzY2hlbWVzLCBvciAibm8gc3Ryb25nIHByZWZl cmVuY2UiLiBBcyB0aGVyZSB3ZXJlIG5vIG9iamVjdGlvbnMgdG8gdGhlIHN0YXRlZCByZWFzb25z IHN1cHBvcnRpbmcgaW5kaXZpZHVhbCBzY2hlbWVzLCB0aGUgcm91Z2ggY29uc2Vuc3VzIHVudGls IG5vdyB3YXMgYXJndWFibHkgZm9yIHRoYXQ7IHB1dHRpbmcgZm9yd2FyZCBhIGNsZWFyIHByZWZl cmVuY2UgZ2l2ZXMgdXMgZ3JvdW5kcyBmb3Igbm90IGRpc21pc3NpbmcgdGhlIGdyb3VwIG9wdGlv bi4gRWFzZSBvZiBpbXBsZW1lbnRhdGlvbiB3aXRob3V0IGVycm9yLCBlZmZpY2llbmN5LCBvciBz ZWN1cml0eSBhcmUgYWxsIHJlYXNvbmFibGUgYXJndW1lbnRzIGZvciBjaG9vc2luZyBvbmUgb2Yg dGhlc2Ugb3IgdGhlIG90aGVyIC0gaGF2aW5nIGFuIGV4aXN0aW5nIFBSIHRvIGZvbGxvdyBzaG91 bGQgbm90IGJlIG91ciBkZWNpc2lvbiBtZXRyaWMuIFNvIGl0IGlzIGdvb2QgdG8gc2VlIGEgY2xl YXIgc3RhdGVtZW50IG9uIHRoZSBtYWlsaW5nbGlzdC4gDQoNCkdpdmVuIHRoZSBwb2ludHMgb3V0 bGluZWQgaW4gdGhlIGRvY3VtZW50LCB0aGUgcG9zaXRpdmVzIGFuZCBuZWdhdGl2ZXMgb2YgYm90 aCBzdWdnZXN0IHRoYXQgdGhlIGluZGl2aWR1YWwgc2lnbmF0dXJlIG9wdGlvbiBtYXkgYmUgYmV0 dGVyIGZvciBzZWN1cml0eS4gSG93ZXZlciwgaWYgdGhlcmUgaXMgZXZlbiBvbmUgc3Ryb25nIGFy Z3VtZW50IGZvciBoYXZpbmcgYSBzaW5nbGUgZ3JvdXAgc2NoZW1lLCB0aGF0IGlzIG5vdCBhIGNv bXBhcmFibGUgdW5kZXIgdGhlIGluZGl2aWR1YWwgb3B0aW9uLCB0aGVuIHRoYXQgbWF5IGJlIGEg ZmFpciBiYXNpcyBmb3IgdGhlIHNpbmdsZSBncm91cCBzY2hlbWUgY2hvaWNlLiANCkNhbiB5b3Ug ZGVzY3JpYmUgdGhlIHNlY3VyaXR5IChvciBlZmZpY2llbmN5L2ltcGxlbWVudGF0aW9uKSBmYWN0 b3JzIHRoYXQgbGVhZCB0byB5b3VyIHByZWZlcmVuY2U/DQoNCkJyaXR0YSANCg0KDQoNCu+7v09u IDIvMjYvMjAsIDc6MjUgUE0sICJNTFMgb24gYmVoYWxmIG9mIEJlbmphbWluIEJldXJkb3VjaGUi IDxtbHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYmVuamFtaW4uYmV1cmRvdWNoZUBp bnJpYS5mcj4gd3JvdGU6DQoNCiAgICBJIHdvdWxkIHN0cm9uZ2x5IHByZWZlciBvbmUgc2lnbmF0 dXJlIHNjaGVtZSBmb3IgdGhlIGxpZmV0aW1lIG9mIHRoZSBncm91cC4NCiAgICBCLg0KICAgIA0K ICAgID4gT24gMjYgRmViIDIwMjAsIGF0IDE3OjI4LCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5j b20+IHdyb3RlOg0KICAgID4gDQogICAgPiBUaGVyZSBzZWVtcyB0byBiZSByb3VnaCBjb25zZW5z dXMgKHN0cmVzc2luZyB0aGUgcm91Z2gpIHRvIGdvIHdpdGggb25lIHNjaGVtZSBwZXIgZ3JvdXAu IEJ5IHJvdWdoIGNvbnNlbnN1cywgSSBtZWFuIHRoZXJlIHNlZW1zIHRvIGJlIGEgd2lsbGluZ25l c3MgYnkgdGhlIGdyb3VwIHRvIGxpdmUgd2l0aCB0aGlzIGRlY2lzaW9uIGFuZCBub2JvZHkgaXMg c3VwZXIgYmVudCBvdXQgb2Ygc2hhcGUgYWJvdXQgaXQuIFRlY2huaWNhbGx5LCB0aGF04oCZcyBh bGwgd2UgbmVlZCB0byBtb3ZlIGZvcndhcmQsIGJ1dCB0aGVyZSBhcmUgc29tZSBjb25jZXJucyBj b25jZXJucyB0aGF0IHNpbmNlIGl04oCZcyBzdWNoIGEgc21hbGwgZ3JvdXAgYW5kIHRoZXJlIGFy ZSBzbyBmZXcgc3Ryb25nIHZvaWNlcyBmb3IgdGhlIGNob2ljZSB0aGF0IHdlIHNob3VsZCBnaXZl IGl0IGp1c3QgYSBiaXQgbW9yZSB0aW1lLiBTbywgSSBhbSBleHRlbmRpbmcgdGhpcyBjYWxsIHVu dGlsIDIzNTkgVVRDIDIgTWFyY2ggKGkuZS4sIE1vbmRheSBuaWdodCkuDQogICAgPiANCiAgICA+ IEFsc28sIHRoZXJlIGFyZSByZWFsbHkgdGhyZWUgY2lwaGVyc3VpdGUtcmVsYXRlZCBkZWNpc2lv bnMgYmVpbmcgbWFkZSwgYXMgbm90ZWQgaW4gdGhlIGVtYWlsIGJlbG93Lg0KICAgID4gDQogICAg PiBzcHQNCiAgICA+IA0KICAgID4+IE9uIEZlYiAyNSwgMjAyMCwgYXQgMTM6MjQsIFJpY2hhcmQg QmFybmVzIDxybGJAaXB2LnN4PiB3cm90ZToNCiAgICA+PiANCiAgICA+PiBJIHdpbGwgbm90IGJl IGFibGUgdG8gbWFrZSB0aGUgY2FsbCB0b21vcnJvdywgc28gdG8gc3VtbWFyaXplIG15IG9waW5p b24gb24gdGhpczoNCiAgICA+PiANCiAgICA+PiAqIEkgYW0gT0sgd2l0aCBtZXJnaW5nIHRoZSBj dXJyZW50IFBSDQogICAgPj4gICogSSBoYXZlIGEgc2xpZ2h0IHByZWZlcmVuY2UgZm9yICpub3Qq IGluY2x1ZGluZyB0aGUgc2lnIGFsZyBpbiB0aGUgY2lwaGVyc3VpdGUNCiAgICA+PiAgKiBUaGUg c2ltcGxpY2l0eSBjYXNlIGZvciBpbmNsdWRpbmcgaXQgc2VlbXMgcmVhc29uYWJsZSwgYnV0IG5v dCBkaXNwb3NpdGl2ZQ0KICAgID4+ICAqIEluIGFueSBjYXNlLCBJIGRvbid0IGNhcmUgc3Ryb25n bHkgb25lIHdheSBvciBhbm90aGVyOyBJIGNhcmUgbW9yZSBhYm91dCBwcm9ncmVzcw0KICAgID4+ ICogVGhpcyBpcyBhbiBlYXN5IGNoYW5nZSB0byByZXZlcnQgaWYgd2UgY2hhbmdlIG91ciBtaW5k cyBsYXRlcg0KICAgID4+ICAqIENyZWRlbnRpYWxzIGFyZSBnb2luZyB0byBpbmRpY2F0ZSB0aGUg c2lnbmF0dXJlIGFsZ29yaXRobSBhbnl3YXkNCiAgICA+PiAgKiBTbyB0aGUgb25seSBkaWZmZXJl bmNlIGluIHNwZWMgaXMgd2hldGhlciBlbmRwb2ludHMgY2hlY2sgQ3JlZGVudGlhbC5TaWdBbGdv cml0aG0gPT0gQ2lwaGVyU3VpdGUuU2lnQWxnb3JpdGhtDQogICAgPj4gDQogICAgPj4gDQogICAg Pj4gT24gVHVlLCBGZWIgMjUsIDIwMjAgYXQgMTI6NDMgUE0gU2VhbiBUdXJuZXIgPHNlYW5Ac24z cmQuY29tPiB3cm90ZToNCiAgICA+PiBOb3RlIHRoYXQgdGhlIG1haW4gcG9pbnQgb2YgdGhlIHRl bGVjb24gdG9tb3Jyb3cgaXMgdG8gYWRkcmVzcyB0aGUgY2lwaGVyIHN1aXRlIGlzc3VlLiAgUGxl YXNlIHRha2UgdGhlIHRpbWUgdG8gcmV2aWV3Og0KICAgID4+IC0gdGhlIHJlbGF0ZWQgUFJzOg0K ICAgID4+IGh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJvdG9jb2wvcHVsbC8yNzkNCiAg ICA+PiBodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwvMzA3DQogICAg Pj4gLSB0aGUgbWVzc2FnZXMgaW4gdGhpcyB0aHJlYWQNCiAgICA+PiAtIHRoZSBpc3N1ZXMgQnJp dHRhIG91dGxpbmVkOg0KICAgID4+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2Qv MVpEczRLR3AwXzZrcFFacFJKX3Q0a1ZsbWdBOTRfcE10ZFNpbElkRkt3MTQvZWRpdD91c3A9c2hh cmluZw0KICAgID4+IA0KICAgID4+IFdlIHdvdWxkIGxpa2UgdG8gY2xvc2UgdGhpcyBpc3N1ZSBv dXQgdG9tb3Jyb3cuDQogICAgPj4gDQogICAgPj4gQ2hlZXJzLA0KICAgID4+IA0KICAgID4+IHNw dA0KICAgID4+IA0KICAgID4+PiBPbiBGZWIgMTksIDIwMjAsIGF0IDAxOjA5LCBLb25yYWQgS29o YnJvayA8a29ucmFkLmtvaGJyb2tAZGF0YXNocmluZS5kZT4gd3JvdGU6DQogICAgPj4+IA0KICAg ID4+PiBIaSBCcml0dGEsDQogICAgPj4+IA0KICAgID4+PiBJIHRoaW5rIHlvdSBzdW0gaXQgdXAg dmVyeSBuaWNlbHkuIFRoZXJlIGlzIG9uZSAoYWxiZWl0IHNvbWV3aGF0IHNwZWN1bGF0aXZlKQ0K ICAgID4+PiBhcmd1bWVudCB3aHkgYSBzaW5nbGUgY2lwaGVyc3VpdGUgcGVyIGdyb3VwIG1pZ2h0 IGFjdHVhbGx5IGJlIGJlbmVmaWNpYWwgaW4gYQ0KICAgID4+PiBmZWRlcmF0aW9uIGNvbnRleHQu IEluIHRoZSBldmVudCB0aGF0IHRoZXJlIGlzICJnbG9iYWwgY29uY2Vuc3VzIiB0aGF0IGENCiAg ICA+Pj4gY2lwaGVyc3VpdGUgbmVlZHMgdG8gYmUgZGVwcmVjYXRlZCwgbXkgZXhwZWN0YXRpb24g d291bGQgYmUgdGhhdCBhIG1ham9yaXR5IG9mDQogICAgPj4+IHRoZSBmZWRlcmF0aW9uIG5vZGVz L2FwcGxpY2F0aW9uIHByb3ZpZGVycyB3b3VsZCBtb3ZlIHRvIGJhbiB0aG9zZSBjaXBoZXJzdWl0 cywNCiAgICA+Pj4gZXhjbHVkaW5nIGFueW9uZSB3aG8gd291bGQgdXNlIF9leGNsdXNpdmVseV8g dGhhdCBjaXBoZXJzdWl0ZS4gVGhhdCB3b3VsZCBpbg0KICAgID4+PiB0dXJuIGJlIGEgbW90aXZh dGlvbiBmb3IgYWxsIG90aGVyIG5vZGVzL2FwcGxpY2F0aW9uIHByb3ZpZGVycyB0byBjYXRjaCB1 cCBhcw0KICAgID4+PiB3ZWxsLiBUaGlzIGFsc28gbWVhbnMgdGhhdCBub2RlcyBjYW4ndCBiZSBt YWRlIChieSB3aGF0ZXZlciBhdXRob3JpdHkpIHRvIHVzZQ0KICAgID4+PiB3ZWFrIGNpcGhlcnN1 aXRlcyBleGNsdXNpdmVseSBhbmQgc3RpbGwgZXhwZWN0IHRvIGZlZGVyYXRlIHdpdGggb3RoZXIg bm9kZXMgdGhhdA0KICAgID4+PiBoYXZlIG1vcmUgc2Vuc2libGUgcG9saWNpZXMuDQogICAgPj4+ IA0KICAgID4+PiBUaGF0J3MgbW9zdGx5IG15IGd1ZXNzIG9mIGhvdyB0aGUgZHluYW1pY3MgaW4g c3VjaCBhIGZlZGVyYXRlZCBlbnZpcm9ubWVudA0KICAgID4+PiBfY291bGRfIHdvcmssIHRob3Vn aC4gQW55b25lIGhlcmUgd2l0aCBzb21lIGFjdHVhbCBleHBlcmllbmNlL2V4cGVydGlzZSB0aGV5 IGNhbg0KICAgID4+PiBzaGFyZSBvZiB3aGF0IHRoZSBkeW5hbWljcyBjb3VsZCBiZT8NCiAgICA+ Pj4gDQogICAgPj4+IE92ZXJhbGwsIEkgdGhpbmsgSSdtIGluIGZhdm9yIG9mIG9uZS1jaXBoZXJz dWl0ZS1wZXItZ3JvdXAuIEl0IGp1c3Qgc2VlbXMgYSBsb3QNCiAgICA+Pj4gc2ltcGxlciBhbmQg ZXZlbiBpbiB0aGUgY29udGV4dCBvZiBmZWRlcmF0aW9uLCBJIHRoaW5rIHRoYXQgbW9zdA0KICAg ID4+PiBub2Rlcy9hcHBsaWNhdGlvbiBwcm92aWRlcnMgd291bGQgYWxsb3cgc2V2ZXJhbCBjaXBo ZXJzdWl0ZXMgdG8gYmVnaW4gd2l0aCwNCiAgICA+Pj4gd2hlcmUgbm90IGFsbCBvZiB0aGVtIGFy ZSB3ZWFrLCBtZWFuaW5nIG5vIG9uZSB3b3VsZCByZWFsbHkgYmUgZXhjbHVkZWQgdG9vIHF1aWNr bHkuDQogICAgPj4+IA0KICAgID4+PiBDaGVlcnMsDQogICAgPj4+IEtvbnJhZA0KICAgID4+PiAN CiAgICA+Pj4gDQogICAgPj4+IE9uIDE4LjAyLjIwIDIxOjAwLCBIYWxlLCBCcml0dGEgKENJVikg d3JvdGU6DQogICAgPj4+PiBVbmRlciB0aGUgdG9waWMgb2YgaW5kaXZpZHVhbC9zaW5nbGUgc2ln bmF0dXJlIHNjaGVtZXMgdGhlcmUgaXMgdGhlIGZpbmFsIGlzc3VlIG9mIGZlZGVyYXRpb24uIElu IGEgZmVkZXJhdGVkIGNvbnRleHQsIGdyb3VwcyBhcmUgbm8gbG9uZ2VyIHVuZGVyIHRoZSBjb250 cm9sIG9mIGEgc2luZ2xlIGFwcGxpY2F0aW9uLCBtZWFuaW5nIHRoYXQgd2Ugd291bGQgbG9zZSBz b21lIGNvbnRyb2wgaW4gZm9yY2luZyBnb29kIGNpcGhlcnN1aXRlIGNob2ljZXMuIFRoaXMgY291 bGQgbGVhZCB0byB0d28gaXNzdWVzOg0KICAgID4+Pj4gDQogICAgPj4+PiAxKSBNTFMgd291bGQg bW92ZSBjbG9zZXIgdG8gZmFjaW5nIHRoZSBUTFMgcHJvYmxlbSBvZiBoYXZpbmcgb2xkIHN1aXRl cyBzdXBwb3J0ZWQgYnkgZWRnZSBjYXNlcywgd2hpY2ggaW4gdHVybiB3ZWFrZW4gdGhlIGVudGly ZSBncm91cCdzIHNlY3VyaXR5LiBUaGVyZSBpcyBhbHdheXMgdGhlIGFyZ3VtZW50IHRoYXQgZ3Jv dXBzIHdvdWxkIHNpbXBseSByZWZ1c2Ugam9pbmVycyB0aGF0IGRvIG5vdCBzdXBwb3J0IHRoZSBj dXJyZW50IGdyb3VwIGNpcGhlciwgYnV0IHRoaXMgaXMgbm90IHZlcnkgcHJhY3RpY2FsIGZyb20g YSB1c2FiaWxpdHkgdmlldy4gRS5nLiBpZiBldmVyeW9uZSB1c2luZyBhcHBsaWNhdGlvbiBYIHJl ZnVzZWQgZ3JvdXAgbWVtYmVycyB3aG8gd2VyZSB1c2luZyBhcHBsaWNhdGlvbiBZLCB0aGVuIHRo ZSBwb2ludCBvZiBmZWRlcmF0aW9uIHdvdWxkIGJlIGxhcmdlbHkgZGVmZWF0ZWQuIFNvLCBlaXRo ZXIgc29tZSBmb3JtIG9mIHJlbmVnb3RpYXRpb24gaXMgYWxsb3dlZCAoZS5nLiBleHBvcnQgcHNr KSBhbmQgZG93bmdyYWRlIGJlY29tZXMgbW9yZSBsaWtlbHksIG9yIGZlZGVyYXRpb24gZG9lcyBu b3Qgd29yayByZWxpYWJseS4gDQogICAgPj4+PiANCiAgICA+Pj4+IDIpIEhlYWxpbmcgd291bGQg dGFrZSBsb25nZXIuIFNpbmNlIG5vIG9uZSBhcHBsaWNhdGlvbiBoYXMgYSBtYXN0ZXIgdmlldyBh bmQgY29udHJvbCBvdmVyIGNpcGhlcnN1aXRlcywgdXBncmFkaW5nIGxvbmctbGl2ZWQgZ3JvdXBz IHVzaW5nIHF1ZXN0aW9uYWJsZSBjaXBoZXJzIGNvdWxkIHRha2UgYSBzaWduaWZpY2FudCBhbW91 bnQgb2YgdGltZSAoYWxsIGFwcGxpY2F0aW9ucyB3b3VsZCBuZWVkIHRvIGRvIHNvIGluIG9yZGVy IGZvciB0aGUgZ3JvdXAgdG8gdXBncmFkZSkgb3IgYWx0ZXJuYXRpdmVseSByZXN1bHQgaW4ga2lj a2luZyBncm91cCBtZW1iZXJzIG91dCBvZiB0aGUgZ3JvdXAgKGFnYWluLCBwb3NzaWJsZSwgYnV0 IHF1ZXN0aW9uYWJsZSBmb3IgdXNhYmlsaXR5IGV4Y2VwdCBpbiBleHRyZW1lIGNhc2VzKS4gVW5k ZXIgYW4gaW5kaXZpZHVhbCBjaXBoZXIgY2hvaWNlLCBhbnkgb25lIG1lbWJlciBjYW4gY2hvb3Nl L3VwZ3JhZGUgdGhlaXIgc2NoZW1lLCBhbGxvd2luZyBmb3IgZmFzdGVyIGFkYXB0YWJpbGl0eSBh bmQgcG90ZW50aWFsIGJlbmVmaXRzIHRvIFBDUy4gDQogICAgPj4+PiANCiAgICA+Pj4+IEZyb20g dGhlIGFib3ZlLCBpdCBzZWVtcyB0aGF0IGEgc2luZ2xlIGdyb3VwIGNpcGhlciBtYWtlcyBmZWRl cmF0aW9uIGhhcmRlci9zbG93ZXIvbGVzcyBzZWN1cmUsIGJ1dCBJIG1heSBub3QgaGF2ZSBhIGNs ZWFyIHZpZXcgb24gaG93IGZlZGVyYXRpb24gd291bGQgd29yayBpbiB0aGlzIGNvbnRleHQuIERv ZXMgYW55b25lIGtub3cgd2hldGhlciB0aGUgYWJvdmUgYXJlIHJlYWxseSBjb25jZXJucyBvciBu b3QgcmVsZXZhbnQgZHVlIHRvIG90aGVyIHJlYXNvbnM/IA0KICAgID4+Pj4gDQogICAgPj4+PiAo Tm90ZSB0aGF0IHRoaXMgaXMgdGhpbmtpbmcgaW4gdGhlIGxvbmctdGVybSBjb250ZXh0LiBPYnZp b3VzbHkgd2UgZG8gbm90IHdhbnQgdG8gc3RhbmRhcmRpemUgYW55IGNpcGhlciBjaG9pY2UgdGhh dCBpcyBzdWItb3B0aW1hbDsgaG93ZXZlciBhbnkgbnVtYmVyIG9mIHRoaW5ncyBtYXkgaGFwcGVu IHdpdGggcHJvdG9jb2wgdmVyc2lvbmluZyBhbmQgY2lwaGVyIGJyZWFrcyBvdmVyIHRoZSBzcGFu IG9mIHNldmVyYWwgeWVhcnMuKQ0KICAgID4+Pj4gDQogICAgPj4+PiBVbmRlciBhbGwgdGhlIGNv bnNpZGVyYXRpb25zIHRoYXQgSSBoYXZlIHNlZW4gc28gZmFyLCB0aGUgcHJvcyBhbmQgY29ucyBv biBib3RoIHNpZGVzIHBsYWNlIHRoZSBpbmRpdmlkdWFsIHNpZ25hdHVyZSBjaXBoZXIgb3B0aW9u IGluIHRoZSBsZWFkLiBIb3dldmVyIHRoYXQgbGVhZCBpcyBzbWFsbCwgaGVuY2Ugd2h5IEkgaGF2 ZSBub3QgYmVlbiBhcmd1aW5nIGZvciBpdC4gVGhlIGlzc3VlIG9mIGZlZGVyYXRpb24gY291bGQg YmUgYSBkZWNpZGluZyBmYWN0b3IuIElmIHdlIHdhbnQgZmVkZXJhdGlvbiBpbiB0aGUgZnV0dXJl IGl0IGlzIG9mIGNvdXJzZSBiZXR0ZXIgbm90IHRvIGJ1aWxkIGluaGliaXRpbmcgZmFjdG9ycyBp bnRvIE1MUyBub3cgdGhhdCBjb3VsZCB1bmRlcm1pbmUgZWl0aGVyIHVzYWJpbGl0eSBvciBzZWN1 cml0eSBpbiBzdWNoIGNvbnRleHRzLiBUbyBtYWtlIGEgY2FzZSB0byBwcm9jZWVkIHdpdGggdGhl IHNpbmdsZSBncm91cCBjaXBoZXIgb3B0aW9uLCBpdCB3b3VsZCBiZSBncmVhdCBpZiBzb21lb25l IGNvdWxkIHByb3ZpZGUgYSBjb252aW5jaW5nIGFyZ3VtZW50IGFzIHRvIHdoeSBpdCB3b3VsZCBi ZSB0aGUgYmVzdCBvcHRpb24gZm9yIHVzYWJpbGl0eSBhbmQgc2VjdXJpdHkgaW4gdGhlIGZlZGVy YXRlZCBlbnZpcm9ubWVudCAob3IgcHJlY2x1ZGUgYSBmZWRlcmF0ZWQgdXNlLWNhc2UgYWx0b2dl dGhlcikuDQogICAgPj4+PiANCiAgICA+Pj4+IC0tLQ0KICAgID4+Pj4gDQogICAgPj4+PiBCcml0 dGEgDQogICAgPj4+PiANCiAgICA+Pj4+IA0KICAgID4+Pj4gT24gMi8xMi8yMCwgODowMSBBTSwg Ik1MUyBvbiBiZWhhbGYgb2YgSGFsZSwgQnJpdHRhIChDSVYpIiA8bWxzLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGJyaXR0YS5oYWxlQG5wcy5lZHU+IHdyb3RlOg0KICAgID4+Pj4gDQog ICAgPj4+PiAgIEhpLA0KICAgID4+Pj4gDQogICAgPj4+PiAgIENvbmNlcm5pbmcgdGhlIHVzZSBv ZiBhIHNpbmdsZSBncm91cCBzaWduYXR1cmUgc2NoZW1lIG9yIGluZGl2aWR1YWwgc2lnbmF0dXJl IHNjaGVtZXMsIGl0IGlzIHByb2JhYmx5IHdvcnRod2hpbGUgdG8gZXhwYW5kIG9uIHRoZSBjb25z aWRlcmF0aW9uIHBvaW50cyBhbmQgY2xhcmlmeSB3aGF0IHNlY3VyaXR5IGltcGxpY2F0aW9ucyB3 ZSBhcmUgYWNjZXB0aW5nIC0gaW4gZWl0aGVyIGNhc2UuIEkgaGF2ZSBsaXN0ZWQgb3V0IHNvbWUg aXNzdWVzIGluIHRoZSBmb2xsb3dpbmcgR29vZ2xlIGRvYzoNCiAgICA+Pj4+IA0KICAgID4+Pj4g ICBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzFaRHM0S0dwMF82a3BRWnBSSl90 NGtWbG1nQTk0X3BNdGRTaWxJZEZLdzE0L2VkaXQ/dXNwPXNoYXJpbmcNCiAgICA+Pj4+IA0KICAg ID4+Pj4gICBJIGFtIG5vdCBtYWtpbmcgYW4gYXJndW1lbnQgZm9yIGVpdGhlciBjYXNlIGF0IHRo aXMgcG9pbnQsIGJ1dCBwdXNoaW5nIHRoaXMgb3V0IGZvciBkaXNjdXNzaW9uIGFuZCB0byBoZWxw IHVzIGFjaGlldmUgbW9yZSBjbGFyaXR5IGFzIHRvIHRoZSBiZW5lZml0cyBhbmQgY29uc2VxdWVu Y2VzIG9mIGVpdGhlciBjaG9pY2UuIFRoZXJlIGFyZSBjZXJ0YWlubHkgbW9yZSBpc3N1ZXMgdG8g Y29uc2lkZXIgKGUuZy4gZWFzZSBvZiBpbXBsZW1lbnRhdGlvbiwgZWZmaWNpZW5jeSwgZXRjLiBp biBhZGRpdGlvbiB0byBzZWN1cml0eSBjb25zaWRlcmF0aW9ucykgYW5kIG90aGVyIHZpZXdzIC0g ZmVlbCBmcmVlIHRvIGFkZCB0aGVtIG9yIGRpc2N1c3Mgb24gdGhlIG1haWxpbmcgbGlzdC4gDQog ICAgPj4+PiANCiAgICA+Pj4+ICAgQWxsIHRoZSBiZXN0LA0KICAgID4+Pj4gDQogICAgPj4+PiAg IEJyaXR0YSANCiAgICA+Pj4+IA0KICAgID4+Pj4gDQogICAgPj4+PiAgIE9uIDIvNi8yMCwgODox MSBBTSwgIk1MUyBvbiBiZWhhbGYgb2YgU2VhbiBUdXJuZXIiIDxtbHMtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2Ygc2VhbkBzbjNyZC5jb20+IHdyb3RlOg0KICAgID4+Pj4gDQogICAgPj4+ PiAgICAgICBIaSENCiAgICA+Pj4+IA0KICAgID4+Pj4gICAgICAgdGw7ZHI6IGNvbmZpcm1pbmcg TVRJIHN1aXRlIHNlbGVjdGlvbnMgYW5kIHJhdGlvbmFsZSBmb3IgYXZvaWRpbmcgcHJvbGlmZXJh dGlvbg0KICAgID4+Pj4gDQogICAgPj4+PiAgICAgICBEdXJpbmcgdGhlIEYyRiBJbnRlcmltIGlu IEphbnVhcnksIHRoZSBXRyBkaXNjdXNzZWQgY2lwaGVyIHN1aXRlcy1yZWxhdGVkIGlzc3Vlcy4g TmFtZWx5LCB3aGV0aGVyIGEgcGVyLWdyb3VwIHNpZ25hdHVyZSBzY2hlbWUgc2hvdWxkIGJlIGRy aXZlbiBieSB0aGUgY2hvc2VuIGNpcGhlciBzdWl0ZSwgd2hhdCB3ZXJlIHRoZSBNVEkgKE1hbmRh dG9yeSBUbyBJbXBsZW1lbnQpIGNpcGhlciBzdWl0ZXMsIGFuZCB3aGF0IHRoZSBhY3R1YWwgYWxn b3JpdGhtIHNob3VsZCBiZS4NCiAgICA+Pj4+IA0KICAgID4+Pj4gICAgICAgVGhlcmUgd2FzIHJv dWdoIGFncmVlbWVudCB0aGF0IHRoZXJlIHNob3VsZCBiZSBvbmUgc2lnbmF0dXJlIHNjaGVtZSBw ZXIgZ3JvdXAgYW5kIHRoYXQgc2hvdWxkIGJlIGRyaXZlbiBieSB0aGUgY2lwaGVyIHN1aXRlLiBU aGVyZSBhcmUsIGF0IGxlYXN0LCB0aHJlZSB0aGluZ3MgdG8gY29uc2lkZXI6IDEpIGlmIGEgcG90 ZW50aWFsIGdyb3VwIG1lbWJlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBhbGdvcml0aG0sIHRoZW4g dGhleSB3aWxsIG5vdCBiZWNvbWUgYSBtZW1iZXIgb3IgdGhlIGdyb3VwIHdpbGwgbmVlZCB0byBk b3duZ3JhZGU7IDIpIHdoZW4gdGhlIGdyb3VwIG5lZWRzL3dhbnRzIHRvIHVwZGF0ZSwgaXQgaXMg YSBmbGFnIGRheTsgYW5kLCAzKSB0aGUgY2lwaGVyIHN1aXRlcyB3aWxsIGhhdmUgYSBzaW1pbGFy IGNvbWJpbmF0b3JpYWwgaXNzdWVzIGFzIHRoZSBUTFMgY2lwaGVyIHN1aXRlcyBwcmlvciB0byBU TFMgMS4zLiBUaGUgYWdyZWVtZW50IHdhcyDigJxyb3VnaOKAnSBiZWNhdXNlIDEpIGxpa2VseSBo YXMgc29tZSBpbXBvcnRhbnQgaW1wbGljYXRpb25zLg0KICAgID4+Pj4gDQogICAgPj4+PiAgICAg ICBUaGUgTUxTIGNpcGhlciBzdWl0ZXMgZGVmaW5lZCB3ZXJlIGFzIGZvbGxvd3M6IA0KICAgID4+ Pj4gICAgICAgLSBNTFMxMF8xMjhfSFBLRVgyNTUxOV9BRVMxMjhHQ01fU0hBMjU2X0VkMjU1MTkN CiAgICA+Pj4+ICAgICAgIC0gTUxTMTBfMTI4X0hQS0VQMjU2X0FFUzEyOEdDTV9TSEEyNTZfUDI1 Ng0KICAgID4+Pj4gICAgICAgLSBNTFMxMF8xMjhfSFBLRVgyNTUxOV9DSEFDSEEyMFBPTFkxMzA1 X1NIQTI1Nl9FZDI1NTE5DQogICAgPj4+PiAgICAgICAtIE1MUzEwXzI1Nl9IUEtFWDQ0OF9BRVMy NTZHQ01fU0hBMzg0X0VkNDQ4DQogICAgPj4+PiAgICAgICAtIE1MUzEwXzI1Nl9IUEtFUDUyMV9B RVMyNTZHQ01fU0hBMzg0X1A1MjENCiAgICA+Pj4+ICAgICAgIC0gTUxTMTBfMjU2X0hQS0VYNDQ4 X0NIQUNIQTIwUE9MWTEzMDVfU0hBMzg0X0VkNDQ4DQogICAgPj4+PiANCiAgICA+Pj4+ICAgICAg IEF0IHRoZSBpbnRlcmltLCB0aGUgY29uc2Vuc3VzIHdhcyB0byBtYWtlIHRoZSBub24tTklTVCBz dWl0ZXMgdGhlIE1USS4gIFRoZSByYXRpb25hbGUgd2FzIHRoYXQgdGhvc2UgaW1wbGVtZW50YXRp b24gdGhhdCBuZWVkIHRvIGJlIE5JU1QgY29tcGxpYW50IHdpbGwgZG8gc28gcmVnYXJkbGVzcyBv ZiB0aGUgY2hvaWNlIG1hZGUgYnkgdGhlIFdHLg0KICAgID4+Pj4gDQogICAgPj4+PiAgICAgICBJ biBsb29raW5nIGF0IHRoZSBhY3R1YWwgY2lwaGVyIHN1aXRlcywgaXQgd2FzIG5vdGVkIHRoYXQg dGhlIDI1Ni1iaXQgc2NoZW1lcyB0aGUgU0hBIHNob3VsZCBiZSBTSEEtNTEyLiBUaGUgcmF0aW9u YWxlIGFncmVlZCB3YXMgdGhhdCBTSEEtMzg0IGlzIFNIQS01MTIgY3V0IGluIGhhbGYsIHNvIGp1 c3QgZG8gU0hBLTUxMiBiZWNhdXNlIGl0IGlzIG9uZSBsZXNzIG9wZXJhdGlvbi4NCiAgICA+Pj4+ IA0KICAgID4+Pj4gICAgICAgVG8gYXZvaWQgdGhlIHByb2xpZmVyYXRpb24gb2YgY2lwaGVyIHN1 aXRlcywgZ3VpZGFuY2Ugd2lsbCBiZSBwcm92aWRlZCB0byBiZSBjb25zZXJ2YXRpdmUgYWJvdXQg YWxsb2NhdGluZyBuZXcgY29kZSBwb2ludHMuIFRoZSBjb25zZW5zdXMgYXQgdGhlIGludGVyaW0g d2FzIHRoYXQgdGhlIHN1aXRlcyBwcm92aWRlZCB3ZXJlIG1pbmltYWwgYW5kIHByb3ZpZGVkIGdv b2QgY292ZXJhZ2UgZm9yIHRoZSBrbm93biB1c2UgY2FzZXM6DQogICAgPj4+PiAgICAgICAtIChY MjU1MTksIEFFUy1HQ00sIEVkMjU1MTkpIC0gR29vZCBmb3IgZGVza3RvcA0KICAgID4+Pj4gICAg ICAgLSAoUC0yNTYsIEFFUy1HQ00sIFAtMjU2KSAtIENvbXBsaWFuY2UNCiAgICA+Pj4+ICAgICAg IC0gKFgyNTUxOSwgQ2hhY2hhUG9seSwgRWQyNTUxOSkgLSBHb29kIGZvciBtb2JpbGUNCiAgICA+ Pj4+IA0KICAgID4+Pj4gICAgICAgVGhlIGNoYWlycyBuZWVkIHRvIGNvbmZpcm0gdGhlIGludGVy aW3igJlzIGNvbnNlbnN1cyBvbiBsaXN0LCBzbyBwbGVhc2UgbGV0IHRoZSBXRyBrbm93IGJ5IDIz NTkgVVRDIDIwIEZlYnJ1YXJ5IHdoZXRoZXIgeW91IGRpc2FncmVlIHdpdGggdGhlc2UgY2hvaWNl cyBhbmQgd2h5Lg0KICAgID4+Pj4gDQogICAgPj4+PiAgICAgICBOT1RFOiBUaGUgZmluYWwgdGV4 dCB3aWxsIG9idmlvdXNseSBiZSByZXZpZXdlZCwgYnV0IGlzIGJlaW5nIGNvbXBvc2VkIGFzIHBh cnQgb2YgdGhlIGZvbGxvd2luZyBQUjoNCiAgICA+Pj4+ICAgICAgIGh0dHBzOi8vZ2l0aHViLmNv bS9tbHN3Zy9tbHMtcHJvdG9jb2wvcHVsbC8yNzkNCiAgICA+Pj4+IA0KICAgID4+Pj4gICAgICAg Tk9URTogV2UgY29tYmluZWQgdGhlc2UgY2lwaGVyIHN1aXRlIHJlbGF0ZWQgY29uc2Vuc3VzIHBv aW50cywgYnV0IGlmIHdlIG9ubHkgY29tZSB0byBjb25zZW5zdXMgb24gc29tZSBvZiB0aGVzZSB3 ZSBjYW4gc3RpbGwgaW5jb3Jwb3JhdGUgd2hhdCB3ZSBkbyBhZ3JlZSBvbi4NCiAgICA+Pj4+IA0K ICAgID4+Pj4gICAgICAgQ2hlZXJzLA0KICAgID4+Pj4gDQogICAgPj4+PiAgICAgICBOaWNrIGFu ZCBTZWFuDQogICAgPj4+PiAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgID4+Pj4gICAgICAgTUxTIG1haWxpbmcgbGlzdA0KICAgID4+Pj4g ICAgICAgTUxTQGlldGYub3JnDQogICAgPj4+PiAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21scw0KICAgID4+Pj4gDQogICAgPj4+PiANCiAgICA+Pj4+ICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+ICAg TUxTIG1haWxpbmcgbGlzdA0KICAgID4+Pj4gICBNTFNAaWV0Zi5vcmcNCiAgICA+Pj4+ICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAgICA+Pj4+IA0KICAgID4+ Pj4gDQogICAgPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgID4+Pj4gTUxTIG1haWxpbmcgbGlzdA0KICAgID4+Pj4gTUxTQGlldGYub3JnDQog ICAgPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21scw0KICAgID4+ Pj4gDQogICAgPj4+IA0KICAgID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgID4+PiBNTFMgbWFpbGluZyBsaXN0DQogICAgPj4+IE1MU0BpZXRm Lm9yZw0KICAgID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21scw0K ICAgID4+IA0KICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgPj4gTUxTIG1haWxpbmcgbGlzdA0KICAgID4+IE1MU0BpZXRmLm9yZw0KICAg ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzDQogICAgPiANCiAg ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg PiBNTFMgbWFpbGluZyBsaXN0DQogICAgPiBNTFNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzDQogICAgDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBNTFMgbWFpbGluZyBsaXN0DQog ICAgTUxTQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbHMNCiAgICANCg0K From nobody Wed Feb 26 11:17:14 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CADD3A11B6 for ; Wed, 26 Feb 2020 11:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1eqgphSlwwk for ; Wed, 26 Feb 2020 11:17:05 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DEF3A1238 for ; Wed, 26 Feb 2020 11:17:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,489,1574118000"; d="scan'208";a="437796403" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 20:17:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Benjamin Beurdouche In-Reply-To: <13647581-208F-449C-9FE3-59FA4B22B58F@nps.edu> Date: Wed, 26 Feb 2020 20:17:00 +0100 Cc: ML Messaging Layer Security Content-Transfer-Encoding: quoted-printable Message-Id: <7D05D9F3-735C-4D7D-9AFA-996D12F88DA1@inria.fr> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <13647581-208F-449C-9FE3-59FA4B22B58F@nps.edu> To: Britta Hale X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 19:17:12 -0000 I have a few worries, so quick thoughts: 1. agility causes a lot of problems: I don=E2=80=99t think I need to = remind people of the TLS story https://hal.inria.fr/hal-01114250 2. interop fragmentation: this is not a two party protocol where = membership is set forever. If a single member does not support one crypto scheme, this member might = never be able to join an hybrid group. 3. security: I clearly don=E2=80=99t believe we should assume anything = from the security of the protocol in the case a cryptographic scheme is broken. I don=E2=80=99t want to = get to a point where we have horrible downgrade stories and I would clearly want to kill and restart the entire group I think fragmentation is my main worry actually, and if we figure out = that we were wrong, adding more agility is likely to be more easy than removing it. So my intuition is that we should proceed with one signature scheme for = the lifetime of the group and make sure we have a solid story to export and reconstruct a group, = which we need anyway. Ben > On 26 Feb 2020, at 19:51, Hale, Britta (CIV) = wrote: >=20 > Thank you Benjamin for speaking up. If we go forward with either = option it is good to have a documented basis for doing so on the = mailinglist, and until now we have arguments which support individual = schemes, or "no strong preference". As there were no objections to the = stated reasons supporting individual schemes, the rough consensus until = now was arguably for that; putting forward a clear preference gives us = grounds for not dismissing the group option. Ease of implementation = without error, efficiency, or security are all reasonable arguments for = choosing one of these or the other - having an existing PR to follow = should not be our decision metric. So it is good to see a clear = statement on the mailinglist.=20 >=20 > Given the points outlined in the document, the positives and negatives = of both suggest that the individual signature option may be better for = security. However, if there is even one strong argument for having a = single group scheme, that is not a comparable under the individual = option, then that may be a fair basis for the single group scheme = choice.=20 > Can you describe the security (or efficiency/implementation) factors = that lead to your preference? >=20 > Britta=20 >=20 >=20 >=20 > =EF=BB=BFOn 2/26/20, 7:25 PM, "MLS on behalf of Benjamin Beurdouche" = wrote: >=20 > I would strongly prefer one signature scheme for the lifetime of = the group. > B. >=20 >> On 26 Feb 2020, at 17:28, Sean Turner wrote: >>=20 >> There seems to be rough consensus (stressing the rough) to go with = one scheme per group. By rough consensus, I mean there seems to be a = willingness by the group to live with this decision and nobody is super = bent out of shape about it. Technically, that=E2=80=99s all we need to = move forward, but there are some concerns concerns that since it=E2=80=99s= such a small group and there are so few strong voices for the choice = that we should give it just a bit more time. So, I am extending this = call until 2359 UTC 2 March (i.e., Monday night). >>=20 >> Also, there are really three ciphersuite-related decisions being = made, as noted in the email below. >>=20 >> spt >>=20 >>> On Feb 25, 2020, at 13:24, Richard Barnes wrote: >>>=20 >>> I will not be able to make the call tomorrow, so to summarize my = opinion on this: >>>=20 >>> * I am OK with merging the current PR >>> * I have a slight preference for *not* including the sig alg in the = ciphersuite >>> * The simplicity case for including it seems reasonable, but not = dispositive >>> * In any case, I don't care strongly one way or another; I care more = about progress >>> * This is an easy change to revert if we change our minds later >>> * Credentials are going to indicate the signature algorithm anyway >>> * So the only difference in spec is whether endpoints check = Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm >>>=20 >>>=20 >>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: >>> Note that the main point of the telecon tomorrow is to address the = cipher suite issue. Please take the time to review: >>> - the related PRs: >>> https://github.com/mlswg/mls-protocol/pull/279 >>> https://github.com/mlswg/mls-protocol/pull/307 >>> - the messages in this thread >>> - the issues Britta outlined: >>> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>>=20 >>> We would like to close this issue out tomorrow. >>>=20 >>> Cheers, >>>=20 >>> spt >>>=20 >>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok = wrote: >>>>=20 >>>> Hi Britta, >>>>=20 >>>> I think you sum it up very nicely. There is one (albeit somewhat = speculative) >>>> argument why a single ciphersuite per group might actually be = beneficial in a >>>> federation context. In the event that there is "global concensus" = that a >>>> ciphersuite needs to be deprecated, my expectation would be that a = majority of >>>> the federation nodes/application providers would move to ban those = ciphersuits, >>>> excluding anyone who would use _exclusively_ that ciphersuite. That = would in >>>> turn be a motivation for all other nodes/application providers to = catch up as >>>> well. This also means that nodes can't be made (by whatever = authority) to use >>>> weak ciphersuites exclusively and still expect to federate with = other nodes that >>>> have more sensible policies. >>>>=20 >>>> That's mostly my guess of how the dynamics in such a federated = environment >>>> _could_ work, though. Anyone here with some actual = experience/expertise they can >>>> share of what the dynamics could be? >>>>=20 >>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just = seems a lot >>>> simpler and even in the context of federation, I think that most >>>> nodes/application providers would allow several ciphersuites to = begin with, >>>> where not all of them are weak, meaning no one would really be = excluded too quickly. >>>>=20 >>>> Cheers, >>>> Konrad >>>>=20 >>>>=20 >>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: >>>>> Under the topic of individual/single signature schemes there is = the final issue of federation. In a federated context, groups are no = longer under the control of a single application, meaning that we would = lose some control in forcing good ciphersuite choices. This could lead = to two issues: >>>>>=20 >>>>> 1) MLS would move closer to facing the TLS problem of having old = suites supported by edge cases, which in turn weaken the entire group's = security. There is always the argument that groups would simply refuse = joiners that do not support the current group cipher, but this is not = very practical from a usability view. E.g. if everyone using application = X refused group members who were using application Y, then the point of = federation would be largely defeated. So, either some form of = renegotiation is allowed (e.g. export psk) and downgrade becomes more = likely, or federation does not work reliably.=20 >>>>>=20 >>>>> 2) Healing would take longer. Since no one application has a = master view and control over ciphersuites, upgrading long-lived groups = using questionable ciphers could take a significant amount of time (all = applications would need to do so in order for the group to upgrade) or = alternatively result in kicking group members out of the group (again, = possible, but questionable for usability except in extreme cases). Under = an individual cipher choice, any one member can choose/upgrade their = scheme, allowing for faster adaptability and potential benefits to PCS.=20= >>>>>=20 >>>>> =46rom the above, it seems that a single group cipher makes = federation harder/slower/less secure, but I may not have a clear view on = how federation would work in this context. Does anyone know whether the = above are really concerns or not relevant due to other reasons?=20 >>>>>=20 >>>>> (Note that this is thinking in the long-term context. Obviously we = do not want to standardize any cipher choice that is sub-optimal; = however any number of things may happen with protocol versioning and = cipher breaks over the span of several years.) >>>>>=20 >>>>> Under all the considerations that I have seen so far, the pros and = cons on both sides place the individual signature cipher option in the = lead. However that lead is small, hence why I have not been arguing for = it. The issue of federation could be a deciding factor. If we want = federation in the future it is of course better not to build inhibiting = factors into MLS now that could undermine either usability or security = in such contexts. To make a case to proceed with the single group cipher = option, it would be great if someone could provide a convincing argument = as to why it would be the best option for usability and security in the = federated environment (or preclude a federated use-case altogether). >>>>>=20 >>>>> --- >>>>>=20 >>>>> Britta=20 >>>>>=20 >>>>>=20 >>>>> On 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" = wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Concerning the use of a single group signature scheme or = individual signature schemes, it is probably worthwhile to expand on the = consideration points and clarify what security implications we are = accepting - in either case. I have listed out some issues in the = following Google doc: >>>>>=20 >>>>> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>>>>=20 >>>>> I am not making an argument for either case at this point, but = pushing this out for discussion and to help us achieve more clarity as = to the benefits and consequences of either choice. There are certainly = more issues to consider (e.g. ease of implementation, efficiency, etc. = in addition to security considerations) and other views - feel free to = add them or discuss on the mailing list.=20 >>>>>=20 >>>>> All the best, >>>>>=20 >>>>> Britta=20 >>>>>=20 >>>>>=20 >>>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" = wrote: >>>>>=20 >>>>> Hi! >>>>>=20 >>>>> tl;dr: confirming MTI suite selections and rationale for = avoiding proliferation >>>>>=20 >>>>> During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. >>>>>=20 >>>>> There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There = are, at least, three things to consider: 1) if a potential group member = does not support the algorithm, then they will not become a member or = the group will need to downgrade; 2) when the group needs/wants to = update, it is a flag day; and, 3) the cipher suites will have a similar = combinatorial issues as the TLS cipher suites prior to TLS 1.3. The = agreement was =E2=80=9Crough=E2=80=9D because 1) likely has some = important implications. >>>>>=20 >>>>> The MLS cipher suites defined were as follows:=20 >>>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >>>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >>>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >>>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >>>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >>>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >>>>>=20 >>>>> At the interim, the consensus was to make the non-NIST suites = the MTI. The rationale was that those implementation that need to be = NIST compliant will do so regardless of the choice made by the WG. >>>>>=20 >>>>> In looking at the actual cipher suites, it was noted that the = 256-bit schemes the SHA should be SHA-512. The rationale agreed was that = SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one = less operation. >>>>>=20 >>>>> To avoid the proliferation of cipher suites, guidance will be = provided to be conservative about allocating new code points. The = consensus at the interim was that the suites provided were minimal and = provided good coverage for the known use cases: >>>>> - (X25519, AES-GCM, Ed25519) - Good for desktop >>>>> - (P-256, AES-GCM, P-256) - Compliance >>>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile >>>>>=20 >>>>> The chairs need to confirm the interim=E2=80=99s consensus on = list, so please let the WG know by 2359 UTC 20 February whether you = disagree with these choices and why. >>>>>=20 >>>>> NOTE: The final text will obviously be reviewed, but is being = composed as part of the following PR: >>>>> https://github.com/mlswg/mls-protocol/pull/279 >>>>>=20 >>>>> NOTE: We combined these cipher suite related consensus = points, but if we only come to consensus on some of these we can still = incorporate what we do agree on. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Nick and Sean >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 >=20 From nobody Wed Feb 26 11:38:00 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288F93A1261 for ; Wed, 26 Feb 2020 11:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLaFj9W1J9kV for ; Wed, 26 Feb 2020 11:37:52 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D1B3A1257 for ; Wed, 26 Feb 2020 11:37:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,489,1574118000"; d="scan'208";a="437797588" Received: from 89-156-101-160.rev.numericable.fr (HELO [192.168.0.62]) ([89.156.101.160]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2020 20:37:48 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Karthik Bhargavan In-Reply-To: <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> Date: Wed, 26 Feb 2020 20:37:48 +0100 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> To: Cas Cremers X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 19:37:59 -0000 Hello All, I think we could go either way: multiple or single signature algorithm = per group. However, I would prefer if we required *all* the algorithms that group = members must support to be declared up-front at group creation. That is, my preference is not to add new signature algorithms as a group = evolves and new members are added. The rationale behind this thinking is that when a member joins a group, = she can inspect the group=E2=80=99s parameters to decide whether she = supports the algorithms needed to converse in the group. It would be weird if the = group allowed a new member whose authentication credential or message = signatures cannot be processed by existing members. And it would be hard to try to = dynamically detect the algorithms that the group members support. Instead, declaring all *required* algorithms at group creation seems = like a sane choice to me. -Karthik > On 26 Feb 2020, at 19:48, Cas Cremers wrote: >=20 > Hi, >=20 > This is a tricky one. I think allowing multiple signature schemes per > group can improve security in subtle ways, especially in large groups > with potentially diverse clients. >=20 > I understand part of the "one scheme per group is simpler" argument, = but > I am not sure it is simpler in practice, since it puts more weight on > the choice of the initiators of the group, and might complicate adding > group members afterwards. I don't think it is a blocking factor for = any > analysis either. >=20 > So I have *a slight preference for allowing multiple signature schemes > per group*, from the perspective of facilitating large diverse groups = in > the future, and the potential local security benefits. >=20 > But I definitely agree with Richard that this can be a small change > later, and doesn't seem to be some fundamental design choice that = cannot > be reverted/relaxed/tightened later; I also care about progress, so > let's pick something for now. >=20 > Best, >=20 > Cas >=20 >=20 >=20 >=20 >=20 > On 2/26/20 7:24 PM, Benjamin Beurdouche wrote: >> I would strongly prefer one signature scheme for the lifetime of the = group. >> B. >>=20 >>> On 26 Feb 2020, at 17:28, Sean Turner wrote: >>>=20 >>> There seems to be rough consensus (stressing the rough) to go with = one scheme per group. By rough consensus, I mean there seems to be a = willingness by the group to live with this decision and nobody is super = bent out of shape about it. Technically, that=E2=80=99s all we need to = move forward, but there are some concerns concerns that since it=E2=80=99s= such a small group and there are so few strong voices for the choice = that we should give it just a bit more time. So, I am extending this = call until 2359 UTC 2 March (i.e., Monday night). >>>=20 >>> Also, there are really three ciphersuite-related decisions being = made, as noted in the email below. >>>=20 >>> spt >>>=20 >>>> On Feb 25, 2020, at 13:24, Richard Barnes wrote: >>>>=20 >>>> I will not be able to make the call tomorrow, so to summarize my = opinion on this: >>>>=20 >>>> * I am OK with merging the current PR >>>> * I have a slight preference for *not* including the sig alg in the = ciphersuite >>>> * The simplicity case for including it seems reasonable, but not = dispositive >>>> * In any case, I don't care strongly one way or another; I care = more about progress >>>> * This is an easy change to revert if we change our minds later >>>> * Credentials are going to indicate the signature algorithm anyway >>>> * So the only difference in spec is whether endpoints check = Credential.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm >>>>=20 >>>>=20 >>>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner = wrote: >>>> Note that the main point of the telecon tomorrow is to address the = cipher suite issue. Please take the time to review: >>>> - the related PRs: >>>> https://github.com/mlswg/mls-protocol/pull/279 >>>> https://github.com/mlswg/mls-protocol/pull/307 >>>> - the messages in this thread >>>> - the issues Britta outlined: >>>> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>>>=20 >>>> We would like to close this issue out tomorrow. >>>>=20 >>>> Cheers, >>>>=20 >>>> spt >>>>=20 >>>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok = wrote: >>>>>=20 >>>>> Hi Britta, >>>>>=20 >>>>> I think you sum it up very nicely. There is one (albeit somewhat = speculative) >>>>> argument why a single ciphersuite per group might actually be = beneficial in a >>>>> federation context. In the event that there is "global concensus" = that a >>>>> ciphersuite needs to be deprecated, my expectation would be that a = majority of >>>>> the federation nodes/application providers would move to ban those = ciphersuits, >>>>> excluding anyone who would use _exclusively_ that ciphersuite. = That would in >>>>> turn be a motivation for all other nodes/application providers to = catch up as >>>>> well. This also means that nodes can't be made (by whatever = authority) to use >>>>> weak ciphersuites exclusively and still expect to federate with = other nodes that >>>>> have more sensible policies. >>>>>=20 >>>>> That's mostly my guess of how the dynamics in such a federated = environment >>>>> _could_ work, though. Anyone here with some actual = experience/expertise they can >>>>> share of what the dynamics could be? >>>>>=20 >>>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It = just seems a lot >>>>> simpler and even in the context of federation, I think that most >>>>> nodes/application providers would allow several ciphersuites to = begin with, >>>>> where not all of them are weak, meaning no one would really be = excluded too quickly. >>>>>=20 >>>>> Cheers, >>>>> Konrad >>>>>=20 >>>>>=20 >>>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: >>>>>> Under the topic of individual/single signature schemes there is = the final issue of federation. In a federated context, groups are no = longer under the control of a single application, meaning that we would = lose some control in forcing good ciphersuite choices. This could lead = to two issues: >>>>>>=20 >>>>>> 1) MLS would move closer to facing the TLS problem of having old = suites supported by edge cases, which in turn weaken the entire group's = security. There is always the argument that groups would simply refuse = joiners that do not support the current group cipher, but this is not = very practical from a usability view. E.g. if everyone using application = X refused group members who were using application Y, then the point of = federation would be largely defeated. So, either some form of = renegotiation is allowed (e.g. export psk) and downgrade becomes more = likely, or federation does not work reliably.=20 >>>>>>=20 >>>>>> 2) Healing would take longer. Since no one application has a = master view and control over ciphersuites, upgrading long-lived groups = using questionable ciphers could take a significant amount of time (all = applications would need to do so in order for the group to upgrade) or = alternatively result in kicking group members out of the group (again, = possible, but questionable for usability except in extreme cases). Under = an individual cipher choice, any one member can choose/upgrade their = scheme, allowing for faster adaptability and potential benefits to PCS.=20= >>>>>>=20 >>>>>> =46rom the above, it seems that a single group cipher makes = federation harder/slower/less secure, but I may not have a clear view on = how federation would work in this context. Does anyone know whether the = above are really concerns or not relevant due to other reasons?=20 >>>>>>=20 >>>>>> (Note that this is thinking in the long-term context. Obviously = we do not want to standardize any cipher choice that is sub-optimal; = however any number of things may happen with protocol versioning and = cipher breaks over the span of several years.) >>>>>>=20 >>>>>> Under all the considerations that I have seen so far, the pros = and cons on both sides place the individual signature cipher option in = the lead. However that lead is small, hence why I have not been arguing = for it. The issue of federation could be a deciding factor. If we want = federation in the future it is of course better not to build inhibiting = factors into MLS now that could undermine either usability or security = in such contexts. To make a case to proceed with the single group cipher = option, it would be great if someone could provide a convincing argument = as to why it would be the best option for usability and security in the = federated environment (or preclude a federated use-case altogether). >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> Britta=20 >>>>>>=20 >>>>>>=20 >>>>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta = (CIV)" wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Concerning the use of a single group signature scheme or = individual signature schemes, it is probably worthwhile to expand on the = consideration points and clarify what security implications we are = accepting - in either case. I have listed out some issues in the = following Google doc: >>>>>>=20 >>>>>> = https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilId= FKw14/edit?usp=3Dsharing >>>>>>=20 >>>>>> I am not making an argument for either case at this point, but = pushing this out for discussion and to help us achieve more clarity as = to the benefits and consequences of either choice. There are certainly = more issues to consider (e.g. ease of implementation, efficiency, etc. = in addition to security considerations) and other views - feel free to = add them or discuss on the mailing list.=20 >>>>>>=20 >>>>>> All the best, >>>>>>=20 >>>>>> Britta=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" = wrote: >>>>>>=20 >>>>>> Hi! >>>>>>=20 >>>>>> tl;dr: confirming MTI suite selections and rationale for = avoiding proliferation >>>>>>=20 >>>>>> During the F2F Interim in January, the WG discussed cipher = suites-related issues. Namely, whether a per-group signature scheme = should be driven by the chosen cipher suite, what were the MTI = (Mandatory To Implement) cipher suites, and what the actual algorithm = should be. >>>>>>=20 >>>>>> There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There = are, at least, three things to consider: 1) if a potential group member = does not support the algorithm, then they will not become a member or = the group will need to downgrade; 2) when the group needs/wants to = update, it is a flag day; and, 3) the cipher suites will have a similar = combinatorial issues as the TLS cipher suites prior to TLS 1.3. The = agreement was =E2=80=9Crough=E2=80=9D because 1) likely has some = important implications. >>>>>>=20 >>>>>> The MLS cipher suites defined were as follows:=20 >>>>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >>>>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >>>>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >>>>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >>>>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >>>>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >>>>>>=20 >>>>>> At the interim, the consensus was to make the non-NIST = suites the MTI. The rationale was that those implementation that need = to be NIST compliant will do so regardless of the choice made by the WG. >>>>>>=20 >>>>>> In looking at the actual cipher suites, it was noted that = the 256-bit schemes the SHA should be SHA-512. The rationale agreed was = that SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is = one less operation. >>>>>>=20 >>>>>> To avoid the proliferation of cipher suites, guidance will = be provided to be conservative about allocating new code points. The = consensus at the interim was that the suites provided were minimal and = provided good coverage for the known use cases: >>>>>> - (X25519, AES-GCM, Ed25519) - Good for desktop >>>>>> - (P-256, AES-GCM, P-256) - Compliance >>>>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile >>>>>>=20 >>>>>> The chairs need to confirm the interim=E2=80=99s consensus = on list, so please let the WG know by 2359 UTC 20 February whether you = disagree with these choices and why. >>>>>>=20 >>>>>> NOTE: The final text will obviously be reviewed, but is = being composed as part of the following PR: >>>>>> https://github.com/mlswg/mls-protocol/pull/279 >>>>>>=20 >>>>>> NOTE: We combined these cipher suite related consensus = points, but if we only come to consensus on some of these we can still = incorporate what we do agree on. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Nick and Sean >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 26 11:41:30 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCC93A12A8 for ; Wed, 26 Feb 2020 11:41:24 -0800 (PST) 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, FREEMAIL_FROM=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydJjha5ya4HF for ; Wed, 26 Feb 2020 11:41:21 -0800 (PST) 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 93E273A1165 for ; Wed, 26 Feb 2020 11:41:21 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id y17so210384wrn.6 for ; Wed, 26 Feb 2020 11:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ldkRuJZ2mcbpy6gwYVTyWT2Nrr1oYtHfuKaX6yqYC+I=; b=ezwsE7F7jwSLoG3gu1v9UPgwq6fcyotjDyf5+6VdI+BGdBkzsdgDhXqmUmFpCUzxtY jlcWbpjw48zuDWdVL25VBMQVDzbVSGq4ngFAXeowmgAJ+9lkgMBFfkY6S9ylNIdqlt1/ RJCaMKtGevtL4bfh1xIS6lbmAN/3UaawtqM185UufVncRKXSpodhd5VpvELoLyfaI1NS rbDpzYdfIRWfdUM91iJfqS7YOeWutcenVZvLNoJyhe2m08wIQ9XB/rK2ndaGWvQdhHT9 QJlZqAl4tIOvrSvoFEhQZLm1DHs5r5ioCxokgynbczk2EYlV12YA0RCBZtV3EDe8kUxn w6ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ldkRuJZ2mcbpy6gwYVTyWT2Nrr1oYtHfuKaX6yqYC+I=; b=CJiAAD7/y7kI1I0MyX5aSViRKwgCcaNv11FDCpQrKwX0lVXP7pWZ2OAIVGRMGmSPrK zPbfgBGuaJz40gq+iQzrmYNIoJXtM7sR3+JslfWr7fbRP+7cURat9UFsygEwefYYP6OT d4y/z5NbIZZvHWu4+L3WcHIC3XLsH6QGZgx1QR7AjeW6t+GplfvMP4cFI04ej8AMGEcl 3NGcGa4zD5w9OF+mOxkL6ZQN6rwvLipDOpLU5G09gNnxosbcakPRIjQt3u0fCDaQ1DUM x/2IiXySAyjviGcB10RjwmSX/s7hpU0JksVCL8YRg8BYISJdS/ro1yF4wDk1UKhROnmX M2yw== X-Gm-Message-State: APjAAAVzWv9QLXOmv5mkjSH0md59hUKqNrb7N8pirhyzlZ3fUn6V2xrD U8bhiZgXm1/CkZ4BHUd/kBoU2/8p6z9FYiyBS64= X-Google-Smtp-Source: APXvYqzRA0lP0U1N1E+yqovO5bmGmc0sF90cLK4GSP6vHO8kyUp3CTOH7W69eKGowabNxt9RXSvvfbPdafUDlH7LELA= X-Received: by 2002:a5d:540f:: with SMTP id g15mr256788wrv.86.1582746079440; Wed, 26 Feb 2020 11:41:19 -0800 (PST) MIME-Version: 1.0 References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> In-Reply-To: <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> From: Cas Cremers Date: Wed, 26 Feb 2020 20:41:03 +0100 Message-ID: To: Karthik Bhargavan Cc: ML Messaging Layer Security Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 19:41:28 -0000 Hi, I agree with Karthik's suggestion; in practice this may simply be the intersection of the algorithms that the initial members support. Best, Cas On Wed, Feb 26, 2020 at 8:37 PM Karthik Bhargavan wrote: > > Hello All, > > I think we could go either way: multiple or single signature algorithm pe= r group. > However, I would prefer if we required *all* the algorithms that group me= mbers must support to be declared up-front at group creation. > That is, my preference is not to add new signature algorithms as a group = evolves and new members are added. > > The rationale behind this thinking is that when a member joins a group, s= he can inspect the group=E2=80=99s parameters to decide whether she support= s > the algorithms needed to converse in the group. It would be weird if the = group allowed a new member whose authentication credential or message signa= tures > cannot be processed by existing members. And it would be hard to try to d= ynamically detect the algorithms that the group members support. > Instead, declaring all *required* algorithms at group creation seems like= a sane choice to me. > > -Karthik > > > > On 26 Feb 2020, at 19:48, Cas Cremers wrote: > > > > Hi, > > > > This is a tricky one. I think allowing multiple signature schemes per > > group can improve security in subtle ways, especially in large groups > > with potentially diverse clients. > > > > I understand part of the "one scheme per group is simpler" argument, bu= t > > I am not sure it is simpler in practice, since it puts more weight on > > the choice of the initiators of the group, and might complicate adding > > group members afterwards. I don't think it is a blocking factor for any > > analysis either. > > > > So I have *a slight preference for allowing multiple signature schemes > > per group*, from the perspective of facilitating large diverse groups i= n > > the future, and the potential local security benefits. > > > > But I definitely agree with Richard that this can be a small change > > later, and doesn't seem to be some fundamental design choice that canno= t > > be reverted/relaxed/tightened later; I also care about progress, so > > let's pick something for now. > > > > Best, > > > > Cas > > > > > > > > > > > > On 2/26/20 7:24 PM, Benjamin Beurdouche wrote: > >> I would strongly prefer one signature scheme for the lifetime of the g= roup. > >> B. > >> > >>> On 26 Feb 2020, at 17:28, Sean Turner wrote: > >>> > >>> There seems to be rough consensus (stressing the rough) to go with on= e scheme per group. By rough consensus, I mean there seems to be a willingn= ess by the group to live with this decision and nobody is super bent out of= shape about it. Technically, that=E2=80=99s all we need to move forward, b= ut there are some concerns concerns that since it=E2=80=99s such a small gr= oup and there are so few strong voices for the choice that we should give i= t just a bit more time. So, I am extending this call until 2359 UTC 2 March= (i.e., Monday night). > >>> > >>> Also, there are really three ciphersuite-related decisions being made= , as noted in the email below. > >>> > >>> spt > >>> > >>>> On Feb 25, 2020, at 13:24, Richard Barnes wrote: > >>>> > >>>> I will not be able to make the call tomorrow, so to summarize my opi= nion on this: > >>>> > >>>> * I am OK with merging the current PR > >>>> * I have a slight preference for *not* including the sig alg in the = ciphersuite > >>>> * The simplicity case for including it seems reasonable, but not dis= positive > >>>> * In any case, I don't care strongly one way or another; I care more= about progress > >>>> * This is an easy change to revert if we change our minds later > >>>> * Credentials are going to indicate the signature algorithm anyway > >>>> * So the only difference in spec is whether endpoints check Credenti= al.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm > >>>> > >>>> > >>>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: > >>>> Note that the main point of the telecon tomorrow is to address the c= ipher suite issue. Please take the time to review: > >>>> - the related PRs: > >>>> https://github.com/mlswg/mls-protocol/pull/279 > >>>> https://github.com/mlswg/mls-protocol/pull/307 > >>>> - the messages in this thread > >>>> - the issues Britta outlined: > >>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMt= dSilIdFKw14/edit?usp=3Dsharing > >>>> > >>>> We would like to close this issue out tomorrow. > >>>> > >>>> Cheers, > >>>> > >>>> spt > >>>> > >>>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok wrote: > >>>>> > >>>>> Hi Britta, > >>>>> > >>>>> I think you sum it up very nicely. There is one (albeit somewhat sp= eculative) > >>>>> argument why a single ciphersuite per group might actually be benef= icial in a > >>>>> federation context. In the event that there is "global concensus" t= hat a > >>>>> ciphersuite needs to be deprecated, my expectation would be that a = majority of > >>>>> the federation nodes/application providers would move to ban those = ciphersuits, > >>>>> excluding anyone who would use _exclusively_ that ciphersuite. That= would in > >>>>> turn be a motivation for all other nodes/application providers to c= atch up as > >>>>> well. This also means that nodes can't be made (by whatever authori= ty) to use > >>>>> weak ciphersuites exclusively and still expect to federate with oth= er nodes that > >>>>> have more sensible policies. > >>>>> > >>>>> That's mostly my guess of how the dynamics in such a federated envi= ronment > >>>>> _could_ work, though. Anyone here with some actual experience/exper= tise they can > >>>>> share of what the dynamics could be? > >>>>> > >>>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just= seems a lot > >>>>> simpler and even in the context of federation, I think that most > >>>>> nodes/application providers would allow several ciphersuites to beg= in with, > >>>>> where not all of them are weak, meaning no one would really be excl= uded too quickly. > >>>>> > >>>>> Cheers, > >>>>> Konrad > >>>>> > >>>>> > >>>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: > >>>>>> Under the topic of individual/single signature schemes there is th= e final issue of federation. In a federated context, groups are no longer u= nder the control of a single application, meaning that we would lose some c= ontrol in forcing good ciphersuite choices. This could lead to two issues: > >>>>>> > >>>>>> 1) MLS would move closer to facing the TLS problem of having old s= uites supported by edge cases, which in turn weaken the entire group's secu= rity. There is always the argument that groups would simply refuse joiners = that do not support the current group cipher, but this is not very practica= l from a usability view. E.g. if everyone using application X refused group= members who were using application Y, then the point of federation would b= e largely defeated. So, either some form of renegotiation is allowed (e.g. = export psk) and downgrade becomes more likely, or federation does not work = reliably. > >>>>>> > >>>>>> 2) Healing would take longer. Since no one application has a maste= r view and control over ciphersuites, upgrading long-lived groups using que= stionable ciphers could take a significant amount of time (all applications= would need to do so in order for the group to upgrade) or alternatively re= sult in kicking group members out of the group (again, possible, but questi= onable for usability except in extreme cases). Under an individual cipher c= hoice, any one member can choose/upgrade their scheme, allowing for faster = adaptability and potential benefits to PCS. > >>>>>> > >>>>>> From the above, it seems that a single group cipher makes federati= on harder/slower/less secure, but I may not have a clear view on how federa= tion would work in this context. Does anyone know whether the above are rea= lly concerns or not relevant due to other reasons? > >>>>>> > >>>>>> (Note that this is thinking in the long-term context. Obviously we= do not want to standardize any cipher choice that is sub-optimal; however = any number of things may happen with protocol versioning and cipher breaks = over the span of several years.) > >>>>>> > >>>>>> Under all the considerations that I have seen so far, the pros and= cons on both sides place the individual signature cipher option in the lea= d. However that lead is small, hence why I have not been arguing for it. Th= e issue of federation could be a deciding factor. If we want federation in = the future it is of course better not to build inhibiting factors into MLS = now that could undermine either usability or security in such contexts. To = make a case to proceed with the single group cipher option, it would be gre= at if someone could provide a convincing argument as to why it would be the= best option for usability and security in the federated environment (or pr= eclude a federated use-case altogether). > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> Britta > >>>>>> > >>>>>> > >>>>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)= " wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Concerning the use of a single group signature scheme or individu= al signature schemes, it is probably worthwhile to expand on the considerat= ion points and clarify what security implications we are accepting - in eit= her case. I have listed out some issues in the following Google doc: > >>>>>> > >>>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_= pMtdSilIdFKw14/edit?usp=3Dsharing > >>>>>> > >>>>>> I am not making an argument for either case at this point, but pu= shing this out for discussion and to help us achieve more clarity as to the= benefits and consequences of either choice. There are certainly more issue= s to consider (e.g. ease of implementation, efficiency, etc. in addition to= security considerations) and other views - feel free to add them or discus= s on the mailing list. > >>>>>> > >>>>>> All the best, > >>>>>> > >>>>>> Britta > >>>>>> > >>>>>> > >>>>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" wrote: > >>>>>> > >>>>>> Hi! > >>>>>> > >>>>>> tl;dr: confirming MTI suite selections and rationale for avoi= ding proliferation > >>>>>> > >>>>>> During the F2F Interim in January, the WG discussed cipher su= ites-related issues. Namely, whether a per-group signature scheme should be= driven by the chosen cipher suite, what were the MTI (Mandatory To Impleme= nt) cipher suites, and what the actual algorithm should be. > >>>>>> > >>>>>> There was rough agreement that there should be one signature = scheme per group and that should be driven by the cipher suite. There are, = at least, three things to consider: 1) if a potential group member does not= support the algorithm, then they will not become a member or the group wil= l need to downgrade; 2) when the group needs/wants to update, it is a flag = day; and, 3) the cipher suites will have a similar combinatorial issues as = the TLS cipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough=E2= =80=9D because 1) likely has some important implications. > >>>>>> > >>>>>> The MLS cipher suites defined were as follows: > >>>>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > >>>>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > >>>>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > >>>>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > >>>>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > >>>>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > >>>>>> > >>>>>> At the interim, the consensus was to make the non-NIST suites= the MTI. The rationale was that those implementation that need to be NIST= compliant will do so regardless of the choice made by the WG. > >>>>>> > >>>>>> In looking at the actual cipher suites, it was noted that the= 256-bit schemes the SHA should be SHA-512. The rationale agreed was that S= HA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less op= eration. > >>>>>> > >>>>>> To avoid the proliferation of cipher suites, guidance will be= provided to be conservative about allocating new code points. The consensu= s at the interim was that the suites provided were minimal and provided goo= d coverage for the known use cases: > >>>>>> - (X25519, AES-GCM, Ed25519) - Good for desktop > >>>>>> - (P-256, AES-GCM, P-256) - Compliance > >>>>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile > >>>>>> > >>>>>> The chairs need to confirm the interim=E2=80=99s consensus on= list, so please let the WG know by 2359 UTC 20 February whether you disagr= ee with these choices and why. > >>>>>> > >>>>>> NOTE: The final text will obviously be reviewed, but is being= composed as part of the following PR: > >>>>>> https://github.com/mlswg/mls-protocol/pull/279 > >>>>>> > >>>>>> NOTE: We combined these cipher suite related consensus points= , but if we only come to consensus on some of these we can still incorporat= e what we do agree on. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Nick and Sean > >>>>>> _______________________________________________ > >>>>>> MLS mailing list > >>>>>> MLS@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MLS mailing list > >>>>>> MLS@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MLS mailing list > >>>>>> MLS@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> MLS mailing list > >>>>> MLS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mls > >>>> > >>>> _______________________________________________ > >>>> MLS mailing list > >>>> MLS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mls > >>> > >>> _______________________________________________ > >>> MLS mailing list > >>> MLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mls > >> > >> _______________________________________________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls > >> > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Feb 26 11:47:46 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293533A1274 for ; Wed, 26 Feb 2020 11:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qAC57SiURoeE for ; Wed, 26 Feb 2020 11:47:40 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2DB3A12A2 for ; Wed, 26 Feb 2020 11:47:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,489,1574118000"; d="scan'208";a="340530095" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.48]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 26 Feb 2020 20:47:38 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Benjamin Beurdouche Mime-Version: 1.0 (1.0) Date: Wed, 26 Feb 2020 20:47:37 +0100 Message-Id: References: Cc: Karthik Bhargavan , ML Messaging Layer Security In-Reply-To: To: Cas Cremers X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 19:47:43 -0000 It is what we currently do, the problem is not creation or the initial membe= rs, it is the newcomers. B. > On Feb 26, 2020, at 8:41 PM, Cas Cremers wrote: >=20 > =EF=BB=BFHi, >=20 > I agree with Karthik's suggestion; in practice this may simply be the > intersection of the algorithms that the initial members support. >=20 > Best, >=20 > Cas >=20 >> On Wed, Feb 26, 2020 at 8:37 PM Karthik Bhargavan >> wrote: >>=20 >> Hello All, >>=20 >> I think we could go either way: multiple or single signature algorithm pe= r group. >> However, I would prefer if we required *all* the algorithms that group me= mbers must support to be declared up-front at group creation. >> That is, my preference is not to add new signature algorithms as a group e= volves and new members are added. >>=20 >> The rationale behind this thinking is that when a member joins a group, s= he can inspect the group=E2=80=99s parameters to decide whether she supports= >> the algorithms needed to converse in the group. It would be weird if the g= roup allowed a new member whose authentication credential or message signatu= res >> cannot be processed by existing members. And it would be hard to try to d= ynamically detect the algorithms that the group members support. >> Instead, declaring all *required* algorithms at group creation seems like= a sane choice to me. >>=20 >> -Karthik >>=20 >>=20 >>>> On 26 Feb 2020, at 19:48, Cas Cremers wrote: >>>=20 >>> Hi, >>>=20 >>> This is a tricky one. I think allowing multiple signature schemes per >>> group can improve security in subtle ways, especially in large groups >>> with potentially diverse clients. >>>=20 >>> I understand part of the "one scheme per group is simpler" argument, but= >>> I am not sure it is simpler in practice, since it puts more weight on >>> the choice of the initiators of the group, and might complicate adding >>> group members afterwards. I don't think it is a blocking factor for any >>> analysis either. >>>=20 >>> So I have *a slight preference for allowing multiple signature schemes >>> per group*, from the perspective of facilitating large diverse groups in= >>> the future, and the potential local security benefits. >>>=20 >>> But I definitely agree with Richard that this can be a small change >>> later, and doesn't seem to be some fundamental design choice that cannot= >>> be reverted/relaxed/tightened later; I also care about progress, so >>> let's pick something for now. >>>=20 >>> Best, >>>=20 >>> Cas >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2/26/20 7:24 PM, Benjamin Beurdouche wrote: >>>> I would strongly prefer one signature scheme for the lifetime of the gr= oup. >>>> B. >>>>=20 >>>>> On 26 Feb 2020, at 17:28, Sean Turner wrote: >>>>>=20 >>>>> There seems to be rough consensus (stressing the rough) to go with one= scheme per group. By rough consensus, I mean there seems to be a willingnes= s by the group to live with this decision and nobody is super bent out of sh= ape about it. Technically, that=E2=80=99s all we need to move forward, but t= here are some concerns concerns that since it=E2=80=99s such a small group a= nd there are so few strong voices for the choice that we should give it just= a bit more time. So, I am extending this call until 2359 UTC 2 March (i.e.,= Monday night). >>>>>=20 >>>>> Also, there are really three ciphersuite-related decisions being made,= as noted in the email below. >>>>>=20 >>>>> spt >>>>>=20 >>>>>> On Feb 25, 2020, at 13:24, Richard Barnes wrote: >>>>>>=20 >>>>>> I will not be able to make the call tomorrow, so to summarize my opin= ion on this: >>>>>>=20 >>>>>> * I am OK with merging the current PR >>>>>> * I have a slight preference for *not* including the sig alg in the c= iphersuite >>>>>> * The simplicity case for including it seems reasonable, but not disp= ositive >>>>>> * In any case, I don't care strongly one way or another; I care more a= bout progress >>>>>> * This is an easy change to revert if we change our minds later >>>>>> * Credentials are going to indicate the signature algorithm anyway >>>>>> * So the only difference in spec is whether endpoints check Credentia= l.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: >>>>>> Note that the main point of the telecon tomorrow is to address the ci= pher suite issue. Please take the time to review: >>>>>> - the related PRs: >>>>>> https://github.com/mlswg/mls-protocol/pull/279 >>>>>> https://github.com/mlswg/mls-protocol/pull/307 >>>>>> - the messages in this thread >>>>>> - the issues Britta outlined: >>>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtd= SilIdFKw14/edit?usp=3Dsharing >>>>>>=20 >>>>>> We would like to close this issue out tomorrow. >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> spt >>>>>>=20 >>>>>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok wrote: >>>>>>>=20 >>>>>>> Hi Britta, >>>>>>>=20 >>>>>>> I think you sum it up very nicely. There is one (albeit somewhat spe= culative) >>>>>>> argument why a single ciphersuite per group might actually be benefi= cial in a >>>>>>> federation context. In the event that there is "global concensus" th= at a >>>>>>> ciphersuite needs to be deprecated, my expectation would be that a m= ajority of >>>>>>> the federation nodes/application providers would move to ban those c= iphersuits, >>>>>>> excluding anyone who would use _exclusively_ that ciphersuite. That w= ould in >>>>>>> turn be a motivation for all other nodes/application providers to ca= tch up as >>>>>>> well. This also means that nodes can't be made (by whatever authorit= y) to use >>>>>>> weak ciphersuites exclusively and still expect to federate with othe= r nodes that >>>>>>> have more sensible policies. >>>>>>>=20 >>>>>>> That's mostly my guess of how the dynamics in such a federated envir= onment >>>>>>> _could_ work, though. Anyone here with some actual experience/expert= ise they can >>>>>>> share of what the dynamics could be? >>>>>>>=20 >>>>>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just s= eems a lot >>>>>>> simpler and even in the context of federation, I think that most >>>>>>> nodes/application providers would allow several ciphersuites to begi= n with, >>>>>>> where not all of them are weak, meaning no one would really be exclu= ded too quickly. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Konrad >>>>>>>=20 >>>>>>>=20 >>>>>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: >>>>>>>> Under the topic of individual/single signature schemes there is the= final issue of federation. In a federated context, groups are no longer und= er the control of a single application, meaning that we would lose some cont= rol in forcing good ciphersuite choices. This could lead to two issues: >>>>>>>>=20 >>>>>>>> 1) MLS would move closer to facing the TLS problem of having old su= ites supported by edge cases, which in turn weaken the entire group's securi= ty. There is always the argument that groups would simply refuse joiners tha= t do not support the current group cipher, but this is not very practical fr= om a usability view. E.g. if everyone using application X refused group memb= ers who were using application Y, then the point of federation would be larg= ely defeated. So, either some form of renegotiation is allowed (e.g. export p= sk) and downgrade becomes more likely, or federation does not work reliably.= >>>>>>>>=20 >>>>>>>> 2) Healing would take longer. Since no one application has a master= view and control over ciphersuites, upgrading long-lived groups using quest= ionable ciphers could take a significant amount of time (all applications wo= uld need to do so in order for the group to upgrade) or alternatively result= in kicking group members out of the group (again, possible, but questionabl= e for usability except in extreme cases). Under an individual cipher choice,= any one member can choose/upgrade their scheme, allowing for faster adaptab= ility and potential benefits to PCS. >>>>>>>>=20 >>>>>>>> =46rom the above, it seems that a single group cipher makes federat= ion harder/slower/less secure, but I may not have a clear view on how federa= tion would work in this context. Does anyone know whether the above are real= ly concerns or not relevant due to other reasons? >>>>>>>>=20 >>>>>>>> (Note that this is thinking in the long-term context. Obviously we d= o not want to standardize any cipher choice that is sub-optimal; however any= number of things may happen with protocol versioning and cipher breaks over= the span of several years.) >>>>>>>>=20 >>>>>>>> Under all the considerations that I have seen so far, the pros and c= ons on both sides place the individual signature cipher option in the lead. H= owever that lead is small, hence why I have not been arguing for it. The iss= ue of federation could be a deciding factor. If we want federation in the fu= ture it is of course better not to build inhibiting factors into MLS now tha= t could undermine either usability or security in such contexts. To make a c= ase to proceed with the single group cipher option, it would be great if som= eone could provide a convincing argument as to why it would be the best opti= on for usability and security in the federated environment (or preclude a fe= derated use-case altogether). >>>>>>>>=20 >>>>>>>> --- >>>>>>>>=20 >>>>>>>> Britta >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)"= wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> Concerning the use of a single group signature scheme or individual= signature schemes, it is probably worthwhile to expand on the consideration= points and clarify what security implications we are accepting - in either c= ase. I have listed out some issues in the following Google doc: >>>>>>>>=20 >>>>>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pM= tdSilIdFKw14/edit?usp=3Dsharing >>>>>>>>=20 >>>>>>>> I am not making an argument for either case at this point, but push= ing this out for discussion and to help us achieve more clarity as to the be= nefits and consequences of either choice. There are certainly more issues to= consider (e.g. ease of implementation, efficiency, etc. in addition to secu= rity considerations) and other views - feel free to add them or discuss on t= he mailing list. >>>>>>>>=20 >>>>>>>> All the best, >>>>>>>>=20 >>>>>>>> Britta >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" wrote: >>>>>>>>=20 >>>>>>>> Hi! >>>>>>>>=20 >>>>>>>> tl;dr: confirming MTI suite selections and rationale for avoidi= ng proliferation >>>>>>>>=20 >>>>>>>> During the F2F Interim in January, the WG discussed cipher suit= es-related issues. Namely, whether a per-group signature scheme should be dr= iven by the chosen cipher suite, what were the MTI (Mandatory To Implement) c= ipher suites, and what the actual algorithm should be. >>>>>>>>=20 >>>>>>>> There was rough agreement that there should be one signature sc= heme per group and that should be driven by the cipher suite. There are, at l= east, three things to consider: 1) if a potential group member does not supp= ort the algorithm, then they will not become a member or the group will need= to downgrade; 2) when the group needs/wants to update, it is a flag day; an= d, 3) the cipher suites will have a similar combinatorial issues as the TLS c= ipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough=E2=80=9D bec= ause 1) likely has some important implications. >>>>>>>>=20 >>>>>>>> The MLS cipher suites defined were as follows: >>>>>>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 >>>>>>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 >>>>>>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 >>>>>>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 >>>>>>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 >>>>>>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 >>>>>>>>=20 >>>>>>>> At the interim, the consensus was to make the non-NIST suites t= he MTI. The rationale was that those implementation that need to be NIST co= mpliant will do so regardless of the choice made by the WG. >>>>>>>>=20 >>>>>>>> In looking at the actual cipher suites, it was noted that the 2= 56-bit schemes the SHA should be SHA-512. The rationale agreed was that SHA-= 384 is SHA-512 cut in half, so just do SHA-512 because it is one less operat= ion. >>>>>>>>=20 >>>>>>>> To avoid the proliferation of cipher suites, guidance will be p= rovided to be conservative about allocating new code points. The consensus a= t the interim was that the suites provided were minimal and provided good co= verage for the known use cases: >>>>>>>> - (X25519, AES-GCM, Ed25519) - Good for desktop >>>>>>>> - (P-256, AES-GCM, P-256) - Compliance >>>>>>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile >>>>>>>>=20 >>>>>>>> The chairs need to confirm the interim=E2=80=99s consensus on l= ist, so please let the WG know by 2359 UTC 20 February whether you disagree w= ith these choices and why. >>>>>>>>=20 >>>>>>>> NOTE: The final text will obviously be reviewed, but is being c= omposed as part of the following PR: >>>>>>>> https://github.com/mlswg/mls-protocol/pull/279 >>>>>>>>=20 >>>>>>>> NOTE: We combined these cipher suite related consensus points, b= ut if we only come to consensus on some of these we can still incorporate wh= at we do agree on. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Nick and Sean >>>>>>>> _______________________________________________ >>>>>>>> MLS mailing list >>>>>>>> MLS@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> MLS mailing list >>>>>>>> MLS@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> MLS mailing list >>>>>>>> MLS@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> MLS mailing list >>>>>>> MLS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MLS mailing list >>>>>> MLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mls >>>>>=20 >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>>=20 >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 26 11:52:21 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0243A12EB for ; Wed, 26 Feb 2020 11:52:20 -0800 (PST) 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, FREEMAIL_FROM=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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N89uZkR18hAj for ; Wed, 26 Feb 2020 11:52:18 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25DE3A12D8 for ; Wed, 26 Feb 2020 11:52:17 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id p17so635948wma.1 for ; Wed, 26 Feb 2020 11:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kDxy9xoq4tNmAcCrYV8p5ztpvuWSPL//Gh8EwGOcWZs=; b=aCv11RgDvZ2l98Qx+MAPXA8uR5dPizkiYe7NM7F3GlSOZrioMP49iSnkHgJlqld6j6 sCjNXF2tZhTODUAcmhow4EJiGp1bD1F119nXrknBZh4+3QiwrXRa+sG+Y5aOYcPWjxGa iwRE/CLAxWeo2vN2JwICpNQ4FQtjPz595bi7h7P2VW1fnTDMKk47Lv6HYfyyj0/8BRbq pfiRhPh0PlTbdWS2q0tBKLur5VCIVR+C8ZyxG6FkMStmWmbttzGEgFGWKLx+ntYEqs+p qokTHTxsnhoILxPGeDIEak0T2sJz7lewUYOfQf0awPCKcdf0xk5WFPHS2hItYFuocwVb xq2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kDxy9xoq4tNmAcCrYV8p5ztpvuWSPL//Gh8EwGOcWZs=; b=YYqTk6PA5u0n85RxvfMI4Tte3h7eCBOI84haWfzo4jAa7YGkCI6DNlcRTh8F01AjZr 6VByFkXh5ruTrrjef+MplJa65L9MvhYegeV4VBDg6FGYdArUj5qcms3N141vOc7TzfJ4 L9efOzH0OeNZ91p02osC2+mRXVU5cqzvFmht2BQVg08CoRu479w3JNIzlRhKbP7IYqys kg0s8Zsaif1lRo/uldw7quzYi0Gh02iH2NGZ9gyerd+6vURFQuyiqPb5ZZUyzxDYPxj8 bBLjyvyd9RKgnVVSYIeOZEeRLcfICiNvodz90kud9VxnSjQxeEepxm47hYZpwV4Gt0fZ c3Xw== X-Gm-Message-State: APjAAAXHvDoxMalpdxhHmDADxHdX3CwtOlhmxe5a4rl77FHJFvKGwgGM 7eWMfhpGNnyK327a01wMvBXhcyJtdqS9Z5MKzYsr6Q== X-Google-Smtp-Source: APXvYqw94IRRgFD2DSemawxTCHL+uEJZFntLSOWDv/fdL6qPX0u/vrwgt6QSzapIKQDnZh8d1aN9R1fvDhG8nYhrLjo= X-Received: by 2002:a05:600c:2207:: with SMTP id z7mr524835wml.138.1582746735825; Wed, 26 Feb 2020 11:52:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Cas Cremers Date: Wed, 26 Feb 2020 20:51:59 +0100 Message-ID: To: Benjamin Beurdouche Cc: Karthik Bhargavan , ML Messaging Layer Security Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 19:52:20 -0000 Sure, I meant taking up the suggestion as fixing this set for newcomers. On Wed, Feb 26, 2020 at 8:47 PM Benjamin Beurdouche wrote: > > It is what we currently do, the problem is not creation or the initial me= mbers, it is the newcomers. > B. > > > On Feb 26, 2020, at 8:41 PM, Cas Cremers wrote: > > > > =EF=BB=BFHi, > > > > I agree with Karthik's suggestion; in practice this may simply be the > > intersection of the algorithms that the initial members support. > > > > Best, > > > > Cas > > > >> On Wed, Feb 26, 2020 at 8:37 PM Karthik Bhargavan > >> wrote: > >> > >> Hello All, > >> > >> I think we could go either way: multiple or single signature algorithm= per group. > >> However, I would prefer if we required *all* the algorithms that group= members must support to be declared up-front at group creation. > >> That is, my preference is not to add new signature algorithms as a gro= up evolves and new members are added. > >> > >> The rationale behind this thinking is that when a member joins a group= , she can inspect the group=E2=80=99s parameters to decide whether she supp= orts > >> the algorithms needed to converse in the group. It would be weird if t= he group allowed a new member whose authentication credential or message si= gnatures > >> cannot be processed by existing members. And it would be hard to try t= o dynamically detect the algorithms that the group members support. > >> Instead, declaring all *required* algorithms at group creation seems l= ike a sane choice to me. > >> > >> -Karthik > >> > >> > >>>> On 26 Feb 2020, at 19:48, Cas Cremers wrote: > >>> > >>> Hi, > >>> > >>> This is a tricky one. I think allowing multiple signature schemes per > >>> group can improve security in subtle ways, especially in large groups > >>> with potentially diverse clients. > >>> > >>> I understand part of the "one scheme per group is simpler" argument, = but > >>> I am not sure it is simpler in practice, since it puts more weight on > >>> the choice of the initiators of the group, and might complicate addin= g > >>> group members afterwards. I don't think it is a blocking factor for a= ny > >>> analysis either. > >>> > >>> So I have *a slight preference for allowing multiple signature scheme= s > >>> per group*, from the perspective of facilitating large diverse groups= in > >>> the future, and the potential local security benefits. > >>> > >>> But I definitely agree with Richard that this can be a small change > >>> later, and doesn't seem to be some fundamental design choice that can= not > >>> be reverted/relaxed/tightened later; I also care about progress, so > >>> let's pick something for now. > >>> > >>> Best, > >>> > >>> Cas > >>> > >>> > >>> > >>> > >>> > >>> On 2/26/20 7:24 PM, Benjamin Beurdouche wrote: > >>>> I would strongly prefer one signature scheme for the lifetime of the= group. > >>>> B. > >>>> > >>>>> On 26 Feb 2020, at 17:28, Sean Turner wrote: > >>>>> > >>>>> There seems to be rough consensus (stressing the rough) to go with = one scheme per group. By rough consensus, I mean there seems to be a willin= gness by the group to live with this decision and nobody is super bent out = of shape about it. Technically, that=E2=80=99s all we need to move forward,= but there are some concerns concerns that since it=E2=80=99s such a small = group and there are so few strong voices for the choice that we should give= it just a bit more time. So, I am extending this call until 2359 UTC 2 Mar= ch (i.e., Monday night). > >>>>> > >>>>> Also, there are really three ciphersuite-related decisions being ma= de, as noted in the email below. > >>>>> > >>>>> spt > >>>>> > >>>>>> On Feb 25, 2020, at 13:24, Richard Barnes wrote: > >>>>>> > >>>>>> I will not be able to make the call tomorrow, so to summarize my o= pinion on this: > >>>>>> > >>>>>> * I am OK with merging the current PR > >>>>>> * I have a slight preference for *not* including the sig alg in th= e ciphersuite > >>>>>> * The simplicity case for including it seems reasonable, but not d= ispositive > >>>>>> * In any case, I don't care strongly one way or another; I care mo= re about progress > >>>>>> * This is an easy change to revert if we change our minds later > >>>>>> * Credentials are going to indicate the signature algorithm anyway > >>>>>> * So the only difference in spec is whether endpoints check Creden= tial.SigAlgorithm =3D=3D CipherSuite.SigAlgorithm > >>>>>> > >>>>>> > >>>>>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrot= e: > >>>>>> Note that the main point of the telecon tomorrow is to address the= cipher suite issue. Please take the time to review: > >>>>>> - the related PRs: > >>>>>> https://github.com/mlswg/mls-protocol/pull/279 > >>>>>> https://github.com/mlswg/mls-protocol/pull/307 > >>>>>> - the messages in this thread > >>>>>> - the issues Britta outlined: > >>>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_p= MtdSilIdFKw14/edit?usp=3Dsharing > >>>>>> > >>>>>> We would like to close this issue out tomorrow. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> spt > >>>>>> > >>>>>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok wrote: > >>>>>>> > >>>>>>> Hi Britta, > >>>>>>> > >>>>>>> I think you sum it up very nicely. There is one (albeit somewhat = speculative) > >>>>>>> argument why a single ciphersuite per group might actually be ben= eficial in a > >>>>>>> federation context. In the event that there is "global concensus"= that a > >>>>>>> ciphersuite needs to be deprecated, my expectation would be that = a majority of > >>>>>>> the federation nodes/application providers would move to ban thos= e ciphersuits, > >>>>>>> excluding anyone who would use _exclusively_ that ciphersuite. Th= at would in > >>>>>>> turn be a motivation for all other nodes/application providers to= catch up as > >>>>>>> well. This also means that nodes can't be made (by whatever autho= rity) to use > >>>>>>> weak ciphersuites exclusively and still expect to federate with o= ther nodes that > >>>>>>> have more sensible policies. > >>>>>>> > >>>>>>> That's mostly my guess of how the dynamics in such a federated en= vironment > >>>>>>> _could_ work, though. Anyone here with some actual experience/exp= ertise they can > >>>>>>> share of what the dynamics could be? > >>>>>>> > >>>>>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It ju= st seems a lot > >>>>>>> simpler and even in the context of federation, I think that most > >>>>>>> nodes/application providers would allow several ciphersuites to b= egin with, > >>>>>>> where not all of them are weak, meaning no one would really be ex= cluded too quickly. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Konrad > >>>>>>> > >>>>>>> > >>>>>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: > >>>>>>>> Under the topic of individual/single signature schemes there is = the final issue of federation. In a federated context, groups are no longer= under the control of a single application, meaning that we would lose some= control in forcing good ciphersuite choices. This could lead to two issues= : > >>>>>>>> > >>>>>>>> 1) MLS would move closer to facing the TLS problem of having old= suites supported by edge cases, which in turn weaken the entire group's se= curity. There is always the argument that groups would simply refuse joiner= s that do not support the current group cipher, but this is not very practi= cal from a usability view. E.g. if everyone using application X refused gro= up members who were using application Y, then the point of federation would= be largely defeated. So, either some form of renegotiation is allowed (e.g= . export psk) and downgrade becomes more likely, or federation does not wor= k reliably. > >>>>>>>> > >>>>>>>> 2) Healing would take longer. Since no one application has a mas= ter view and control over ciphersuites, upgrading long-lived groups using q= uestionable ciphers could take a significant amount of time (all applicatio= ns would need to do so in order for the group to upgrade) or alternatively = result in kicking group members out of the group (again, possible, but ques= tionable for usability except in extreme cases). Under an individual cipher= choice, any one member can choose/upgrade their scheme, allowing for faste= r adaptability and potential benefits to PCS. > >>>>>>>> > >>>>>>>> From the above, it seems that a single group cipher makes federa= tion harder/slower/less secure, but I may not have a clear view on how fede= ration would work in this context. Does anyone know whether the above are r= eally concerns or not relevant due to other reasons? > >>>>>>>> > >>>>>>>> (Note that this is thinking in the long-term context. Obviously = we do not want to standardize any cipher choice that is sub-optimal; howeve= r any number of things may happen with protocol versioning and cipher break= s over the span of several years.) > >>>>>>>> > >>>>>>>> Under all the considerations that I have seen so far, the pros a= nd cons on both sides place the individual signature cipher option in the l= ead. However that lead is small, hence why I have not been arguing for it. = The issue of federation could be a deciding factor. If we want federation i= n the future it is of course better not to build inhibiting factors into ML= S now that could undermine either usability or security in such contexts. T= o make a case to proceed with the single group cipher option, it would be g= reat if someone could provide a convincing argument as to why it would be t= he best option for usability and security in the federated environment (or = preclude a federated use-case altogether). > >>>>>>>> > >>>>>>>> --- > >>>>>>>> > >>>>>>>> Britta > >>>>>>>> > >>>>>>>> > >>>>>>>> =EF=BB=BFOn 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CI= V)" wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Concerning the use of a single group signature scheme or individ= ual signature schemes, it is probably worthwhile to expand on the considera= tion points and clarify what security implications we are accepting - in ei= ther case. I have listed out some issues in the following Google doc: > >>>>>>>> > >>>>>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94= _pMtdSilIdFKw14/edit?usp=3Dsharing > >>>>>>>> > >>>>>>>> I am not making an argument for either case at this point, but p= ushing this out for discussion and to help us achieve more clarity as to th= e benefits and consequences of either choice. There are certainly more issu= es to consider (e.g. ease of implementation, efficiency, etc. in addition t= o security considerations) and other views - feel free to add them or discu= ss on the mailing list. > >>>>>>>> > >>>>>>>> All the best, > >>>>>>>> > >>>>>>>> Britta > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" wrote: > >>>>>>>> > >>>>>>>> Hi! > >>>>>>>> > >>>>>>>> tl;dr: confirming MTI suite selections and rationale for avo= iding proliferation > >>>>>>>> > >>>>>>>> During the F2F Interim in January, the WG discussed cipher s= uites-related issues. Namely, whether a per-group signature scheme should b= e driven by the chosen cipher suite, what were the MTI (Mandatory To Implem= ent) cipher suites, and what the actual algorithm should be. > >>>>>>>> > >>>>>>>> There was rough agreement that there should be one signature= scheme per group and that should be driven by the cipher suite. There are,= at least, three things to consider: 1) if a potential group member does no= t support the algorithm, then they will not become a member or the group wi= ll need to downgrade; 2) when the group needs/wants to update, it is a flag= day; and, 3) the cipher suites will have a similar combinatorial issues as= the TLS cipher suites prior to TLS 1.3. The agreement was =E2=80=9Crough= =E2=80=9D because 1) likely has some important implications. > >>>>>>>> > >>>>>>>> The MLS cipher suites defined were as follows: > >>>>>>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > >>>>>>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > >>>>>>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > >>>>>>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > >>>>>>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > >>>>>>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > >>>>>>>> > >>>>>>>> At the interim, the consensus was to make the non-NIST suite= s the MTI. The rationale was that those implementation that need to be NIS= T compliant will do so regardless of the choice made by the WG. > >>>>>>>> > >>>>>>>> In looking at the actual cipher suites, it was noted that th= e 256-bit schemes the SHA should be SHA-512. The rationale agreed was that = SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less o= peration. > >>>>>>>> > >>>>>>>> To avoid the proliferation of cipher suites, guidance will b= e provided to be conservative about allocating new code points. The consens= us at the interim was that the suites provided were minimal and provided go= od coverage for the known use cases: > >>>>>>>> - (X25519, AES-GCM, Ed25519) - Good for desktop > >>>>>>>> - (P-256, AES-GCM, P-256) - Compliance > >>>>>>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile > >>>>>>>> > >>>>>>>> The chairs need to confirm the interim=E2=80=99s consensus o= n list, so please let the WG know by 2359 UTC 20 February whether you disag= ree with these choices and why. > >>>>>>>> > >>>>>>>> NOTE: The final text will obviously be reviewed, but is bein= g composed as part of the following PR: > >>>>>>>> https://github.com/mlswg/mls-protocol/pull/279 > >>>>>>>> > >>>>>>>> NOTE: We combined these cipher suite related consensus point= s, but if we only come to consensus on some of these we can still incorpora= te what we do agree on. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> > >>>>>>>> Nick and Sean > >>>>>>>> _______________________________________________ > >>>>>>>> MLS mailing list > >>>>>>>> MLS@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> MLS mailing list > >>>>>>>> MLS@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> MLS mailing list > >>>>>>>> MLS@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> MLS mailing list > >>>>>>> MLS@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MLS mailing list > >>>>>> MLS@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>> > >>>>> _______________________________________________ > >>>>> MLS mailing list > >>>>> MLS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mls > >>>> > >>>> _______________________________________________ > >>>> MLS mailing list > >>>> MLS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mls > >>>> > >>> > >>> _______________________________________________ > >>> MLS mailing list > >>> MLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mls > >> > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Feb 26 11:53:33 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60C13A12F7 for ; Wed, 26 Feb 2020 11:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzvvIIFnARqw for ; Wed, 26 Feb 2020 11:53:29 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 682153A12F1 for ; Wed, 26 Feb 2020 11:53:29 -0800 (PST) X-ASG-Debug-ID: 1582746808-0e39454962ae350001-bGA3T6 Received: from mail.nps.edu (synergos.ern.nps.edu [172.20.4.116]) by mule.nps.edu with ESMTP id iDv9KmEHmbt8ZVeN; Wed, 26 Feb 2020 11:53:28 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Wed, 26 Feb 2020 11:53:28 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.104) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Wed, 26 Feb 2020 11:53:28 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lbVQCxqVkWA4uhGZg2vXpX8DHnuZxgvmLScdsfaNRMSRVg+UuY5S4E0mcYiOFQat9HlguhEp2FvLEVtdb1KJcm2k6iElkyudzCoj9sMw17sqv5gpeSDIcpypYoNba2T9FiReQ2NjhkAX33olR+XCO+wqSgMfO3ocS8zYmuMOGal0gGTGVGRiwOSSIqR9MQ+EAtUtrlqOIYXNoDYoh1UIE+R00+CHemI3BtLhJ+uATGxXdWCWguld96UtlTJOx65zJjfuS6locVfPy8IkAt0MmioaMpPHsWasJEhgNZGNcRooYyrj51auAQ4TAbMqtZ6+wkWgWbiP4zxJ2Zuia09E3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S6Glot8Gnrcvco71M33LIHRSfUj+EpKH4QzsR6WiZQQ=; b=ECucpAng1StMXJ6S4A/ok4CBYIENHy/9NldfRowvzf+obLAHnI437kGgIJuv/kOZT3W6En6AI7pzXTcl2TjJsTQkL7LE/UPChXtp7jriE5jGjn3GV5K2YfI1/stdB62fe5fE0Eojk6wd7LOW+bdeMioavYbgt4CD0UqBmV1vHIlKJXMg4L/J/yC/jpGwNbgcry7aNcFhvqPhPjSof5JhrTeubotTos+a0MVXnsdJERt3GDztmZj8Fh3F6q8ZuQaLbpj0Y63U0nYhn3WOPQUfqI+ZMeAvcyaM0+GTA/X8UzWkD038X6Wl4fTL2C9Z/rN858UYSoSigzb3Zh2HIOzAHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3876.namprd13.prod.outlook.com (2603:10b6:a03:22c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Wed, 26 Feb 2020 19:53:25 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 19:53:25 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:22c::11] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:22c::11 From: "Hale, Britta (CIV)" To: Benjamin Beurdouche , Cas Cremers CC: Karthik Bhargavan , "ML Messaging Layer Security" Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAAAOiAgAAB1oD//3uBAA== Date: Wed, 26 Feb 2020 19:53:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [88.203.39.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3be7fdaf-120f-435a-52e5-08d7baf58ad2 x-ms-traffictypediagnostic: BY5PR13MB3876: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(189003)(199004)(498600001)(66556008)(66476007)(66446008)(6506007)(186003)(64756008)(26005)(53546011)(86362001)(75432002)(5660300002)(66946007)(6512007)(6486002)(91956017)(76116006)(966005)(36756003)(81156014)(2616005)(4326008)(8676002)(110136005)(54906003)(30864003)(81166006)(2906002)(8936002)(71200400001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3876; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ANt8O6vfsdv114ELzV94tQAuWsuJwdg+YrsuZYk6VrEqs7NYe6WbTmBp/tphkJW9XFZNX3iROsOOae6nl8PUWcmNy/7kaEy4/ji0OSw+XUftb9lHW0lLulaaRcDBHNUpnX6mNuIokjuC21IBATPpj2AYElW9xwQGItwwBZHyOZxgrhaw+nIMHO4Ut3wHnzQcaINqSLwaNxbaKGYhQ10Q4iy4IpHzUeBKsC6X9NJSCAFnXq/n2qA+YPiDxqi61cZI7ZYjeyDmSLmW/M+fHgv4WwZSvWgL9YjE4oh/+trAQCVEg6i2QsFLeLKc+ozn+uugI/gUrQn9FWHIEUqi/H+ehgD1ZsrwMfvOlqPVLXI7I09IDQUNtyKdrs9jvd8+6TIh2wUQULLJjLdVOe2KzjmXOXp7FznlV2j88ec9h3eHGc+w7r/4gWFmyi1QSv54d5YawmNvVXdArJUB9CxS/DYBSEkKZVLNnXlx0MBg5CK1w/jtqn15fGUgcU3YtCOIvs5E4vCAX6cgu6IE6PCAw1Otjg== x-ms-exchange-antispam-messagedata: rdWTyr1eTW0COMIUmnd9csTlCjCFwP7UQlcb6zaXyqOWulR7TWGtvEI2KelWJzD5puwwFmfUvJebRHqzmErJDa6lpCfR03uW1fevAGVwzwRdmnxv9Sp4Z3TGzAYKQVdcLvtWiFR3KrdVSWkVFJhVzw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <21D62766F774EE4E9D06BD453C047B2C@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3be7fdaf-120f-435a-52e5-08d7baf58ad2 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 19:53:25.2749 (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: cc5imKGys07Im3LSw7XT1/etYgP4yuqpETvWaizCGSjhSvlgTlpZo2kHZRoRxM4dE9kremaSIU+dJRHMEh+4Gw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3876 X-OriginatorOrg: nps.edu X-Barracuda-Connect: synergos.ern.nps.edu[172.20.4.116] X-Barracuda-Start-Time: 1582746808 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 16994 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80278 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [MLS] confirming cipher suites decisions 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, 26 Feb 2020 19:53:32 -0000 QWN0dWFsbHkgdGhpcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgc2luZ2xlLXNjaGVtZSBvcHRpb24s IGFzIHRoZXJlIHRoZSBjaG9pY2UgaXMgZW50aXJlbHkgcmVzdHJpY3RlZCBhbmQgYW55IG5ld2Nv bWVyIGhhcyB0aGVpciBzaWduYXR1cmUgc2VjdXJpdHkgZGljdGF0ZWQuIEluIHRoaXMgb3B0aW9u IHRoZXJlIGFyZSBjaG9pY2VzIGZvciBuZXdjb21lcnMgLSBub3QgY29tcGxldGUgZnJlZWRvbSBv ZiBzY2hlbWUgc2VsZWN0aW9uLCBidXQgc29tZSBmcmVlZG9tLg0KDQpUaGlzIHNvdW5kcyBsaWtl IGEgZ29vZCBjb21wcm9taXNlIHRvIG1lIGFzIHdlbGwuIEdpdmluZyBuZXdjb21lcnMgb3B0aW9u cyBtYXkgcmVkdWNlIGRvd25ncmFkZSBpc3N1ZXMgYW1vbmcgb3RoZXIgdGhpbmdzLCB3aGlsZSB0 aGlzIGFsc28gc2V0cyBsaW1pdHMgb24gdGhlIHNjaGVtZSBzZWxlY3Rpb24uIEV2ZW4gaWYgdGhl cmUgYXJlIG9ubHkgYSBjb3VwbGUgc2lnbmF0dXJlIHNjaGVtZXMgaW4gb2ZmZXJlZCBhbGdvcml0 aG1zLCBtYW55IG9mIHRoZSBjb25jZXJucyBzdXJyb3VuZGluZyB0aGUgb3JpZ2luYWwgc2luZ2xl LXNjaGVtZSBvcHRpb24gd291bGQgYmUgYWxsZXZpYXRlZC4gDQoNCkJyaXR0YQ0KDQoNCg0K77u/ T24gMi8yNi8yMCwgODo0OCBQTSwgIk1MUyBvbiBiZWhhbGYgb2YgQmVuamFtaW4gQmV1cmRvdWNo ZSIgPG1scy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBiZW5qYW1pbi5iZXVyZG91Y2hl QGlucmlhLmZyPiB3cm90ZToNCg0KICAgIEl0IGlzIHdoYXQgd2UgY3VycmVudGx5IGRvLCB0aGUg cHJvYmxlbSBpcyBub3QgY3JlYXRpb24gb3IgdGhlIGluaXRpYWwgbWVtYmVycywgaXQgaXMgdGhl IG5ld2NvbWVycy4NCiAgICBCLg0KICAgIA0KICAgID4gT24gRmViIDI2LCAyMDIwLCBhdCA4OjQx IFBNLCBDYXMgQ3JlbWVycyA8Y2FzLmNyZW1lcnNAZ21haWwuY29tPiB3cm90ZToNCiAgICA+IA0K ICAgID4gSGksDQogICAgPiANCiAgICA+IEkgYWdyZWUgd2l0aCBLYXJ0aGlrJ3Mgc3VnZ2VzdGlv bjsgaW4gcHJhY3RpY2UgdGhpcyBtYXkgc2ltcGx5IGJlIHRoZQ0KICAgID4gaW50ZXJzZWN0aW9u IG9mIHRoZSBhbGdvcml0aG1zIHRoYXQgdGhlIGluaXRpYWwgbWVtYmVycyBzdXBwb3J0Lg0KICAg ID4gDQogICAgPiBCZXN0LA0KICAgID4gDQogICAgPiBDYXMNCiAgICA+IA0KICAgID4+IE9uIFdl ZCwgRmViIDI2LCAyMDIwIGF0IDg6MzcgUE0gS2FydGhpayBCaGFyZ2F2YW4NCiAgICA+PiA8a2Fy dGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPiB3cm90ZToNCiAgICA+PiANCiAgICA+PiBIZWxs byBBbGwsDQogICAgPj4gDQogICAgPj4gSSB0aGluayB3ZSBjb3VsZCBnbyBlaXRoZXIgd2F5OiBt dWx0aXBsZSBvciBzaW5nbGUgc2lnbmF0dXJlIGFsZ29yaXRobSBwZXIgZ3JvdXAuDQogICAgPj4g SG93ZXZlciwgSSB3b3VsZCBwcmVmZXIgaWYgd2UgcmVxdWlyZWQgKmFsbCogdGhlIGFsZ29yaXRo bXMgdGhhdCBncm91cCBtZW1iZXJzIG11c3Qgc3VwcG9ydCB0byBiZSBkZWNsYXJlZCB1cC1mcm9u dCBhdCBncm91cCBjcmVhdGlvbi4NCiAgICA+PiBUaGF0IGlzLCBteSBwcmVmZXJlbmNlIGlzIG5v dCB0byBhZGQgbmV3IHNpZ25hdHVyZSBhbGdvcml0aG1zIGFzIGEgZ3JvdXAgZXZvbHZlcyBhbmQg bmV3IG1lbWJlcnMgYXJlIGFkZGVkLg0KICAgID4+IA0KICAgID4+IFRoZSByYXRpb25hbGUgYmVo aW5kIHRoaXMgdGhpbmtpbmcgaXMgdGhhdCB3aGVuIGEgbWVtYmVyIGpvaW5zIGEgZ3JvdXAsIHNo ZSBjYW4gaW5zcGVjdCB0aGUgZ3JvdXDigJlzIHBhcmFtZXRlcnMgdG8gZGVjaWRlIHdoZXRoZXIg c2hlIHN1cHBvcnRzDQogICAgPj4gdGhlIGFsZ29yaXRobXMgbmVlZGVkIHRvIGNvbnZlcnNlIGlu IHRoZSBncm91cC4gSXQgd291bGQgYmUgd2VpcmQgaWYgdGhlIGdyb3VwIGFsbG93ZWQgYSBuZXcg bWVtYmVyIHdob3NlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWwgb3IgbWVzc2FnZSBzaWduYXR1 cmVzDQogICAgPj4gY2Fubm90IGJlIHByb2Nlc3NlZCBieSBleGlzdGluZyBtZW1iZXJzLiBBbmQg aXQgd291bGQgYmUgaGFyZCB0byB0cnkgdG8gZHluYW1pY2FsbHkgZGV0ZWN0IHRoZSBhbGdvcml0 aG1zIHRoYXQgdGhlIGdyb3VwIG1lbWJlcnMgc3VwcG9ydC4NCiAgICA+PiBJbnN0ZWFkLCBkZWNs YXJpbmcgYWxsICpyZXF1aXJlZCogYWxnb3JpdGhtcyBhdCBncm91cCBjcmVhdGlvbiBzZWVtcyBs aWtlIGEgc2FuZSBjaG9pY2UgdG8gbWUuDQogICAgPj4gDQogICAgPj4gLUthcnRoaWsNCiAgICA+ PiANCiAgICA+PiANCiAgICA+Pj4+IE9uIDI2IEZlYiAyMDIwLCBhdCAxOTo0OCwgQ2FzIENyZW1l cnMgPGNhcy5jcmVtZXJzQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPj4+IA0KICAgID4+PiBIaSwN CiAgICA+Pj4gDQogICAgPj4+IFRoaXMgaXMgYSB0cmlja3kgb25lLiBJIHRoaW5rIGFsbG93aW5n IG11bHRpcGxlIHNpZ25hdHVyZSBzY2hlbWVzIHBlcg0KICAgID4+PiBncm91cCBjYW4gaW1wcm92 ZSBzZWN1cml0eSBpbiBzdWJ0bGUgd2F5cywgZXNwZWNpYWxseSBpbiBsYXJnZSBncm91cHMNCiAg ICA+Pj4gd2l0aCBwb3RlbnRpYWxseSBkaXZlcnNlIGNsaWVudHMuDQogICAgPj4+IA0KICAgID4+ PiBJIHVuZGVyc3RhbmQgcGFydCBvZiB0aGUgIm9uZSBzY2hlbWUgcGVyIGdyb3VwIGlzIHNpbXBs ZXIiIGFyZ3VtZW50LCBidXQNCiAgICA+Pj4gSSBhbSBub3Qgc3VyZSBpdCBpcyBzaW1wbGVyIGlu IHByYWN0aWNlLCBzaW5jZSBpdCBwdXRzIG1vcmUgd2VpZ2h0IG9uDQogICAgPj4+IHRoZSBjaG9p Y2Ugb2YgdGhlIGluaXRpYXRvcnMgb2YgdGhlIGdyb3VwLCBhbmQgbWlnaHQgY29tcGxpY2F0ZSBh ZGRpbmcNCiAgICA+Pj4gZ3JvdXAgbWVtYmVycyBhZnRlcndhcmRzLiBJIGRvbid0IHRoaW5rIGl0 IGlzIGEgYmxvY2tpbmcgZmFjdG9yIGZvciBhbnkNCiAgICA+Pj4gYW5hbHlzaXMgZWl0aGVyLg0K ICAgID4+PiANCiAgICA+Pj4gU28gSSBoYXZlICphIHNsaWdodCBwcmVmZXJlbmNlIGZvciBhbGxv d2luZyBtdWx0aXBsZSBzaWduYXR1cmUgc2NoZW1lcw0KICAgID4+PiBwZXIgZ3JvdXAqLCBmcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiBmYWNpbGl0YXRpbmcgbGFyZ2UgZGl2ZXJzZSBncm91cHMgaW4N CiAgICA+Pj4gdGhlIGZ1dHVyZSwgYW5kIHRoZSBwb3RlbnRpYWwgbG9jYWwgc2VjdXJpdHkgYmVu ZWZpdHMuDQogICAgPj4+IA0KICAgID4+PiBCdXQgSSBkZWZpbml0ZWx5IGFncmVlIHdpdGggUmlj aGFyZCB0aGF0IHRoaXMgY2FuIGJlIGEgc21hbGwgY2hhbmdlDQogICAgPj4+IGxhdGVyLCBhbmQg ZG9lc24ndCBzZWVtIHRvIGJlIHNvbWUgZnVuZGFtZW50YWwgZGVzaWduIGNob2ljZSB0aGF0IGNh bm5vdA0KICAgID4+PiBiZSByZXZlcnRlZC9yZWxheGVkL3RpZ2h0ZW5lZCBsYXRlcjsgSSBhbHNv IGNhcmUgYWJvdXQgcHJvZ3Jlc3MsIHNvDQogICAgPj4+IGxldCdzIHBpY2sgc29tZXRoaW5nIGZv ciBub3cuDQogICAgPj4+IA0KICAgID4+PiBCZXN0LA0KICAgID4+PiANCiAgICA+Pj4gQ2FzDQog ICAgPj4+IA0KICAgID4+PiANCiAgICA+Pj4gDQogICAgPj4+IA0KICAgID4+PiANCiAgICA+Pj4g T24gMi8yNi8yMCA3OjI0IFBNLCBCZW5qYW1pbiBCZXVyZG91Y2hlIHdyb3RlOg0KICAgID4+Pj4g SSB3b3VsZCBzdHJvbmdseSBwcmVmZXIgb25lIHNpZ25hdHVyZSBzY2hlbWUgZm9yIHRoZSBsaWZl dGltZSBvZiB0aGUgZ3JvdXAuDQogICAgPj4+PiBCLg0KICAgID4+Pj4gDQogICAgPj4+Pj4gT24g MjYgRmViIDIwMjAsIGF0IDE3OjI4LCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+IHdyb3Rl Og0KICAgID4+Pj4+IA0KICAgID4+Pj4+IFRoZXJlIHNlZW1zIHRvIGJlIHJvdWdoIGNvbnNlbnN1 cyAoc3RyZXNzaW5nIHRoZSByb3VnaCkgdG8gZ28gd2l0aCBvbmUgc2NoZW1lIHBlciBncm91cC4g Qnkgcm91Z2ggY29uc2Vuc3VzLCBJIG1lYW4gdGhlcmUgc2VlbXMgdG8gYmUgYSB3aWxsaW5nbmVz cyBieSB0aGUgZ3JvdXAgdG8gbGl2ZSB3aXRoIHRoaXMgZGVjaXNpb24gYW5kIG5vYm9keSBpcyBz dXBlciBiZW50IG91dCBvZiBzaGFwZSBhYm91dCBpdC4gVGVjaG5pY2FsbHksIHRoYXTigJlzIGFs bCB3ZSBuZWVkIHRvIG1vdmUgZm9yd2FyZCwgYnV0IHRoZXJlIGFyZSBzb21lIGNvbmNlcm5zIGNv bmNlcm5zIHRoYXQgc2luY2UgaXTigJlzIHN1Y2ggYSBzbWFsbCBncm91cCBhbmQgdGhlcmUgYXJl IHNvIGZldyBzdHJvbmcgdm9pY2VzIGZvciB0aGUgY2hvaWNlIHRoYXQgd2Ugc2hvdWxkIGdpdmUg aXQganVzdCBhIGJpdCBtb3JlIHRpbWUuIFNvLCBJIGFtIGV4dGVuZGluZyB0aGlzIGNhbGwgdW50 aWwgMjM1OSBVVEMgMiBNYXJjaCAoaS5lLiwgTW9uZGF5IG5pZ2h0KS4NCiAgICA+Pj4+PiANCiAg ICA+Pj4+PiBBbHNvLCB0aGVyZSBhcmUgcmVhbGx5IHRocmVlIGNpcGhlcnN1aXRlLXJlbGF0ZWQg ZGVjaXNpb25zIGJlaW5nIG1hZGUsIGFzIG5vdGVkIGluIHRoZSBlbWFpbCBiZWxvdy4NCiAgICA+ Pj4+PiANCiAgICA+Pj4+PiBzcHQNCiAgICA+Pj4+PiANCiAgICA+Pj4+Pj4gT24gRmViIDI1LCAy MDIwLCBhdCAxMzoyNCwgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+IHdyb3RlOg0KICAgID4+ Pj4+PiANCiAgICA+Pj4+Pj4gSSB3aWxsIG5vdCBiZSBhYmxlIHRvIG1ha2UgdGhlIGNhbGwgdG9t b3Jyb3csIHNvIHRvIHN1bW1hcml6ZSBteSBvcGluaW9uIG9uIHRoaXM6DQogICAgPj4+Pj4+IA0K ICAgID4+Pj4+PiAqIEkgYW0gT0sgd2l0aCBtZXJnaW5nIHRoZSBjdXJyZW50IFBSDQogICAgPj4+ Pj4+ICogSSBoYXZlIGEgc2xpZ2h0IHByZWZlcmVuY2UgZm9yICpub3QqIGluY2x1ZGluZyB0aGUg c2lnIGFsZyBpbiB0aGUgY2lwaGVyc3VpdGUNCiAgICA+Pj4+Pj4gKiBUaGUgc2ltcGxpY2l0eSBj YXNlIGZvciBpbmNsdWRpbmcgaXQgc2VlbXMgcmVhc29uYWJsZSwgYnV0IG5vdCBkaXNwb3NpdGl2 ZQ0KICAgID4+Pj4+PiAqIEluIGFueSBjYXNlLCBJIGRvbid0IGNhcmUgc3Ryb25nbHkgb25lIHdh eSBvciBhbm90aGVyOyBJIGNhcmUgbW9yZSBhYm91dCBwcm9ncmVzcw0KICAgID4+Pj4+PiAqIFRo aXMgaXMgYW4gZWFzeSBjaGFuZ2UgdG8gcmV2ZXJ0IGlmIHdlIGNoYW5nZSBvdXIgbWluZHMgbGF0 ZXINCiAgICA+Pj4+Pj4gKiBDcmVkZW50aWFscyBhcmUgZ29pbmcgdG8gaW5kaWNhdGUgdGhlIHNp Z25hdHVyZSBhbGdvcml0aG0gYW55d2F5DQogICAgPj4+Pj4+ICogU28gdGhlIG9ubHkgZGlmZmVy ZW5jZSBpbiBzcGVjIGlzIHdoZXRoZXIgZW5kcG9pbnRzIGNoZWNrIENyZWRlbnRpYWwuU2lnQWxn b3JpdGhtID09IENpcGhlclN1aXRlLlNpZ0FsZ29yaXRobQ0KICAgID4+Pj4+PiANCiAgICA+Pj4+ Pj4gDQogICAgPj4+Pj4+IE9uIFR1ZSwgRmViIDI1LCAyMDIwIGF0IDEyOjQzIFBNIFNlYW4gVHVy bmVyIDxzZWFuQHNuM3JkLmNvbT4gd3JvdGU6DQogICAgPj4+Pj4+IE5vdGUgdGhhdCB0aGUgbWFp biBwb2ludCBvZiB0aGUgdGVsZWNvbiB0b21vcnJvdyBpcyB0byBhZGRyZXNzIHRoZSBjaXBoZXIg c3VpdGUgaXNzdWUuICBQbGVhc2UgdGFrZSB0aGUgdGltZSB0byByZXZpZXc6DQogICAgPj4+Pj4+ IC0gdGhlIHJlbGF0ZWQgUFJzOg0KICAgID4+Pj4+PiBodHRwczovL2dpdGh1Yi5jb20vbWxzd2cv bWxzLXByb3RvY29sL3B1bGwvMjc5DQogICAgPj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3 Zy9tbHMtcHJvdG9jb2wvcHVsbC8zMDcNCiAgICA+Pj4+Pj4gLSB0aGUgbWVzc2FnZXMgaW4gdGhp cyB0aHJlYWQNCiAgICA+Pj4+Pj4gLSB0aGUgaXNzdWVzIEJyaXR0YSBvdXRsaW5lZDoNCiAgICA+ Pj4+Pj4gaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xWkRzNEtHcDBfNmtwUVpw UkpfdDRrVmxtZ0E5NF9wTXRkU2lsSWRGS3cxNC9lZGl0P3VzcD1zaGFyaW5nDQogICAgPj4+Pj4+ IA0KICAgID4+Pj4+PiBXZSB3b3VsZCBsaWtlIHRvIGNsb3NlIHRoaXMgaXNzdWUgb3V0IHRvbW9y cm93Lg0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gQ2hlZXJzLA0KICAgID4+Pj4+PiANCiAgICA+ Pj4+Pj4gc3B0DQogICAgPj4+Pj4+IA0KICAgID4+Pj4+Pj4gT24gRmViIDE5LCAyMDIwLCBhdCAw MTowOSwgS29ucmFkIEtvaGJyb2sgPGtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU+IHdyb3Rl Og0KICAgID4+Pj4+Pj4gDQogICAgPj4+Pj4+PiBIaSBCcml0dGEsDQogICAgPj4+Pj4+PiANCiAg ICA+Pj4+Pj4+IEkgdGhpbmsgeW91IHN1bSBpdCB1cCB2ZXJ5IG5pY2VseS4gVGhlcmUgaXMgb25l IChhbGJlaXQgc29tZXdoYXQgc3BlY3VsYXRpdmUpDQogICAgPj4+Pj4+PiBhcmd1bWVudCB3aHkg YSBzaW5nbGUgY2lwaGVyc3VpdGUgcGVyIGdyb3VwIG1pZ2h0IGFjdHVhbGx5IGJlIGJlbmVmaWNp YWwgaW4gYQ0KICAgID4+Pj4+Pj4gZmVkZXJhdGlvbiBjb250ZXh0LiBJbiB0aGUgZXZlbnQgdGhh dCB0aGVyZSBpcyAiZ2xvYmFsIGNvbmNlbnN1cyIgdGhhdCBhDQogICAgPj4+Pj4+PiBjaXBoZXJz dWl0ZSBuZWVkcyB0byBiZSBkZXByZWNhdGVkLCBteSBleHBlY3RhdGlvbiB3b3VsZCBiZSB0aGF0 IGEgbWFqb3JpdHkgb2YNCiAgICA+Pj4+Pj4+IHRoZSBmZWRlcmF0aW9uIG5vZGVzL2FwcGxpY2F0 aW9uIHByb3ZpZGVycyB3b3VsZCBtb3ZlIHRvIGJhbiB0aG9zZSBjaXBoZXJzdWl0cywNCiAgICA+ Pj4+Pj4+IGV4Y2x1ZGluZyBhbnlvbmUgd2hvIHdvdWxkIHVzZSBfZXhjbHVzaXZlbHlfIHRoYXQg Y2lwaGVyc3VpdGUuIFRoYXQgd291bGQgaW4NCiAgICA+Pj4+Pj4+IHR1cm4gYmUgYSBtb3RpdmF0 aW9uIGZvciBhbGwgb3RoZXIgbm9kZXMvYXBwbGljYXRpb24gcHJvdmlkZXJzIHRvIGNhdGNoIHVw IGFzDQogICAgPj4+Pj4+PiB3ZWxsLiBUaGlzIGFsc28gbWVhbnMgdGhhdCBub2RlcyBjYW4ndCBi ZSBtYWRlIChieSB3aGF0ZXZlciBhdXRob3JpdHkpIHRvIHVzZQ0KICAgID4+Pj4+Pj4gd2VhayBj aXBoZXJzdWl0ZXMgZXhjbHVzaXZlbHkgYW5kIHN0aWxsIGV4cGVjdCB0byBmZWRlcmF0ZSB3aXRo IG90aGVyIG5vZGVzIHRoYXQNCiAgICA+Pj4+Pj4+IGhhdmUgbW9yZSBzZW5zaWJsZSBwb2xpY2ll cy4NCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gVGhhdCdzIG1vc3RseSBteSBndWVzcyBvZiBo b3cgdGhlIGR5bmFtaWNzIGluIHN1Y2ggYSBmZWRlcmF0ZWQgZW52aXJvbm1lbnQNCiAgICA+Pj4+ Pj4+IF9jb3VsZF8gd29yaywgdGhvdWdoLiBBbnlvbmUgaGVyZSB3aXRoIHNvbWUgYWN0dWFsIGV4 cGVyaWVuY2UvZXhwZXJ0aXNlIHRoZXkgY2FuDQogICAgPj4+Pj4+PiBzaGFyZSBvZiB3aGF0IHRo ZSBkeW5hbWljcyBjb3VsZCBiZT8NCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gT3ZlcmFsbCwg SSB0aGluayBJJ20gaW4gZmF2b3Igb2Ygb25lLWNpcGhlcnN1aXRlLXBlci1ncm91cC4gSXQganVz dCBzZWVtcyBhIGxvdA0KICAgID4+Pj4+Pj4gc2ltcGxlciBhbmQgZXZlbiBpbiB0aGUgY29udGV4 dCBvZiBmZWRlcmF0aW9uLCBJIHRoaW5rIHRoYXQgbW9zdA0KICAgID4+Pj4+Pj4gbm9kZXMvYXBw bGljYXRpb24gcHJvdmlkZXJzIHdvdWxkIGFsbG93IHNldmVyYWwgY2lwaGVyc3VpdGVzIHRvIGJl Z2luIHdpdGgsDQogICAgPj4+Pj4+PiB3aGVyZSBub3QgYWxsIG9mIHRoZW0gYXJlIHdlYWssIG1l YW5pbmcgbm8gb25lIHdvdWxkIHJlYWxseSBiZSBleGNsdWRlZCB0b28gcXVpY2tseS4NCiAgICA+ Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gQ2hlZXJzLA0KICAgID4+Pj4+Pj4gS29ucmFkDQogICAgPj4+ Pj4+PiANCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gT24gMTguMDIuMjAgMjE6MDAsIEhhbGUs IEJyaXR0YSAoQ0lWKSB3cm90ZToNCiAgICA+Pj4+Pj4+PiBVbmRlciB0aGUgdG9waWMgb2YgaW5k aXZpZHVhbC9zaW5nbGUgc2lnbmF0dXJlIHNjaGVtZXMgdGhlcmUgaXMgdGhlIGZpbmFsIGlzc3Vl IG9mIGZlZGVyYXRpb24uIEluIGEgZmVkZXJhdGVkIGNvbnRleHQsIGdyb3VwcyBhcmUgbm8gbG9u Z2VyIHVuZGVyIHRoZSBjb250cm9sIG9mIGEgc2luZ2xlIGFwcGxpY2F0aW9uLCBtZWFuaW5nIHRo YXQgd2Ugd291bGQgbG9zZSBzb21lIGNvbnRyb2wgaW4gZm9yY2luZyBnb29kIGNpcGhlcnN1aXRl IGNob2ljZXMuIFRoaXMgY291bGQgbGVhZCB0byB0d28gaXNzdWVzOg0KICAgID4+Pj4+Pj4+IA0K ICAgID4+Pj4+Pj4+IDEpIE1MUyB3b3VsZCBtb3ZlIGNsb3NlciB0byBmYWNpbmcgdGhlIFRMUyBw cm9ibGVtIG9mIGhhdmluZyBvbGQgc3VpdGVzIHN1cHBvcnRlZCBieSBlZGdlIGNhc2VzLCB3aGlj aCBpbiB0dXJuIHdlYWtlbiB0aGUgZW50aXJlIGdyb3VwJ3Mgc2VjdXJpdHkuIFRoZXJlIGlzIGFs d2F5cyB0aGUgYXJndW1lbnQgdGhhdCBncm91cHMgd291bGQgc2ltcGx5IHJlZnVzZSBqb2luZXJz IHRoYXQgZG8gbm90IHN1cHBvcnQgdGhlIGN1cnJlbnQgZ3JvdXAgY2lwaGVyLCBidXQgdGhpcyBp cyBub3QgdmVyeSBwcmFjdGljYWwgZnJvbSBhIHVzYWJpbGl0eSB2aWV3LiBFLmcuIGlmIGV2ZXJ5 b25lIHVzaW5nIGFwcGxpY2F0aW9uIFggcmVmdXNlZCBncm91cCBtZW1iZXJzIHdobyB3ZXJlIHVz aW5nIGFwcGxpY2F0aW9uIFksIHRoZW4gdGhlIHBvaW50IG9mIGZlZGVyYXRpb24gd291bGQgYmUg bGFyZ2VseSBkZWZlYXRlZC4gU28sIGVpdGhlciBzb21lIGZvcm0gb2YgcmVuZWdvdGlhdGlvbiBp cyBhbGxvd2VkIChlLmcuIGV4cG9ydCBwc2spIGFuZCBkb3duZ3JhZGUgYmVjb21lcyBtb3JlIGxp a2VseSwgb3IgZmVkZXJhdGlvbiBkb2VzIG5vdCB3b3JrIHJlbGlhYmx5Lg0KICAgID4+Pj4+Pj4+ IA0KICAgID4+Pj4+Pj4+IDIpIEhlYWxpbmcgd291bGQgdGFrZSBsb25nZXIuIFNpbmNlIG5vIG9u ZSBhcHBsaWNhdGlvbiBoYXMgYSBtYXN0ZXIgdmlldyBhbmQgY29udHJvbCBvdmVyIGNpcGhlcnN1 aXRlcywgdXBncmFkaW5nIGxvbmctbGl2ZWQgZ3JvdXBzIHVzaW5nIHF1ZXN0aW9uYWJsZSBjaXBo ZXJzIGNvdWxkIHRha2UgYSBzaWduaWZpY2FudCBhbW91bnQgb2YgdGltZSAoYWxsIGFwcGxpY2F0 aW9ucyB3b3VsZCBuZWVkIHRvIGRvIHNvIGluIG9yZGVyIGZvciB0aGUgZ3JvdXAgdG8gdXBncmFk ZSkgb3IgYWx0ZXJuYXRpdmVseSByZXN1bHQgaW4ga2lja2luZyBncm91cCBtZW1iZXJzIG91dCBv ZiB0aGUgZ3JvdXAgKGFnYWluLCBwb3NzaWJsZSwgYnV0IHF1ZXN0aW9uYWJsZSBmb3IgdXNhYmls aXR5IGV4Y2VwdCBpbiBleHRyZW1lIGNhc2VzKS4gVW5kZXIgYW4gaW5kaXZpZHVhbCBjaXBoZXIg Y2hvaWNlLCBhbnkgb25lIG1lbWJlciBjYW4gY2hvb3NlL3VwZ3JhZGUgdGhlaXIgc2NoZW1lLCBh bGxvd2luZyBmb3IgZmFzdGVyIGFkYXB0YWJpbGl0eSBhbmQgcG90ZW50aWFsIGJlbmVmaXRzIHRv IFBDUy4NCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiBGcm9tIHRoZSBhYm92ZSwgaXQgc2Vl bXMgdGhhdCBhIHNpbmdsZSBncm91cCBjaXBoZXIgbWFrZXMgZmVkZXJhdGlvbiBoYXJkZXIvc2xv d2VyL2xlc3Mgc2VjdXJlLCBidXQgSSBtYXkgbm90IGhhdmUgYSBjbGVhciB2aWV3IG9uIGhvdyBm ZWRlcmF0aW9uIHdvdWxkIHdvcmsgaW4gdGhpcyBjb250ZXh0LiBEb2VzIGFueW9uZSBrbm93IHdo ZXRoZXIgdGhlIGFib3ZlIGFyZSByZWFsbHkgY29uY2VybnMgb3Igbm90IHJlbGV2YW50IGR1ZSB0 byBvdGhlciByZWFzb25zPw0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+IChOb3RlIHRoYXQg dGhpcyBpcyB0aGlua2luZyBpbiB0aGUgbG9uZy10ZXJtIGNvbnRleHQuIE9idmlvdXNseSB3ZSBk byBub3Qgd2FudCB0byBzdGFuZGFyZGl6ZSBhbnkgY2lwaGVyIGNob2ljZSB0aGF0IGlzIHN1Yi1v cHRpbWFsOyBob3dldmVyIGFueSBudW1iZXIgb2YgdGhpbmdzIG1heSBoYXBwZW4gd2l0aCBwcm90 b2NvbCB2ZXJzaW9uaW5nIGFuZCBjaXBoZXIgYnJlYWtzIG92ZXIgdGhlIHNwYW4gb2Ygc2V2ZXJh bCB5ZWFycy4pDQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4gVW5kZXIgYWxsIHRoZSBjb25z aWRlcmF0aW9ucyB0aGF0IEkgaGF2ZSBzZWVuIHNvIGZhciwgdGhlIHByb3MgYW5kIGNvbnMgb24g Ym90aCBzaWRlcyBwbGFjZSB0aGUgaW5kaXZpZHVhbCBzaWduYXR1cmUgY2lwaGVyIG9wdGlvbiBp biB0aGUgbGVhZC4gSG93ZXZlciB0aGF0IGxlYWQgaXMgc21hbGwsIGhlbmNlIHdoeSBJIGhhdmUg bm90IGJlZW4gYXJndWluZyBmb3IgaXQuIFRoZSBpc3N1ZSBvZiBmZWRlcmF0aW9uIGNvdWxkIGJl IGEgZGVjaWRpbmcgZmFjdG9yLiBJZiB3ZSB3YW50IGZlZGVyYXRpb24gaW4gdGhlIGZ1dHVyZSBp dCBpcyBvZiBjb3Vyc2UgYmV0dGVyIG5vdCB0byBidWlsZCBpbmhpYml0aW5nIGZhY3RvcnMgaW50 byBNTFMgbm93IHRoYXQgY291bGQgdW5kZXJtaW5lIGVpdGhlciB1c2FiaWxpdHkgb3Igc2VjdXJp dHkgaW4gc3VjaCBjb250ZXh0cy4gVG8gbWFrZSBhIGNhc2UgdG8gcHJvY2VlZCB3aXRoIHRoZSBz aW5nbGUgZ3JvdXAgY2lwaGVyIG9wdGlvbiwgaXQgd291bGQgYmUgZ3JlYXQgaWYgc29tZW9uZSBj b3VsZCBwcm92aWRlIGEgY29udmluY2luZyBhcmd1bWVudCBhcyB0byB3aHkgaXQgd291bGQgYmUg dGhlIGJlc3Qgb3B0aW9uIGZvciB1c2FiaWxpdHkgYW5kIHNlY3VyaXR5IGluIHRoZSBmZWRlcmF0 ZWQgZW52aXJvbm1lbnQgKG9yIHByZWNsdWRlIGEgZmVkZXJhdGVkIHVzZS1jYXNlIGFsdG9nZXRo ZXIpLg0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+IC0tLQ0KICAgID4+Pj4+Pj4+IA0KICAg ID4+Pj4+Pj4+IEJyaXR0YQ0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+ Pj4+IE9uIDIvMTIvMjAsIDg6MDEgQU0sICJNTFMgb24gYmVoYWxmIG9mIEhhbGUsIEJyaXR0YSAo Q0lWKSIgPG1scy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBicml0dGEuaGFsZUBucHMu ZWR1PiB3cm90ZToNCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiBIaSwNCiAgICA+Pj4+Pj4+ PiANCiAgICA+Pj4+Pj4+PiBDb25jZXJuaW5nIHRoZSB1c2Ugb2YgYSBzaW5nbGUgZ3JvdXAgc2ln bmF0dXJlIHNjaGVtZSBvciBpbmRpdmlkdWFsIHNpZ25hdHVyZSBzY2hlbWVzLCBpdCBpcyBwcm9i YWJseSB3b3J0aHdoaWxlIHRvIGV4cGFuZCBvbiB0aGUgY29uc2lkZXJhdGlvbiBwb2ludHMgYW5k IGNsYXJpZnkgd2hhdCBzZWN1cml0eSBpbXBsaWNhdGlvbnMgd2UgYXJlIGFjY2VwdGluZyAtIGlu IGVpdGhlciBjYXNlLiBJIGhhdmUgbGlzdGVkIG91dCBzb21lIGlzc3VlcyBpbiB0aGUgZm9sbG93 aW5nIEdvb2dsZSBkb2M6DQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4gaHR0cHM6Ly9kb2Nz Lmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xWkRzNEtHcDBfNmtwUVpwUkpfdDRrVmxtZ0E5NF9wTXRk U2lsSWRGS3cxNC9lZGl0P3VzcD1zaGFyaW5nDQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4g SSBhbSBub3QgbWFraW5nIGFuIGFyZ3VtZW50IGZvciBlaXRoZXIgY2FzZSBhdCB0aGlzIHBvaW50 LCBidXQgcHVzaGluZyB0aGlzIG91dCBmb3IgZGlzY3Vzc2lvbiBhbmQgdG8gaGVscCB1cyBhY2hp ZXZlIG1vcmUgY2xhcml0eSBhcyB0byB0aGUgYmVuZWZpdHMgYW5kIGNvbnNlcXVlbmNlcyBvZiBl aXRoZXIgY2hvaWNlLiBUaGVyZSBhcmUgY2VydGFpbmx5IG1vcmUgaXNzdWVzIHRvIGNvbnNpZGVy IChlLmcuIGVhc2Ugb2YgaW1wbGVtZW50YXRpb24sIGVmZmljaWVuY3ksIGV0Yy4gaW4gYWRkaXRp b24gdG8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMpIGFuZCBvdGhlciB2aWV3cyAtIGZlZWwgZnJl ZSB0byBhZGQgdGhlbSBvciBkaXNjdXNzIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQogICAgPj4+Pj4+ Pj4gDQogICAgPj4+Pj4+Pj4gQWxsIHRoZSBiZXN0LA0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+ Pj4+IEJyaXR0YQ0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+IE9u IDIvNi8yMCwgODoxMSBBTSwgIk1MUyBvbiBiZWhhbGYgb2YgU2VhbiBUdXJuZXIiIDxtbHMtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc2VhbkBzbjNyZC5jb20+IHdyb3RlOg0KICAgID4+ Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+ICAgICBIaSENCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+ PiAgICAgdGw7ZHI6IGNvbmZpcm1pbmcgTVRJIHN1aXRlIHNlbGVjdGlvbnMgYW5kIHJhdGlvbmFs ZSBmb3IgYXZvaWRpbmcgcHJvbGlmZXJhdGlvbg0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+ ICAgICBEdXJpbmcgdGhlIEYyRiBJbnRlcmltIGluIEphbnVhcnksIHRoZSBXRyBkaXNjdXNzZWQg Y2lwaGVyIHN1aXRlcy1yZWxhdGVkIGlzc3Vlcy4gTmFtZWx5LCB3aGV0aGVyIGEgcGVyLWdyb3Vw IHNpZ25hdHVyZSBzY2hlbWUgc2hvdWxkIGJlIGRyaXZlbiBieSB0aGUgY2hvc2VuIGNpcGhlciBz dWl0ZSwgd2hhdCB3ZXJlIHRoZSBNVEkgKE1hbmRhdG9yeSBUbyBJbXBsZW1lbnQpIGNpcGhlciBz dWl0ZXMsIGFuZCB3aGF0IHRoZSBhY3R1YWwgYWxnb3JpdGhtIHNob3VsZCBiZS4NCiAgICA+Pj4+ Pj4+PiANCiAgICA+Pj4+Pj4+PiAgICAgVGhlcmUgd2FzIHJvdWdoIGFncmVlbWVudCB0aGF0IHRo ZXJlIHNob3VsZCBiZSBvbmUgc2lnbmF0dXJlIHNjaGVtZSBwZXIgZ3JvdXAgYW5kIHRoYXQgc2hv dWxkIGJlIGRyaXZlbiBieSB0aGUgY2lwaGVyIHN1aXRlLiBUaGVyZSBhcmUsIGF0IGxlYXN0LCB0 aHJlZSB0aGluZ3MgdG8gY29uc2lkZXI6IDEpIGlmIGEgcG90ZW50aWFsIGdyb3VwIG1lbWJlciBk b2VzIG5vdCBzdXBwb3J0IHRoZSBhbGdvcml0aG0sIHRoZW4gdGhleSB3aWxsIG5vdCBiZWNvbWUg YSBtZW1iZXIgb3IgdGhlIGdyb3VwIHdpbGwgbmVlZCB0byBkb3duZ3JhZGU7IDIpIHdoZW4gdGhl IGdyb3VwIG5lZWRzL3dhbnRzIHRvIHVwZGF0ZSwgaXQgaXMgYSBmbGFnIGRheTsgYW5kLCAzKSB0 aGUgY2lwaGVyIHN1aXRlcyB3aWxsIGhhdmUgYSBzaW1pbGFyIGNvbWJpbmF0b3JpYWwgaXNzdWVz IGFzIHRoZSBUTFMgY2lwaGVyIHN1aXRlcyBwcmlvciB0byBUTFMgMS4zLiBUaGUgYWdyZWVtZW50 IHdhcyDigJxyb3VnaOKAnSBiZWNhdXNlIDEpIGxpa2VseSBoYXMgc29tZSBpbXBvcnRhbnQgaW1w bGljYXRpb25zLg0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+ICAgICBUaGUgTUxTIGNpcGhl ciBzdWl0ZXMgZGVmaW5lZCB3ZXJlIGFzIGZvbGxvd3M6DQogICAgPj4+Pj4+Pj4gICAgIC0gTUxT MTBfMTI4X0hQS0VYMjU1MTlfQUVTMTI4R0NNX1NIQTI1Nl9FZDI1NTE5DQogICAgPj4+Pj4+Pj4g ICAgIC0gTUxTMTBfMTI4X0hQS0VQMjU2X0FFUzEyOEdDTV9TSEEyNTZfUDI1Ng0KICAgID4+Pj4+ Pj4+ICAgICAtIE1MUzEwXzEyOF9IUEtFWDI1NTE5X0NIQUNIQTIwUE9MWTEzMDVfU0hBMjU2X0Vk MjU1MTkNCiAgICA+Pj4+Pj4+PiAgICAgLSBNTFMxMF8yNTZfSFBLRVg0NDhfQUVTMjU2R0NNX1NI QTM4NF9FZDQ0OA0KICAgID4+Pj4+Pj4+ICAgICAtIE1MUzEwXzI1Nl9IUEtFUDUyMV9BRVMyNTZH Q01fU0hBMzg0X1A1MjENCiAgICA+Pj4+Pj4+PiAgICAgLSBNTFMxMF8yNTZfSFBLRVg0NDhfQ0hB Q0hBMjBQT0xZMTMwNV9TSEEzODRfRWQ0NDgNCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiAg ICAgQXQgdGhlIGludGVyaW0sIHRoZSBjb25zZW5zdXMgd2FzIHRvIG1ha2UgdGhlIG5vbi1OSVNU IHN1aXRlcyB0aGUgTVRJLiAgVGhlIHJhdGlvbmFsZSB3YXMgdGhhdCB0aG9zZSBpbXBsZW1lbnRh dGlvbiB0aGF0IG5lZWQgdG8gYmUgTklTVCBjb21wbGlhbnQgd2lsbCBkbyBzbyByZWdhcmRsZXNz IG9mIHRoZSBjaG9pY2UgbWFkZSBieSB0aGUgV0cuDQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+ Pj4gICAgIEluIGxvb2tpbmcgYXQgdGhlIGFjdHVhbCBjaXBoZXIgc3VpdGVzLCBpdCB3YXMgbm90 ZWQgdGhhdCB0aGUgMjU2LWJpdCBzY2hlbWVzIHRoZSBTSEEgc2hvdWxkIGJlIFNIQS01MTIuIFRo ZSByYXRpb25hbGUgYWdyZWVkIHdhcyB0aGF0IFNIQS0zODQgaXMgU0hBLTUxMiBjdXQgaW4gaGFs Ziwgc28ganVzdCBkbyBTSEEtNTEyIGJlY2F1c2UgaXQgaXMgb25lIGxlc3Mgb3BlcmF0aW9uLg0K ICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+ICAgICBUbyBhdm9pZCB0aGUgcHJvbGlmZXJhdGlv biBvZiBjaXBoZXIgc3VpdGVzLCBndWlkYW5jZSB3aWxsIGJlIHByb3ZpZGVkIHRvIGJlIGNvbnNl cnZhdGl2ZSBhYm91dCBhbGxvY2F0aW5nIG5ldyBjb2RlIHBvaW50cy4gVGhlIGNvbnNlbnN1cyBh dCB0aGUgaW50ZXJpbSB3YXMgdGhhdCB0aGUgc3VpdGVzIHByb3ZpZGVkIHdlcmUgbWluaW1hbCBh bmQgcHJvdmlkZWQgZ29vZCBjb3ZlcmFnZSBmb3IgdGhlIGtub3duIHVzZSBjYXNlczoNCiAgICA+ Pj4+Pj4+PiAgICAgLSAoWDI1NTE5LCBBRVMtR0NNLCBFZDI1NTE5KSAtIEdvb2QgZm9yIGRlc2t0 b3ANCiAgICA+Pj4+Pj4+PiAgICAgLSAoUC0yNTYsIEFFUy1HQ00sIFAtMjU2KSAtIENvbXBsaWFu Y2UNCiAgICA+Pj4+Pj4+PiAgICAgLSAoWDI1NTE5LCBDaGFjaGFQb2x5LCBFZDI1NTE5KSAtIEdv b2QgZm9yIG1vYmlsZQ0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+ICAgICBUaGUgY2hhaXJz IG5lZWQgdG8gY29uZmlybSB0aGUgaW50ZXJpbeKAmXMgY29uc2Vuc3VzIG9uIGxpc3QsIHNvIHBs ZWFzZSBsZXQgdGhlIFdHIGtub3cgYnkgMjM1OSBVVEMgMjAgRmVicnVhcnkgd2hldGhlciB5b3Ug ZGlzYWdyZWUgd2l0aCB0aGVzZSBjaG9pY2VzIGFuZCB3aHkuDQogICAgPj4+Pj4+Pj4gDQogICAg Pj4+Pj4+Pj4gICAgIE5PVEU6IFRoZSBmaW5hbCB0ZXh0IHdpbGwgb2J2aW91c2x5IGJlIHJldmll d2VkLCBidXQgaXMgYmVpbmcgY29tcG9zZWQgYXMgcGFydCBvZiB0aGUgZm9sbG93aW5nIFBSOg0K ICAgID4+Pj4+Pj4+ICAgICBodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1 bGwvMjc5DQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4gICAgIE5PVEU6IFdlIGNvbWJpbmVk IHRoZXNlIGNpcGhlciBzdWl0ZSByZWxhdGVkIGNvbnNlbnN1cyBwb2ludHMsIGJ1dCBpZiB3ZSBv bmx5IGNvbWUgdG8gY29uc2Vuc3VzIG9uIHNvbWUgb2YgdGhlc2Ugd2UgY2FuIHN0aWxsIGluY29y cG9yYXRlIHdoYXQgd2UgZG8gYWdyZWUgb24uDQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4g ICAgIENoZWVycywNCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiAgICAgTmljayBhbmQgU2Vh bg0KICAgID4+Pj4+Pj4+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgID4+Pj4+Pj4+ICAgICBNTFMgbWFpbGluZyBsaXN0DQogICAgPj4+Pj4+ Pj4gICAgIE1MU0BpZXRmLm9yZw0KICAgID4+Pj4+Pj4+ICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21scw0KICAgID4+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4+IA0KICAg ID4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgPj4+Pj4+Pj4gTUxTIG1haWxpbmcgbGlzdA0KICAgID4+Pj4+Pj4+IE1MU0BpZXRmLm9y Zw0KICAgID4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxz DQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4gDQogICAgPj4+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+Pj4+PiBNTFMgbWFp bGluZyBsaXN0DQogICAgPj4+Pj4+Pj4gTUxTQGlldGYub3JnDQogICAgPj4+Pj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAgICA+Pj4+Pj4+PiANCiAgICA+ Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICA+Pj4+Pj4+IE1MUyBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+Pj4+IE1M U0BpZXRmLm9yZw0KICAgID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbHMNCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4+Pj4+IE1MUyBtYWlsaW5nIGxpc3QNCiAg ICA+Pj4+Pj4gTUxTQGlldGYub3JnDQogICAgPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWxzDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+PiBNTFMgbWFpbGluZyBs aXN0DQogICAgPj4+Pj4gTUxTQGlldGYub3JnDQogICAgPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAgICA+Pj4+IA0KICAgID4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4+IE1MUyBtYWlsaW5n IGxpc3QNCiAgICA+Pj4+IE1MU0BpZXRmLm9yZw0KICAgID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAgICA+Pj4+IA0KICAgID4+PiANCiAgICA+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4gTUxT IG1haWxpbmcgbGlzdA0KICAgID4+PiBNTFNAaWV0Zi5vcmcNCiAgICA+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAgICA+PiANCiAgICA+IA0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IE1MUyBt YWlsaW5nIGxpc3QNCiAgICA+IE1MU0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIE1MUyBtYWlsaW5nIGxpc3QNCiAgICBNTFNA aWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21scw0K ICAgIA0KDQo= From nobody Wed Feb 26 23:36:32 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D023A13F5 for ; Wed, 26 Feb 2020 23:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0zVjW-5DExMt for ; Wed, 26 Feb 2020 23:36:27 -0800 (PST) Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050::465:202]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AFF3A13EE for ; Wed, 26 Feb 2020 23:36:27 -0800 (PST) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 48Skxj1knKzQlFX for ; Thu, 27 Feb 2020 08:36:25 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id QQWx1cXdyh-E for ; Thu, 27 Feb 2020 08:36:18 +0100 (CET) To: mls@ietf.org References: From: Konrad Kohbrok Message-ID: Date: Thu, 27 Feb 2020 09:36:18 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 07:36:31 -0000 I also think this is a good compromise. I'm curious to see what the dynamic will be in a federated environment when one or more signature schemes turn out to be weak (or no one wants to use pre-quantum crypto anymore) and what people's policy on group-reboots will be in that scenario. I don't think there is precedence for such a system and we can't predict too much of that now, so it's good to go for a compromise. Konrad On 26/02/2020 21:53, Hale, Britta (CIV) wrote: > Actually this is different from the single-scheme option, as there the choice is entirely restricted and any newcomer has their signature security dictated. In this option there are choices for newcomers - not complete freedom of scheme selection, but some freedom. > > This sounds like a good compromise to me as well. Giving newcomers options may reduce downgrade issues among other things, while this also sets limits on the scheme selection. Even if there are only a couple signature schemes in offered algorithms, many of the concerns surrounding the original single-scheme option would be alleviated. > > Britta > > > > On 2/26/20, 8:48 PM, "MLS on behalf of Benjamin Beurdouche" wrote: > > It is what we currently do, the problem is not creation or the initial members, it is the newcomers. > B. > > > On Feb 26, 2020, at 8:41 PM, Cas Cremers wrote: > > > > Hi, > > > > I agree with Karthik's suggestion; in practice this may simply be the > > intersection of the algorithms that the initial members support. > > > > Best, > > > > Cas > > > >> On Wed, Feb 26, 2020 at 8:37 PM Karthik Bhargavan > >> wrote: > >> > >> Hello All, > >> > >> I think we could go either way: multiple or single signature algorithm per group. > >> However, I would prefer if we required *all* the algorithms that group members must support to be declared up-front at group creation. > >> That is, my preference is not to add new signature algorithms as a group evolves and new members are added. > >> > >> The rationale behind this thinking is that when a member joins a group, she can inspect the group’s parameters to decide whether she supports > >> the algorithms needed to converse in the group. It would be weird if the group allowed a new member whose authentication credential or message signatures > >> cannot be processed by existing members. And it would be hard to try to dynamically detect the algorithms that the group members support. > >> Instead, declaring all *required* algorithms at group creation seems like a sane choice to me. > >> > >> -Karthik > >> > >> > >>>> On 26 Feb 2020, at 19:48, Cas Cremers wrote: > >>> > >>> Hi, > >>> > >>> This is a tricky one. I think allowing multiple signature schemes per > >>> group can improve security in subtle ways, especially in large groups > >>> with potentially diverse clients. > >>> > >>> I understand part of the "one scheme per group is simpler" argument, but > >>> I am not sure it is simpler in practice, since it puts more weight on > >>> the choice of the initiators of the group, and might complicate adding > >>> group members afterwards. I don't think it is a blocking factor for any > >>> analysis either. > >>> > >>> So I have *a slight preference for allowing multiple signature schemes > >>> per group*, from the perspective of facilitating large diverse groups in > >>> the future, and the potential local security benefits. > >>> > >>> But I definitely agree with Richard that this can be a small change > >>> later, and doesn't seem to be some fundamental design choice that cannot > >>> be reverted/relaxed/tightened later; I also care about progress, so > >>> let's pick something for now. > >>> > >>> Best, > >>> > >>> Cas > >>> > >>> > >>> > >>> > >>> > >>> On 2/26/20 7:24 PM, Benjamin Beurdouche wrote: > >>>> I would strongly prefer one signature scheme for the lifetime of the group. > >>>> B. > >>>> > >>>>> On 26 Feb 2020, at 17:28, Sean Turner wrote: > >>>>> > >>>>> There seems to be rough consensus (stressing the rough) to go with one scheme per group. By rough consensus, I mean there seems to be a willingness by the group to live with this decision and nobody is super bent out of shape about it. Technically, that’s all we need to move forward, but there are some concerns concerns that since it’s such a small group and there are so few strong voices for the choice that we should give it just a bit more time. So, I am extending this call until 2359 UTC 2 March (i.e., Monday night). > >>>>> > >>>>> Also, there are really three ciphersuite-related decisions being made, as noted in the email below. > >>>>> > >>>>> spt > >>>>> > >>>>>> On Feb 25, 2020, at 13:24, Richard Barnes wrote: > >>>>>> > >>>>>> I will not be able to make the call tomorrow, so to summarize my opinion on this: > >>>>>> > >>>>>> * I am OK with merging the current PR > >>>>>> * I have a slight preference for *not* including the sig alg in the ciphersuite > >>>>>> * The simplicity case for including it seems reasonable, but not dispositive > >>>>>> * In any case, I don't care strongly one way or another; I care more about progress > >>>>>> * This is an easy change to revert if we change our minds later > >>>>>> * Credentials are going to indicate the signature algorithm anyway > >>>>>> * So the only difference in spec is whether endpoints check Credential.SigAlgorithm == CipherSuite.SigAlgorithm > >>>>>> > >>>>>> > >>>>>> On Tue, Feb 25, 2020 at 12:43 PM Sean Turner wrote: > >>>>>> Note that the main point of the telecon tomorrow is to address the cipher suite issue. Please take the time to review: > >>>>>> - the related PRs: > >>>>>> https://github.com/mlswg/mls-protocol/pull/279 > >>>>>> https://github.com/mlswg/mls-protocol/pull/307 > >>>>>> - the messages in this thread > >>>>>> - the issues Britta outlined: > >>>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing > >>>>>> > >>>>>> We would like to close this issue out tomorrow. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> spt > >>>>>> > >>>>>>> On Feb 19, 2020, at 01:09, Konrad Kohbrok wrote: > >>>>>>> > >>>>>>> Hi Britta, > >>>>>>> > >>>>>>> I think you sum it up very nicely. There is one (albeit somewhat speculative) > >>>>>>> argument why a single ciphersuite per group might actually be beneficial in a > >>>>>>> federation context. In the event that there is "global concensus" that a > >>>>>>> ciphersuite needs to be deprecated, my expectation would be that a majority of > >>>>>>> the federation nodes/application providers would move to ban those ciphersuits, > >>>>>>> excluding anyone who would use _exclusively_ that ciphersuite. That would in > >>>>>>> turn be a motivation for all other nodes/application providers to catch up as > >>>>>>> well. This also means that nodes can't be made (by whatever authority) to use > >>>>>>> weak ciphersuites exclusively and still expect to federate with other nodes that > >>>>>>> have more sensible policies. > >>>>>>> > >>>>>>> That's mostly my guess of how the dynamics in such a federated environment > >>>>>>> _could_ work, though. Anyone here with some actual experience/expertise they can > >>>>>>> share of what the dynamics could be? > >>>>>>> > >>>>>>> Overall, I think I'm in favor of one-ciphersuite-per-group. It just seems a lot > >>>>>>> simpler and even in the context of federation, I think that most > >>>>>>> nodes/application providers would allow several ciphersuites to begin with, > >>>>>>> where not all of them are weak, meaning no one would really be excluded too quickly. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Konrad > >>>>>>> > >>>>>>> > >>>>>>> On 18.02.20 21:00, Hale, Britta (CIV) wrote: > >>>>>>>> Under the topic of individual/single signature schemes there is the final issue of federation. In a federated context, groups are no longer under the control of a single application, meaning that we would lose some control in forcing good ciphersuite choices. This could lead to two issues: > >>>>>>>> > >>>>>>>> 1) MLS would move closer to facing the TLS problem of having old suites supported by edge cases, which in turn weaken the entire group's security. There is always the argument that groups would simply refuse joiners that do not support the current group cipher, but this is not very practical from a usability view. E.g. if everyone using application X refused group members who were using application Y, then the point of federation would be largely defeated. So, either some form of renegotiation is allowed (e.g. export psk) and downgrade becomes more likely, or federation does not work reliably. > >>>>>>>> > >>>>>>>> 2) Healing would take longer. Since no one application has a master view and control over ciphersuites, upgrading long-lived groups using questionable ciphers could take a significant amount of time (all applications would need to do so in order for the group to upgrade) or alternatively result in kicking group members out of the group (again, possible, but questionable for usability except in extreme cases). Under an individual cipher choice, any one member can choose/upgrade their scheme, allowing for faster adaptability and potential benefits to PCS. > >>>>>>>> > >>>>>>>> From the above, it seems that a single group cipher makes federation harder/slower/less secure, but I may not have a clear view on how federation would work in this context. Does anyone know whether the above are really concerns or not relevant due to other reasons? > >>>>>>>> > >>>>>>>> (Note that this is thinking in the long-term context. Obviously we do not want to standardize any cipher choice that is sub-optimal; however any number of things may happen with protocol versioning and cipher breaks over the span of several years.) > >>>>>>>> > >>>>>>>> Under all the considerations that I have seen so far, the pros and cons on both sides place the individual signature cipher option in the lead. However that lead is small, hence why I have not been arguing for it. The issue of federation could be a deciding factor. If we want federation in the future it is of course better not to build inhibiting factors into MLS now that could undermine either usability or security in such contexts. To make a case to proceed with the single group cipher option, it would be great if someone could provide a convincing argument as to why it would be the best option for usability and security in the federated environment (or preclude a federated use-case altogether). > >>>>>>>> > >>>>>>>> --- > >>>>>>>> > >>>>>>>> Britta > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2/12/20, 8:01 AM, "MLS on behalf of Hale, Britta (CIV)" wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Concerning the use of a single group signature scheme or individual signature schemes, it is probably worthwhile to expand on the consideration points and clarify what security implications we are accepting - in either case. I have listed out some issues in the following Google doc: > >>>>>>>> > >>>>>>>> https://docs.google.com/document/d/1ZDs4KGp0_6kpQZpRJ_t4kVlmgA94_pMtdSilIdFKw14/edit?usp=sharing > >>>>>>>> > >>>>>>>> I am not making an argument for either case at this point, but pushing this out for discussion and to help us achieve more clarity as to the benefits and consequences of either choice. There are certainly more issues to consider (e.g. ease of implementation, efficiency, etc. in addition to security considerations) and other views - feel free to add them or discuss on the mailing list. > >>>>>>>> > >>>>>>>> All the best, > >>>>>>>> > >>>>>>>> Britta > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2/6/20, 8:11 AM, "MLS on behalf of Sean Turner" wrote: > >>>>>>>> > >>>>>>>> Hi! > >>>>>>>> > >>>>>>>> tl;dr: confirming MTI suite selections and rationale for avoiding proliferation > >>>>>>>> > >>>>>>>> During the F2F Interim in January, the WG discussed cipher suites-related issues. Namely, whether a per-group signature scheme should be driven by the chosen cipher suite, what were the MTI (Mandatory To Implement) cipher suites, and what the actual algorithm should be. > >>>>>>>> > >>>>>>>> There was rough agreement that there should be one signature scheme per group and that should be driven by the cipher suite. There are, at least, three things to consider: 1) if a potential group member does not support the algorithm, then they will not become a member or the group will need to downgrade; 2) when the group needs/wants to update, it is a flag day; and, 3) the cipher suites will have a similar combinatorial issues as the TLS cipher suites prior to TLS 1.3. The agreement was “rough” because 1) likely has some important implications. > >>>>>>>> > >>>>>>>> The MLS cipher suites defined were as follows: > >>>>>>>> - MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 > >>>>>>>> - MLS10_128_HPKEP256_AES128GCM_SHA256_P256 > >>>>>>>> - MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519 > >>>>>>>> - MLS10_256_HPKEX448_AES256GCM_SHA384_Ed448 > >>>>>>>> - MLS10_256_HPKEP521_AES256GCM_SHA384_P521 > >>>>>>>> - MLS10_256_HPKEX448_CHACHA20POLY1305_SHA384_Ed448 > >>>>>>>> > >>>>>>>> At the interim, the consensus was to make the non-NIST suites the MTI. The rationale was that those implementation that need to be NIST compliant will do so regardless of the choice made by the WG. > >>>>>>>> > >>>>>>>> In looking at the actual cipher suites, it was noted that the 256-bit schemes the SHA should be SHA-512. The rationale agreed was that SHA-384 is SHA-512 cut in half, so just do SHA-512 because it is one less operation. > >>>>>>>> > >>>>>>>> To avoid the proliferation of cipher suites, guidance will be provided to be conservative about allocating new code points. The consensus at the interim was that the suites provided were minimal and provided good coverage for the known use cases: > >>>>>>>> - (X25519, AES-GCM, Ed25519) - Good for desktop > >>>>>>>> - (P-256, AES-GCM, P-256) - Compliance > >>>>>>>> - (X25519, ChachaPoly, Ed25519) - Good for mobile > >>>>>>>> > >>>>>>>> The chairs need to confirm the interim’s consensus on list, so please let the WG know by 2359 UTC 20 February whether you disagree with these choices and why. > >>>>>>>> > >>>>>>>> NOTE: The final text will obviously be reviewed, but is being composed as part of the following PR: > >>>>>>>> https://github.com/mlswg/mls-protocol/pull/279 > >>>>>>>> > >>>>>>>> NOTE: We combined these cipher suite related consensus points, but if we only come to consensus on some of these we can still incorporate what we do agree on. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> > >>>>>>>> Nick and Sean > >>>>>>>> _______________________________________________ > >>>>>>>> MLS mailing list > >>>>>>>> MLS@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> MLS mailing list > >>>>>>>> MLS@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> MLS mailing list > >>>>>>>> MLS@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> MLS mailing list > >>>>>>> MLS@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MLS mailing list > >>>>>> MLS@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mls > >>>>> > >>>>> _______________________________________________ > >>>>> MLS mailing list > >>>>> MLS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mls > >>>> > >>>> _______________________________________________ > >>>> MLS mailing list > >>>> MLS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mls > >>>> > >>> > >>> _______________________________________________ > >>> MLS mailing list > >>> MLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mls > >> > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Thu Feb 27 01:03:44 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38B53A1592 for ; Thu, 27 Feb 2020 01:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DHvorMuPhzOB for ; Thu, 27 Feb 2020 01:03:39 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F453A1591 for ; Thu, 27 Feb 2020 01:03:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,491,1574118000"; d="scan'208,217,223";a="340571110" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 10:03:35 +0100 From: Benjamin Beurdouche Message-Id: <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_EBD010A4-CD13-4383-A64B-C2BF552D3646" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Thu, 27 Feb 2020 10:03:35 +0100 In-Reply-To: <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> Cc: Karthikeyan Bhargavan , ML Messaging Layer Security To: Cas Cremers , Britta Hale , Konrad Kohbrok References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 09:03:42 -0000 --Apple-Mail=_EBD010A4-CD13-4383-A64B-C2BF552D3646 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =46rom the last messages, I think my answer to Cas was misleading=E2=80=A6= R1. Joining a group without supporting all the crypto is unacceptable R2. Allowing a system where clients all advertise the MTI ciphersuite and where the newcomers cannot join should be unacceptable. Goal of MLS: we want everybody to be able to build a group and talk = securely to everybody else. No need for security if people can=E2=80=99t create = groups because of algorithm fragmentation. > On 26 Feb 2020, at 20:37, Karthik Bhargavan = > = wrote: >=20 > Hello All, >=20 > I think we could go either way: multiple or single signature algorithm = per group. > However, I would prefer if we required *all* the algorithms that group = members must support to be declared up-front at group creation. This is currently the case that =E2=80=9Cthat all the algorithm that = group members must support to be declared at group creation" and it is also the root cause of = potential fragmentation. If the creator takes the responsibility of explicitly picking something = else than the MTI ciphersuite they take the risk explicitly to break interop and break R2, but that is = fine. If we went for the scheme such as picking a list which contains more = than the MTI, even at group creation, *only clients supporting everything* would be allowed to = join otherwise breaking R1. To me this Is unacceptable. That is why we want to restrict this set to a minimum: in my case to = *one* ciphersuite. The largest set the creator will pick, the more difficult it will be for = new member to join the group. > That is, my preference is not to add new signature algorithms as a = group evolves and new members are added. That was never an option. > The rationale behind this thinking is that when a member joins a = group, she can inspect the group=E2=80=99s parameters to decide whether = she supports > the algorithms needed to converse in the group. It would be weird if = the group allowed a new member whose authentication credential or = message signatures > cannot be processed by existing members. If the newcomer doesn=E2=80=99t support enough, but just the MTI, they = may never join which is unacceptable, as everyone else has to support the MTI, R2. > And it would be hard to try to dynamically detect the algorithms that = the group members support. > Instead, declaring all *required* algorithms at group creation seems = like a sane choice to me. So again, requiring to support more, is not only a dangerous idea = regarding implementations, but is dangerous for interoperability and fragmentation. Moreover this new proposal is not solving any of the current problems I = have with the multiple algorithms approach I had in my previous message: ----- 1. agility causes a lot of problems: I don=E2=80=99t think I need to = remind people of the TLS story https://hal.inria.fr/hal-01114250 = 2. interop fragmentation: this is not a two party protocol where = membership is set forever. If a single member does not support one crypto scheme, this member might = never be able to join an hybrid group. 3. security: I clearly don=E2=80=99t believe we should assume anything = from the security of the protocol in the case a cryptographic scheme is broken. I don=E2=80=99t want to = get to a point where we have horrible downgrade stories and I would clearly want to kill and restart the entire group I think fragmentation is my main worry actually, and if we figure out = that we were wrong, adding more agility is likely to be more easy than removing it. So my intuition is that we should proceed with one signature scheme for = the lifetime of the group and make sure we have a solid story to export and reconstruct a group, = which we need anyway. B. --Apple-Mail=_EBD010A4-CD13-4383-A64B-C2BF552D3646 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =46ro= m the last messages, I think my answer to Cas was misleading=E2=80=A6

R1. = Joining a group without supporting all the crypto is = unacceptable
R2. Allowing a system where clients all advertise = the MTI ciphersuite
and where the newcomers cannot join should = be unacceptable.

Goal of MLS: we = want everybody to be able to build a group and talk = securely
to everybody else. No need for security if people = can=E2=80=99t create groups because of
algorithm = fragmentation.

On 26 Feb 2020, at 20:37, = Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> wrote:

Hello = All,

I think we could go either way: = multiple or single signature algorithm per group.
However, = I would prefer if we required *all* the algorithms that group members = must support to be declared up-front at group creation.

This = is currently the case that =E2=80=9Cthat all the algorithm that group = members must support
to be declared at group creation" and it = is also the root cause of potential fragmentation.

If the creator takes the responsibility of = explicitly picking something else than the MTI = ciphersuite
they take the risk explicitly to break interop and = break R2, but that is fine.

If we = went for the scheme such as picking a list which contains more than the = MTI, even at
group creation, *only clients supporting = everything* would be allowed to join otherwise breaking = R1.

To me this Is = unacceptable.
That is why we want to restrict this set to = a minimum: in my case to *one* ciphersuite.
The largest set = the creator will pick, the more difficult it will be for new member to = join the group.

That is, my = preference is not to add new signature algorithms as a group evolves and = new members are added.

That was never an option.

The rationale behind this thinking is that when a member = joins a group, she can inspect the group=E2=80=99s parameters to decide = whether she supports
the algorithms needed to converse in = the group. It would be weird if the group allowed a new member whose = authentication credential or message signatures
cannot be = processed by existing members.

If the newcomer doesn=E2=80=99t support enough, = but just the MTI, they may never join which is
unacceptable, = as everyone else has to support the MTI, R2.

And it would be hard to try to dynamically detect the = algorithms that the group members support.
Instead, = declaring all *required* algorithms at group creation seems like a sane = choice to me.

So = again, requiring to support more, is not only a dangerous idea regarding = implementations,
but is dangerous for interoperability and = fragmentation.

Moreover this new = proposal is not solving any of the current problems I have with the = multiple
algorithms approach I had in my previous = message:
-----

1. agility = causes a lot of problems: I don=E2=80=99t think I need to remind people = of the TLS story https://hal.inria.fr/hal-01114250

2. interop fragmentation: this is not a two party protocol = where membership is set forever.
If a single member does = not support one crypto scheme, this member might never be able to join = an hybrid group.

3. security: I clearly = don=E2=80=99t believe we should assume anything from the security of the = protocol
in the case a cryptographic scheme is broken. I = don=E2=80=99t want to get to a point where we have horrible downgrade = stories
and I would clearly want to kill and restart the = entire group

I think fragmentation is my = main worry actually, and if we figure out that we were wrong,
adding more agility is likely to be more easy than removing = it.

So my intuition is that we should = proceed with one signature scheme for the lifetime of the group
and make sure we have a solid story to export and reconstruct = a group, which we need anyway.

B.



= --Apple-Mail=_EBD010A4-CD13-4383-A64B-C2BF552D3646-- From nobody Thu Feb 27 01:58:06 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB13A16EE for ; Thu, 27 Feb 2020 01:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-237tR4uY3b for ; Thu, 27 Feb 2020 01:57:59 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 592423A16E9 for ; Thu, 27 Feb 2020 01:57:59 -0800 (PST) X-ASG-Debug-ID: 1582797478-0e39454964c8890001-bGA3T6 Received: from mail.nps.edu (synergos.ern.nps.edu [172.20.4.116]) by mule.nps.edu with ESMTP id trw7D6ANEMjFr5j6; Thu, 27 Feb 2020 01:57:58 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from skywalker.ern.nps.edu (172.20.4.117) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Thu, 27 Feb 2020 01:57:58 -0800 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Thu, 27 Feb 2020 01:57:58 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FU06tPi9EnGNAdVRn9dE32wpCpdJLXa5eCqwg/ZqzwnIxXgxtg9BNbjsjla/kEIoO+IrJkZKvvnq2ISKmlNqRC48wWqJUeP84d2QYWPqHlt//5FK8B2jc7vnzTpwM8Y0rj7SOCQdfyG75VDQODVyqqTaZYDF36f1JbG/Ohg8iM62QDTx5gURWmA88QkT3d9KNi36NHSYYY+cBeDl9MdgYVdhCsY25qmZtS839By1JyM2bSTV7/o0eV09wuUkwP8gO57kCbrpSnrKMnhOUKeQcg3vQGhl4cUOXmwVGSIaQ8rcukWDUJUSzkKtTkF8KsYFsBYA64Rl32Xh7VaY26KG0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=96gJp0MulT95Z+AIpZ9PU7EG4IECcm/xry3S7boDqWQ=; b=T/TLTy+AgmNtxB4dd91hDzWVy9X2D9iB9LkbenK56zsNa+QDYlOBBqUnsCHmTnp+hYeJ2ZQwHz2FGoGa9MV4DymTkvD1HqGpWvduYkJHpUaBwKpiibpPFJDv8bUNRWQ2OTgXr36mO1pk6FF5UMpn8IibdSfVKFwd6fsmaz97JnM6V2SkGm2ZfbnbviEmtSEFXbJaHzu+XIb3UDcuN/kYl/H3r02mMeYenhA2ZuqjGdsQcr/ivjmu072CyJoRp9JYlYtqt/AkMOsvGJh+zSqse3UOIMSogHdu0xsp7I5PrvGMCO7aBHUnBadWbiBiKjzJqP5ssmCPaFf55X3F+EnZQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3315.namprd13.prod.outlook.com (2603:10b6:a03:1a1::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.5; Thu, 27 Feb 2020 09:57:54 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 09:57:54 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:1a1::28] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:1a1::28 From: "Hale, Britta (CIV)" To: Benjamin Beurdouche , Cas Cremers , Karthik Bhargavan CC: ML Messaging Layer Security , Konrad Kohbrok Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAA4SKA//+JDYA= Date: Thu, 27 Feb 2020 09:57:54 +0000 Message-ID: References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> In-Reply-To: <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [195.158.89.246] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de3b5b02-8ee3-483d-422d-08d7bb6b8414 x-ms-traffictypediagnostic: BY5PR13MB3315: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39840400004)(396003)(366004)(346002)(376002)(136003)(189003)(199004)(66946007)(76116006)(71200400001)(8936002)(8676002)(81166006)(81156014)(75432002)(5660300002)(4326008)(91956017)(2906002)(66476007)(6506007)(53546011)(478600001)(786003)(36756003)(316002)(54906003)(64756008)(966005)(66446008)(66556008)(86362001)(110136005)(6486002)(26005)(33656002)(6512007)(2616005)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3315; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W5+YrZ2f3oqVUN0GJV/JxIhisPoUP+903YFc4sBtrikE6aoPM1/pVbRsDM3J1NqpCrtrzQRDk7g+hQv9lC1eGwJK9WFCaISn6cUIzpqtyxkukN+IUkD4uvqWwwTygyEL+H9KU0/x2WNCPp7ZLa6VjVYDu1g5Zu3SrirvLdbiK6p7O+K/lQWxGJfS+4ng4yHTSelhyDje80t7zac5h1gsGNo0YYUz4oapCU97QacIRCSj7kiCIy/BTXbBxnCVxsGS04GGfzcg9y9tu3sh/pGKmQmYwiDyKPZOPMsqtzcMGjMg5UoXL3tH7pM0EoY2Tbwl57cRHY0bz18amn9ILffp9i+watb/QFt/YTvSxbxCUC8mXn1HFrzkFv3OApX/kMwF0i1Xz7HkTn8Bl5IfJhRQzANXv588lgwaTEn+cjbssRl4P+U27nOyDsRBpEzFs0TBQXis6e1L6/HibfKCbessDRcdxYd8roZHl5XyCLIYuv3ZZ69rlpnozm1PSC9aP6/qyXXIw7t5QZqfurxg0hOkiQ== x-ms-exchange-antispam-messagedata: 53tn4/87w5q9VA6BiJtlBjuqFqDA8ITZJvWJl65q3NoKooFT6EBao3hXGBf6oqPe5NCiK09sRI/2zoBLKF/bnibhwRMlzV9HieRtLITTyHHlg+sL239KrBTeK+IduaixUE+WL1HzKG/RcO1lFGClCg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A6881857406E45E9BEC7823E15633619npsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: de3b5b02-8ee3-483d-422d-08d7bb6b8414 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 09:57:54.6770 (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: lmhbdphQ+Yi5eYrRFxCkgkuSyIZuWugXI6OIFCMfoNJWPCaXNJHq3l6lJ+A9EtlQscEeIAIjAWsZr5QX22AXdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3315 X-OriginatorOrg: nps.edu X-Barracuda-Connect: synergos.ern.nps.edu[172.20.4.116] X-Barracuda-Start-Time: 1582797478 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 15154 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80292 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 09:58:06 -0000 --_000_A6881857406E45E9BEC7823E15633619npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVuamFtaW4sDQoNClRoZSBpc3N1ZXMgeW91IGRlc2NyaWJlIGFyZSBwcmltYXJpbHkgVExTLXR5 cGUgcHJvYmxlbXMsIHdoZXJlIHVuY29udHJvbGxlZCwgbGFyZ2Utc2NhbGUgYWdpbGl0eSBhbmQg aW50ZXJvcCBpc3N1ZXMgZXhpc3QuIEFzIGhhcyBiZWVuIHN0YXRlZCBpbiB0aGUgd29ya2luZyBn cm91cCBhcyBhIHN1cHBvcnRpbmcgYXJndW1lbnQgdG8gbWFueSBjaGFuZ2VzIG92ZXIgdGhlIGRp ZmZlcmVudCBkcmFmdHMsIHdpdGhpbiB0aGUgbWVzc2FnaW5nL01MUyBzcGFjZSB3ZSBhcmUgbG9v a2luZyBhdCBzaWduaWZpY2FudGx5IG1vcmUgY2xpZW50LXNwZWNpZmljIGNvbnRyb2wuIEl0IGlz IG5vdCB1bnJlYXNvbmFibGUgZm9yIGEgbmV3Y29tZXIgdG8gc3VwcG9ydCBhIHNlbGVjdGlvbiBv ZiBzaWduYXR1cmUgc2NoZW1lcy4gSWYgdGhlIGdyb3VwIGNyZWF0b3IgcmVhbGx5IHdhbnRzIGZ1 bGwgaW50ZXJvcCwgdGhleSBjYW4gYWx3YXlzIGRlZmluZSB0aGUgc2V0IG9mIGF2YWlsYWJsZSBz Y2hlbWVzIHRvIGNvbnNpc3Qgb25seSBvZiB0aGUgTVRJLg0KDQoNCkJyaXR0YQ0KDQoNCg0KDQpG cm9tOiBCZW5qYW1pbiBCZXVyZG91Y2hlIDxiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPg0K RGF0ZTogVGh1cnNkYXksIEZlYnJ1YXJ5IDI3LCAyMDIwIGF0IDEwOjAzIEFNDQpUbzogQ2FzIENy ZW1lcnMgPGNhcy5jcmVtZXJzQGdtYWlsLmNvbT4sICJIYWxlLCBCcml0dGEgKENJVikiIDxicml0 dGEuaGFsZUBucHMuZWR1PiwgS29ucmFkIEtvaGJyb2sgPGtvbnJhZC5rb2hicm9rQGRhdGFzaHJp bmUuZGU+DQpDYzogS2FydGhpa2V5YW4gQmhhcmdhdmFuIDxrYXJ0aGlrZXlhbi5iaGFyZ2F2YW5A aW5yaWEuZnI+LCBNTCBNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgPG1sc0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbTUxTXSBjb25maXJtaW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zDQoNCkZy b20gdGhlIGxhc3QgbWVzc2FnZXMsIEkgdGhpbmsgbXkgYW5zd2VyIHRvIENhcyB3YXMgbWlzbGVh ZGluZ+KApg0KDQpSMS4gSm9pbmluZyBhIGdyb3VwIHdpdGhvdXQgc3VwcG9ydGluZyBhbGwgdGhl IGNyeXB0byBpcyB1bmFjY2VwdGFibGUNClIyLiBBbGxvd2luZyBhIHN5c3RlbSB3aGVyZSBjbGll bnRzIGFsbCBhZHZlcnRpc2UgdGhlIE1USSBjaXBoZXJzdWl0ZQ0KYW5kIHdoZXJlIHRoZSBuZXdj b21lcnMgY2Fubm90IGpvaW4gc2hvdWxkIGJlIHVuYWNjZXB0YWJsZS4NCg0KR29hbCBvZiBNTFM6 IHdlIHdhbnQgZXZlcnlib2R5IHRvIGJlIGFibGUgdG8gYnVpbGQgYSBncm91cCBhbmQgdGFsayBz ZWN1cmVseQ0KdG8gZXZlcnlib2R5IGVsc2UuIE5vIG5lZWQgZm9yIHNlY3VyaXR5IGlmIHBlb3Bs ZSBjYW7igJl0IGNyZWF0ZSBncm91cHMgYmVjYXVzZSBvZg0KYWxnb3JpdGhtIGZyYWdtZW50YXRp b24uDQoNCk9uIDI2IEZlYiAyMDIwLCBhdCAyMDozNywgS2FydGhpayBCaGFyZ2F2YW4gPGthcnRo aWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcjxtYWlsdG86a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlu cmlhLmZyPj4gd3JvdGU6DQoNCkhlbGxvIEFsbCwNCg0KSSB0aGluayB3ZSBjb3VsZCBnbyBlaXRo ZXIgd2F5OiBtdWx0aXBsZSBvciBzaW5nbGUgc2lnbmF0dXJlIGFsZ29yaXRobSBwZXIgZ3JvdXAu DQpIb3dldmVyLCBJIHdvdWxkIHByZWZlciBpZiB3ZSByZXF1aXJlZCAqYWxsKiB0aGUgYWxnb3Jp dGhtcyB0aGF0IGdyb3VwIG1lbWJlcnMgbXVzdCBzdXBwb3J0IHRvIGJlIGRlY2xhcmVkIHVwLWZy b250IGF0IGdyb3VwIGNyZWF0aW9uLg0KDQpUaGlzIGlzIGN1cnJlbnRseSB0aGUgY2FzZSB0aGF0 IOKAnHRoYXQgYWxsIHRoZSBhbGdvcml0aG0gdGhhdCBncm91cCBtZW1iZXJzIG11c3Qgc3VwcG9y dA0KdG8gYmUgZGVjbGFyZWQgYXQgZ3JvdXAgY3JlYXRpb24iIGFuZCBpdCBpcyBhbHNvIHRoZSBy b290IGNhdXNlIG9mIHBvdGVudGlhbCBmcmFnbWVudGF0aW9uLg0KDQpJZiB0aGUgY3JlYXRvciB0 YWtlcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgZXhwbGljaXRseSBwaWNraW5nIHNvbWV0aGluZyBl bHNlIHRoYW4gdGhlIE1USSBjaXBoZXJzdWl0ZQ0KdGhleSB0YWtlIHRoZSByaXNrIGV4cGxpY2l0 bHkgdG8gYnJlYWsgaW50ZXJvcCBhbmQgYnJlYWsgUjIsIGJ1dCB0aGF0IGlzIGZpbmUuDQoNCklm IHdlIHdlbnQgZm9yIHRoZSBzY2hlbWUgc3VjaCBhcyBwaWNraW5nIGEgbGlzdCB3aGljaCBjb250 YWlucyBtb3JlIHRoYW4gdGhlIE1USSwgZXZlbiBhdA0KZ3JvdXAgY3JlYXRpb24sICpvbmx5IGNs aWVudHMgc3VwcG9ydGluZyBldmVyeXRoaW5nKiB3b3VsZCBiZSBhbGxvd2VkIHRvIGpvaW4gb3Ro ZXJ3aXNlIGJyZWFraW5nIFIxLg0KDQpUbyBtZSB0aGlzIElzIHVuYWNjZXB0YWJsZS4NClRoYXQg aXMgd2h5IHdlIHdhbnQgdG8gcmVzdHJpY3QgdGhpcyBzZXQgdG8gYSBtaW5pbXVtOiBpbiBteSBj YXNlIHRvICpvbmUqIGNpcGhlcnN1aXRlLg0KVGhlIGxhcmdlc3Qgc2V0IHRoZSBjcmVhdG9yIHdp bGwgcGljaywgdGhlIG1vcmUgZGlmZmljdWx0IGl0IHdpbGwgYmUgZm9yIG5ldyBtZW1iZXIgdG8g am9pbiB0aGUgZ3JvdXAuDQoNClRoYXQgaXMsIG15IHByZWZlcmVuY2UgaXMgbm90IHRvIGFkZCBu ZXcgc2lnbmF0dXJlIGFsZ29yaXRobXMgYXMgYSBncm91cCBldm9sdmVzIGFuZCBuZXcgbWVtYmVy cyBhcmUgYWRkZWQuDQoNClRoYXQgd2FzIG5ldmVyIGFuIG9wdGlvbi4NCg0KDQpUaGUgcmF0aW9u YWxlIGJlaGluZCB0aGlzIHRoaW5raW5nIGlzIHRoYXQgd2hlbiBhIG1lbWJlciBqb2lucyBhIGdy b3VwLCBzaGUgY2FuIGluc3BlY3QgdGhlIGdyb3Vw4oCZcyBwYXJhbWV0ZXJzIHRvIGRlY2lkZSB3 aGV0aGVyIHNoZSBzdXBwb3J0cw0KdGhlIGFsZ29yaXRobXMgbmVlZGVkIHRvIGNvbnZlcnNlIGlu IHRoZSBncm91cC4gSXQgd291bGQgYmUgd2VpcmQgaWYgdGhlIGdyb3VwIGFsbG93ZWQgYSBuZXcg bWVtYmVyIHdob3NlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWwgb3IgbWVzc2FnZSBzaWduYXR1 cmVzDQpjYW5ub3QgYmUgcHJvY2Vzc2VkIGJ5IGV4aXN0aW5nIG1lbWJlcnMuDQoNCklmIHRoZSBu ZXdjb21lciBkb2VzbuKAmXQgc3VwcG9ydCBlbm91Z2gsIGJ1dCBqdXN0IHRoZSBNVEksIHRoZXkg bWF5IG5ldmVyIGpvaW4gd2hpY2ggaXMNCnVuYWNjZXB0YWJsZSwgYXMgZXZlcnlvbmUgZWxzZSBo YXMgdG8gc3VwcG9ydCB0aGUgTVRJLCBSMi4NCg0KQW5kIGl0IHdvdWxkIGJlIGhhcmQgdG8gdHJ5 IHRvIGR5bmFtaWNhbGx5IGRldGVjdCB0aGUgYWxnb3JpdGhtcyB0aGF0IHRoZSBncm91cCBtZW1i ZXJzIHN1cHBvcnQuDQpJbnN0ZWFkLCBkZWNsYXJpbmcgYWxsICpyZXF1aXJlZCogYWxnb3JpdGht cyBhdCBncm91cCBjcmVhdGlvbiBzZWVtcyBsaWtlIGEgc2FuZSBjaG9pY2UgdG8gbWUuDQoNClNv IGFnYWluLCByZXF1aXJpbmcgdG8gc3VwcG9ydCBtb3JlLCBpcyBub3Qgb25seSBhIGRhbmdlcm91 cyBpZGVhIHJlZ2FyZGluZyBpbXBsZW1lbnRhdGlvbnMsDQpidXQgaXMgZGFuZ2Vyb3VzIGZvciBp bnRlcm9wZXJhYmlsaXR5IGFuZCBmcmFnbWVudGF0aW9uLg0KDQpNb3Jlb3ZlciB0aGlzIG5ldyBw cm9wb3NhbCBpcyBub3Qgc29sdmluZyBhbnkgb2YgdGhlIGN1cnJlbnQgcHJvYmxlbXMgSSBoYXZl IHdpdGggdGhlIG11bHRpcGxlDQphbGdvcml0aG1zIGFwcHJvYWNoIEkgaGFkIGluIG15IHByZXZp b3VzIG1lc3NhZ2U6DQotLS0tLQ0KDQoxLiBhZ2lsaXR5IGNhdXNlcyBhIGxvdCBvZiBwcm9ibGVt czogSSBkb27igJl0IHRoaW5rIEkgbmVlZCB0byByZW1pbmQgcGVvcGxlIG9mIHRoZSBUTFMgc3Rv cnkgaHR0cHM6Ly9oYWwuaW5yaWEuZnIvaGFsLTAxMTE0MjUwDQoNCjIuIGludGVyb3AgZnJhZ21l bnRhdGlvbjogdGhpcyBpcyBub3QgYSB0d28gcGFydHkgcHJvdG9jb2wgd2hlcmUgbWVtYmVyc2hp cCBpcyBzZXQgZm9yZXZlci4NCklmIGEgc2luZ2xlIG1lbWJlciBkb2VzIG5vdCBzdXBwb3J0IG9u ZSBjcnlwdG8gc2NoZW1lLCB0aGlzIG1lbWJlciBtaWdodCBuZXZlciBiZSBhYmxlIHRvIGpvaW4g YW4gaHlicmlkIGdyb3VwLg0KDQozLiBzZWN1cml0eTogSSBjbGVhcmx5IGRvbuKAmXQgYmVsaWV2 ZSB3ZSBzaG91bGQgYXNzdW1lIGFueXRoaW5nIGZyb20gdGhlIHNlY3VyaXR5IG9mIHRoZSBwcm90 b2NvbA0KaW4gdGhlIGNhc2UgYSBjcnlwdG9ncmFwaGljIHNjaGVtZSBpcyBicm9rZW4uIEkgZG9u 4oCZdCB3YW50IHRvIGdldCB0byBhIHBvaW50IHdoZXJlIHdlIGhhdmUgaG9ycmlibGUgZG93bmdy YWRlIHN0b3JpZXMNCmFuZCBJIHdvdWxkIGNsZWFybHkgd2FudCB0byBraWxsIGFuZCByZXN0YXJ0 IHRoZSBlbnRpcmUgZ3JvdXANCg0KSSB0aGluayBmcmFnbWVudGF0aW9uIGlzIG15IG1haW4gd29y cnkgYWN0dWFsbHksIGFuZCBpZiB3ZSBmaWd1cmUgb3V0IHRoYXQgd2Ugd2VyZSB3cm9uZywNCmFk ZGluZyBtb3JlIGFnaWxpdHkgaXMgbGlrZWx5IHRvIGJlIG1vcmUgZWFzeSB0aGFuIHJlbW92aW5n IGl0Lg0KDQpTbyBteSBpbnR1aXRpb24gaXMgdGhhdCB3ZSBzaG91bGQgcHJvY2VlZCB3aXRoIG9u ZSBzaWduYXR1cmUgc2NoZW1lIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlIGdyb3VwDQphbmQgbWFr ZSBzdXJlIHdlIGhhdmUgYSBzb2xpZCBzdG9yeSB0byBleHBvcnQgYW5kIHJlY29uc3RydWN0IGEg Z3JvdXAsIHdoaWNoIHdlIG5lZWQgYW55d2F5Lg0KDQpCLg0KDQoNCg0K --_000_A6881857406E45E9BEC7823E15633619npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <43C8BF5884C8BD419C4642AC4725128E@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlbmphbWluLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWVzIHlv dSBkZXNjcmliZSBhcmUgcHJpbWFyaWx5IFRMUy10eXBlIHByb2JsZW1zLCB3aGVyZSB1bmNvbnRy b2xsZWQsIGxhcmdlLXNjYWxlIGFnaWxpdHkgYW5kIGludGVyb3AgaXNzdWVzIGV4aXN0LiBBcyBo YXMgYmVlbiBzdGF0ZWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgYXMgYSBzdXBwb3J0aW5nIGFyZ3Vt ZW50IHRvIG1hbnkgY2hhbmdlcyBvdmVyIHRoZSBkaWZmZXJlbnQgZHJhZnRzLCB3aXRoaW4NCiB0 aGUgbWVzc2FnaW5nL01MUyBzcGFjZSB3ZSBhcmUgbG9va2luZyBhdCBzaWduaWZpY2FudGx5IG1v cmUgY2xpZW50LXNwZWNpZmljIGNvbnRyb2wuIEl0IGlzIG5vdCB1bnJlYXNvbmFibGUgZm9yIGEg bmV3Y29tZXIgdG8gc3VwcG9ydCBhIHNlbGVjdGlvbiBvZiBzaWduYXR1cmUgc2NoZW1lcy4gSWYg dGhlIGdyb3VwIGNyZWF0b3IgcmVhbGx5IHdhbnRzIGZ1bGwgaW50ZXJvcCwgdGhleSBjYW4gYWx3 YXlzIGRlZmluZSB0aGUgc2V0IG9mIGF2YWlsYWJsZQ0KIHNjaGVtZXMgdG8gY29uc2lzdCBvbmx5 IG9mIHRoZSBNVEkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QnJpdHRhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5CZW5qYW1pbiBCZXVyZG91Y2hlICZsdDtiZW5qYW1pbi5iZXVyZG91Y2hlQGlu cmlhLmZyJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgRmVicnVhcnkgMjcsIDIwMjAg YXQgMTA6MDMgQU08YnI+DQo8Yj5UbzogPC9iPkNhcyBDcmVtZXJzICZsdDtjYXMuY3JlbWVyc0Bn bWFpbC5jb20mZ3Q7LCAmcXVvdDtIYWxlLCBCcml0dGEgKENJVikmcXVvdDsgJmx0O2JyaXR0YS5o YWxlQG5wcy5lZHUmZ3Q7LCBLb25yYWQgS29oYnJvayAmbHQ7a29ucmFkLmtvaGJyb2tAZGF0YXNo cmluZS5kZSZndDs8YnI+DQo8Yj5DYzogPC9iPkthcnRoaWtleWFuIEJoYXJnYXZhbiAmbHQ7a2Fy dGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyJmd0OywgTUwgTWVzc2FnaW5nIExheWVyIFNlY3Vy aXR5ICZsdDttbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTUxTXSBj b25maXJtaW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb20gdGhlIGxhc3QgbWVzc2FnZXMsIEkg dGhpbmsgbXkgYW5zd2VyIHRvIENhcyB3YXMgbWlzbGVhZGluZ+KApg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlIxLiBKb2luaW5n IGEgZ3JvdXAgd2l0aG91dCBzdXBwb3J0aW5nIGFsbCB0aGUgY3J5cHRvIGlzIHVuYWNjZXB0YWJs ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UjIu IEFsbG93aW5nIGEgc3lzdGVtIHdoZXJlIGNsaWVudHMgYWxsIGFkdmVydGlzZSB0aGUgTVRJIGNp cGhlcnN1aXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hbmQgd2hlcmUgdGhlIG5ld2NvbWVycyBjYW5ub3Qgam9pbiBzaG91bGQgYmUgdW5hY2Nl cHRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Hb2FsIG9mIE1MUzogd2Ugd2FudCBldmVyeWJvZHkgdG8gYmUgYWJsZSB0byBidWlsZCBh IGdyb3VwIGFuZCB0YWxrIHNlY3VyZWx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj50byBldmVyeWJvZHkgZWxzZS4gTm8gbmVlZCBmb3Igc2VjdXJp dHkgaWYgcGVvcGxlIGNhbuKAmXQgY3JlYXRlIGdyb3VwcyBiZWNhdXNlIG9mPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbGdvcml0aG0gZnJhZ21l bnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gMjYgRmViIDIwMjAsIGF0IDIwOjM3LCBLYXJ0aGlrIEJoYXJnYXZh biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mciI+a2Fy dGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBBbGwsPGJyPg0KPGJyPg0KSSB0 aGluayB3ZSBjb3VsZCBnbyBlaXRoZXIgd2F5OiBtdWx0aXBsZSBvciBzaW5nbGUgc2lnbmF0dXJl IGFsZ29yaXRobSBwZXIgZ3JvdXAuPGJyPg0KSG93ZXZlciwgSSB3b3VsZCBwcmVmZXIgaWYgd2Ug cmVxdWlyZWQgKmFsbCogdGhlIGFsZ29yaXRobXMgdGhhdCBncm91cCBtZW1iZXJzIG11c3Qgc3Vw cG9ydCB0byBiZSBkZWNsYXJlZCB1cC1mcm9udCBhdCBncm91cCBjcmVhdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGlzIGN1cnJlbnRseSB0aGUgY2FzZSB0aGF0IOKAnHRoYXQgYWxsIHRo ZSBhbGdvcml0aG0gdGhhdCBncm91cCBtZW1iZXJzIG11c3Qgc3VwcG9ydDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gYmUgZGVjbGFyZWQgYXQg Z3JvdXAgY3JlYXRpb24mcXVvdDsgYW5kIGl0IGlzIGFsc28gdGhlIHJvb3QgY2F1c2Ugb2YgcG90 ZW50aWFsIGZyYWdtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBjcmVhdG9yIHRha2VzIHRoZSByZXNwb25zaWJpbGl0 eSBvZiBleHBsaWNpdGx5IHBpY2tpbmcgc29tZXRoaW5nIGVsc2UgdGhhbiB0aGUgTVRJIGNpcGhl cnN1aXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij50aGV5IHRha2UgdGhlIHJpc2sgZXhwbGljaXRseSB0byBicmVhayBpbnRlcm9wIGFuZCBicmVh ayBSMiwgYnV0IHRoYXQgaXMgZmluZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2Ugd2VudCBmb3IgdGhlIHNjaGVtZSBzdWNoIGFzIHBp Y2tpbmcgYSBsaXN0IHdoaWNoIGNvbnRhaW5zIG1vcmUgdGhhbiB0aGUgTVRJLCBldmVuIGF0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ncm91cCBj cmVhdGlvbiwgKm9ubHkgY2xpZW50cyBzdXBwb3J0aW5nIGV2ZXJ5dGhpbmcqIHdvdWxkIGJlIGFs bG93ZWQgdG8gam9pbiBvdGhlcndpc2UgYnJlYWtpbmcgUjEuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIG1lIHRoaXMgSXMgdW5hY2NlcHRh YmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYXQgaXMgd2h5IHdlIHdhbnQgdG8gcmVzdHJpY3QgdGhpcyBzZXQgdG8gYSBtaW5p bXVtOiBpbiBteSBjYXNlIHRvICpvbmUqIGNpcGhlcnN1aXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxhcmdlc3Qgc2V0IHRoZSBjcmVh dG9yIHdpbGwgcGljaywgdGhlIG1vcmUgZGlmZmljdWx0IGl0IHdpbGwgYmUgZm9yIG5ldyBtZW1i ZXIgdG8gam9pbiB0aGUgZ3JvdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcywgbXkgcHJlZmVyZW5j ZSBpcyBub3QgdG8gYWRkIG5ldyBzaWduYXR1cmUgYWxnb3JpdGhtcyBhcyBhIGdyb3VwIGV2b2x2 ZXMgYW5kIG5ldyBtZW1iZXJzIGFyZSBhZGRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdh cyBuZXZlciBhbiBvcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSByYXRpb25hbGUgYmVoaW5kIHRoaXMgdGhpbmtpbmcgaXMgdGhh dCB3aGVuIGEgbWVtYmVyIGpvaW5zIGEgZ3JvdXAsIHNoZSBjYW4gaW5zcGVjdCB0aGUgZ3JvdXDi gJlzIHBhcmFtZXRlcnMgdG8gZGVjaWRlIHdoZXRoZXIgc2hlIHN1cHBvcnRzPGJyPg0KdGhlIGFs Z29yaXRobXMgbmVlZGVkIHRvIGNvbnZlcnNlIGluIHRoZSBncm91cC4gSXQgd291bGQgYmUgd2Vp cmQgaWYgdGhlIGdyb3VwIGFsbG93ZWQgYSBuZXcgbWVtYmVyIHdob3NlIGF1dGhlbnRpY2F0aW9u IGNyZWRlbnRpYWwgb3IgbWVzc2FnZSBzaWduYXR1cmVzPGJyPg0KY2Fubm90IGJlIHByb2Nlc3Nl ZCBieSBleGlzdGluZyBtZW1iZXJzLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgbmV3Y29t ZXIgZG9lc27igJl0IHN1cHBvcnQgZW5vdWdoLCBidXQganVzdCB0aGUgTVRJLCB0aGV5IG1heSBu ZXZlciBqb2luIHdoaWNoIGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj51bmFjY2VwdGFibGUsIGFzIGV2ZXJ5b25lIGVsc2UgaGFzIHRvIHN1cHBv cnQgdGhlIE1USSwgUjIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBpdCB3b3VsZCBiZSBoYXJkIHRvIHRyeSB0byBkeW5h bWljYWxseSBkZXRlY3QgdGhlIGFsZ29yaXRobXMgdGhhdCB0aGUgZ3JvdXAgbWVtYmVycyBzdXBw b3J0Ljxicj4NCkluc3RlYWQsIGRlY2xhcmluZyBhbGwgKnJlcXVpcmVkKiBhbGdvcml0aG1zIGF0 IGdyb3VwIGNyZWF0aW9uIHNlZW1zIGxpa2UgYSBzYW5lIGNob2ljZSB0byBtZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U28gYWdhaW4sIHJlcXVpcmluZyB0byBzdXBwb3J0IG1vcmUsIGlzIG5vdCBv bmx5IGEgZGFuZ2Vyb3VzIGlkZWEgcmVnYXJkaW5nIGltcGxlbWVudGF0aW9ucyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBpcyBkYW5nZXJv dXMgZm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIGZyYWdtZW50YXRpb24uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vcmVvdmVyIHRoaXMgbmV3 IHByb3Bvc2FsIGlzIG5vdCBzb2x2aW5nIGFueSBvZiB0aGUgY3VycmVudCBwcm9ibGVtcyBJIGhh dmUgd2l0aCB0aGUgbXVsdGlwbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmFsZ29yaXRobXMgYXBwcm9hY2ggSSBoYWQgaW4gbXkgcHJldmlvdXMg bWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjEuIGFnaWxpdHkgY2F1c2VzIGEgbG90IG9mIHByb2JsZW1zOiBJIGRvbuKAmXQgdGhp bmsgSSBuZWVkIHRvIHJlbWluZCBwZW9wbGUgb2YgdGhlIFRMUyBzdG9yeSZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vaGFsLmlucmlhLmZyL2hhbC0wMTExNDI1MCI+aHR0cHM6Ly9oYWwuaW5yaWEuZnIv aGFsLTAxMTE0MjUwPC9hPjxicj4NCjxicj4NCjIuIGludGVyb3AgZnJhZ21lbnRhdGlvbjogdGhp cyBpcyBub3QgYSB0d28gcGFydHkgcHJvdG9jb2wgd2hlcmUgbWVtYmVyc2hpcCBpcyBzZXQgZm9y ZXZlci48YnI+DQpJZiBhIHNpbmdsZSBtZW1iZXIgZG9lcyBub3Qgc3VwcG9ydCBvbmUgY3J5cHRv IHNjaGVtZSwgdGhpcyBtZW1iZXIgbWlnaHQgbmV2ZXIgYmUgYWJsZSB0byBqb2luIGFuIGh5YnJp ZCBncm91cC48YnI+DQo8YnI+DQozLiBzZWN1cml0eTogSSBjbGVhcmx5IGRvbuKAmXQgYmVsaWV2 ZSB3ZSBzaG91bGQgYXNzdW1lIGFueXRoaW5nIGZyb20gdGhlIHNlY3VyaXR5IG9mIHRoZSBwcm90 b2NvbDxicj4NCmluIHRoZSBjYXNlIGEgY3J5cHRvZ3JhcGhpYyBzY2hlbWUgaXMgYnJva2VuLiBJ IGRvbuKAmXQgd2FudCB0byBnZXQgdG8gYSBwb2ludCB3aGVyZSB3ZSBoYXZlIGhvcnJpYmxlIGRv d25ncmFkZSBzdG9yaWVzPGJyPg0KYW5kIEkgd291bGQgY2xlYXJseSB3YW50IHRvIGtpbGwgYW5k IHJlc3RhcnQgdGhlIGVudGlyZSBncm91cDxicj4NCjxicj4NCkkgdGhpbmsgZnJhZ21lbnRhdGlv biBpcyBteSBtYWluIHdvcnJ5IGFjdHVhbGx5LCBhbmQgaWYgd2UgZmlndXJlIG91dCB0aGF0IHdl IHdlcmUgd3JvbmcsPGJyPg0KYWRkaW5nIG1vcmUgYWdpbGl0eSBpcyBsaWtlbHkgdG8gYmUgbW9y ZSBlYXN5IHRoYW4gcmVtb3ZpbmcgaXQuPGJyPg0KPGJyPg0KU28gbXkgaW50dWl0aW9uIGlzIHRo YXQgd2Ugc2hvdWxkIHByb2NlZWQgd2l0aCBvbmUgc2lnbmF0dXJlIHNjaGVtZSBmb3IgdGhlIGxp ZmV0aW1lIG9mIHRoZSBncm91cDxicj4NCmFuZCBtYWtlIHN1cmUgd2UgaGF2ZSBhIHNvbGlkIHN0 b3J5IHRvIGV4cG9ydCBhbmQgcmVjb25zdHJ1Y3QgYSBncm91cCwgd2hpY2ggd2UgbmVlZCBhbnl3 YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_A6881857406E45E9BEC7823E15633619npsedu_-- From nobody Thu Feb 27 02:47:26 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C63A08ED for ; Thu, 27 Feb 2020 02:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 etK0kPSkpZk5 for ; Thu, 27 Feb 2020 02:47:14 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EF53A086F for ; Thu, 27 Feb 2020 02:47:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,491,1574118000"; d="scan'208,217";a="340588647" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 11:47:10 +0100 From: Benjamin Beurdouche Message-Id: <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Thu, 27 Feb 2020 11:47:10 +0100 In-Reply-To: Cc: Cas Cremers , Karthikeyan Bhargavan , ML Messaging Layer Security , Konrad Kohbrok To: Britta Hale References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 10:47:25 -0000 --Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Britta, > On 27 Feb 2020, at 10:57, Hale, Britta (CIV) = wrote: >=20 > Benjamin, > =20 > The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist. Yes exactly, and I think two-party short lived connections for TLS are = easier to handle than will be the long-lived multi-party connections of MLS. > As has been stated in the working group as a supporting argument to = many changes over the different drafts, within the messaging/MLS space = we are looking at significantly more client-specific control. Yes, and we keep being careful that it is the case when writing the = drafts, but this doesn=E2=80=99t mean that we should be willing to risk = interoperability. > It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI. I think at reverse, if you are willing to break interop, you should be = selecting something else than the MTI when creating the group. And again, in what I say, = nothing prevents you to pick the NIST ciphersuite for compliance and use only that. But I don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability. Out of curiosity, where you somehow arguing for multiple MTIs here ? B.= --Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Britta,

On 27 Feb 2020, at 10:57, Hale, Britta (CIV) = <britta.hale@nps.edu> wrote:

Benjamin,
 
The issues you describe are primarily TLS-type problems, = where uncontrolled, large-scale agility and interop issues exist. =

Yes = exactly, and I think two-party short lived connections for TLS are = easier to handle
than will be the long-lived multi-party = connections of MLS.

As has been stated in the = working group as a supporting argument to many changes over the = different drafts, within the messaging/MLS space we are looking at = significantly more client-specific control. =

Yes, and = we keep being careful that it is the case when writing the = drafts,
but this doesn=E2=80=99t mean that we should be = willing to risk interoperability.

It is not unreasonable for = a newcomer to support a selection of signature schemes. If the group = creator really wants full interop, they can always define the set of = available schemes to consist only of the = MTI.

I think at = reverse, if you are willing to break interop, you should be selecting = something
else than the MTI when creating the group. And = again, in what I say, nothing prevents
you to pick the NIST = ciphersuite for compliance and use only that.
But I = don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability.

Out of curiosity, where you somehow arguing for = multiple MTIs here ?

B.
= --Apple-Mail=_FF65B8DD-9134-4D69-90AA-907DC6AF678B-- From nobody Thu Feb 27 02:48:50 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299333A0854 for ; Thu, 27 Feb 2020 02:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0XSjGU23uFF for ; Thu, 27 Feb 2020 02:48:47 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D213A0850 for ; Thu, 27 Feb 2020 02:48:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,491,1574118000"; d="scan'208,217";a="437874666" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 11:48:36 +0100 From: Benjamin Beurdouche Message-Id: <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_212B10E5-CDC4-4D87-B476-173C10087303" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Thu, 27 Feb 2020 11:48:36 +0100 In-Reply-To: <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> Cc: Cas Cremers , Karthikeyan Bhargavan , ML Messaging Layer Security , Konrad Kohbrok To: Britta Hale References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 10:48:49 -0000 --Apple-Mail=_212B10E5-CDC4-4D87-B476-173C10087303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27 Feb 2020, at 11:47, Benjamin Beurdouche = > = wrote: >=20 > Hi Britta, >=20 >> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) > wrote: >>=20 >> Benjamin, >> =20 >> The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist. >=20 > Yes exactly, and I think two-party short lived connections for TLS are = easier to handle > than will be the long-lived multi-party connections of MLS. >=20 >> As has been stated in the working group as a supporting argument to = many changes over the different drafts, within the messaging/MLS space = we are looking at significantly more client-specific control. >=20 > Yes, and we keep being careful that it is the case when writing the = drafts, > but this doesn=E2=80=99t mean that we should be willing to risk = interoperability. >=20 >> It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI. >=20 > I think at reverse, if you are willing to break interop, you should be = selecting something S/should be selecting/can select/ > else than the MTI when creating the group. And again, in what I say, = nothing prevents > you to pick the NIST ciphersuite for compliance and use only that. > But I don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability. >=20 > Out of curiosity, where you somehow arguing for multiple MTIs here ? >=20 > B. --Apple-Mail=_212B10E5-CDC4-4D87-B476-173C10087303 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 27 Feb 2020, at 11:47, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:

Hi Britta,

On 27 Feb 2020, at 10:57, Hale, Britta (CIV) = <britta.hale@nps.edu> wrote:

Benjamin,
 
The issues you describe are primarily TLS-type problems, = where uncontrolled, large-scale agility and interop issues exist. =

Yes exactly, and I think two-party short = lived connections for TLS are easier to handle
than = will be the long-lived multi-party connections of MLS.

As has = been stated in the working group as a supporting argument to many = changes over the different drafts, within the messaging/MLS space we are = looking at significantly more client-specific control. =

Yes, and we keep being careful that it is the case when = writing the drafts,
but this doesn=E2=80=99t mean = that we should be willing to risk interoperability.

It is not = unreasonable for a newcomer to support a selection of signature schemes. = If the group creator really wants full interop, they can always define = the set of available schemes to consist only of the = MTI.

I = think at reverse, if you are willing to break interop, you should be = selecting something

S/should be selecting/can select/

else than the MTI when = creating the group. And again, in what I say, nothing prevents
you to pick the NIST ciphersuite for compliance and use only = that.
But I don=E2=80=99t see the interest of = mixing algs and put at risk implementations and = interoperability.

Out of curiosity, where you somehow arguing for multiple MTIs = here ?

B.

= --Apple-Mail=_212B10E5-CDC4-4D87-B476-173C10087303-- From nobody Thu Feb 27 03:50:11 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B473A0A0A for ; Thu, 27 Feb 2020 03:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPlB0VEuqwpX for ; Thu, 27 Feb 2020 03:50:08 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 146BB3A09FD for ; Thu, 27 Feb 2020 03:50:08 -0800 (PST) X-ASG-Debug-ID: 1582804207-0e39454964c89d0001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id sC7Usf8qDsyE36k6; Thu, 27 Feb 2020 03:50:07 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from skywalker.ern.nps.edu (172.20.4.117) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Thu, 27 Feb 2020 03:50:07 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.171) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Thu, 27 Feb 2020 03:50:06 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QjKZ5nqJmYtvkR2YmO4yPx5soJDzCa4Xma6SgT6ttY68FurFiiE9XeUbTJFMzRWFR777/uoOh9NZ5sw7oxzdu/INVx1mE4Z8vWr97OYqBqk8q55Kgu/OJvAg2juXnSVhBdMOA1z6xA3tRo97g4KpahKF/GTVvWkctyekbS2qRVy6VGz6gTyW4FuUI7M8lYNsIIu3Ci70DMkjE0XxMj7kLzWw/ZwPJXSz8eYY9MfT3LqvhdwvtSANvkM+5nSofZW3PMXBveuqJ3AgemMMtuf3/Qef+/aXBBLIBdqRwwjnZbAd/xr4hqerByhkyG78CrAMWGxOFtS6/gBXrUqQ8VMHPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xk/5uv9cXg08zpQU+5wLQ5a16aKbp9lZ7xtv/S+xxS0=; b=mYafDpXIGJvtOlZDWr87J5H9Y/ypMqmfPyLeam4TizOUz7GOBG9nrzWn1LwlrQyRHIXyVb6PLtANOnjyEEiIwxqEVETsxqNb2LrhUCixlR4KSA4I9lJsCPXnzuq58FehTWKDjU1QqZgeuUihgR/KF20ghpxO0TCZXTosn+FeVBGgRdTQ4ksqo6y/bTPYnXE8gJ5ddoL31RIy0L0pMEsJOlFHmqcO2nXRpGWogqLxrckQTkAXh6qZi5XoXvhsDaQjPH06WjWi1xpkE8JGUxF+1J3LvLD3SBYUHlNafUCJ0eLUyzrKLfAF4gCK7EDrb6Oxh5oqtN5NNEjz5FLMZjfRQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3714.namprd13.prod.outlook.com (2603:10b6:a03:22b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.5; Thu, 27 Feb 2020 11:50:03 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 11:50:03 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:22b::18] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:22b::18 From: "Hale, Britta (CIV)" To: Benjamin Beurdouche CC: Cas Cremers , Karthikeyan Bhargavan , ML Messaging Layer Security , Konrad Kohbrok Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAA4SKA//+JDYCAAJPkAIAAAGYA//+LDgA= Date: Thu, 27 Feb 2020 11:50:03 +0000 Message-ID: <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> In-Reply-To: <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [195.158.89.246] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1463e04-1f00-419c-8b0e-08d7bb7b2ede x-ms-traffictypediagnostic: BY5PR13MB3714: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39840400004)(136003)(366004)(346002)(189003)(199004)(186003)(26005)(81166006)(6486002)(91956017)(5660300002)(2616005)(54906003)(36756003)(33656002)(76116006)(786003)(66946007)(81156014)(316002)(75432002)(64756008)(478600001)(8936002)(6916009)(4326008)(2906002)(53546011)(6512007)(86362001)(66446008)(8676002)(66556008)(71200400001)(6506007)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3714; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NnQRY/N+enn8DC9wdiK/OcyzaWV0JjhhwR2x+dq6opaHLEw31uatoKsxqw5kUME9EcebVVAo7a4NqOVZD1q4dhLTthftgyUMzr/0qEuR3j6JisfZzmcuERRW4zF8HmFyLANWIIvGrgTflpa5Xv6hNqE1SsnxQ5zO0vexe4e1Jb69XR0b0MWP74lbEAkNqTW8kckqopdoskVDodqKeGyZ5nnP9GyTd0OSdLUGnl5iT6P49dC2IPBswGLqhj/W5qMGEydygSBIfDOFzvsb9s4nXBC2lR+Yc4Q8F63aWc3zc89Cpx7dee7d6kCjOUfj0YCnGyUE7ZH6vvBlLe8S2lGxZNkdc4ERrTE5p9Iiz8vvIoj8iwkF84K694ur0ovI58pwLt8q5GMeQlvm0Cskouvg7/GDjWf4ns184yAYmOyJombbn0UjSvE45SAw3IHaN7Js x-ms-exchange-antispam-messagedata: uRn3F9EIVPO1POdmWPt3aPX9Dr5sjJZdHN38Fwve51Agvs1wFO8kyhpz7h2KYQ0i56GMGBBRg40EpH5WwA8MJLGRQS+M+T+o2ymd6dIpBoktjC6D0PtwTekUfhg0PM/c4f05EHWfi6tG8Q1uhdpFtw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_57308ED129F448D78AB9D88AC49803C5npsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e1463e04-1f00-419c-8b0e-08d7bb7b2ede X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 11:50:03.7063 (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: 5p1anfxqeZrLDkcwwatw624fb2WlT69pUNdEoqcjoWjfiT3Vb4uihpQDw/xPPfI9GYBFZRqPYpH/s6T1Q03cKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3714 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1582804207 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 11164 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80294 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 11:50:10 -0000 --_000_57308ED129F448D78AB9D88AC49803C5npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVuamFtaW4sDQoNClRoZSBwb2ludCBvZiBjb21wYXJpc29uIHdpdGggVExTIGlzIHRoYXQgaW50 ZXJvcCBpcyBzaWduaWZpY2FudGx5IGxlc3Mgb2YgYW4gaXNzdWUgd2hlbiBldmVyeW9uZSBpbiB0 aGUgZ3JvdXAgaXMgdXNpbmcgdGhlIHNhbWUgY2xpZW50IHByb2dyYW0uDQoNCkluIHRlcm1zIG9m IGludGVyb3AsIHlvdXIgY29uY2VybnMgYmVjb21lIGEgZGlzY3Vzc2lvbiBwb2ludCBtYWlubHkg aW4gdGhlIGZlZGVyYXRpb24gY2FzZSDigJMgYW5kIHRoYXQgaXMgYW4gaW1wb3J0YW50IGNhc2Ug dGhhdCB3ZSBzaG91bGQgcGxhbiBmb3IuIEJ1dCwgYXMgSSBzYWlkIGFuZCB5b3UgcmUtaXRlcmF0 ZWQsIGlmIHRoZSB1c2UgY2FzZSByZWFsbHkgZXhwZWN0cyBpbnRlcm9wIGlzc3VlcyBmcm9tIGFs bG93aW5nIGNob2ljZSwgdGhlbiBub3RoaW5nIHByZXZlbnRzIHRoZSBzZWxlY3Rpb24gb2YgYSBz aW5nbGUgc2NoZW1lIGZvciB0aGUgc2V0IG9mIGFsbG93YWJsZSBzY2hlbWVzLg0KDQpBcyB0byB0 aGUgcmVhc29ucyBiZWhpbmQgYWxsb3dpbmcgbXVsdGlwbGUgYWxnb3JpdGhtcywgdGhlIGRvY3Vt ZW50IG9uIHRoZSBtYWlsaW5nbGlzdCBoYXMgYWxyZWFkeSBvdXRsaW5lZCBzZXZlcmFsIOKAkyB0 aGVzZSBhcmUgc2VjdXJpdHkgcmVhc29ucyBmb3Igc3VwcG9ydGluZyBpbmRpdmlkdWFsIGFsZ29y aXRobXMuIFRoZSBpbnRlcm9wIG9iamVjdGlvbnMgZmFsbCBvbiB0aGUgdXNhYmlsaXR5IHNpZGUs IHNvIHRoZSBjdXJyZW50IGRpc2N1c3Npb24gaXMgcmVhbGx5IGFib3V0IHVzYWJpbGl0eSB2cy4g c2VjdXJpdHkgY29uY2VybnMuIEhvd2V2ZXIsIGF0IHRoZSBpbnRlcnNlY3Rpb24gb2YgdGhlc2Ug dHdvIG9wdGlvbnMgaXMgdGhlIGlkZWEgb2YgYWxsb3dpbmcgYSBzZXQgb2YgcG9zc2libGUgYWxn b3JpdGhtcyBhcyBLYXJ0aGlrIHN1Z2dlc3RzLiBUaGlzIGlzIGEgZ29vZCBjb21wcm9taXNlLg0K DQpJIHdvdWxkIGRlZmluaXRlbHkgbm90IHN1Z2dlc3QgdGhhdCB5b3UgY29uc2lkZXIgbXVsdGlw bGUgTVRJcyBhdCB0aGlzIHN0YWdlLiBJZiB0aGF0IGlzIHNvbWV0aGluZyB5b3Ugd2FudCwgaXQg aXMgYmVzdCB0byByYWlzZSBpdCBhcyBhIHNlcGFyYXRlIGlzc3VlLg0KDQotLS0NCg0KQnJpdHRh DQoNCg0KRnJvbTogQmVuamFtaW4gQmV1cmRvdWNoZSA8YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJp YS5mcj4NCkRhdGU6IFRodXJzZGF5LCBGZWJydWFyeSAyNywgMjAyMCBhdCAxMTo0OCBBTQ0KVG86 ICJIYWxlLCBCcml0dGEgKENJVikiIDxicml0dGEuaGFsZUBucHMuZWR1Pg0KQ2M6IENhcyBDcmVt ZXJzIDxjYXMuY3JlbWVyc0BnbWFpbC5jb20+LCBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gPGthcnRo aWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcj4sIE1MIE1lc3NhZ2luZyBMYXllciBTZWN1cml0eSA8 bWxzQGlldGYub3JnPiwgS29ucmFkIEtvaGJyb2sgPGtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUu ZGU+DQpTdWJqZWN0OiBSZTogW01MU10gY29uZmlybWluZyBjaXBoZXIgc3VpdGVzIGRlY2lzaW9u cw0KDQoNCg0KDQpPbiAyNyBGZWIgMjAyMCwgYXQgMTE6NDcsIEJlbmphbWluIEJldXJkb3VjaGUg PGJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI8bWFpbHRvOmJlbmphbWluLmJldXJkb3VjaGVA aW5yaWEuZnI+PiB3cm90ZToNCg0KSGkgQnJpdHRhLA0KDQoNCk9uIDI3IEZlYiAyMDIwLCBhdCAx MDo1NywgSGFsZSwgQnJpdHRhIChDSVYpIDxicml0dGEuaGFsZUBucHMuZWR1PG1haWx0bzpicml0 dGEuaGFsZUBucHMuZWR1Pj4gd3JvdGU6DQoNCkJlbmphbWluLA0KDQpUaGUgaXNzdWVzIHlvdSBk ZXNjcmliZSBhcmUgcHJpbWFyaWx5IFRMUy10eXBlIHByb2JsZW1zLCB3aGVyZSB1bmNvbnRyb2xs ZWQsIGxhcmdlLXNjYWxlIGFnaWxpdHkgYW5kIGludGVyb3AgaXNzdWVzIGV4aXN0Lg0KDQpZZXMg ZXhhY3RseSwgYW5kIEkgdGhpbmsgdHdvLXBhcnR5IHNob3J0IGxpdmVkIGNvbm5lY3Rpb25zIGZv ciBUTFMgYXJlIGVhc2llciB0byBoYW5kbGUNCnRoYW4gd2lsbCBiZSB0aGUgbG9uZy1saXZlZCBt dWx0aS1wYXJ0eSBjb25uZWN0aW9ucyBvZiBNTFMuDQoNCg0KQXMgaGFzIGJlZW4gc3RhdGVkIGlu IHRoZSB3b3JraW5nIGdyb3VwIGFzIGEgc3VwcG9ydGluZyBhcmd1bWVudCB0byBtYW55IGNoYW5n ZXMgb3ZlciB0aGUgZGlmZmVyZW50IGRyYWZ0cywgd2l0aGluIHRoZSBtZXNzYWdpbmcvTUxTIHNw YWNlIHdlIGFyZSBsb29raW5nIGF0IHNpZ25pZmljYW50bHkgbW9yZSBjbGllbnQtc3BlY2lmaWMg Y29udHJvbC4NCg0KWWVzLCBhbmQgd2Uga2VlcCBiZWluZyBjYXJlZnVsIHRoYXQgaXQgaXMgdGhl IGNhc2Ugd2hlbiB3cml0aW5nIHRoZSBkcmFmdHMsDQpidXQgdGhpcyBkb2VzbuKAmXQgbWVhbiB0 aGF0IHdlIHNob3VsZCBiZSB3aWxsaW5nIHRvIHJpc2sgaW50ZXJvcGVyYWJpbGl0eS4NCg0KDQpJ dCBpcyBub3QgdW5yZWFzb25hYmxlIGZvciBhIG5ld2NvbWVyIHRvIHN1cHBvcnQgYSBzZWxlY3Rp b24gb2Ygc2lnbmF0dXJlIHNjaGVtZXMuIElmIHRoZSBncm91cCBjcmVhdG9yIHJlYWxseSB3YW50 cyBmdWxsIGludGVyb3AsIHRoZXkgY2FuIGFsd2F5cyBkZWZpbmUgdGhlIHNldCBvZiBhdmFpbGFi bGUgc2NoZW1lcyB0byBjb25zaXN0IG9ubHkgb2YgdGhlIE1USS4NCg0KSSB0aGluayBhdCByZXZl cnNlLCBpZiB5b3UgYXJlIHdpbGxpbmcgdG8gYnJlYWsgaW50ZXJvcCwgeW91IHNob3VsZCBiZSBz ZWxlY3Rpbmcgc29tZXRoaW5nDQoNClMvc2hvdWxkIGJlIHNlbGVjdGluZy9jYW4gc2VsZWN0Lw0K DQoNCmVsc2UgdGhhbiB0aGUgTVRJIHdoZW4gY3JlYXRpbmcgdGhlIGdyb3VwLiBBbmQgYWdhaW4s IGluIHdoYXQgSSBzYXksIG5vdGhpbmcgcHJldmVudHMNCnlvdSB0byBwaWNrIHRoZSBOSVNUIGNp cGhlcnN1aXRlIGZvciBjb21wbGlhbmNlIGFuZCB1c2Ugb25seSB0aGF0Lg0KQnV0IEkgZG9u4oCZ dCBzZWUgdGhlIGludGVyZXN0IG9mIG1peGluZyBhbGdzIGFuZCBwdXQgYXQgcmlzayBpbXBsZW1l bnRhdGlvbnMgYW5kIGludGVyb3BlcmFiaWxpdHkuDQoNCk91dCBvZiBjdXJpb3NpdHksIHdoZXJl IHlvdSBzb21laG93IGFyZ3VpbmcgZm9yIG11bHRpcGxlIE1USXMgaGVyZSA/DQoNCkIuDQoNCg0K --_000_57308ED129F448D78AB9D88AC49803C5npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlbmphbWluLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBvaW50IG9m IGNvbXBhcmlzb24gd2l0aCBUTFMgaXMgdGhhdCBpbnRlcm9wIGlzIHNpZ25pZmljYW50bHkgbGVz cyBvZiBhbiBpc3N1ZSB3aGVuIGV2ZXJ5b25lIGluIHRoZSBncm91cCBpcyB1c2luZyB0aGUgc2Ft ZSBjbGllbnQgcHJvZ3JhbS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0ZXJtcyBvZiBp bnRlcm9wLCB5b3VyIGNvbmNlcm5zIGJlY29tZSBhIGRpc2N1c3Npb24gcG9pbnQgbWFpbmx5IGlu IHRoZSBmZWRlcmF0aW9uIGNhc2Ug4oCTIGFuZCB0aGF0IGlzIGFuIGltcG9ydGFudCBjYXNlIHRo YXQgd2Ugc2hvdWxkIHBsYW4gZm9yLiBCdXQsIGFzIEkgc2FpZCBhbmQgeW91IHJlLWl0ZXJhdGVk LCBpZiB0aGUgdXNlIGNhc2UgcmVhbGx5IGV4cGVjdHMgaW50ZXJvcCBpc3N1ZXMgZnJvbSBhbGxv d2luZw0KIGNob2ljZSwgdGhlbiBub3RoaW5nIHByZXZlbnRzIHRoZSBzZWxlY3Rpb24gb2YgYSBz aW5nbGUgc2NoZW1lIGZvciB0aGUgc2V0IG9mIGFsbG93YWJsZSBzY2hlbWVzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BcyB0byB0aGUgcmVhc29ucyBiZWhpbmQgYWxsb3dpbmcgbXVsdGlwbGUg YWxnb3JpdGhtcywgdGhlIGRvY3VtZW50IG9uIHRoZSBtYWlsaW5nbGlzdCBoYXMgYWxyZWFkeSBv dXRsaW5lZCBzZXZlcmFsIOKAkyB0aGVzZSBhcmUgc2VjdXJpdHkgcmVhc29ucyBmb3Igc3VwcG9y dGluZyBpbmRpdmlkdWFsIGFsZ29yaXRobXMuIFRoZSBpbnRlcm9wIG9iamVjdGlvbnMgZmFsbCBv biB0aGUgdXNhYmlsaXR5IHNpZGUsIHNvDQogdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiBpcyByZWFs bHkgYWJvdXQgdXNhYmlsaXR5IHZzLiBzZWN1cml0eSBjb25jZXJucy4gSG93ZXZlciwgYXQgdGhl IGludGVyc2VjdGlvbiBvZiB0aGVzZSB0d28gb3B0aW9ucyBpcyB0aGUgaWRlYSBvZiBhbGxvd2lu ZyBhIHNldCBvZiBwb3NzaWJsZSBhbGdvcml0aG1zIGFzIEthcnRoaWsgc3VnZ2VzdHMuIFRoaXMg aXMgYSBnb29kIGNvbXByb21pc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgZGVm aW5pdGVseSBub3Qgc3VnZ2VzdCB0aGF0IHlvdSBjb25zaWRlciBtdWx0aXBsZSBNVElzIGF0IHRo aXMgc3RhZ2UuIElmIHRoYXQgaXMgc29tZXRoaW5nIHlvdSB3YW50LCBpdCBpcyBiZXN0IHRvIHJh aXNlIGl0IGFzIGEgc2VwYXJhdGUgaXNzdWUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkJyaXR0YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5CZW5qYW1pbiBCZXVyZG91Y2hlICZsdDtiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZy Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgRmVicnVhcnkgMjcsIDIwMjAgYXQgMTE6 NDggQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O0hhbGUsIEJyaXR0YSAoQ0lWKSZxdW90OyAmbHQ7 YnJpdHRhLmhhbGVAbnBzLmVkdSZndDs8YnI+DQo8Yj5DYzogPC9iPkNhcyBDcmVtZXJzICZsdDtj YXMuY3JlbWVyc0BnbWFpbC5jb20mZ3Q7LCBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gJmx0O2thcnRo aWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mciZndDssIE1MIE1lc3NhZ2luZyBMYXllciBTZWN1cml0 eSAmbHQ7bWxzQGlldGYub3JnJmd0OywgS29ucmFkIEtvaGJyb2sgJmx0O2tvbnJhZC5rb2hicm9r QGRhdGFzaHJpbmUuZGUmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTUxTXSBjb25maXJt aW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjcgRmViIDIwMjAsIGF0IDExOjQ3LCBCZW5qYW1pbiBC ZXVyZG91Y2hlICZsdDs8YSBocmVmPSJtYWlsdG86YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5m ciI+YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQnJpdHRhLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjcgRmViIDIwMjAsIGF0IDEw OjU3LCBIYWxlLCBCcml0dGEgKENJVikgJmx0OzxhIGhyZWY9Im1haWx0bzpicml0dGEuaGFsZUBu cHMuZWR1Ij5icml0dGEuaGFsZUBucHMuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW5qYW1pbiw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlcyB5b3UgZGVz Y3JpYmUgYXJlIHByaW1hcmlseSBUTFMtdHlwZSBwcm9ibGVtcywgd2hlcmUgdW5jb250cm9sbGVk LCBsYXJnZS1zY2FsZSBhZ2lsaXR5IGFuZCBpbnRlcm9wIGlzc3VlcyBleGlzdC4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgZXhhY3RseSwgYW5kIEkgdGhpbmsgdHdvLXBhcnR5IHNo b3J0IGxpdmVkIGNvbm5lY3Rpb25zIGZvciBUTFMgYXJlIGVhc2llciB0byBoYW5kbGU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW4gd2lsbCBi ZSB0aGUgbG9uZy1saXZlZCBtdWx0aS1wYXJ0eSBjb25uZWN0aW9ucyBvZiBNTFMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMg aGFzIGJlZW4gc3RhdGVkIGluIHRoZSB3b3JraW5nIGdyb3VwIGFzIGEgc3VwcG9ydGluZyBhcmd1 bWVudCB0byBtYW55IGNoYW5nZXMgb3ZlciB0aGUgZGlmZmVyZW50IGRyYWZ0cywgd2l0aGluIHRo ZSBtZXNzYWdpbmcvTUxTIHNwYWNlIHdlIGFyZSBsb29raW5nIGF0IHNpZ25pZmljYW50bHkgbW9y ZSBjbGllbnQtc3BlY2lmaWMgY29udHJvbC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYW5k IHdlIGtlZXAgYmVpbmcgY2FyZWZ1bCB0aGF0IGl0IGlzIHRoZSBjYXNlIHdoZW4gd3JpdGluZyB0 aGUgZHJhZnRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YnV0IHRoaXMgZG9lc27igJl0IG1lYW4gdGhhdCB3ZSBzaG91bGQgYmUgd2lsbGluZyB0 byByaXNrIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIG5vdCB1bnJlYXNvbmFibGUgZm9yIGEgbmV3Y29t ZXIgdG8gc3VwcG9ydCBhIHNlbGVjdGlvbiBvZiBzaWduYXR1cmUgc2NoZW1lcy4gSWYgdGhlIGdy b3VwIGNyZWF0b3IgcmVhbGx5IHdhbnRzIGZ1bGwgaW50ZXJvcCwgdGhleSBjYW4gYWx3YXlzIGRl ZmluZSB0aGUgc2V0IG9mIGF2YWlsYWJsZSBzY2hlbWVzIHRvIGNvbnNpc3Qgb25seSBvZiB0aGUg TVRJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBhdCByZXZlcnNlLCBpZiB5b3UgYXJlIHdpbGxpbmcg dG8gYnJlYWsgaW50ZXJvcCwgeW91IHNob3VsZCBiZSBzZWxlY3Rpbmcgc29tZXRoaW5nPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TL3Nob3VsZCBiZSBzZWxlY3RpbmcvY2FuIHNlbGVjdC88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmVsc2UgdGhhbiB0aGUgTVRJIHdoZW4gY3JlYXRpbmcgdGhlIGdyb3VwLiBBbmQgYWdhaW4s IGluIHdoYXQgSSBzYXksIG5vdGhpbmcgcHJldmVudHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnlvdSB0byBwaWNrIHRoZSBOSVNUIGNpcGhlcnN1 aXRlIGZvciBjb21wbGlhbmNlIGFuZCB1c2Ugb25seSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkgZG9u4oCZdCBzZWUgdGhlIGlu dGVyZXN0IG9mIG1peGluZyBhbGdzIGFuZCBwdXQgYXQgcmlzayBpbXBsZW1lbnRhdGlvbnMgYW5k IGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk91dCBvZiBjdXJpb3NpdHksIHdoZXJlIHlvdSBzb21laG93IGFyZ3Vp bmcgZm9yIG11bHRpcGxlIE1USXMgaGVyZSA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_57308ED129F448D78AB9D88AC49803C5npsedu_-- From nobody Thu Feb 27 10:02:25 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3523A0E71 for ; Thu, 27 Feb 2020 10:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAN6dyKpnxqu for ; Thu, 27 Feb 2020 10:02:22 -0800 (PST) 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 D21703A0E6D for ; Thu, 27 Feb 2020 10:02:21 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id j7so4522844wrp.13 for ; Thu, 27 Feb 2020 10:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3bJNYStzUEUN3Fow2VU7aVa0YNRH76VcjRHkwq1dFiA=; b=wb3WUvA8Qte4fBsoYcUec98RNYO7SBsqWcI5tfLtdhH9wcayYfezBP4vvvoz6iwedZ F/5Hhrvz3M7h2T3ubbjqdffzCrZxk+wzvJzzZGF8kENnIid4GfI8nXfBDEyzuiwOdWP4 10Xa4zuPfqbEcln2J47q0JY1iQFdJb05O1SuTUxFcmoPgd/IZS/jkjQobreYEYxNQ9yS gG/BpZWGr+P3zdp4I3nU8S1UpG6oRJgVV1KbTZv9MnkAgJdCqJLiL7kmmcKchI0+81uT DgZsyW8KBTAv9WIPKgkQ3UTixs0CgyyFLvqp4NFOqSWH0pOq9950t4lywalMIq5c7WAW mTYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3bJNYStzUEUN3Fow2VU7aVa0YNRH76VcjRHkwq1dFiA=; b=P7nTXW0jp2lqcJHhrR0dbfTHoOocfXkn0LpWL/lX6n5q1i29uPuCBM7AwU2G9RCkw3 gPxwHIj0sR/c7k49PkUWPOWA4meI/T/j4b2X+QPrgYWzpHJdcza9WlXcoVk0QNr3wHBT +H4GKvNTsqNFlr6sGlJz2DNnFlVKhUyct2m9keaV+qvnO6AFck2jjh4jKyj00n0uqJvY QejJQBjLvbHb6pBCpTWiEwN1YAvd/k6RFv18bku4I+e/14undZS5icCa1EM0ICK0tIAw OSkQILLe8U8I/YoC7zuRK3zzA/bi6F7pYTFRJI5qjTiRuXIkb5y44x/wvX3scrv0ix0a btfw== X-Gm-Message-State: APjAAAVUkduBxZLiCvJhyq0vpI2WP1x60lVeqrHecUnRpTG8cYeJO9yy oepl02LDUElTzihnHfKtqWIeYw== X-Google-Smtp-Source: APXvYqzjQg1eyc1cjUGnynI+xyvRYA41F7LJUEAsMwv5xODxNEZuBH/y0i1ggGZscgnJstmHoeKlHA== X-Received: by 2002:a5d:4f89:: with SMTP id d9mr36360wru.391.1582826540091; Thu, 27 Feb 2020 10:02:20 -0800 (PST) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id b10sm8505236wrt.90.2020.02.27.10.02.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 10:02:18 -0800 (PST) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1F6FF80B-19AF-4BE4-9040-5356D48782F7" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Thu, 27 Feb 2020 19:02:17 +0100 In-Reply-To: <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> Cc: Benjamin Beurdouche , Karthikeyan Bhargavan , Cas Cremers , ML Messaging Layer Security , Konrad Kohbrok To: "Hale, Britta (CIV)" References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 18:02:25 -0000 --Apple-Mail=_1F6FF80B-19AF-4BE4-9040-5356D48782F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with what Karthik said, and I think that that was the underlying = assumption all along (at east for me). The negotiation has to happen = ahead of time, namely when - (1) an existing member proposes to add a new member, or when - (2) an external party proposes to add a new member. In the current proposal with a fixed signature per group the decision = taking is rather simple: If the new member advertises support for the = group's ciphersuite in their CIKs, they can be added to the group. I would like to see the decision taking fleshed out for the alternative = approach that supports multiple signatures.=20 We need to make sure that members can verify signatures, which means we = need a list of acceptable signature algorithms that every member agrees = upon before a new member is added. Signature algorithms can be = advertised in another extension in CIKs, but it is not entirely clear to = me how clients agree on what the list of acceptable signatures is. Would = it be the lowest common denominator, meaning the intersection of the = algorithms advertised in the CIKs? If so, it means the list gets largely = determined by the early joiners. Also, can the list change over time? = That would be contrary to the idea that all negotiations should happen = ahead of time. There might an easy solution here, I just don=E2=80=99t see it right = now. Raphael=20 > On 27 Feb 2020, at 12:50, Hale, Britta (CIV) = wrote: >=20 > Benjamin,=20 > =20 > The point of comparison with TLS is that interop is significantly less = of an issue when everyone in the group is using the same client program. > =20 > In terms of interop, your concerns become a discussion point mainly in = the federation case =E2=80=93 and that is an important case that we = should plan for. But, as I said and you re-iterated, if the use case = really expects interop issues from allowing choice, then nothing = prevents the selection of a single scheme for the set of allowable = schemes. > =20 > As to the reasons behind allowing multiple algorithms, the document on = the mailinglist has already outlined several =E2=80=93 these are = security reasons for supporting individual algorithms. The interop = objections fall on the usability side, so the current discussion is = really about usability vs. security concerns. However, at the = intersection of these two options is the idea of allowing a set of = possible algorithms as Karthik suggests. This is a good compromise. > =20 > I would definitely not suggest that you consider multiple MTIs at this = stage. If that is something you want, it is best to raise it as a = separate issue. > =20 > --- > =20 > Britta > =20 > =20 > From: Benjamin Beurdouche > Date: Thursday, February 27, 2020 at 11:48 AM > To: "Hale, Britta (CIV)" > Cc: Cas Cremers , Karthikeyan Bhargavan = , ML Messaging Layer Security = , Konrad Kohbrok > Subject: Re: [MLS] confirming cipher suites decisions > =20 > =20 >=20 >=20 >> On 27 Feb 2020, at 11:47, Benjamin Beurdouche = > = wrote: >> =20 >> Hi Britta, >>=20 >>=20 >>> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) > wrote: >>> =20 >>> Benjamin, >>> =20 >>> The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist. >> =20 >> Yes exactly, and I think two-party short lived connections for TLS = are easier to handle >> than will be the long-lived multi-party connections of MLS. >>=20 >>=20 >>> As has been stated in the working group as a supporting argument to = many changes over the different drafts, within the messaging/MLS space = we are looking at significantly more client-specific control. >> =20 >> Yes, and we keep being careful that it is the case when writing the = drafts, >> but this doesn=E2=80=99t mean that we should be willing to risk = interoperability. >>=20 >>=20 >>> It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI. >> =20 >> I think at reverse, if you are willing to break interop, you should = be selecting something > =20 > S/should be selecting/can select/ >=20 >=20 >> else than the MTI when creating the group. And again, in what I say, = nothing prevents >> you to pick the NIST ciphersuite for compliance and use only that. >> But I don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability. >> =20 >> Out of curiosity, where you somehow arguing for multiple MTIs here ? >> =20 >> B. >=20 >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_1F6FF80B-19AF-4BE4-9040-5356D48782F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with what Karthik said, and I think that that was the underlying = assumption all along (at east for me). The negotiation has to happen = ahead of time, namely when

 - (1) an existing member proposes to add a new member, = or when
 - (2) an external party proposes to = add a new member.

In the current proposal with a fixed signature per group the = decision taking is rather simple: If the new member advertises support = for the group's ciphersuite in their CIKs, they can be added to the = group.

I would = like to see the decision taking fleshed out for the alternative approach = that supports multiple signatures. 
We need to = make sure that members can verify signatures, which means we need a list = of acceptable signature algorithms that every member agrees upon before = a new member is added. Signature algorithms can be advertised in another = extension in CIKs, but it is not entirely clear to me how clients agree = on what the list of acceptable signatures is. Would it be the lowest = common denominator, meaning the intersection of the algorithms = advertised in the CIKs? If so, it means the list gets largely determined = by the early joiners. Also, can the list change over time? That would be = contrary to the idea that all negotiations should happen ahead of = time.
There might an easy solution here, I just = don=E2=80=99t see it right now.

Raphael 

On 27 = Feb 2020, at 12:50, Hale, Britta (CIV) <britta.hale@nps.edu>= wrote:

Benjamin, 
 
The point = of comparison with TLS is that interop is significantly less of an issue = when everyone in the group is using the same client program.
 
In terms = of interop, your concerns become a discussion point mainly in the = federation case =E2=80=93 and that is an important case that we should = plan for. But, as I said and you re-iterated, if the use case really = expects interop issues from allowing choice, then nothing prevents the = selection of a single scheme for the set of allowable schemes.
 
As to the = reasons behind allowing multiple algorithms, the document on the = mailinglist has already outlined several =E2=80=93 these are security = reasons for supporting individual algorithms. The interop objections = fall on the usability side, so the current discussion is really about = usability vs. security concerns. However, at the intersection of these = two options is the idea of allowing a set of possible algorithms as = Karthik suggests. This is a good compromise.
 
I would = definitely not suggest that you consider multiple MTIs at this stage. If = that is something you want, it is best to raise it as a separate = issue.
 
---
 
Britta
 
 
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Date: Thursday, February 27, = 2020 at 11:48 AM
To: "Hale, Britta (CIV)" = <britta.hale@nps.edu>
Cc: Cas = Cremers <cas.cremers@gmail.com>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, ML Messaging Layer = Security <mls@ietf.org>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming = cipher suites decisions
 
 


On 27 Feb 2020, at 11:47, Benjamin = Beurdouche <benjamin.beurdouche@inria.fr> wrote:
 
Hi Britta,


On 27 Feb 2020, at 10:57, Hale, Britta = (CIV) <britta.hale@nps.edu> = wrote:
 
Benjamin,
 
The issues you describe are primarily = TLS-type problems, where uncontrolled, large-scale agility and interop = issues exist.
 
Yes exactly, and I think two-party = short lived connections for TLS are easier to handle
than will be the long-lived multi-party connections of = MLS.


As has been stated in the = working group as a supporting argument to many changes over the = different drafts, within the messaging/MLS space we are looking at = significantly more client-specific control.
 
Yes, and we keep being careful that it is the case when = writing the drafts,
but this doesn=E2=80=99t mean that we = should be willing to risk interoperability.


It is not unreasonable for a newcomer to support a selection = of signature schemes. If the group creator really wants full interop, = they can always define the set of available schemes to consist only of = the MTI.
 
I think at reverse, if you are willing to break interop, you = should be selecting something
 
S/should be selecting/can select/


else than the MTI when creating the = group. And again, in what I say, nothing prevents
you to pick the NIST ciphersuite for compliance and use only = that.
But I don=E2=80=99t see the interest of = mixing algs and put at risk implementations and interoperability.
 
Out of curiosity, where you somehow = arguing for multiple MTIs here ?
 
B.


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

= --Apple-Mail=_1F6FF80B-19AF-4BE4-9040-5356D48782F7-- From nobody Thu Feb 27 21:54:59 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5182B3A109C for ; Thu, 27 Feb 2020 21:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUMnIHfwSPaP for ; Thu, 27 Feb 2020 21:54:55 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9448B3A108F for ; Thu, 27 Feb 2020 21:54:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,493,1574118000"; d="scan'208,217";a="437983593" Received: from 89-156-101-160.rev.numericable.fr (HELO [192.168.0.62]) ([89.156.101.160]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2020 06:54:52 +0100 From: Karthik Bhargavan Message-Id: <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_8579ACB5-CEBA-4FA1-8B59-C780B292EB3E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 28 Feb 2020 06:54:50 +0100 In-Reply-To: Cc: "Hale, Britta (CIV)" , Benjamin Beurdouche , Cas Cremers , ML Messaging Layer Security , Konrad Kohbrok To: Raphael Robert References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 05:54:58 -0000 --Apple-Mail=_8579ACB5-CEBA-4FA1-8B59-C780B292EB3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am not sure about the practical ramifications of groups where members = use different algorithms. Still, I think it is feasible to eventually have a design where the = group creator proposes a set of algorithms as =E2=80=9Cmust implement=E2=80= =9D for the group. Each new member must support (i.e. implement) =E2=80=9Call=E2=80=9D the = algorithms in this list in order to join the group. However, the member has the option to use whichever supported algorithm = she prefers for messages she sends. While all of this is a reasonable long-term goal, perhaps we should = start with a version where the creator only chooses one algorithm in = each category, leaving no choice to the members. We can document this choice as a future extension point, and change it = as we understand the federation scenario and deployment constraints a = bit better? Best, Karthik > On 27 Feb 2020, at 19:02, Raphael Robert wrote: >=20 > I agree with what Karthik said, and I think that that was the = underlying assumption all along (at east for me). The negotiation has to = happen ahead of time, namely when >=20 > - (1) an existing member proposes to add a new member, or when > - (2) an external party proposes to add a new member. >=20 > In the current proposal with a fixed signature per group the decision = taking is rather simple: If the new member advertises support for the = group's ciphersuite in their CIKs, they can be added to the group. >=20 > I would like to see the decision taking fleshed out for the = alternative approach that supports multiple signatures.=20 > We need to make sure that members can verify signatures, which means = we need a list of acceptable signature algorithms that every member = agrees upon before a new member is added. Signature algorithms can be = advertised in another extension in CIKs, but it is not entirely clear to = me how clients agree on what the list of acceptable signatures is. Would = it be the lowest common denominator, meaning the intersection of the = algorithms advertised in the CIKs? If so, it means the list gets largely = determined by the early joiners. Also, can the list change over time? = That would be contrary to the idea that all negotiations should happen = ahead of time. > There might an easy solution here, I just don=E2=80=99t see it right = now. >=20 > Raphael=20 >=20 >> On 27 Feb 2020, at 12:50, Hale, Britta (CIV) > wrote: >>=20 >> Benjamin,=20 >> =20 >> The point of comparison with TLS is that interop is significantly = less of an issue when everyone in the group is using the same client = program. >> =20 >> In terms of interop, your concerns become a discussion point mainly = in the federation case =E2=80=93 and that is an important case that we = should plan for. But, as I said and you re-iterated, if the use case = really expects interop issues from allowing choice, then nothing = prevents the selection of a single scheme for the set of allowable = schemes. >> =20 >> As to the reasons behind allowing multiple algorithms, the document = on the mailinglist has already outlined several =E2=80=93 these are = security reasons for supporting individual algorithms. The interop = objections fall on the usability side, so the current discussion is = really about usability vs. security concerns. However, at the = intersection of these two options is the idea of allowing a set of = possible algorithms as Karthik suggests. This is a good compromise. >> =20 >> I would definitely not suggest that you consider multiple MTIs at = this stage. If that is something you want, it is best to raise it as a = separate issue. >> =20 >> --- >> =20 >> Britta >> =20 >> =20 >> From: Benjamin Beurdouche > >> Date: Thursday, February 27, 2020 at 11:48 AM >> To: "Hale, Britta (CIV)" > >> Cc: Cas Cremers >, Karthikeyan Bhargavan = >, ML Messaging Layer Security = >, Konrad Kohbrok = > >> Subject: Re: [MLS] confirming cipher suites decisions >> =20 >> =20 >>=20 >>=20 >>> On 27 Feb 2020, at 11:47, Benjamin Beurdouche = > = wrote: >>> =20 >>> Hi Britta, >>>=20 >>>=20 >>>> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) > wrote: >>>> =20 >>>> Benjamin, >>>> =20 >>>> The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist. >>> =20 >>> Yes exactly, and I think two-party short lived connections for TLS = are easier to handle >>> than will be the long-lived multi-party connections of MLS. >>>=20 >>>=20 >>>> As has been stated in the working group as a supporting argument to = many changes over the different drafts, within the messaging/MLS space = we are looking at significantly more client-specific control. >>> =20 >>> Yes, and we keep being careful that it is the case when writing the = drafts, >>> but this doesn=E2=80=99t mean that we should be willing to risk = interoperability. >>>=20 >>>=20 >>>> It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI. >>> =20 >>> I think at reverse, if you are willing to break interop, you should = be selecting something >> =20 >> S/should be selecting/can select/ >>=20 >>=20 >>> else than the MTI when creating the group. And again, in what I say, = nothing prevents >>> you to pick the NIST ciphersuite for compliance and use only that. >>> But I don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability. >>> =20 >>> Out of curiosity, where you somehow arguing for multiple MTIs here ? >>> =20 >>> B. >>=20 >>=20 >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_8579ACB5-CEBA-4FA1-8B59-C780B292EB3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am not sure about the practical ramifications of groups where members = use different algorithms.

Still, I think it is feasible to eventually have a design = where the group creator proposes a set of algorithms as =E2=80=9Cmust = implement=E2=80=9D for the group.
Each new member = must support (i.e. implement) =E2=80=9Call=E2=80=9D the algorithms in = this list in order to join the group.
However, the = member has the option to use whichever supported algorithm she prefers = for messages she sends.

While all of this is a reasonable long-term goal, perhaps we = should start with a version where the creator only chooses one algorithm = in each category, leaving no choice to the members.
We can document this choice as a future extension point, and = change it as we understand the federation scenario and deployment = constraints a bit better?

Best,
Karthik


On 27 Feb 2020, at 19:02, = Raphael Robert <raphael@wire.com> wrote:

I agree with what = Karthik said, and I think that that was the underlying assumption all = along (at east for me). The negotiation has to happen ahead of time, = namely when

 - = (1) an existing member proposes to add a new member, or when
 - (2) an external party proposes to add a new = member.

In the = current proposal with a fixed signature per group the decision taking is = rather simple: If the new member advertises support for the group's = ciphersuite in their CIKs, they can be added to the group.

I would like to see the = decision taking fleshed out for the alternative approach that supports = multiple signatures. 
We need to make sure = that members can verify signatures, which means we need a list of = acceptable signature algorithms that every member agrees upon before a = new member is added. Signature algorithms can be advertised in another = extension in CIKs, but it is not entirely clear to me how clients agree = on what the list of acceptable signatures is. Would it be the lowest = common denominator, meaning the intersection of the algorithms = advertised in the CIKs? If so, it means the list gets largely determined = by the early joiners. Also, can the list change over time? That would be = contrary to the idea that all negotiations should happen ahead of = time.
There might an easy solution here, I just = don=E2=80=99t see it right now.

Raphael 

On 27 Feb 2020, at 12:50, Hale, Britta (CIV) <britta.hale@nps.edu>= wrote:

Benjamin, 
 
The point = of comparison with TLS is that interop is significantly less of an issue = when everyone in the group is using the same client program.
 
In terms = of interop, your concerns become a discussion point mainly in the = federation case =E2=80=93 and that is an important case that we should = plan for. But, as I said and you re-iterated, if the use case really = expects interop issues from allowing choice, then nothing prevents the = selection of a single scheme for the set of allowable schemes.
 
As to the = reasons behind allowing multiple algorithms, the document on the = mailinglist has already outlined several =E2=80=93 these are security = reasons for supporting individual algorithms. The interop objections = fall on the usability side, so the current discussion is really about = usability vs. security concerns. However, at the intersection of these = two options is the idea of allowing a set of possible algorithms as = Karthik suggests. This is a good compromise.
 
I would = definitely not suggest that you consider multiple MTIs at this stage. If = that is something you want, it is best to raise it as a separate = issue.
 
---
 
Britta
 
 
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Date: Thursday, February 27, = 2020 at 11:48 AM
To: "Hale, Britta (CIV)" = <britta.hale@nps.edu>
Cc: Cas = Cremers <cas.cremers@gmail.com>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, ML Messaging Layer = Security <mls@ietf.org>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming = cipher suites decisions
 
 


On 27 Feb 2020, at 11:47, Benjamin = Beurdouche <benjamin.beurdouche@inria.fr> wrote:
 
Hi Britta,


On 27 Feb 2020, at 10:57, Hale, Britta = (CIV) <britta.hale@nps.edu> = wrote:
 
Benjamin,
 
The issues you describe are primarily = TLS-type problems, where uncontrolled, large-scale agility and interop = issues exist.
 
Yes exactly, and I think two-party = short lived connections for TLS are easier to handle
than will be the long-lived multi-party connections of = MLS.


As has been stated in the = working group as a supporting argument to many changes over the = different drafts, within the messaging/MLS space we are looking at = significantly more client-specific control.
 
Yes, and we keep being careful that it is the case when = writing the drafts,
but this doesn=E2=80=99t mean that we = should be willing to risk interoperability.


It is not unreasonable for a newcomer to support a selection = of signature schemes. If the group creator really wants full interop, = they can always define the set of available schemes to consist only of = the MTI.
 
I think at reverse, if you are willing to break interop, you = should be selecting something
 
S/should be selecting/can select/


else than the MTI when creating the = group. And again, in what I say, nothing prevents
you to pick the NIST ciphersuite for compliance and use only = that.
But I don=E2=80=99t see the interest of = mixing algs and put at risk implementations and interoperability.
 
Out of curiosity, where you somehow = arguing for multiple MTIs here ?
 
B.


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


= --Apple-Mail=_8579ACB5-CEBA-4FA1-8B59-C780B292EB3E-- From nobody Thu Feb 27 23:22:09 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B500D3A11FF for ; Thu, 27 Feb 2020 23:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j1-PutpvO9b for ; Thu, 27 Feb 2020 23:22:05 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE973A11FE for ; Thu, 27 Feb 2020 23:22:05 -0800 (PST) X-ASG-Debug-ID: 1582874522-0e39454964ced40001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id j6azZYzFBkpXuC5d; Thu, 27 Feb 2020 23:22:02 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Thu, 27 Feb 2020 23:22:02 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.174) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Thu, 27 Feb 2020 23:22:02 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UIiQNTue/ytr+n/ZqP0/bi4Ct+R3WOG5UA1Mf50/t7VbmYFk8TLKYtJxNLYhzk8L3Nx2YhlcOKenykM8kykcujxbLQX5AqgZCm6exQXLZDWIU4HgTB4r969BWCl9WwaCYVX9VF+65wz1MEy3oNo31pjdMOkMT5yPLYGiKr8eI1GxrUNAfYdvVuqugK1GrK7S4s7xu+ANaOltj1zhhNBXdwtKlCNjREBAvBRP+9i0NDuMZs5blD5eNk1/iObpSzLaeMm6m7C1/b2ifGP5i4clhW7opm9HiQ5jbmvklIYZ5hNSqGlKrW998j/nVIkM7bivp1b12m6dqm5VysDbxa4LpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HoTd88jalHg+8FOfhPXe6n2G4YPAcLAwO0ppaoGt2cI=; b=L3IWPNiFF/NqoX3GqqoFdO3bPm/opAfDS7bNkSxmEo7aLTdRauk8iLHcf8P+QG9DgCG5hkBLdmgACUUrozyYYjrj+RlKMg046URsebmA3cddXRllXnbXN79amxiVoHCzFlI4ajKdm4aa1AyBaHuL+EjFtnNsVajnCG2tgTw+0UdL+hnUDbkYBR2OsLuGxfmcu8Jy6VKljV5q+kocma2OWoaPCbJbQBGZDSGkpmIswfOhUMP2xhLAESFo1crN0TWrBhF2f/1YJEf6GhDmaop2V3CdDFJc0fJFhbFhlL90fQU9ygNQ6NOjNq12n8Gb0FeOQdpbKSkc8Yjera0EU6IH1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3586.namprd13.prod.outlook.com (2603:10b6:a03:1ae::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.5; Fri, 28 Feb 2020 07:21:59 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 07:21:59 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:1ae::22] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:1ae::22 From: "Hale, Britta (CIV)" To: Karthik Bhargavan , Raphael Robert CC: Benjamin Beurdouche , Cas Cremers , ML Messaging Layer Security , "Konrad Kohbrok" Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAA4SKA//+JDYCAAJPkAIAAAGYA//+LDgCAAO4egIAAxxUA//+SO4A= Date: Fri, 28 Feb 2020 07:21:58 +0000 Message-ID: <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> In-Reply-To: <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [88.203.39.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3bc4b033-54e1-48fe-68c7-08d7bc1ee609 x-ms-traffictypediagnostic: BY5PR13MB3586: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(376002)(136003)(39850400004)(189003)(199004)(36756003)(478600001)(5660300002)(6486002)(2616005)(966005)(54906003)(786003)(110136005)(316002)(4326008)(75432002)(64756008)(8936002)(66446008)(66476007)(66556008)(26005)(6512007)(81166006)(81156014)(6506007)(53546011)(2906002)(33656002)(91956017)(71200400001)(186003)(66946007)(76116006)(8676002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3586; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qCCOeyyq+MgwtoqBWoTrhPgUoCykcgdwfGzTj0yFWRY+04wHjJFIW423YyFhoGuhYYlz4J0uAQQZxz0MfSv5hU0ujItbVBJYSebRM4zOwVLj4SgHCDTRDQNPV/o5+MSOxibP7ALXMFKSKU2i5Xg+kqu1KY11fA/MzaugWTqr0UpsDupVgwr/wqAjL0GGvjJErUzc6gxuW/hGmw+8NuVxy/Djzgougq14Zlxm7PehDq3Y1So/JP9K8IHfsx5PQ+ldy3uW96Q+aCy2vfEIjnmExocKlcTLGVXa+WvSWodV2rCAyeGxR4fjMjIUDwutoGttBWVbbblUOXJYIr3WBZetOAi0yU+bjxMAkxARXoqKTsnU+Mkf0GLylUic7Q3OmCpTwjTYjhr2NRVPXR6t88vAt9j0mIfEJk2DCN+ZQB0B7HKmGHyQpfoTNd/imqmxjaElFgu/MXGoqn7cyp90XWBX3x+P/ufx6vz7RBQdwD90APLBndTnizK1re76N60yCypUHZLXJoeiRBMmQcrnDce3OQ== x-ms-exchange-antispam-messagedata: j1G+9ZJFY9wZxftgFdzGNkRBKmn29hjVMyLXZzkUTBJLJGnDtDIBLdUh5j4QFcV8WESex5iGr0FucSSzPSvcqq6BmiYP5/z0ejoUx0KDfc1/vmadAfwBMsHfguqcKHm6FVOlpDwLgEcMo5eMx8oJbg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3083F8087A92443CBF7C762C2D2381B0npsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3bc4b033-54e1-48fe-68c7-08d7bc1ee609 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 07:21:58.8742 (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: P93DmqkpMdDOtK50L1lAQdjf10h3g5deDMoazyjp0L1twQ2w1qX/60k5mBNAwymmJqlq2rZUAyZ5IgsQvX9NPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3586 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1582874522 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 31388 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80313 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 07:22:08 -0000 --_000_3083F8087A92443CBF7C762C2D2381B0npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGVybXMgb2YgbmVnb3RpYXRpb24sIEkgdGhpbmsgd2UgY2FuIGNsb3NlbHkgY29ycmVsYXRl IHRoZSBpc3N1ZXMgYW5kIHByYWN0aWNhbCByYW1pZmljYXRpb25zIGluIGNob29zaW5nIGEgc2ln bmF0dXJlIHNjaGVtZSBsaXN0IHdpdGggdGhlIGNpcGhlcnN1aXRlIG5lZ290aWF0aW9uIHRoYXQg YWxyZWFkeSB0YWtlcyBwbGFjZS4NCkxldCB1cyBhc3N1bWUgdGhhdCBldmVyeSBtZW1iZXIgd291 bGQgbm90IG9ubHkgaGF2ZSBhIGxpc3Qgb2Ygc3VwcG9ydGVkIGNpcGhlcnN1aXRlcyBpbiB0aGVp ciBDSUssIGJ1dCBhbHNvIG9mIHNpZ25hdHVyZSBzY2hlbWVzLiBUaGUgYWN0aW9uIG9mIHRoZSBn cm91cCBjcmVhdG9yIGlzIHRoZW4gY29tcGFyYWJsZSBpbiB0aGUgZm9sbG93aW5nIGEvYiBjYXNl cyBmb3IgY2lwaGVyc3VpdGVzL3NpZ25hdHVyZSBzY2hlbWVzOg0KDQoNCiAgMS4gIFRoZSBncm91 cCBjcmVhdG9yIHdhbnRzIHRvIGVuc3VyZSBhbnkgbmV3Y29tZXIgY2FuIGpvaW4gdGhlIGdyb3Vw Og0KICAgICAqICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyB0aGUgTVRJIGNpcGhlcnN1aXRl Lg0KICAgICAqICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyB0aGUgTVRJIGFzIHRoZSBzaW5n bGUgZWxlbWVudCBpbiB0aGUgc2V0IG9mIHBvc3NpYmxlIHNpZ25hdHVyZXMuDQoNCg0KDQogIDEu ICBUaGUgZ3JvdXAgY3JlYXRvciB3YW50cyBtb3JlIGNvbnRyb2wgYW5kIGlzIG5vdCBwYXJ0aWN1 bGFybHkgY29uY2VybmVkIGFib3V0IG5ld2NvbWVycyBpbiB0aGUgbG9uZy10ZXJtOg0KICAgICAq ICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyBhIG5vbi1NVEkgY2lwaGVyc3VpdGUgZnJvbSB0 aGUgaW5pdGlhbCBncm91cCBtZW1iZXJz4oCZIGxpc3RzLg0KICAgICAqICAgVGhlIGdyb3VwIGNy ZWF0b3IgY2hvb3NlcyBhIHN1YnNldCBvZiBpbml0aWFsIGdyb3VwIG1lbWJlcnPigJkgc3VwcG9y dGVkIGFsZ29yaXRobXMgKHdoaWNoIG1heSBvciBtYXkgbm90IGluY2x1ZGUgdGhlIE1USSkuDQpG b3IgdGhlIHNha2Ugb2YgYXJndW1lbnQsIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgYWx0ZXJuYXRp dmUgdG8gYjoNCg0KICAgICAqICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyBhIHNpbmdsZSBu b24tTVRJIHNpZ25hdHVyZSBzY2hlbWUuDQoNClRoZSBpc3N1ZXMgZm9yIG5ld2NvbWVycyBpbiBj YXNlIDJiIGlzIG5vdCB2ZXJ5IGRpZmZlcmVudCBmcm9tIDJjICh3aGljaCBpcyB1bHRpbWF0ZWx5 IHRoZSBjYXNlIGlmIHdlIG9ubHkgc3VwcG9ydCBvbmUgc2NoZW1lKS4gQmFzaWNhbGx5LCB0aGUg bmV3Y29tZXIgc3VwcG9ydHMgdGhlIHNjaGVtZS9zZXQgb2Ygc2NoZW1lcyBvciBoZSBkb2VzIG5v dC4gSW4gMmEsIDJiLCBhbmQgMmMsIGFsZ29yaXRobXMgYXJlIGRpY3RhdGVkIGJ5IHRoZSBzZXQg b2YgaW5pdGlhbCBtZW1iZXJzLCBzbyB3ZSBhcmUgbm90IGxvb2tpbmcgYXQgYSBzaWduaWZpY2Fu dCB1c2FiaWxpdHkgZGlmZmVyZW5jZSB0aGVyZS4NCg0KRm9yIGNob29zaW5nIHRoZSBzaWduYXR1 cmUgc2NoZW1lIGxpc3QsIGFueSBwcm9wZXIgc3Vic2V0IG9mIHRoZSBpbnRlcnNlY3Rpb24gb2Yg dGhlIGluaXRpYWwgZ3JvdXAgbWVtYmVyc+KAmSBsaXN0IHdvdWxkIGJlIHBvc3NpYmxlIChoZW5j ZSB3aHkgd2UgaGF2ZSBmcmVlZG9tIHRvIGNob29zZSB7TVRJfSBpbiBjYXNlIDFiKS4gSG93ZXZl ciwgd2UgY291bGQgbWFrZSBpdCBzaW1wbGUgYW5kIHVzZSB0aGUgYWN0dWFsIGludGVyc2VjdGlv bi4NCg0KQXMgZmFyIGFzIGxpc3RzIGNoYW5naW5nIG92ZXIgdGltZTogaW4gdGVybXMgb2Ygd2hh dCBhIG1lbWJlciBjYW4gc3VwcG9ydCB0aGUgYW5zd2VyIGlzIGFuIGFmZmlybWF0aXZlLiBJbiB0 aGUgc2FtZSB3YXkgdGhlIHN1cHBvcnRlZCBjaXBoZXJzdWl0ZXMgY2FuIGNoYW5nZSBvdmVyIHRp bWUsIHRoZSBzdXBwb3J0ZWQgc2lnbmF0dXJlIHNjaGVtZXMgY2FuIGFzIHdlbGwuIEhvd2V2ZXIs IGluIHRlcm1zIG9mIHdoYXQgaXMgdXNlZCBpbiB0aGUgZ3JvdXAsIHRoaXMgc2hvdWxkIG5vdCBj aGFuZ2U6IG9uY2UgZml4ZWQgYXQgZ3JvdXAgaW5pdGlhdGlvbiB0aGUgbGlzdCBpcyBzdGF0aWMg Zm9yIHRoZSBsaWZldGltZSBvZiB0aGUgZ3JvdXAuIE9uY2UgYSBtZW1iZXIgaGFzIGNob3NlbiBh IHNpZ25hdHVyZSBzY2hlbWUgZnJvbSB0aGUgbGlzdCwgdGhlIGNob2ljZSBpcyBzdGF0aWMgZm9y IHRoZSBsaWZldGltZSBvZiB0aGUgZ3JvdXAuIFRoZSBncm91cCBzaG91bGQgdGh1cyBub3QgYmUg YWRhcHRhYmxlIHRvIGNoYW5nZXMgaW4gdGhlIG9mZmVyZWQgYWxnb3JpdGhtcyBvZiB0aGUgQ0lL cy4NCg0KQnJpdHRhDQoNCg0KDQpGcm9tOiBLYXJ0aGlrIEJoYXJnYXZhbiA8a2FydGhpa2V5YW4u YmhhcmdhdmFuQGlucmlhLmZyPg0KRGF0ZTogRnJpZGF5LCBGZWJydWFyeSAyOCwgMjAyMCBhdCA2 OjU1IEFNDQpUbzogUmFwaGFlbCBSb2JlcnQgPHJhcGhhZWxAd2lyZS5jb20+DQpDYzogIkhhbGUs IEJyaXR0YSAoQ0lWKSIgPGJyaXR0YS5oYWxlQG5wcy5lZHU+LCBCZW5qYW1pbiBCZXVyZG91Y2hl IDxiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPiwgQ2FzIENyZW1lcnMgPGNhcy5jcmVtZXJz QGdtYWlsLmNvbT4sIE1MIE1lc3NhZ2luZyBMYXllciBTZWN1cml0eSA8bWxzQGlldGYub3JnPiwg S29ucmFkIEtvaGJyb2sgPEtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU+DQpTdWJqZWN0OiBS ZTogW01MU10gY29uZmlybWluZyBjaXBoZXIgc3VpdGVzIGRlY2lzaW9ucw0KDQpJIGFtIG5vdCBz dXJlIGFib3V0IHRoZSBwcmFjdGljYWwgcmFtaWZpY2F0aW9ucyBvZiBncm91cHMgd2hlcmUgbWVt YmVycyB1c2UgZGlmZmVyZW50IGFsZ29yaXRobXMuDQoNClN0aWxsLCBJIHRoaW5rIGl0IGlzIGZl YXNpYmxlIHRvIGV2ZW50dWFsbHkgaGF2ZSBhIGRlc2lnbiB3aGVyZSB0aGUgZ3JvdXAgY3JlYXRv ciBwcm9wb3NlcyBhIHNldCBvZiBhbGdvcml0aG1zIGFzIOKAnG11c3QgaW1wbGVtZW504oCdIGZv ciB0aGUgZ3JvdXAuDQpFYWNoIG5ldyBtZW1iZXIgbXVzdCBzdXBwb3J0IChpLmUuIGltcGxlbWVu dCkg4oCcYWxs4oCdIHRoZSBhbGdvcml0aG1zIGluIHRoaXMgbGlzdCBpbiBvcmRlciB0byBqb2lu IHRoZSBncm91cC4NCkhvd2V2ZXIsIHRoZSBtZW1iZXIgaGFzIHRoZSBvcHRpb24gdG8gdXNlIHdo aWNoZXZlciBzdXBwb3J0ZWQgYWxnb3JpdGhtIHNoZSBwcmVmZXJzIGZvciBtZXNzYWdlcyBzaGUg c2VuZHMuDQoNCldoaWxlIGFsbCBvZiB0aGlzIGlzIGEgcmVhc29uYWJsZSBsb25nLXRlcm0gZ29h bCwgcGVyaGFwcyB3ZSBzaG91bGQgc3RhcnQgd2l0aCBhIHZlcnNpb24gd2hlcmUgdGhlIGNyZWF0 b3Igb25seSBjaG9vc2VzIG9uZSBhbGdvcml0aG0gaW4gZWFjaCBjYXRlZ29yeSwgbGVhdmluZyBu byBjaG9pY2UgdG8gdGhlIG1lbWJlcnMuDQpXZSBjYW4gZG9jdW1lbnQgdGhpcyBjaG9pY2UgYXMg YSBmdXR1cmUgZXh0ZW5zaW9uIHBvaW50LCBhbmQgY2hhbmdlIGl0IGFzIHdlIHVuZGVyc3RhbmQg dGhlIGZlZGVyYXRpb24gc2NlbmFyaW8gYW5kIGRlcGxveW1lbnQgY29uc3RyYWludHMgYSBiaXQg YmV0dGVyPw0KDQpCZXN0LA0KS2FydGhpaw0KDQoNCg0KT24gMjcgRmViIDIwMjAsIGF0IDE5OjAy LCBSYXBoYWVsIFJvYmVydCA8cmFwaGFlbEB3aXJlLmNvbTxtYWlsdG86cmFwaGFlbEB3aXJlLmNv bT4+IHdyb3RlOg0KDQpJIGFncmVlIHdpdGggd2hhdCBLYXJ0aGlrIHNhaWQsIGFuZCBJIHRoaW5r IHRoYXQgdGhhdCB3YXMgdGhlIHVuZGVybHlpbmcgYXNzdW1wdGlvbiBhbGwgYWxvbmcgKGF0IGVh c3QgZm9yIG1lKS4gVGhlIG5lZ290aWF0aW9uIGhhcyB0byBoYXBwZW4gYWhlYWQgb2YgdGltZSwg bmFtZWx5IHdoZW4NCg0KIC0gKDEpIGFuIGV4aXN0aW5nIG1lbWJlciBwcm9wb3NlcyB0byBhZGQg YSBuZXcgbWVtYmVyLCBvciB3aGVuDQogLSAoMikgYW4gZXh0ZXJuYWwgcGFydHkgcHJvcG9zZXMg dG8gYWRkIGEgbmV3IG1lbWJlci4NCg0KSW4gdGhlIGN1cnJlbnQgcHJvcG9zYWwgd2l0aCBhIGZp eGVkIHNpZ25hdHVyZSBwZXIgZ3JvdXAgdGhlIGRlY2lzaW9uIHRha2luZyBpcyByYXRoZXIgc2lt cGxlOiBJZiB0aGUgbmV3IG1lbWJlciBhZHZlcnRpc2VzIHN1cHBvcnQgZm9yIHRoZSBncm91cCdz IGNpcGhlcnN1aXRlIGluIHRoZWlyIENJS3MsIHRoZXkgY2FuIGJlIGFkZGVkIHRvIHRoZSBncm91 cC4NCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgZGVjaXNpb24gdGFraW5nIGZsZXNoZWQgb3V0 IGZvciB0aGUgYWx0ZXJuYXRpdmUgYXBwcm9hY2ggdGhhdCBzdXBwb3J0cyBtdWx0aXBsZSBzaWdu YXR1cmVzLg0KV2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBtZW1iZXJzIGNhbiB2ZXJpZnkgc2ln bmF0dXJlcywgd2hpY2ggbWVhbnMgd2UgbmVlZCBhIGxpc3Qgb2YgYWNjZXB0YWJsZSBzaWduYXR1 cmUgYWxnb3JpdGhtcyB0aGF0IGV2ZXJ5IG1lbWJlciBhZ3JlZXMgdXBvbiBiZWZvcmUgYSBuZXcg bWVtYmVyIGlzIGFkZGVkLiBTaWduYXR1cmUgYWxnb3JpdGhtcyBjYW4gYmUgYWR2ZXJ0aXNlZCBp biBhbm90aGVyIGV4dGVuc2lvbiBpbiBDSUtzLCBidXQgaXQgaXMgbm90IGVudGlyZWx5IGNsZWFy IHRvIG1lIGhvdyBjbGllbnRzIGFncmVlIG9uIHdoYXQgdGhlIGxpc3Qgb2YgYWNjZXB0YWJsZSBz aWduYXR1cmVzIGlzLiBXb3VsZCBpdCBiZSB0aGUgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciwg bWVhbmluZyB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZSBhbGdvcml0aG1zIGFkdmVydGlzZWQgaW4g dGhlIENJS3M/IElmIHNvLCBpdCBtZWFucyB0aGUgbGlzdCBnZXRzIGxhcmdlbHkgZGV0ZXJtaW5l ZCBieSB0aGUgZWFybHkgam9pbmVycy4gQWxzbywgY2FuIHRoZSBsaXN0IGNoYW5nZSBvdmVyIHRp bWU/IFRoYXQgd291bGQgYmUgY29udHJhcnkgdG8gdGhlIGlkZWEgdGhhdCBhbGwgbmVnb3RpYXRp b25zIHNob3VsZCBoYXBwZW4gYWhlYWQgb2YgdGltZS4NClRoZXJlIG1pZ2h0IGFuIGVhc3kgc29s dXRpb24gaGVyZSwgSSBqdXN0IGRvbuKAmXQgc2VlIGl0IHJpZ2h0IG5vdy4NCg0KUmFwaGFlbA0K DQoNCk9uIDI3IEZlYiAyMDIwLCBhdCAxMjo1MCwgSGFsZSwgQnJpdHRhIChDSVYpIDxicml0dGEu aGFsZUBucHMuZWR1PG1haWx0bzpicml0dGEuaGFsZUBucHMuZWR1Pj4gd3JvdGU6DQoNCkJlbmph bWluLA0KDQpUaGUgcG9pbnQgb2YgY29tcGFyaXNvbiB3aXRoIFRMUyBpcyB0aGF0IGludGVyb3Ag aXMgc2lnbmlmaWNhbnRseSBsZXNzIG9mIGFuIGlzc3VlIHdoZW4gZXZlcnlvbmUgaW4gdGhlIGdy b3VwIGlzIHVzaW5nIHRoZSBzYW1lIGNsaWVudCBwcm9ncmFtLg0KDQpJbiB0ZXJtcyBvZiBpbnRl cm9wLCB5b3VyIGNvbmNlcm5zIGJlY29tZSBhIGRpc2N1c3Npb24gcG9pbnQgbWFpbmx5IGluIHRo ZSBmZWRlcmF0aW9uIGNhc2Ug4oCTIGFuZCB0aGF0IGlzIGFuIGltcG9ydGFudCBjYXNlIHRoYXQg d2Ugc2hvdWxkIHBsYW4gZm9yLiBCdXQsIGFzIEkgc2FpZCBhbmQgeW91IHJlLWl0ZXJhdGVkLCBp ZiB0aGUgdXNlIGNhc2UgcmVhbGx5IGV4cGVjdHMgaW50ZXJvcCBpc3N1ZXMgZnJvbSBhbGxvd2lu ZyBjaG9pY2UsIHRoZW4gbm90aGluZyBwcmV2ZW50cyB0aGUgc2VsZWN0aW9uIG9mIGEgc2luZ2xl IHNjaGVtZSBmb3IgdGhlIHNldCBvZiBhbGxvd2FibGUgc2NoZW1lcy4NCg0KQXMgdG8gdGhlIHJl YXNvbnMgYmVoaW5kIGFsbG93aW5nIG11bHRpcGxlIGFsZ29yaXRobXMsIHRoZSBkb2N1bWVudCBv biB0aGUgbWFpbGluZ2xpc3QgaGFzIGFscmVhZHkgb3V0bGluZWQgc2V2ZXJhbCDigJMgdGhlc2Ug YXJlIHNlY3VyaXR5IHJlYXNvbnMgZm9yIHN1cHBvcnRpbmcgaW5kaXZpZHVhbCBhbGdvcml0aG1z LiBUaGUgaW50ZXJvcCBvYmplY3Rpb25zIGZhbGwgb24gdGhlIHVzYWJpbGl0eSBzaWRlLCBzbyB0 aGUgY3VycmVudCBkaXNjdXNzaW9uIGlzIHJlYWxseSBhYm91dCB1c2FiaWxpdHkgdnMuIHNlY3Vy aXR5IGNvbmNlcm5zLiBIb3dldmVyLCBhdCB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZXNlIHR3byBv cHRpb25zIGlzIHRoZSBpZGVhIG9mIGFsbG93aW5nIGEgc2V0IG9mIHBvc3NpYmxlIGFsZ29yaXRo bXMgYXMgS2FydGhpayBzdWdnZXN0cy4gVGhpcyBpcyBhIGdvb2QgY29tcHJvbWlzZS4NCg0KSSB3 b3VsZCBkZWZpbml0ZWx5IG5vdCBzdWdnZXN0IHRoYXQgeW91IGNvbnNpZGVyIG11bHRpcGxlIE1U SXMgYXQgdGhpcyBzdGFnZS4gSWYgdGhhdCBpcyBzb21ldGhpbmcgeW91IHdhbnQsIGl0IGlzIGJl c3QgdG8gcmFpc2UgaXQgYXMgYSBzZXBhcmF0ZSBpc3N1ZS4NCg0KLS0tDQoNCkJyaXR0YQ0KDQoN CkZyb206IEJlbmphbWluIEJldXJkb3VjaGUgPGJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI8 bWFpbHRvOmJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI+Pg0KRGF0ZTogVGh1cnNkYXksIEZl YnJ1YXJ5IDI3LCAyMDIwIGF0IDExOjQ4IEFNDQpUbzogIkhhbGUsIEJyaXR0YSAoQ0lWKSIgPGJy aXR0YS5oYWxlQG5wcy5lZHU8bWFpbHRvOmJyaXR0YS5oYWxlQG5wcy5lZHU+Pg0KQ2M6IENhcyBD cmVtZXJzIDxjYXMuY3JlbWVyc0BnbWFpbC5jb208bWFpbHRvOmNhcy5jcmVtZXJzQGdtYWlsLmNv bT4+LCBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gPGthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5m cjxtYWlsdG86a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPj4sIE1MIE1lc3NhZ2luZyBM YXllciBTZWN1cml0eSA8bWxzQGlldGYub3JnPG1haWx0bzptbHNAaWV0Zi5vcmc+PiwgS29ucmFk IEtvaGJyb2sgPGtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU8bWFpbHRvOmtvbnJhZC5rb2hi cm9rQGRhdGFzaHJpbmUuZGU+Pg0KU3ViamVjdDogUmU6IFtNTFNdIGNvbmZpcm1pbmcgY2lwaGVy IHN1aXRlcyBkZWNpc2lvbnMNCg0KDQoNCg0KDQpPbiAyNyBGZWIgMjAyMCwgYXQgMTE6NDcsIEJl bmphbWluIEJldXJkb3VjaGUgPGJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI8bWFpbHRvOmJl bmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI+PiB3cm90ZToNCg0KSGkgQnJpdHRhLA0KDQoNCg0K T24gMjcgRmViIDIwMjAsIGF0IDEwOjU3LCBIYWxlLCBCcml0dGEgKENJVikgPGJyaXR0YS5oYWxl QG5wcy5lZHU8bWFpbHRvOmJyaXR0YS5oYWxlQG5wcy5lZHU+PiB3cm90ZToNCg0KQmVuamFtaW4s DQoNClRoZSBpc3N1ZXMgeW91IGRlc2NyaWJlIGFyZSBwcmltYXJpbHkgVExTLXR5cGUgcHJvYmxl bXMsIHdoZXJlIHVuY29udHJvbGxlZCwgbGFyZ2Utc2NhbGUgYWdpbGl0eSBhbmQgaW50ZXJvcCBp c3N1ZXMgZXhpc3QuDQoNClllcyBleGFjdGx5LCBhbmQgSSB0aGluayB0d28tcGFydHkgc2hvcnQg bGl2ZWQgY29ubmVjdGlvbnMgZm9yIFRMUyBhcmUgZWFzaWVyIHRvIGhhbmRsZQ0KdGhhbiB3aWxs IGJlIHRoZSBsb25nLWxpdmVkIG11bHRpLXBhcnR5IGNvbm5lY3Rpb25zIG9mIE1MUy4NCg0KDQoN CkFzIGhhcyBiZWVuIHN0YXRlZCBpbiB0aGUgd29ya2luZyBncm91cCBhcyBhIHN1cHBvcnRpbmcg YXJndW1lbnQgdG8gbWFueSBjaGFuZ2VzIG92ZXIgdGhlIGRpZmZlcmVudCBkcmFmdHMsIHdpdGhp biB0aGUgbWVzc2FnaW5nL01MUyBzcGFjZSB3ZSBhcmUgbG9va2luZyBhdCBzaWduaWZpY2FudGx5 IG1vcmUgY2xpZW50LXNwZWNpZmljIGNvbnRyb2wuDQoNClllcywgYW5kIHdlIGtlZXAgYmVpbmcg Y2FyZWZ1bCB0aGF0IGl0IGlzIHRoZSBjYXNlIHdoZW4gd3JpdGluZyB0aGUgZHJhZnRzLA0KYnV0 IHRoaXMgZG9lc27igJl0IG1lYW4gdGhhdCB3ZSBzaG91bGQgYmUgd2lsbGluZyB0byByaXNrIGlu dGVyb3BlcmFiaWxpdHkuDQoNCg0KDQpJdCBpcyBub3QgdW5yZWFzb25hYmxlIGZvciBhIG5ld2Nv bWVyIHRvIHN1cHBvcnQgYSBzZWxlY3Rpb24gb2Ygc2lnbmF0dXJlIHNjaGVtZXMuIElmIHRoZSBn cm91cCBjcmVhdG9yIHJlYWxseSB3YW50cyBmdWxsIGludGVyb3AsIHRoZXkgY2FuIGFsd2F5cyBk ZWZpbmUgdGhlIHNldCBvZiBhdmFpbGFibGUgc2NoZW1lcyB0byBjb25zaXN0IG9ubHkgb2YgdGhl IE1USS4NCg0KSSB0aGluayBhdCByZXZlcnNlLCBpZiB5b3UgYXJlIHdpbGxpbmcgdG8gYnJlYWsg aW50ZXJvcCwgeW91IHNob3VsZCBiZSBzZWxlY3Rpbmcgc29tZXRoaW5nDQoNClMvc2hvdWxkIGJl IHNlbGVjdGluZy9jYW4gc2VsZWN0Lw0KDQoNCg0KZWxzZSB0aGFuIHRoZSBNVEkgd2hlbiBjcmVh dGluZyB0aGUgZ3JvdXAuIEFuZCBhZ2FpbiwgaW4gd2hhdCBJIHNheSwgbm90aGluZyBwcmV2ZW50 cw0KeW91IHRvIHBpY2sgdGhlIE5JU1QgY2lwaGVyc3VpdGUgZm9yIGNvbXBsaWFuY2UgYW5kIHVz ZSBvbmx5IHRoYXQuDQpCdXQgSSBkb27igJl0IHNlZSB0aGUgaW50ZXJlc3Qgb2YgbWl4aW5nIGFs Z3MgYW5kIHB1dCBhdCByaXNrIGltcGxlbWVudGF0aW9ucyBhbmQgaW50ZXJvcGVyYWJpbGl0eS4N Cg0KT3V0IG9mIGN1cmlvc2l0eSwgd2hlcmUgeW91IHNvbWVob3cgYXJndWluZyBmb3IgbXVsdGlw bGUgTVRJcyBoZXJlID8NCg0KQi4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpNTFMgbWFpbGluZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFpbHRv Ok1MU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxz DQoNCg0K --_000_3083F8087A92443CBF7C762C2D2381B0npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <7F4D74AB0E79974CA4827879AD3F3FA2@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEzNjgwOTQyMDk7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00Mzk4MzE2OCA2NzY5ODcwNSA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTkyODM0NDk1MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQzOTgzMTY4IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5JbiB0ZXJtcyBvZiBuZWdvdGlhdGlvbiwgSSB0aGluayB3ZSBjYW4gY2xvc2VseSBjb3JyZWxh dGUgdGhlIGlzc3VlcyBhbmQgcHJhY3RpY2FsIHJhbWlmaWNhdGlvbnMgaW4gY2hvb3NpbmcgYSBz aWduYXR1cmUgc2NoZW1lIGxpc3Qgd2l0aCB0aGUgY2lwaGVyc3VpdGUgbmVnb3RpYXRpb24gdGhh dCBhbHJlYWR5IHRha2VzIHBsYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5MZXQgdXMg YXNzdW1lIHRoYXQgZXZlcnkgbWVtYmVyIHdvdWxkIG5vdCBvbmx5IGhhdmUgYSBsaXN0IG9mIHN1 cHBvcnRlZCBjaXBoZXJzdWl0ZXMgaW4gdGhlaXIgQ0lLLCBidXQgYWxzbyBvZiBzaWduYXR1cmUg c2NoZW1lcy4gVGhlIGFjdGlvbiBvZiB0aGUgZ3JvdXAgY3JlYXRvciBpcyB0aGVuIGNvbXBhcmFi bGUgaW4gdGhlIGZvbGxvd2luZyBhL2IgY2FzZXMgZm9yDQogY2lwaGVyc3VpdGVzL3NpZ25hdHVy ZSBzY2hlbWVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPG9s IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6YmxhY2s7bWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBncm91cCBjcmVhdG9yIHdhbnRzIHRvIGVuc3VyZSBh bnkgbmV3Y29tZXIgY2FuIGpvaW4gdGhlIGdyb3VwOjxvOnA+PC9vOnA+PC9saT48b2wgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjpibGFjazttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzEiPg0KVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyB0aGUgTVRJIGNpcGhlcnN1 aXRlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJj b2xvcjpibGFjazttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KVGhl IGdyb3VwIGNyZWF0b3IgY2hvb3NlcyB0aGUgTVRJIGFzIHRoZSBzaW5nbGUgZWxlbWVudCBpbiB0 aGUgc2V0IG9mIHBvc3NpYmxlIHNpZ25hdHVyZXMuPG86cD48L286cD48L2xpPjwvb2w+DQo8L29s Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjpibGFjazttYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIGdyb3VwIGNyZWF0b3Igd2FudHMgbW9yZSBjb250 cm9sIGFuZCBpcyBub3QgcGFydGljdWxhcmx5IGNvbmNlcm5lZCBhYm91dCBuZXdjb21lcnMgaW4g dGhlIGxvbmctdGVybTo8bzpwPjwvbzpwPjwvbGk+PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg c3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i Y29sb3I6YmxhY2s7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NClRo ZSBncm91cCBjcmVhdG9yIGNob29zZXMgYSBub24tTVRJIGNpcGhlcnN1aXRlIGZyb20gdGhlIGlu aXRpYWwgZ3JvdXAgbWVtYmVyc+KAmSBsaXN0cy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6YmxhY2s7bWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwwIGxldmVsMiBsZm8xIj4NClRoZSBncm91cCBjcmVhdG9yIGNob29zZXMgYSBzdWJzZXQg b2YgaW5pdGlhbCBncm91cCBtZW1iZXJz4oCZIHN1cHBvcnRlZCBhbGdvcml0aG1zICh3aGljaCBt YXkgb3IgbWF5IG5vdCBpbmNsdWRlIHRoZSBNVEkpLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9v bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Rm9yIHRo ZSBzYWtlIG9mIGFyZ3VtZW50LCBjb25zaWRlciB0aGUgZm9sbG93aW5nIGFsdGVybmF0aXZlIHRv IGI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3Rh cnQ9IjIiIHR5cGU9IjEiPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5 cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6YmxhY2s7 bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NClRoZSBncm91cCBjcmVh dG9yIGNob29zZXMgYSBzaW5nbGUgbm9uLU1USSBzaWduYXR1cmUgc2NoZW1lLjxvOnA+PC9vOnA+ PC9saT48L29sPg0KPC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgaXNzdWVzIGZvciBuZXdjb21lcnMgaW4g Y2FzZSAyYiBpcyBub3QgdmVyeSBkaWZmZXJlbnQgZnJvbSAyYyAod2hpY2ggaXMgdWx0aW1hdGVs eSB0aGUgY2FzZSBpZiB3ZSBvbmx5IHN1cHBvcnQgb25lIHNjaGVtZSkuIEJhc2ljYWxseSwgdGhl IG5ld2NvbWVyIHN1cHBvcnRzIHRoZSBzY2hlbWUvc2V0IG9mIHNjaGVtZXMgb3IgaGUgZG9lcyBu b3QuIEluIDJhLA0KIDJiLCBhbmQgMmMsIGFsZ29yaXRobXMgYXJlIGRpY3RhdGVkIGJ5IHRoZSBz ZXQgb2YgaW5pdGlhbCBtZW1iZXJzLCBzbyB3ZSBhcmUgbm90IGxvb2tpbmcgYXQgYSBzaWduaWZp Y2FudCB1c2FiaWxpdHkgZGlmZmVyZW5jZSB0aGVyZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5Gb3IgY2hvb3NpbmcgdGhlIHNpZ25hdHVyZSBzY2hlbWUgbGlzdCwgYW55IHBy b3BlciBzdWJzZXQgb2YgdGhlIGludGVyc2VjdGlvbiBvZiB0aGUgaW5pdGlhbCBncm91cCBtZW1i ZXJz4oCZIGxpc3Qgd291bGQgYmUgcG9zc2libGUgKGhlbmNlIHdoeSB3ZSBoYXZlIGZyZWVkb20g dG8gY2hvb3NlIHtNVEl9IGluIGNhc2UgMWIpLiBIb3dldmVyLCB3ZSBjb3VsZCBtYWtlDQogaXQg c2ltcGxlIGFuZCB1c2UgdGhlIGFjdHVhbCBpbnRlcnNlY3Rpb24uIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5BcyBmYXIgYXMgbGlzdHMgY2hhbmdpbmcgb3ZlciB0aW1lOiBpbiB0 ZXJtcyBvZiB3aGF0IGEgbWVtYmVyIGNhbiBzdXBwb3J0IHRoZSBhbnN3ZXIgaXMgYW4gYWZmaXJt YXRpdmUuIEluIHRoZSBzYW1lIHdheSB0aGUgc3VwcG9ydGVkIGNpcGhlcnN1aXRlcyBjYW4gY2hh bmdlIG92ZXIgdGltZSwgdGhlIHN1cHBvcnRlZCBzaWduYXR1cmUgc2NoZW1lcyBjYW4gYXMgd2Vs bC4NCiBIb3dldmVyLCBpbiB0ZXJtcyBvZiB3aGF0IGlzIHVzZWQgaW4gdGhlIGdyb3VwLCB0aGlz IHNob3VsZCBub3QgY2hhbmdlOiBvbmNlIGZpeGVkIGF0IGdyb3VwIGluaXRpYXRpb24gdGhlIGxp c3QgaXMgc3RhdGljIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlIGdyb3VwLiBPbmNlIGEgbWVtYmVy IGhhcyBjaG9zZW4gYSBzaWduYXR1cmUgc2NoZW1lIGZyb20gdGhlIGxpc3QsIHRoZSBjaG9pY2Ug aXMgc3RhdGljIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlDQogZ3JvdXAuIFRoZSBncm91cCBzaG91 bGQgdGh1cyBub3QgYmUgYWRhcHRhYmxlIHRvIGNoYW5nZXMgaW4gdGhlIG9mZmVyZWQgYWxnb3Jp dGhtcyBvZiB0aGUgQ0lLcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyaXR0YTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkthcnRoaWsg QmhhcmdhdmFuICZsdDtrYXJ0aGlrZXlhbi5iaGFyZ2F2YW5AaW5yaWEuZnImZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPkZyaWRheSwgRmVicnVhcnkgMjgsIDIwMjAgYXQgNjo1NSBBTTxicj4NCjxiPlRv OiA8L2I+UmFwaGFlbCBSb2JlcnQgJmx0O3JhcGhhZWxAd2lyZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDtIYWxlLCBCcml0dGEgKENJVikmcXVvdDsgJmx0O2JyaXR0YS5oYWxlQG5wcy5l ZHUmZ3Q7LCBCZW5qYW1pbiBCZXVyZG91Y2hlICZsdDtiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlh LmZyJmd0OywgQ2FzIENyZW1lcnMgJmx0O2Nhcy5jcmVtZXJzQGdtYWlsLmNvbSZndDssIE1MIE1l c3NhZ2luZyBMYXllciBTZWN1cml0eSAmbHQ7bWxzQGlldGYub3JnJmd0OywgS29ucmFkIEtvaGJy b2sgJmx0O0tvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGUmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbTUxTXSBjb25maXJtaW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHN1 cmUgYWJvdXQgdGhlIHByYWN0aWNhbCByYW1pZmljYXRpb25zIG9mIGdyb3VwcyB3aGVyZSBtZW1i ZXJzIHVzZSBkaWZmZXJlbnQgYWxnb3JpdGhtcy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlN0aWxsLCBJIHRoaW5rIGl0IGlzIGZlYXNpYmxlIHRvIGV2ZW50dWFsbHkg aGF2ZSBhIGRlc2lnbiB3aGVyZSB0aGUgZ3JvdXAgY3JlYXRvciBwcm9wb3NlcyBhIHNldCBvZiBh bGdvcml0aG1zIGFzIOKAnG11c3QgaW1wbGVtZW504oCdIGZvciB0aGUgZ3JvdXAuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FYWNoIG5ldyBtZW1i ZXIgbXVzdCBzdXBwb3J0IChpLmUuIGltcGxlbWVudCkg4oCcYWxs4oCdIHRoZSBhbGdvcml0aG1z IGluIHRoaXMgbGlzdCBpbiBvcmRlciB0byBqb2luIHRoZSBncm91cC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHRoZSBtZW1iZXIg aGFzIHRoZSBvcHRpb24gdG8gdXNlIHdoaWNoZXZlciBzdXBwb3J0ZWQgYWxnb3JpdGhtIHNoZSBw cmVmZXJzIGZvciBtZXNzYWdlcyBzaGUgc2VuZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIGFsbCBvZiB0aGlzIGlzIGEgcmVhc29u YWJsZSBsb25nLXRlcm0gZ29hbCwgcGVyaGFwcyB3ZSBzaG91bGQgc3RhcnQgd2l0aCBhIHZlcnNp b24gd2hlcmUgdGhlIGNyZWF0b3Igb25seSBjaG9vc2VzIG9uZSBhbGdvcml0aG0gaW4gZWFjaCBj YXRlZ29yeSwgbGVhdmluZyBubyBjaG9pY2UgdG8gdGhlIG1lbWJlcnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjYW4gZG9jdW1lbnQgdGhp cyBjaG9pY2UgYXMgYSBmdXR1cmUgZXh0ZW5zaW9uIHBvaW50LCBhbmQgY2hhbmdlIGl0IGFzIHdl IHVuZGVyc3RhbmQgdGhlIGZlZGVyYXRpb24gc2NlbmFyaW8gYW5kIGRlcGxveW1lbnQgY29uc3Ry YWludHMgYSBiaXQgYmV0dGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+S2FydGhpazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNyBGZWIgMjAyMCwgYXQgMTk6MDIs IFJhcGhhZWwgUm9iZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86cmFwaGFlbEB3aXJlLmNvbSI+cmFw aGFlbEB3aXJlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIHdoYXQgS2FydGhpayBzYWlkLCBhbmQgSSB0 aGluayB0aGF0IHRoYXQgd2FzIHRoZSB1bmRlcmx5aW5nIGFzc3VtcHRpb24gYWxsIGFsb25nIChh dCBlYXN0IGZvciBtZSkuIFRoZSBuZWdvdGlhdGlvbiBoYXMgdG8gaGFwcGVuIGFoZWFkIG9mIHRp bWUsIG5hbWVseSB3aGVuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOy0gKDEpIGFuIGV4aXN0aW5nIG1lbWJlciBwcm9wb3NlcyB0byBhZGQgYSBu ZXcgbWVtYmVyLCBvciB3aGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDstICgyKSBhbiBleHRlcm5hbCBwYXJ0eSBwcm9wb3NlcyB0byBh ZGQgYSBuZXcgbWVtYmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiB0aGUgY3VycmVudCBwcm9wb3NhbCB3aXRoIGEgZml4ZWQgc2lnbmF0 dXJlIHBlciBncm91cCB0aGUgZGVjaXNpb24gdGFraW5nIGlzIHJhdGhlciBzaW1wbGU6IElmIHRo ZSBuZXcgbWVtYmVyIGFkdmVydGlzZXMgc3VwcG9ydCBmb3IgdGhlIGdyb3VwJ3MgY2lwaGVyc3Vp dGUgaW4gdGhlaXIgQ0lLcywgdGhleSBjYW4gYmUgYWRkZWQgdG8gdGhlIGdyb3VwLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxp a2UgdG8gc2VlIHRoZSBkZWNpc2lvbiB0YWtpbmcgZmxlc2hlZCBvdXQgZm9yIHRoZSBhbHRlcm5h dGl2ZSBhcHByb2FjaCB0aGF0IHN1cHBvcnRzIG11bHRpcGxlIHNpZ25hdHVyZXMuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBuZWVk IHRvIG1ha2Ugc3VyZSB0aGF0IG1lbWJlcnMgY2FuIHZlcmlmeSBzaWduYXR1cmVzLCB3aGljaCBt ZWFucyB3ZSBuZWVkIGEgbGlzdCBvZiBhY2NlcHRhYmxlIHNpZ25hdHVyZSBhbGdvcml0aG1zIHRo YXQgZXZlcnkgbWVtYmVyIGFncmVlcyB1cG9uIGJlZm9yZSBhIG5ldyBtZW1iZXIgaXMgYWRkZWQu IFNpZ25hdHVyZSBhbGdvcml0aG1zIGNhbiBiZSBhZHZlcnRpc2VkIGluIGFub3RoZXIgZXh0ZW5z aW9uDQogaW4gQ0lLcywgYnV0IGl0IGlzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSBob3cgY2xp ZW50cyBhZ3JlZSBvbiB3aGF0IHRoZSBsaXN0IG9mIGFjY2VwdGFibGUgc2lnbmF0dXJlcyBpcy4g V291bGQgaXQgYmUgdGhlIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IsIG1lYW5pbmcgdGhlIGlu dGVyc2VjdGlvbiBvZiB0aGUgYWxnb3JpdGhtcyBhZHZlcnRpc2VkIGluIHRoZSBDSUtzPyBJZiBz bywgaXQgbWVhbnMgdGhlIGxpc3QgZ2V0cyBsYXJnZWx5DQogZGV0ZXJtaW5lZCBieSB0aGUgZWFy bHkgam9pbmVycy4gQWxzbywgY2FuIHRoZSBsaXN0IGNoYW5nZSBvdmVyIHRpbWU/IFRoYXQgd291 bGQgYmUgY29udHJhcnkgdG8gdGhlIGlkZWEgdGhhdCBhbGwgbmVnb3RpYXRpb25zIHNob3VsZCBo YXBwZW4gYWhlYWQgb2YgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZXJlIG1pZ2h0IGFuIGVhc3kgc29sdXRpb24gaGVyZSwgSSBqdXN0 IGRvbuKAmXQgc2VlIGl0IHJpZ2h0IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFwaGFlbCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjcgRmViIDIwMjAsIGF0IDEyOjUwLCBIYWxl LCBCcml0dGEgKENJVikgJmx0OzxhIGhyZWY9Im1haWx0bzpicml0dGEuaGFsZUBucHMuZWR1Ij5i cml0dGEuaGFsZUBucHMuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW5qYW1pbiw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwb2ludCBvZiBjb21wYXJpc29uIHdpdGggVExTIGlz IHRoYXQgaW50ZXJvcCBpcyBzaWduaWZpY2FudGx5IGxlc3Mgb2YgYW4gaXNzdWUgd2hlbiBldmVy eW9uZSBpbiB0aGUgZ3JvdXAgaXMgdXNpbmcgdGhlIHNhbWUgY2xpZW50IHByb2dyYW0uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRlcm1z IG9mIGludGVyb3AsIHlvdXIgY29uY2VybnMgYmVjb21lIGEgZGlzY3Vzc2lvbiBwb2ludCBtYWlu bHkgaW4gdGhlIGZlZGVyYXRpb24gY2FzZSDigJMgYW5kIHRoYXQgaXMgYW4gaW1wb3J0YW50IGNh c2UgdGhhdCB3ZSBzaG91bGQgcGxhbiBmb3IuIEJ1dCwgYXMgSSBzYWlkIGFuZCB5b3UgcmUtaXRl cmF0ZWQsIGlmIHRoZSB1c2UgY2FzZSByZWFsbHkgZXhwZWN0cyBpbnRlcm9wIGlzc3VlcyBmcm9t IGFsbG93aW5nDQogY2hvaWNlLCB0aGVuIG5vdGhpbmcgcHJldmVudHMgdGhlIHNlbGVjdGlvbiBv ZiBhIHNpbmdsZSBzY2hlbWUgZm9yIHRoZSBzZXQgb2YgYWxsb3dhYmxlIHNjaGVtZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHRvIHRo ZSByZWFzb25zIGJlaGluZCBhbGxvd2luZyBtdWx0aXBsZSBhbGdvcml0aG1zLCB0aGUgZG9jdW1l bnQgb24gdGhlIG1haWxpbmdsaXN0IGhhcyBhbHJlYWR5IG91dGxpbmVkIHNldmVyYWwg4oCTIHRo ZXNlIGFyZSBzZWN1cml0eSByZWFzb25zIGZvciBzdXBwb3J0aW5nIGluZGl2aWR1YWwgYWxnb3Jp dGhtcy4gVGhlIGludGVyb3Agb2JqZWN0aW9ucyBmYWxsIG9uIHRoZSB1c2FiaWxpdHkgc2lkZSwg c28NCiB0aGUgY3VycmVudCBkaXNjdXNzaW9uIGlzIHJlYWxseSBhYm91dCB1c2FiaWxpdHkgdnMu IHNlY3VyaXR5IGNvbmNlcm5zLiBIb3dldmVyLCBhdCB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZXNl IHR3byBvcHRpb25zIGlzIHRoZSBpZGVhIG9mIGFsbG93aW5nIGEgc2V0IG9mIHBvc3NpYmxlIGFs Z29yaXRobXMgYXMgS2FydGhpayBzdWdnZXN0cy4gVGhpcyBpcyBhIGdvb2QgY29tcHJvbWlzZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3 b3VsZCBkZWZpbml0ZWx5IG5vdCBzdWdnZXN0IHRoYXQgeW91IGNvbnNpZGVyIG11bHRpcGxlIE1U SXMgYXQgdGhpcyBzdGFnZS4gSWYgdGhhdCBpcyBzb21ldGhpbmcgeW91IHdhbnQsIGl0IGlzIGJl c3QgdG8gcmFpc2UgaXQgYXMgYSBzZXBhcmF0ZSBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccml0dGE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5CZW5qYW1pbiBCZXVyZG91 Y2hlICZsdDs8YSBocmVmPSJtYWlsdG86YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mciI+YmVu amFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mcjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlRodXJzZGF5LCBGZWJy dWFyeSAyNywgMjAyMCBhdCAxMTo0OCBBTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7SGFsZSwgQnJpdHRhIChDSVYp JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdSI+YnJpdHRhLmhh bGVAbnBzLmVkdTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5DYXMgQ3JlbWVycyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNhcy5jcmVtZXJzQGdtYWlsLmNvbSI+Y2FzLmNyZW1lcnNAZ21haWwuY29tPC9hPiZndDssIEth cnRoaWtleWFuIEJoYXJnYXZhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcnRoaWtleWFuLmJoYXJn YXZhbkBpbnJpYS5mciI+a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPC9hPiZndDssIE1M IE1lc3NhZ2luZyBMYXllcg0KIFNlY3VyaXR5ICZsdDs8YSBocmVmPSJtYWlsdG86bWxzQGlldGYu b3JnIj5tbHNAaWV0Zi5vcmc8L2E+Jmd0OywgS29ucmFkIEtvaGJyb2sgJmx0OzxhIGhyZWY9Im1h aWx0bzprb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlIj5rb25yYWQua29oYnJva0BkYXRhc2hy aW5lLmRlPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6IFtNTFNdIGNvbmZpcm1pbmcgY2lwaGVyIHN1 aXRlcyBkZWNpc2lvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiAyNyBGZWIgMjAyMCwgYXQgMTE6NDcsIEJlbmphbWluIEJldXJk b3VjaGUgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5iZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPC9z cGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQnJpdHRhLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMjcgRmViIDIwMjAsIGF0IDEwOjU3LCBIYWxlLCBCcml0dGEg KENJVikgJmx0OzxhIGhyZWY9Im1haWx0bzpicml0dGEuaGFsZUBucHMuZWR1Ij48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5icml0dGEuaGFsZUBucHMuZWR1PC9zcGFuPjwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVuamFtaW4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBpc3N1ZXMgeW91IGRlc2NyaWJlIGFyZSBwcmltYXJpbHkgVExTLXR5cGUgcHJvYmxlbXMs IHdoZXJlIHVuY29udHJvbGxlZCwgbGFyZ2Utc2NhbGUgYWdpbGl0eSBhbmQgaW50ZXJvcCBpc3N1 ZXMgZXhpc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlllcyBleGFjdGx5LCBhbmQgSSB0aGluayB0d28tcGFydHkgc2hvcnQgbGl2ZWQg Y29ubmVjdGlvbnMgZm9yIFRMUyBhcmUgZWFzaWVyIHRvIGhhbmRsZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbiB3 aWxsIGJlIHRoZSBsb25nLWxpdmVkIG11bHRpLXBhcnR5IGNvbm5lY3Rpb25zIG9mIE1MUy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBoYXMgYmVlbiBzdGF0ZWQg aW4gdGhlIHdvcmtpbmcgZ3JvdXAgYXMgYSBzdXBwb3J0aW5nIGFyZ3VtZW50IHRvIG1hbnkgY2hh bmdlcyBvdmVyIHRoZSBkaWZmZXJlbnQgZHJhZnRzLCB3aXRoaW4gdGhlIG1lc3NhZ2luZy9NTFMg c3BhY2Ugd2UgYXJlIGxvb2tpbmcgYXQgc2lnbmlmaWNhbnRseSBtb3JlIGNsaWVudC1zcGVjaWZp YyBjb250cm9sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlllcywgYW5kIHdlIGtlZXAgYmVpbmcgY2FyZWZ1bCB0aGF0IGl0IGlzIHRoZSBjYXNlIHdo ZW4gd3JpdGluZyB0aGUgZHJhZnRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YnV0IHRoaXMgZG9lc27igJl0IG1lYW4g dGhhdCB3ZSBzaG91bGQgYmUgd2lsbGluZyB0byByaXNrIGludGVyb3BlcmFiaWxpdHkuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIG5vdCB1bnJlYXNvbmFibGUgZm9yIGEg bmV3Y29tZXIgdG8gc3VwcG9ydCBhIHNlbGVjdGlvbiBvZiBzaWduYXR1cmUgc2NoZW1lcy4gSWYg dGhlIGdyb3VwIGNyZWF0b3IgcmVhbGx5IHdhbnRzIGZ1bGwgaW50ZXJvcCwgdGhleSBjYW4gYWx3 YXlzIGRlZmluZSB0aGUgc2V0IG9mIGF2YWlsYWJsZSBzY2hlbWVzIHRvIGNvbnNpc3Qgb25seSBv ZiB0aGUgTVRJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0 aGluayBhdCByZXZlcnNlLCBpZiB5b3UgYXJlIHdpbGxpbmcgdG8gYnJlYWsgaW50ZXJvcCwgeW91 IHNob3VsZCBiZSBzZWxlY3Rpbmcgc29tZXRoaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TL3Nob3VsZCBiZSBzZWxlY3RpbmcvY2Fu IHNlbGVjdC88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmVsc2UgdGhh biB0aGUgTVRJIHdoZW4gY3JlYXRpbmcgdGhlIGdyb3VwLiBBbmQgYWdhaW4sIGluIHdoYXQgSSBz YXksIG5vdGhpbmcgcHJldmVudHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnlvdSB0byBwaWNrIHRoZSBOSVNUIGNpcGhl cnN1aXRlIGZvciBjb21wbGlhbmNlIGFuZCB1c2Ugb25seSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkg ZG9u4oCZdCBzZWUgdGhlIGludGVyZXN0IG9mIG1peGluZyBhbGdzIGFuZCBwdXQgYXQgcmlzayBp bXBsZW1lbnRhdGlvbnMgYW5kIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk91dCBvZiBjdXJpb3NpdHksIHdoZXJlIHlvdSBzb21laG93IGFyZ3VpbmcgZm9yIG11 bHRpcGxlIE1USXMgaGVyZSA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpNTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOk1MU0BpZXRmLm9yZyI+TUxTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3083F8087A92443CBF7C762C2D2381B0npsedu_-- From nobody Thu Feb 27 23:31:12 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918EB3A121E for ; Thu, 27 Feb 2020 23:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It-FpSWGa_1N for ; Thu, 27 Feb 2020 23:31:07 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6E93A121D for ; Thu, 27 Feb 2020 23:31:07 -0800 (PST) X-ASG-Debug-ID: 1582875066-0e39454964ced50001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id BjCrZYP6ezBWlGDp; Thu, 27 Feb 2020 23:31:06 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Thu, 27 Feb 2020 23:31:06 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.49) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Thu, 27 Feb 2020 23:31:06 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eN4QhZY8JRYq0yYMHNFKK7g0um6Quns3jXLbODpBmmVkX4ONqVq35jAA/7DnWvHH28Pax53iT0c/kpGvbMQh3R1gBlCppO3TTcKckEjCnd6yKxBCtJQEDJF7lu1tKwz+vZOjmhEKa4xYD0x08uRkuMgHjQxCV05MeaAJu2OKLzKzxcrsF8l+FSxJ+g4mci9vQ+sRUj9Aj0ePisaylfroW/yJDIT/HAKLFa4urgy1Ekbjd0d9GLEF2rHVD1gwZdX2Qh7T52y7+JcJZNkqxWFBNpYKH6qDgXbJP2CDyYU8cdyBvve3EljjYPy3HRsb65D6BahrKF373S3BcyCLMUsTww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p9XoyVyu129lxo6SgTAs5pj9fCB+ceJAt8aBFC8BSuk=; b=JGjvUCkE4sjugnjWnTIm05FF/SlwdJNFHSsuUchTPrJFiAL6nmIeS7XH8wqn+3KDX6KgImKx/yuUvEEQSufuoRBEVubFYo4JoFyo9Qy9cQzYJ40fzkeOF8IjB/la4xw4XDXqloTV68iTMbzkQTnLojlNlJHGG5LBQz6fPZoULztXBb5kEsjxjIe2P1cOiV6kz0PUhrSVlOBlKhd2FRSJNkZBtuD7QAF9PsjyaBVpUxlPD6I2Ca2BOVOvoBZT1RnAmnOG7e3UrT+qz8ai8Q2RQx3YovZ5KhDiqKojhBAVXO2a+QxR52pYL8GKsdaW6BvnIWyVjH0aUYUYFYhWLwkyMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3586.namprd13.prod.outlook.com (2603:10b6:a03:1ae::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.5; Fri, 28 Feb 2020 07:31:04 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 07:31:04 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:1ae::22] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:1ae::22 From: "Hale, Britta (CIV)" To: Karthik Bhargavan , Raphael Robert CC: Benjamin Beurdouche , Cas Cremers , ML Messaging Layer Security , "Konrad Kohbrok" Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAA4SKA//+JDYCAAJPkAIAAAGYA//+LDgCAAO4egIAAxxUA//+SO4AAAFFngA== Date: Fri, 28 Feb 2020 07:31:04 +0000 Message-ID: <9DD8A71E-B8A8-4141-810B-BCE5F8DDDED3@nps.edu> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu> In-Reply-To: <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [88.203.39.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f015fab-d17b-47f2-bde2-08d7bc202b5f x-ms-traffictypediagnostic: BY5PR13MB3586: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39850400004)(376002)(396003)(346002)(366004)(199004)(189003)(6512007)(26005)(81156014)(6506007)(53546011)(81166006)(64756008)(75432002)(66446008)(66476007)(8936002)(66556008)(71200400001)(91956017)(76116006)(8676002)(86362001)(186003)(66946007)(2906002)(33656002)(4326008)(478600001)(5660300002)(36756003)(6486002)(54906003)(110136005)(316002)(786003)(2616005)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3586; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oAQLzHx8Qewi/TEB7ko5DaMeu3oyreMHf7a1lxpmTyGnPK/mUDkZc0ZIvLclwFzDR/bM/GOzU8TPftjlBKbvZ6jof2w4sq+WDtu5q64LbHBNBnzVULLdigyNLQETzN9VU2xIiqtMxWPh+KZix5rtBC+v3eVfU0mto/wqRW+gm6IsvnV2FAgmTHgu1c3zR2GMavkjGCleopISYowwGAFKAlOE8aRA+gBGhYKVMFbJCE2Jv9cPeyXv6NzGGEqCxmPrKx0iJ228cmfhQkc9VJ51qENk4kcdlOAPKs+T9INuVmN8zw5pflK61Z0breea2j0leZ8yC4HFAwGVb43uxG5XSE75EqjRGrGQ8FTIPVOjPBndXFJikWu0ngZTXSHfNFmXRA3M008RgoOGpnB/8QOJRLg8MJvb7ySDOkDScdI1EhuzV8l/4LuxBrUAH4u+id3pOXaVGXQ0tW121+xZr+ZPBUy0jbkM5T0xIzNBUhhhu3vxseaoRzyWOyut2PIuchH72qvkGjK4QYfNSZomBUq80A== x-ms-exchange-antispam-messagedata: 7IHqW7PXF8hx0owDR/wO7J1md/n/amj2HLAqfcdhV0eCOIR01gGwbXFwNaclstJavCrWVYYtIm4uzjxW+eYNTbwz3qZmyhbISHFvxPVyI+LRNLCDQTaflFEVedJLq9WAbiLdWEWh1SPHxdAb2stDVw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9DD8A71EB8A84141810BBCE5F8DDDED3npsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9f015fab-d17b-47f2-bde2-08d7bc202b5f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 07:31:04.7825 (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: lTAXuSCYhW6Jpj787s9sind/femYhUyBS5/eVO9nAeoWelQY9SJRRYeKL1PWXDME6xC4LSBobH9Ws2zEYUtfDA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3586 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1582875066 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 39322 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80314 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 07:31:10 -0000 --_000_9DD8A71EB8A84141810BBCE5F8DDDED3npsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgYXJndWFibHkgYSB0aGlyZCDigJxjYXNl4oCdLCB3aGljaCBtYXkgYmUgd2hlcmUg bW9zdCBvZiB0aGUgcHJhY3RpY2FsaXR5IHF1ZXN0aW9ucyBhcmUgYXJpc2luZyBmcm9tOg0KDQoN CiAgMS4gIFRoZSBncm91cCBjcmVhdG9yIHdhbnRzIG1vcmUgY29udHJvbCBvZiB0aGUgc2VjdXJp dHkgb2YgdGhlIHNpZ25hdHVyZSBzY2hlbWUgb25seS4NCg0KICAgICAqICAgVGhlIGdyb3VwIGNy ZWF0b3IgY2hvb3NlcyB0aGUgTVRJIGNpcGhlcnN1aXRlLg0KICAgICAqICAgVGhlIGdyb3VwIGNy ZWF0b3IgY2hvb3NlcyBhIHN1YnNldCBvZiBpbml0aWFsIGdyb3VwIG1lbWJlcnPigJkgc3VwcG9y dGVkIGFsZ29yaXRobXMgKHdoaWNoIG1heSBvciBtYXkgbm90IGluY2x1ZGUgdGhlIE1USSkuDQpB Z2FpbiwgZm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50LCBjb25zaWRlciB0aGUgZm9sbG93aW5nIGFs dGVybmF0aXZlIHRvIGI6DQoNCiAgICAgKiAgIFRoZSBncm91cCBjcmVhdG9yIGNob29zZXMgYSBz aW5nbGUgbm9uLU1USSBzaWduYXR1cmUgc2NoZW1lLg0KDQpIZXJlLCB0aGUgY2lwaGVyc3VpdGUg Y2hvaWNlIGFuZCBzaWduYXR1cmUgc2NoZW1lIGNob2ljZSBhcmUgbm90IGNvbXBhcmFibGU6IDNh IGluZGljYXRlcyB0aGF0IHdlIHdhbnQgZnVsbCBmbGV4aWJpbGl0eSwgd2hpbGUgM2IvM2MgaW5k aWNhdGUgbW9yZSBmb2N1cyBvbiBzZWN1cml0eSAtIG5vdCB0aGF0IHRoZSBNVEkgaXMgbGVzcyBz ZWN1cmUsIGJ1dCB0aGF0IHRoZSBncm91cCBjcmVhdG9yIHdhbnRzIGEgbm9uLU1USSBzY2hlbWUg Zm9yIHNvbWUgcGFydGljdWxhciByZWFzb24uIE90aGVyd2lzZSB0aGlzIHdvdWxkIHJlZHVjZSB0 byBjYXNlIDEpLg0KDQpUaGF0IHBvaW50IGFzaWRlLCBpbiBjYXNlIDMpIGEgbmV3Y29tZXIgd291 bGQgYmUgYWJsZSB0byBqb2luIGJhc2VkIG9uIGNpcGhlcnN1aXRlIGFsb25lLiBUaGVuIHRoZSBy ZWFsIGRlYmF0ZSBpcyB0aGVuIG9uIHRoZSBwcm9iYWJpbGl0eSBvZiB0aGUgbmV3Y29tZXIgc3Vw cG9ydGluZyBhIHNpbmdsZSBub24tTVRJIHNjaGVtZSB2ZXJzdXMgYSBzZXQgb2Ygc2NoZW1lcy4g SSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgYSBwb2ludCB3b3J0aCBmb2N1c2luZyBvbiwgYXMg aXQgaXMgY2xlYXJseSBhIHNwZWNpYWwgY2FzZSBvZiAyKSBpbiB0ZXJtcyBvZiB0aGUgaW50ZW50 IGFuZCBtb3RpdmF0aW9uIG9mIHRoZSBncm91cCBjcmVhdG9yIChpLmUuIGlmIHRoZSBncm91cCBj cmVhdG9yIGlzIG1vcmUgZm9jdXNlZCBvbiB0aGUgc2VjdXJpdHkgYW5kIG90aGVyIGFzcGVjdHMg dGhhbiBhbGxvd2luZyBhbnlvbmUgdG8gam9pbiwgdGhlbiBpc3N1ZXMgaW4gMykgc2VlbSBsYXJn ZWx5IHRvIGJlIGEgbW9vdCBwb2ludCkuDQoNCkJyaXR0YQ0KDQoNCg0KRnJvbTogIkhhbGUsIEJy aXR0YSAoQ0lWKSIgPGJyaXR0YS5oYWxlQG5wcy5lZHU+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5 IDI4LCAyMDIwIGF0IDg6MjEgQU0NClRvOiBLYXJ0aGlrIEJoYXJnYXZhbiA8a2FydGhpa2V5YW4u YmhhcmdhdmFuQGlucmlhLmZyPiwgUmFwaGFlbCBSb2JlcnQgPHJhcGhhZWxAd2lyZS5jb20+DQpD YzogQmVuamFtaW4gQmV1cmRvdWNoZSA8YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mcj4sIENh cyBDcmVtZXJzIDxjYXMuY3JlbWVyc0BnbWFpbC5jb20+LCBNTCBNZXNzYWdpbmcgTGF5ZXIgU2Vj dXJpdHkgPG1sc0BpZXRmLm9yZz4sIEtvbnJhZCBLb2hicm9rIDxLb25yYWQua29oYnJva0BkYXRh c2hyaW5lLmRlPg0KU3ViamVjdDogUmU6IFtNTFNdIGNvbmZpcm1pbmcgY2lwaGVyIHN1aXRlcyBk ZWNpc2lvbnMNCg0KSW4gdGVybXMgb2YgbmVnb3RpYXRpb24sIEkgdGhpbmsgd2UgY2FuIGNsb3Nl bHkgY29ycmVsYXRlIHRoZSBpc3N1ZXMgYW5kIHByYWN0aWNhbCByYW1pZmljYXRpb25zIGluIGNo b29zaW5nIGEgc2lnbmF0dXJlIHNjaGVtZSBsaXN0IHdpdGggdGhlIGNpcGhlcnN1aXRlIG5lZ290 aWF0aW9uIHRoYXQgYWxyZWFkeSB0YWtlcyBwbGFjZS4NCkxldCB1cyBhc3N1bWUgdGhhdCBldmVy eSBtZW1iZXIgd291bGQgbm90IG9ubHkgaGF2ZSBhIGxpc3Qgb2Ygc3VwcG9ydGVkIGNpcGhlcnN1 aXRlcyBpbiB0aGVpciBDSUssIGJ1dCBhbHNvIG9mIHNpZ25hdHVyZSBzY2hlbWVzLiBUaGUgYWN0 aW9uIG9mIHRoZSBncm91cCBjcmVhdG9yIGlzIHRoZW4gY29tcGFyYWJsZSBpbiB0aGUgZm9sbG93 aW5nIGEvYiBjYXNlcyBmb3IgY2lwaGVyc3VpdGVzL3NpZ25hdHVyZSBzY2hlbWVzOg0KDQoNCiAg MS4gIFRoZSBncm91cCBjcmVhdG9yIHdhbnRzIHRvIGVuc3VyZSBhbnkgbmV3Y29tZXIgY2FuIGpv aW4gdGhlIGdyb3VwOg0KICAgICAqICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyB0aGUgTVRJ IGNpcGhlcnN1aXRlLg0KICAgICAqICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyB0aGUgTVRJ IGFzIHRoZSBzaW5nbGUgZWxlbWVudCBpbiB0aGUgc2V0IG9mIHBvc3NpYmxlIHNpZ25hdHVyZXMu DQoNCg0KDQogIDEuICBUaGUgZ3JvdXAgY3JlYXRvciB3YW50cyBtb3JlIGNvbnRyb2wgYW5kIGlz IG5vdCBwYXJ0aWN1bGFybHkgY29uY2VybmVkIGFib3V0IG5ld2NvbWVycyBpbiB0aGUgbG9uZy10 ZXJtOg0KICAgICAqICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyBhIG5vbi1NVEkgY2lwaGVy c3VpdGUgZnJvbSB0aGUgaW5pdGlhbCBncm91cCBtZW1iZXJz4oCZIGxpc3RzLg0KICAgICAqICAg VGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyBhIHN1YnNldCBvZiBpbml0aWFsIGdyb3VwIG1lbWJl cnPigJkgc3VwcG9ydGVkIGFsZ29yaXRobXMgKHdoaWNoIG1heSBvciBtYXkgbm90IGluY2x1ZGUg dGhlIE1USSkuDQpGb3IgdGhlIHNha2Ugb2YgYXJndW1lbnQsIGNvbnNpZGVyIHRoZSBmb2xsb3dp bmcgYWx0ZXJuYXRpdmUgdG8gYjoNCg0KICAgICAqICAgVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3Nl cyBhIHNpbmdsZSBub24tTVRJIHNpZ25hdHVyZSBzY2hlbWUuDQoNClRoZSBpc3N1ZXMgZm9yIG5l d2NvbWVycyBpbiBjYXNlIDJiIGlzIG5vdCB2ZXJ5IGRpZmZlcmVudCBmcm9tIDJjICh3aGljaCBp cyB1bHRpbWF0ZWx5IHRoZSBjYXNlIGlmIHdlIG9ubHkgc3VwcG9ydCBvbmUgc2NoZW1lKS4gQmFz aWNhbGx5LCB0aGUgbmV3Y29tZXIgc3VwcG9ydHMgdGhlIHNjaGVtZS9zZXQgb2Ygc2NoZW1lcyBv ciBoZSBkb2VzIG5vdC4gSW4gMmEsIDJiLCBhbmQgMmMsIGFsZ29yaXRobXMgYXJlIGRpY3RhdGVk IGJ5IHRoZSBzZXQgb2YgaW5pdGlhbCBtZW1iZXJzLCBzbyB3ZSBhcmUgbm90IGxvb2tpbmcgYXQg YSBzaWduaWZpY2FudCB1c2FiaWxpdHkgZGlmZmVyZW5jZSB0aGVyZS4NCg0KRm9yIGNob29zaW5n IHRoZSBzaWduYXR1cmUgc2NoZW1lIGxpc3QsIGFueSBwcm9wZXIgc3Vic2V0IG9mIHRoZSBpbnRl cnNlY3Rpb24gb2YgdGhlIGluaXRpYWwgZ3JvdXAgbWVtYmVyc+KAmSBsaXN0IHdvdWxkIGJlIHBv c3NpYmxlIChoZW5jZSB3aHkgd2UgaGF2ZSBmcmVlZG9tIHRvIGNob29zZSB7TVRJfSBpbiBjYXNl IDFiKS4gSG93ZXZlciwgd2UgY291bGQgbWFrZSBpdCBzaW1wbGUgYW5kIHVzZSB0aGUgYWN0dWFs IGludGVyc2VjdGlvbi4NCg0KQXMgZmFyIGFzIGxpc3RzIGNoYW5naW5nIG92ZXIgdGltZTogaW4g dGVybXMgb2Ygd2hhdCBhIG1lbWJlciBjYW4gc3VwcG9ydCB0aGUgYW5zd2VyIGlzIGFuIGFmZmly bWF0aXZlLiBJbiB0aGUgc2FtZSB3YXkgdGhlIHN1cHBvcnRlZCBjaXBoZXJzdWl0ZXMgY2FuIGNo YW5nZSBvdmVyIHRpbWUsIHRoZSBzdXBwb3J0ZWQgc2lnbmF0dXJlIHNjaGVtZXMgY2FuIGFzIHdl bGwuIEhvd2V2ZXIsIGluIHRlcm1zIG9mIHdoYXQgaXMgdXNlZCBpbiB0aGUgZ3JvdXAsIHRoaXMg c2hvdWxkIG5vdCBjaGFuZ2U6IG9uY2UgZml4ZWQgYXQgZ3JvdXAgaW5pdGlhdGlvbiB0aGUgbGlz dCBpcyBzdGF0aWMgZm9yIHRoZSBsaWZldGltZSBvZiB0aGUgZ3JvdXAuIE9uY2UgYSBtZW1iZXIg aGFzIGNob3NlbiBhIHNpZ25hdHVyZSBzY2hlbWUgZnJvbSB0aGUgbGlzdCwgdGhlIGNob2ljZSBp cyBzdGF0aWMgZm9yIHRoZSBsaWZldGltZSBvZiB0aGUgZ3JvdXAuIFRoZSBncm91cCBzaG91bGQg dGh1cyBub3QgYmUgYWRhcHRhYmxlIHRvIGNoYW5nZXMgaW4gdGhlIG9mZmVyZWQgYWxnb3JpdGht cyBvZiB0aGUgQ0lLcy4NCg0KQnJpdHRhDQoNCg0KDQpGcm9tOiBLYXJ0aGlrIEJoYXJnYXZhbiA8 a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPg0KRGF0ZTogRnJpZGF5LCBGZWJydWFyeSAy OCwgMjAyMCBhdCA2OjU1IEFNDQpUbzogUmFwaGFlbCBSb2JlcnQgPHJhcGhhZWxAd2lyZS5jb20+ DQpDYzogIkhhbGUsIEJyaXR0YSAoQ0lWKSIgPGJyaXR0YS5oYWxlQG5wcy5lZHU+LCBCZW5qYW1p biBCZXVyZG91Y2hlIDxiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPiwgQ2FzIENyZW1lcnMg PGNhcy5jcmVtZXJzQGdtYWlsLmNvbT4sIE1MIE1lc3NhZ2luZyBMYXllciBTZWN1cml0eSA8bWxz QGlldGYub3JnPiwgS29ucmFkIEtvaGJyb2sgPEtvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU+ DQpTdWJqZWN0OiBSZTogW01MU10gY29uZmlybWluZyBjaXBoZXIgc3VpdGVzIGRlY2lzaW9ucw0K DQpJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBwcmFjdGljYWwgcmFtaWZpY2F0aW9ucyBvZiBncm91 cHMgd2hlcmUgbWVtYmVycyB1c2UgZGlmZmVyZW50IGFsZ29yaXRobXMuDQoNClN0aWxsLCBJIHRo aW5rIGl0IGlzIGZlYXNpYmxlIHRvIGV2ZW50dWFsbHkgaGF2ZSBhIGRlc2lnbiB3aGVyZSB0aGUg Z3JvdXAgY3JlYXRvciBwcm9wb3NlcyBhIHNldCBvZiBhbGdvcml0aG1zIGFzIOKAnG11c3QgaW1w bGVtZW504oCdIGZvciB0aGUgZ3JvdXAuDQpFYWNoIG5ldyBtZW1iZXIgbXVzdCBzdXBwb3J0IChp LmUuIGltcGxlbWVudCkg4oCcYWxs4oCdIHRoZSBhbGdvcml0aG1zIGluIHRoaXMgbGlzdCBpbiBv cmRlciB0byBqb2luIHRoZSBncm91cC4NCkhvd2V2ZXIsIHRoZSBtZW1iZXIgaGFzIHRoZSBvcHRp b24gdG8gdXNlIHdoaWNoZXZlciBzdXBwb3J0ZWQgYWxnb3JpdGhtIHNoZSBwcmVmZXJzIGZvciBt ZXNzYWdlcyBzaGUgc2VuZHMuDQoNCldoaWxlIGFsbCBvZiB0aGlzIGlzIGEgcmVhc29uYWJsZSBs b25nLXRlcm0gZ29hbCwgcGVyaGFwcyB3ZSBzaG91bGQgc3RhcnQgd2l0aCBhIHZlcnNpb24gd2hl cmUgdGhlIGNyZWF0b3Igb25seSBjaG9vc2VzIG9uZSBhbGdvcml0aG0gaW4gZWFjaCBjYXRlZ29y eSwgbGVhdmluZyBubyBjaG9pY2UgdG8gdGhlIG1lbWJlcnMuDQpXZSBjYW4gZG9jdW1lbnQgdGhp cyBjaG9pY2UgYXMgYSBmdXR1cmUgZXh0ZW5zaW9uIHBvaW50LCBhbmQgY2hhbmdlIGl0IGFzIHdl IHVuZGVyc3RhbmQgdGhlIGZlZGVyYXRpb24gc2NlbmFyaW8gYW5kIGRlcGxveW1lbnQgY29uc3Ry YWludHMgYSBiaXQgYmV0dGVyPw0KDQpCZXN0LA0KS2FydGhpaw0KDQoNCg0KDQpPbiAyNyBGZWIg MjAyMCwgYXQgMTk6MDIsIFJhcGhhZWwgUm9iZXJ0IDxyYXBoYWVsQHdpcmUuY29tPG1haWx0bzpy YXBoYWVsQHdpcmUuY29tPj4gd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCB3aGF0IEthcnRoaWsgc2Fp ZCwgYW5kIEkgdGhpbmsgdGhhdCB0aGF0IHdhcyB0aGUgdW5kZXJseWluZyBhc3N1bXB0aW9uIGFs bCBhbG9uZyAoYXQgZWFzdCBmb3IgbWUpLiBUaGUgbmVnb3RpYXRpb24gaGFzIHRvIGhhcHBlbiBh aGVhZCBvZiB0aW1lLCBuYW1lbHkgd2hlbg0KDQogLSAoMSkgYW4gZXhpc3RpbmcgbWVtYmVyIHBy b3Bvc2VzIHRvIGFkZCBhIG5ldyBtZW1iZXIsIG9yIHdoZW4NCiAtICgyKSBhbiBleHRlcm5hbCBw YXJ0eSBwcm9wb3NlcyB0byBhZGQgYSBuZXcgbWVtYmVyLg0KDQpJbiB0aGUgY3VycmVudCBwcm9w b3NhbCB3aXRoIGEgZml4ZWQgc2lnbmF0dXJlIHBlciBncm91cCB0aGUgZGVjaXNpb24gdGFraW5n IGlzIHJhdGhlciBzaW1wbGU6IElmIHRoZSBuZXcgbWVtYmVyIGFkdmVydGlzZXMgc3VwcG9ydCBm b3IgdGhlIGdyb3VwJ3MgY2lwaGVyc3VpdGUgaW4gdGhlaXIgQ0lLcywgdGhleSBjYW4gYmUgYWRk ZWQgdG8gdGhlIGdyb3VwLg0KDQpJIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBkZWNpc2lvbiB0YWtp bmcgZmxlc2hlZCBvdXQgZm9yIHRoZSBhbHRlcm5hdGl2ZSBhcHByb2FjaCB0aGF0IHN1cHBvcnRz IG11bHRpcGxlIHNpZ25hdHVyZXMuDQpXZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IG1lbWJlcnMg Y2FuIHZlcmlmeSBzaWduYXR1cmVzLCB3aGljaCBtZWFucyB3ZSBuZWVkIGEgbGlzdCBvZiBhY2Nl cHRhYmxlIHNpZ25hdHVyZSBhbGdvcml0aG1zIHRoYXQgZXZlcnkgbWVtYmVyIGFncmVlcyB1cG9u IGJlZm9yZSBhIG5ldyBtZW1iZXIgaXMgYWRkZWQuIFNpZ25hdHVyZSBhbGdvcml0aG1zIGNhbiBi ZSBhZHZlcnRpc2VkIGluIGFub3RoZXIgZXh0ZW5zaW9uIGluIENJS3MsIGJ1dCBpdCBpcyBub3Qg ZW50aXJlbHkgY2xlYXIgdG8gbWUgaG93IGNsaWVudHMgYWdyZWUgb24gd2hhdCB0aGUgbGlzdCBv ZiBhY2NlcHRhYmxlIHNpZ25hdHVyZXMgaXMuIFdvdWxkIGl0IGJlIHRoZSBsb3dlc3QgY29tbW9u IGRlbm9taW5hdG9yLCBtZWFuaW5nIHRoZSBpbnRlcnNlY3Rpb24gb2YgdGhlIGFsZ29yaXRobXMg YWR2ZXJ0aXNlZCBpbiB0aGUgQ0lLcz8gSWYgc28sIGl0IG1lYW5zIHRoZSBsaXN0IGdldHMgbGFy Z2VseSBkZXRlcm1pbmVkIGJ5IHRoZSBlYXJseSBqb2luZXJzLiBBbHNvLCBjYW4gdGhlIGxpc3Qg Y2hhbmdlIG92ZXIgdGltZT8gVGhhdCB3b3VsZCBiZSBjb250cmFyeSB0byB0aGUgaWRlYSB0aGF0 IGFsbCBuZWdvdGlhdGlvbnMgc2hvdWxkIGhhcHBlbiBhaGVhZCBvZiB0aW1lLg0KVGhlcmUgbWln aHQgYW4gZWFzeSBzb2x1dGlvbiBoZXJlLCBJIGp1c3QgZG9u4oCZdCBzZWUgaXQgcmlnaHQgbm93 Lg0KDQpSYXBoYWVsDQoNCg0KDQpPbiAyNyBGZWIgMjAyMCwgYXQgMTI6NTAsIEhhbGUsIEJyaXR0 YSAoQ0lWKSA8YnJpdHRhLmhhbGVAbnBzLmVkdTxtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdT4+ IHdyb3RlOg0KDQpCZW5qYW1pbiwNCg0KVGhlIHBvaW50IG9mIGNvbXBhcmlzb24gd2l0aCBUTFMg aXMgdGhhdCBpbnRlcm9wIGlzIHNpZ25pZmljYW50bHkgbGVzcyBvZiBhbiBpc3N1ZSB3aGVuIGV2 ZXJ5b25lIGluIHRoZSBncm91cCBpcyB1c2luZyB0aGUgc2FtZSBjbGllbnQgcHJvZ3JhbS4NCg0K SW4gdGVybXMgb2YgaW50ZXJvcCwgeW91ciBjb25jZXJucyBiZWNvbWUgYSBkaXNjdXNzaW9uIHBv aW50IG1haW5seSBpbiB0aGUgZmVkZXJhdGlvbiBjYXNlIOKAkyBhbmQgdGhhdCBpcyBhbiBpbXBv cnRhbnQgY2FzZSB0aGF0IHdlIHNob3VsZCBwbGFuIGZvci4gQnV0LCBhcyBJIHNhaWQgYW5kIHlv dSByZS1pdGVyYXRlZCwgaWYgdGhlIHVzZSBjYXNlIHJlYWxseSBleHBlY3RzIGludGVyb3AgaXNz dWVzIGZyb20gYWxsb3dpbmcgY2hvaWNlLCB0aGVuIG5vdGhpbmcgcHJldmVudHMgdGhlIHNlbGVj dGlvbiBvZiBhIHNpbmdsZSBzY2hlbWUgZm9yIHRoZSBzZXQgb2YgYWxsb3dhYmxlIHNjaGVtZXMu DQoNCkFzIHRvIHRoZSByZWFzb25zIGJlaGluZCBhbGxvd2luZyBtdWx0aXBsZSBhbGdvcml0aG1z LCB0aGUgZG9jdW1lbnQgb24gdGhlIG1haWxpbmdsaXN0IGhhcyBhbHJlYWR5IG91dGxpbmVkIHNl dmVyYWwg4oCTIHRoZXNlIGFyZSBzZWN1cml0eSByZWFzb25zIGZvciBzdXBwb3J0aW5nIGluZGl2 aWR1YWwgYWxnb3JpdGhtcy4gVGhlIGludGVyb3Agb2JqZWN0aW9ucyBmYWxsIG9uIHRoZSB1c2Fi aWxpdHkgc2lkZSwgc28gdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiBpcyByZWFsbHkgYWJvdXQgdXNh YmlsaXR5IHZzLiBzZWN1cml0eSBjb25jZXJucy4gSG93ZXZlciwgYXQgdGhlIGludGVyc2VjdGlv biBvZiB0aGVzZSB0d28gb3B0aW9ucyBpcyB0aGUgaWRlYSBvZiBhbGxvd2luZyBhIHNldCBvZiBw b3NzaWJsZSBhbGdvcml0aG1zIGFzIEthcnRoaWsgc3VnZ2VzdHMuIFRoaXMgaXMgYSBnb29kIGNv bXByb21pc2UuDQoNCkkgd291bGQgZGVmaW5pdGVseSBub3Qgc3VnZ2VzdCB0aGF0IHlvdSBjb25z aWRlciBtdWx0aXBsZSBNVElzIGF0IHRoaXMgc3RhZ2UuIElmIHRoYXQgaXMgc29tZXRoaW5nIHlv dSB3YW50LCBpdCBpcyBiZXN0IHRvIHJhaXNlIGl0IGFzIGEgc2VwYXJhdGUgaXNzdWUuDQoNCi0t LQ0KDQpCcml0dGENCg0KDQpGcm9tOiBCZW5qYW1pbiBCZXVyZG91Y2hlIDxiZW5qYW1pbi5iZXVy ZG91Y2hlQGlucmlhLmZyPG1haWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPj4NCkRh dGU6IFRodXJzZGF5LCBGZWJydWFyeSAyNywgMjAyMCBhdCAxMTo0OCBBTQ0KVG86ICJIYWxlLCBC cml0dGEgKENJVikiIDxicml0dGEuaGFsZUBucHMuZWR1PG1haWx0bzpicml0dGEuaGFsZUBucHMu ZWR1Pj4NCkNjOiBDYXMgQ3JlbWVycyA8Y2FzLmNyZW1lcnNAZ21haWwuY29tPG1haWx0bzpjYXMu Y3JlbWVyc0BnbWFpbC5jb20+PiwgS2FydGhpa2V5YW4gQmhhcmdhdmFuIDxrYXJ0aGlrZXlhbi5i aGFyZ2F2YW5AaW5yaWEuZnI8bWFpbHRvOmthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcj4+ LCBNTCBNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgPG1sc0BpZXRmLm9yZzxtYWlsdG86bWxzQGll dGYub3JnPj4sIEtvbnJhZCBLb2hicm9rIDxrb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPG1h aWx0bzprb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPj4NClN1YmplY3Q6IFJlOiBbTUxTXSBj b25maXJtaW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zDQoNCg0KDQoNCg0KDQpPbiAyNyBGZWIg MjAyMCwgYXQgMTE6NDcsIEJlbmphbWluIEJldXJkb3VjaGUgPGJlbmphbWluLmJldXJkb3VjaGVA aW5yaWEuZnI8bWFpbHRvOmJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI+PiB3cm90ZToNCg0K SGkgQnJpdHRhLA0KDQoNCg0KDQpPbiAyNyBGZWIgMjAyMCwgYXQgMTA6NTcsIEhhbGUsIEJyaXR0 YSAoQ0lWKSA8YnJpdHRhLmhhbGVAbnBzLmVkdTxtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdT4+ IHdyb3RlOg0KDQpCZW5qYW1pbiwNCg0KVGhlIGlzc3VlcyB5b3UgZGVzY3JpYmUgYXJlIHByaW1h cmlseSBUTFMtdHlwZSBwcm9ibGVtcywgd2hlcmUgdW5jb250cm9sbGVkLCBsYXJnZS1zY2FsZSBh Z2lsaXR5IGFuZCBpbnRlcm9wIGlzc3VlcyBleGlzdC4NCg0KWWVzIGV4YWN0bHksIGFuZCBJIHRo aW5rIHR3by1wYXJ0eSBzaG9ydCBsaXZlZCBjb25uZWN0aW9ucyBmb3IgVExTIGFyZSBlYXNpZXIg dG8gaGFuZGxlDQp0aGFuIHdpbGwgYmUgdGhlIGxvbmctbGl2ZWQgbXVsdGktcGFydHkgY29ubmVj dGlvbnMgb2YgTUxTLg0KDQoNCg0KDQpBcyBoYXMgYmVlbiBzdGF0ZWQgaW4gdGhlIHdvcmtpbmcg Z3JvdXAgYXMgYSBzdXBwb3J0aW5nIGFyZ3VtZW50IHRvIG1hbnkgY2hhbmdlcyBvdmVyIHRoZSBk aWZmZXJlbnQgZHJhZnRzLCB3aXRoaW4gdGhlIG1lc3NhZ2luZy9NTFMgc3BhY2Ugd2UgYXJlIGxv b2tpbmcgYXQgc2lnbmlmaWNhbnRseSBtb3JlIGNsaWVudC1zcGVjaWZpYyBjb250cm9sLg0KDQpZ ZXMsIGFuZCB3ZSBrZWVwIGJlaW5nIGNhcmVmdWwgdGhhdCBpdCBpcyB0aGUgY2FzZSB3aGVuIHdy aXRpbmcgdGhlIGRyYWZ0cywNCmJ1dCB0aGlzIGRvZXNu4oCZdCBtZWFuIHRoYXQgd2Ugc2hvdWxk IGJlIHdpbGxpbmcgdG8gcmlzayBpbnRlcm9wZXJhYmlsaXR5Lg0KDQoNCg0KDQpJdCBpcyBub3Qg dW5yZWFzb25hYmxlIGZvciBhIG5ld2NvbWVyIHRvIHN1cHBvcnQgYSBzZWxlY3Rpb24gb2Ygc2ln bmF0dXJlIHNjaGVtZXMuIElmIHRoZSBncm91cCBjcmVhdG9yIHJlYWxseSB3YW50cyBmdWxsIGlu dGVyb3AsIHRoZXkgY2FuIGFsd2F5cyBkZWZpbmUgdGhlIHNldCBvZiBhdmFpbGFibGUgc2NoZW1l cyB0byBjb25zaXN0IG9ubHkgb2YgdGhlIE1USS4NCg0KSSB0aGluayBhdCByZXZlcnNlLCBpZiB5 b3UgYXJlIHdpbGxpbmcgdG8gYnJlYWsgaW50ZXJvcCwgeW91IHNob3VsZCBiZSBzZWxlY3Rpbmcg c29tZXRoaW5nDQoNClMvc2hvdWxkIGJlIHNlbGVjdGluZy9jYW4gc2VsZWN0Lw0KDQoNCg0KDQpl bHNlIHRoYW4gdGhlIE1USSB3aGVuIGNyZWF0aW5nIHRoZSBncm91cC4gQW5kIGFnYWluLCBpbiB3 aGF0IEkgc2F5LCBub3RoaW5nIHByZXZlbnRzDQp5b3UgdG8gcGljayB0aGUgTklTVCBjaXBoZXJz dWl0ZSBmb3IgY29tcGxpYW5jZSBhbmQgdXNlIG9ubHkgdGhhdC4NCkJ1dCBJIGRvbuKAmXQgc2Vl IHRoZSBpbnRlcmVzdCBvZiBtaXhpbmcgYWxncyBhbmQgcHV0IGF0IHJpc2sgaW1wbGVtZW50YXRp b25zIGFuZCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpPdXQgb2YgY3VyaW9zaXR5LCB3aGVyZSB5b3Ug c29tZWhvdyBhcmd1aW5nIGZvciBtdWx0aXBsZSBNVElzIGhlcmUgPw0KDQpCLg0KDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxp bmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21scw0KDQoNCg== --_000_9DD8A71EB8A84141810BBCE5F8DDDED3npsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <16840FCFD0A3D347A4C7B673A20C572C@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6NDgyNjE3MTE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyNTE5 MzM4Mzg7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjY1ODM4ODAwODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NTc2NjMzMDY2IDIyODc0NTE0OCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDouNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoxLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEu NzVpbjsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoyLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 Mi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDozLjI1aW47 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6My43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuMjVp bjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6NC43NWluOw0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo3MTUwODMxODg7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MzQyNjA3NzQ7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6 bGV2ZWwyDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzDQoJe21z by1saXN0LWlkOjk0NDU3ODc4NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2ODMxNzgyMDA7 fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0DQoJe21z by1saXN0LWlkOjEzNjgwOTQyMDk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjIxMzg3Mzk2IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGw0 OmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGw0Omxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDox OTI4MzQ0OTUzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotNDM5ODMxNjggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs NTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZXJlIGlzIGFyZ3VhYmx5 IGEgdGhpcmQg4oCcY2FzZeKAnSwgd2hpY2ggbWF5IGJlIHdoZXJlIG1vc3Qgb2YgdGhlIHByYWN0 aWNhbGl0eSBxdWVzdGlvbnMgYXJlIGFyaXNpbmcgZnJvbTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIz IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOmJs YWNrO21hcmdpbi1sZWZ0Oi4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm83Ij4NClRoZSBncm91 cCBjcmVhdG9yIHdhbnRzIG1vcmUgY29udHJvbCBvZiB0aGUgc2VjdXJpdHkgb2YgdGhlIHNpZ25h dHVyZSBzY2hlbWUgb25seS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxvbCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4i IHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNSBsZXZlbDIgbGZvNiI+DQpU aGUgZ3JvdXAgY3JlYXRvciBjaG9vc2VzIHRoZSBNVEkgY2lwaGVyc3VpdGUuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOmJsYWNrO21hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsNSBsZXZlbDIgbGZvNiI+DQpUaGUgZ3JvdXAgY3JlYXRvciBj aG9vc2VzIGEgc3Vic2V0IG9mIGluaXRpYWwgZ3JvdXAgbWVtYmVyc+KAmSBzdXBwb3J0ZWQgYWxn b3JpdGhtcyAod2hpY2ggbWF5IG9yIG1heSBub3QgaW5jbHVkZSB0aGUgTVRJKS48bzpwPjwvbzpw PjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkFnYWluLCBmb3IgdGhlIHNha2Ugb2YgYXJndW1lbnQsIGNvbnNpZGVyIHRoZSBm b2xsb3dpbmcgYWx0ZXJuYXRpdmUgdG8gYjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdp bi10b3A6MGluIiBzdGFydD0iMyIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJjb2xvcjpibGFjazttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDUgbGV2ZWwy IGxmbzYiPg0KVGhlIGdyb3VwIGNyZWF0b3IgY2hvb3NlcyBhIHNpbmdsZSBub24tTVRJIHNpZ25h dHVyZSBzY2hlbWUuPG86cD48L286cD48L2xpPjwvb2w+DQo8L29sPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlLCB0aGUgY2lwaGVyc3VpdGUgY2hvaWNlIGFu ZCBzaWduYXR1cmUgc2NoZW1lIGNob2ljZSBhcmUgbm90IGNvbXBhcmFibGU6IDNhIGluZGljYXRl cyB0aGF0IHdlIHdhbnQgZnVsbCBmbGV4aWJpbGl0eSwgd2hpbGUgM2IvM2MgaW5kaWNhdGUgbW9y ZSBmb2N1cyBvbiBzZWN1cml0eSAtIG5vdCB0aGF0IHRoZSBNVEkgaXMgbGVzcyBzZWN1cmUsIGJ1 dCB0aGF0IHRoZSBncm91cCBjcmVhdG9yIHdhbnRzIGEgbm9uLU1USQ0KIHNjaGVtZSBmb3Igc29t ZSBwYXJ0aWN1bGFyIHJlYXNvbi4gT3RoZXJ3aXNlIHRoaXMgd291bGQgcmVkdWNlIHRvIGNhc2Ug MSkuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHBvaW50IGFzaWRlLCBpbiBj YXNlIDMpIGEgbmV3Y29tZXIgd291bGQgYmUgYWJsZSB0byBqb2luIGJhc2VkIG9uIGNpcGhlcnN1 aXRlIGFsb25lLiBUaGVuIHRoZSByZWFsIGRlYmF0ZSBpcyB0aGVuIG9uIHRoZSBwcm9iYWJpbGl0 eSBvZiB0aGUgbmV3Y29tZXIgc3VwcG9ydGluZyBhIHNpbmdsZSBub24tTVRJIHNjaGVtZSB2ZXJz dXMgYSBzZXQgb2Ygc2NoZW1lcy4gSSBhbSBub3Qgc3VyZSB0aGF0IHRoaXMNCiBpcyBhIHBvaW50 IHdvcnRoIGZvY3VzaW5nIG9uLCBhcyBpdCBpcyBjbGVhcmx5IGEgc3BlY2lhbCBjYXNlIG9mIDIp IGluIHRlcm1zIG9mIHRoZSBpbnRlbnQgYW5kIG1vdGl2YXRpb24gb2YgdGhlIGdyb3VwIGNyZWF0 b3IgKGkuZS4gaWYgdGhlIGdyb3VwIGNyZWF0b3IgaXMgbW9yZSBmb2N1c2VkIG9uIHRoZSBzZWN1 cml0eSBhbmQgb3RoZXIgYXNwZWN0cyB0aGFuIGFsbG93aW5nIGFueW9uZSB0byBqb2luLCB0aGVu IGlzc3VlcyBpbiAzKSBzZWVtDQogbGFyZ2VseSB0byBiZSBhIG1vb3QgcG9pbnQpLiA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QnJpdHRhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7SGFsZSwgQnJp dHRhIChDSVYpJnF1b3Q7ICZsdDticml0dGEuaGFsZUBucHMuZWR1Jmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5GcmlkYXksIEZlYnJ1YXJ5IDI4LCAyMDIwIGF0IDg6MjEgQU08YnI+DQo8Yj5UbzogPC9i PkthcnRoaWsgQmhhcmdhdmFuICZsdDtrYXJ0aGlrZXlhbi5iaGFyZ2F2YW5AaW5yaWEuZnImZ3Q7 LCBSYXBoYWVsIFJvYmVydCAmbHQ7cmFwaGFlbEB3aXJlLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9i PkJlbmphbWluIEJldXJkb3VjaGUgJmx0O2JlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnImZ3Q7 LCBDYXMgQ3JlbWVycyAmbHQ7Y2FzLmNyZW1lcnNAZ21haWwuY29tJmd0OywgTUwgTWVzc2FnaW5n IExheWVyIFNlY3VyaXR5ICZsdDttbHNAaWV0Zi5vcmcmZ3Q7LCBLb25yYWQgS29oYnJvayAmbHQ7 S29ucmFkLmtvaGJyb2tAZGF0YXNocmluZS5kZSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtNTFNdIGNvbmZpcm1pbmcgY2lwaGVyIHN1aXRlcyBkZWNpc2lvbnM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5JbiB0ZXJtcyBvZiBuZWdvdGlhdGlvbiwgSSB0aGluayB3ZSBjYW4gY2xvc2VseSBj b3JyZWxhdGUgdGhlIGlzc3VlcyBhbmQgcHJhY3RpY2FsIHJhbWlmaWNhdGlvbnMgaW4gY2hvb3Np bmcgYSBzaWduYXR1cmUgc2NoZW1lIGxpc3Qgd2l0aCB0aGUgY2lwaGVyc3VpdGUgbmVnb3RpYXRp b24gdGhhdCBhbHJlYWR5IHRha2VzIHBsYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TGV0IHVzIGFzc3VtZSB0 aGF0IGV2ZXJ5IG1lbWJlciB3b3VsZCBub3Qgb25seSBoYXZlIGEgbGlzdCBvZiBzdXBwb3J0ZWQg Y2lwaGVyc3VpdGVzIGluIHRoZWlyIENJSywgYnV0IGFsc28gb2Ygc2lnbmF0dXJlIHNjaGVtZXMu IFRoZSBhY3Rpb24gb2YgdGhlIGdyb3VwIGNyZWF0b3IgaXMgdGhlbiBjb21wYXJhYmxlIGluIHRo ZSBmb2xsb3dpbmcgYS9iIGNhc2VzIGZvcg0KIGNpcGhlcnN1aXRlcy9zaWduYXR1cmUgc2NoZW1l czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9ImNvbG9yOmJsYWNrO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBs ZXZlbDEgbGZvMyI+DQpUaGUgZ3JvdXAgY3JlYXRvciB3YW50cyB0byBlbnN1cmUgYW55IG5ld2Nv bWVyIGNhbiBqb2luIHRoZSBncm91cDo8bzpwPjwvbzpwPjwvbGk+PG9sIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0iY29sb3I6YmxhY2s7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVsMiBs Zm8zIj4NClRoZSBncm91cCBjcmVhdG9yIGNob29zZXMgdGhlIE1USSBjaXBoZXJzdWl0ZS48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6Ymxh Y2s7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxldmVsMiBsZm8zIj4NClRoZSBncm91cCBj cmVhdG9yIGNob29zZXMgdGhlIE1USSBhcyB0aGUgc2luZ2xlIGVsZW1lbnQgaW4gdGhlIHNldCBv ZiBwb3NzaWJsZSBzaWduYXR1cmVzLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9vbD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6YmxhY2s7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0 IGxldmVsMSBsZm8zIj4NClRoZSBncm91cCBjcmVhdG9yIHdhbnRzIG1vcmUgY29udHJvbCBhbmQg aXMgbm90IHBhcnRpY3VsYXJseSBjb25jZXJuZWQgYWJvdXQgbmV3Y29tZXJzIGluIHRoZSBsb25n LXRlcm06PG86cD48L286cD48L2xpPjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIx IiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOmJs YWNrO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDIgbGZvMyI+DQpUaGUgZ3JvdXAg Y3JlYXRvciBjaG9vc2VzIGEgbm9uLU1USSBjaXBoZXJzdWl0ZSBmcm9tIHRoZSBpbml0aWFsIGdy b3VwIG1lbWJlcnPigJkgbGlzdHMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9ImNvbG9yOmJsYWNrO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBs ZXZlbDIgbGZvMyI+DQpUaGUgZ3JvdXAgY3JlYXRvciBjaG9vc2VzIGEgc3Vic2V0IG9mIGluaXRp YWwgZ3JvdXAgbWVtYmVyc+KAmSBzdXBwb3J0ZWQgYWxnb3JpdGhtcyAod2hpY2ggbWF5IG9yIG1h eSBub3QgaW5jbHVkZSB0aGUgTVRJKS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZvciB0aGUgc2FrZSBv ZiBhcmd1bWVudCwgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBhbHRlcm5hdGl2ZSB0byBiOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIyIiB0 eXBlPSIxIj4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIzIiB0eXBlPSJhIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOmJsYWNrO21hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDIgbGZvMyI+DQpUaGUgZ3JvdXAgY3JlYXRvciBjaG9v c2VzIGEgc2luZ2xlIG5vbi1NVEkgc2lnbmF0dXJlIHNjaGVtZS48bzpwPjwvbzpwPjwvbGk+PC9v bD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGlzc3VlcyBmb3IgbmV3Y29tZXJzIGluIGNhc2UgMmIg aXMgbm90IHZlcnkgZGlmZmVyZW50IGZyb20gMmMgKHdoaWNoIGlzIHVsdGltYXRlbHkgdGhlIGNh c2UgaWYgd2Ugb25seSBzdXBwb3J0IG9uZSBzY2hlbWUpLiBCYXNpY2FsbHksIHRoZSBuZXdjb21l ciBzdXBwb3J0cyB0aGUgc2NoZW1lL3NldCBvZiBzY2hlbWVzIG9yIGhlIGRvZXMgbm90LiBJbiAy YSwNCiAyYiwgYW5kIDJjLCBhbGdvcml0aG1zIGFyZSBkaWN0YXRlZCBieSB0aGUgc2V0IG9mIGlu aXRpYWwgbWVtYmVycywgc28gd2UgYXJlIG5vdCBsb29raW5nIGF0IGEgc2lnbmlmaWNhbnQgdXNh YmlsaXR5IGRpZmZlcmVuY2UgdGhlcmUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Rm9yIGNob29zaW5nIHRoZSBzaWduYXR1cmUgc2NoZW1lIGxpc3QsIGFueSBwcm9wZXIgc3Vi c2V0IG9mIHRoZSBpbnRlcnNlY3Rpb24gb2YgdGhlIGluaXRpYWwgZ3JvdXAgbWVtYmVyc+KAmSBs aXN0IHdvdWxkIGJlIHBvc3NpYmxlIChoZW5jZSB3aHkgd2UgaGF2ZSBmcmVlZG9tIHRvIGNob29z ZSB7TVRJfSBpbiBjYXNlIDFiKS4gSG93ZXZlciwgd2UgY291bGQgbWFrZQ0KIGl0IHNpbXBsZSBh bmQgdXNlIHRoZSBhY3R1YWwgaW50ZXJzZWN0aW9uLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+QXMgZmFyIGFzIGxpc3RzIGNoYW5naW5nIG92ZXIgdGltZTogaW4gdGVybXMgb2Yg d2hhdCBhIG1lbWJlciBjYW4gc3VwcG9ydCB0aGUgYW5zd2VyIGlzIGFuIGFmZmlybWF0aXZlLiBJ biB0aGUgc2FtZSB3YXkgdGhlIHN1cHBvcnRlZCBjaXBoZXJzdWl0ZXMgY2FuIGNoYW5nZSBvdmVy IHRpbWUsIHRoZSBzdXBwb3J0ZWQgc2lnbmF0dXJlIHNjaGVtZXMgY2FuIGFzIHdlbGwuDQogSG93 ZXZlciwgaW4gdGVybXMgb2Ygd2hhdCBpcyB1c2VkIGluIHRoZSBncm91cCwgdGhpcyBzaG91bGQg bm90IGNoYW5nZTogb25jZSBmaXhlZCBhdCBncm91cCBpbml0aWF0aW9uIHRoZSBsaXN0IGlzIHN0 YXRpYyBmb3IgdGhlIGxpZmV0aW1lIG9mIHRoZSBncm91cC4gT25jZSBhIG1lbWJlciBoYXMgY2hv c2VuIGEgc2lnbmF0dXJlIHNjaGVtZSBmcm9tIHRoZSBsaXN0LCB0aGUgY2hvaWNlIGlzIHN0YXRp YyBmb3IgdGhlIGxpZmV0aW1lIG9mIHRoZQ0KIGdyb3VwLiBUaGUgZ3JvdXAgc2hvdWxkIHRodXMg bm90IGJlIGFkYXB0YWJsZSB0byBjaGFuZ2VzIGluIHRoZSBvZmZlcmVkIGFsZ29yaXRobXMgb2Yg dGhlIENJS3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Ccml0dGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5LYXJ0aGlrIEJoYXJnYXZh biAmbHQ7a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyJmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5GcmlkYXksIEZlYnJ1YXJ5IDI4LCAyMDIwIGF0IDY6NTUgQU08YnI+DQo8Yj5UbzogPC9iPlJh cGhhZWwgUm9iZXJ0ICZsdDtyYXBoYWVsQHdpcmUuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1 b3Q7SGFsZSwgQnJpdHRhIChDSVYpJnF1b3Q7ICZsdDticml0dGEuaGFsZUBucHMuZWR1Jmd0Oywg QmVuamFtaW4gQmV1cmRvdWNoZSAmbHQ7YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mciZndDss IENhcyBDcmVtZXJzICZsdDtjYXMuY3JlbWVyc0BnbWFpbC5jb20mZ3Q7LCBNTCBNZXNzYWdpbmcg TGF5ZXIgU2VjdXJpdHkgJmx0O21sc0BpZXRmLm9yZyZndDssIEtvbnJhZCBLb2hicm9rICZsdDtL b25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W01MU10gY29uZmlybWluZyBjaXBoZXIgc3VpdGVzIGRlY2lzaW9uczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzdXJlIGFib3V0 IHRoZSBwcmFjdGljYWwgcmFtaWZpY2F0aW9ucyBvZiBncm91cHMgd2hlcmUgbWVtYmVycyB1c2Ug ZGlmZmVyZW50IGFsZ29yaXRobXMuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdGlsbCwgSSB0aGluayBpdCBpcyBmZWFzaWJsZSB0byBldmVudHVhbGx5IGhhdmUgYSBk ZXNpZ24gd2hlcmUgdGhlIGdyb3VwIGNyZWF0b3IgcHJvcG9zZXMgYSBzZXQgb2YgYWxnb3JpdGht cyBhcyDigJxtdXN0IGltcGxlbWVudOKAnSBmb3IgdGhlIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWFjaCBuZXcgbWVtYmVyIG11c3Qg c3VwcG9ydCAoaS5lLiBpbXBsZW1lbnQpIOKAnGFsbOKAnSB0aGUgYWxnb3JpdGhtcyBpbiB0aGlz IGxpc3QgaW4gb3JkZXIgdG8gam9pbiB0aGUgZ3JvdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCB0aGUgbWVtYmVyIGhhcyB0aGUg b3B0aW9uIHRvIHVzZSB3aGljaGV2ZXIgc3VwcG9ydGVkIGFsZ29yaXRobSBzaGUgcHJlZmVycyBm b3IgbWVzc2FnZXMgc2hlIHNlbmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSBhbGwgb2YgdGhpcyBpcyBhIHJlYXNvbmFibGUgbG9u Zy10ZXJtIGdvYWwsIHBlcmhhcHMgd2Ugc2hvdWxkIHN0YXJ0IHdpdGggYSB2ZXJzaW9uIHdoZXJl IHRoZSBjcmVhdG9yIG9ubHkgY2hvb3NlcyBvbmUgYWxnb3JpdGhtIGluIGVhY2ggY2F0ZWdvcnks IGxlYXZpbmcgbm8gY2hvaWNlIHRvIHRoZSBtZW1iZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgY2FuIGRvY3VtZW50IHRoaXMgY2hvaWNl IGFzIGEgZnV0dXJlIGV4dGVuc2lvbiBwb2ludCwgYW5kIGNoYW5nZSBpdCBhcyB3ZSB1bmRlcnN0 YW5kIHRoZSBmZWRlcmF0aW9uIHNjZW5hcmlvIGFuZCBkZXBsb3ltZW50IGNvbnN0cmFpbnRzIGEg Yml0IGJldHRlcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkthcnRoaWs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjcgRmViIDIwMjAsIGF0IDE5OjAyLCBS YXBoYWVsIFJvYmVydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhcGhhZWxAd2lyZS5jb20iPnJhcGhh ZWxAd2lyZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCB3aGF0IEthcnRoaWsgc2FpZCwgYW5kIEkgdGhp bmsgdGhhdCB0aGF0IHdhcyB0aGUgdW5kZXJseWluZyBhc3N1bXB0aW9uIGFsbCBhbG9uZyAoYXQg ZWFzdCBmb3IgbWUpLiBUaGUgbmVnb3RpYXRpb24gaGFzIHRvIGhhcHBlbiBhaGVhZCBvZiB0aW1l LCBuYW1lbHkgd2hlbg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDstICgxKSBhbiBleGlzdGluZyBtZW1iZXIgcHJvcG9zZXMgdG8gYWRkIGEgbmV3 IG1lbWJlciwgb3Igd2hlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7LSAoMikgYW4gZXh0ZXJuYWwgcGFydHkgcHJvcG9zZXMgdG8gYWRk IGEgbmV3IG1lbWJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gdGhlIGN1cnJlbnQgcHJvcG9zYWwgd2l0aCBhIGZpeGVkIHNpZ25hdHVy ZSBwZXIgZ3JvdXAgdGhlIGRlY2lzaW9uIHRha2luZyBpcyByYXRoZXIgc2ltcGxlOiBJZiB0aGUg bmV3IG1lbWJlciBhZHZlcnRpc2VzIHN1cHBvcnQgZm9yIHRoZSBncm91cCdzIGNpcGhlcnN1aXRl IGluIHRoZWlyIENJS3MsIHRoZXkgY2FuIGJlIGFkZGVkIHRvIHRoZSBncm91cC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtl IHRvIHNlZSB0aGUgZGVjaXNpb24gdGFraW5nIGZsZXNoZWQgb3V0IGZvciB0aGUgYWx0ZXJuYXRp dmUgYXBwcm9hY2ggdGhhdCBzdXBwb3J0cyBtdWx0aXBsZSBzaWduYXR1cmVzLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgbmVlZCB0 byBtYWtlIHN1cmUgdGhhdCBtZW1iZXJzIGNhbiB2ZXJpZnkgc2lnbmF0dXJlcywgd2hpY2ggbWVh bnMgd2UgbmVlZCBhIGxpc3Qgb2YgYWNjZXB0YWJsZSBzaWduYXR1cmUgYWxnb3JpdGhtcyB0aGF0 IGV2ZXJ5IG1lbWJlciBhZ3JlZXMgdXBvbiBiZWZvcmUgYSBuZXcgbWVtYmVyIGlzIGFkZGVkLiBT aWduYXR1cmUgYWxnb3JpdGhtcyBjYW4gYmUgYWR2ZXJ0aXNlZCBpbiBhbm90aGVyIGV4dGVuc2lv bg0KIGluIENJS3MsIGJ1dCBpdCBpcyBub3QgZW50aXJlbHkgY2xlYXIgdG8gbWUgaG93IGNsaWVu dHMgYWdyZWUgb24gd2hhdCB0aGUgbGlzdCBvZiBhY2NlcHRhYmxlIHNpZ25hdHVyZXMgaXMuIFdv dWxkIGl0IGJlIHRoZSBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yLCBtZWFuaW5nIHRoZSBpbnRl cnNlY3Rpb24gb2YgdGhlIGFsZ29yaXRobXMgYWR2ZXJ0aXNlZCBpbiB0aGUgQ0lLcz8gSWYgc28s IGl0IG1lYW5zIHRoZSBsaXN0IGdldHMgbGFyZ2VseQ0KIGRldGVybWluZWQgYnkgdGhlIGVhcmx5 IGpvaW5lcnMuIEFsc28sIGNhbiB0aGUgbGlzdCBjaGFuZ2Ugb3ZlciB0aW1lPyBUaGF0IHdvdWxk IGJlIGNvbnRyYXJ5IHRvIHRoZSBpZGVhIHRoYXQgYWxsIG5lZ290aWF0aW9ucyBzaG91bGQgaGFw cGVuIGFoZWFkIG9mIHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVyZSBtaWdodCBhbiBlYXN5IHNvbHV0aW9uIGhlcmUsIEkganVzdCBk b27igJl0IHNlZSBpdCByaWdodCBub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhcGhhZWwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI3IEZlYiAyMDIwLCBhdCAxMjo1MCwg SGFsZSwgQnJpdHRhIChDSVYpICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVk dSI+YnJpdHRhLmhhbGVAbnBzLmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVuamFtaW4sPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcG9pbnQgb2YgY29tcGFyaXNvbiB3aXRoIFRM UyBpcyB0aGF0IGludGVyb3AgaXMgc2lnbmlmaWNhbnRseSBsZXNzIG9mIGFuIGlzc3VlIHdoZW4g ZXZlcnlvbmUgaW4gdGhlIGdyb3VwIGlzIHVzaW5nIHRoZSBzYW1lIGNsaWVudCBwcm9ncmFtLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0 ZXJtcyBvZiBpbnRlcm9wLCB5b3VyIGNvbmNlcm5zIGJlY29tZSBhIGRpc2N1c3Npb24gcG9pbnQg bWFpbmx5IGluIHRoZSBmZWRlcmF0aW9uIGNhc2Ug4oCTIGFuZCB0aGF0IGlzIGFuIGltcG9ydGFu dCBjYXNlIHRoYXQgd2Ugc2hvdWxkIHBsYW4gZm9yLiBCdXQsIGFzIEkgc2FpZCBhbmQgeW91IHJl LWl0ZXJhdGVkLCBpZiB0aGUgdXNlIGNhc2UgcmVhbGx5IGV4cGVjdHMgaW50ZXJvcCBpc3N1ZXMg ZnJvbSBhbGxvd2luZw0KIGNob2ljZSwgdGhlbiBub3RoaW5nIHByZXZlbnRzIHRoZSBzZWxlY3Rp b24gb2YgYSBzaW5nbGUgc2NoZW1lIGZvciB0aGUgc2V0IG9mIGFsbG93YWJsZSBzY2hlbWVzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB0 byB0aGUgcmVhc29ucyBiZWhpbmQgYWxsb3dpbmcgbXVsdGlwbGUgYWxnb3JpdGhtcywgdGhlIGRv Y3VtZW50IG9uIHRoZSBtYWlsaW5nbGlzdCBoYXMgYWxyZWFkeSBvdXRsaW5lZCBzZXZlcmFsIOKA kyB0aGVzZSBhcmUgc2VjdXJpdHkgcmVhc29ucyBmb3Igc3VwcG9ydGluZyBpbmRpdmlkdWFsIGFs Z29yaXRobXMuIFRoZSBpbnRlcm9wIG9iamVjdGlvbnMgZmFsbCBvbiB0aGUgdXNhYmlsaXR5IHNp ZGUsIHNvDQogdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiBpcyByZWFsbHkgYWJvdXQgdXNhYmlsaXR5 IHZzLiBzZWN1cml0eSBjb25jZXJucy4gSG93ZXZlciwgYXQgdGhlIGludGVyc2VjdGlvbiBvZiB0 aGVzZSB0d28gb3B0aW9ucyBpcyB0aGUgaWRlYSBvZiBhbGxvd2luZyBhIHNldCBvZiBwb3NzaWJs ZSBhbGdvcml0aG1zIGFzIEthcnRoaWsgc3VnZ2VzdHMuIFRoaXMgaXMgYSBnb29kIGNvbXByb21p c2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkkgd291bGQgZGVmaW5pdGVseSBub3Qgc3VnZ2VzdCB0aGF0IHlvdSBjb25zaWRlciBtdWx0aXBs ZSBNVElzIGF0IHRoaXMgc3RhZ2UuIElmIHRoYXQgaXMgc29tZXRoaW5nIHlvdSB3YW50LCBpdCBp cyBiZXN0IHRvIHJhaXNlIGl0IGFzIGEgc2VwYXJhdGUgaXNzdWUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpdHRhPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QmVuamFtaW4gQmV1 cmRvdWNoZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnIi PmJlbmphbWluLmJldXJkb3VjaGVAaW5yaWEuZnI8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5UaHVyc2RheSwg RmVicnVhcnkgMjcsIDIwMjAgYXQgMTE6NDggQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90O0hhbGUsIEJyaXR0YSAo Q0lWKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaXR0YS5oYWxlQG5wcy5lZHUiPmJyaXR0 YS5oYWxlQG5wcy5lZHU8L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Q2FzIENyZW1lcnMgJmx0OzxhIGhyZWY9Im1h aWx0bzpjYXMuY3JlbWVyc0BnbWFpbC5jb20iPmNhcy5jcmVtZXJzQGdtYWlsLmNvbTwvYT4mZ3Q7 LCBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gJmx0OzxhIGhyZWY9Im1haWx0bzprYXJ0aGlrZXlhbi5i aGFyZ2F2YW5AaW5yaWEuZnIiPmthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcjwvYT4mZ3Q7 LCBNTCBNZXNzYWdpbmcgTGF5ZXINCiBTZWN1cml0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1sc0Bp ZXRmLm9yZyI+bWxzQGlldGYub3JnPC9hPiZndDssIEtvbnJhZCBLb2hicm9rICZsdDs8YSBocmVm PSJtYWlsdG86a29ucmFkLmtvaGJyb2tAZGF0YXNocmluZS5kZSI+a29ucmFkLmtvaGJyb2tAZGF0 YXNocmluZS5kZTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbTUxTXSBjb25maXJtaW5nIGNpcGhl ciBzdWl0ZXMgZGVjaXNpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjcgRmViIDIwMjAsIGF0IDExOjQ3LCBCZW5q YW1pbiBCZXVyZG91Y2hlICZsdDs8YSBocmVmPSJtYWlsdG86YmVuamFtaW4uYmV1cmRvdWNoZUBp bnJpYS5mciI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVuamFtaW4uYmV1cmRvdWNoZUBp bnJpYS5mcjwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEJyaXR0 YSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI3IEZlYiAyMDIwLCBhdCAxMDo1 NywgSGFsZSwgQnJpdHRhIChDSVYpICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhhbGVAbnBz LmVkdSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YnJpdHRhLmhhbGVAbnBzLmVkdTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbmphbWluLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWVzIHlvdSBkZXNjcmliZSBhcmUgcHJpbWFyaWx5IFRM Uy10eXBlIHByb2JsZW1zLCB3aGVyZSB1bmNvbnRyb2xsZWQsIGxhcmdlLXNjYWxlIGFnaWxpdHkg YW5kIGludGVyb3AgaXNzdWVzIGV4aXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMgZXhhY3RseSwgYW5kIEkgdGhpbmsgdHdvLXBh cnR5IHNob3J0IGxpdmVkIGNvbm5lY3Rpb25zIGZvciBUTFMgYXJlIGVhc2llciB0byBoYW5kbGU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnRoYW4gd2lsbCBiZSB0aGUgbG9uZy1saXZlZCBtdWx0aS1wYXJ0eSBjb25uZWN0 aW9ucyBvZiBNTFMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXMgaGFzIGJlZW4gc3RhdGVkIGluIHRoZSB3b3JraW5nIGdyb3VwIGFzIGEgc3VwcG9ydGlu ZyBhcmd1bWVudCB0byBtYW55IGNoYW5nZXMgb3ZlciB0aGUgZGlmZmVyZW50IGRyYWZ0cywgd2l0 aGluIHRoZSBtZXNzYWdpbmcvTUxTIHNwYWNlIHdlIGFyZSBsb29raW5nIGF0IHNpZ25pZmljYW50 bHkgbW9yZSBjbGllbnQtc3BlY2lmaWMgY29udHJvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGFuZCB3ZSBrZWVwIGJlaW5nIGNhcmVmdWwg dGhhdCBpdCBpcyB0aGUgY2FzZSB3aGVuIHdyaXRpbmcgdGhlIGRyYWZ0cyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1 dCB0aGlzIGRvZXNu4oCZdCBtZWFuIHRoYXQgd2Ugc2hvdWxkIGJlIHdpbGxpbmcgdG8gcmlzayBp bnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBpcyBub3QgdW5yZWFzb25hYmxlIGZvciBhIG5ld2NvbWVyIHRvIHN1cHBvcnQgYSBzZWxlY3Rp b24gb2Ygc2lnbmF0dXJlIHNjaGVtZXMuIElmIHRoZSBncm91cCBjcmVhdG9yIHJlYWxseSB3YW50 cyBmdWxsIGludGVyb3AsIHRoZXkgY2FuIGFsd2F5cyBkZWZpbmUgdGhlIHNldCBvZiBhdmFpbGFi bGUgc2NoZW1lcyB0byBjb25zaXN0IG9ubHkgb2YgdGhlIE1USS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgYXQgcmV2ZXJzZSwgaWYgeW91IGFyZSB3 aWxsaW5nIHRvIGJyZWFrIGludGVyb3AsIHlvdSBzaG91bGQgYmUgc2VsZWN0aW5nIHNvbWV0aGlu ZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Uy9zaG91bGQgYmUgc2VsZWN0aW5nL2NhbiBzZWxlY3QvPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lbHNlIHRoYW4gdGhlIE1USSB3aGVuIGNyZWF0aW5n IHRoZSBncm91cC4gQW5kIGFnYWluLCBpbiB3aGF0IEkgc2F5LCBub3RoaW5nIHByZXZlbnRzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj55b3UgdG8gcGljayB0aGUgTklTVCBjaXBoZXJzdWl0ZSBmb3IgY29tcGxpYW5jZSBh bmQgdXNlIG9ubHkgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIGRvbuKAmXQgc2VlIHRoZSBpbnRlcmVz dCBvZiBtaXhpbmcgYWxncyBhbmQgcHV0IGF0IHJpc2sgaW1wbGVtZW50YXRpb25zIGFuZCBpbnRl cm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdXQgb2YgY3VyaW9zaXR5 LCB3aGVyZSB5b3Ugc29tZWhvdyBhcmd1aW5nIGZvciBtdWx0aXBsZSBNVElzIGhlcmUgPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2EiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KTUxTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpNTFNA aWV0Zi5vcmciPk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21scyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbHM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9DD8A71EB8A84141810BBCE5F8DDDED3npsedu_-- From nobody Fri Feb 28 03:35:35 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FA43A164E for ; Fri, 28 Feb 2020 03:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNvE57uxaco5 for ; Fri, 28 Feb 2020 03:35:30 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 E6E9B3A164C for ; Fri, 28 Feb 2020 03:35:29 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id a141so2830013wme.2 for ; Fri, 28 Feb 2020 03:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8lBKd2Yn7dj4dfb/9+FmRwdA0URH7ThDWsbbmt6BMZA=; b=2Im/Tfo6ZuE1KUVoVyT7YBPc99GAfpb657uVqU3/wLm2/qscPI7Mew0TYakrsTDRkH XitGKxhMy1Dcu9gtzEHjzFaCSAur4QoNIYBHIyOEboc961K3RYQqpREjWza5rKdHJGjV LzrWPCIqXNo9d9jfIbWpj5ICrvMwGgic7y6XVaK1FeQnby9gIsd6rXZ4gqg0ZDCoMu7A mffloGWhYpBt3plLEZW8wFa/yIwPiMcevrQNMdObemQ1SEuVe4+kVrMMeVfXXy9cSwU/ KFoldvTF865cduSMYmuDvu7XoEsreHbEXHcKzgEd9CXqlrubpC+BgtBDJ3Y+ZLZogob3 ZZqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8lBKd2Yn7dj4dfb/9+FmRwdA0URH7ThDWsbbmt6BMZA=; b=nDiMDToi1PUb0j0EXkVQmSfLVGJGUZvvb2RGNW4Y042mhxBC8TwiSu1GcjUCtV5HOS XiJoUMskSGqamDisadCz07OTG4EClTG6DLZm1L8sP8MtdwJB+fwJDp0tafna19oiQ00y cLcaeeT/vthu+uZEKsfxKBfWqW6tnHnPVi55rOmWBCrexlrkTinDbgqn1IvHLoJ/5rCT sVdhyn41No3Te9g7H2eIWP4934gAkL2FVtpBDuQnhrZGQEBDZSuMBgjgucv1C6/qJ+dN UN0ZwkFHrKkwW5jfVJwj1jGnxB62jFvTXW7hFwdr92oQIYLUZTRS2r2jMPUf/nUuM/K4 XvnA== X-Gm-Message-State: APjAAAViQfKFLZGInRe2H5Z2lzuNYPF+keH9P6Kg/nAU+XhZiYPWGEa0 o/DfG3wkFuOym9LOcKiavTUrQg== X-Google-Smtp-Source: APXvYqyQ+KpCVBt0iYu5VHT8WcsqxKg0Qrc7A2qirNFH2eABiWvc/Ey0ys+aTJZkqrQlC2HAZKUF7A== X-Received: by 2002:a1c:5f54:: with SMTP id t81mr4587851wmb.155.1582889727957; Fri, 28 Feb 2020 03:35:27 -0800 (PST) Received: from [192.168.178.21] ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id q12sm12866408wrg.71.2020.02.28.03.35.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 03:35:26 -0800 (PST) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_32A5BD8A-6CD2-44E4-938A-0E42E1205F6D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 28 Feb 2020 12:34:55 +0100 In-Reply-To: <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu> Cc: Karthik Bhargavan , Benjamin Beurdouche , Cas Cremers , ML Messaging Layer Security , Konrad Kohbrok To: "Hale, Britta (CIV)" References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 11:35:34 -0000 --Apple-Mail=_32A5BD8A-6CD2-44E4-938A-0E42E1205F6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If we put aside the strategic considerations for a minute, I think the = two proposals boil down to the following: Proposal A (the current one): - Ciphersuites contain a signature scheme - The group creator picks a ciphersuite upon group creation - The creator MUST only add members to the group that advertise the = ciphersuite in their CIKs - The same rule applies to any AddProposal in the future - The ciphersuite is explicitly mentioned in the Welcome message - Members MUST only use the signature scheme of the ciphersuite to sign = messages Proposal B (as proposed by Britta et al.): - Ciphersuites do not contain a signature scheme - The group creator picks a ciphersuite upon group creation - The group creator picks a list of signature schemes (LSS) - The creator MUST only add members to the group that advertise the = ciphersuite in their CIKs AND all elements of the LSS - The same rule applies to any AddProposal in the future - The ciphersuite AND the LSS are explicitly mentioned in the Welcome = message - Members MUST only use the signature schemes that are part of the LSS = to sign messages In order to make progress, I would like to propose that we move forward = with the current proposal simply because it is well understood and fully = specified. However, we add the following two open issues to the protocol = draft: OPEN ISSUE: Security could be improved by allowing more flexibility with = signatures schemes. If a signature scheme becomes insecure over time, = members could be given the choice of choosing a more secure signature = scheme as long at there is a guarantee that all other members are able = to verify signatures under that new scheme. OPEN ISSUE: Crypto primitives of the chosen ciphersuite could become = insecure overtime and jeopardize the security of the whole group. Since = TreeKEM doesn=E2=80=99t support mixing different DHKEM algorithms and = different symmetric encryption algorithms, we need a way to upgrade an = existing group to a new and more secure ciphersuite. This would give us some more time to work on the open issues and come up = with fully fleshed out proposals that we can discuss and ultimately all = agree with. Would this approach be acceptable to everyone? Raphael > On 28 Feb 2020, at 08:21, Hale, Britta (CIV) = wrote: >=20 > In terms of negotiation, I think we can closely correlate the issues = and practical ramifications in choosing a signature scheme list with the = ciphersuite negotiation that already takes place. > Let us assume that every member would not only have a list of = supported ciphersuites in their CIK, but also of signature schemes. The = action of the group creator is then comparable in the following a/b = cases for ciphersuites/signature schemes: > =20 > The group creator wants to ensure any newcomer can join the group: > The group creator chooses the MTI ciphersuite. > The group creator chooses the MTI as the single element in the set of = possible signatures. > =20 > The group creator wants more control and is not particularly concerned = about newcomers in the long-term: > The group creator chooses a non-MTI ciphersuite from the initial group = members=E2=80=99 lists. > The group creator chooses a subset of initial group members=E2=80=99 = supported algorithms (which may or may not include the MTI). > For the sake of argument, consider the following alternative to b: > The group creator chooses a single non-MTI signature scheme. > =20 > The issues for newcomers in case 2b is not very different from 2c = (which is ultimately the case if we only support one scheme). Basically, = the newcomer supports the scheme/set of schemes or he does not. In 2a, = 2b, and 2c, algorithms are dictated by the set of initial members, so we = are not looking at a significant usability difference there. > =20 > For choosing the signature scheme list, any proper subset of the = intersection of the initial group members=E2=80=99 list would be = possible (hence why we have freedom to choose {MTI} in case 1b). = However, we could make it simple and use the actual intersection.=20 > =20 > As far as lists changing over time: in terms of what a member can = support the answer is an affirmative. In the same way the supported = ciphersuites can change over time, the supported signature schemes can = as well. However, in terms of what is used in the group, this should not = change: once fixed at group initiation the list is static for the = lifetime of the group. Once a member has chosen a signature scheme from = the list, the choice is static for the lifetime of the group. The group = should thus not be adaptable to changes in the offered algorithms of the = CIKs. > =20 > Britta > =20 > =20 > =20 > From: Karthik Bhargavan > Date: Friday, February 28, 2020 at 6:55 AM > To: Raphael Robert > Cc: "Hale, Britta (CIV)" , Benjamin Beurdouche = , Cas Cremers , ML = Messaging Layer Security , Konrad Kohbrok = > Subject: Re: [MLS] confirming cipher suites decisions > =20 > I am not sure about the practical ramifications of groups where = members use different algorithms. > =20 > Still, I think it is feasible to eventually have a design where the = group creator proposes a set of algorithms as =E2=80=9Cmust implement=E2=80= =9D for the group. > Each new member must support (i.e. implement) =E2=80=9Call=E2=80=9D = the algorithms in this list in order to join the group. > However, the member has the option to use whichever supported = algorithm she prefers for messages she sends. > =20 > While all of this is a reasonable long-term goal, perhaps we should = start with a version where the creator only chooses one algorithm in = each category, leaving no choice to the members. > We can document this choice as a future extension point, and change it = as we understand the federation scenario and deployment constraints a = bit better? > =20 > Best, > Karthik > =20 >=20 >=20 >> On 27 Feb 2020, at 19:02, Raphael Robert > wrote: >> =20 >> I agree with what Karthik said, and I think that that was the = underlying assumption all along (at east for me). The negotiation has to = happen ahead of time, namely when >> =20 >> - (1) an existing member proposes to add a new member, or when >> - (2) an external party proposes to add a new member. >> =20 >> In the current proposal with a fixed signature per group the decision = taking is rather simple: If the new member advertises support for the = group's ciphersuite in their CIKs, they can be added to the group. >> =20 >> I would like to see the decision taking fleshed out for the = alternative approach that supports multiple signatures.=20 >> We need to make sure that members can verify signatures, which means = we need a list of acceptable signature algorithms that every member = agrees upon before a new member is added. Signature algorithms can be = advertised in another extension in CIKs, but it is not entirely clear to = me how clients agree on what the list of acceptable signatures is. Would = it be the lowest common denominator, meaning the intersection of the = algorithms advertised in the CIKs? If so, it means the list gets largely = determined by the early joiners. Also, can the list change over time? = That would be contrary to the idea that all negotiations should happen = ahead of time. >> There might an easy solution here, I just don=E2=80=99t see it right = now. >> =20 >> Raphael=20 >>=20 >>=20 >>> On 27 Feb 2020, at 12:50, Hale, Britta (CIV) > wrote: >>> =20 >>> Benjamin,=20 >>> =20 >>> The point of comparison with TLS is that interop is significantly = less of an issue when everyone in the group is using the same client = program. >>> =20 >>> In terms of interop, your concerns become a discussion point mainly = in the federation case =E2=80=93 and that is an important case that we = should plan for. But, as I said and you re-iterated, if the use case = really expects interop issues from allowing choice, then nothing = prevents the selection of a single scheme for the set of allowable = schemes. >>> =20 >>> As to the reasons behind allowing multiple algorithms, the document = on the mailinglist has already outlined several =E2=80=93 these are = security reasons for supporting individual algorithms. The interop = objections fall on the usability side, so the current discussion is = really about usability vs. security concerns. However, at the = intersection of these two options is the idea of allowing a set of = possible algorithms as Karthik suggests. This is a good compromise. >>> =20 >>> I would definitely not suggest that you consider multiple MTIs at = this stage. If that is something you want, it is best to raise it as a = separate issue. >>> =20 >>> --- >>> =20 >>> Britta >>> =20 >>> =20 >>> From: Benjamin Beurdouche > >>> Date: Thursday, February 27, 2020 at 11:48 AM >>> To: "Hale, Britta (CIV)" > >>> Cc: Cas Cremers >, Karthikeyan Bhargavan = >, ML Messaging Layer Security = >, Konrad Kohbrok = > >>> Subject: Re: [MLS] confirming cipher suites decisions >>> =20 >>> =20 >>>=20 >>>=20 >>>=20 >>>> On 27 Feb 2020, at 11:47, Benjamin Beurdouche = > = wrote: >>>> =20 >>>> Hi Britta, >>>>=20 >>>>=20 >>>>=20 >>>>> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) > wrote: >>>>> =20 >>>>> Benjamin, >>>>> =20 >>>>> The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist. >>>> =20 >>>> Yes exactly, and I think two-party short lived connections for TLS = are easier to handle >>>> than will be the long-lived multi-party connections of MLS. >>>>=20 >>>>=20 >>>>=20 >>>>> As has been stated in the working group as a supporting argument = to many changes over the different drafts, within the messaging/MLS = space we are looking at significantly more client-specific control. >>>> =20 >>>> Yes, and we keep being careful that it is the case when writing the = drafts, >>>> but this doesn=E2=80=99t mean that we should be willing to risk = interoperability. >>>>=20 >>>>=20 >>>>=20 >>>>> It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI. >>>> =20 >>>> I think at reverse, if you are willing to break interop, you should = be selecting something >>> =20 >>> S/should be selecting/can select/ >>>=20 >>>=20 >>>=20 >>>> else than the MTI when creating the group. And again, in what I = say, nothing prevents >>>> you to pick the NIST ciphersuite for compliance and use only that. >>>> But I don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability. >>>> =20 >>>> Out of curiosity, where you somehow arguing for multiple MTIs here = ? >>>> =20 >>>> B. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_32A5BD8A-6CD2-44E4-938A-0E42E1205F6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = we put aside the strategic considerations for a minute, I think the two = proposals boil down to the following:

Proposal A (the current one):

 - Ciphersuites = contain a signature scheme
 - The group = creator picks a ciphersuite upon group creation
 - The creator MUST only add members to the group that = advertise the ciphersuite in their CIKs
 - The = same rule applies to any AddProposal in the future
 - The ciphersuite is explicitly mentioned in the = Welcome message
 - Members MUST only use the = signature scheme of the ciphersuite to sign messages

Proposal B (as proposed = by Britta et al.):

 - Ciphersuites do not contain a signature = scheme
 - The group creator picks a = ciphersuite upon group creation
 - The group = creator picks a list of signature schemes (LSS)
 - The creator MUST only add members to the group = that advertise the ciphersuite in their CIKs AND all elements of the = LSS
 - The same rule applies to any = AddProposal in the future
 - The ciphersuite = AND the LSS are explicitly mentioned in the Welcome message
 - Members MUST only use the signature schemes that are = part of the LSS to sign messages

In order to make progress, I would like = to propose that we move forward with the current proposal simply because = it is well understood and fully specified. However, we add the following = two open issues to the protocol draft:

OPEN ISSUE: Security could be improved = by allowing more flexibility with signatures schemes. If a signature = scheme becomes insecure over time, members could be given the choice of = choosing a more secure signature scheme as long at there is a guarantee = that all other members are able to verify signatures under that new = scheme.

OPEN = ISSUE: Crypto primitives of the chosen ciphersuite could become insecure = overtime and jeopardize the security of the whole group. Since TreeKEM = doesn=E2=80=99t support mixing different DHKEM algorithms and different = symmetric encryption algorithms, we need a way to upgrade an existing = group to a new and more secure ciphersuite.

This would give us some more time to = work on the open issues and come up with fully fleshed out proposals = that we can discuss and ultimately all agree with.

Would this approach be = acceptable to everyone?

Raphael


On 28 Feb 2020, at 08:21, Hale, Britta (CIV) <britta.hale@nps.edu>= wrote:

In terms of negotiation, I think we can closely = correlate the issues and practical ramifications in choosing a signature = scheme list with the ciphersuite negotiation that already takes = place.
Let us assume that every member would not only = have a list of supported ciphersuites in their CIK, but also of = signature schemes. The action of the group creator is then comparable in = the following a/b cases for ciphersuites/signature schemes:
 
  1. The group = creator wants to ensure any newcomer can join the group:
    1. The group creator chooses the MTI ciphersuite.
    2. The group creator chooses the MTI as the single element in = the set of possible signatures.
 
  1. The group creator wants more = control and is not particularly concerned about newcomers in the = long-term:
    1. The group creator chooses a = non-MTI ciphersuite from the initial group members=E2=80=99 lists.
    2. The group creator chooses a subset of initial group = members=E2=80=99 supported algorithms (which may or may not include the = MTI).
For the sake of argument, = consider the following alternative to b:
    1. The group creator chooses a = single non-MTI signature scheme.
 
The issues for newcomers in case = 2b is not very different from 2c (which is ultimately the case if we = only support one scheme). Basically, the newcomer supports the = scheme/set of schemes or he does not. In 2a, 2b, and 2c, algorithms are = dictated by the set of initial members, so we are not looking at a = significant usability difference there.
 
For = choosing the signature scheme list, any proper subset of the = intersection of the initial group members=E2=80=99 list would be = possible (hence why we have freedom to choose {MTI} in case 1b). = However, we could make it simple and use the actual intersection. 
 
As far as = lists changing over time: in terms of what a member can support the = answer is an affirmative. In the same way the supported ciphersuites can = change over time, the supported signature schemes can as well. However, = in terms of what is used in the group, this should not change: once = fixed at group initiation the list is static for the lifetime of the = group. Once a member has chosen a signature scheme from the list, the = choice is static for the lifetime of the group. The group should thus = not be adaptable to changes in the offered algorithms of the CIKs.
 
Britta
 
 
 
From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
Date: Friday, February 28, = 2020 at 6:55 AM
To: Raphael Robert <raphael@wire.com>
Cc: "Hale, Britta (CIV)" = <britta.hale@nps.edu>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>, Cas Cremers <cas.cremers@gmail.com>, ML Messaging Layer Security = <mls@ietf.org>, = Konrad Kohbrok <Konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming = cipher suites decisions
 
I= am not sure about the practical ramifications of groups where members = use different algorithms.
 
Still, I think it is = feasible to eventually have a design where the group creator proposes a = set of algorithms as =E2=80=9Cmust implement=E2=80=9D for the group.
Each new member must support (i.e. implement) =E2=80=9Call=E2=80= =9D the algorithms in this list in order to join the group.
However, the member has the option to use whichever supported = algorithm she prefers for messages she sends.
 
While all of this is a reasonable = long-term goal, perhaps we should start with a version where the creator = only chooses one algorithm in each category, leaving no choice to the = members.
We can document this choice as a future = extension point, and change it as we understand the federation scenario = and deployment constraints a bit better?
 
Best,
Karthik
 


On 27 Feb 2020, at 19:02, Raphael = Robert <raphael@wire.com> = wrote:
 
I agree with what Karthik = said, and I think that that was the underlying assumption all along (at = east for me). The negotiation has to happen ahead of time, namely = when
 
 - (1) an existing member proposes = to add a new member, or when
 - (2) an external = party proposes to add a new member.
 
In the current proposal with a fixed signature per group the = decision taking is rather simple: If the new member advertises support = for the group's ciphersuite in their CIKs, they can be added to the = group.
 
I would like to see the decision taking fleshed out for the = alternative approach that supports multiple signatures. 
We need to make sure that members can verify signatures, = which means we need a list of acceptable signature algorithms that every = member agrees upon before a new member is added. Signature algorithms = can be advertised in another extension in CIKs, but it is not entirely = clear to me how clients agree on what the list of acceptable signatures = is. Would it be the lowest common denominator, meaning the intersection = of the algorithms advertised in the CIKs? If so, it means the list gets = largely determined by the early joiners. Also, can the list change over = time? That would be contrary to the idea that all negotiations should = happen ahead of time.
There might an easy = solution here, I just don=E2=80=99t see it right now.
 
Raphael 


On 27 Feb 2020, at 12:50, Hale, Britta = (CIV) <britta.hale@nps.edu> = wrote:
 
Benjamin, 
 
The point of comparison with TLS is = that interop is significantly less of an issue when everyone in the = group is using the same client program.
 
In terms of interop, your concerns = become a discussion point mainly in the federation case =E2=80=93 and = that is an important case that we should plan for. But, as I said and = you re-iterated, if the use case really expects interop issues from = allowing choice, then nothing prevents the selection of a single scheme = for the set of allowable schemes.
 
As to the reasons behind allowing multiple algorithms, the = document on the mailinglist has already outlined several =E2=80=93 these = are security reasons for supporting individual algorithms. The interop = objections fall on the usability side, so the current discussion is = really about usability vs. security concerns. However, at the = intersection of these two options is the idea of allowing a set of = possible algorithms as Karthik suggests. This is a good compromise.
 
I would definitely not suggest that you = consider multiple MTIs at this stage. If that is something you want, it = is best to raise it as a separate issue.
 
---
 
Britta
 
 
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Date: Thursday, February 27, = 2020 at 11:48 AM
To: "Hale, Britta (CIV)" = <britta.hale@nps.edu>
Cc: Cas Cremers <cas.cremers@gmail.com>, = Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, ML Messaging Layer = Security <mls@ietf.org>, Konrad = Kohbrok <konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming = cipher suites decisions
 
 



On 27 Feb 2020, at 11:47, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
 
Hi = Britta,



On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <britta.hale@nps.edu> wrote:
 
Benjamin,
 
The issues you describe are primarily = TLS-type problems, where uncontrolled, large-scale agility and interop = issues exist.
 
Yes exactly, and I think = two-party short lived connections for TLS are easier to handle
than will be the long-lived multi-party = connections of MLS.



As has been stated in the working group = as a supporting argument to many changes over the different drafts, = within the messaging/MLS space we are looking at significantly more = client-specific control.
 
Yes, and we keep being careful that it = is the case when writing the drafts,
but this doesn=E2=80=99t mean that we = should be willing to risk interoperability.



It is not = unreasonable for a newcomer to support a selection of signature schemes. = If the group creator really wants full interop, they can always define = the set of available schemes to consist only of the MTI.
 
I think at reverse, if you are willing = to break interop, you should be selecting something
 
S/should be selecting/can select/



else than the MTI when creating the group. And again, in what = I say, nothing prevents
you to = pick the NIST ciphersuite for compliance and use only that.
But I don=E2=80=99t see the interest of = mixing algs and put at risk implementations and interoperability.
 
Out of curiosity, where you somehow = arguing for multiple MTIs here ?
 
B.



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

= --Apple-Mail=_32A5BD8A-6CD2-44E4-938A-0E42E1205F6D-- From nobody Fri Feb 28 04:18:22 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653EA3A16E3 for ; Fri, 28 Feb 2020 04:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds2_uLyLG-kd for ; Fri, 28 Feb 2020 04:18:17 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 193DC3A09C0 for ; Fri, 28 Feb 2020 04:18:17 -0800 (PST) X-ASG-Debug-ID: 1582892295-0e39454965cf0f0001-bGA3T6 Received: from mail.nps.edu (synergos.ern.nps.edu [172.20.4.116]) by mule.nps.edu with ESMTP id clv6McRiZJS8SiAZ; Fri, 28 Feb 2020 04:18:15 -0800 (PST) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Fri, 28 Feb 2020 04:18:15 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (104.47.38.55) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Fri, 28 Feb 2020 04:18:15 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mO6zxNKpKKycdcdTi8XZuwap9t+9srgYVnZSfGcw2WUkeItz9xoR/6Hyu9ziLJqf/2VusZme7SnBmErXGoI1gDy73AE3PhzAMbY+C+rqrvvYZC/ZOX/8N2ikv6B7h8a7uHEl1gbdbGe6AV3+DylQ6NJxU3f/gI9BFbP7VQXw3CdsfRaM3Axbb/ny2edBeZgJAwchkBok/zEvG6M8a8JQ1aEoZj5wANF+55jpuVhz4RXYdlu2FT+/C/4QBD7kEUmDsC4jN6Y9xvA2mWwTNt1NwVfA3dLW16KrHtj8Dvk3YEXESdZ0/rE2ahstSthpJ91Xs2T9TaPeUvbj1ys1RcVFeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zpGa2jWYJVfw7R0i0CbRZY+HF08Mms2fnC08Ngqqyy8=; b=W3jBqWiEr2yzHdHZNbhmzPSAhagiQEL1h1R19l5zEXOCgf7gF4JmEIEv3HAjebDX3ZEcs1RN1M6ayQNRoNmw3/GON+424jfbR5OQZ+XAlD+PPZ3bScMrcEbd7aNzCiGTlDcy+Lg92vYOqdTScVWRawVtVpK8kBcLkgoK1SXHoT/rw9bmd/aOSLabZkD4aSrc56zrIZFQHL/e0YCuwnw2so+iVB6I0t/a3sDfDbJLVYFAAQ5c9+gvXjrLRTX/tESlOMnMzvKmVKlYn45nogEmwFvacoobXxf2N0gaE4AoVTrB80kuDSmG+220rWfARfyvmOolNl5xK+ldjESgh1liTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3697.namprd13.prod.outlook.com (2603:10b6:a03:22e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.11; Fri, 28 Feb 2020 12:18:13 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::31ba:c240:895e:1475%7]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 12:18:12 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:22e::11] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:22e::11 From: "Hale, Britta (CIV)" To: Raphael Robert CC: Karthik Bhargavan , Benjamin Beurdouche , Cas Cremers , "ML Messaging Layer Security" , Konrad Kohbrok Thread-Topic: [MLS] confirming cipher suites decisions X-ASG-Orig-Subj: Re: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QgItlQOeVhVQUSdKiw0YIWW2agXOr8AgAmxSwCAATAYgIAKMACAgAALVYCAAXH8AIAAIHiAgAAGs4CAAA3FAIAA4SKA//+JDYCAAJPkAIAAAGYA//+LDgCAAO4egIAAxxUA//+SO4AAGZlGgAAAb30o Date: Fri, 28 Feb 2020 12:18:12 +0000 Message-ID: References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [176.11.134.145] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b6aeff48-e6e7-483c-00c5-08d7bc484807 x-ms-traffictypediagnostic: BY5PR13MB3697: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39850400004)(346002)(366004)(136003)(376002)(199004)(189003)(33656002)(54906003)(26005)(86362001)(30864003)(5660300002)(8676002)(75432002)(66946007)(8936002)(55016002)(66556008)(66476007)(64756008)(66446008)(76116006)(6506007)(966005)(2906002)(81166006)(91956017)(71200400001)(81156014)(53546011)(478600001)(7696005)(9686003)(186003)(316002)(786003)(55236004)(4326008)(45080400002)(52536014)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3697; H:BY5PR13MB3013.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tAAtEBSUpV71VAEwkUTraj+lcEkDWADqCbgX/qoZu+DgqBUD+P5DKsZM9YG7qEraVnAkaRtRfjfb/fJU1q5Owixo2FFINbnT3N+YwOgjb2du80jnFG4y0f9mIYDsa0yUPk4wuVNyu9bGOgncNfexnI6nPQHnzwmXzO/I/n3EisAoYsPSxNtAOtrpVBu6+Wpls1kRSodXNktQ7UgwJtARTNxAjDhJv7WgiiyLdNkkeOnh4BchWyTUVnVqn+Z2yYypt7ShAWr73jQ6iG8UIdtnfWOMXKOeRhhK0odT1DpuGtzqC1ylqA2AH+C4qqOdQ3Npe+KtQpoBLfYjfavuY8fgvH98sxmbfafa4fey4wWoelG+GJM3mYPGWyU0K2AHLZTMIn3BG1T9Bs58lXywtnFfqZcNRGXkc9HkfycWtraJPLmU1G/gIbqw8kOZcZ2L5O+52sIYc8cdTZ0F3M+WJrogHCtgcCZ+dQ2XnIfjUaJ+pfpaNwdMXxET52JSNh4HKbdGiPi0O7e3umXsIk4F4oFM3g== x-ms-exchange-antispam-messagedata: JZ1pgVTlPLS6Aq1vHLuLQIXuHOIaIm7dXfux9VoUGuiuOW4EPJRzMduuNB8jQGcoHwURQO5zXin0syvE4yhuJxIB1Zotk9s1/N0tM+l8efXwazZUSvwyLlZBJzKIzOJiLz9ujz8F1KjeeOLOrqBVuA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3013D301CA5B74E09673705CFBE80BY5PR13MB3013namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b6aeff48-e6e7-483c-00c5-08d7bc484807 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 12:18:12.5162 (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: SXQZQhlHlxJNqELjMejYaN3P4vGU2RLgtdAMxNzdWyUeaXud0+qkQ7ZQruAts11Wh0Gwmuc8ORa5r1FQmk1R2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3697 X-OriginatorOrg: nps.edu X-Barracuda-Connect: synergos.ern.nps.edu[172.20.4.116] X-Barracuda-Start-Time: 1582892295 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 47681 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.80318 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 12:18:21 -0000 --_000_BY5PR13MB3013D301CA5B74E09673705CFBE80BY5PR13MB3013namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This description provides a good, succinct outline of the two options with = respect to a usability comparison. I think that we now are in a decent stat= e of clarity regarding both how both alternatives would work in practice (t= hanks to Raphael) and how the security of the alternatives line up (extrapo= lated from the previous alternative of full signature scheme choice flexibi= lity). Consequently, both options appear to be well understood, so I do not believ= e that there is any argument there - if anyone does not understand either a= lternative then it can be clarified. - We have a decent view of security concerns on this issue, as have been vo= iced by several people (4 strong votes for option B). - The interop concerns are limited and mostly in the federated environment = (2 strong votes for option A). - No one has voiced efficiency concerns. Any one of these is a decent reason too choose one alternative over another= . Having an open PR is not. We all want to make progress, have this decided, and move on. We should do = it correctly. It seems ill-advised to back track and bypass where we are at= in consensus. Britta Get Outlook for Android ________________________________ From: Raphael Robert Sent: Friday, February 28, 2020 12:34:55 PM To: Hale, Britta (CIV) Cc: Karthik Bhargavan ; Benjamin Beurdouche= ; Cas Cremers ; ML Me= ssaging Layer Security ; Konrad Kohbrok Subject: Re: [MLS] confirming cipher suites decisions If we put aside the strategic considerations for a minute, I think the two = proposals boil down to the following: Proposal A (the current one): - Ciphersuites contain a signature scheme - The group creator picks a ciphersuite upon group creation - The creator MUST only add members to the group that advertise the cipher= suite in their CIKs - The same rule applies to any AddProposal in the future - The ciphersuite is explicitly mentioned in the Welcome message - Members MUST only use the signature scheme of the ciphersuite to sign me= ssages Proposal B (as proposed by Britta et al.): - Ciphersuites do not contain a signature scheme - The group creator picks a ciphersuite upon group creation - The group creator picks a list of signature schemes (LSS) - The creator MUST only add members to the group that advertise the cipher= suite in their CIKs AND all elements of the LSS - The same rule applies to any AddProposal in the future - The ciphersuite AND the LSS are explicitly mentioned in the Welcome mess= age - Members MUST only use the signature schemes that are part of the LSS to = sign messages In order to make progress, I would like to propose that we move forward wit= h the current proposal simply because it is well understood and fully speci= fied. However, we add the following two open issues to the protocol draft: OPEN ISSUE: Security could be improved by allowing more flexibility with si= gnatures schemes. If a signature scheme becomes insecure over time, members= could be given the choice of choosing a more secure signature scheme as lo= ng at there is a guarantee that all other members are able to verify signat= ures under that new scheme. OPEN ISSUE: Crypto primitives of the chosen ciphersuite could become insecu= re overtime and jeopardize the security of the whole group. Since TreeKEM d= oesn=92t support mixing different DHKEM algorithms and different symmetric = encryption algorithms, we need a way to upgrade an existing group to a new = and more secure ciphersuite. This would give us some more time to work on the open issues and come up wi= th fully fleshed out proposals that we can discuss and ultimately all agree= with. Would this approach be acceptable to everyone? Raphael On 28 Feb 2020, at 08:21, Hale, Britta (CIV) > wrote: In terms of negotiation, I think we can closely correlate the issues and pr= actical ramifications in choosing a signature scheme list with the ciphersu= ite negotiation that already takes place. Let us assume that every member would not only have a list of supported cip= hersuites in their CIK, but also of signature schemes. The action of the gr= oup creator is then comparable in the following a/b cases for ciphersuites/= signature schemes: 1. The group creator wants to ensure any newcomer can join the group: * The group creator chooses the MTI ciphersuite. * The group creator chooses the MTI as the single element in the set= of possible signatures. 1. The group creator wants more control and is not particularly concerne= d about newcomers in the long-term: * The group creator chooses a non-MTI ciphersuite from the initial g= roup members=92 lists. * The group creator chooses a subset of initial group members=92 sup= ported algorithms (which may or may not include the MTI). For the sake of argument, consider the following alternative to b: * The group creator chooses a single non-MTI signature scheme. The issues for newcomers in case 2b is not very different from 2c (which is= ultimately the case if we only support one scheme). Basically, the newcome= r supports the scheme/set of schemes or he does not. In 2a, 2b, and 2c, alg= orithms are dictated by the set of initial members, so we are not looking a= t a significant usability difference there. For choosing the signature scheme list, any proper subset of the intersecti= on of the initial group members=92 list would be possible (hence why we hav= e freedom to choose {MTI} in case 1b). However, we could make it simple and= use the actual intersection. As far as lists changing over time: in terms of what a member can support t= he answer is an affirmative. In the same way the supported ciphersuites can= change over time, the supported signature schemes can as well. However, in= terms of what is used in the group, this should not change: once fixed at = group initiation the list is static for the lifetime of the group. Once a m= ember has chosen a signature scheme from the list, the choice is static for= the lifetime of the group. The group should thus not be adaptable to chang= es in the offered algorithms of the CIKs. Britta From: Karthik Bhargavan > Date: Friday, February 28, 2020 at 6:55 AM To: Raphael Robert > Cc: "Hale, Britta (CIV)" >,= Benjamin Beurdouche >, Cas Cremers >, ML Messaging Layer Security >, Kon= rad Kohbrok > Subject: Re: [MLS] confirming cipher suites decisions I am not sure about the practical ramifications of groups where members use= different algorithms. Still, I think it is feasible to eventually have a design where the group c= reator proposes a set of algorithms as =93must implement=94 for the group. Each new member must support (i.e. implement) =93all=94 the algorithms in t= his list in order to join the group. However, the member has the option to use whichever supported algorithm she= prefers for messages she sends. While all of this is a reasonable long-term goal, perhaps we should start w= ith a version where the creator only chooses one algorithm in each category= , leaving no choice to the members. We can document this choice as a future extension point, and change it as w= e understand the federation scenario and deployment constraints a bit bette= r? Best, Karthik On 27 Feb 2020, at 19:02, Raphael Robert > wrote: I agree with what Karthik said, and I think that that was the underlying as= sumption all along (at east for me). The negotiation has to happen ahead of= time, namely when - (1) an existing member proposes to add a new member, or when - (2) an external party proposes to add a new member. In the current proposal with a fixed signature per group the decision takin= g is rather simple: If the new member advertises support for the group's ci= phersuite in their CIKs, they can be added to the group. I would like to see the decision taking fleshed out for the alternative app= roach that supports multiple signatures. We need to make sure that members can verify signatures, which means we nee= d a list of acceptable signature algorithms that every member agrees upon b= efore a new member is added. Signature algorithms can be advertised in anot= her extension in CIKs, but it is not entirely clear to me how clients agree= on what the list of acceptable signatures is. Would it be the lowest commo= n denominator, meaning the intersection of the algorithms advertised in the= CIKs? If so, it means the list gets largely determined by the early joiner= s. Also, can the list change over time? That would be contrary to the idea = that all negotiations should happen ahead of time. There might an easy solution here, I just don=92t see it right now. Raphael On 27 Feb 2020, at 12:50, Hale, Britta (CIV) > wrote: Benjamin, The point of comparison with TLS is that interop is significantly less of a= n issue when everyone in the group is using the same client program. In terms of interop, your concerns become a discussion point mainly in the = federation case =96 and that is an important case that we should plan for. = But, as I said and you re-iterated, if the use case really expects interop = issues from allowing choice, then nothing prevents the selection of a singl= e scheme for the set of allowable schemes. As to the reasons behind allowing multiple algorithms, the document on the = mailinglist has already outlined several =96 these are security reasons for= supporting individual algorithms. The interop objections fall on the usabi= lity side, so the current discussion is really about usability vs. security= concerns. However, at the intersection of these two options is the idea of= allowing a set of possible algorithms as Karthik suggests. This is a good = compromise. I would definitely not suggest that you consider multiple MTIs at this stag= e. If that is something you want, it is best to raise it as a separate issu= e. --- Britta From: Benjamin Beurdouche > Date: Thursday, February 27, 2020 at 11:48 AM To: "Hale, Britta (CIV)" > Cc: Cas Cremers >, Kart= hikeyan Bhargavan >, ML Messaging Layer Security >, Konrad Kohbrok > Subject: Re: [MLS] confirming cipher suites decisions On 27 Feb 2020, at 11:47, Benjamin Beurdouche > wrote: Hi Britta, On 27 Feb 2020, at 10:57, Hale, Britta (CIV) > wrote: Benjamin, The issues you describe are primarily TLS-type problems, where uncontrolled= , large-scale agility and interop issues exist. Yes exactly, and I think two-party short lived connections for TLS are easi= er to handle than will be the long-lived multi-party connections of MLS. As has been stated in the working group as a supporting argument to many ch= anges over the different drafts, within the messaging/MLS space we are look= ing at significantly more client-specific control. Yes, and we keep being careful that it is the case when writing the drafts, but this doesn=92t mean that we should be willing to risk interoperability. It is not unreasonable for a newcomer to support a selection of signature s= chemes. If the group creator really wants full interop, they can always def= ine the set of available schemes to consist only of the MTI. I think at reverse, if you are willing to break interop, you should be sele= cting something S/should be selecting/can select/ else than the MTI when creating the group. And again, in what I say, nothin= g prevents you to pick the NIST ciphersuite for compliance and use only that. But I don=92t see the interest of mixing algs and put at risk implementatio= ns and interoperability. Out of curiosity, where you somehow arguing for multiple MTIs here ? B. _______________________________________________ MLS mailing list MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls --_000_BY5PR13MB3013D301CA5B74E09673705CFBE80BY5PR13MB3013namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This description provides a good, succinct outline of the two options with = respect to a usability comparison. I think that we now are in a decent stat= e of clarity regarding both how both alternatives would work in practice (t= hanks to Raphael) and how the security of the alternatives line up (extrapolated from the previous alternative of= full signature scheme choice flexibility).

Consequently, both options appear to be well understood, so I do not believ= e that there is any argument there - if anyone does not understand either a= lternative then it can be clarified.

- We have a decent view of security concerns on this issue, as have been vo= iced by several people (4 strong votes for option B).
- The interop concerns are limited and mostly in the federated environment = (2 strong votes for option A).
- No one has voiced efficiency concerns.
Any one of these is a decent reason too choose one alternative over another= . Having an open PR is not.

We all want to make progress, have this decided, and move on. We should do = it correctly. It seems ill-advised to back track and bypass where we are at= in consensus.


Britta


From: Raphael Robert <ra= phael@wire.com>
Sent: Friday, February 28, 2020 12:34:55 PM
To: Hale, Britta (CIV) <britta.hale@nps.edu>
Cc: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>; Benjam= in Beurdouche <benjamin.beurdouche@inria.fr>; Cas Cremers <cas.cre= mers@gmail.com>; ML Messaging Layer Security <mls@ietf.org>; Konra= d Kohbrok <Konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming cipher suites decisions
 

Proposal A (the current one):

 - Ciphersuites contain a signature scheme
 - The group creator picks a ciphersuite upon group cr= eation
 - The creator MUST only add members to the group that= advertise the ciphersuite in their CIKs
 - The same rule applies to any AddProposal in the fut= ure
 - The ciphersuite is explicitly mentioned in the Welc= ome message
 - Members MUST only use the signature scheme of the c= iphersuite to sign messages

Proposal B (as proposed by Britta et al.):

 - Ciphersuites do not contain a signature scheme
 - The group creator picks a ciphersuite upon gro= up creation
 - The group creator picks a list of signature schemes= (LSS)
 - The creator MUST only add members to the group= that advertise the ciphersuite in their CIKs AND all elements of the LSS
 - The same rule applies to any AddProposal in the fut= ure
 - The ciphersuite AND the LSS are explicitly mentione= d in the Welcome message
 - Members MUST only use the signature schemes that ar= e part of the LSS to sign messages

In order to make progress, I would like to propose that we = move forward with the current proposal simply because it is well understood= and fully specified. However, we add the following two open issues to the = protocol draft:

OPEN ISSUE: Security could be improved by allowing more fle= xibility with signatures schemes. If a signature scheme becomes insecure ov= er time, members could be given the choice of choosing a more secure signat= ure scheme as long at there is a guarantee that all other members are able to verify signatures under that new scheme= .

OPEN ISSUE: Crypto primitives of the chosen ciphersuite cou= ld become insecure overtime and jeopardize the security of the whole group.= Since TreeKEM doesn=92t support mixing different DHKEM algorithms and diff= erent symmetric encryption algorithms, we need a way to upgrade an existing group to a new and more secure cipher= suite.

This would give us some more time to work on the open issue= s and come up with fully fleshed out proposals that we can discuss and ulti= mately all agree with.

Would this approach be acceptable to everyone?

Raphael


On 28 Feb 2020, at 08:21, Hale, Britta (CIV) <britta.hale@nps.edu> wrote:<= /div>
In terms of negotiation, I think we can closely= correlate the issues and practical ramifications in choosing a signature s= cheme list with the ciphersuite negotiation that already takes place.
Let us assume that every member would not only = have a list of supported ciphersuites in their CIK, but also of signature s= chemes. The action of the group creator is then comparable in the following= a/b cases for ciphersuites/signature schemes:
 
  1. The group creator wants to ensure any newcomer can join the group:
    1. The group creator chooses the MTI ciphersuite.
    2. The group creator chooses the MTI as the single element in the set of possi= ble signatures.
 
  1. The group creator wants more control and is not particularly concerned abou= t newcomers in the long-term:
    1. The group creator chooses a non-MTI ciphersuite from the initial group memb= ers=92 lists.
    2. The group creator chooses a subset of initial group members=92 supported al= gorithms (which may or may not include the MTI).
For the sake of argument, consider the followin= g alternative to b:
    1. The group creator chooses a single non-MTI signature scheme.
 
The issues for newcomers in case 2b is not very= different from 2c (which is ultimately the case if we only support one sch= eme). Basically, the newcomer supports the scheme/set of schemes or he does= not. In 2a, 2b, and 2c, algorithms are dictated by the set of initial members, so we are not looking at a sig= nificant usability difference there.
 
For choosing the signature scheme list, any pro= per subset of the intersection of the initial group members=92 list would b= e possible (hence why we have freedom to choose {MTI} in case 1b). However,= we could make it simple and use the actual intersection. <= /div>
 
As far as lists changing over time: in terms of= what a member can support the answer is an affirmative. In the same way th= e supported ciphersuites can change over time, the supported signature sche= mes can as well. However, in terms of what is used in the group, this should not change: once fixed at group ini= tiation the list is static for the lifetime of the group. Once a member has= chosen a signature scheme from the list, the choice is static for the life= time of the group. The group should thus not be adaptable to changes in the offered algorithms of the CIKs.
 
Britta
 
 
 
From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
Date: Friday, February 28, 2020 at 6:55 AM
To: R= aphael Robert <raphael@wi= re.com>
Cc: &= quot;Hale, Britta (CIV)" <britta.hale@nps.edu>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr<= /a>>, Cas Cremers <cas.cr= emers@gmail.com>, ML Messaging Layer Security <mls@ietf.org>, Konrad Kohbrok <Konrad.kohbrok@datashri= ne.de>
Subject: = Re: [MLS] confirming cipher suites decisions
 
I am not sure about the practical ramifications of groups where members use= different algorithms.
 
Still, I think it is feasible to eventually have a design where the group c= reator proposes a set of algorithms as =93must implement=94 for the group.<= /div>
Each new member must support (i.e. implement) =93all=94 the algorithms in t= his list in order to join the group.
However, the member has the option to use whichever supported algorithm she= prefers for messages she sends.
 
While all of this is a reasonable long-term goal, perhaps we should start w= ith a version where the creator only chooses one algorithm in each category= , leaving no choice to the members.
We can document this choice as a future extension point, and change it as w= e understand the federation scenario and deployment constraints a bit bette= r?
 
Best,
Karthik
 


On 27 Feb 2020, at 19:02, Raphael Robert <raphael@= wire.com> wrote:
 
I agree with what Karthik said, and I think that that was the underlying as= sumption all along (at east for me). The negotiation has to happen ahead of= time, namely when
 
 - (1) an existing member proposes to add a new member, or when
 - (2) an external party proposes to add a new member.
 
In the current proposal with a fixed signature per group the decision takin= g is rather simple: If the new member advertises support for the group's ci= phersuite in their CIKs, they can be added to the group.
 
I would like to see the decision taking fleshed out for the alternative app= roach that supports multiple signatures. 
We need to make sure that members can verify signatures, which means we nee= d a list of acceptable signature algorithms that every member agrees upon b= efore a new member is added. Signature algorithms can be advertised in anot= her extension in CIKs, but it is not entirely clear to me how clients agree on what the list of acceptable = signatures is. Would it be the lowest common denominator, meaning the inter= section of the algorithms advertised in the CIKs? If so, it means the list = gets largely determined by the early joiners. Also, can the list change over time? That would be contrary to th= e idea that all negotiations should happen ahead of time.
There might an easy solution here, I just don=92t see it right now.
 
Raphael 


On 27 Feb 2020, at 12:50, Hale, Britta (CIV) <b= ritta.hale@nps.edu> wrote:
 
Benjamin, 
 
The point of comparison with TLS is that interop is significantly less of a= n issue when everyone in the group is using the same client program.
 
In terms of interop, your concerns become a discussion point mainly in the = federation case =96 and that is an important case that we should plan for. = But, as I said and you re-iterated, if the use case really expects interop = issues from allowing choice, then nothing prevents the selection of a single scheme for the set of allowable= schemes.
 
As to the reasons behind allowing multiple algorithms, the document on the = mailinglist has already outlined several =96 these are security reasons for= supporting individual algorithms. The interop objections fall on the usabi= lity side, so the current discussion is really about usability vs. security concerns. However, at the intersect= ion of these two options is the idea of allowing a set of possible algorith= ms as Karthik suggests. This is a good compromise.
 
I would definitely not suggest that you consider multiple MTIs at this stag= e. If that is something you want, it is best to raise it as a separate issu= e.
 
---
 
Britta
 
 
From: Benjamin Beurdouche <= benjamin.beurdouche@inria.fr>
Date: Thursday, February 27, 2020 at 11:48 AM
To: &= quot;Hale, Britta (CIV)" <britta.hale@nps.= edu>
Cc: C= as Cremers <cas.cremers@gmail.com>, Ka= rthikeyan Bhargavan <karthikeyan.bha= rgavan@inria.fr>, ML Messaging Layer Security <mls@ietf.org>, Ko= nrad Kohbrok <konrad.kohbrok@datashrin= e.de>
Subject: = Re: [MLS] confirming cipher suites decisions
 
 



On 27 Feb 2020, at 11:47, Benjamin Beurdouche <benjamin.beurdouche@inria.= fr> wrote:
 
Hi Britta,



On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <<= span class=3D"" style=3D"color:purple">britta.hale@nps.edu> w= rote:
 
Benjamin,
 
The issues you describe are primarily TLS-type problems, where uncontrolled= , large-scale agility and interop issues exist.
 
Yes exactly, and I think two-party short lived connections for TLS are easi= er to handle
than will be the long-lived multi-party connections of MLS.



As has been stated in the working group as a supporting argument to many ch= anges over the different drafts, within the messaging/MLS space we are look= ing at significantly more client-specific control.
 
Yes, and we keep being careful that it is the case when writing the drafts,=
but this doesn=92t mean that we should be willing to risk interoperability.=



It is not unreasonable for a newcomer to support a selection of signature s= chemes. If the group creator really wants full interop, they can always def= ine the set of available schemes to consist only of the MTI.
 
I think at reverse, if you are willing to break interop, you should be sele= cting something
 
S/should be selecting/can select/



else than the MTI when creating the group. And again, in what I say, nothin= g prevents
you to pick the NIST ciphersuite for compliance and use only that.
But I don=92t see the interest of mixing algs and put at risk implementatio= ns and interoperability.
 
Out of curiosity, where you somehow arguing for multiple MTIs here ?
 
B.



___________= ____________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listin= fo/mls

--_000_BY5PR13MB3013D301CA5B74E09673705CFBE80BY5PR13MB3013namp_-- From nobody Fri Feb 28 10:07:10 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFB13A1C67 for ; Fri, 28 Feb 2020 10:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaRQ7-1KRRAB for ; Fri, 28 Feb 2020 10:06:18 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 8AAEB3A1AA5 for ; Fri, 28 Feb 2020 10:06:17 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id m16so3952788wrx.11 for ; Fri, 28 Feb 2020 10:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y4zVPYEc+Rp1cMwoIcVSstQjJO/hNuYjs4hCTThjOWQ=; b=JpucCZWooR+OwzrqANCLeupu1YGM5ioj+ng/CCL6XEIuE0+t95IrnbYoDphMOxImb7 Qm1YfMWyBuTxoNiRH18GJyFlH6w2EwyAV+GgzFTcvfCKvybw4LIW4mb1qqbjVCNUDyzK vll4fv0tIu2YEPfYs6gBKK+CAwd0GQp01sVhing0WK+IWHd+lKZ8DBZy7nIUmy/eVF3U B0Zkgt05sL537hJHSf98QTlZhZ/8daQA9nacqAqAt90r9ZxnRFcU1RhjoEu4HvxmU77C AzuEKaZPUyFrZhj9SdnDF0KqoRl96iJxOFxUoO72h1qD5iFInUZmmUQBawId5VUdzVfR R23w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y4zVPYEc+Rp1cMwoIcVSstQjJO/hNuYjs4hCTThjOWQ=; b=JRwci5IxhOWj+NYYUJEofa/+3/5bUQYm42kayaZiofJ/ZuNvbMbaE7ZGwXT8HGQ9IQ cNG5pN/RWStJOt9aNZjj8d7enIMCNJXJ1GGQ/UumYLIB8IuYiFmq/yPP/It0y0WzJk3Y CW/jIcpMrrxmJSzgFpxVw5v08FFnebE1UnjYvwx8F08iYLLiEeMHp3LJx6oW5cvpmFoL MuWuFhpEE4Q2ayRA06jlB1IwqZaNrSCy7C3ekiqd+WWpz//eqIk0QZ2g0kd8Do6LRbcN ObvkGUogDfxOFkxArsIBBYTVN3U+FaSUm1fTXlTD+jtO0YwKA/bnt+Mfv+wmdoceUNk4 5wbg== X-Gm-Message-State: APjAAAV+B/Y5qCxKQoaKHQs3CO+2EzwT6EQIFjECJ4X4/0lH029NLrTv o+sq9co2vdKFZDkjsHlMGul41Q== X-Google-Smtp-Source: APXvYqy7iAQv/tIWNg2QqQhRIfXCopFBI+lT8IFODVtNmQ5BnBUSrmuHiQ9y+46t7GnSkC8VUyyPVA== X-Received: by 2002:adf:f84a:: with SMTP id d10mr6023666wrq.208.1582913174059; Fri, 28 Feb 2020 10:06:14 -0800 (PST) Received: from [192.168.178.21] ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id g14sm14118639wrv.58.2020.02.28.10.06.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 10:06:13 -0800 (PST) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D11AE6E7-5B4E-4C6D-8BA6-A69201A5C735" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 28 Feb 2020 19:05:41 +0100 In-Reply-To: Cc: Karthik Bhargavan , Benjamin Beurdouche , Cas Cremers , ML Messaging Layer Security , Konrad Kohbrok To: "Hale, Britta (CIV)" References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 18:06:27 -0000 --Apple-Mail=_D11AE6E7-5B4E-4C6D-8BA6-A69201A5C735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I for one feel some further clarification on the context is needed, = because the posts on the mailing list don=E2=80=99t fully reflect what = we discussed extensively during the virtual interim calls and some = nuances got lost. First of all I think there was full consensus on the fact that = degradation of the security of crypto primitives is something we deeply = care about, because degradation jeopardizes the security properties of = the group and an attacker could use it for downgrade attacks. The = dissensus arose around the question on how exactly we want to address = degradation. In general, any of the crypto primitives in the ciphersuites can suffer = degradation at some point. We need a sound mechanism to upgrade groups = from one ciphersuite to another. Konrad announced that Britta and he are = working on a proposal and I think that=E2=80=99s great news! My understanding is that there is no dissensus around the fact that this = mechanism is now more than ever firmly on the roadmap. Naturally such a = mechanism would also allow upgrading the signature scheme if it was part = of the ciphersuite. So with that in mind we can further boil down the two choices: Proposal A: - Single signature scheme as part of the ciphersuite - We treat the signature scheme like all other crypto primitives - We use the ciphersuite upgrade mechanism for all primitives, = including signature schemes Proposal B: - Ciphersuite + LSS - We treat the signature scheme as a special crypto primitive in that = we allow individual members to no longer use unsafe schemes even before = we upgrade the whole group=E2=80=99s ciphersuite - We use the ciphersuite upgrade mechanism for all primitives, except = for the signature scheme If memory serves well, this is how far we got in the calls.=20 My opinion was (and still is) that I favor Proposal A, because I = wasn=E2=80=99t convinced we need to treat the signature scheme = differently than other crypto primitives. I much more prefer to have a = sound upgrade mechanism and put some pressure on the clients to abandon = old and unsafe ciphersuites in general. I also think that in order to = achieve ubiquitous federation we should limit choices to the minimum = that is strictly necessary. That being said, I fully acknowledge that if we look only at security, = Proposal B sounds like the better choice because broken signature = schemes might have less of an impact. If =E2=80=93 given the extra = context mentioned above =E2=80=93 people feel we absolutely want this = extra security potentially at the expense of interoperability I won=E2=80=99= t stand in the way. I just wanted to make sure everyone is aware of what = has been discussed previously before we resort to counting votes. Raphael > On 28 Feb 2020, at 13:18, Hale, Britta (CIV) = wrote: >=20 > This description provides a good, succinct outline of the two options = with respect to a usability comparison. I think that we now are in a = decent state of clarity regarding both how both alternatives would work = in practice (thanks to Raphael) and how the security of the alternatives = line up (extrapolated from the previous alternative of full signature = scheme choice flexibility).=20 >=20 > Consequently, both options appear to be well understood, so I do not = believe that there is any argument there - if anyone does not understand = either alternative then it can be clarified. >=20 > - We have a decent view of security concerns on this issue, as have = been voiced by several people (4 strong votes for option B). > - The interop concerns are limited and mostly in the federated = environment (2 strong votes for option A). > - No one has voiced efficiency concerns.=20 > Any one of these is a decent reason too choose one alternative over = another. Having an open PR is not.=20 >=20 > We all want to make progress, have this decided, and move on. We = should do it correctly. It seems ill-advised to back track and bypass = where we are at in consensus. >=20 >=20 > Britta >=20 >=20 > Get Outlook for Android > From: Raphael Robert > Sent: Friday, February 28, 2020 12:34:55 PM > To: Hale, Britta (CIV) > Cc: Karthik Bhargavan ; Benjamin = Beurdouche ; Cas Cremers = ; ML Messaging Layer Security ; = Konrad Kohbrok > Subject: Re: [MLS] confirming cipher suites decisions > =20 > If we put aside the strategic considerations for a minute, I think the = two proposals boil down to the following: >=20 > Proposal A (the current one): >=20 > - Ciphersuites contain a signature scheme > - The group creator picks a ciphersuite upon group creation > - The creator MUST only add members to the group that advertise the = ciphersuite in their CIKs > - The same rule applies to any AddProposal in the future > - The ciphersuite is explicitly mentioned in the Welcome message > - Members MUST only use the signature scheme of the ciphersuite to = sign messages >=20 > Proposal B (as proposed by Britta et al.): >=20 > - Ciphersuites do not contain a signature scheme > - The group creator picks a ciphersuite upon group creation > - The group creator picks a list of signature schemes (LSS) > - The creator MUST only add members to the group that advertise the = ciphersuite in their CIKs AND all elements of the LSS > - The same rule applies to any AddProposal in the future > - The ciphersuite AND the LSS are explicitly mentioned in the Welcome = message > - Members MUST only use the signature schemes that are part of the = LSS to sign messages >=20 > In order to make progress, I would like to propose that we move = forward with the current proposal simply because it is well understood = and fully specified. However, we add the following two open issues to = the protocol draft: >=20 > OPEN ISSUE: Security could be improved by allowing more flexibility = with signatures schemes. If a signature scheme becomes insecure over = time, members could be given the choice of choosing a more secure = signature scheme as long at there is a guarantee that all other members = are able to verify signatures under that new scheme. >=20 > OPEN ISSUE: Crypto primitives of the chosen ciphersuite could become = insecure overtime and jeopardize the security of the whole group. Since = TreeKEM doesn=E2=80=99t support mixing different DHKEM algorithms and = different symmetric encryption algorithms, we need a way to upgrade an = existing group to a new and more secure ciphersuite. >=20 > This would give us some more time to work on the open issues and come = up with fully fleshed out proposals that we can discuss and ultimately = all agree with. >=20 > Would this approach be acceptable to everyone? >=20 > Raphael >=20 >=20 >> On 28 Feb 2020, at 08:21, Hale, Britta (CIV) > wrote: >>=20 >> In terms of negotiation, I think we can closely correlate the issues = and practical ramifications in choosing a signature scheme list with the = ciphersuite negotiation that already takes place. >> Let us assume that every member would not only have a list of = supported ciphersuites in their CIK, but also of signature schemes. The = action of the group creator is then comparable in the following a/b = cases for ciphersuites/signature schemes: >> =20 >> The group creator wants to ensure any newcomer can join the group: >> The group creator chooses the MTI ciphersuite. >> The group creator chooses the MTI as the single element in the set of = possible signatures. >> =20 >> The group creator wants more control and is not particularly = concerned about newcomers in the long-term: >> The group creator chooses a non-MTI ciphersuite from the initial = group members=E2=80=99 lists. >> The group creator chooses a subset of initial group members=E2=80=99 = supported algorithms (which may or may not include the MTI). >> For the sake of argument, consider the following alternative to b: >> The group creator chooses a single non-MTI signature scheme. >> =20 >> The issues for newcomers in case 2b is not very different from 2c = (which is ultimately the case if we only support one scheme). Basically, = the newcomer supports the scheme/set of schemes or he does not. In 2a, = 2b, and 2c, algorithms are dictated by the set of initial members, so we = are not looking at a significant usability difference there. >> =20 >> For choosing the signature scheme list, any proper subset of the = intersection of the initial group members=E2=80=99 list would be = possible (hence why we have freedom to choose {MTI} in case 1b). = However, we could make it simple and use the actual intersection.=20 >> =20 >> As far as lists changing over time: in terms of what a member can = support the answer is an affirmative. In the same way the supported = ciphersuites can change over time, the supported signature schemes can = as well. However, in terms of what is used in the group, this should not = change: once fixed at group initiation the list is static for the = lifetime of the group. Once a member has chosen a signature scheme from = the list, the choice is static for the lifetime of the group. The group = should thus not be adaptable to changes in the offered algorithms of the = CIKs. >> =20 >> Britta >> =20 >> =20 >> =20 >> From: Karthik Bhargavan > >> Date: Friday, February 28, 2020 at 6:55 AM >> To: Raphael Robert > >> Cc: "Hale, Britta (CIV)" >, Benjamin Beurdouche = >, = Cas Cremers >, ML = Messaging Layer Security >, Konrad = Kohbrok > >> Subject: Re: [MLS] confirming cipher suites decisions >> =20 >> I am not sure about the practical ramifications of groups where = members use different algorithms. >> =20 >> Still, I think it is feasible to eventually have a design where the = group creator proposes a set of algorithms as =E2=80=9Cmust implement=E2=80= =9D for the group. >> Each new member must support (i.e. implement) =E2=80=9Call=E2=80=9D = the algorithms in this list in order to join the group. >> However, the member has the option to use whichever supported = algorithm she prefers for messages she sends. >> =20 >> While all of this is a reasonable long-term goal, perhaps we should = start with a version where the creator only chooses one algorithm in = each category, leaving no choice to the members. >> We can document this choice as a future extension point, and change = it as we understand the federation scenario and deployment constraints a = bit better? >> =20 >> Best, >> Karthik >> =20 >>=20 >>=20 >>> On 27 Feb 2020, at 19:02, Raphael Robert > wrote: >>> =20 >>> I agree with what Karthik said, and I think that that was the = underlying assumption all along (at east for me). The negotiation has to = happen ahead of time, namely when >>> =20 >>> - (1) an existing member proposes to add a new member, or when >>> - (2) an external party proposes to add a new member. >>> =20 >>> In the current proposal with a fixed signature per group the = decision taking is rather simple: If the new member advertises support = for the group's ciphersuite in their CIKs, they can be added to the = group. >>> =20 >>> I would like to see the decision taking fleshed out for the = alternative approach that supports multiple signatures.=20 >>> We need to make sure that members can verify signatures, which means = we need a list of acceptable signature algorithms that every member = agrees upon before a new member is added. Signature algorithms can be = advertised in another extension in CIKs, but it is not entirely clear to = me how clients agree on what the list of acceptable signatures is. Would = it be the lowest common denominator, meaning the intersection of the = algorithms advertised in the CIKs? If so, it means the list gets largely = determined by the early joiners. Also, can the list change over time? = That would be contrary to the idea that all negotiations should happen = ahead of time. >>> There might an easy solution here, I just don=E2=80=99t see it right = now. >>> =20 >>> Raphael=20 >>>=20 >>>=20 >>>> On 27 Feb 2020, at 12:50, Hale, Britta (CIV) > wrote: >>>> =20 >>>> Benjamin,=20 >>>> =20 >>>> The point of comparison with TLS is that interop is significantly = less of an issue when everyone in the group is using the same client = program. >>>> =20 >>>> In terms of interop, your concerns become a discussion point mainly = in the federation case =E2=80=93 and that is an important case that we = should plan for. But, as I said and you re-iterated, if the use case = really expects interop issues from allowing choice, then nothing = prevents the selection of a single scheme for the set of allowable = schemes. >>>> =20 >>>> As to the reasons behind allowing multiple algorithms, the document = on the mailinglist has already outlined several =E2=80=93 these are = security reasons for supporting individual algorithms. The interop = objections fall on the usability side, so the current discussion is = really about usability vs. security concerns. However, at the = intersection of these two options is the idea of allowing a set of = possible algorithms as Karthik suggests. This is a good compromise. >>>> =20 >>>> I would definitely not suggest that you consider multiple MTIs at = this stage. If that is something you want, it is best to raise it as a = separate issue. >>>> =20 >>>> --- >>>> =20 >>>> Britta >>>> =20 >>>> =20 >>>> From: Benjamin Beurdouche > >>>> Date: Thursday, February 27, 2020 at 11:48 AM >>>> To: "Hale, Britta (CIV)" > >>>> Cc: Cas Cremers >, Karthikeyan Bhargavan = >, ML Messaging Layer Security = >, Konrad Kohbrok = > >>>> Subject: Re: [MLS] confirming cipher suites decisions >>>> =20 >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>>> On 27 Feb 2020, at 11:47, Benjamin Beurdouche = > = wrote: >>>>> =20 >>>>> Hi Britta, >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 27 Feb 2020, at 10:57, Hale, Britta (CIV) > wrote: >>>>>> =20 >>>>>> Benjamin, >>>>>> =20 >>>>>> The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist. >>>>> =20 >>>>> Yes exactly, and I think two-party short lived connections for TLS = are easier to handle >>>>> than will be the long-lived multi-party connections of MLS. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> As has been stated in the working group as a supporting argument = to many changes over the different drafts, within the messaging/MLS = space we are looking at significantly more client-specific control. >>>>> =20 >>>>> Yes, and we keep being careful that it is the case when writing = the drafts, >>>>> but this doesn=E2=80=99t mean that we should be willing to risk = interoperability. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI. >>>>> =20 >>>>> I think at reverse, if you are willing to break interop, you = should be selecting something >>>> =20 >>>> S/should be selecting/can select/ >>>>=20 >>>>=20 >>>>=20 >>>>> else than the MTI when creating the group. And again, in what I = say, nothing prevents >>>>> you to pick the NIST ciphersuite for compliance and use only that. >>>>> But I don=E2=80=99t see the interest of mixing algs and put at = risk implementations and interoperability. >>>>> =20 >>>>> Out of curiosity, where you somehow arguing for multiple MTIs here = ? >>>>> =20 >>>>> B. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_D11AE6E7-5B4E-4C6D-8BA6-A69201A5C735 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = for one feel some further clarification on the context is needed, = because the posts on the mailing list don=E2=80=99t fully reflect what = we discussed extensively during the virtual interim calls and some = nuances got lost.
First of all I think there was full = consensus on the fact that degradation of the security of crypto = primitives is something we deeply care about, because degradation = jeopardizes the security properties of the group and an attacker could = use it for downgrade attacks. The dissensus arose around the question on = how exactly we want to address degradation.
In = general, any of the crypto primitives in the ciphersuites can suffer = degradation at some point. We need a sound mechanism to upgrade groups = from one ciphersuite to another. Konrad announced that Britta and he are = working on a proposal and I think that=E2=80=99s great news!
My understanding is that there is no dissensus around the = fact that this mechanism is now more than ever firmly on the roadmap. = Naturally such a mechanism would also allow upgrading the signature = scheme if it was part of the ciphersuite.

So with that in mind we can further = boil down the two choices:

Proposal A:
 - Single signature = scheme as part of the ciphersuite
 - We treat = the signature scheme like all other crypto primitives
 - We use the ciphersuite upgrade mechanism for all = primitives, including signature schemes

Proposal B:
 - = Ciphersuite + LSS
 - We treat the signature = scheme as a special crypto primitive in that we allow individual members = to no longer use unsafe schemes even before we upgrade the whole = group=E2=80=99s ciphersuite
 - We use the = ciphersuite upgrade mechanism for all primitives, except for the = signature scheme

If memory serves well, this is how far we got in the = calls. 

My = opinion was (and still is) that I favor Proposal A, because I wasn=E2=80=99= t convinced we need to treat the signature scheme differently than other = crypto primitives. I much more prefer to have a sound upgrade mechanism = and put some pressure on the clients to abandon old and unsafe = ciphersuites in general. I also think that in order to achieve = ubiquitous federation we should limit choices to the minimum that is = strictly necessary.

That being said, I fully acknowledge that if we look only at = security, Proposal B sounds like the better choice because broken = signature schemes might have less of an impact. If =E2=80=93 given the = extra context mentioned above =E2=80=93 people feel we absolutely want = this extra security potentially at the expense of interoperability I = won=E2=80=99t stand in the way. I just wanted to make sure everyone is = aware of what has been discussed previously before we resort to counting = votes.

Raphael


On 28 = Feb 2020, at 13:18, Hale, Britta (CIV) <britta.hale@nps.edu>= wrote:

This description provides a good, succinct outline of the two options = with respect to a usability comparison. I think that we now are in a = decent state of clarity regarding both how both alternatives would work = in practice (thanks to Raphael) and how the security of the alternatives line up (extrapolated from the previous alternative = of full signature scheme choice flexibility).

Consequently, both options appear to be well understood, so I do not = believe that there is any argument there - if anyone does not understand = either alternative then it can be clarified.

- We have a decent view of security concerns on this issue, as have been = voiced by several people (4 strong votes for option B).
- The interop concerns are limited and mostly in the federated = environment (2 strong votes for option A).
- No one has voiced efficiency concerns.
Any one of these is a decent reason too choose one alternative over = another. Having an open PR is not.

We all want to make progress, have this decided, and move on. We should = do it correctly. It seems ill-advised to back track and bypass where we = are at in consensus.


Britta


Get Outlook for = Android

From: = Raphael Robert <raphael@wire.com>
Sent: Friday, February 28, 2020 12:34:55 PM
To: Hale, Britta (CIV) <britta.hale@nps.edu>
Cc: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>; Benjamin Beurdouche = <benjamin.beurdouche@inria.fr>; Cas Cremers <cas.cremers@gmail.com>; ML Messaging Layer Security = <mls@ietf.org>; = Konrad Kohbrok <Konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming cipher suites = decisions
 
If we put aside the strategic = considerations for a minute, I think the two proposals boil down to the = following:

Proposal A (the current one):

 - Ciphersuites contain a signature scheme
 - The group creator picks a ciphersuite upon group = creation
 - The creator MUST only add members to the group = that advertise the ciphersuite in their CIKs
 - The same rule applies to any AddProposal in the = future
 - The ciphersuite is explicitly mentioned in the = Welcome message
 - Members MUST only use the signature scheme of = the ciphersuite to sign messages

Proposal B (as proposed by Britta et al.):

 - Ciphersuites do not contain a signature = scheme
 - The group creator picks a ciphersuite upon = group creation
 - The group creator picks a list of signature = schemes (LSS)
 - The creator MUST only add members to the = group that advertise the ciphersuite in their CIKs AND all elements of = the LSS
 - The same rule applies to any AddProposal in the = future
 - The ciphersuite AND the LSS are explicitly = mentioned in the Welcome message
 - Members MUST only use the signature schemes that = are part of the LSS to sign messages

In order to make progress, I would like to propose that = we move forward with the current proposal simply because it is well = understood and fully specified. However, we add the following two open = issues to the protocol draft:

OPEN ISSUE: Security could be improved by allowing more = flexibility with signatures schemes. If a signature scheme becomes = insecure over time, members could be given the choice of choosing a more = secure signature scheme as long at there is a guarantee that all other members are able to verify signatures under that new = scheme.

OPEN ISSUE: Crypto primitives of the chosen ciphersuite = could become insecure overtime and jeopardize the security of the whole = group. Since TreeKEM doesn=E2=80=99t support mixing different DHKEM = algorithms and different symmetric encryption algorithms, we need a way to upgrade an existing group to a new and more secure = ciphersuite.

This would give us some more time to work on the open = issues and come up with fully fleshed out proposals that we can discuss = and ultimately all agree with.

Would this approach be acceptable to everyone?

Raphael


On 28 Feb 2020, at 08:21, Hale, Britta (CIV) <britta.hale@nps.edu>= wrote:

In terms of negotiation, I think we can = closely correlate the issues and practical ramifications in choosing a = signature scheme list with the ciphersuite negotiation that already = takes place.
Let us assume that every member would not = only have a list of supported ciphersuites in their CIK, but also of = signature schemes. The action of the group creator is then comparable in = the following a/b cases for ciphersuites/signature schemes:
 
  1. The group creator wants to ensure any newcomer can join the = group:
    1. The group creator chooses the MTI ciphersuite.
    2. The group creator chooses the MTI as the single element in the set of = possible signatures.
 
  1. The group creator wants more control and is not particularly concerned = about newcomers in the long-term:
    1. The group creator chooses a non-MTI ciphersuite from the initial group = members=E2=80=99 lists.
    2. The group creator chooses a subset of initial group members=E2=80=99 = supported algorithms (which may or may not include the MTI).
For the sake of argument, consider the = following alternative to b:
    1. The group creator chooses a single non-MTI signature scheme.
 
The issues for newcomers in case 2b is not = very different from 2c (which is ultimately the case if we only support = one scheme). Basically, the newcomer supports the scheme/set of schemes = or he does not. In 2a, 2b, and 2c, algorithms are dictated by the set of initial members, so we are not looking at a = significant usability difference there.
 
For choosing the signature scheme list, any = proper subset of the intersection of the initial group members=E2=80=99 = list would be possible (hence why we have freedom to choose {MTI} in = case 1b). However, we could make it simple and use the actual intersection. 
 
As far as lists changing over time: in terms = of what a member can support the answer is an affirmative. In the same = way the supported ciphersuites can change over time, the supported = signature schemes can as well. However, in terms of what is used in the group, this should not change: once fixed at group = initiation the list is static for the lifetime of the group. Once a = member has chosen a signature scheme from the list, the choice is static = for the lifetime of the group. The group should thus not be adaptable to changes in the offered algorithms of the = CIKs.
 
Britta
 
 
 
From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
Date: Friday, February 28, = 2020 at 6:55 AM
To: Raphael Robert <raphael@wire.com>
Cc: "Hale, Britta (CIV)" = <britta.hale@nps.edu>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>, Cas Cremers <cas.cremers@gmail.com>, ML Messaging Layer Security = <mls@ietf.org>, = Konrad Kohbrok <Konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming = cipher suites decisions
 
I am not sure about the practical ramifications of groups where members = use different algorithms.
 
Still, I think it is feasible to eventually have a design where the = group creator proposes a set of algorithms as =E2=80=9Cmust implement=E2=80= =9D for the group.
Each new member must support (i.e. implement) =E2=80=9Call=E2=80=9D the = algorithms in this list in order to join the group.
However, the member has the option to use whichever supported algorithm = she prefers for messages she sends.
 
While all of this is a reasonable long-term goal, perhaps we should = start with a version where the creator only chooses one algorithm in = each category, leaving no choice to the members.
We can document this choice as a future extension point, and change it = as we understand the federation scenario and deployment constraints a = bit better?
 
Best,
Karthik
 


On 27 Feb 2020, at 19:02, Raphael Robert <raphael@wire.com> wrote:
 
I agree with what Karthik said, and I think that that was the underlying = assumption all along (at east for me). The negotiation has to happen = ahead of time, namely when
 
 - (1) an existing member proposes to add a new member, or = when
 - (2) an external party proposes to add a new member.
 
In the current proposal with a fixed signature per group the decision = taking is rather simple: If the new member advertises support for the = group's ciphersuite in their CIKs, they can be added to the group.
 
I would like to see the decision taking fleshed out for the alternative = approach that supports multiple signatures. 
We need to make sure that members can verify signatures, which means we = need a list of acceptable signature algorithms that every member agrees = upon before a new member is added. Signature algorithms can be = advertised in another extension in CIKs, but it is not entirely clear to me how clients agree on what the list of = acceptable signatures is. Would it be the lowest common denominator, = meaning the intersection of the algorithms advertised in the CIKs? If = so, it means the list gets largely determined by the early joiners. Also, can the list change over time? That would be contrary to = the idea that all negotiations should happen ahead of time.
There might an easy solution here, I just don=E2=80=99t see it right = now.
 
Raphael 


On 27 Feb 2020, at 12:50, Hale, Britta (CIV) <britta.hale@nps.edu> wrote:
 
Benjamin, 
 
The point of comparison with TLS is that interop is significantly less = of an issue when everyone in the group is using the same client = program.
 
In terms of interop, your concerns become a discussion point mainly in = the federation case =E2=80=93 and that is an important case that we = should plan for. But, as I said and you re-iterated, if the use case = really expects interop issues from allowing choice, then nothing prevents the selection of a single scheme for the set of = allowable schemes.
 
As to the reasons behind allowing multiple algorithms, the document on = the mailinglist has already outlined several =E2=80=93 these are = security reasons for supporting individual algorithms. The interop = objections fall on the usability side, so the current discussion is really about usability vs. security concerns. However, at the = intersection of these two options is the idea of allowing a set of = possible algorithms as Karthik suggests. This is a good = compromise.
 
I would definitely not suggest that you consider multiple MTIs at this = stage. If that is something you want, it is best to raise it as a = separate issue.
 
---
 
Britta
 
 
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Date: Thursday, February = 27, 2020 at 11:48 AM
To: "Hale, Britta (CIV)" = <britta.hale@nps.edu>
Cc: Cas Cremers <cas.cremers@gmail.com>, Karthikeyan = Bhargavan <karthikeyan.bhargavan@inria.fr>, ML Messaging Layer Security <mls@ietf.org>, Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Subject: Re: [MLS] confirming = cipher suites decisions
 
 



On 27 Feb 2020, at 11:47, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> = wrote:
 
Hi Britta,



On 27 Feb 2020, at 10:57, Hale, Britta (CIV) <britta.hale@nps.edu> wrote:
 
Benjamin,
 
The issues you describe are primarily TLS-type problems, where = uncontrolled, large-scale agility and interop issues exist.
 
Yes exactly, and I think two-party short lived connections for TLS are = easier to handle
than will be the long-lived multi-party connections of MLS.



As has been stated in the working group as a supporting argument to many = changes over the different drafts, within the messaging/MLS space we are = looking at significantly more client-specific control.
 
Yes, and we keep being careful that it is the case when writing the = drafts,
but this doesn=E2=80=99t mean that we should be willing to risk = interoperability.



It is not unreasonable for a newcomer to support a selection of = signature schemes. If the group creator really wants full interop, they = can always define the set of available schemes to consist only of the = MTI.
 
I think at reverse, if you are willing to break interop, you should be = selecting something
 
S/should be selecting/can select/



else than the MTI when creating the group. And again, in what I say, = nothing prevents
you to pick the NIST ciphersuite for compliance and use only that.
But I don=E2=80=99t see the interest of mixing algs and put at risk = implementations and interoperability.
 
Out of curiosity, where you somehow arguing for multiple MTIs here = ?
 
B.



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


= --Apple-Mail=_D11AE6E7-5B4E-4C6D-8BA6-A69201A5C735-- From nobody Fri Feb 28 11:51:10 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF033A1CD5 for ; Fri, 28 Feb 2020 11:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fb.com header.b=HpR1G0cV; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=IccEedQK 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 W4hPU12wiE2O for ; Fri, 28 Feb 2020 11:51:03 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5A43A1CD1 for ; Fri, 28 Feb 2020 11:51:03 -0800 (PST) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01SJdIwi023639; Fri, 28 Feb 2020 11:50:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=resszYaENdT8llZB8JHanZLQLGFVu9oINygyRVJovck=; b=HpR1G0cVOcEeWhYYIkbLO4VHaYUo7niJQc7tnSNIG5i6hW1FpKTbjXbj0s6ZsmrQxwZZ wyhcykjNa7Ijb/7Cz+5kQFFrRYe8IB7+iPvrHPE/ZMGGVcqMMK+r0nty5zHc/NeXj7/Q PQ90ne5DtBu3aCGidWRvlyp7AYV/jZIcmFI= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2yepurw74x-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 28 Feb 2020 11:50:49 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Fri, 28 Feb 2020 11:50:30 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ga+WgJmXZ07903/MvRtbeI1066XQVLngJZJajf95LKO4Yxz/plC3Wxo7F0eVWyAAKara60J6fplj65f/hskg5DsJmzGlH681Vk++qCUFLbFeWrvCq5Ddt5UCVlV96ntKKR60PtBnVLnuUEK85271goX0k99o59xwbBBsQDgR3+aJ2I6Yjj1GsdORWp6U0heNWpeSBTG0YHR/DUfm65qhef618VpQlt8WsAfzsk+tpIzagvwJBuuFiQ+i57xmo05zr8HURL5OsZ6CCYGyBya05MowE4xOn7HY/egFFrxyZ2jdTnJDy3duXfIEYmzPndMypxTjetaM6KTkO1PDxRt+HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=resszYaENdT8llZB8JHanZLQLGFVu9oINygyRVJovck=; b=QwxykJC2/fx1Ddtl756Gn044MZkVMgwVv31CEy2BrVXGKOK8EGtgwz+u1/mhjVa0oIRXGSTo/xPh7VqNKQDQpZw/BdUECNha9KRqHQ/bjgtbOmpH6d1vfWuoctZIFq+opRyyOLe/nFRldgall2qL97gfYAgl9aFUY9fhd7mY6h29fNUjsE8xhIEbuac1IsvVxONbT9FL+YRkofX7ymscrpbpdFOr6k/VktQycDHuxVVPsttXANjR4/u6GyMddp+171BWlaGOVPbTTj5nwdsh/7SHJX7fN5sJsEaMcMwaMc2r0S1gOpw6dudDE4yYpfc4u1VZbbcwGPJ1qL2M2Oe+aQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=resszYaENdT8llZB8JHanZLQLGFVu9oINygyRVJovck=; b=IccEedQKptPg6UhgwwzAJnF0C0Os2LTTKwmga/+cml4ox0MCW+mDj25yCb/2LombheclZlzVBivEJ8LX2noYELor2AmQgpAysSRzzpGmsEQ4soUh5+aGregxYpgiqAuB6t+IgxQbMByyqdq3YEzFwBiWy7fNqoU8d6F8gF0Vaa4= Received: from MWHPR15MB1152.namprd15.prod.outlook.com (2603:10b6:320:25::16) by MWHPR15MB1885.namprd15.prod.outlook.com (2603:10b6:301:4d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 28 Feb 2020 19:50:29 +0000 Received: from MWHPR15MB1152.namprd15.prod.outlook.com ([fe80::8447:952e:7aac:9fbd]) by MWHPR15MB1152.namprd15.prod.outlook.com ([fe80::8447:952e:7aac:9fbd%9]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 19:50:29 +0000 From: Jon Millican To: Raphael Robert , "Hale, Britta (CIV)" CC: Karthik Bhargavan , Cas Cremers , Benjamin Beurdouche , ML Messaging Layer Security , Konrad Kohbrok Thread-Topic: [MLS] confirming cipher suites decisions Thread-Index: AQHV3QeoYov+2cXGtE2YuKiX5RJmUqgXwNwAgAmxT4CAAKn3gIAKMAGAgAALVYCAAXH8AIAAIHiAgAAGsoCAAA3FAIAA4SKAgAAPLQCAAA3EAIAAAGcAgAARK4CAAGgAgIAAxxYAgAAYWACAAEasgIAADBgAgABhFoD//5crAA== Date: Fri, 28 Feb 2020 19:50:29 +0000 Message-ID: <109AB2E0-6BD3-4ADD-8A94-6FEF9AEF9C48@fb.com> References: <06d1ebbf-2163-02bc-1cf5-4dc3633ce64a@datashrine.de> <0BE1075B-081C-4D44-82CB-56044BCAC0CC@sn3rd.com> <15F5F403-B3DD-4CE9-B47E-FA5D04BBBDC6@sn3rd.com> <83F1DE47-1230-4118-81C6-E065F5049995@inria.fr> <619cf3d1-eb09-485c-595f-3bfbb4b175b5@gmail.com> <463B50F6-67FF-4E40-8CAE-14D272CDD965@inria.fr> <5A69070B-BF2F-4A91-939F-0BD473F3FB0A@inria.fr> <4AEB16AA-BF20-4238-9B6E-2C0BD7760AC2@inria.fr> <77B4B842-16AF-40C0-BFBB-B58420AA89AA@inria.fr> <57308ED1-29F4-48D7-8AB9-D88AC49803C5@nps.edu> <3DDF2660-3A10-4C58-8857-C24EFF4DC768@inria.fr> <3083F808-7A92-443C-BF7C-762C2D2381B0@nps.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:500::5:c521] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 60ee3a4c-5110-42c7-f992-08d7bc87769c x-ms-traffictypediagnostic: MWHPR15MB1885: x-microsoft-antispam-prvs: x-fb-source: Internal x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(39860400002)(136003)(189003)(199004)(81166006)(478600001)(186003)(66946007)(8676002)(66476007)(66556008)(81156014)(2616005)(76116006)(110136005)(71200400001)(86362001)(53546011)(4326008)(6506007)(54906003)(45080400002)(36756003)(316002)(33656002)(966005)(8936002)(5660300002)(6512007)(64756008)(2906002)(6486002)(66446008)(30864003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1885; H:MWHPR15MB1152.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c4+hMwurHqGa79HreszEI6snsT7ZbnuUFJNUAmXo+nYTelKSZVQMOQz+JxsX7apgmPZmCtm5PD9AcZdEjhT9o9P7AcZCaKlLfOigq9NBotDvy2KnNnpbl72g1W1/vxaeOjutwNVayxnKkjvMogR4454d79s5lOZ20o6OyuGnJE431Ga0WVGlrO/aVh5uswUssFuT63zYgXq7tIjuxR4NyczF4n8RYzJY09E5pobHOBF4NCb9ROk1sXb8pPJyyPeXmXzZI9+jdSNhIaRPRbac4HF8R+8RDtLQHwlXuwZmDq2du+kioDm3z3DHZ7dKkwRwj8nmRvv4qkc6dy3cxfDRfEpB7RRWfY2dWaju+nkKXXU/Ap0f/F7GDtgTPl00J6fNhtuaIcQEOzz5bzc/LtClVW+wPX7IIQEDEsJM+kAfWAKH786D661OmTzpHGzkRB+aydEXXLByCQq2n9PntXs28kVNprKSWGQ6VZ1FZeoE78gqxQRvahAnig+hTLbj9FNBImQusqcKNpSseSrG/QCd+w== x-ms-exchange-antispam-messagedata: ehLHpS83zqwzt63n7w56Z3Ml7s6FTP2EycqGFWI61ucJUzW9SgS1LRe2no9tMTEPfVEPmkjwzXhSZJKU5YMsj2HSY/J/X7YmCex1UE62p+a0bCMYW3atokGPRkqbiwkjzDfZTCZVyah7WqIQ2XzVb3YQWmAW7o4B7eIndDt2tv1XDP3gyFSTeAjD2cDYQlIA x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_109AB2E06BD34ADD8A946FEF9AEF9C48fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 60ee3a4c-5110-42c7-f992-08d7bc87769c X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 19:50:29.1321 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mRGuwnb5Jbk2QJSkVhlvMnDdmGqgpPePpOsx2UbjG4CxASYg7euw9xfIJvae2MgB5LDzM+BcwHCUkvhZqO4aXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1885 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_07:2020-02-28, 2020-02-28 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 adultscore=0 spamscore=0 impostorscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002280139 X-FB-Internal: deliver Archived-At: Subject: Re: [MLS] confirming cipher suites decisions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 19:51:08 -0000 --_000_109AB2E06BD34ADD8A946FEF9AEF9C48fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJ4oCZbSBqdXN0IGNhdGNoaW5nIHVwIG9uIHRoaXMgZGlzY3Vzc2lvbi4gRnJv bSBteSBwZXJzcGVjdGl2ZSBJIGRvbuKAmXQgaGF2ZSBwYXJ0aWN1bGFybHkgc3Ryb25nIGZlZWxp bmdzIG9uIHRoZSBjaG9pY2UgaGVyZS4gSSB3b3VsZCBzYXkgdGhhdCwgdGh1cyBmYXIsIEkgaGF2 ZSBub3QgZW5jb3VudGVyZWQgY29uY2VybnMgYWJvdXQgdGhlIGxhY2sgb2YgY3J5cHRvIGFnaWxp dHkgaW4gU2lnbmFsIOKAkyB3aGljaCB3ZSB1c2UgdmVyeSB3aWRlbHkuIEZvciBsb25nLXJ1bm5p bmcgY29udmVyc2F0aW9ucyB0aG91Z2gsIEkgZGVmaW5pdGVseSBsaWtlIHRoZSBpZGVhIG9mIGFu IGFiaWxpdHkgdG8gdXBncmFkZSBjcnlwdG8gb3ZlciB0aW1lOyBhcyB3ZSBzaG91bGQgYXNzdW1l IHRoYXQgdGhyZWFkcyBjYW4gcmVtYWluIGFjdGl2ZSBmb3IgeWVhcnMuDQoNClRvIEJyaXR0YeKA mXMgcG9pbnQgYWJvdXQgbm9ib2R5IGhhdmluZyB5ZXQgcmFpc2VkIHBlcmZvcm1hbmNlIGNvbmNl cm5zOyB0aGlzIHdhcyBhY3R1YWxseSBvbmUgb2YgbXkgcHJpbWFyeSBjb25jZXJucyByZWFkaW5n IHRocm91Z2ggdGhlIHRocmVhZC4gSSByZWNhbGwgcmVhZGluZyBhYm91dCBzb21lIGV4cGVyaW1l bnRzIOKAkyBJIHRoaW5rIGJ5IEdvb2dsZSDigJMgd2hlcmUgdGhleSBpbXByb3ZlZCBUTFMgcGVy Zm9ybWFuY2UgZnJvbSBieSBjaG9vc2luZyBjaXBoZXIgc3VpdGVzIHRvIGJlIHRob3NlIHdoaWNo IHdlcmUgbW9zdCBlZmZpY2llbnQgb24gY2xpZW50IGRldmljZXMuIElmIHdlIGFyZSB0byByb2xs IG91dCBNTFMgZ2xvYmFsbHksIHRvIGRldmljZXMgZnJvbSBoaWdoLWVuZCBpUGhvbmVzIHdpdGgg Z29vZCBuZXR3b3JrIGJhbmR3aWR0aCwgMTAteWVhciBvbGQgQW5kcm9pZCBwaG9uZXMgd2l0aCBl eHBlbnNpdmUgYW5kIHNsb3cgY29ubmVjdGlvbnMsIGFuZCBhbHNvIGFjcm9zcyB3ZWIgYnJvd3Nl cnMg4oCTIEkgY2FuIGltYWdpbmUgdGhhdCB0aGVyZSBtYXkgYmUgc2l0dWF0aW9ucyB3aGVyZSB0 aGUgcGVyZm9ybWFuY2UgY2hhcmFjdGVyaXN0aWNzIG9mIGNyeXB0byBjaG9pY2VzIG1lYW5pbmdm dWxseSB2YXJ5IGFsb25nIHZhcmlvdXMgYXhlcy4gSW4gdGhpcyBzZW5zZSwgSSB3b3VsZCBwb3Rl bnRpYWxseSBiZSBzbGlnaHRseSB0ZW1wdGVkIHRvIGxlYW4gdG93YXJkcyBhbiBvcHRpb24gd2hl cmUgZXZlcnkgY2xpZW50IGNhbiB1c2UgdGhlaXIgb3duIGNob2ljZSBvZiBjcnlwdG87IHN1Ympl Y3QgdG8gYWxsIGNsaWVudHMgaW4gYSBjaGF0IGFjdHVhbGx5IHN1cHBvcnRpbmcgdGhpcyBjaG9p Y2UgKGVuYWJsaW5nIGRlcHJlY2F0aW9uIGZvciBzZWN1cml0eSBwdXJwb3NlcywgYmVjYXVzZSB0 aGUgbW9zdCB1cC10by1kYXRlIGNsaWVudCBpcyBhYmxlIHRvIHJlbW92ZSBzdXBwb3J0IGZvciBu ZXdseS1pbnNlY3VyZSBvcHRpb25zIGFuZCBmb3JjZSB0aGUgd2hvbGUgZ3JvdXAgYXdheSBmcm9t IHRoZW0pLg0KDQpIb3dldmVyLCB0aGF0IHNhaWQsIEnigJltIGNvbnNjaW91cyBvZiB0aGUgY29t cGxleGl0eSBvZiB3aGF0IHdl4oCZcmUgYnVpbGRpbmcgYWxyZWFkeTsgYW5kIG9mIHRoZSBuZWVk IGZvciBwcm9ncmVzcy4gR2l2ZW4gdGhlIGV4cGVyaWVuY2UgdGh1cyBmYXIgd2l0aCBTaWduYWws IEnigJltIGFsc28gdGVtcHRlZCB0byBsZWFuIHRvd2FyZHMgUHJvcG9zYWwgQSBpbiB0aGUgbmFt ZSBvZiBncmVhdGVyIHNpbXBsaWNpdHkuIEFzIGhhcyBiZWVuIG1lbnRpb25lZCBtdWx0aXBsZSB0 aW1lcywgd2UgY2FuIGFsd2F5cyBpdGVyYXRlIG9uIHRoaXMgaW4gZnV0dXJlIOKAkyBhbmQgd2Ug d291bGQgbGlrZWx5IGFscmVhZHkgZ2V0IG1vc3Qgb2YgdGhlIGJlbmVmaXRzIGZyb20gYSB3aG9s ZS1ncm91cC11cGdyYWRlIG1lY2hhbmlzbS4NCg0KSm9uDQoNCkZyb206IE1MUyA8bWxzLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSYXBoYWVsIFJvYmVydCA8cmFwaGFlbD00MHdpcmUu Y29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogRnJpZGF5LCAyOCBGZWJydWFyeSAyMDIwIGF0IDEw OjA3DQpUbzogIkhhbGUsIEJyaXR0YSAoQ0lWKSIgPGJyaXR0YS5oYWxlQG5wcy5lZHU+DQpDYzog S2FydGhpayBCaGFyZ2F2YW4gPGthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcj4sIENhcyBD cmVtZXJzIDxjYXMuY3JlbWVyc0BnbWFpbC5jb20+LCBCZW5qYW1pbiBCZXVyZG91Y2hlIDxiZW5q YW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPiwgTUwgTWVzc2FnaW5nIExheWVyIFNlY3VyaXR5IDxt bHNAaWV0Zi5vcmc+LCBLb25yYWQgS29oYnJvayA8S29ucmFkLmtvaGJyb2tAZGF0YXNocmluZS5k ZT4NClN1YmplY3Q6IFJlOiBbTUxTXSBjb25maXJtaW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25z DQoNCkkgZm9yIG9uZSBmZWVsIHNvbWUgZnVydGhlciBjbGFyaWZpY2F0aW9uIG9uIHRoZSBjb250 ZXh0IGlzIG5lZWRlZCwgYmVjYXVzZSB0aGUgcG9zdHMgb24gdGhlIG1haWxpbmcgbGlzdCBkb27i gJl0IGZ1bGx5IHJlZmxlY3Qgd2hhdCB3ZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgZHVyaW5nIHRo ZSB2aXJ0dWFsIGludGVyaW0gY2FsbHMgYW5kIHNvbWUgbnVhbmNlcyBnb3QgbG9zdC4NCkZpcnN0 IG9mIGFsbCBJIHRoaW5rIHRoZXJlIHdhcyBmdWxsIGNvbnNlbnN1cyBvbiB0aGUgZmFjdCB0aGF0 IGRlZ3JhZGF0aW9uIG9mIHRoZSBzZWN1cml0eSBvZiBjcnlwdG8gcHJpbWl0aXZlcyBpcyBzb21l dGhpbmcgd2UgZGVlcGx5IGNhcmUgYWJvdXQsIGJlY2F1c2UgZGVncmFkYXRpb24gamVvcGFyZGl6 ZXMgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhlIGdyb3VwIGFuZCBhbiBhdHRhY2tlciBj b3VsZCB1c2UgaXQgZm9yIGRvd25ncmFkZSBhdHRhY2tzLiBUaGUgZGlzc2Vuc3VzIGFyb3NlIGFy b3VuZCB0aGUgcXVlc3Rpb24gb24gaG93IGV4YWN0bHkgd2Ugd2FudCB0byBhZGRyZXNzIGRlZ3Jh ZGF0aW9uLg0KSW4gZ2VuZXJhbCwgYW55IG9mIHRoZSBjcnlwdG8gcHJpbWl0aXZlcyBpbiB0aGUg Y2lwaGVyc3VpdGVzIGNhbiBzdWZmZXIgZGVncmFkYXRpb24gYXQgc29tZSBwb2ludC4gV2UgbmVl ZCBhIHNvdW5kIG1lY2hhbmlzbSB0byB1cGdyYWRlIGdyb3VwcyBmcm9tIG9uZSBjaXBoZXJzdWl0 ZSB0byBhbm90aGVyLiBLb25yYWQgYW5ub3VuY2VkIHRoYXQgQnJpdHRhIGFuZCBoZSBhcmUgd29y a2luZyBvbiBhIHByb3Bvc2FsIGFuZCBJIHRoaW5rIHRoYXTigJlzIGdyZWF0IG5ld3MhDQpNeSB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlcmUgaXMgbm8gZGlzc2Vuc3VzIGFyb3VuZCB0aGUgZmFj dCB0aGF0IHRoaXMgbWVjaGFuaXNtIGlzIG5vdyBtb3JlIHRoYW4gZXZlciBmaXJtbHkgb24gdGhl IHJvYWRtYXAuIE5hdHVyYWxseSBzdWNoIGEgbWVjaGFuaXNtIHdvdWxkIGFsc28gYWxsb3cgdXBn cmFkaW5nIHRoZSBzaWduYXR1cmUgc2NoZW1lIGlmIGl0IHdhcyBwYXJ0IG9mIHRoZSBjaXBoZXJz dWl0ZS4NCg0KU28gd2l0aCB0aGF0IGluIG1pbmQgd2UgY2FuIGZ1cnRoZXIgYm9pbCBkb3duIHRo ZSB0d28gY2hvaWNlczoNCg0KUHJvcG9zYWwgQToNCiAtIFNpbmdsZSBzaWduYXR1cmUgc2NoZW1l IGFzIHBhcnQgb2YgdGhlIGNpcGhlcnN1aXRlDQogLSBXZSB0cmVhdCB0aGUgc2lnbmF0dXJlIHNj aGVtZSBsaWtlIGFsbCBvdGhlciBjcnlwdG8gcHJpbWl0aXZlcw0KIC0gV2UgdXNlIHRoZSBjaXBo ZXJzdWl0ZSB1cGdyYWRlIG1lY2hhbmlzbSBmb3IgYWxsIHByaW1pdGl2ZXMsIGluY2x1ZGluZyBz aWduYXR1cmUgc2NoZW1lcw0KDQpQcm9wb3NhbCBCOg0KIC0gQ2lwaGVyc3VpdGUgKyBMU1MNCiAt IFdlIHRyZWF0IHRoZSBzaWduYXR1cmUgc2NoZW1lIGFzIGEgc3BlY2lhbCBjcnlwdG8gcHJpbWl0 aXZlIGluIHRoYXQgd2UgYWxsb3cgaW5kaXZpZHVhbCBtZW1iZXJzIHRvIG5vIGxvbmdlciB1c2Ug dW5zYWZlIHNjaGVtZXMgZXZlbiBiZWZvcmUgd2UgdXBncmFkZSB0aGUgd2hvbGUgZ3JvdXDigJlz IGNpcGhlcnN1aXRlDQogLSBXZSB1c2UgdGhlIGNpcGhlcnN1aXRlIHVwZ3JhZGUgbWVjaGFuaXNt IGZvciBhbGwgcHJpbWl0aXZlcywgZXhjZXB0IGZvciB0aGUgc2lnbmF0dXJlIHNjaGVtZQ0KDQpJ ZiBtZW1vcnkgc2VydmVzIHdlbGwsIHRoaXMgaXMgaG93IGZhciB3ZSBnb3QgaW4gdGhlIGNhbGxz Lg0KDQpNeSBvcGluaW9uIHdhcyAoYW5kIHN0aWxsIGlzKSB0aGF0IEkgZmF2b3IgUHJvcG9zYWwg QSwgYmVjYXVzZSBJIHdhc27igJl0IGNvbnZpbmNlZCB3ZSBuZWVkIHRvIHRyZWF0IHRoZSBzaWdu YXR1cmUgc2NoZW1lIGRpZmZlcmVudGx5IHRoYW4gb3RoZXIgY3J5cHRvIHByaW1pdGl2ZXMuIEkg bXVjaCBtb3JlIHByZWZlciB0byBoYXZlIGEgc291bmQgdXBncmFkZSBtZWNoYW5pc20gYW5kIHB1 dCBzb21lIHByZXNzdXJlIG9uIHRoZSBjbGllbnRzIHRvIGFiYW5kb24gb2xkIGFuZCB1bnNhZmUg Y2lwaGVyc3VpdGVzIGluIGdlbmVyYWwuIEkgYWxzbyB0aGluayB0aGF0IGluIG9yZGVyIHRvIGFj aGlldmUgdWJpcXVpdG91cyBmZWRlcmF0aW9uIHdlIHNob3VsZCBsaW1pdCBjaG9pY2VzIHRvIHRo ZSBtaW5pbXVtIHRoYXQgaXMgc3RyaWN0bHkgbmVjZXNzYXJ5Lg0KDQpUaGF0IGJlaW5nIHNhaWQs IEkgZnVsbHkgYWNrbm93bGVkZ2UgdGhhdCBpZiB3ZSBsb29rIG9ubHkgYXQgc2VjdXJpdHksIFBy b3Bvc2FsIEIgc291bmRzIGxpa2UgdGhlIGJldHRlciBjaG9pY2UgYmVjYXVzZSBicm9rZW4gc2ln bmF0dXJlIHNjaGVtZXMgbWlnaHQgaGF2ZSBsZXNzIG9mIGFuIGltcGFjdC4gSWYg4oCTIGdpdmVu IHRoZSBleHRyYSBjb250ZXh0IG1lbnRpb25lZCBhYm92ZSDigJMgcGVvcGxlIGZlZWwgd2UgYWJz b2x1dGVseSB3YW50IHRoaXMgZXh0cmEgc2VjdXJpdHkgcG90ZW50aWFsbHkgYXQgdGhlIGV4cGVu c2Ugb2YgaW50ZXJvcGVyYWJpbGl0eSBJIHdvbuKAmXQgc3RhbmQgaW4gdGhlIHdheS4gSSBqdXN0 IHdhbnRlZCB0byBtYWtlIHN1cmUgZXZlcnlvbmUgaXMgYXdhcmUgb2Ygd2hhdCBoYXMgYmVlbiBk aXNjdXNzZWQgcHJldmlvdXNseSBiZWZvcmUgd2UgcmVzb3J0IHRvIGNvdW50aW5nIHZvdGVzLg0K DQpSYXBoYWVsDQoNCg0KDQpPbiAyOCBGZWIgMjAyMCwgYXQgMTM6MTgsIEhhbGUsIEJyaXR0YSAo Q0lWKSA8YnJpdHRhLmhhbGVAbnBzLmVkdTxtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdT4+IHdy b3RlOg0KDQpUaGlzIGRlc2NyaXB0aW9uIHByb3ZpZGVzIGEgZ29vZCwgc3VjY2luY3Qgb3V0bGlu ZSBvZiB0aGUgdHdvIG9wdGlvbnMgd2l0aCByZXNwZWN0IHRvIGEgdXNhYmlsaXR5IGNvbXBhcmlz b24uIEkgdGhpbmsgdGhhdCB3ZSBub3cgYXJlIGluIGEgZGVjZW50IHN0YXRlIG9mIGNsYXJpdHkg cmVnYXJkaW5nIGJvdGggaG93IGJvdGggYWx0ZXJuYXRpdmVzIHdvdWxkIHdvcmsgaW4gcHJhY3Rp Y2UgKHRoYW5rcyB0byBSYXBoYWVsKSBhbmQgaG93IHRoZSBzZWN1cml0eSBvZiB0aGUgYWx0ZXJu YXRpdmVzIGxpbmUgdXAgKGV4dHJhcG9sYXRlZCBmcm9tIHRoZSBwcmV2aW91cyBhbHRlcm5hdGl2 ZSBvZiBmdWxsIHNpZ25hdHVyZSBzY2hlbWUgY2hvaWNlIGZsZXhpYmlsaXR5KS4NCkNvbnNlcXVl bnRseSwgYm90aCBvcHRpb25zIGFwcGVhciB0byBiZSB3ZWxsIHVuZGVyc3Rvb2QsIHNvIEkgZG8g bm90IGJlbGlldmUgdGhhdCB0aGVyZSBpcyBhbnkgYXJndW1lbnQgdGhlcmUgLSBpZiBhbnlvbmUg ZG9lcyBub3QgdW5kZXJzdGFuZCBlaXRoZXIgYWx0ZXJuYXRpdmUgdGhlbiBpdCBjYW4gYmUgY2xh cmlmaWVkLg0KLSBXZSBoYXZlIGEgZGVjZW50IHZpZXcgb2Ygc2VjdXJpdHkgY29uY2VybnMgb24g dGhpcyBpc3N1ZSwgYXMgaGF2ZSBiZWVuIHZvaWNlZCBieSBzZXZlcmFsIHBlb3BsZSAoNCBzdHJv bmcgdm90ZXMgZm9yIG9wdGlvbiBCKS4NCi0gVGhlIGludGVyb3AgY29uY2VybnMgYXJlIGxpbWl0 ZWQgYW5kIG1vc3RseSBpbiB0aGUgZmVkZXJhdGVkIGVudmlyb25tZW50ICgyIHN0cm9uZyB2b3Rl cyBmb3Igb3B0aW9uIEEpLg0KLSBObyBvbmUgaGFzIHZvaWNlZCBlZmZpY2llbmN5IGNvbmNlcm5z Lg0KQW55IG9uZSBvZiB0aGVzZSBpcyBhIGRlY2VudCByZWFzb24gdG9vIGNob29zZSBvbmUgYWx0 ZXJuYXRpdmUgb3ZlciBhbm90aGVyLiBIYXZpbmcgYW4gb3BlbiBQUiBpcyBub3QuDQpXZSBhbGwg d2FudCB0byBtYWtlIHByb2dyZXNzLCBoYXZlIHRoaXMgZGVjaWRlZCwgYW5kIG1vdmUgb24uIFdl IHNob3VsZCBkbyBpdCBjb3JyZWN0bHkuIEl0IHNlZW1zIGlsbC1hZHZpc2VkIHRvIGJhY2sgdHJh Y2sgYW5kIGJ5cGFzcyB3aGVyZSB3ZSBhcmUgYXQgaW4gY29uc2Vuc3VzLg0KDQpCcml0dGENCg0K R2V0IE91dGxvb2sgZm9yIEFuZHJvaWQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19ha2EubXNfZ2hlaTM2JmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgz eWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT1JQzFoWlBURVVmdHVpOEhBUHRJ NVhrN3RreTM5MG5NZnlOa2ZCS2RVb1dZJnM9bXpRR21OWkFtTnFOeTdmdWpkOFJOSmc2R2czeXUx NlFCVE8yOEdBLUgyVSZlPT4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IFJhcGhhZWwgUm9iZXJ0IDxyYXBoYWVsQHdpcmUuY29tPG1haWx0bzpyYXBoYWVsQHdpcmUu Y29tPj4NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjgsIDIwMjAgMTI6MzQ6NTUgUE0NClRvOiBI YWxlLCBCcml0dGEgKENJVikgPGJyaXR0YS5oYWxlQG5wcy5lZHU8bWFpbHRvOmJyaXR0YS5oYWxl QG5wcy5lZHU+Pg0KQ2M6IEthcnRoaWsgQmhhcmdhdmFuIDxrYXJ0aGlrZXlhbi5iaGFyZ2F2YW5A aW5yaWEuZnI8bWFpbHRvOmthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcj4+OyBCZW5qYW1p biBCZXVyZG91Y2hlIDxiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPG1haWx0bzpiZW5qYW1p bi5iZXVyZG91Y2hlQGlucmlhLmZyPj47IENhcyBDcmVtZXJzIDxjYXMuY3JlbWVyc0BnbWFpbC5j b208bWFpbHRvOmNhcy5jcmVtZXJzQGdtYWlsLmNvbT4+OyBNTCBNZXNzYWdpbmcgTGF5ZXIgU2Vj dXJpdHkgPG1sc0BpZXRmLm9yZzxtYWlsdG86bWxzQGlldGYub3JnPj47IEtvbnJhZCBLb2hicm9r IDxLb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPG1haWx0bzpLb25yYWQua29oYnJva0BkYXRh c2hyaW5lLmRlPj4NClN1YmplY3Q6IFJlOiBbTUxTXSBjb25maXJtaW5nIGNpcGhlciBzdWl0ZXMg ZGVjaXNpb25zDQoNCklmIHdlIHB1dCBhc2lkZSB0aGUgc3RyYXRlZ2ljIGNvbnNpZGVyYXRpb25z IGZvciBhIG1pbnV0ZSwgSSB0aGluayB0aGUgdHdvIHByb3Bvc2FscyBib2lsIGRvd24gdG8gdGhl IGZvbGxvd2luZzoNCg0KUHJvcG9zYWwgQSAodGhlIGN1cnJlbnQgb25lKToNCg0KIC0gQ2lwaGVy c3VpdGVzIGNvbnRhaW4gYSBzaWduYXR1cmUgc2NoZW1lDQogLSBUaGUgZ3JvdXAgY3JlYXRvciBw aWNrcyBhIGNpcGhlcnN1aXRlIHVwb24gZ3JvdXAgY3JlYXRpb24NCiAtIFRoZSBjcmVhdG9yIE1V U1Qgb25seSBhZGQgbWVtYmVycyB0byB0aGUgZ3JvdXAgdGhhdCBhZHZlcnRpc2UgdGhlIGNpcGhl cnN1aXRlIGluIHRoZWlyIENJS3MNCiAtIFRoZSBzYW1lIHJ1bGUgYXBwbGllcyB0byBhbnkgQWRk UHJvcG9zYWwgaW4gdGhlIGZ1dHVyZQ0KIC0gVGhlIGNpcGhlcnN1aXRlIGlzIGV4cGxpY2l0bHkg bWVudGlvbmVkIGluIHRoZSBXZWxjb21lIG1lc3NhZ2UNCiAtIE1lbWJlcnMgTVVTVCBvbmx5IHVz ZSB0aGUgc2lnbmF0dXJlIHNjaGVtZSBvZiB0aGUgY2lwaGVyc3VpdGUgdG8gc2lnbiBtZXNzYWdl cw0KDQpQcm9wb3NhbCBCIChhcyBwcm9wb3NlZCBieSBCcml0dGEgZXQgYWwuKToNCg0KIC0gQ2lw aGVyc3VpdGVzIGRvIG5vdCBjb250YWluIGEgc2lnbmF0dXJlIHNjaGVtZQ0KIC0gVGhlIGdyb3Vw IGNyZWF0b3IgcGlja3MgYSBjaXBoZXJzdWl0ZSB1cG9uIGdyb3VwIGNyZWF0aW9uDQogLSBUaGUg Z3JvdXAgY3JlYXRvciBwaWNrcyBhIGxpc3Qgb2Ygc2lnbmF0dXJlIHNjaGVtZXMgKExTUykNCiAt IFRoZSBjcmVhdG9yIE1VU1Qgb25seSBhZGQgbWVtYmVycyB0byB0aGUgZ3JvdXAgdGhhdCBhZHZl cnRpc2UgdGhlIGNpcGhlcnN1aXRlIGluIHRoZWlyIENJS3MgQU5EIGFsbCBlbGVtZW50cyBvZiB0 aGUgTFNTDQogLSBUaGUgc2FtZSBydWxlIGFwcGxpZXMgdG8gYW55IEFkZFByb3Bvc2FsIGluIHRo ZSBmdXR1cmUNCiAtIFRoZSBjaXBoZXJzdWl0ZSBBTkQgdGhlIExTUyBhcmUgZXhwbGljaXRseSBt ZW50aW9uZWQgaW4gdGhlIFdlbGNvbWUgbWVzc2FnZQ0KIC0gTWVtYmVycyBNVVNUIG9ubHkgdXNl IHRoZSBzaWduYXR1cmUgc2NoZW1lcyB0aGF0IGFyZSBwYXJ0IG9mIHRoZSBMU1MgdG8gc2lnbiBt ZXNzYWdlcw0KDQpJbiBvcmRlciB0byBtYWtlIHByb2dyZXNzLCBJIHdvdWxkIGxpa2UgdG8gcHJv cG9zZSB0aGF0IHdlIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBjdXJyZW50IHByb3Bvc2FsIHNpbXBs eSBiZWNhdXNlIGl0IGlzIHdlbGwgdW5kZXJzdG9vZCBhbmQgZnVsbHkgc3BlY2lmaWVkLiBIb3dl dmVyLCB3ZSBhZGQgdGhlIGZvbGxvd2luZyB0d28gb3BlbiBpc3N1ZXMgdG8gdGhlIHByb3RvY29s IGRyYWZ0Og0KDQpPUEVOIElTU1VFOiBTZWN1cml0eSBjb3VsZCBiZSBpbXByb3ZlZCBieSBhbGxv d2luZyBtb3JlIGZsZXhpYmlsaXR5IHdpdGggc2lnbmF0dXJlcyBzY2hlbWVzLiBJZiBhIHNpZ25h dHVyZSBzY2hlbWUgYmVjb21lcyBpbnNlY3VyZSBvdmVyIHRpbWUsIG1lbWJlcnMgY291bGQgYmUg Z2l2ZW4gdGhlIGNob2ljZSBvZiBjaG9vc2luZyBhIG1vcmUgc2VjdXJlIHNpZ25hdHVyZSBzY2hl bWUgYXMgbG9uZyBhdCB0aGVyZSBpcyBhIGd1YXJhbnRlZSB0aGF0IGFsbCBvdGhlciBtZW1iZXJz IGFyZSBhYmxlIHRvIHZlcmlmeSBzaWduYXR1cmVzIHVuZGVyIHRoYXQgbmV3IHNjaGVtZS4NCg0K T1BFTiBJU1NVRTogQ3J5cHRvIHByaW1pdGl2ZXMgb2YgdGhlIGNob3NlbiBjaXBoZXJzdWl0ZSBj b3VsZCBiZWNvbWUgaW5zZWN1cmUgb3ZlcnRpbWUgYW5kIGplb3BhcmRpemUgdGhlIHNlY3VyaXR5 IG9mIHRoZSB3aG9sZSBncm91cC4gU2luY2UgVHJlZUtFTSBkb2VzbuKAmXQgc3VwcG9ydCBtaXhp bmcgZGlmZmVyZW50IERIS0VNIGFsZ29yaXRobXMgYW5kIGRpZmZlcmVudCBzeW1tZXRyaWMgZW5j cnlwdGlvbiBhbGdvcml0aG1zLCB3ZSBuZWVkIGEgd2F5IHRvIHVwZ3JhZGUgYW4gZXhpc3Rpbmcg Z3JvdXAgdG8gYSBuZXcgYW5kIG1vcmUgc2VjdXJlIGNpcGhlcnN1aXRlLg0KDQpUaGlzIHdvdWxk IGdpdmUgdXMgc29tZSBtb3JlIHRpbWUgdG8gd29yayBvbiB0aGUgb3BlbiBpc3N1ZXMgYW5kIGNv bWUgdXAgd2l0aCBmdWxseSBmbGVzaGVkIG91dCBwcm9wb3NhbHMgdGhhdCB3ZSBjYW4gZGlzY3Vz cyBhbmQgdWx0aW1hdGVseSBhbGwgYWdyZWUgd2l0aC4NCg0KV291bGQgdGhpcyBhcHByb2FjaCBi ZSBhY2NlcHRhYmxlIHRvIGV2ZXJ5b25lPw0KDQpSYXBoYWVsDQoNCg0KDQpPbiAyOCBGZWIgMjAy MCwgYXQgMDg6MjEsIEhhbGUsIEJyaXR0YSAoQ0lWKSA8YnJpdHRhLmhhbGVAbnBzLmVkdTxtYWls dG86YnJpdHRhLmhhbGVAbnBzLmVkdT4+IHdyb3RlOg0KDQpJbiB0ZXJtcyBvZiBuZWdvdGlhdGlv biwgSSB0aGluayB3ZSBjYW4gY2xvc2VseSBjb3JyZWxhdGUgdGhlIGlzc3VlcyBhbmQgcHJhY3Rp Y2FsIHJhbWlmaWNhdGlvbnMgaW4gY2hvb3NpbmcgYSBzaWduYXR1cmUgc2NoZW1lIGxpc3Qgd2l0 aCB0aGUgY2lwaGVyc3VpdGUgbmVnb3RpYXRpb24gdGhhdCBhbHJlYWR5IHRha2VzIHBsYWNlLg0K TGV0IHVzIGFzc3VtZSB0aGF0IGV2ZXJ5IG1lbWJlciB3b3VsZCBub3Qgb25seSBoYXZlIGEgbGlz dCBvZiBzdXBwb3J0ZWQgY2lwaGVyc3VpdGVzIGluIHRoZWlyIENJSywgYnV0IGFsc28gb2Ygc2ln bmF0dXJlIHNjaGVtZXMuIFRoZSBhY3Rpb24gb2YgdGhlIGdyb3VwIGNyZWF0b3IgaXMgdGhlbiBj b21wYXJhYmxlIGluIHRoZSBmb2xsb3dpbmcgYS9iIGNhc2VzIGZvciBjaXBoZXJzdWl0ZXMvc2ln bmF0dXJlIHNjaGVtZXM6DQoNCg0KICAxLiAgVGhlIGdyb3VwIGNyZWF0b3Igd2FudHMgdG8gZW5z dXJlIGFueSBuZXdjb21lciBjYW4gam9pbiB0aGUgZ3JvdXA6DQoNCiAgICAgKiAgIFRoZSBncm91 cCBjcmVhdG9yIGNob29zZXMgdGhlIE1USSBjaXBoZXJzdWl0ZS4NCiAgICAgKiAgIFRoZSBncm91 cCBjcmVhdG9yIGNob29zZXMgdGhlIE1USSBhcyB0aGUgc2luZ2xlIGVsZW1lbnQgaW4gdGhlIHNl dCBvZiBwb3NzaWJsZSBzaWduYXR1cmVzLg0KDQoNCiAgMS4gIFRoZSBncm91cCBjcmVhdG9yIHdh bnRzIG1vcmUgY29udHJvbCBhbmQgaXMgbm90IHBhcnRpY3VsYXJseSBjb25jZXJuZWQgYWJvdXQg bmV3Y29tZXJzIGluIHRoZSBsb25nLXRlcm06DQoNCiAgICAgKiAgIFRoZSBncm91cCBjcmVhdG9y IGNob29zZXMgYSBub24tTVRJIGNpcGhlcnN1aXRlIGZyb20gdGhlIGluaXRpYWwgZ3JvdXAgbWVt YmVyc+KAmSBsaXN0cy4NCiAgICAgKiAgIFRoZSBncm91cCBjcmVhdG9yIGNob29zZXMgYSBzdWJz ZXQgb2YgaW5pdGlhbCBncm91cCBtZW1iZXJz4oCZIHN1cHBvcnRlZCBhbGdvcml0aG1zICh3aGlj aCBtYXkgb3IgbWF5IG5vdCBpbmNsdWRlIHRoZSBNVEkpLg0KRm9yIHRoZSBzYWtlIG9mIGFyZ3Vt ZW50LCBjb25zaWRlciB0aGUgZm9sbG93aW5nIGFsdGVybmF0aXZlIHRvIGI6DQoNCiAgICAgKiAg IFRoZSBncm91cCBjcmVhdG9yIGNob29zZXMgYSBzaW5nbGUgbm9uLU1USSBzaWduYXR1cmUgc2No ZW1lLg0KDQpUaGUgaXNzdWVzIGZvciBuZXdjb21lcnMgaW4gY2FzZSAyYiBpcyBub3QgdmVyeSBk aWZmZXJlbnQgZnJvbSAyYyAod2hpY2ggaXMgdWx0aW1hdGVseSB0aGUgY2FzZSBpZiB3ZSBvbmx5 IHN1cHBvcnQgb25lIHNjaGVtZSkuIEJhc2ljYWxseSwgdGhlIG5ld2NvbWVyIHN1cHBvcnRzIHRo ZSBzY2hlbWUvc2V0IG9mIHNjaGVtZXMgb3IgaGUgZG9lcyBub3QuIEluIDJhLCAyYiwgYW5kIDJj LCBhbGdvcml0aG1zIGFyZSBkaWN0YXRlZCBieSB0aGUgc2V0IG9mIGluaXRpYWwgbWVtYmVycywg c28gd2UgYXJlIG5vdCBsb29raW5nIGF0IGEgc2lnbmlmaWNhbnQgdXNhYmlsaXR5IGRpZmZlcmVu Y2UgdGhlcmUuDQoNCkZvciBjaG9vc2luZyB0aGUgc2lnbmF0dXJlIHNjaGVtZSBsaXN0LCBhbnkg cHJvcGVyIHN1YnNldCBvZiB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZSBpbml0aWFsIGdyb3VwIG1l bWJlcnPigJkgbGlzdCB3b3VsZCBiZSBwb3NzaWJsZSAoaGVuY2Ugd2h5IHdlIGhhdmUgZnJlZWRv bSB0byBjaG9vc2Uge01USX0gaW4gY2FzZSAxYikuIEhvd2V2ZXIsIHdlIGNvdWxkIG1ha2UgaXQg c2ltcGxlIGFuZCB1c2UgdGhlIGFjdHVhbCBpbnRlcnNlY3Rpb24uDQoNCkFzIGZhciBhcyBsaXN0 cyBjaGFuZ2luZyBvdmVyIHRpbWU6IGluIHRlcm1zIG9mIHdoYXQgYSBtZW1iZXIgY2FuIHN1cHBv cnQgdGhlIGFuc3dlciBpcyBhbiBhZmZpcm1hdGl2ZS4gSW4gdGhlIHNhbWUgd2F5IHRoZSBzdXBw b3J0ZWQgY2lwaGVyc3VpdGVzIGNhbiBjaGFuZ2Ugb3ZlciB0aW1lLCB0aGUgc3VwcG9ydGVkIHNp Z25hdHVyZSBzY2hlbWVzIGNhbiBhcyB3ZWxsLiBIb3dldmVyLCBpbiB0ZXJtcyBvZiB3aGF0IGlz IHVzZWQgaW4gdGhlIGdyb3VwLCB0aGlzIHNob3VsZCBub3QgY2hhbmdlOiBvbmNlIGZpeGVkIGF0 IGdyb3VwIGluaXRpYXRpb24gdGhlIGxpc3QgaXMgc3RhdGljIGZvciB0aGUgbGlmZXRpbWUgb2Yg dGhlIGdyb3VwLiBPbmNlIGEgbWVtYmVyIGhhcyBjaG9zZW4gYSBzaWduYXR1cmUgc2NoZW1lIGZy b20gdGhlIGxpc3QsIHRoZSBjaG9pY2UgaXMgc3RhdGljIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhl IGdyb3VwLiBUaGUgZ3JvdXAgc2hvdWxkIHRodXMgbm90IGJlIGFkYXB0YWJsZSB0byBjaGFuZ2Vz IGluIHRoZSBvZmZlcmVkIGFsZ29yaXRobXMgb2YgdGhlIENJS3MuDQoNCkJyaXR0YQ0KDQoNCg0K RnJvbTogS2FydGhpayBCaGFyZ2F2YW4gPGthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mcjxt YWlsdG86a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPj4NCkRhdGU6IEZyaWRheSwgRmVi cnVhcnkgMjgsIDIwMjAgYXQgNjo1NSBBTQ0KVG86IFJhcGhhZWwgUm9iZXJ0IDxyYXBoYWVsQHdp cmUuY29tPG1haWx0bzpyYXBoYWVsQHdpcmUuY29tPj4NCkNjOiAiSGFsZSwgQnJpdHRhIChDSVYp IiA8YnJpdHRhLmhhbGVAbnBzLmVkdTxtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdT4+LCBCZW5q YW1pbiBCZXVyZG91Y2hlIDxiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPG1haWx0bzpiZW5q YW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPj4sIENhcyBDcmVtZXJzIDxjYXMuY3JlbWVyc0BnbWFp bC5jb208bWFpbHRvOmNhcy5jcmVtZXJzQGdtYWlsLmNvbT4+LCBNTCBNZXNzYWdpbmcgTGF5ZXIg U2VjdXJpdHkgPG1sc0BpZXRmLm9yZzxtYWlsdG86bWxzQGlldGYub3JnPj4sIEtvbnJhZCBLb2hi cm9rIDxLb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPG1haWx0bzpLb25yYWQua29oYnJva0Bk YXRhc2hyaW5lLmRlPj4NClN1YmplY3Q6IFJlOiBbTUxTXSBjb25maXJtaW5nIGNpcGhlciBzdWl0 ZXMgZGVjaXNpb25zDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIHByYWN0aWNhbCByYW1pZmlj YXRpb25zIG9mIGdyb3VwcyB3aGVyZSBtZW1iZXJzIHVzZSBkaWZmZXJlbnQgYWxnb3JpdGhtcy4N Cg0KU3RpbGwsIEkgdGhpbmsgaXQgaXMgZmVhc2libGUgdG8gZXZlbnR1YWxseSBoYXZlIGEgZGVz aWduIHdoZXJlIHRoZSBncm91cCBjcmVhdG9yIHByb3Bvc2VzIGEgc2V0IG9mIGFsZ29yaXRobXMg YXMg4oCcbXVzdCBpbXBsZW1lbnTigJ0gZm9yIHRoZSBncm91cC4NCkVhY2ggbmV3IG1lbWJlciBt dXN0IHN1cHBvcnQgKGkuZS4gaW1wbGVtZW50KSDigJxhbGzigJ0gdGhlIGFsZ29yaXRobXMgaW4g dGhpcyBsaXN0IGluIG9yZGVyIHRvIGpvaW4gdGhlIGdyb3VwLg0KSG93ZXZlciwgdGhlIG1lbWJl ciBoYXMgdGhlIG9wdGlvbiB0byB1c2Ugd2hpY2hldmVyIHN1cHBvcnRlZCBhbGdvcml0aG0gc2hl IHByZWZlcnMgZm9yIG1lc3NhZ2VzIHNoZSBzZW5kcy4NCg0KV2hpbGUgYWxsIG9mIHRoaXMgaXMg YSByZWFzb25hYmxlIGxvbmctdGVybSBnb2FsLCBwZXJoYXBzIHdlIHNob3VsZCBzdGFydCB3aXRo IGEgdmVyc2lvbiB3aGVyZSB0aGUgY3JlYXRvciBvbmx5IGNob29zZXMgb25lIGFsZ29yaXRobSBp biBlYWNoIGNhdGVnb3J5LCBsZWF2aW5nIG5vIGNob2ljZSB0byB0aGUgbWVtYmVycy4NCldlIGNh biBkb2N1bWVudCB0aGlzIGNob2ljZSBhcyBhIGZ1dHVyZSBleHRlbnNpb24gcG9pbnQsIGFuZCBj aGFuZ2UgaXQgYXMgd2UgdW5kZXJzdGFuZCB0aGUgZmVkZXJhdGlvbiBzY2VuYXJpbyBhbmQgZGVw bG95bWVudCBjb25zdHJhaW50cyBhIGJpdCBiZXR0ZXI/DQoNCkJlc3QsDQpLYXJ0aGlrDQoNCg0K T24gMjcgRmViIDIwMjAsIGF0IDE5OjAyLCBSYXBoYWVsIFJvYmVydCA8cmFwaGFlbEB3aXJlLmNv bTxtYWlsdG86cmFwaGFlbEB3aXJlLmNvbT4+IHdyb3RlOg0KDQpJIGFncmVlIHdpdGggd2hhdCBL YXJ0aGlrIHNhaWQsIGFuZCBJIHRoaW5rIHRoYXQgdGhhdCB3YXMgdGhlIHVuZGVybHlpbmcgYXNz dW1wdGlvbiBhbGwgYWxvbmcgKGF0IGVhc3QgZm9yIG1lKS4gVGhlIG5lZ290aWF0aW9uIGhhcyB0 byBoYXBwZW4gYWhlYWQgb2YgdGltZSwgbmFtZWx5IHdoZW4NCg0KIC0gKDEpIGFuIGV4aXN0aW5n IG1lbWJlciBwcm9wb3NlcyB0byBhZGQgYSBuZXcgbWVtYmVyLCBvciB3aGVuDQogLSAoMikgYW4g ZXh0ZXJuYWwgcGFydHkgcHJvcG9zZXMgdG8gYWRkIGEgbmV3IG1lbWJlci4NCg0KSW4gdGhlIGN1 cnJlbnQgcHJvcG9zYWwgd2l0aCBhIGZpeGVkIHNpZ25hdHVyZSBwZXIgZ3JvdXAgdGhlIGRlY2lz aW9uIHRha2luZyBpcyByYXRoZXIgc2ltcGxlOiBJZiB0aGUgbmV3IG1lbWJlciBhZHZlcnRpc2Vz IHN1cHBvcnQgZm9yIHRoZSBncm91cCdzIGNpcGhlcnN1aXRlIGluIHRoZWlyIENJS3MsIHRoZXkg Y2FuIGJlIGFkZGVkIHRvIHRoZSBncm91cC4NCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgZGVj aXNpb24gdGFraW5nIGZsZXNoZWQgb3V0IGZvciB0aGUgYWx0ZXJuYXRpdmUgYXBwcm9hY2ggdGhh dCBzdXBwb3J0cyBtdWx0aXBsZSBzaWduYXR1cmVzLg0KV2UgbmVlZCB0byBtYWtlIHN1cmUgdGhh dCBtZW1iZXJzIGNhbiB2ZXJpZnkgc2lnbmF0dXJlcywgd2hpY2ggbWVhbnMgd2UgbmVlZCBhIGxp c3Qgb2YgYWNjZXB0YWJsZSBzaWduYXR1cmUgYWxnb3JpdGhtcyB0aGF0IGV2ZXJ5IG1lbWJlciBh Z3JlZXMgdXBvbiBiZWZvcmUgYSBuZXcgbWVtYmVyIGlzIGFkZGVkLiBTaWduYXR1cmUgYWxnb3Jp dGhtcyBjYW4gYmUgYWR2ZXJ0aXNlZCBpbiBhbm90aGVyIGV4dGVuc2lvbiBpbiBDSUtzLCBidXQg aXQgaXMgbm90IGVudGlyZWx5IGNsZWFyIHRvIG1lIGhvdyBjbGllbnRzIGFncmVlIG9uIHdoYXQg dGhlIGxpc3Qgb2YgYWNjZXB0YWJsZSBzaWduYXR1cmVzIGlzLiBXb3VsZCBpdCBiZSB0aGUgbG93 ZXN0IGNvbW1vbiBkZW5vbWluYXRvciwgbWVhbmluZyB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZSBh bGdvcml0aG1zIGFkdmVydGlzZWQgaW4gdGhlIENJS3M/IElmIHNvLCBpdCBtZWFucyB0aGUgbGlz dCBnZXRzIGxhcmdlbHkgZGV0ZXJtaW5lZCBieSB0aGUgZWFybHkgam9pbmVycy4gQWxzbywgY2Fu IHRoZSBsaXN0IGNoYW5nZSBvdmVyIHRpbWU/IFRoYXQgd291bGQgYmUgY29udHJhcnkgdG8gdGhl IGlkZWEgdGhhdCBhbGwgbmVnb3RpYXRpb25zIHNob3VsZCBoYXBwZW4gYWhlYWQgb2YgdGltZS4N ClRoZXJlIG1pZ2h0IGFuIGVhc3kgc29sdXRpb24gaGVyZSwgSSBqdXN0IGRvbuKAmXQgc2VlIGl0 IHJpZ2h0IG5vdy4NCg0KUmFwaGFlbA0KDQpPbiAyNyBGZWIgMjAyMCwgYXQgMTI6NTAsIEhhbGUs IEJyaXR0YSAoQ0lWKSA8YnJpdHRhLmhhbGVAbnBzLmVkdTxtYWlsdG86YnJpdHRhLmhhbGVAbnBz LmVkdT4+IHdyb3RlOg0KDQpCZW5qYW1pbiwNCg0KVGhlIHBvaW50IG9mIGNvbXBhcmlzb24gd2l0 aCBUTFMgaXMgdGhhdCBpbnRlcm9wIGlzIHNpZ25pZmljYW50bHkgbGVzcyBvZiBhbiBpc3N1ZSB3 aGVuIGV2ZXJ5b25lIGluIHRoZSBncm91cCBpcyB1c2luZyB0aGUgc2FtZSBjbGllbnQgcHJvZ3Jh bS4NCg0KSW4gdGVybXMgb2YgaW50ZXJvcCwgeW91ciBjb25jZXJucyBiZWNvbWUgYSBkaXNjdXNz aW9uIHBvaW50IG1haW5seSBpbiB0aGUgZmVkZXJhdGlvbiBjYXNlIOKAkyBhbmQgdGhhdCBpcyBh biBpbXBvcnRhbnQgY2FzZSB0aGF0IHdlIHNob3VsZCBwbGFuIGZvci4gQnV0LCBhcyBJIHNhaWQg YW5kIHlvdSByZS1pdGVyYXRlZCwgaWYgdGhlIHVzZSBjYXNlIHJlYWxseSBleHBlY3RzIGludGVy b3AgaXNzdWVzIGZyb20gYWxsb3dpbmcgY2hvaWNlLCB0aGVuIG5vdGhpbmcgcHJldmVudHMgdGhl IHNlbGVjdGlvbiBvZiBhIHNpbmdsZSBzY2hlbWUgZm9yIHRoZSBzZXQgb2YgYWxsb3dhYmxlIHNj aGVtZXMuDQoNCkFzIHRvIHRoZSByZWFzb25zIGJlaGluZCBhbGxvd2luZyBtdWx0aXBsZSBhbGdv cml0aG1zLCB0aGUgZG9jdW1lbnQgb24gdGhlIG1haWxpbmdsaXN0IGhhcyBhbHJlYWR5IG91dGxp bmVkIHNldmVyYWwg4oCTIHRoZXNlIGFyZSBzZWN1cml0eSByZWFzb25zIGZvciBzdXBwb3J0aW5n IGluZGl2aWR1YWwgYWxnb3JpdGhtcy4gVGhlIGludGVyb3Agb2JqZWN0aW9ucyBmYWxsIG9uIHRo ZSB1c2FiaWxpdHkgc2lkZSwgc28gdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiBpcyByZWFsbHkgYWJv dXQgdXNhYmlsaXR5IHZzLiBzZWN1cml0eSBjb25jZXJucy4gSG93ZXZlciwgYXQgdGhlIGludGVy c2VjdGlvbiBvZiB0aGVzZSB0d28gb3B0aW9ucyBpcyB0aGUgaWRlYSBvZiBhbGxvd2luZyBhIHNl dCBvZiBwb3NzaWJsZSBhbGdvcml0aG1zIGFzIEthcnRoaWsgc3VnZ2VzdHMuIFRoaXMgaXMgYSBn b29kIGNvbXByb21pc2UuDQoNCkkgd291bGQgZGVmaW5pdGVseSBub3Qgc3VnZ2VzdCB0aGF0IHlv dSBjb25zaWRlciBtdWx0aXBsZSBNVElzIGF0IHRoaXMgc3RhZ2UuIElmIHRoYXQgaXMgc29tZXRo aW5nIHlvdSB3YW50LCBpdCBpcyBiZXN0IHRvIHJhaXNlIGl0IGFzIGEgc2VwYXJhdGUgaXNzdWUu DQoNCi0tLQ0KDQpCcml0dGENCg0KDQpGcm9tOiBCZW5qYW1pbiBCZXVyZG91Y2hlIDxiZW5qYW1p bi5iZXVyZG91Y2hlQGlucmlhLmZyPG1haWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZy Pj4NCkRhdGU6IFRodXJzZGF5LCBGZWJydWFyeSAyNywgMjAyMCBhdCAxMTo0OCBBTQ0KVG86ICJI YWxlLCBCcml0dGEgKENJVikiIDxicml0dGEuaGFsZUBucHMuZWR1PG1haWx0bzpicml0dGEuaGFs ZUBucHMuZWR1Pj4NCkNjOiBDYXMgQ3JlbWVycyA8Y2FzLmNyZW1lcnNAZ21haWwuY29tPG1haWx0 bzpjYXMuY3JlbWVyc0BnbWFpbC5jb20+PiwgS2FydGhpa2V5YW4gQmhhcmdhdmFuIDxrYXJ0aGlr ZXlhbi5iaGFyZ2F2YW5AaW5yaWEuZnI8bWFpbHRvOmthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJp YS5mcj4+LCBNTCBNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgPG1sc0BpZXRmLm9yZzxtYWlsdG86 bWxzQGlldGYub3JnPj4sIEtvbnJhZCBLb2hicm9rIDxrb25yYWQua29oYnJva0BkYXRhc2hyaW5l LmRlPG1haWx0bzprb25yYWQua29oYnJva0BkYXRhc2hyaW5lLmRlPj4NClN1YmplY3Q6IFJlOiBb TUxTXSBjb25maXJtaW5nIGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zDQoNCg0KDQoNCk9uIDI3IEZl YiAyMDIwLCBhdCAxMTo0NywgQmVuamFtaW4gQmV1cmRvdWNoZSA8YmVuamFtaW4uYmV1cmRvdWNo ZUBpbnJpYS5mcjxtYWlsdG86YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mcj4+IHdyb3RlOg0K DQpIaSBCcml0dGEsDQoNCg0KT24gMjcgRmViIDIwMjAsIGF0IDEwOjU3LCBIYWxlLCBCcml0dGEg KENJVikgPGJyaXR0YS5oYWxlQG5wcy5lZHU8bWFpbHRvOmJyaXR0YS5oYWxlQG5wcy5lZHU+PiB3 cm90ZToNCg0KQmVuamFtaW4sDQoNClRoZSBpc3N1ZXMgeW91IGRlc2NyaWJlIGFyZSBwcmltYXJp bHkgVExTLXR5cGUgcHJvYmxlbXMsIHdoZXJlIHVuY29udHJvbGxlZCwgbGFyZ2Utc2NhbGUgYWdp bGl0eSBhbmQgaW50ZXJvcCBpc3N1ZXMgZXhpc3QuDQoNClllcyBleGFjdGx5LCBhbmQgSSB0aGlu ayB0d28tcGFydHkgc2hvcnQgbGl2ZWQgY29ubmVjdGlvbnMgZm9yIFRMUyBhcmUgZWFzaWVyIHRv IGhhbmRsZQ0KdGhhbiB3aWxsIGJlIHRoZSBsb25nLWxpdmVkIG11bHRpLXBhcnR5IGNvbm5lY3Rp b25zIG9mIE1MUy4NCg0KDQpBcyBoYXMgYmVlbiBzdGF0ZWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAg YXMgYSBzdXBwb3J0aW5nIGFyZ3VtZW50IHRvIG1hbnkgY2hhbmdlcyBvdmVyIHRoZSBkaWZmZXJl bnQgZHJhZnRzLCB3aXRoaW4gdGhlIG1lc3NhZ2luZy9NTFMgc3BhY2Ugd2UgYXJlIGxvb2tpbmcg YXQgc2lnbmlmaWNhbnRseSBtb3JlIGNsaWVudC1zcGVjaWZpYyBjb250cm9sLg0KDQpZZXMsIGFu ZCB3ZSBrZWVwIGJlaW5nIGNhcmVmdWwgdGhhdCBpdCBpcyB0aGUgY2FzZSB3aGVuIHdyaXRpbmcg dGhlIGRyYWZ0cywNCmJ1dCB0aGlzIGRvZXNu4oCZdCBtZWFuIHRoYXQgd2Ugc2hvdWxkIGJlIHdp bGxpbmcgdG8gcmlzayBpbnRlcm9wZXJhYmlsaXR5Lg0KDQoNCkl0IGlzIG5vdCB1bnJlYXNvbmFi bGUgZm9yIGEgbmV3Y29tZXIgdG8gc3VwcG9ydCBhIHNlbGVjdGlvbiBvZiBzaWduYXR1cmUgc2No ZW1lcy4gSWYgdGhlIGdyb3VwIGNyZWF0b3IgcmVhbGx5IHdhbnRzIGZ1bGwgaW50ZXJvcCwgdGhl eSBjYW4gYWx3YXlzIGRlZmluZSB0aGUgc2V0IG9mIGF2YWlsYWJsZSBzY2hlbWVzIHRvIGNvbnNp c3Qgb25seSBvZiB0aGUgTVRJLg0KDQpJIHRoaW5rIGF0IHJldmVyc2UsIGlmIHlvdSBhcmUgd2ls bGluZyB0byBicmVhayBpbnRlcm9wLCB5b3Ugc2hvdWxkIGJlIHNlbGVjdGluZyBzb21ldGhpbmcN Cg0KUy9zaG91bGQgYmUgc2VsZWN0aW5nL2NhbiBzZWxlY3QvDQoNCg0KZWxzZSB0aGFuIHRoZSBN VEkgd2hlbiBjcmVhdGluZyB0aGUgZ3JvdXAuIEFuZCBhZ2FpbiwgaW4gd2hhdCBJIHNheSwgbm90 aGluZyBwcmV2ZW50cw0KeW91IHRvIHBpY2sgdGhlIE5JU1QgY2lwaGVyc3VpdGUgZm9yIGNvbXBs aWFuY2UgYW5kIHVzZSBvbmx5IHRoYXQuDQpCdXQgSSBkb27igJl0IHNlZSB0aGUgaW50ZXJlc3Qg b2YgbWl4aW5nIGFsZ3MgYW5kIHB1dCBhdCByaXNrIGltcGxlbWVudGF0aW9ucyBhbmQgaW50ZXJv cGVyYWJpbGl0eS4NCg0KT3V0IG9mIGN1cmlvc2l0eSwgd2hlcmUgeW91IHNvbWVob3cgYXJndWlu ZyBmb3IgbXVsdGlwbGUgTVRJcyBoZXJlID8NCg0KQi4NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxTQGlldGYu b3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21sczxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZkPUR3TUZhUSZjPTVWRDBS VHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09SUMxaFpQVEVVZnR1 aThIQVB0STVYazd0a3kzOTBuTWZ5TmtmQktkVW9XWSZzPXlyVS1hLXRLMm9EaUxUbnlfOU9pMUd5 aWVhSVIyOVdIcjhLckZWWk1XOE0mZT0+DQoNCg0K --_000_109AB2E06BD34ADD8A946FEF9AEF9C48fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC54bXNvbGlzdHBhcmFncmFwaCwgbGkueG1zb2xpc3RwYXJhZ3JhcGgsIGRp di54bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTp4X21zb2xpc3RwYXJhZ3JhcGg7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLnhhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6eF9hcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NjY1NjY2MTUyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTYwMjcxMzE5Mjt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDoxNDIxMzY3MDkxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDcwNTE2 MTA7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZl bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1zdGFydC1h dDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTg4NzU5Njc4MTsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMxMTIzNTEwNjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcy LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBhbGwsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkni gJltIGp1c3QgY2F0Y2hpbmcgdXAgb24gdGhpcyBkaXNjdXNzaW9uLiBGcm9tIG15IHBlcnNwZWN0 aXZlIEkgZG9u4oCZdCBoYXZlIHBhcnRpY3VsYXJseSBzdHJvbmcgZmVlbGluZ3Mgb24gdGhlIGNo b2ljZSBoZXJlLiBJIHdvdWxkIHNheSB0aGF0LCB0aHVzIGZhciwgSSBoYXZlIG5vdCBlbmNvdW50 ZXJlZCBjb25jZXJucyBhYm91dCB0aGUgbGFjaw0KIG9mIGNyeXB0byBhZ2lsaXR5IGluIFNpZ25h bCDigJMgd2hpY2ggd2UgdXNlIHZlcnkgd2lkZWx5LiBGb3IgbG9uZy1ydW5uaW5nIGNvbnZlcnNh dGlvbnMgdGhvdWdoLCBJIGRlZmluaXRlbHkgbGlrZSB0aGUgaWRlYSBvZiBhbiBhYmlsaXR5IHRv IHVwZ3JhZGUgY3J5cHRvIG92ZXIgdGltZTsgYXMgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0IHRocmVh ZHMgY2FuIHJlbWFpbiBhY3RpdmUgZm9yIHllYXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UbyBCcml0dGHigJlzIHBvaW50 IGFib3V0IG5vYm9keSBoYXZpbmcgeWV0IHJhaXNlZCBwZXJmb3JtYW5jZSBjb25jZXJuczsgdGhp cyB3YXMgYWN0dWFsbHkgb25lIG9mIG15IHByaW1hcnkgY29uY2VybnMgcmVhZGluZyB0aHJvdWdo IHRoZSB0aHJlYWQuIEkgcmVjYWxsIHJlYWRpbmcgYWJvdXQgc29tZSBleHBlcmltZW50cyDigJMg SSB0aGluayBieQ0KIEdvb2dsZSDigJMgd2hlcmUgdGhleSBpbXByb3ZlZCBUTFMgcGVyZm9ybWFu Y2UgZnJvbSBieSBjaG9vc2luZyBjaXBoZXIgc3VpdGVzIHRvIGJlIHRob3NlIHdoaWNoIHdlcmUg bW9zdCBlZmZpY2llbnQgb24gY2xpZW50IGRldmljZXMuIElmIHdlIGFyZSB0byByb2xsIG91dCBN TFMgZ2xvYmFsbHksIHRvIGRldmljZXMgZnJvbSBoaWdoLWVuZCBpUGhvbmVzIHdpdGggZ29vZCBu ZXR3b3JrIGJhbmR3aWR0aCwgMTAteWVhciBvbGQgQW5kcm9pZCBwaG9uZXMNCiB3aXRoIGV4cGVu c2l2ZSBhbmQgc2xvdyBjb25uZWN0aW9ucywgYW5kIGFsc28gYWNyb3NzIHdlYiBicm93c2VycyDi gJMgSSBjYW4gaW1hZ2luZSB0aGF0IHRoZXJlIG1heSBiZSBzaXR1YXRpb25zIHdoZXJlIHRoZSBw ZXJmb3JtYW5jZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgY3J5cHRvIGNob2ljZXMgbWVhbmluZ2Z1bGx5 IHZhcnkgYWxvbmcgdmFyaW91cyBheGVzLiBJbiB0aGlzIHNlbnNlLCBJIHdvdWxkIHBvdGVudGlh bGx5IGJlIHNsaWdodGx5IHRlbXB0ZWQNCiB0byBsZWFuIHRvd2FyZHMgYW4gb3B0aW9uIHdoZXJl IGV2ZXJ5IGNsaWVudCBjYW4gdXNlIHRoZWlyIG93biBjaG9pY2Ugb2YgY3J5cHRvOyBzdWJqZWN0 IHRvIGFsbCBjbGllbnRzIGluIGEgY2hhdCBhY3R1YWxseSBzdXBwb3J0aW5nIHRoaXMgY2hvaWNl IChlbmFibGluZyBkZXByZWNhdGlvbiBmb3Igc2VjdXJpdHkgcHVycG9zZXMsIGJlY2F1c2UgdGhl IG1vc3QgdXAtdG8tZGF0ZSBjbGllbnQgaXMgYWJsZSB0byByZW1vdmUgc3VwcG9ydCBmb3INCiBu ZXdseS1pbnNlY3VyZSBvcHRpb25zIGFuZCBmb3JjZSB0aGUgd2hvbGUgZ3JvdXAgYXdheSBmcm9t IHRoZW0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyPg0KSG93ZXZlciwgdGhhdCBz YWlkLCBJ4oCZbSBjb25zY2lvdXMgb2YgdGhlIGNvbXBsZXhpdHkgb2Ygd2hhdCB3ZeKAmXJlIGJ1 aWxkaW5nIGFscmVhZHk7IGFuZCBvZiB0aGUgbmVlZCBmb3IgcHJvZ3Jlc3MuIEdpdmVuIHRoZSBl eHBlcmllbmNlIHRodXMgZmFyIHdpdGggU2lnbmFsLCBJ4oCZbSBhbHNvIHRlbXB0ZWQgdG8gbGVh biB0b3dhcmRzIFByb3Bvc2FsIEEgaW4gdGhlIG5hbWUgb2YgZ3JlYXRlciBzaW1wbGljaXR5LiBB cyBoYXMgYmVlbiBtZW50aW9uZWQNCiBtdWx0aXBsZSB0aW1lcywgd2UgY2FuIGFsd2F5cyBpdGVy YXRlIG9uIHRoaXMgaW4gZnV0dXJlIOKAkyBhbmQgd2Ugd291bGQgbGlrZWx5IGFscmVhZHkgZ2V0 IG1vc3Qgb2YgdGhlIGJlbmVmaXRzIGZyb20gYSB3aG9sZS1ncm91cC11cGdyYWRlIG1lY2hhbmlz bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+TUxT ICZsdDttbHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFJhcGhhZWwgUm9iZXJ0 ICZsdDtyYXBoYWVsPTQwd2lyZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPkZyaWRheSwgMjggRmVicnVhcnkgMjAyMCBhdCAxMDowNzxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7SGFsZSwgQnJpdHRhIChDSVYpJnF1b3Q7ICZsdDticml0dGEuaGFsZUBucHMuZWR1Jmd0Ozxi cj4NCjxiPkNjOiA8L2I+S2FydGhpayBCaGFyZ2F2YW4gJmx0O2thcnRoaWtleWFuLmJoYXJnYXZh bkBpbnJpYS5mciZndDssIENhcyBDcmVtZXJzICZsdDtjYXMuY3JlbWVyc0BnbWFpbC5jb20mZ3Q7 LCBCZW5qYW1pbiBCZXVyZG91Y2hlICZsdDtiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyJmd0 OywgTUwgTWVzc2FnaW5nIExheWVyIFNlY3VyaXR5ICZsdDttbHNAaWV0Zi5vcmcmZ3Q7LCBLb25y YWQgS29oYnJvayAmbHQ7S29ucmFkLmtvaGJyb2tAZGF0YXNocmluZS5kZSZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtNTFNdIGNvbmZpcm1pbmcgY2lwaGVyIHN1aXRlcyBkZWNpc2lvbnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBm b3Igb25lIGZlZWwgc29tZSBmdXJ0aGVyIGNsYXJpZmljYXRpb24gb24gdGhlIGNvbnRleHQgaXMg bmVlZGVkLCBiZWNhdXNlIHRoZSBwb3N0cyBvbiB0aGUgbWFpbGluZyBsaXN0IGRvbuKAmXQgZnVs bHkgcmVmbGVjdCB3aGF0IHdlIGRpc2N1c3NlZCBleHRlbnNpdmVseSBkdXJpbmcgdGhlIHZpcnR1 YWwgaW50ZXJpbSBjYWxscyBhbmQgc29tZSBudWFuY2VzIGdvdCBsb3N0Lg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rmlyc3Qgb2YgYWxsIEkgdGhpbmsgdGhl cmUgd2FzIGZ1bGwgY29uc2Vuc3VzIG9uIHRoZSBmYWN0IHRoYXQgZGVncmFkYXRpb24gb2YgdGhl IHNlY3VyaXR5IG9mIGNyeXB0byBwcmltaXRpdmVzIGlzIHNvbWV0aGluZyB3ZSBkZWVwbHkgY2Fy ZSBhYm91dCwgYmVjYXVzZSBkZWdyYWRhdGlvbiBqZW9wYXJkaXplcyB0aGUgc2VjdXJpdHkgcHJv cGVydGllcyBvZiB0aGUgZ3JvdXAgYW5kIGFuIGF0dGFja2VyIGNvdWxkDQogdXNlIGl0IGZvciBk b3duZ3JhZGUgYXR0YWNrcy4gVGhlIGRpc3NlbnN1cyBhcm9zZSBhcm91bmQgdGhlIHF1ZXN0aW9u IG9uIGhvdyBleGFjdGx5IHdlIHdhbnQgdG8gYWRkcmVzcyBkZWdyYWRhdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGdlbmVyYWwsIGFu eSBvZiB0aGUgY3J5cHRvIHByaW1pdGl2ZXMgaW4gdGhlIGNpcGhlcnN1aXRlcyBjYW4gc3VmZmVy IGRlZ3JhZGF0aW9uIGF0IHNvbWUgcG9pbnQuIFdlIG5lZWQgYSBzb3VuZCBtZWNoYW5pc20gdG8g dXBncmFkZSBncm91cHMgZnJvbSBvbmUgY2lwaGVyc3VpdGUgdG8gYW5vdGhlci4gS29ucmFkIGFu bm91bmNlZCB0aGF0IEJyaXR0YSBhbmQgaGUgYXJlIHdvcmtpbmcgb24gYSBwcm9wb3NhbA0KIGFu ZCBJIHRoaW5rIHRoYXTigJlzIGdyZWF0IG5ld3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlcmUg aXMgbm8gZGlzc2Vuc3VzIGFyb3VuZCB0aGUgZmFjdCB0aGF0IHRoaXMgbWVjaGFuaXNtIGlzIG5v dyBtb3JlIHRoYW4gZXZlciBmaXJtbHkgb24gdGhlIHJvYWRtYXAuIE5hdHVyYWxseSBzdWNoIGEg bWVjaGFuaXNtIHdvdWxkIGFsc28gYWxsb3cgdXBncmFkaW5nIHRoZSBzaWduYXR1cmUgc2NoZW1l IGlmIGl0IHdhcyBwYXJ0IG9mIHRoZSBjaXBoZXJzdWl0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gd2l0aCB0aGF0IGluIG1pbmQgd2Ug Y2FuIGZ1cnRoZXIgYm9pbCBkb3duIHRoZSB0d28gY2hvaWNlczo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJvcG9zYWwgQTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gU2luZ2xl IHNpZ25hdHVyZSBzY2hlbWUgYXMgcGFydCBvZiB0aGUgY2lwaGVyc3VpdGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gV2UgdHJlYXQg dGhlIHNpZ25hdHVyZSBzY2hlbWUgbGlrZSBhbGwgb3RoZXIgY3J5cHRvIHByaW1pdGl2ZXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0g V2UgdXNlIHRoZSBjaXBoZXJzdWl0ZSB1cGdyYWRlIG1lY2hhbmlzbSBmb3IgYWxsIHByaW1pdGl2 ZXMsIGluY2x1ZGluZyBzaWduYXR1cmUgc2NoZW1lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm9wb3NhbCBCOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSBDaXBoZXJzdWl0ZSAm IzQzOyBMU1M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOy0gV2UgdHJlYXQgdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXMgYSBzcGVjaWFsIGNy eXB0byBwcmltaXRpdmUgaW4gdGhhdCB3ZSBhbGxvdyBpbmRpdmlkdWFsIG1lbWJlcnMgdG8gbm8g bG9uZ2VyIHVzZSB1bnNhZmUgc2NoZW1lcyBldmVuIGJlZm9yZSB3ZSB1cGdyYWRlIHRoZSB3aG9s ZSBncm91cOKAmXMgY2lwaGVyc3VpdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gV2UgdXNlIHRoZSBjaXBoZXJzdWl0ZSB1cGdyYWRl IG1lY2hhbmlzbSBmb3IgYWxsIHByaW1pdGl2ZXMsIGV4Y2VwdCBmb3IgdGhlIHNpZ25hdHVyZSBz Y2hlbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SWYgbWVtb3J5IHNlcnZlcyB3ZWxsLCB0aGlzIGlzIGhvdyBmYXIgd2UgZ290IGluIHRoZSBj YWxscy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TXkgb3BpbmlvbiB3YXMgKGFuZCBzdGlsbCBpcykgdGhhdCBJIGZhdm9yIFByb3Bv c2FsIEEsIGJlY2F1c2UgSSB3YXNu4oCZdCBjb252aW5jZWQgd2UgbmVlZCB0byB0cmVhdCB0aGUg c2lnbmF0dXJlIHNjaGVtZSBkaWZmZXJlbnRseSB0aGFuIG90aGVyIGNyeXB0byBwcmltaXRpdmVz LiBJIG11Y2ggbW9yZSBwcmVmZXIgdG8gaGF2ZSBhIHNvdW5kIHVwZ3JhZGUgbWVjaGFuaXNtIGFu ZCBwdXQgc29tZSBwcmVzc3VyZQ0KIG9uIHRoZSBjbGllbnRzIHRvIGFiYW5kb24gb2xkIGFuZCB1 bnNhZmUgY2lwaGVyc3VpdGVzIGluIGdlbmVyYWwuIEkgYWxzbyB0aGluayB0aGF0IGluIG9yZGVy IHRvIGFjaGlldmUgdWJpcXVpdG91cyBmZWRlcmF0aW9uIHdlIHNob3VsZCBsaW1pdCBjaG9pY2Vz IHRvIHRoZSBtaW5pbXVtIHRoYXQgaXMgc3RyaWN0bHkgbmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGJlaW5nIHNhaWQs IEkgZnVsbHkgYWNrbm93bGVkZ2UgdGhhdCBpZiB3ZSBsb29rIG9ubHkgYXQgc2VjdXJpdHksIFBy b3Bvc2FsIEIgc291bmRzIGxpa2UgdGhlIGJldHRlciBjaG9pY2UgYmVjYXVzZSBicm9rZW4gc2ln bmF0dXJlIHNjaGVtZXMgbWlnaHQgaGF2ZSBsZXNzIG9mIGFuIGltcGFjdC4gSWYg4oCTIGdpdmVu IHRoZSBleHRyYSBjb250ZXh0IG1lbnRpb25lZCBhYm92ZSDigJMgcGVvcGxlIGZlZWwgd2UNCiBh YnNvbHV0ZWx5IHdhbnQgdGhpcyBleHRyYSBzZWN1cml0eSBwb3RlbnRpYWxseSBhdCB0aGUgZXhw ZW5zZSBvZiBpbnRlcm9wZXJhYmlsaXR5IEkgd29u4oCZdCBzdGFuZCBpbiB0aGUgd2F5LiBJIGp1 c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSBldmVyeW9uZSBpcyBhd2FyZSBvZiB3aGF0IGhhcyBiZWVu IGRpc2N1c3NlZCBwcmV2aW91c2x5IGJlZm9yZSB3ZSByZXNvcnQgdG8gY291bnRpbmcgdm90ZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJh cGhhZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g MjggRmViIDIwMjAsIGF0IDEzOjE4LCBIYWxlLCBCcml0dGEgKENJVikgJmx0OzxhIGhyZWY9Im1h aWx0bzpicml0dGEuaGFsZUBucHMuZWR1Ij5icml0dGEuaGFsZUBucHMuZWR1PC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBkZXNjcmlwdGlvbiBwcm92aWRlcyBhIGdv b2QsIHN1Y2NpbmN0IG91dGxpbmUgb2YgdGhlIHR3byBvcHRpb25zIHdpdGggcmVzcGVjdCB0byBh IHVzYWJpbGl0eSBjb21wYXJpc29uLiBJIHRoaW5rIHRoYXQgd2Ugbm93IGFyZSBpbiBhIGRlY2Vu dCBzdGF0ZSBvZiBjbGFyaXR5DQogcmVnYXJkaW5nIGJvdGggaG93IGJvdGggYWx0ZXJuYXRpdmVz IHdvdWxkIHdvcmsgaW4gcHJhY3RpY2UgKHRoYW5rcyB0byBSYXBoYWVsKSBhbmQgaG93IHRoZSBz ZWN1cml0eSBvZiB0aGUgYWx0ZXJuYXRpdmVzIGxpbmUgdXAgKGV4dHJhcG9sYXRlZCBmcm9tIHRo ZSBwcmV2aW91cyBhbHRlcm5hdGl2ZSBvZiBmdWxsIHNpZ25hdHVyZSBzY2hlbWUgY2hvaWNlIGZs ZXhpYmlsaXR5KS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkNvbnNlcXVlbnRseSwg Ym90aCBvcHRpb25zIGFwcGVhciB0byBiZSB3ZWxsIHVuZGVyc3Rvb2QsIHNvIEkgZG8gbm90IGJl bGlldmUgdGhhdCB0aGVyZSBpcyBhbnkgYXJndW1lbnQgdGhlcmUgLSBpZiBhbnlvbmUgZG9lcyBu b3QgdW5kZXJzdGFuZCBlaXRoZXIgYWx0ZXJuYXRpdmUgdGhlbg0KIGl0IGNhbiBiZSBjbGFyaWZp ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPi0gV2UgaGF2ZSBhIGRlY2VudCB2aWV3IG9mIHNlY3VyaXR5IGNvbmNlcm5zIG9uIHRoaXMg aXNzdWUsIGFzIGhhdmUgYmVlbiB2b2ljZWQgYnkgc2V2ZXJhbCBwZW9wbGUgKDQgc3Ryb25nIHZv dGVzIGZvciBvcHRpb24gQikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPi0gVGhlIGludGVyb3AgY29uY2VybnMgYXJlIGxpbWl0ZWQgYW5k IG1vc3RseSBpbiB0aGUgZmVkZXJhdGVkIGVudmlyb25tZW50ICgyIHN0cm9uZyB2b3RlcyBmb3Ig b3B0aW9uIEEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4tIE5vIG9uZSBoYXMgdm9pY2VkIGVmZmljaWVuY3kgY29uY2VybnMuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Bbnkgb25lIG9mIHRoZXNlIGlzIGEgZGVjZW50IHJl YXNvbiB0b28gY2hvb3NlIG9uZSBhbHRlcm5hdGl2ZSBvdmVyIGFub3RoZXIuIEhhdmluZyBhbiBv cGVuIFBSIGlzIG5vdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldlIGFsbCB3YW50 IHRvIG1ha2UgcHJvZ3Jlc3MsIGhhdmUgdGhpcyBkZWNpZGVkLCBhbmQgbW92ZSBvbi4gV2Ugc2hv dWxkIGRvIGl0IGNvcnJlY3RseS4gSXQgc2VlbXMgaWxsLWFkdmlzZWQgdG8gYmFjayB0cmFjayBh bmQgYnlwYXNzIHdoZXJlIHdlIGFyZSBhdCBpbiBjb25zZW5zdXMuPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QnJpdHRhPGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5HZXQgPGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19ha2EubXNfZ2hlaTM2JmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3 JmFtcDtyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmYW1wO209SUMxaFpQVEVVZnR1aThIQVB0STVY azd0a3kzOTBuTWZ5TmtmQktkVW9XWSZhbXA7cz1telFHbU5aQW1OcU55N2Z1amQ4Uk5KZzZHZzN5 dTE2UUJUTzI4R0EtSDJVJmFtcDtlPSI+DQpPdXRsb29rIGZvciBBbmRyb2lkPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjAiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUmFwaGFlbCBSb2JlcnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpyYXBoYWVsQHdpcmUuY29tIj5yYXBoYWVsQHdpcmUuY29tPC9hPiZndDs8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAyOCwgMjAyMCAxMjozNDo1NSBQTTxicj4NCjxi PlRvOjwvYj4gSGFsZSwgQnJpdHRhIChDSVYpICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhh bGVAbnBzLmVkdSI+YnJpdHRhLmhhbGVAbnBzLmVkdTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBL YXJ0aGlrIEJoYXJnYXZhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcnRoaWtleWFuLmJoYXJnYXZh bkBpbnJpYS5mciI+a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPC9hPiZndDs7IEJlbmph bWluIEJldXJkb3VjaGUgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlu cmlhLmZyIj5iZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPC9hPiZndDs7IENhcyBDcmVtZXJz ICZsdDs8YSBocmVmPSJtYWlsdG86Y2FzLmNyZW1lcnNAZ21haWwuY29tIj5jYXMuY3JlbWVyc0Bn bWFpbC5jb208L2E+Jmd0OzsNCiBNTCBNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgJmx0OzxhIGhy ZWY9Im1haWx0bzptbHNAaWV0Zi5vcmciPm1sc0BpZXRmLm9yZzwvYT4mZ3Q7OyBLb25yYWQgS29o YnJvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOktvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGUiPktv bnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW01MU10gY29uZmlybWluZyBjaXBoZXIgc3VpdGVzIGRlY2lzaW9ucyA8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgcHV0IGFzaWRl IHRoZSBzdHJhdGVnaWMgY29uc2lkZXJhdGlvbnMgZm9yIGEgbWludXRlLCBJIHRoaW5rIHRoZSB0 d28gcHJvcG9zYWxzIGJvaWwgZG93biB0byB0aGUgZm9sbG93aW5nOg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm9wb3NhbCBBICh0aGUgY3VycmVudCBv bmUpOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDstIENpcGhlcnN1aXRlcyBjb250YWluIGEgc2lnbmF0dXJlIHNjaGVtZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSBUaGUg Z3JvdXAgY3JlYXRvciBwaWNrcyBhIGNpcGhlcnN1aXRlIHVwb24gZ3JvdXAgY3JlYXRpb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0g VGhlIGNyZWF0b3IgTVVTVCBvbmx5IGFkZCBtZW1iZXJzIHRvIHRoZSBncm91cCB0aGF0IGFkdmVy dGlzZSB0aGUgY2lwaGVyc3VpdGUgaW4gdGhlaXIgQ0lLczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSBUaGUgc2FtZSBydWxlIGFwcGxp ZXMgdG8gYW55IEFkZFByb3Bvc2FsIGluIHRoZSBmdXR1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gVGhlIGNpcGhlcnN1aXRlIGlz IGV4cGxpY2l0bHkgbWVudGlvbmVkIGluIHRoZSBXZWxjb21lIG1lc3NhZ2U8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gTWVtYmVycyBN VVNUIG9ubHkgdXNlIHRoZSBzaWduYXR1cmUgc2NoZW1lIG9mIHRoZSBjaXBoZXJzdWl0ZSB0byBz aWduIG1lc3NhZ2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlByb3Bvc2FsIEIgKGFzIHByb3Bvc2VkIGJ5IEJyaXR0YSBldCBhbC4pOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDst IENpcGhlcnN1aXRlcyBkbyBub3QgY29udGFpbiBhIHNpZ25hdHVyZSBzY2hlbWU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0mbmJzcDtU aGUgZ3JvdXAgY3JlYXRvciBwaWNrcyBhIGNpcGhlcnN1aXRlIHVwb24gZ3JvdXAgY3JlYXRpb248 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw Oy0gVGhlIGdyb3VwIGNyZWF0b3IgcGlja3MgYSBsaXN0IG9mIHNpZ25hdHVyZSBzY2hlbWVzIChM U1MpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDstJm5ic3A7VGhlIGNyZWF0b3IgTVVTVCBvbmx5IGFkZCBtZW1iZXJzIHRvIHRoZSBncm91 cCB0aGF0IGFkdmVydGlzZSB0aGUgY2lwaGVyc3VpdGUgaW4gdGhlaXIgQ0lLcyBBTkQgYWxsIGVs ZW1lbnRzIG9mIHRoZSBMU1M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOy0gVGhlIHNhbWUgcnVsZSBhcHBsaWVzIHRvIGFueSBBZGRQcm9w b3NhbCBpbiB0aGUgZnV0dXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDstIFRoZSBjaXBoZXJzdWl0ZSBBTkQgdGhlIExTUyBhcmUgZXhw bGljaXRseSBtZW50aW9uZWQgaW4gdGhlIFdlbGNvbWUgbWVzc2FnZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSBNZW1iZXJzIE1VU1Qg b25seSB1c2UgdGhlIHNpZ25hdHVyZSBzY2hlbWVzIHRoYXQgYXJlIHBhcnQgb2YgdGhlIExTUyB0 byBzaWduIG1lc3NhZ2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluIG9yZGVyIHRvIG1ha2UgcHJvZ3Jlc3MsIEkgd291bGQgbGlrZSB0byBw cm9wb3NlIHRoYXQgd2UgbW92ZSBmb3J3YXJkIHdpdGggdGhlIGN1cnJlbnQgcHJvcG9zYWwgc2lt cGx5IGJlY2F1c2UgaXQgaXMgd2VsbCB1bmRlcnN0b29kIGFuZCBmdWxseSBzcGVjaWZpZWQuIEhv d2V2ZXIsIHdlIGFkZCB0aGUgZm9sbG93aW5nIHR3byBvcGVuIGlzc3VlcyB0byB0aGUgcHJvdG9j b2wgZHJhZnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9QRU4gSVNTVUU6IFNlY3VyaXR5IGNvdWxkIGJlIGltcHJvdmVkIGJ5IGFsbG93aW5n IG1vcmUgZmxleGliaWxpdHkgd2l0aCBzaWduYXR1cmVzIHNjaGVtZXMuIElmIGEgc2lnbmF0dXJl IHNjaGVtZSBiZWNvbWVzIGluc2VjdXJlIG92ZXIgdGltZSwgbWVtYmVycyBjb3VsZCBiZSBnaXZl biB0aGUgY2hvaWNlIG9mIGNob29zaW5nIGEgbW9yZSBzZWN1cmUgc2lnbmF0dXJlIHNjaGVtZSBh cyBsb25nIGF0IHRoZXJlDQogaXMgYSBndWFyYW50ZWUgdGhhdCBhbGwgb3RoZXIgbWVtYmVycyBh cmUgYWJsZSB0byB2ZXJpZnkgc2lnbmF0dXJlcyB1bmRlciB0aGF0IG5ldyBzY2hlbWUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9QRU4gSVNT VUU6IENyeXB0byBwcmltaXRpdmVzIG9mIHRoZSBjaG9zZW4gY2lwaGVyc3VpdGUgY291bGQgYmVj b21lIGluc2VjdXJlIG92ZXJ0aW1lIGFuZCBqZW9wYXJkaXplIHRoZSBzZWN1cml0eSBvZiB0aGUg d2hvbGUgZ3JvdXAuIFNpbmNlIFRyZWVLRU0gZG9lc27igJl0IHN1cHBvcnQgbWl4aW5nIGRpZmZl cmVudCBESEtFTSBhbGdvcml0aG1zIGFuZCBkaWZmZXJlbnQgc3ltbWV0cmljIGVuY3J5cHRpb24g YWxnb3JpdGhtcywNCiB3ZSBuZWVkIGEgd2F5IHRvIHVwZ3JhZGUgYW4gZXhpc3RpbmcgZ3JvdXAg dG8gYSBuZXcgYW5kIG1vcmUgc2VjdXJlIGNpcGhlcnN1aXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdvdWxkIGdpdmUgdXMgc29t ZSBtb3JlIHRpbWUgdG8gd29yayBvbiB0aGUgb3BlbiBpc3N1ZXMgYW5kIGNvbWUgdXAgd2l0aCBm dWxseSBmbGVzaGVkIG91dCBwcm9wb3NhbHMgdGhhdCB3ZSBjYW4gZGlzY3VzcyBhbmQgdWx0aW1h dGVseSBhbGwgYWdyZWUgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V291bGQgdGhpcyBhcHByb2FjaCBiZSBhY2NlcHRhYmxlIHRvIGV2 ZXJ5b25lPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SYXBoYWVsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI4IEZlYiAyMDIwLCBhdCAwODoyMSwgSGFsZSwgQnJpdHRh IChDSVYpICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdSI+YnJpdHRhLmhh bGVAbnBzLmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRlcm1zIG9mIG5lZ290aWF0aW9uLCBJIHRoaW5rIHdl IGNhbiBjbG9zZWx5IGNvcnJlbGF0ZSB0aGUgaXNzdWVzIGFuZCBwcmFjdGljYWwgcmFtaWZpY2F0 aW9ucyBpbiBjaG9vc2luZyBhIHNpZ25hdHVyZSBzY2hlbWUgbGlzdCB3aXRoIHRoZSBjaXBoZXJz dWl0ZSBuZWdvdGlhdGlvbiB0aGF0IGFscmVhZHkgdGFrZXMgcGxhY2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQgdXMgYXNzdW1lIHRoYXQg ZXZlcnkgbWVtYmVyIHdvdWxkIG5vdCBvbmx5IGhhdmUgYSBsaXN0IG9mIHN1cHBvcnRlZCBjaXBo ZXJzdWl0ZXMgaW4gdGhlaXIgQ0lLLCBidXQgYWxzbyBvZiBzaWduYXR1cmUgc2NoZW1lcy4gVGhl IGFjdGlvbiBvZiB0aGUgZ3JvdXAgY3JlYXRvciBpcyB0aGVuIGNvbXBhcmFibGUgaW4gdGhlIGZv bGxvd2luZyBhL2IgY2FzZXMgZm9yIGNpcGhlcnN1aXRlcy9zaWduYXR1cmUgc2NoZW1lczo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0i MSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Inhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LXRvcDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1saXN0 OmwyIGxldmVsMSBsZm8xIj4NClRoZSBncm91cCBjcmVhdG9yIHdhbnRzIHRvIGVuc3VyZSBhbnkg bmV3Y29tZXIgY2FuIGpvaW4gdGhlIGdyb3VwOjxvOnA+PC9vOnA+PC9saT48L29sPg0KPG9sIHN0 eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPG9sIHN0eWxlPSJtYXJn aW4tdG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJ4bXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi10b3A6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0 b206LjAwMDFwdDttc28tbGlzdDpsMiBsZXZlbDIgbGZvMSI+DQpUaGUgZ3JvdXAgY3JlYXRvciBj aG9vc2VzIHRoZSBNVEkgY2lwaGVyc3VpdGUuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0ieG1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tdG9wOjBjbTttYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzEiPg0KVGhlIGdyb3Vw IGNyZWF0b3IgY2hvb3NlcyB0aGUgTVRJIGFzIHRoZSBzaW5nbGUgZWxlbWVudCBpbiB0aGUgc2V0 IG9mIHBvc3NpYmxlIHNpZ25hdHVyZXMuPG86cD48L286cD48L2xpPjwvb2w+DQo8L29sPg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFy dD0iMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Inhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLXRvcDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8yIj4NClRoZSBncm91cCBjcmVhdG9yIHdhbnRzIG1vcmUgY29udHJv bCBhbmQgaXMgbm90IHBhcnRpY3VsYXJseSBjb25jZXJuZWQgYWJvdXQgbmV3Y29tZXJzIGluIHRo ZSBsb25nLXRlcm06PG86cD48L286cD48L2xpPjwvb2w+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6 MGNtIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFy dD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Inhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLXRvcDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O21zby1s aXN0OmwwIGxldmVsMiBsZm8yIj4NClRoZSBncm91cCBjcmVhdG9yIGNob29zZXMgYSBub24tTVRJ IGNpcGhlcnN1aXRlIGZyb20gdGhlIGluaXRpYWwgZ3JvdXAgbWVtYmVyc+KAmSBsaXN0cy48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJ4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi10 b3A6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tbGlzdDps MCBsZXZlbDIgbGZvMiI+DQpUaGUgZ3JvdXAgY3JlYXRvciBjaG9vc2VzIGEgc3Vic2V0IG9mIGlu aXRpYWwgZ3JvdXAgbWVtYmVyc+KAmSBzdXBwb3J0ZWQgYWxnb3JpdGhtcyAod2hpY2ggbWF5IG9y IG1heSBub3QgaW5jbHVkZSB0aGUgTVRJKS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50LCBjb25z aWRlciB0aGUgZm9sbG93aW5nIGFsdGVybmF0aXZlIHRvIGI6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxvbCBz dHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIzIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0ieG1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tdG9wOjBjbTttYXJnaW4tYm90dG9tOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzMiPg0KVGhlIGdyb3Vw IGNyZWF0b3IgY2hvb3NlcyBhIHNpbmdsZSBub24tTVRJIHNpZ25hdHVyZSBzY2hlbWUuPG86cD48 L286cD48L2xpPjwvb2w+DQo8L29sPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGlzc3VlcyBmb3IgbmV3Y29tZXJzIGluIGNhc2UgMmIgaXMgbm90IHZlcnkgZGlmZmVyZW50IGZy b20gMmMgKHdoaWNoIGlzIHVsdGltYXRlbHkgdGhlIGNhc2UgaWYgd2Ugb25seSBzdXBwb3J0IG9u ZSBzY2hlbWUpLiBCYXNpY2FsbHksIHRoZSBuZXdjb21lciBzdXBwb3J0cyB0aGUgc2NoZW1lL3Nl dCBvZiBzY2hlbWVzIG9yIGhlIGRvZXMgbm90LiBJbiAyYSwgMmIsIGFuZCAyYywgYWxnb3JpdGht cyBhcmUNCiBkaWN0YXRlZCBieSB0aGUgc2V0IG9mIGluaXRpYWwgbWVtYmVycywgc28gd2UgYXJl IG5vdCBsb29raW5nIGF0IGEgc2lnbmlmaWNhbnQgdXNhYmlsaXR5IGRpZmZlcmVuY2UgdGhlcmUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZv ciBjaG9vc2luZyB0aGUgc2lnbmF0dXJlIHNjaGVtZSBsaXN0LCBhbnkgcHJvcGVyIHN1YnNldCBv ZiB0aGUgaW50ZXJzZWN0aW9uIG9mIHRoZSBpbml0aWFsIGdyb3VwIG1lbWJlcnPigJkgbGlzdCB3 b3VsZCBiZSBwb3NzaWJsZSAoaGVuY2Ugd2h5IHdlIGhhdmUgZnJlZWRvbSB0byBjaG9vc2Uge01U SX0gaW4gY2FzZSAxYikuIEhvd2V2ZXIsIHdlIGNvdWxkIG1ha2UgaXQgc2ltcGxlIGFuZCB1c2Ug dGhlIGFjdHVhbA0KIGludGVyc2VjdGlvbi48c3BhbiBjbGFzcz0ieGFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BcyBmYXIgYXMgbGlzdHMgY2hhbmdpbmcgb3ZlciB0aW1lOiBpbiB0 ZXJtcyBvZiB3aGF0IGEgbWVtYmVyIGNhbiBzdXBwb3J0IHRoZSBhbnN3ZXIgaXMgYW4gYWZmaXJt YXRpdmUuIEluIHRoZSBzYW1lIHdheSB0aGUgc3VwcG9ydGVkIGNpcGhlcnN1aXRlcyBjYW4gY2hh bmdlIG92ZXIgdGltZSwgdGhlIHN1cHBvcnRlZCBzaWduYXR1cmUgc2NoZW1lcyBjYW4gYXMgd2Vs bC4gSG93ZXZlciwgaW4gdGVybXMgb2Ygd2hhdA0KIGlzIHVzZWQgaW4gdGhlIGdyb3VwLCB0aGlz IHNob3VsZCBub3QgY2hhbmdlOiBvbmNlIGZpeGVkIGF0IGdyb3VwIGluaXRpYXRpb24gdGhlIGxp c3QgaXMgc3RhdGljIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlIGdyb3VwLiBPbmNlIGEgbWVtYmVy IGhhcyBjaG9zZW4gYSBzaWduYXR1cmUgc2NoZW1lIGZyb20gdGhlIGxpc3QsIHRoZSBjaG9pY2Ug aXMgc3RhdGljIGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlIGdyb3VwLiBUaGUgZ3JvdXAgc2hvdWxk IHRodXMNCiBub3QgYmUgYWRhcHRhYmxlIHRvIGNoYW5nZXMgaW4gdGhlIG9mZmVyZWQgYWxnb3Jp dGhtcyBvZiB0aGUgQ0lLcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QnJpdHRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0ieGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPkthcnRoaWsgQmhhcmdhdmFuICZsdDs8YSBocmVmPSJtYWlsdG86a2FydGhpa2V5 YW4uYmhhcmdhdmFuQGlucmlhLmZyIj5rYXJ0aGlrZXlhbi5iaGFyZ2F2YW5AaW5yaWEuZnI8L2E+ Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9InhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+RnJpZGF5LCBGZWJydWFyeSAyOCwgMjAyMCBhdCA2OjU1IEFNPGJyPg0K PGI+VG86PHNwYW4gY2xhc3M9InhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L2I+UmFwaGFlbCBSb2JlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyYXBoYWVsQHdpcmUuY29tIj5y YXBoYWVsQHdpcmUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0ieGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4mcXVvdDtIYWxlLCBCcml0dGEgKENJVikm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpicml0dGEuaGFsZUBucHMuZWR1Ij5icml0dGEuaGFs ZUBucHMuZWR1PC9hPiZndDssIEJlbmphbWluIEJldXJkb3VjaGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyIj5iZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlh LmZyPC9hPiZndDssIENhcyBDcmVtZXJzICZsdDs8YSBocmVmPSJtYWlsdG86Y2FzLmNyZW1lcnNA Z21haWwuY29tIj5jYXMuY3JlbWVyc0BnbWFpbC5jb208L2E+Jmd0OywNCiBNTCBNZXNzYWdpbmcg TGF5ZXIgU2VjdXJpdHkgJmx0OzxhIGhyZWY9Im1haWx0bzptbHNAaWV0Zi5vcmciPm1sc0BpZXRm Lm9yZzwvYT4mZ3Q7LCBLb25yYWQgS29oYnJvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOktvbnJhZC5r b2hicm9rQGRhdGFzaHJpbmUuZGUiPktvbnJhZC5rb2hicm9rQGRhdGFzaHJpbmUuZGU8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9InhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+UmU6IFtNTFNdIGNvbmZpcm1pbmcgY2lwaGVyIHN1aXRlcyBkZWNpc2lv bnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgcHJh Y3RpY2FsIHJhbWlmaWNhdGlvbnMgb2YgZ3JvdXBzIHdoZXJlIG1lbWJlcnMgdXNlIGRpZmZlcmVu dCBhbGdvcml0aG1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0aWxsLCBJIHRoaW5rIGl0IGlzIGZlYXNpYmxlIHRv IGV2ZW50dWFsbHkgaGF2ZSBhIGRlc2lnbiB3aGVyZSB0aGUgZ3JvdXAgY3JlYXRvciBwcm9wb3Nl cyBhIHNldCBvZiBhbGdvcml0aG1zIGFzIOKAnG11c3QgaW1wbGVtZW504oCdIGZvciB0aGUgZ3Jv dXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5FYWNoIG5ldyBtZW1iZXIgbXVzdCBzdXBwb3J0IChpLmUuIGltcGxlbWVu dCkg4oCcYWxs4oCdIHRoZSBhbGdvcml0aG1zIGluIHRoaXMgbGlzdCBpbiBvcmRlciB0byBqb2lu IHRoZSBncm91cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHRoZSBtZW1iZXIgaGFzIHRoZSBvcHRpb24g dG8gdXNlIHdoaWNoZXZlciBzdXBwb3J0ZWQgYWxnb3JpdGhtIHNoZSBwcmVmZXJzIGZvciBtZXNz YWdlcyBzaGUgc2VuZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIGFsbCBvZiB0 aGlzIGlzIGEgcmVhc29uYWJsZSBsb25nLXRlcm0gZ29hbCwgcGVyaGFwcyB3ZSBzaG91bGQgc3Rh cnQgd2l0aCBhIHZlcnNpb24gd2hlcmUgdGhlIGNyZWF0b3Igb25seSBjaG9vc2VzIG9uZSBhbGdv cml0aG0gaW4gZWFjaCBjYXRlZ29yeSwgbGVhdmluZyBubyBjaG9pY2UgdG8gdGhlIG1lbWJlcnMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBjYW4gZG9jdW1lbnQgdGhpcyBjaG9pY2UgYXMgYSBmdXR1cmUgZXh0ZW5z aW9uIHBvaW50LCBhbmQgY2hhbmdlIGl0IGFzIHdlIHVuZGVyc3RhbmQgdGhlIGZlZGVyYXRpb24g c2NlbmFyaW8gYW5kIGRlcGxveW1lbnQgY29uc3RyYWludHMgYSBiaXQgYmV0dGVyPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2FydGhpazxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDI3IEZlYiAyMDIwLCBhdCAxOTowMiwgUmFwaGFlbCBSb2JlcnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpyYXBoYWVsQHdpcmUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yYXBo YWVsQHdpcmUuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBh Z3JlZSB3aXRoIHdoYXQgS2FydGhpayBzYWlkLCBhbmQgSSB0aGluayB0aGF0IHRoYXQgd2FzIHRo ZSB1bmRlcmx5aW5nIGFzc3VtcHRpb24gYWxsIGFsb25nIChhdCBlYXN0IGZvciBtZSkuIFRoZSBu ZWdvdGlhdGlvbiBoYXMgdG8gaGFwcGVuIGFoZWFkIG9mIHRpbWUsIG5hbWVseSB3aGVuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDstICgxKSBhbiBleGlzdGluZyBtZW1iZXIgcHJvcG9zZXMgdG8g YWRkIGEgbmV3IG1lbWJlciwgb3Igd2hlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSAoMikgYW4gZXh0ZXJu YWwgcGFydHkgcHJvcG9zZXMgdG8gYWRkIGEgbmV3IG1lbWJlci48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW4gdGhlIGN1cnJlbnQgcHJvcG9zYWwgd2l0aCBhIGZpeGVkIHNpZ25hdHVyZSBw ZXIgZ3JvdXAgdGhlIGRlY2lzaW9uIHRha2luZyBpcyByYXRoZXIgc2ltcGxlOiBJZiB0aGUgbmV3 IG1lbWJlciBhZHZlcnRpc2VzIHN1cHBvcnQgZm9yIHRoZSBncm91cCdzIGNpcGhlcnN1aXRlIGlu IHRoZWlyIENJS3MsIHRoZXkgY2FuIGJlIGFkZGVkIHRvIHRoZSBncm91cC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgZGVjaXNpb24gdGFraW5nIGZs ZXNoZWQgb3V0IGZvciB0aGUgYWx0ZXJuYXRpdmUgYXBwcm9hY2ggdGhhdCBzdXBwb3J0cyBtdWx0 aXBsZSBzaWduYXR1cmVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgbmVlZCB0byBtYWtlIHN1cmUgdGhh dCBtZW1iZXJzIGNhbiB2ZXJpZnkgc2lnbmF0dXJlcywgd2hpY2ggbWVhbnMgd2UgbmVlZCBhIGxp c3Qgb2YgYWNjZXB0YWJsZSBzaWduYXR1cmUgYWxnb3JpdGhtcyB0aGF0IGV2ZXJ5IG1lbWJlciBh Z3JlZXMgdXBvbiBiZWZvcmUgYSBuZXcgbWVtYmVyIGlzIGFkZGVkLiBTaWduYXR1cmUgYWxnb3Jp dGhtcyBjYW4gYmUgYWR2ZXJ0aXNlZCBpbiBhbm90aGVyIGV4dGVuc2lvbg0KIGluIENJS3MsIGJ1 dCBpdCBpcyBub3QgZW50aXJlbHkgY2xlYXIgdG8gbWUgaG93IGNsaWVudHMgYWdyZWUgb24gd2hh dCB0aGUgbGlzdCBvZiBhY2NlcHRhYmxlIHNpZ25hdHVyZXMgaXMuIFdvdWxkIGl0IGJlIHRoZSBs b3dlc3QgY29tbW9uIGRlbm9taW5hdG9yLCBtZWFuaW5nIHRoZSBpbnRlcnNlY3Rpb24gb2YgdGhl IGFsZ29yaXRobXMgYWR2ZXJ0aXNlZCBpbiB0aGUgQ0lLcz8gSWYgc28sIGl0IG1lYW5zIHRoZSBs aXN0IGdldHMgbGFyZ2VseQ0KIGRldGVybWluZWQgYnkgdGhlIGVhcmx5IGpvaW5lcnMuIEFsc28s IGNhbiB0aGUgbGlzdCBjaGFuZ2Ugb3ZlciB0aW1lPyBUaGF0IHdvdWxkIGJlIGNvbnRyYXJ5IHRv IHRoZSBpZGVhIHRoYXQgYWxsIG5lZ290aWF0aW9ucyBzaG91bGQgaGFwcGVuIGFoZWFkIG9mIHRp bWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVyZSBtaWdodCBhbiBlYXN5IHNvbHV0aW9uIGhlcmUsIEkganVzdCBk b27igJl0IHNlZSBpdCByaWdodCBub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhcGhh ZWwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjcg RmViIDIwMjAsIGF0IDEyOjUwLCBIYWxlLCBCcml0dGEgKENJVikgJmx0OzxhIGhyZWY9Im1haWx0 bzpicml0dGEuaGFsZUBucHMuZWR1Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5icml0dGEu aGFsZUBucHMuZWR1PC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVu amFtaW4sPHNwYW4gY2xhc3M9InhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBvaW50IG9mIGNvbXBhcmlzb24gd2l0aCBU TFMgaXMgdGhhdCBpbnRlcm9wIGlzIHNpZ25pZmljYW50bHkgbGVzcyBvZiBhbiBpc3N1ZSB3aGVu IGV2ZXJ5b25lIGluIHRoZSBncm91cCBpcyB1c2luZyB0aGUgc2FtZSBjbGllbnQgcHJvZ3JhbS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGVybXMgb2YgaW50ZXJvcCwgeW91ciBjb25j ZXJucyBiZWNvbWUgYSBkaXNjdXNzaW9uIHBvaW50IG1haW5seSBpbiB0aGUgZmVkZXJhdGlvbiBj YXNlIOKAkyBhbmQgdGhhdCBpcyBhbiBpbXBvcnRhbnQgY2FzZSB0aGF0IHdlIHNob3VsZCBwbGFu IGZvci4gQnV0LCBhcyBJIHNhaWQgYW5kIHlvdSByZS1pdGVyYXRlZCwgaWYgdGhlIHVzZSBjYXNl IHJlYWxseSBleHBlY3RzIGludGVyb3AgaXNzdWVzIGZyb20gYWxsb3dpbmcNCiBjaG9pY2UsIHRo ZW4gbm90aGluZyBwcmV2ZW50cyB0aGUgc2VsZWN0aW9uIG9mIGEgc2luZ2xlIHNjaGVtZSBmb3Ig dGhlIHNldCBvZiBhbGxvd2FibGUgc2NoZW1lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QXMgdG8gdGhlIHJlYXNvbnMgYmVoaW5kIGFsbG93aW5nIG11bHRpcGxlIGFsZ29yaXRobXMsIHRo ZSBkb2N1bWVudCBvbiB0aGUgbWFpbGluZ2xpc3QgaGFzIGFscmVhZHkgb3V0bGluZWQgc2V2ZXJh bCDigJMgdGhlc2UgYXJlIHNlY3VyaXR5IHJlYXNvbnMgZm9yIHN1cHBvcnRpbmcgaW5kaXZpZHVh bCBhbGdvcml0aG1zLiBUaGUgaW50ZXJvcCBvYmplY3Rpb25zIGZhbGwgb24gdGhlIHVzYWJpbGl0 eSBzaWRlLCBzbw0KIHRoZSBjdXJyZW50IGRpc2N1c3Npb24gaXMgcmVhbGx5IGFib3V0IHVzYWJp bGl0eSB2cy4gc2VjdXJpdHkgY29uY2VybnMuIEhvd2V2ZXIsIGF0IHRoZSBpbnRlcnNlY3Rpb24g b2YgdGhlc2UgdHdvIG9wdGlvbnMgaXMgdGhlIGlkZWEgb2YgYWxsb3dpbmcgYSBzZXQgb2YgcG9z c2libGUgYWxnb3JpdGhtcyBhcyBLYXJ0aGlrIHN1Z2dlc3RzLiBUaGlzIGlzIGEgZ29vZCBjb21w cm9taXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGRlZmluaXRlbHkgbm90 IHN1Z2dlc3QgdGhhdCB5b3UgY29uc2lkZXIgbXVsdGlwbGUgTVRJcyBhdCB0aGlzIHN0YWdlLiBJ ZiB0aGF0IGlzIHNvbWV0aGluZyB5b3Ugd2FudCwgaXQgaXMgYmVzdCB0byByYWlzZSBpdCBhcyBh IHNlcGFyYXRlIGlzc3VlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyaXR0YTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZyb206PHNwYW4gY2xhc3M9InhhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5CZW5qYW1pbiBCZXVyZG91Y2hlICZsdDs8YSBocmVmPSJtYWlsdG86YmVu amFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mciI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVu amFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mcjwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNw YW4gY2xhc3M9InhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VGh1cnNk YXksIEZlYnJ1YXJ5IDI3LCAyMDIwIGF0IDExOjQ4IEFNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9 InhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+JnF1b3Q7SGFsZSwgQnJp dHRhIChDSVYpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhhbGVAbnBzLmVkdSI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YnJpdHRhLmhhbGVAbnBzLmVkdTwvc3Bhbj48L2E+ Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJ4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPkNhcyBDcmVtZXJzICZsdDs8YSBocmVmPSJtYWlsdG86Y2FzLmNyZW1lcnNA Z21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5jYXMuY3JlbWVyc0BnbWFpbC5j b208L3NwYW4+PC9hPiZndDssIEthcnRoaWtleWFuIEJoYXJnYXZhbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmthcnRoaWtleWFuLmJoYXJnYXZhbkBpbnJpYS5mciI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPC9zcGFuPjwvYT4mZ3Q7LA0KIE1M IE1lc3NhZ2luZyBMYXllciBTZWN1cml0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1sc0BpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWxzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7 LCBLb25yYWQgS29oYnJvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvbnJhZC5rb2hicm9rQGRhdGFz aHJpbmUuZGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmtvbnJhZC5rb2hicm9rQGRhdGFz aHJpbmUuZGU8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjxzcGFuIGNsYXNzPSJ4YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbTUxTXSBjb25maXJtaW5n IGNpcGhlciBzdWl0ZXMgZGVjaXNpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAy NyBGZWIgMjAyMCwgYXQgMTE6NDcsIEJlbmphbWluIEJldXJkb3VjaGUgJmx0OzxhIGhyZWY9Im1h aWx0bzpiZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5iZW5qYW1pbi5iZXVyZG91Y2hlQGlucmlhLmZyPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQnJpdHRh LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNyBGZWIgMjAyMCwgYXQgMTA6NTcsIEhhbGUsIEJy aXR0YSAoQ0lWKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaXR0YS5oYWxlQG5wcy5lZHUiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmJyaXR0YS5oYWxlQG5wcy5lZHU8L3NwYW4+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C ZW5qYW1pbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGlzc3VlcyB5b3UgZGVzY3JpYmUgYXJlIHByaW1hcmlseSBUTFMtdHlwZSBw cm9ibGVtcywgd2hlcmUgdW5jb250cm9sbGVkLCBsYXJnZS1zY2FsZSBhZ2lsaXR5IGFuZCBpbnRl cm9wIGlzc3VlcyBleGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzIGV4YWN0 bHksIGFuZCBJIHRoaW5rIHR3by1wYXJ0eSBzaG9ydCBsaXZlZCBjb25uZWN0aW9ucyBmb3IgVExT IGFyZSBlYXNpZXIgdG8gaGFuZGxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFuIHdpbGwg YmUgdGhlIGxvbmctbGl2ZWQgbXVsdGktcGFydHkgY29ubmVjdGlvbnMgb2YgTUxTLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgaGFzIGJlZW4gc3RhdGVkIGluIHRoZSB3 b3JraW5nIGdyb3VwIGFzIGEgc3VwcG9ydGluZyBhcmd1bWVudCB0byBtYW55IGNoYW5nZXMgb3Zl ciB0aGUgZGlmZmVyZW50IGRyYWZ0cywgd2l0aGluIHRoZSBtZXNzYWdpbmcvTUxTIHNwYWNlIHdl IGFyZSBsb29raW5nIGF0IHNpZ25pZmljYW50bHkgbW9yZSBjbGllbnQtc3BlY2lmaWMgY29udHJv bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGFuZCB3ZSBrZWVwIGJlaW5nIGNhcmVmdWwg dGhhdCBpdCBpcyB0aGUgY2FzZSB3aGVuIHdyaXRpbmcgdGhlIGRyYWZ0cyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmJ1dCB0aGlzIGRvZXNu4oCZdCBtZWFuIHRoYXQgd2Ugc2hvdWxkIGJlIHdp bGxpbmcgdG8gcmlzayBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0IGlzIG5vdCB1bnJlYXNvbmFibGUgZm9yIGEgbmV3Y29tZXIgdG8gc3VwcG9ydCBhIHNl bGVjdGlvbiBvZiBzaWduYXR1cmUgc2NoZW1lcy4gSWYgdGhlIGdyb3VwIGNyZWF0b3IgcmVhbGx5 IHdhbnRzIGZ1bGwgaW50ZXJvcCwgdGhleSBjYW4gYWx3YXlzIGRlZmluZSB0aGUgc2V0IG9mIGF2 YWlsYWJsZSBzY2hlbWVzIHRvIGNvbnNpc3Qgb25seSBvZiB0aGUgTVRJLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB0aGluayBhdCByZXZlcnNlLCBpZiB5b3UgYXJlIHdpbGxpbmcgdG8gYnJlYWsgaW50ZXJv cCwgeW91IHNob3VsZCBiZSBzZWxlY3Rpbmcgc29tZXRoaW5nPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TL3Nob3VsZCBiZSBzZWxlY3RpbmcvY2FuIHNlbGVjdC88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZWxzZSB0aGFuIHRoZSBNVEkgd2hlbiBjcmVhdGluZyB0 aGUgZ3JvdXAuIEFuZCBhZ2FpbiwgaW4gd2hhdCBJIHNheSwgbm90aGluZyBwcmV2ZW50czxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+eW91IHRvIHBpY2sgdGhlIE5JU1QgY2lwaGVyc3VpdGUgZm9y IGNvbXBsaWFuY2UgYW5kIHVzZSBvbmx5IHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C dXQgSSBkb27igJl0IHNlZSB0aGUgaW50ZXJlc3Qgb2YgbWl4aW5nIGFsZ3MgYW5kIHB1dCBhdCBy aXNrIGltcGxlbWVudGF0aW9ucyBhbmQgaW50ZXJvcGVyYWJpbGl0eS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3V0IG9mIGN1cmlvc2l0 eSwgd2hlcmUgeW91IHNvbWVob3cgYXJndWluZyBmb3IgbXVsdGlwbGUgTVRJcyBoZXJlID88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTUxTIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpNTFNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pk1MU0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1w O3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7bT1JQzFoWlBURVVmdHVpOEhBUHRJNVhrN3Rr eTM5MG5NZnlOa2ZCS2RVb1dZJmFtcDtzPXlyVS1hLXRLMm9EaUxUbnlfOU9pMUd5aWVhSVIyOVdI cjhLckZWWk1XOE0mYW1wO2U9Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_109AB2E06BD34ADD8A946FEF9AEF9C48fbcom_-- From nobody Fri Feb 28 14:37:21 2020 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F3D3A1F69; Fri, 28 Feb 2020 14:35:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931086.19931.16753354350257673252@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:10 -0800 Archived-At: Subject: [MLS] mls - Requested session has been scheduled for IETF 107 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:17 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mls Session 1 (2:00 requested) Monday, 23 March 2020, Afternoon Session I 1330-1530 Room Name: Georgia B size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/mls.ics Request Information: --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack Key Participant Conflict: acme artarea dispatch perc People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: Chair Conflict: Privacy Pass BOF --------------------------------------------------------- From nobody Sat Feb 29 23:41:02 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1775D3A0991 for ; Sat, 29 Feb 2020 23:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=n7JPaqQE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V1CBhCmm 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 ic0vLF1cgIol for ; Sat, 29 Feb 2020 23:40:58 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08513A0995 for ; Sat, 29 Feb 2020 23:40:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C0D01550 for ; Sun, 1 Mar 2020 02:32:24 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 01 Mar 2020 02:32:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=nltOZTKC+k9T4K4cYuK+PhMoYkXMeVzVIU6XB0QktkA=; b=n7JPaqQE dM3tF0FJ3ki0xeUMbCbsH0QNRIcWo2SCX3igVxC6jn0Fs3xFDXSiEKbTVG5j2BEC OYqKCNtUdiPzdotzJcQ9m27C1bwzT1STLj/VOXQIt0ggZimZmQ0DxLCgYayVCpe7 S/F4eCaGrfrbOOPAhdgALaFi7ku0JbpFleyvb0sim0p1bLkrD1x1BCL/iglrabis jSLog7QTG06jVWkOocO5KWgduigXDzpTdj5TefbP6+Bu36ktkMbcmuomz2igH+Cl FjImWxn6f0eIBwStihh03bkyJPUnJzUruKVtY7SK8a/3IEg6pumR0BJvFQpll9vb Lsw0aDyDE0anWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=nltOZTKC+k9T4K4cYuK+PhMoYkXMe VzVIU6XB0QktkA=; b=V1CBhCmmRwjGK30Da39KIUUd+T+fptphEoPPAiS0aWS1Y ZUWWyd/OU5Fz8D+iT+g/8oArCu2Iq0rLJRyuJXFE5fV52eGlM/pE504dWs15X+Al 5wEwXxHGH/DXhOh4S0a+qPCGYLx6MGtErIG+L1oYXuK1aBOth41N/ItNIQ+mJ81l z4pkm88SMgia44+OwG7Z0UbVNdQ8jCxKuzLr4GBBvFIQNEZg/M5yRpB9smyegUlh PD1AUk4Kyd1J0Ta4vuakr1R/WyVBYWVxLlqcxErkMlX1ajFLVZerly1GoP+GQHsJ 6smXX/7/LDzy6NDQEl6tXzZ1Yec8/wXNyx87ye00w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtuddguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmnecukfhppeehvddrudejledrudefvddrudegvdenucevlhhu shhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprh gvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [52.179.132.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 39FA7328005A for ; Sun, 1 Mar 2020 02:32:24 -0500 (EST) Content-Type: multipart/alternative; boundary="===============7085300231998516960==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200301073224.39FA7328005A@mailuser.nyi.internal> Date: Sun, 1 Mar 2020 02:32:24 -0500 (EST) 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, 01 Mar 2020 07:41:00 -0000 --===============7085300231998516960== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-protocol (+2/-0/=F0=9F=92=AC0) 2 pull requests submitted: - Update MLSPlaintextTBS struct to match MLSPlaintext. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/309=20 - Remove nonce from SenderData AAD. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/308=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============7085300231998516960== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday March 01, 2020

Pull requests

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

2 pull requests submitted:

Repositories tracked by this digest:

--===============7085300231998516960==--