From nobody Sat Dec 4 23:30:17 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76C53A1214 for ; Sat, 4 Dec 2021 23:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 0Yf5Gvq6_o1N for ; Sat, 4 Dec 2021 23:30:13 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 781DC3A1213 for ; Sat, 4 Dec 2021 23:30:13 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id 77-20020a1c0450000000b0033123de3425so8099065wme.0 for ; Sat, 04 Dec 2021 23:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:from:to:subject; bh=O8E60PKKpoQOIuu34PBQxR21CjwlyoHRqGq0pLDnC4I=; b=XTXh4E2y7RnVw8StEgnQ8W0sS+extiOC9FGyEa2EbwDtm7H7SUx46oMVRfpR02Y/do zE1v4GOMTASshEEHMDUUhPbEI+MhdVH8MmRmjKkX/iTjHdfMnP0BKa4bzAMed27V8UY5 y83t8EQHGy/ZjD5KHvL6qn8P0fp8m3xdJmRgVqArGL9FKwfY11vMVg/4oX7n4gwm+vFH yZi9SBdTKNhyqKGuFFmQnrnx0bNo3Sb0PJSkqmJciTcKO+1OhpsgyDlrY5Mo9JJycOvz ISK/TJDF8Crkm8v5//LVrWmXFl2OeIy8b4a3oC1NpiFh7KBHMT6z4fYrgd6/ZiL8A2I9 uGFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:from:to:subject; bh=O8E60PKKpoQOIuu34PBQxR21CjwlyoHRqGq0pLDnC4I=; b=UEy0fB5ZOSkWZnDO9MQSTdw21UJKemRlGdEDqQYx8UkOqarFTtjyEyqd9xXF+zBNeT R8Efm8Frd+0luxMblecm3o1b/vQMMVvQqd2TxUfosPUmjsFRzhsSv74rRhd7ZoywnijD oj4g8vSKYUZsXwyg7gYWV0WEM1zLi/0EUEKPSdLI5JcJCuCid0Gr2cPG8edBevi8SWPG R7BI3zZAWVAfslw2T1Jo1fE7tff7sN5JFmLihQof6O/IFlgodr6tis7EhlbAXSOUrWZs LB3OKY/dGrk/3zMzsF5b9nTIdnjhRaMJY5pIZS29WDvtABYekvi3TPyep9+7Lv9yDyKy MHww== X-Gm-Message-State: AOAM531CZHgma2B5dXA82X5qj5sTacjjhZmAR9DtumO7Xm1aUhlzWddO TEgbRmnVuE7/bthX1CEdSxT8AZIjecs= X-Google-Smtp-Source: ABdhPJw1m8CQw4sy73wEza39mq6Yc2qozHmmMtR9/tfsaXou8jV7QG0cdBBUZ/EU6B5bDJYAfxEu/A== X-Received: by 2002:a7b:c744:: with SMTP id w4mr30020629wmk.50.1638689409836; Sat, 04 Dec 2021 23:30:09 -0800 (PST) Received: from basil.dsg.cs.tcd.ie (basil.dsg.cs.tcd.ie. [134.226.36.138]) by smtp.gmail.com with ESMTPSA id w22sm7124200wmi.27.2021.12.04.23.30.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Dec 2021 23:30:09 -0800 (PST) Message-ID: <61ac6a81.1c69fb81.66386.7ecb@mx.google.com> Date: Sat, 04 Dec 2021 23:30:09 -0800 (PST) Content-Type: multipart/alternative; boundary="===============2909270712005212067==" MIME-Version: 1.0 From: Webmaster via GitHub API To: lake@ietf.org Archived-At: Subject: [Lake] Weekly github digest (reqs, edhoc) X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2021 07:30:15 -0000 --===============2909270712005212067== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * lake-wg/edhoc (+1/-0/=F0=9F=92=AC3) 1 issues created: - Error message =3D> Discontinue (by gselander) https://github.com/lake-wg/edhoc/issues/208=20 3 issues received 3 new comments: - #208 Error message =3D> Discontinue (1 by gselander) https://github.com/lake-wg/edhoc/issues/208=20 - #204 Length of labels, removal of master (1 by emanjon) https://github.com/lake-wg/edhoc/issues/204=20 - #178 Security considerations of TOFU (1 by gselander) https://github.com/lake-wg/edhoc/issues/178=20 Pull requests ------------- * lake-wg/edhoc (+3/-1/=F0=9F=92=AC0) 3 pull requests submitted: - Updated Internet Threat Model considerations (issue #198) (by emanjon) https://github.com/lake-wg/edhoc/pull/207=20 - EAD internal structure and the EAD API (issue #186) (by emanjon) https://github.com/lake-wg/edhoc/pull/206=20 - Length of labels, removal of master (issue #204) (by emanjon) https://github.com/lake-wg/edhoc/pull/205=20 1 pull requests merged: - Updated Internet Threat Model considerations (issue #198) https://github.com/lake-wg/edhoc/pull/207=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/lake-wg/reqs * https://github.com/lake-wg/edhoc --===============2909270712005212067== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (reqs, edhoc)

Sunday December 05, 2021

Issues

lake-wg/edhoc (+1/-0/=F0=9F=92=AC3)

1 issues created:

3 issues received 3 new comments:

Pull requests

lake-wg/edhoc (+3/-1/=F0=9F=92=AC0)

3 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:
--===============2909270712005212067==-- From nobody Sat Dec 11 23:30:21 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678303A07BF for ; Sat, 11 Dec 2021 23:30:18 -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, HTML_MESSAGE=0.001, 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=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 B90_Nh6TX6d0 for ; Sat, 11 Dec 2021 23:30:15 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 CE42C3A07BC for ; Sat, 11 Dec 2021 23:30:14 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id t18so21857461wrg.11 for ; Sat, 11 Dec 2021 23:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:from:to:subject; bh=51f6pRjNGHnEJYxEEJ9uM0ugaanDBs+vlt09Fx4lEXY=; b=LW3lF3snOgPXv15MzzQF/2EP7EWzlxw+ndn/SUnW4hBRmecbiblHgmcBz6vfpibyxO uXK67v8IVGqm2ViYNvKbqnDHPIf8aoDwisDFFp1yzeTvwvDU47iwBQP+6VtgboOfCXFz NIZRO4y6sVtvVgdEQ7zJ2SY+Phb9dliw2aM/ZH0HGZElI1C1gXmFDuoY0/QYbXlOjp8l Xqj5UKY2w5HzVRmLLqOXaV3tfdSlgWIB4ZcKuzDs24TPYZtKHwyOs7OoQa2PhPIpipRS bVqP8sYJQSilrmbd8fZdPfZjPCkx3r1nrFl5mye9dMGzT4ja9YQUOETWg3rB4uA/GEeS HRcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:from:to:subject; bh=51f6pRjNGHnEJYxEEJ9uM0ugaanDBs+vlt09Fx4lEXY=; b=6/s/YPvH16KFJvPmx2XBPNCTibLqzrTiR9kRJDPACpJWb42cDk9MnHl+E6JTfuGxVa Vh+Zap9pKUcjKTEsUXAFyaGjRo5Dwxbr4cnAZUflbQLZPqhxw9qipl+xeDAmiMI9aVyh d/5zoaQjY3XfbzJyt/k1z9OhssCdarZde9pTuZCcgCJgOlvKj33quzjctBTCiZrBFZqW pagqYOfw5aYgC1vm5tbwiQgGc5y9hEYZty/hpdsrIXpM+3qLZGPI2vMnXraEVEtiWLS2 5+0SKTBBV/R+9d3xHaDPFdwaZDAB/PdjP5npmHooyClb2jDvi/SxBczJLHzZ+441x3Ox bDjA== X-Gm-Message-State: AOAM530j8TLaBZ6JhNqX5Pmv51AQumM3Rs2tL/NW+6Zs/Co+R1OwfdCg jzB23v5MdsIfgAYdFJCdQsAQAxfuvCY= X-Google-Smtp-Source: ABdhPJzXdP7S8wP1MG8tCGOXisi9tSBsCNTcqpbSkolKGF53nr7NkPV0anzL//IhT5emoDMPmB0Qew== X-Received: by 2002:adf:f24a:: with SMTP id b10mr8434284wrp.607.1639294212341; Sat, 11 Dec 2021 23:30:12 -0800 (PST) Received: from basil.dsg.cs.tcd.ie (basil.dsg.cs.tcd.ie. [134.226.36.138]) by smtp.gmail.com with ESMTPSA id l1sm6799421wrn.15.2021.12.11.23.30.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Dec 2021 23:30:12 -0800 (PST) Message-ID: <61b5a504.1c69fb81.331a9.49d3@mx.google.com> Date: Sat, 11 Dec 2021 23:30:12 -0800 (PST) Content-Type: multipart/alternative; boundary="===============7875772384688058116==" MIME-Version: 1.0 From: Webmaster via GitHub API To: lake@ietf.org Archived-At: Subject: [Lake] Weekly github digest (reqs, edhoc) X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2021 07:30:19 -0000 --===============7875772384688058116== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * lake-wg/edhoc (+6/-0/=F0=9F=92=AC13) 6 issues created: - Verification of identities in X.509 and CWT (by gselander) https://github.com/lake-wg/edhoc/issues/215=20 - Security considerations on gererating secret material and public materi= al such as connection IDs. (by emanjon) https://github.com/lake-wg/edhoc/issues/214=20 - Security considerations on connection IDs (by emanjon) https://github.com/lake-wg/edhoc/issues/213=20 - Shorten 3.5 (by gselander) https://github.com/lake-wg/edhoc/issues/212=20 - Add appendix about the use of EAD (by gselander) https://github.com/lake-wg/edhoc/issues/210=20 - Change MTI cipher suite to (0 AND 1) OR (2 AND 3) (by gselander) https://github.com/lake-wg/edhoc/issues/209=20 6 issues received 13 new comments: - #214 Security considerations on gererating secret material and public m= aterial such as connection IDs. (1 by gselander) https://github.com/lake-wg/edhoc/issues/214=20 - #212 Shorten 3.5 (1 by emanjon) https://github.com/lake-wg/edhoc/issues/212=20 - #210 Add appendix about the use of EAD (2 by emanjon, gselander) https://github.com/lake-wg/edhoc/issues/210=20 - #209 Change MTI cipher suite to (0 AND 1) OR (2 AND 3) (3 by emanjon, g= selander) https://github.com/lake-wg/edhoc/issues/209=20 - #208 Error message =3D> Discontinue (2 by emanjon) https://github.com/lake-wg/edhoc/issues/208=20 - #201 Minor cryptographic explanations (4 by emanjon) https://github.com/lake-wg/edhoc/issues/201 [Close?] [Done in master]=20 Pull requests ------------- * lake-wg/edhoc (+1/-0/=F0=9F=92=AC2) 1 pull requests submitted: - Updates following Stephen's review (by gselander) https://github.com/lake-wg/edhoc/pull/211=20 2 pull requests received 2 new comments: - #211 Updates following Stephen's review (1 by gselander) https://github.com/lake-wg/edhoc/pull/211=20 - #199 Updates following Marco's review (1 by gselander) https://github.com/lake-wg/edhoc/pull/199=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/lake-wg/reqs * https://github.com/lake-wg/edhoc --===============7875772384688058116== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (reqs, edhoc)

Sunday December 12, 2021

Issues

lake-wg/edhoc (+6/-0/=F0=9F=92=AC13)

6 issues created:

6 issues received 13 new comments:

Pull requests

lake-wg/edhoc (+1/-0/=F0=9F=92=AC2)

1 pull requests submitted:

2 pull requests received 2 new comments:

Repositories tracked by this digest:
--===============7875772384688058116==-- From nobody Mon Dec 13 06:47:18 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7083A00E5 for ; Mon, 13 Dec 2021 06:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 lIyvUEMEKzEf for ; Mon, 13 Dec 2021 06:47:11 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2058.outbound.protection.outlook.com [104.47.13.58]) (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 AD7B83A0128 for ; Mon, 13 Dec 2021 06:47:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c0Nm6gk1UtxhApiwTsCrUEs8tUQpWsi4Rz0tJn9cE1bY1ioLpHCC1exmZwWYs1IRhtWWKmSeMgGcrxxh6qjfwG4PSqh2aodk46rCuG04zX8iWqFuTDnOIDos9kjB5gaXqAeHtv3qDcM+2PHGViXixNVxDVHAUAStRqr38O7xSA4gEZL6SYR9XC632xGMq8wmqgkjXutwjsWMLsFmvfLWIuxP76MgJckT9EJ10aHwT2aIOXQPkqePWiljIJuObIAGK2I8tXrlHmg2uQNZzuU6OydcBGE2ojpht2P6h4G6+2LKEq0YBKQDiIhG+BvrQUGouh1pbkosEDLdIIq4gADv3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=P6RFyxvZDF0hYghuAYOGppygLF7gmGrrX1mxSGDhX7I=; b=NoppvsiYPwmysV7R0B38isKz5L6DnbJR6mRw/lFuzYiZDW/KP6BJsmQgl5H3un2X8l8f8ZBMBp+z8kBYJUZqG+U7QsbjjydWmYdC/Xm/C583ezIGvqEQu8te1/pZ3BJK9l2MANws+r3hqpvcYSBVF2g55FjdErk054nQTx88yvOFP93RR7xrltp3biQBhXUGYfNP61hJyOz/NikZlimcsdiTi7bWDseyuz6uTeGvH4fAIOb5dPlwY9yiiouR/MhdGeM230XUpFkOwcUwNKSix6bSN20xmBOTrrjThDxpxpEAKN7vLNf9skL/rmP9XfnxqT5ngUxD2J1hrz4X3suGrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P6RFyxvZDF0hYghuAYOGppygLF7gmGrrX1mxSGDhX7I=; b=qdPHsS/Hyb18ifwcQ9USRlIJZADelpg8E/oQ5GDSEqmJaTTi/E+ECunoKA+NUw9v3lKbhTYcQ33EaqEnBlscIzwvXl2VevqsGPp60kqgb6P0KirpSSh+b1anpN0zzDaPVU5F3EeS/VpzQOJubWpFWuP4+o4dTPnPQdSJ360NFVg= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM4PR0701MB2100.eurprd07.prod.outlook.com (2603:10a6:200:4b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.13; Mon, 13 Dec 2021 14:47:02 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4801.013; Mon, 13 Dec 2021 14:47:02 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Marco Tiloca , "lake@ietf.org" Thread-Topic: [Lake] Review of draft-ietf-lake-edhoc-12 Thread-Index: AQHX0M+U3ZO5X7wwWEat1MQe9YOC86wfBaBf Date: Mon, 13 Dec 2021 14:47:02 +0000 Message-ID: References: <5bc7e680-1513-f838-1188-8e2b67630430@ri.se> In-Reply-To: <5bc7e680-1513-f838-1188-8e2b67630430@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 27230665-54bc-6613-4e9b-a27e0993a708 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d28ab516-110c-4762-da4f-08d9be476ca1 x-ms-traffictypediagnostic: AM4PR0701MB2100:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cTUG6lrQzukmphADTL31hY2Gt8A3hVXxrj0nXGOPTB7jwDQtNQdc5Ju9BfumQAB5ifCsgpYxfibXHvrVEakfJDQ247M486aMsRnYIthGlPD5Fo4DHOf+kVi8aaA3ugXW1E6uUcO2+FB9R6sBjTGc/xpr59Ao/FOt8ePWaagGv2N75xWgwsivtDO8LNzDn1qT7cOQcHQKxLHh9AwMFthsaPJxbRSp8RxB456avVl5k48Ga2BzmSTGb1qJUjnF71PUQhxTf3ZgsTpdlUkz9fU02UnKoCjMJcmzMCpo8jS+7sM7SDZR6aTprzwDmVa2sJK3feZK0KOFk5yZPyEXk7Xttx1Jqrnr9WAco3mBxnyVAe8KeaeS04vieTYD8Csk2WsfoXC6Hj0zwOYvWNmnq48pPTYivzxs3jkeuKqix4zAJnyLjQVjGAlYbfVM08r6YtV4fu+tD/ykSgmPUrtSZ6/sp2kWwWG2pnuNwfvf/YWWx1aJoXJsiIWqjlw9PkMYFXtRUSV/UwTI1Iik//9m8RjDD+Pyd1h2FpuANCtO2+mmXuXjLTaEldRMkZCXJqrK/LS8OIFqHmQhW1NoSJz/k4GVMzpZzXxgzWRblFWJ+zXb9TYpQQmOD3MNQC1QF/GLoWOW8iMwVDHXrt8S1KHlqSeainuX/RKdIuPh+tTuR44q5LiDrFYHDQs9C0AxJ2q0d9aCoPAnhsijTQWcjnttv7+g8g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(33656002)(82960400001)(186003)(122000001)(38100700002)(52536014)(2906002)(5660300002)(19627405001)(30864003)(55016003)(8936002)(110136005)(8676002)(66556008)(91956017)(66476007)(64756008)(38070700005)(86362001)(66946007)(66446008)(316002)(6506007)(7696005)(9686003)(71200400001)(53546011)(76116006)(66574015)(83380400001)(508600001)(559001)(579004)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Ta/JZ8mjrWV4xW7tLe86Ep5va/P6a74h4PYD0gQs93k6/8/rkj1yPGr6AD?= =?iso-8859-1?Q?ITgUWrNzzB21blnjcui0H9Y9b8j2yjCp/jE2KRyiCMMzUbsq+7Np49J/Ff?= =?iso-8859-1?Q?Guuqi1Nog3hRu+m4AFUhdBF5x1mFzAFwigfHG8JHYsznWuYVs7wXDVvc2A?= =?iso-8859-1?Q?XB/mJ8vt3jByiUv4HbfSQovHP4LOn+EbPtiHaBctFcFYCsw/4bjSbyOhBV?= =?iso-8859-1?Q?6s5IV73HGlyk4mvFEMW3VXInwAc3+HXOW85xCu42StGd7wSVysYVCfS2iZ?= =?iso-8859-1?Q?3RGZ6aKCv4tFAI/ddjl4rDUxoHia5a6ebHaRB4nOHaWEkQPneKWyBb9UG4?= =?iso-8859-1?Q?T4YSwCUmyqw2Vq8hmH2vmCUgZ0TOO98Pa7XfLFNJCbpPMaSLgR0m7fnCsd?= =?iso-8859-1?Q?eylDcLj84JOPYUwl0+x+Wp7ctl1bIl5LVfcfilb89NrD+OJn876cNZTLZY?= =?iso-8859-1?Q?ZsbmzSiT8FLe+QJ9HQY5Cn58u70FWG6rthM0HsbUiPoJUiGiSv8u+Xy3Zc?= =?iso-8859-1?Q?RFZLG55YiIEUvS5aZNmhcrzZO8yR98Ld5xqqWZznipu2OD7NdYajmGq38R?= =?iso-8859-1?Q?GwjcUD1UcFvSN1O4veDbp6/1kdaEccR4NtRmNWEgHVl4tjstPWrPf9IF/l?= =?iso-8859-1?Q?tsxTx8XQW6NsxB9qabY/CI7L1WyWXomBmDDLhBTnyASX+u2ZVlNdVCnW91?= =?iso-8859-1?Q?GyL+DzXMt2E/h3cCw9zgSN6kG+Fvjkd0+9GF6a4Aw/qOa9Naek++3SCHQp?= =?iso-8859-1?Q?84ds8Fl6cyRtCahjvdJU3NqeB2ttFzjhdH5fFuU7O0HKwHes7HdroTud1z?= =?iso-8859-1?Q?0tsbqyJbnkuQ0pJLEmgC9kjUVGfQZdjVClRZSCIActQNRbBkHT/GunhFs+?= =?iso-8859-1?Q?rdZf42xJRBZqSZTPmf40lhUtstPjTpO25w0EHRwiVsukQmZZPy93z5inEk?= =?iso-8859-1?Q?LL+5qc5zZ1xpkOQ/4qBfOzWF7uMDxsrdncFfB0CGcTNnN3hpgm9Y/jww9J?= =?iso-8859-1?Q?agqfB0GerxGp0V8Li2j8ml1iTFc2gGyGfMoNdPHkiM1D8Nz9bByRywDU/d?= =?iso-8859-1?Q?w70U4Rz2he7bD3co1/YZxEBphCMf3O/NkHJH+dINGIj47MVInz8cbrAdyI?= =?iso-8859-1?Q?nL7o7+WI46kYFH32RxM1A4tAFOJWGp1ZmdGlXR1HhpCcy62miJGlIeYcf3?= =?iso-8859-1?Q?sMImAICdUhA0NxIyE2dFmiALQB+2d1krNPXU8fIfuL8uiSRsxOCndJB7QA?= =?iso-8859-1?Q?lwN474Qpbhm+Kwtmc/mi2EIL8pMEDp6ZNrYtl0IFBPQ7cAqZiXlubXLJvf?= =?iso-8859-1?Q?w9Ih0hHim9TS5rPvNTZD9DHRfG6MXdYXlCPKHJEJMJgFcfHBH4+0KawNJI?= =?iso-8859-1?Q?wGaTfEj05BBWNOUBEEV8quxSIcVeK2Ty37eT5He8SfKlo67GvA9kvLbHDi?= =?iso-8859-1?Q?ivNnwCizHAjecbsnizbUGQbvNsXDJYcjXo9s4UZrIcPGXV1rp/XcNtFAwy?= =?iso-8859-1?Q?DmOtQ+XmK5RIRLlb4WKKjWxje/hXzAsS+dztsTM0Hbw6ErtgVbi5txBtci?= =?iso-8859-1?Q?7D/ToHGa5Lzs3qBtm0dd2/Jk/k70WtlxypoWFchOkdoVx9wQ6RdYN1NgQn?= =?iso-8859-1?Q?mAWGUtabxmPt06p4nvQm44x3cSm2GTXT5PP9ldoLVHH3YfnkBCWChGsPz9?= =?iso-8859-1?Q?e+7EBVJgh9sfUe1VuHPO/zjcaQRVQSK2L6RE0cBWh6avVJZ2fYT+wj+cTb?= =?iso-8859-1?Q?jkqg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB219541145A4E91D7624F5E3AF4699AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d28ab516-110c-4762-da4f-08d9be476ca1 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2021 14:47:02.3356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vZ1W2BqTM2q3bjHCFjac4zBvjNUXE1/2Qm2+X2pF0AjsgvSlhK8G0h5C/ohkPEhY5HmPLqdz4912oAh3teoBNjyBHTuZf8GDB2jzHMM55+o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2100 Archived-At: Subject: Re: [Lake] Review of draft-ietf-lake-edhoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 14:47:16 -0000 --_000_AM4PR0701MB219541145A4E91D7624F5E3AF4699AM4PR0701MB2195_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Marco, Thanks for the review. It is recorded as github issue #192 and a proposed u= pdate to the draft is in PR #199. Comments inline. Please let us know if you have further comments on the upd= ates made or if it is OK to merge #199 and close #192. From: Lake on behalf of Marco Tiloca Date: Wednesday, 3 November 2021 at 17:26 To: lake@ietf.org Subject: [Lake] Review of draft-ietf-lake-edhoc-12 Hi all, As promised, please find below my review of EDHOC v -12. Best, /Marco =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Section 1.1] * "This specification focuses on referencing instead of transporting credentials to reduce message overhead." It is possible to transport credentials both by reference and by value. What suggests the case of transport by reference to be the "focus"? Perhaps you mean that it is possible and preferable/recommended to transport credentials by reference? [GS] According to the requirements document draft-ietf-lake-reqs-04, the in= itial focus as of June 2020 was on RPK (by reference and value) and certifi= cate by reference. Since then several participants have requested the draft= to be more explicit about how to use ID_CRED_x for transport of credential= s, which just follows from the use of COSE. I rephrased as: NEW This specification emphasizes the possibility to reference rather than to t= ransport credentials in order to reduce message overhead, but the latter is= also supported. * "future algorithms and credentials targeting IoT" This probably means "future algorithms and identity credential types targeting IoT". [GS] The term "identity credential" is not previously used in the draft so = I settled for "credential types". * s/compromise of the long-term keys/compromise of the long-term identity keys [GS] The term "identity key" is not used elsewhere in the document. The ter= m "long-term key" is used throughout the document including the security co= nsiderations and is a common term used in protocol analysis which is what t= his text talks about. So I think it makes sense to not change here. The alt= ernative would be to talk about "private authentication key" which is also = used in the document, but more in the context of identities. [Section 1.3] * s/the number of bytes in EDHOC + CoAP can be/the EDHOC message size in bytes when transferred in CoAP can be [GS] Changed to NEW the EDHOC message size when transferred in CoAP can be [Section 1.5] * "and CDDL [RFC8610]. The Concise Data Definition Language (CDDL) is used to express CBOR data structures [RFC8949]" can be rephrased as: "and the Concise Data Definition Language (CDDL) [RFC8610], which is used to express CBOR data structures [RFC8949]" [GS] Harmonizing with previous references, and removed the reference to CBO= R which is already in this paragraph, I changed to: NEW "and the Concise Data Definition Language (CDDL, [RFC8610]), which is used = to express CBOR data structures." [Section 2] * "Verification of a common preferred cipher suite" Shouldn't this say: "Verification of a commonly supported cipher suite which is most preferred by the Initiator" ? [GS] Changed to NEW "Verification of the selected cipher suite" [Section 3.2] * In Figure 4, the second and third column can rather have labels "Initiator Authentication Key" and "Responder Authentication Key". [GS] Done. Also replaced first column label "Value" with "Method Type Value= ". [Section 3.3] * "or in a subsequent application protocol" can be expanded as: "or of an application/security context in a subsequent application protocol" [GS] Changed to NEW or in subsequent applications of EDHOC [Section 3.4.1] * "EDHOC transports that do not inherently provide correlation across all messages of an exchange" can be rephrased as: "Transports that do not inherently provide correlation across all EDHOC messages of an exchange" [GS] Done [Section 3.5.1] * "The EDHOC implementation or the application must enforce information about ..." can be rephrased as: "The EDHOC implementation or the application must take a decision on allowing or not a connection based on information about ..." [GS] Changed to NEW The EDHOC implementation or the application must decide on allowing a conne= ction or not depending on the intended endpoint * s/if it is allowed to communicate with/if it is allowed to communicate with those [GS] Rephrased to harmonize with PKI text. Note that further changes are ex= pected to 3.5 following Stephen's review comment about restructuring. [Section 4.3] * The context can for example be the empty (zero-length) sequence or a single CBOR byte string. Isn't the context supposed to be just a single CBOR byte string? See how it is defined in Section 4.2 when introducing Expand. [GS] Changed to: NEW The context can for example be the empty CBOR byte string. * s/where H() is the hash function/where H() is the EDHOC hash algorithm [GS] Done [Section 5.1] * s/a second time for EDHOC processing/a second time for EDHOC processing within the same ongoing session [GS] Fixed. [Section 5.2.3] * "If an error message is sent, the session MUST be discontinued." Is this sentence actually required? Regardless sending an error message or not, the session is discontinued if any processing step fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing step fails? [GS] This sentence does not talk about failed processing, it is a general i= mplication stating the necessity of discontinuing the session if an error m= essage is sent (for whatever reason), in contrast to the converse statement= in the preceding sentence which states that there is no necessity of sendi= ng an error message if the session is discontinued. I opened issue #208 for= potential further discussion on the topic. [Section 5.3.1] * "G_Y, the ephemeral public key of the Responder, and ..." Just to avoid any risk to interpret this as the concatenation of three elements, I suggest to rephrase as: "G_Y (i.e., the ephemeral public key of the Responder) and ..." [GS] Done. [Section 5.3.2] * s/H() is the hash function in/H() is the EDHOC hash algorithm in [GS] Done * "is the 'signature' field of a COSE_Sign1 object as defined in Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm ..." should be rephrased as: "is the 'signature' field of a COSE_Sign1 object as defined in Section 4.2 of [I-D.ietf-cose-rfc8152bis-struct], computed as defined in Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] by using the signature algorithm ..." [GS] I think it suffices to refer to how it is computed, which in turn refe= rences how it is defined: NEW is the 'signature' field of a COSE_Sign1 object, computed as specified in S= ection 4.4 of {{I-D.ietf-cose-rfc8152bis-struct}} using the signature algor= ithm [Section 5.3.3] * "If an error message is sent, the session MUST be discontinued." Is this sentence actually required? Regardless sending an error message or not, the session is discontinued if any processing step fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing step fails? [GS] Same as above [Section 5.4.2] * s/H() is the hash function in/H() is the EDHOC hash algorithm in [GS] Done * "is the 'signature' field of a COSE_Sign1 object as defined in Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm ..." should be rephrased as: "is the 'signature' field of a COSE_Sign1 object as defined in Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct], computed as defined in Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] by using the signature algorithm ..." [GS] Same as above * s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct] [GS] Done [Section 5.4.3] * s/or the prepended C_I/or the prepended C_R [GS] Done * s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct] [GS] Done * "If an error message is sent, the session MUST be discontinued." Is this sentence actually required? Regardless sending an error message or not, the session is discontinued if any processing step fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing step fails? [GS] Same as above * s/no other party than the Responder/no other party than the Initiator [GS] Done [Section 5.5] * "In deployments where no protected application message is sent from the Responder to the Initiator, the Responder MUST send message_4." Consider to rephrase as: "In deployments where no protected application message is sent from the Responder to the Initiator, message_4 MUST be supported and the Responder MUST send message_4" [GS] Changed to ", message_4 MUST be supported and MUST be used" to apply t= o I as well as R. "Responder MUST send message_4" is still strange, would about I? Maybe just= "message_4 MUST be used"? [Section 5.5.2] * s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct] [GS] Done [Section 5.5.3] * s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct] [GS] Done * "If an error message is sent, the session MUST be discontinued." Is this sentence actually required? Regardless sending an error message or not, the session is discontinued if any processing step fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing step fails? [GS] See above [Section 6] * s/error SHALL be/An error message SHALL be [GS] This change is not done, note that "error" refers to the name of the C= BOR sequence defined below. [Section 6.3] * "Error code 2 MUST only be used in a response to message_1 ..." can be rephrased as: "Error code 2 MUST only be used when replying to message_1" , avoiding to use words like "request" and "response". [GS] Done [Section 6.3.2] * s/the Responder shall only accept message_1 if/the Responder SHALL accept message_1 only if [GS] Done * The last two paragraph are not further comments on the examples, but are rather related to the cipher suite negotiation. I think they better fit as last paragraphs of Section 6.3.1. [GS] Done [Section 8] * "Compromise of PRK_4x3m leads to compromise of all exported keying material derived after the last invocation of the EDHOC-KeyUpdate function.= " I suggest to expand as follows: "Compromise of PRK_4x3m leads to compromise of all exported keying material derived from that key through the EDHOC-Exporter function. If the EDHOC-KeyUpdate function has been used to renew PRK_4x3m, the compromise is limited to the exported keying material derived from the PRK_4x3m installed after the last invocation of the EDHOC-KeyUpdate function." [GS] Changed to NEW Compromise of PRK_4x3m leads to compromise of all keying material derived w= ith the EDHOC-Exporter since the last invocation (if any) of the EDHOC-KeyU= pdate function. [Section 8.6] * The way the first paragraph starts is probably a remnant of when CoAP was still part of the document body rather than in Appendix A. Also, as later discussed in Appendix A.3, the Echo exchange is started by a CoAP server, regardless if it acts exactly as Responder. I suggest to rephrase the paragraph as follows. "EDHOC itself does not provide countermeasures against Denial-of-Service attacks. In particular, by sending a number of new or replayed message_1 an attacker may cause the Responder to allocate state, perform cryptographic operations, and amplify messages. To mitigate such attacks, an implementation SHOULD rely on lower layer mechanisms. For instance, when EDHOC is transferred as an exchange of CoAP messages, the CoAP server can use the Echo option defined in [I-D.ietf-core-echo-request-tag], which forces the CoAP client to demonstrate its reachability at its apparent network address." [GS] Done [Section 8.7] * "... but intended to simplify ..." Since "security context" is mentioned in the following sentences, it is better to explicitly mention that they are referring to the application protocol and not to EDHOC anymore. [GS] I didn't make this proposed change because "security context" is not l= imited to OSCORE, so this sentence applies also to EDHOC. If you still find= this misleading, please explain in what way it is so. [Appendix A.3] * "EDHOC message_2 or the EDHOC error message is sent from the server to the client in the payload of a 2.04 (Changed) response. EDHOC message_3 or the EDHOC error message is sent from the client to the server's resource in the payload of a POST request. If needed, an EDHOC error message is sent from the server to the client in the payload of a 2.04 (Changed) response." This text should also be a remnant of old versions. When using EDHOC for OSCORE, EDHOC error messages as CoAP responses are sent as error responses, see the first paragraph in Appendix A.3.1. The text above can rather, more generically, be: "The server sends to the client EDHOC message_2 in the payload of a 2.04 (Changed) response, or an EDHOC error message in the payload of a response. If needed, the client sends to the server an EDHOC error message in the payload of a POST request. Otherwise, the client sends to the server EDHOC message_3 in the payload of a POST request. If needed, the server sends to the client an EDHOC error message in the payload of a response." [GS] Good spotted, I modifed the original text in a different way: NEW EDHOC message_2 or the EDHOC error message is sent from the server to the c= lient in the payload of the response, in the former case with response code= 2.04 (Changed), in the latter with response code as specified in Section 8= .3.1 EDHOC message_3 or the EDHOC error message is sent from the client to= the server's resource in the payload of a POST request. If EDHOC message_4= is used, or in case of an error message, it is sent from the server to the= client in the payload of the response, with response codes analogously to = message_2. [Appendix A.3.1] * The last sentence can be extended, to mention what additionally is defined in draft-ietf-core-oscore-edhoc, besides the EDHOC+OSCORE request. This includes especially: a deterministic and efficient conversion from OSCORE Sender/Recipient IDs to EDHOC connection identifiers; web-linking and target attributes for discovering of EDHOC resources. [GS] Done [Nits] * Three instances of "key material" should be "keying material" for consistency. [GS] Done * Section 3.3.1, s/and sends in message_2/and sends it in message_2 [GS] Done * Section 3.3.2, s/and a EDHOC connection/and an EDHOC connection [GS] Done * Section 3.6 --- s/pre-defined int label/pre-defined integer label --- s/Implementation can either use/Implementations can either use [GS] Done * Section 3.7, s/requires an 'y' parameter/requires a 'y' parameter [GS] Done * Section 3.8, s/protected out of scope of EDHOC/whose protection is out of the scope of EDHOC [GS] Done * Section 3.9 --- s/verifying cipher suite/verifying a cipher suite --- s/know identity of Responder/know identity of the Responder --- s/know identity of Initiator/know identity of the Initiator [GS] Done * Section 4.3, s/same key kan be/same key can be [GS] Done * Section 5.1, s/then process according to Section 6, else process as/then process it according to Section 6, else process it as [GS] Done * Section 5.3.2, s/facilitate retrieval of/facilitate the retrieval of [GS] Done * Section 5.4.2 --- s/facilitate retrieval of/facilitate the retrieval of --- s/intialization vector/initialization vector --- s/or derived application keys/or derive application keys [GS] Done * Section 5.4.2, s/intialization vector/initialization vector [GS] Done * Section 6.3.2, s/then Responder MUST discontinue/then the Responder MUST discontinue [GS] Done * Section 8, s/protection is provided/protection are provided [GS] Done * Section 8.2 --- s/and instead rely/and instead relies --- s/the Responders identity/the Responder's identity --- s/Requirement for how/Requirements for how [GS] Done * Section 8.6 --- s/forces the initiator/forces the Initiator [GS] Done * Section 9.6, s/an CWT Claims Set/a CWT Claims Set [GS] Done * Section 9.14, s/is defined as/are defined as [GS] Done * Appendix A.3, s/using resource directory/using a resource directory [GS] Done * Appendix B, s/compatibily/compatibility [GS] Done * Appendix C.1, s/dignostic/diagnostic [GS] Done * Appendix E --- s/which does not handle/which do not handle --- s/with respect the current/with respect to the current [GS] Done * Appendix F, s/for message 1/for message_1 [GS] Done Thanks! G=F6ran --_000_AM4PR0701MB219541145A4E91D7624F5E3AF4699AM4PR0701MB2195_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Marco,

 

Thanks for the review. It i= s recorded as github issue #192 and a proposed update to the draft is in PR= #199.

 

Comments inline. Please let us know if you have= further comments on the updates made or if it is OK to merge #199 and clos= e #192.


 

= From: Lake= <lake-bounces@ietf.org> on behalf of Marco Tiloca <marco.tiloca= =3D40ri.se@dmarc.ietf.org>
Date: Wednesday, 3 November 2021 at 17:26
To: lake@ietf.org <lake@ietf.org>
Subject: [Lake] Review of draft-ietf-lake-edhoc-12

Hi all,

As promised, please find below my review of EDHOC v -12.

Best,
/Marco

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[Section 1.1]

* "This specification focuses on referencing instead of transporting <= br> credentials to reduce message overhead."

    It is possible to transport credentials both by referenc= e and by
value. What suggests the case of transport by reference to be the
"focus"? Perhaps you mean that it is possible and preferable/reco= mmended
to transport credentials by reference?

[GS] Accor= ding to the requirements document draft-ietf-lake-reqs-04, the initial focu= s as of June 2020 was on RPK (by reference and= value) and certificate by reference. Since then several participants have requested the draft to be more explicit about ho= w to use ID_CRED_x for transport of credentials, which just follows from th= e use of COSE. I rephrased as:

NEW
This specif= ication emphasizes the possibility to reference rather than to transport cr= edentials in order to reduce message overhead, but the latter is also suppo= rted.



* "future algorithms and credentials targeting IoT"

    This probably means "future algorithms and identity= credential types
targeting IoT".

[GS] The t= erm "identity credential" is not previously used in the draft so = I settled for "credential types".

 


* s/compromise of the long-term keys/compromise of the long-term
identity keys

[GS] The t= erm "identity key" is not used elsewhere in the document. The ter= m "long-term key" is used throughout the document including the s= ecurity considerations and is a common term used in protocol analysis which is what this text talks about. So I think it makes sense to= not change here. The alternative would be to talk about "private auth= entication key" which is also used in the document, but more in the co= ntext of identities.

 



[Section 1.3]

* s/the number of bytes in EDHOC + CoAP can be/the EDHOC message size in bytes when transferred in CoAP can be

[GS] Changed to

NEW
the EDHOC message size when transferred in CoAP can be

 


[Section 1.5]

* "and CDDL [RFC8610]. The Concise Data Definition Language (CDDL) is =
used to express CBOR data structures [RFC8949]"

    can be rephrased as:

    "and the Concise Data Definition Language (CDDL) [R= FC8610], which is
used to express CBOR data structures [RFC8949]"

[GS] Harmo= nizing with previous references, and removed the reference to CBOR which is= already in this paragraph, I changed to:

NEW
"and the Concise Data Definition Language (CDDL, [RFC8610]), which is = used to express CBOR data structures."

 



[Section 2]

* "Verification of a common preferred cipher suite"

    Shouldn't this say: "Verification of a commonly sup= ported cipher
suite which is most preferred by the Initiator" ?

[GS] Chang= ed to

NEW
"Verification of the selected cipher suite"

 



[Section 3.2]

* In Figure 4, the second and third column can rather have labels
"Initiator Authentication Key" and "Responder Authentication= Key".

[GS] Done. Also replaced first column label "Value" with &quo= t;Method Type Value".


[Section 3.3]

* "or in a subsequent application protocol"

    can be expanded as:

    "or of an application/security context in a subsequ= ent application
protocol"

[GS] Changed to

NEW
or in subse= quent applications of EDHOC


[Section 3.4.1]

* "EDHOC transports that do not inherently provide correlation across =
all messages of an exchange"

    can be rephrased as:

    "Transports that do not inherently provide correlat= ion across all
EDHOC messages of an exchange"

[GS] Done<= /span>

 



[Section 3.5.1]

* "The EDHOC implementation or the application must enforce informatio= n
about ..."

    can be rephrased as:

    "The EDHOC implementation or the application must t= ake a decision on
allowing or not a connection based on information about ..."

[GS] Chang= ed to

NEW
The EDHOC implementation or the application must decide on allowing a conne= ction or not depending on the intended endpoint


* s/if it is allowed to communicate with/if it is allowed to communicate with those

[GS] Rephrased to harmonize with PKI text. Note that further changes are expected to 3.5 following Stephen's review comment about restr= ucturing.


[Section 4.3]

* The context can for example be the empty (zero-length) sequence or a
single CBOR byte string.

    Isn't the context supposed to be just a single CBOR byte= string? See
how it is defined in Section 4.2 when introducing Expand.

[GS]  Changed to:

NEW
The context can for example be the empty CBOR byte string.


* s/where H() is the hash function/where H() is the EDHOC hash algorithm

[GS] Done<= /span>



[Section 5.1]

* s/a second time for EDHOC processing/a second time for EDHOC
processing within the same ongoing session

[GS] Fixed.


[Section 5.2.3]

* "If an error message is sent, the session MUST be discontinued."= ;

    Is this sentence actually required? Regardless sending a= n error
message or not, the session is discontinued if any processing step
fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing
step fails?

[GS] This sentence does not talk about failed processing, it is a gener= al implication stating the necessity of discontinuing the session if an err= or message is sent (for whatever reason), in contrast to the converse statement in the preceding sentence which stat= es that there is no necessity of sending an error message if the session is= discontinued. I opened issue #208 for potential further discussion on the = topic.


[Section 5.3.1]

* "G_Y, the ephemeral public key of the Responder, and ..."

    Just to avoid any risk to interpret this as the concaten= ation of
three elements, I suggest
to rephrase= as:

    "G_Y (i.e., the ephemeral public key of the Respond= er) and ..."

[GS] Done.=



[Section 5.3.2]

* s/H() is the hash function in/H() is the EDHOC hash algorithm in

[GS] Done<= /span>

 


* "is the 'signature' field of a COSE_Sign1 object as defined in Secti= on
4.4 of [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm ...&= quot;

    should be rephrased as:

    "is the 'signature' field of a COSE_Sign1 object as= defined in
Section 4.2 of [I-D.ietf-cose-rfc8152bis-struct], computed as defined in Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] by using the signature algorithm ..."

[GS] I think it suffices to refer to how it is computed, which in turn = references how it is defined:

NEW
is the 'sig= nature' field of a COSE_Sign1 object, computed as specified in Section 4.4 = of {{I-D.ietf-cose-rfc8152bis-struct}} using the signature algorithm=


[Section 5.3.3]

* "If an error message is sent, the session MUST be discontinued."= ;

    Is this sentence actually required? Regardless sending a= n error
message or not, the session is discontinued if any processing step
fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing
step fails?

[GS] Same = as above

 



[Section 5.4.2]

* s/H() is the hash function in/H() is the EDHOC hash algorithm in

[GS] Done

 


* "is the 'signature' field of a COSE_Sign1 object as defined in Secti= on
4.4 of [I-D.ietf-cose-rfc8152bis-struct] using the signature algorithm ...&= quot;

    should be rephrased as:

    "is the 'signature' field of a COSE_Sign1 object as= defined in
Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct], computed as defined in Section 4.4 of [I-D.ietf-cose-rfc8152bis-struct] by using the signature algorithm ..."

[GS] Same = as above

 


* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

[GS] Done


[Section 5.4.3]

* s/or the prepended C_I/or the prepended C_R

[GS] Done

 


* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

[GS] Done

 


* "If an error message is sent, the session MUST be discontinued."= ;

    Is this sentence actually required? Regardless sending a= n error
message or not, the session is discontinued if any processing step
fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing
step fails?

[GS] Same as = above


* s/no other party than the Responder/no other party than the Initiator

[GS] Done<= /span>


[Section 5.5]

* "In deployments where no protected application message is sent from =
the Responder to the Initiator, the Responder MUST send message_4."
    Consider to rephrase as:

    "In deployments where no protected application mess= age is sent from
the Responder to the Initiator, message_4 MUST be supported and the
Responder MUST send message_4"

[GS] Changed = to ", message_4 MUST be supported and MUST be used" to apply to I as well as R.

"Responder MUST send mes=
sage_4" is still strange, would about I? Maybe just "message_4 MU=
ST be used"?

 



[Section 5.5.2]

* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

[GS] Done

 



[Section 5.5.3]

* s/as defined in Section 5.3 of [I-D.ietf-cose-rfc8152bis-struct]/as
defined in Sections 5.2 and 5.3 of [I-D.ietf-cose-rfc8152bis-struct]

[GS] Done

 


* "If an error message is sent, the session MUST be discontinued."= ;

    Is this sentence actually required? Regardless sending a= n error
message or not, the session is discontinued if any processing step
fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing
step fails?

[GS] See abov= e

 



[Section 6]

* s/error SHALL be/An error message SHALL be

[GS] This = change is not done, note that "error" refers to the name of the C= BOR sequence defined below.



[Section 6.3]

* "Error code 2 MUST only be used in a response to message_1 ..."=

    can be rephrased as:

    "Error code 2 MUST only be used when replying to me= ssage_1" ,
avoiding to use words like "request" and "response".
[GS] Done


[Section 6.3.2]

* s/the Responder shall only accept message_1 if/the Responder SHALL
accept message_1 only if

[GS] Done


* The last two paragraph are not further comments on the examples, but
are rather related to the cipher suite negotiation. I think they better fit as last paragraphs of Section 6.3.1.

[GS] Done<= /span>



[Section 8]

* "Compromise of PRK_4x3m leads to compromise of all exported keying <= br> material derived after the last invocation of the EDHOC-KeyUpdate function.= "

    I suggest to expand as follows:

    "Compromise of PRK_4x3m leads to compromise of all = exported keying
material derived from that key through the EDHOC-Exporter function. If
the EDHOC-KeyUpdate function has been used to renew PRK_4x3m, the
compromise is limited to the exported keying material derived from the
PRK_4x3m installed after the last invocation of the EDHOC-KeyUpdate
function."

[GS] Chang= ed to

NEW
Compromise = of PRK_4x3m leads to compromise = of all keying material derived with the EDHOC-Exporter since the last in= vocation (if= any) of the EDHOC-KeyUp= date function.


[Section 8.6]

* The way the first paragraph starts is probably a remnant of when CoAP was still part of the document body rather than in Appendix A. Also, as later discussed in Appendix A.3, the Echo exchange is started by a CoAP server, regardless if it acts exactly as Responder. I suggest to
rephrase the paragraph as follows.

    "EDHOC itself does not provide countermeasures agai= nst
Denial-of-Service attacks. In particular, by sending a number of new or replayed message_1 an attacker may cause the Responder to allocate
state, perform cryptographic operations, and amplify messages. To
mitigate such attacks, an implementation SHOULD rely on lower layer
mechanisms. For instance, when EDHOC is transferred  as an exchange of=
CoAP messages, the CoAP server can use the Echo option defined in
[I-D.ietf-core-echo-request-tag], which forces the CoAP client to
demonstrate its reachability at its apparent network address."

[GS] Done

 



[Section 8.7]

* "... but intended to simplify ..."

    Since "security context" is mentioned in the f= ollowing sentences, it
is better to explicitly mention that they are referring to the
application protocol and not to EDHOC anymore.

[GS] I didn't= make this proposed change because "security context" is not limi= ted to OSCORE, so this sentence applies also to EDHOC. If you still find th= is misleading, please explain in what way it is so.


[Appendix A.3]

* "EDHOC message_2 or the EDHOC error message is sent from the server = to
the client in the payload of a 2.04 (Changed) response. EDHOC message_3 or the EDHOC error message is sent from the client to the server's
resource in the payload of a POST request. If needed, an EDHOC error
message is sent from the server to the client in the payload of a 2.04
(Changed) response."

    This text should also be a remnant of old versions. When= using EDHOC
for OSCORE, EDHOC error messages as CoAP responses are sent as error
responses, see the first paragraph in Appendix A.3.1. The text above can rather, more generically, be:

    "The server sends to the client EDHOC message_2 in = the payload of a
2.04 (Changed) response, or an EDHOC error message in the payload of a
response. If needed, the client sends to the server an EDHOC error
message in the payload of a POST request. Otherwise, the client sends to the server EDHOC message_3 in the payload of a POST request. If needed, the server sends to the client an EDHOC error message in the payload of a response."

[GS] Good = spotted, I modifed the original text in a different way:

NEW
EDHOC messa= ge_2 or the EDHOC error message is sent from the server to the client in th= e payload of the response, in the former case with response code 2.04 (Chan= ged), in the latter with response code as specified in Section 8.3.1  EDHOC message_3 or the EDHOC error message is sent from = the client to the server's resource in the payload of a POST request. If ED= HOC message_4 is used, or in case of an error message, it is sent from the server to the client in the payload of the re= sponse, with response codes analogously to message_2.



[Appendix A.3.1]

* The last sentence can be extended, to mention what additionally is
defined in draft-ietf-core-oscore-edhoc, besides the EDHOC+OSCORE
request. This includes especially: a deterministic and efficient
conversion from OSCORE Sender/Recipient IDs to EDHOC connection
identifiers; web-linking and target attributes for discovering of EDHOC resources.

[GS] Done<= /span>

 


[Nits]

* Three instances of "key material" should be "keying materi= al" for
consistency.

[GS] Done<= /span>



* Section 3.3.1, s/and sends in message_2/and sends it in message_2
<= /span>

[GS] Done<= /span>



* Section 3.3.2, s/and a EDHOC connection/and an EDHOC connection

[GS] Done<= /span>



* Section 3.6
--- s/pre-defined int label/pre-defined integer label
--- s/Implementation can either use/Implementations can either use

[GS] Done<= /span>



* Section 3.7, s/requires an 'y' parameter/requires a 'y' parameter
<= /span>

[GS] Done<= /span>

 


* Section 3.8, s/protected out of scope of EDHOC/whose protection is out of the scope of EDHOC

[GS] Done<= /span>

* Section 3.9
--- s/verifying cipher suite/verifying a cipher suite
--- s/know identity of Responder/know identity of the Responder
--- s/know identity of Initiator/know identity of the Initiator
<= /span>

[GS] Done<= /span>


* Section 4.3, s/same key kan be/same key can be

[GS] Done<= /span>



* Section 5.1, s/then process according to Section 6, else process
as/then process it according to Section 6, else process it as
=

[GS] Done<= /span>



* Section 5.3.2, s/facilitate retrieval of/facilitate the retrieval of

[GS] Done<= /span>



* Section 5.4.2
--- s/facilitate retrieval of/facilitate the retrieval of
--- s/intialization vector/initialization vector
--- s/or derived application keys/or derive application keys
<= /p>

[GS] Done<= /span>



* Section 5.4.2, s/intialization vector/initialization vector
=

[GS] Done<= /span>



* Section 6.3.2, s/then Responder MUST discontinue/then the Responder
MUST discontinue

[GS] Done<= /span>



* Section 8, s/protection is provided/protection are provided
=

[GS] Done<= /span>


* Section 8.2
--- s/and instead rely/and instead relies
--- s/the Responders identity/the Responder's identity
--- s/Requirement for how/Requirements for how

[GS] Done<= /span>



* Section 8.6
--- s/forces the initiator/forces the Initiator

[GS] Done<= /span>

 


* Section 9.6, s/an CWT Claims Set/a CWT Claims Set

[GS] Done<= /span>



* Section 9.14, s/is defined as/are defined as

[GS] Done



* Appendix A.3, s/using resource directory/using a resource directory

[GS] Done<= /span>


* Appendix B, s/compatibily/compatibility

[GS] Done<= /span>



* Appendix C.1, s/dignostic/diagnostic

[GS] Done<= /span>


* Appendix E
--- s/which does not handle/which do not handle
--- s/with respect the current/with respect to the current

[GS] Done<= /span>

* Appendix F, s/for message 1/for message_1
<= span lang=3D"EN-US" style=3D"font-size:11.0pt">

[GS] Done

 

Thanks!

G=F6ran




--_000_AM4PR0701MB219541145A4E91D7624F5E3AF4699AM4PR0701MB2195_-- From nobody Mon Dec 13 06:57:31 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6103A0408 for ; Mon, 13 Dec 2021 06:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 y3jxktjTlmR5 for ; Mon, 13 Dec 2021 06:57:24 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05lp2171.outbound.protection.outlook.com [104.47.17.171]) (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 66EED3A012C for ; Mon, 13 Dec 2021 06:57:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KHUJb6BvLxn00gRqW1qaDF6XUosduv95lOF+6tnl5/wyOT+nLkuMWJQat1iPoJqug2j8IVqa0kUosffD2ZGeoPI8TnJ25qboHLmdWcy2bsnXKg+JmDI8azrn6HYFGryiXkvVebj8S7J7k0gCyWYsGe0C2zBmlG7bILIi2AcUglkv4k9q9x3S3w5cCJxfKjXM42N4mj4Gk7C2cr+SFFblzHHtUc0BqAxgPQnXXhVXASbubpUb6yvBL9TH/XF18q/YwivjW3MESLTRUogou71InH5aAZuNxR9KZTCiV1u9osAzbic8HO179g2oC93LAg+jjohOEEzHBs2ly8rcS1qC5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=E7OAy5kHxPmr+M+97Y2YYM0n9UGY0XKTUXWAezQfAO0=; b=RszJN8CSyzUOW2wMFTiCkLV2Elktz5+DAAAMJQ972FukETROZckZ64AqxWIrDzalRb2ok2yDX4luMtVrV5z7wWCoB1UL8xaf8p125jVJe/EwWdm5NT9+Y0Ig6qVk+c0u+MLRp5lCB7dOCwkqz037KbE/8L+xi+xJSlcaVpRxquQ06WWD5fCEcpqbTRp677yRZ5tjv/dQ7KCbc/7+wwynUj0ZHfKIq13GycFh/5e588nHAHxh8AIxprnimp/JagZBroEyMEdR1qusi/i2PxHs1ejwRIG/1j8MsMZc0gQS/geJdl6ZyBHVrA2Xnvz8Z0NyfNFkmI2x/rxWxj3M4Xm+Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E7OAy5kHxPmr+M+97Y2YYM0n9UGY0XKTUXWAezQfAO0=; b=nl7UCYtvi90vm6MRGDsa5BmtHENzkpr/0Eohye4ZsrBUR0zlsILY9Kex0AAjGzUBfdZ2PVqG8yHWeSDiJzaERBThEKOM8uQKRVH+6sf8cLe9WOzdyLOLP62Rs4hCjn+zO8o57h09XkanL0Vq9J3hLitiOMzYnPpYOlGTk52UOYI= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM0PR07MB5907.eurprd07.prod.outlook.com (2603:10a6:208:108::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.13; Mon, 13 Dec 2021 14:57:20 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4801.013; Mon, 13 Dec 2021 14:57:20 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "Hristozov, Stefan" , "lake@ietf.org" Thread-Topic: Review EDHOC-v12 Thread-Index: AQHX0W9vPW87iAHERUCkfmEyZh8LBawlx2dG Date: Mon, 13 Dec 2021 14:57:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 343c6f19-834e-ca52-901b-2658604f19fb authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2981efb5-8a83-4ffe-7b08-08d9be48dcc2 x-ms-traffictypediagnostic: AM0PR07MB5907:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bDPdr9ds6YM6TiMb1ui7CRXfPCW/Kqzwb++dU0/OvV2kzzIKSrXu15oj+N+gqpqcUjOkww0yC9GCRp3cPsFwWJ3E57ZpB9jRu2Ie70ZBWb7WdBrDwA8ccMHNjlj4riVwghgXjRvGqBwRkPx0vUd/0kp0v2GREZG3hayUo7Ju5j9z6P90mNJp6RxqP6tXMgASe/zMLsO7AGwZNJ002Sf5RDFywzuC3Db1zq+vgnRgA0Wu38oWEAEpd5W0R1zTz07n1dtIIulOoBzh2xza3miXfq0rfelGSgW++l91DulUk93zuwH0H5XpYq1H5WP5gjioONursrA7UHn80NUmFYndoaQSOG6xgJ0Kn3wBK77nQ+fKUSFV6j9q5iZX5jLeO0c8pvGPvpFetLW28hX9/ip0UEWRFCde7iVeLZDyQYdQiZ662BI2YRnnDxd1V4uBzJ28SKNrvx8WqhRdF5My6khD6cXhMR347nXdHPjYuv4SjPdRx1fmNd8NvTw/EJv1xTO/v3U47d8o2J7Im1pMOWtub/gMV2BlzqydeOdfq2vYnOS+UqJxPspnStjVgJGpB+0WazAu8JQVxI62qOxPRx4elxmqUF9ybUB+8oWwOvyCKa3c32DYFNvXx5BtUt6i9cME49+3opxIp2vz8WERKHgxLCnb0PtAZjAoi94itoZPMJXVEZxpJ0l8/Cdqtd2lKcYwg5/WpWLIKwzNrvEoxffs2WFwtkvcTb3NL421USHnsjX3kVHhHCOWiftNj9z3PxAJWx39I4kssi77et6NTMmgIIAMqJa5spBIS2bJETJ17os= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(53546011)(26005)(9686003)(6506007)(186003)(82960400001)(122000001)(38100700002)(86362001)(508600001)(83380400001)(66574015)(66476007)(8676002)(110136005)(38070700005)(8936002)(64756008)(316002)(91956017)(33656002)(66556008)(66946007)(66446008)(76116006)(5660300002)(2906002)(52536014)(19627405001)(55016003)(966005)(71200400001)(7696005)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?b21PZW/RuxzFkSHVCIRsb9eMjqNtWKWLob/se+7en5FxUe9Ayk0MsUbLHR?= =?iso-8859-1?Q?pjG6Iu1fV3pOdiA1M2Si7uU0Gh2rWvq9md7GIHAbFUmJmlt8Pyimc1qRnB?= =?iso-8859-1?Q?6Z+puFundOQTlJv6iBuEWxGWrFbJbWbkMP/i3AME2c4t/W1LED60KE1mxO?= =?iso-8859-1?Q?ZczxYZgCQiTYavCBrS7ogzFyOcUaCdZJe7HSostiHm3C1eSwVz5rwdtVje?= =?iso-8859-1?Q?Ooc/XhxIjMjmPyNb2vv1xT3uYJi6a1zDen8/3G2VVVIZ/nnYQL4mF5CdZ/?= =?iso-8859-1?Q?in5OHQYqFk+mguRFAQ2qjBRcDp3lv2LzUuYDWRld8TuWWtlzOlECHFeD7K?= =?iso-8859-1?Q?GcmuJ+pu+/wMDeyhSzttrpfC4RxhAmnZIOejaAjHPDogVzmafSPht2lCmY?= =?iso-8859-1?Q?WdumzYxGFZ6f1qSTyWOH0SE98U9GoeHDt35B6oTr3rEUHkSssmeRM+2qwo?= =?iso-8859-1?Q?4x5PEOLdDsDSwpe7e+ksOpswZ6xOr8M1SOktX4wPHBhK8ZRCJ18MQlph0/?= =?iso-8859-1?Q?2FeZ9ekde+Fm3tiEubt7Af4IhgHPwBxoNoxhDsf/cYzOvotoXJaO3PM0WB?= =?iso-8859-1?Q?chZz7hwJdGb/6uYsUcU7PDNGF+1ng7gJox3eDKGVkj3Opnub1b/otnXLbO?= =?iso-8859-1?Q?8SsR/qIVHfJAvlQqymEFaKI+lv29jK+OgJzs7/6Uka0ui8fdSMij/rGVIw?= =?iso-8859-1?Q?sfYUkndBFbZdeNTee01j0O5KRaMWrjgD6t4Oz9hwk2BstxoTsfjLrv3DDX?= =?iso-8859-1?Q?yaaTkhcxn3ZrFfGpEceRMNprDjahY/dIJdlJfCju7MLAGMmDLBVx1BaP8u?= =?iso-8859-1?Q?8i1OE5lOZY9ox1H9glmrmJwkUlfPak9Gstoo0xPadnv/nPEKfbCvUSg8Gz?= =?iso-8859-1?Q?zhRbR7PQI775Kk2OD/WCUa7cZrb9Vn7njRtbSMoDVgzMKRC9aCqCZ4+YEQ?= =?iso-8859-1?Q?s01/6WYbpfCcvjydBGUvSlCq8xjk3yjIA2jzvhZ6X9lKG28wZ7OvUO8Xhq?= =?iso-8859-1?Q?q4He2IfT+wUQMtth4vdcV9O8y2xLlJeNgERIltAnC/brV62Hrz2hK3GeDw?= =?iso-8859-1?Q?bvD06gbDGzpzRN7e8mENVkkXeyMpqqZSRVUsPNwstMJnPIjmsXFnHkkznY?= =?iso-8859-1?Q?lzYSQK40wGQPGyFBK/2tfx6xjYaC0IDSZe1ZiduO5YELZPns2AqyD7VB4e?= =?iso-8859-1?Q?pdviIddaoxUvEdvfyHPh2B/QYYnF/33PVHlGsMKCBc5+fLO7de8DyZs9pH?= =?iso-8859-1?Q?p2e8r8TIvnGSk8J4yYSO2U3cIKUN52oCPwVAmjtEGPv8brZk3LP/L4hYOi?= =?iso-8859-1?Q?fK/0nDgLfrpPljnERkhWEuPNvTnc9Oijjj2sMVC94+1JYMLP3BXOdAPpHX?= =?iso-8859-1?Q?ojooS/vfZhty/Mt2SgUnomzhTtT5gZjquabxDzIenmIddLBvuq+DHTUp7f?= =?iso-8859-1?Q?FRQ1U4gCQgOo8KayLlvfU7taqRRWGdfdWiJsE07wkyhhJDLB7220pty6oj?= =?iso-8859-1?Q?61tM5qSbO+Rx92/JmvOa30Z5IECVj07AAn5ho97k54ve7n5IOmYeE5kSn9?= =?iso-8859-1?Q?cyhUXbpvuVXjbPtAxsMVGU0FiI3XEVhoFnMokaKqyWxE2BG5GokcfZrEY7?= =?iso-8859-1?Q?4KVJbzgzldQ5KpRjpTST8fpISmQFv9iZfeoN09yNM1Gbp3pc72Yc7T090D?= =?iso-8859-1?Q?jns8VjlSKP5xYpt1SFRWgwz1Xot+EoLMFIm34p8wCCbIbH+6KtPl+K6BVN?= =?iso-8859-1?Q?X6jw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB219508E3C5E8F006A4809F85F46D9AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2981efb5-8a83-4ffe-7b08-08d9be48dcc2 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2021 14:57:19.9510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vB7DeFBvzDdol6ySRbV2t03s1MQ/iWFp/Hz93smHrektrguy7gFKzfYTgaw6RzkU0QdI4LM67De8rHfFeWQNvDm4T3CVvUZzIWHGYTI9eBw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5907 Archived-At: Subject: Re: [Lake] Review EDHOC-v12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 14:57:31 -0000 --_000_AM4PR0701MB219508E3C5E8F006A4809F85F46D9AM4PR0701MB2195_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stefan, Thanks for the review. It is recorded as github issue #194 and a proposed u= pdate to the draft is in PR #200. Comments inline. Please let us know if you have further comments or if it i= s OK to merge #200 and close #194. From: Lake on behalf of Hristozov, Stefan Date: Thursday, 4 November 2021 at 12:43 To: lake@ietf.org Subject: [Lake] Review EDHOC-v12 Hi all, please find below my review of draft-ietf-lake-edhoc-12. Best regards, Stefan 2. Outline "ID_CRED_I and ID_CRED_R are credential identifiers enabling the recipient = party to retrieve the credential of I and R, respectively." I will replace this definition with something like: ID_CRED_I and ID_CRED_R are used to identify and optionally transport the a= uthentication keys of the Initiator and the Responder, respectively. [GS] Done in PR #200. 3.8 EAD Is EAD data generated by the application or data that is pre-provisioned or= obtained from somewhere. If the former is true I would like to suggest tha= t the specification allows for implementations where all inputs and output = that are generated at run time by the application are provided in non-encod= ed form to the EDHOC implementation. In this way, the interface to the appl= ication will be simpler and CBOR encoding and decoding can be completely hi= dden from the application developer. This applies especially for EAD, see i= ssue #186. The general question is who is supposed to encode/decode EAD? Th= e application or the EDHOC implementation? As far I understand the specific= ation now only the application knows how to encode and decode EAD. [GS] Correct, the application encodes/decodes EAD. However, for certain EAD= use cases it may be most appropriate to implement part of the application = and EDHOC together. We will add an appendix which provides some examples of= this, new issue #210. Good point about input and output in non-encoded for= m, that should also be included in those examples. APIs are left out of sco= pe, but it makes sense that EDHOC implementation CBOR encodes the non-encod= ed information. 5.2.1 "If the most preferred cipher suite is selected then SUITES_I is encoded as= that cipher suite, i.e., as an int." Am I understanding that correctly: If other suites are supported in additio= n they are not sent, e.g., if the initiator supports suites 1,2,3, where 1 = is preferred and selected, 1 is sent as int and 2,3 are not sent? If so I w= ill suggest making this sentence more clear. [GS] Yes, your understanding is correct. Since the procedure prescribes onl= y sending the cipher suite which is selected and more preferred supported c= ipher suites, if the selected is the most preferred then only that cipher s= uite is sent. I tried to clarify the sentence further, see PR#200. 6 Error Handling What is the use case for a success error code? Probably it is good to give = some example or reference why it is useful to log successes using a predefi= ned error code and encoding. Is logging the only use case for the success e= rror code? For example, my implementation logs many things for debugging pu= rposes. However, I never needed a success error code. [GS] The error code for success came about from a mail exchange on the IOTO= PS WG mailing list [1]: "2. reserve one of the status codes for success, so= that the status reporting can also use the standard value in case of no er= ror". I added this explanation to the text in PR #200. [1] https://mailarchive.ietf.org/arch/msg/iotops/t9LTpMiZ__kFGZpceLCBaCUHN4= 4/ The spec says that success error code must not be sent, therefore the sente= nce "Error code 0 MAY be used internally.." needs to be "Error code 0 MAY b= e used _only_ internally.."? [GS] I think "MAY only be used internally" is perhaps stating too much (dep= ending on exact meaning of internally). We already state that the success c= ode MUST NOT be used as part of the EDHOC message flow. I'm not sure we sho= uld be more be explicit about how success codes are used. Whether the succe= ss code would somehow be exposed through an application is out of scope of = the protocol IMHO. So I kept "MAY be used internally" which we seem to agre= e about although it is not a complete characterization of the potential use= of success codes. "ERR_INFO can contain any type of CBOR item", see figure 7. Who decides wha= t is the type of the CBOR item? Is this the EDHOC implementation developer? [GS] This is intentionally left open. Returning to the example which motiva= ted the definition of a success code, the use of ERR_INFO in a successful s= tatus report allows additional information relevant to the application to c= omplement the information that this is t "no error". This may be a feature = of a particular EDHOC implementation, an information element required by a = particular application, etc. but what CBOR type is used is not directly imp= acting the protocol and therefore is out of scope for the specification. I = added the latter to the text in PR #200. 7 Mandatory-to-Implement Compliance Requirements "Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2." The difference between 0 and 1 and between 2 and 3 is only the size of the = tag, i.e. the used algorithms are the same. -> I will suggest changing to "= ...suite 0/1 or cipher suite 2/3" or similar. [GS] Good point, I made a separate issue #209. A proposed text is included = in PR #200. Error messages with which error codes are mandatory to implement? Is only a= n error message with ERR_CODE 2 mandatory to implement? [GS] Section 7 of version -12 actually says: "Error codes 1 and 2 MUST be supported." I added "ERR_CODE" to the sentence in PR #200 for easy search. 8.7 Implementation consideration "The selection of trusted CAs should be done very carefully and certificate= revocation should be supported." Is OCSP (RFC6960) what should be used for certificate revocation checking? [GS] Revocation is specified in separate RFCs depending on certificate form= at, so that is one example. How revocation can be accomplished with C509? [GS] C509 has defined CRLs but not yet encoding of OSCP. The topic was brou= ght up at the COSE WG meeting IETF 112, but no details are provided yet. How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we c= ombine OCSP stapling with EAD? [GS] As mentioned, the use of OCSP with COSE is not defined yet. Once defin= ition it should also include COSE header parameter which then can be used f= or transport in ID_CRED_x in EDHOC, or alternatively with EAD. This can be = defined separately. Additionally, to verify a certificate the device should be aware of the tim= e, which is often problematic on constrained devices, i.e. when certificate= s are used the device must have a Real-Time Clock (RTC). [GS] Good point. Verification of validity may require the use of a Real-Tim= e Clock (RTC), but as far as I understand, OCSP stapling does not. I added = a sentence in PR #200. Thanks G=F6ran --_000_AM4PR0701MB219508E3C5E8F006A4809F85F46D9AM4PR0701MB2195_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stefan,

 

Thanks for the review. It i= s recorded as github issue #194 and a proposed update to the draft is in PR= #200.

 

Comments inline. Please let= us know if you have further comments or if it is OK to merge #200 and clos= e #194.

 

 

= From: Lake= <lake-bounces@ietf.org> on behalf of Hristozov, Stefan <stefan.hr= istozov@aisec.fraunhofer.de>
Date: Thursday, 4 November 2021 at 12:43
To: lake@ietf.org <lake@ietf.org>
Subject: [Lake] Review EDHOC-v12

Hi all,

 

please find = below my review of draft-ietf-lake-edhoc-12.

 

Best regards= ,

Stefan

 

 

2. Outline <= /span>

"ID_CRE= D_I and ID_CRED_R are credential identifiers enabling the recipient party t= o retrieve the credential of I and R, respectively."

I will repla= ce this definition with something like:

ID_CRED_I an= d ID_CRED_R are used to identify and optionally transport the authenticatio= n keys of the Initiator and the Responder, respectively.

 

[GS] Done = in PR #200.

 

3.8 EAD

Is EAD data = generated by the application or data that is pre-provisioned or obtained fr= om somewhere. If the former is true I would like to suggest that the specif= ication allows for implementations where all inputs and output that are generated at run time by the application ar= e provided in non-encoded form to the EDHOC implementation. In this way, th= e interface to the application will be simpler and CBOR encoding and decodi= ng can be completely hidden from the application developer. This applies especially for EAD, see issue #186= . The general question is who is supposed to encode/decode EAD? The applica= tion or the EDHOC implementation? As far I understand the specification now= only the application knows how to encode and decode EAD.

 

[GS] Corre= ct, the application encodes/decodes EAD. However, for certain EAD use cases= it may be most appropriate to implement part of the application and EDHOC = together. We will add an appendix which provides some examples of this, new issue #210. Good point about input and= output in non-encoded form, that should also be included in those examples= . APIs are left out of scope, but it makes sense that EDHOC implementation = CBOR encodes the non-encoded information.

 

 

5.2.1=

"If the= most preferred cipher suite is selected then SUITES_I is encoded as that c= ipher suite, i.e., as an int."

Am I underst= anding that correctly: If other suites are supported in addition they are n= ot sent, e.g., if the initiator supports suites 1,2,3, where 1 is preferred= and selected, 1 is sent as int and 2,3 are not sent? If so I will suggest making this sentence more clear.

 

[GS] Yes, = your understanding is correct. Since the procedure prescribes only sending = the cipher suite which is selected and more preferred supported cipher suit= es, if the selected is the most preferred then only that cipher suite is sent. I tried to clarify the sentence furth= er, see PR#200.

 

 

6 Error Hand= ling

What is the = use case for a success error code? Probably it is good to give some example= or reference why it is useful to log successes using a predefined error co= de and encoding. Is logging the only use case for the success error code? For example, my implementation logs m= any things for debugging purposes. However, I never needed a success error = code.

 

[GS] T= he error code for success came about from a mail exchange on the IOTOPS WG = mailing list [1]: &= quot;2. reserve one of the status codes for success, so that the status reporting = can also use the standard value in case of no error". I added this explanation to the text in PR #200.

 

[1] https:= //mailarchive.ietf.org/arch/msg/iotops/t9LTpMiZ__kFGZpceLCBaCUHN44/<= /span>

 

 

The spec say= s that success error code must not be sent, therefore the sentence "Er= ror code 0 MAY be used internally.." needs to be "Error code 0 MA= Y be used _only_ internally.."?

 

[GS] I thi= nk "MAY only be used internally" is perhaps stating too much (dep= ending on exact meaning of internally). We already state that the success c= ode MUST NOT be used as part of the EDHOC message flow. I'm not sure we should be more be explicit about how success codes a= re used. Whether the success code would somehow be exposed through an appli= cation is out of scope of the protocol IMHO. So I kept "MAY be used in= ternally" which we seem to agree about although it is not a complete characterization of the potential use of suc= cess codes.

 

 

"ERR_IN= FO can contain any type of CBOR item", see figure 7. Who decides what = is the type of the CBOR item? Is this the EDHOC implementation developer?

 

[GS] This = is intentionally left open. Returning to the example which motivated the de= finition of a success code, the use of ERR_INFO in a successful status repo= rt allows additional information relevant to the application to complement the information that this is t "no e= rror". This may be a feature of a particular EDHOC implementation, an = information element required by a particular application, etc. but what CBO= R type is used is not directly impacting the protocol and therefore is out of scope for the specification. I added the = latter to the text in PR #200.

 

 

 

7 Mandatory-= to-Implement Compliance Requirements

"Constr= ained endpoints SHOULD implement cipher suite 0 or cipher suite 2."

The differen= ce between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. th= e used algorithms are the same. -> I will suggest changing to "...s= uite 0/1 or cipher suite 2/3" or similar.  

 

[GS] Good point, I made a separate issue #209. A proposed text is includ= ed in PR #200.

 

Error messag= es with which error codes are mandatory to implement? Is only an error mess= age with ERR_CODE 2 mandatory to implement?  

 

[GS] Section 7 of version -12 actually says:

"Error codes 1 and 2 MUST be supported."

I added "ERR_CODE" to the sentence in PR #200 for easy search.=

 

 

 

8.7 Implemen= tation consideration

"The se= lection of trusted CAs should be done very carefully and certificate revoca= tion should be supported."

 

Is OCSP (RFC= 6960) what should be used for certificate revocation checking?

 

[GS] Revocation is specified in separate RFCs depending on certificate f= ormat, so that is one example.

 

How revocati= on can be accomplished with C509?

 

[GS] C509 has defined CRLs but not yet encoding of OSCP. The topic was b= rought up at the COSE WG meeting IETF 112, but no details are provided yet.=

 

How OCSP and= EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP = stapling with EAD?

 

[GS] As mentioned, the use of OCSP with COSE is not defined yet. Once de= finition it should also include COSE header parameter which then can be use= d for transport in ID_CRED_x in EDHOC, or alternatively with EAD. This can be defined separately.

 

Additionally= , to verify a certificate the device should be aware of the time, which is = often problematic on constrained devices, i.e. when certificates are used t= he device must have a Real-Time Clock (RTC).

 

[GS] Good point. Verification of validity may require the use of a Real-= Time Clock (RTC), but as far as I understand, OCSP stapling does not. I add= ed a sentence in PR #200.

 

 

Thanks

G=F6ran


--_000_AM4PR0701MB219508E3C5E8F006A4809F85F46D9AM4PR0701MB2195_-- From nobody Mon Dec 13 13:40:31 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2461A3A0BEF for ; Mon, 13 Dec 2021 13:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 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, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-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=ri.se 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 alspaXkl1iFT for ; Mon, 13 Dec 2021 13:40:18 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70048.outbound.protection.outlook.com [40.107.7.48]) (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 CD8453A0C14 for ; Mon, 13 Dec 2021 13:40:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kgUnXDWu/12XdBqD3WZ6NAQKNDiQxh7QNKqmCzHBsb/yRAy8l7I/M/iKBZBIETmoYG4uTER0tHbrBYGdI4YtiUO724pWEUEXbGXwPvE3Q1woVU+f7T5d8CX6/SMPZ8D7O/BsCYFAKeUX6W+y0581FNheq3gmwZuoRRqlUpvRv5TiyuY2nFowwmd8lOcM1619qog6citGNxeYxOAZGzEwSUIDwT694otm89d34wu+Gb89KhInnsqkRnWFXcY6KPcdHVqEU0i+k9zbAu7duzQcoz8g9WwA5qmNnC2wRk6nb+F3Zn0D72FjiCv2DUQubJO7gisutd8Eg3yrlDwGDWJlng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wdqta1ZfvSzFqkyT4dXS5qHi0fvMXoX9D0GgO6U22pw=; b=SRP7B6mG9/rs4+Efw9ok2I8nC7FWCpSKk6iOtKuF42ANejMk3McGR7rZ4nVsal0spErdaNxWgFaaz+8VREGFtPWYCinXBrs2i8Hwy+hoWdS8fk1B/z6mNUlWlrxACXDu6zsYMmE8zXPoYHPo9LB621JszLq0rAB6eueHjol8oL38p4zBuK3p/TEUAEPt6bGXHG4HhcejC93wBYBA3UhZRff5ouW9CMT1uhym9zhopJJOS2sUswciF1JWLdvkT5QRZbWm0dutHdsISwrj3qfzDHqjYe2/nHXjz/MrOtuJ/05lcMwKCo6ILtSyiN0VhTSAfuAk6qIwq6IbVCCXLMY3QQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wdqta1ZfvSzFqkyT4dXS5qHi0fvMXoX9D0GgO6U22pw=; b=Qe179eHQaUttL5kxg2cWOJ8Cz3cq6UtXFG06XvNRvt9F66blKSPaTcpcwScCG5N/l7EqTLnkKtztszXdB/7ahodkPl1Q/d8tGLNO5qyy7Hwa+slkBYXzmZKpRsdSU0K7Ufcf1ZPDbzj/qlEC1ywzcHb/NFmsqEH6GqWMWhn6lQs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0405.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.16; Mon, 13 Dec 2021 21:40:11 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::20b1:5d0e:9de4:7ca1]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::20b1:5d0e:9de4:7ca1%8]) with mapi id 15.20.4778.018; Mon, 13 Dec 2021 21:40:11 +0000 To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "lake@ietf.org" References: <5bc7e680-1513-f838-1188-8e2b67630430@ri.se> From: Marco Tiloca Message-ID: Date: Mon, 13 Dec 2021 22:40:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Rrjqq89ZsNlaLO8GCknJUQ8T5UCA0kBrr" X-ClientProxiedBy: GV3P280CA0044.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:9::11) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 63cf6295-ae3a-4275-3da2-08d9be81238a X-MS-TrafficTypeDiagnostic: DB6P189MB0405:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dnsm9LXLUFqghvb+A0EsN+foPQJPhQ+rsBSz9xeQGWUEcKB4SGa86oLOfFViBm/kq9FLlV5UcisdDjD6jnb1U7OFE4kUP18GZ7FgUI5hy8N7cKo5vEL/eyjvTMmoMeyW8NsCoJmXAf3yZw4nDxLfMkM+F+gt0e7HetMoPYwT0YJAM8zYND/OM300YNNRmfGdo4icgKtck8/t+0Y+wEpmGthWCq5nimvgndHySokg3RjBpP28zShHMh80h2YdyMMpVH41+eSPk1yKtQ02ouHIl3t6eMBIlHI5eRD1u0mLsNZZxC+6/DVSh7kTakinlutXlnlhsjIemELaeKVK8qw7hQIocOc8Vq77loyeems5+eUSFMbkzxdZDYEPy/9K8sWjtiWnKWwYxUcihT8jVNXCT0/Z2DPHbY1mN/oRJwmaY2JZN7dmWGKbxk9Fa8jw2jhtj807ISd3Ihq41qIq2hDp7mBseLYfJsOSHrQgpa1ByupC9TMCaqfuxb/QO1YLef402bfWAqLhjPr/rugBJkypKWAgnE+LCl3ZSoa92QUdggX/1AN78MH/VZAEsh0sa/1e2iz0zDW07XxzPLr7mE0kzqI4NSgUQzpNQkm/L5f3H1y81HNZ9qtP7qr7+NSPUfz40/ZzEwsdqMYU3kWiLFF28xI9aPTulOPfz3tmGSoWvKFyqLMBzFSrCb8T/NgI8HQvl7aYUZb01GQDMIjMwPs33215LhfuoFEgQhoWFxpb4VqCfPgcLcE6wtIIgUEdmaeLJ7yuxOhuvjY6U4RlqzBjxIGfeeooG6SsmLD0DmUcKsGmvAOCq+A28YgFWip7Ikj4 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(966005)(4001150100001)(8936002)(53546011)(38100700002)(31696002)(508600001)(6506007)(2906002)(45080400002)(19627405001)(186003)(26005)(36756003)(66946007)(86362001)(6486002)(21480400003)(6512007)(316002)(166002)(66574015)(44832011)(6666004)(235185007)(2616005)(83380400001)(31686004)(66556008)(66476007)(5660300002)(110136005)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?g333/gmY3GFXtZatS/F/a7TNp5A9IeZXf5gICQUS8Npg09b6RN9IO6xR?= =?Windows-1252?Q?qFC1czr71pRxA3yCnqQKbyLmLReZjGJcVDpXTevD3QdK5thtvbwME3Ou?= =?Windows-1252?Q?rMZF6GmyEjHds84GjLKvGtiE/8biYBZJy/yNP5qjmZLvbkffhWP1c0gh?= =?Windows-1252?Q?o7lWg3DaWFWHdisSWm0Y6Kg0AWddpOYhe4IMobgryH6hfKPhHdZ9A+K6?= =?Windows-1252?Q?d1dFv0gLTGeiPSUWI5HhNcO1op6pPxd15+w0RSsWy/OT/oMdPjBNv6qz?= =?Windows-1252?Q?YrZ+XmQjx8qoxEgjd61Fa0F5UIWGoOkT0WAGqP0E0B3VX3YmZl8rSr6S?= =?Windows-1252?Q?qMbCPU6DcKS/VYvQe7gPZ55A/u8gIKfYSykJ96h+ZqRjQs5A02dIljRh?= =?Windows-1252?Q?QUgQSdD/l8OMETfQkBIL2KGuqhzOwYrwSpheXlGfYzEfXG1bBca8RDOa?= =?Windows-1252?Q?5cV8S6KyOgwOl/s6LZgaS46XcWjilxnEtld6X08DQAeFzLHFhiuKcrcT?= =?Windows-1252?Q?L1IZ7b7NAKd+b9Q4tRxTDohO8ifUBS//rxRnqRFQCu7Gcj4FP5Wpxfgn?= =?Windows-1252?Q?ufbZqBdcY7dAnHKjtgoJ5GRrhqA/Uw1SUjPz6njoeZG9Q5ncVXUzN/Zb?= =?Windows-1252?Q?px1mvJ9T0ZS7aCGcK3QpaPgwxTtgxh92IwKtxZr0PHaZebzmnqE6NL7E?= =?Windows-1252?Q?dxMX9OcAlefRfclzmB3TxCJzwwFIIhtj7CseAQM2ha2KFj1PCkU5tQhj?= =?Windows-1252?Q?XjkEru3ENYeDIl5h7c4K2OfEIwZkkemDlcQYhWQMiUJuZgET7JljpWm8?= =?Windows-1252?Q?8LwMyZkyl7PNLZzgFlDroUbFTKzy12OHD2ceqvw7LL56PdLSpXX7HxXz?= =?Windows-1252?Q?HumLZ+rZvYbtYMdCIMoYAzw3qsxx/Izu4HzUznapM+QA/qJUaHHgpsXU?= =?Windows-1252?Q?qBjnKyqq5eVbK+OboMPL5eYOq0Y0QsZRAvxIczuDSijHQy7mg53qcOQE?= =?Windows-1252?Q?5I0TCjFnPzfxleXULizQ8iTbNDTcNMPKHlcMRXMQExiSto+xr7wQSqtv?= =?Windows-1252?Q?/gOHT1ydAp+TwHNeo62E4Qf8NNkqTyujksFlVv3ALMzK+Awrzd3h5E5R?= =?Windows-1252?Q?vMV1VFT5FldzqBMSgbl5H2nSsSFmRjySwiFXUucZYY0YBBogulQaEily?= =?Windows-1252?Q?89aCixORWI1zPy9Ewo4yPU+QuC8h1KJZVEThVXhmmWHGEAuVGJsFPo1Y?= =?Windows-1252?Q?RB36yVJJkA7DwesEsGGpDmZs+OAOuLkSi2rxJRnG/qoepGifqwaBZymN?= =?Windows-1252?Q?+rr13qDypTo8FJidSrwoN6v/VIhGfg/+NkXOFSyktFX99/TyIrNrdLI2?= =?Windows-1252?Q?d5SgeaSWNAVoovUT3+CJQOcQG5A/caMTqZekwrP4udnCdq1X+uBB+oXf?= =?Windows-1252?Q?FTMHJg4WERRZMQLOCI5F1EJYs4Ipf2t6h9uA2tqn4C77eAyMrcYbpT4O?= =?Windows-1252?Q?NSn514EHnYYjb7dAMn45EQPsChFAc2uDV5DOkT+s34DWH96e0Iz9hI+A?= =?Windows-1252?Q?29GTSVzUGyQQkn+BbgKTA+QMjZqtyUlwK0no1mJ1Xta6EcDdttSVB2tr?= =?Windows-1252?Q?tScL00kmNvSEbmNmVPJRmJLNN1MD5VMC003sJb208cF+KPltOo5TOBi4?= =?Windows-1252?Q?P+UYQ3D5BtiMjP2Oe+nHo5A4214+ZNho1rN+xNt83MJdS7IwO0A/M7MQ?= =?Windows-1252?Q?xZYvMvDgs83IvBY0bGw=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 63cf6295-ae3a-4275-3da2-08d9be81238a X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2021 21:40:10.7993 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: R2mi24F4Rws5MQ8QphV7uxfASKH/pDadPWiWQ8v/fbdVoE9fpNcDkMcthlgZrjkTaOFoSO7zrkvopZCTaD1uUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0405 Archived-At: Subject: Re: [Lake] Review of draft-ietf-lake-edhoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 21:40:29 -0000 --Rrjqq89ZsNlaLO8GCknJUQ8T5UCA0kBrr Content-Type: multipart/mixed; boundary="VInJaUpVYpEA84DVoyanlrHIrbyhEzuXq"; protected-headers="v1" From: Marco Tiloca To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "lake@ietf.org" Message-ID: Subject: Re: [Lake] Review of draft-ietf-lake-edhoc-12 References: <5bc7e680-1513-f838-1188-8e2b67630430@ri.se> In-Reply-To: --VInJaUpVYpEA84DVoyanlrHIrbyhEzuXq Content-Type: multipart/alternative; boundary="------------19FE17EB795E0C9A1304DA16" Content-Language: en-US This is a multi-part message in MIME format. --------------19FE17EB795E0C9A1304DA16 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi G=F6ran, Thanks for addressing my comments! Please, see below my reply to three points from your response. Other=20 than that, PR #199 looks good to be merged. Best, /Marco On 2021-12-13 15:47, G=F6ran Selander wrote: > > Hi Marco, > > Thanks for the review. It is recorded as github issue #192 and a=20 > proposed update to the draft is in PR #199. > > Comments inline. Please let us know if you have further comments on=20 > the updates made or if it is OK to merge #199 and close #192. > > > *From: *Lake on behalf of Marco Tiloca=20 > > *Date: *Wednesday, 3 November 2021 at 17:26 > *To: *lake@ietf.org > *Subject: *[Lake] Review of draft-ietf-lake-edhoc-12 > > Hi all, > > As promised, please find below my review of EDHOC v -12. > > Best, > /Marco > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > [Section 1.1] > =3D=3D>MT (trimming) <=3D=3D > * s/compromise of the long-term keys/compromise of the long-term > identity keys > > [GS] The term "identity key" is not used elsewhere in the document.=20 > The term "long-term key" is used throughout the document including the = > security considerations and is a common term used in protocol analysis = > which is what this text talks about. So I think it makes sense to not=20 > change here. The alternative would be to talk about "private=20 > authentication key" which is also used in the document, but more in=20 > the context of identities. > =3D=3D>MT I see, then it's good to keep "long-term keys". <=3D=3D > > [Section 8.7] > > * "... but intended to simplify ..." > > =A0=A0=A0 Since "security context" is mentioned in the following senten= ces, it > is better to explicitly mention that they are referring to the > application protocol and not to EDHOC anymore. > > [GS] I didn't make this proposed change because "security context" is=20 > not limited to OSCORE, so this sentence applies also to EDHOC. If you=20 > still find this misleading, please explain in what way it is so. > =3D=3D>MT Ok, I think the confusion comes from not using "security context" as=20 related to the EDHOC execution earlier in the document. That has rather=20 been referred as "protocol state". Perhaps it's worth clarifying this in Section 3.4.1, that now states=20 twice "the retrieval of protocol state during EDHOC protocol execution." = This may become "the retrieval of protocol state and its security=20 context during EDHOC protocol execution". <=3D=3D > > [Appendix A.3] > > * "EDHOC message_2 or the EDHOC error message is sent from the server t= o > the client in the payload of a 2.04 (Changed) response. EDHOC message_3= > or the EDHOC error message is sent from the client to the server's > resource in the payload of a POST request. If needed, an EDHOC error > message is sent from the server to the client in the payload of a 2.04 > (Changed) response." > > =A0=A0=A0 This text should also be a remnant of old versions. When usin= g EDHOC > for OSCORE, EDHOC error messages as CoAP responses are sent as error > responses, see the first paragraph in Appendix A.3.1. The text above ca= n > rather, more generically, be: > > =A0=A0=A0 "The server sends to the client EDHOC message_2 in the payloa= d of a > 2.04 (Changed) response, or an EDHOC error message in the payload of a > response. If needed, the client sends to the server an EDHOC error > message in the payload of a POST request. Otherwise, the client sends t= o > the server EDHOC message_3 in the payload of a POST request. If needed,= > the server sends to the client an EDHOC error message in the payload of= > a response." > > [GS] Good spotted, I modifed the original text in a different way: > > NEW > EDHOC message_2 or the EDHOC error message is sent from the server to=20 > the client in the payload of the response, in the former case with=20 > response code 2.04 (Changed), in the latter with response code as=20 > specified in Section 8.3.1 EDHOC message_3 or the EDHOC error message=20 > is sent from the client to the server's resource in the payload of a=20 > POST request. If EDHOC message_4 is used, or in case of an error=20 > message, it is sent from the server to the client in the payload of=20 > the response, with response codes analogously to message_2. > =3D=3D>MT Looks good, although I guess you meant "as specified in Appendix A.3.1.=20 EDHOC message_3 ..." , rather than "as specified in Section 8.3.1 EDHOC=20 message_3 ..." <=3D=3D > Thanks! > > G=F6ran > > > > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=E5ngen 16 SE-164 40 Kista (Sweden) --------------19FE17EB795E0C9A1304DA16 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi G=F6ran,

Thanks for addressing my comments!

Please, see below my reply to three points from your response. Other than that, PR #199 looks good to be merged.

Best,
/Marco


On 2021-12-13 15:47, G=F6ran Selander wrote:

Hi Marco,

=A0

Thanks for the review. It is recorded as github issue #192 and a proposed update to the draft is in PR #199.

=A0

Comments inline= =2E Please let us know = if you have further comments on the updates made or if it is OK to merge #199 and close #192.


=A0

From: Lake <lake-bounces@ietf.org> on behalf of Marco Tiloca <marco.tiloca=3D40ri.se@dmarc.ietf.org= >
Date: Wednesday, 3 November 2021 at 17:26
To: lake@ietf.org <lake@ietf.org>
Subject: [Lake] Review of draft-ietf-lake-edhoc-12

Hi all,
=
As promised, please find below my review of EDHOC v -12.<= br>
Best,
/Marco

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[Section 1.1]


=3D=3D>MT
(trimming)
<=3D=3D

* s/compromise of the long-term keys/compromise of the long-term
identity keys

[GS] The term "identity key" is not used elsewhere in the document. The term "long-term key" is used throughout the document including the security considerations and is a common term used in protocol analysis which is what this text talks about. So I think it makes sense to not change here. The alternative would be to talk about "private authentication key" which is also used in the document, but more in the context of identities.


=3D=3D>MT
I see, then it's good to keep "long-term keys".
<=3D=3D


[Section 8.7]

* "... but intended to simplify ..."

=A0=A0=A0 Since "security context" is mentioned in the following sentences, it
is better to explicitly mention that they are referring to the
application protocol and not to EDHOC anymore.

[GS] I didn't make this proposed change because "security context" is not limited to OSCORE, so this sentence applies also to EDHOC. If you still find this misleading, please explain in what way it is so.


=3D=3D>MT
Ok, I think the confusion comes from not using "security context" as related to the EDHOC execution earlier in the document. That has rather been referred as "protocol state".

Perhaps it's worth clarifying this in Section 3.4.1, that now states twice "the retrieval of protocol state during EDHOC protocol execution." This may become "the retrieval of protocol state and its security context during EDHOC protocol execution".
<=3D=3D


[Appendix A.3]

* "EDHOC message_2 or the EDHOC error message is sent from the server to
the client in the payload of a 2.04 (Changed) response. EDHOC message_3
or the EDHOC error message is sent from the client to the server's
resource in the payload of a POST request. If needed, an EDHOC error
message is sent from the server to the client in the payload of a 2.04
(Changed) response."

=A0=A0=A0 This text should also be a remnant of old versi= ons. When using EDHOC
for OSCORE, EDHOC error messages as CoAP responses are sent as error
responses, see the first paragraph in Appendix A.3.1. The text above can
rather, more generically, be:

=A0=A0=A0 "The server sends to the client EDHOC message_2= in the payload of a
2.04 (Changed) response, or an EDHOC error message in the payload of a
response. If needed, the client sends to the server an EDHOC error
message in the payload of a POST request. Otherwise, the client sends to
the server EDHOC message_3 in the payload of a POST request. If needed,
the server sends to the client an EDHOC error message in the payload of
a response."

[GS] Good spotted, I modifed the original text in a different way:

NEW
EDHOC message_2 or the EDHOC error message is sent from the server to the client in the payload of the response, in the former case with response code 2.04 (Changed), in the latter with response code as specified in = Section 8.3.1 =A0EDH= OC message_3 or the EDHOC error message is sent from the client to the server's resource in the payload of a POST request. If EDHOC message_4 is used, or in case of an error message, it is sent from the server to the client in the payload of the response, with response codes analogously to message_2.<= span style=3D"font-size:11.0pt" lang=3D"EN-US"><= /p>


=3D=3D>MT
Looks good, although I guess you meant "as specified in Appendix A.3.1. EDHOC message_3 ..." , rather than "as specified in Section 8.3.1 EDHOC message_3 ..."
<=3D=3D
=A0

Thanks!

G=F6ran





--=20
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www=
=2Eri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistag=E5ngen 16
SE-164 40 Kista (Sweden)
--------------19FE17EB795E0C9A1304DA16-- --VInJaUpVYpEA84DVoyanlrHIrbyhEzuXq-- --Rrjqq89ZsNlaLO8GCknJUQ8T5UCA0kBrr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmG3vbgFAwAAAAAACgkQ7iZktA5Y2kO9 NAgAobWl2ljkuSVR5kTWCQEmZQWX9nrH1Myqnts/FxOqSCeo1bfdWGrU8ViT5R+2aJRH8FumlpIN JVVrQhHok+rNjckdIuUAF9h0dQNpmjREvCEEq6m9XoSFJp8p+FppEsb27YGhdVBYUz2F5JioHmh4 ruEYQicq6vTx9FQyjumrEc340bVWraoyEaVHXKMLGvvRsRfuLOF4MsZG2R5WAd5lIyOacVldAiM5 inQoRGHJRi81fwo95T9rn4w3YaUuqMSqIoPxHhssH9xwp8D+4hl8/65SCjL6vB4H7NhsPWdj0pcQ VHCGfdNF/6HZIHutLFfKdouFURilxnnsxO5flik+rQ== =Pc5L -----END PGP SIGNATURE----- --Rrjqq89ZsNlaLO8GCknJUQ8T5UCA0kBrr-- From nobody Mon Dec 13 14:44:46 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65813A0C18 for ; Mon, 13 Dec 2021 14:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZmA1HPBHvwO for ; Mon, 13 Dec 2021 14:44:40 -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 C14813A0BE0 for ; Mon, 13 Dec 2021 14:44:39 -0800 (PST) IronPort-Data: =?us-ascii?q?A9a23=3AxINGgKDj671uwRVW/zThw5YqxClBgxIJ4g17XOL?= =?us-ascii?q?fBwG7gj4j3zMHnGUZXGyBa/veY2D8fI8ja9vi/U9Sv8eAx9UxeLYW3SE0HigS8?= =?us-ascii?q?aIpJvzAcxyuZ3vKRiH7ofMOA/w2MrEsF+hpCC+MzvuRGuK59yAlj/jTHuGU5NP?= =?us-ascii?q?sYUideyc1EU/Ntjozw4bVsqYw6TSIK1vlVeHa+6UzC3f5s9JACV/43orYwP9ZU?= =?us-ascii?q?FsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRpgs1/j82D8+?= =?us-ascii?q?9mbL6f0sWBLfKJQyD4pZUc/fzxEEe/Wpri/99baZDAatUo2zhc9RZzdxJtIe5D?= =?us-ascii?q?xk0NazKme81Uh9CEig4M7cuFLrveCDg7JzOkheun3zEhq8G4FsNFYkR+etfAGx?= =?us-ascii?q?S+7ofMj9lU/wpr4pa25rkG6812p9ldZCyetpD5RldIfjiJa5Oafj+r2/ivLe0B?= =?us-ascii?q?AsNu/0=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AJJuR8K9qCJGtmc+oiy9uk+BsI+orL9Y04lQ7?= =?us-ascii?q?vn1ZYQdec8yGm83rtOlz726+tN93YgBHpTngAtjmfZqyz/5ICOMqUYtKYjOWx1?= =?us-ascii?q?dAQLsSjrcK4geQYxEXGIZmpO9dm4YXMqyEMbFRt7eJ3OEheOxQieVuyciT9JHj?= =?us-ascii?q?J50Ed3AfV0gY1XYPNu/5KDwTeOAlP/sE/cGnl7Q31gZIEE5/Bq/QaRc4to741q?= =?us-ascii?q?f2fb3dEG477nUcmXKzZF2TmdzH+lSjr3IjegIK6bA+8VfEiBDij5/T+c1S9HXn?= =?us-ascii?q?phLuBvlt9ecJseEzffBlgaIuW0nRozftY4IkU6aJvTArrIiUmSUXrOU=3D?= X-IronPort-AV: E=Sophos; i="5.88,203,1635199200"; d="scan'208,217"; a="10758552" Received: from unknown (HELO smtpclient.apple) ([79.143.111.147]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2021 23:44:37 +0100 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: multipart/alternative; boundary="Apple-Mail=_991F5DD3-9EBA-467F-8905-C1057B2045BE" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Message-Id: <21712AC9-58F1-42C1-A366-3F35525C4542@inria.fr> Date: Mon, 13 Dec 2021 23:44:31 +0100 To: lake@ietf.org X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: [Lake] LAKE interim Wednesday 1800 UTC X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 22:44:45 -0000 --Apple-Mail=_991F5DD3-9EBA-467F-8905-C1057B2045BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, As a reminder, our group will be meeting this Wednesday, 15 December = 2021 at 1800 UTC. We posted the agenda and it is available at [1]. The = webex link is available at [2]. I kindly ask the presenters to upload the slides by Wednesday noon UTC. = We will be going over the latest changes, status and the reviews of = draft-ietf-lake-edhoc and draft-ietf-lake-traces. In case you would like to help with taking notes, please drop us an = email.=20 Talk to you on Wednesday ! Mali=C5=A1a and Stephen [1] = https://datatracker.ietf.org/doc/agenda-interim-2021-lake-05-lake-01/ = [2] = https://ietf.webex.com/ietf/j.php?MTID=3Dme537335f0364ae8993f92970a387a9c5= = --Apple-Mail=_991F5DD3-9EBA-467F-8905-C1057B2045BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

As a reminder, our group will be meeting this Wednesday, 15 = December 2021 at 1800 UTC. We posted the agenda and it is available at = [1]. The webex link is available at [2].

I = kindly ask the presenters to upload the slides by Wednesday noon UTC. We = will be going over the latest changes, status and the reviews of = draft-ietf-lake-edhoc and draft-ietf-lake-traces.

In case you would like to help with taking notes, please drop = us an email. 

Talk to you on Wednesday = !

Mali=C5=A1a and Stephen

[1] https://datatracker.ietf.org/doc/agenda-interim-2021-lake-05-la= ke-01/= --Apple-Mail=_991F5DD3-9EBA-467F-8905-C1057B2045BE-- From nobody Tue Dec 14 00:28:35 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419FD3A08B8 for ; Tue, 14 Dec 2021 00:28:33 -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 (1024-bit key) header.d=fraunhofer.onmicrosoft.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 VjyW0H3Ks6XC for ; Tue, 14 Dec 2021 00:28:26 -0800 (PST) Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de [153.96.1.24]) (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 3AEBD3A08B7 for ; Tue, 14 Dec 2021 00:28:23 -0800 (PST) IronPort-SDR: Xt0pr6cYnXWH5O+zH3x48wbT8nGbaTLePJqyjcluFJqb04Cxk4hn261lg/jd8tv60OE4DFnrIr sCY9XBlLDxz/2hmCWo6bA4XbS4VYdDa3Ve6ncFWrqRoyK/HoFFB0pDWKrAIUFj0wCFY4nqUGGo uW9xDpTyGigC7/gBOo6os80qJFEu3qXAB/hDV0PLSJXnjdUScW5Klv3Jgjd6aU1vhyEGCrAw/f OASGuXvlKjB2vGh32ofYBbg05KMPZoqHjepoEjWI0nhS/9YUBO5hXpawe8M0+7ecERlGPbmIq4 qZk= X-IPAS-Result: =?us-ascii?q?A2GABQB7VLhh/xoBYJlQCoQDMScuf4FChEiDRwOFOYUOg?= =?us-ascii?q?wIDkDCKaoJTAxgWJgsBAQEBAQEBAQEHAQE3CgQBAQMEhH8CF4MRASU4EwECB?= =?us-ascii?q?AEBAQEDAgMBAQEBBQEBBgEBAQEBAQUEAgKBGIUvOQ2DU007AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQIIORkuDBIBHgEBAQEDEhEEG?= =?us-ascii?q?QEBLAwPAgEIEQMBAiEBBgMCAgIwFAkIAgQBEiKCUIIOUgUDLgEBDqNIAYE6A?= =?us-ascii?q?oofen8yH2KCCAEBBgQEgTYBgRuCORiCNQMGCQGBMIMOhBwBAYcGJ4FmQ4EVN?= =?us-ascii?q?oJ0PoJjAoEzCwEBNwkNCYJigmWSFhFbBRg3GhQeERAgNgIOKw4sEyUBBgUEG?= =?us-ascii?q?QUCM5FugTaCJokunwuBKwMEA4ILgTWKY5RGM4NvjAKGHZFCli0fgiOKO5Nwh?= =?us-ascii?q?TMCBAIEBQIOAQEGgXiBfnFPgjUBATIJSBkPVpE8M4RhhUp0AjYCBgEKAQEDC?= =?us-ascii?q?ZBwAQE?= IronPort-PHdr: A9a23:oh+BohSic93+4DWlmHCcQwJIy9pso63LVj580XJvo75Nc6H2+ZPkM QSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAAhkCj8hFkwkpGsXQD0r9IbbjZDA7G 8IXUlhj8jm7PEFZFdy4aUfVpyi77CUfEVPxLwNoIOTyFIPIyci6hIiP X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.88,204,1635199200"; d="scan'208,217"; a="38062279" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2021 09:28:20 +0100 IronPort-SDR: c3s4jLG/1lPUsNDFzynm7SgR6f5+w1W82s80OmTgTQ38wxXZqbgm+uG/e+v+myWvp1+0qM/ZPH XZcwJvMXm7yCyK25xthi+uw7HgHsxG7EQ= X-IPAS-Result: =?us-ascii?q?A0CNAQAGVbhhXz6wYZlQCoESgnExJy4HTCxZJkOER4NHA?= =?us-ascii?q?4U5hQ5dAYIkAzgBj3eKaoJTA1QLAQMBAQEBAQcBATcKBAEBhQYCF4MOAiY4E?= =?us-ascii?q?wECBAEBAQEDAgMBAQEBBQEBBQEBAQIBAQUEBzILDgUOEEFkaIFPgWETCzQNh?= =?us-ascii?q?kIBAQEBAxIRBBkBARQYDA8CAQgRAwECIQEGAwICAjAHCgMJCAIEARIiglCCD?= =?us-ascii?q?lIFAy4BAQ6jSwGBOgKKH3p/Mh9igggBAQYEBIE2AYEbgjkYgjUDBgkBgTCDD?= =?us-ascii?q?oQcAQGHBoINQ4EVNoJ0PoJjAoEzCwEBNwkNCYJigmWSFhFbBRg3GhQeERAgN?= =?us-ascii?q?gIOKw4sEyUBBgUEGQUCM5FugTaCJokunwuBKwMEA4ILgTWKY5RGM4NvjAKGH?= =?us-ascii?q?ZFCli0fgiOKO5NwhTMCBAIEBQIOAQEGgXgigVtxT4I1AQEyCUUBAgECDQECA?= =?us-ascii?q?gMBAgECCQEBAlORPDOEYYVKQzECNgIGAQoBAQMJkHABAQ?= IronPort-PHdr: A9a23:feRAmRAaTtm6JfdK1wdSUyQVfhdPi9zP1kY95pkmjudIdaKut9TnM VfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKWkwJjMwMlFkmB8iIQUTwMP/taXk8G 8JPHF9o9n22Kw5bAsH7MlTTuXC5qzAIEwj5NQ17K/6zFoOB5/k= IronPort-Data: A9a23:NmqsrqsEgeNIyJIg00JKI9soeefnVApYMUV32f8akzHdYApBsoF/q tZmKTuDO/aPYTajeYx3YI6x/ElX78LRxtJqGwM6rS5mRS4VgMeUXt7xwmUckM+xwm0vaGo9s q3yv/GZdJhcokf0/0zrb/69xZVF/fngqoDUUYYoAQgsA180IMsdoUg7wbdg2Nc02YHR7z6l4 LseneWPYDdJ5BYpagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDf3Zw0/Df2VhNrXSq 9AvbF2O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/RPjnRa70o1CBYTQWlxi2+2s/ZL8 s5QmKSpZxcNHI3Okt1IBnG0EwkmVUFH0KTCPWD5vNyYzwvIaXLxxfVpAkwse4EVkgp1KTgTr rpJd3ZUMU7F2bjeLLGTEoGAguw4MMTlNYVZumth1i3eH/E4aZnCWKjBo9FC1So2hsdAEOyYa 8dxhT9HMk2QMkEWaj/7Drpum9+LwX2ifAZ4i1+So65mzjj1xxNYhe2F3N39IIXRHJ4Fzy50v Fnu8GPjCxdcL9GbwDyJ/2iEi/XOljjgX4RUH7q9ntZuiV6e7m0eFBNQUkG0ycRVkWbnBokae hNRo3Vw6PZoslKuCNK7UQexvXiEuRARQZxcHoXW9T1h1IL6xQbDOUQidARadfEereEmYR4K1 FWwyoaB6SNUjJWZTneU97GxpDy0ODQIIWJqWcPiZVZYizUEiNxq5i8jXuqPA4bo14ekSGqYL ySi/XRv3u17Ydsjjf3jlW0rlQ5AsbDlY2YICuj/Bz/+q1ImIdf6Ocn2sx7F6LBLaoiDR0SHv H8KltLY4O1m4XCxeM6lHrhl8FKBva3t3NjgbbhHQ8VJG9OFpyTLQGyoyGsiTHqFy+5dEdMTX GfduBlK+LhYN2awYKl8buqZUppxnPS6TY69DqyNP7Kih6SdkifYoUmCgmbPhQjQfLQEy/FuU XtmWZn9VilCU/gPIMSeG75GiuFDKt8CKZP7H8mglk/3gNJylVaZRKoZK1COY/tx4qSeuw7V7 tBQLM2H1wc3bQENSna/zGLnFnhTdSJTLcmv86R/L7ffSiI7ST1JI6GKm9sJJdc695m5Y8+No xlRrGcHkQWj7ZAGQC3RAk1ehETHAcwi8CllZHN0Zj5FGRELOO6S0UvWTLNvFZFPyQCp5aAco yAtd5rSD/JRZC7A/jhBP5DxoJY7JUaihBmDNGyrejEieZ5nSQHTvNPpJ1O9+C4LByuxlM0/v 7z5ilKFG8VeHVw6AZaEcu+rwnOwoWMZxLB4UXzOL4QBY07r6oVrd3H8g6ZvccEBIBnO3BWA0 AOSDUtKrOXBudZkotDInq2P6YmzGvZ4Hk1UEnOd4bvvbXvW+W+qwIlhVueUfGmBBT2up/j4P b1YlqiuPucGkVBGt5tHP4xqla9utcHyo7J6zxh/GCmZZVqcDL49cGKN2tNCt/EQy7JU5Vm2V 0aI9oUIMLmFIpm+QkUUOBJjY/SI1bcagDDP6/QyLkjgoiN6peLVXUJXNhiKqSpcMLosbNJ7m 7h84pZO5lztkAcuP/aHkjtQqzaGIEsGXvh1rZodGoLq1lcmxw0Qe5DaESOqspiDZ88XaBtzf 2TR1fWH3usCgxSYNWQ2U3OL0/BUmJIOvx5H1hkOKg3RyNbCg/Y22jxX8Cg2F1gEkE8YjrgrY mU7ZVdoIaiu/itzgJQRVW6bHQwcVgaS/Vb8ygdUmWDUJ6Vyurch8IHg1T6xwX0k IronPort-HdrOrdr: A9a23:0KZ19q/a5Rr3bD2hR2Buk+AZI+orL9Y04lQ7vn2ZFiY0TiXIra GTdaoguyMc6AxhPE3I+OrwSpVoJEmsk+8N3WB/B8bdYOCLghrZEGgA1/qY/9SDIVyAygc178 4JGNkdebrN4EBB/KPHCW+DYqsdKbG8gcOVbMjlvgtQpGpRGtBdBmlCe3WmO3wzaC96JfMCZe /skvavZADLRZ3aVKiG77A+Moez36ywqK7b X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.88,204,1635199200"; d="scan'208,217";a="6189418" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO smtp.exch.fraunhofer.de) ([153.97.176.62]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2021 09:28:18 +0100 Received: from XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) by XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 14 Dec 2021 09:28:17 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (104.47.13.58) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 14 Dec 2021 09:28:17 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iWtOKujeDBwROrAe2ptMbc9rM16TutXZ2JlJy/3CxDWObHBWel8dcv3N4Vqia09pHbWwdZwA6gA+O898X7biWLzGWbigYjedQ52MmTGnM3ZrIqXELLyhmq1kXqaNSkE1mk1C/bqzGuNeQe8xTgORPXEOqna6q73BI/AZCmpbyuJyvRGBenkdjP00DdyBoAjV1tgP3mY9SwMwE7puOjjw5Ma4Hfj6AhKNFbQsCW1Xh5TEmlsc8kGggCHaQ8Exu/VmED1H6jtZD4hlfoET9uwEsKoVncywbiQIns70LVCh3CA/ZoY9sra8lPVkkYCkmHX+tpQA8A8E5f7BiC4/X+JZOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VyT+fqP2/JlXanP/E0n4NtF0JjQvN90h+1dSbDGnub8=; b=JlVLLHtlBhdeTCcF/N/o4ATMcuP5J5CFssC1Yd3FIHfL/p5hC6z7Vxc8adTYSSlTjsWmfijkN9Dfq+GRO3nsJS2Nej6/LFBB67NSEIYjRGZPouHoJX3gZH2dD7k6S9DfxLoG9eZuAT6v47KC3mopHYtaVq4uMLHGVrCEMh+mewOP+LbebGSavta8P/WQB1SaywhBJGa1D91ZQuJc9n1DilM0YZzPLvSPNF+FQEhgGSzcP1ttwB+tC+UJVRrb5BhviVR6FMZe8i76fMmamTbr5ciGBO4OF5fOO3PtnSxsbmliTAHB618TORGP+2rKWxbGt8MXeu5PbYuhSgWQLF+xzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aisec.fraunhofer.de; dmarc=pass action=none header.from=aisec.fraunhofer.de; dkim=pass header.d=aisec.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VyT+fqP2/JlXanP/E0n4NtF0JjQvN90h+1dSbDGnub8=; b=LXQJGDPSJ9hMGiuEHiSxu+T6/8IeWpX7bN9/dRvLiAWwdgFtpCueXNlNLsDwQ+w9lDfh4nOODUE0vDFgDvPKtvgTGjmmZNey8VAdyGTZye/isZrf2xYpi44/WJuHex+EoBY5hS7kMtA/7CS5iOUnjSTOeNvTQUnuaYyvQTYQHiY= Received: from AM9P194MB1442.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:3a7::13) by AM0P194MB0338.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:62::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.12; Tue, 14 Dec 2021 08:28:16 +0000 Received: from AM9P194MB1442.EURP194.PROD.OUTLOOK.COM ([fe80::71cc:5590:c405:d156]) by AM9P194MB1442.EURP194.PROD.OUTLOOK.COM ([fe80::71cc:5590:c405:d156%8]) with mapi id 15.20.4778.018; Tue, 14 Dec 2021 08:28:16 +0000 From: "Hristozov, Stefan" To: "goran.selander@ericsson.com" , "lake@ietf.org" Thread-Topic: Review EDHOC-v12 Thread-Index: AQHX0W9vPW87iAHERUCkfmEyZh8LBawlx2dGgAwezoA= Date: Tue, 14 Dec 2021 08:28:16 +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: Evolution 3.36.5-0ubuntu1 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=aisec.fraunhofer.de; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c207afc6-7f44-453c-f7cb-08d9bedbad2f x-ms-traffictypediagnostic: AM0P194MB0338:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C2dl4kbDa6QqIGffEMyB9s7hTqMj1QgO4a8k/fUnNJyBYp2Z+lHueiRGfP7HkIxC/XnbZtYHhR5+OND5vhVQ0Z68mamwmJKTlCBWLQ96YDw2YyqCGK6eP4oNvN6aSUWucpmfOFbZyXGYDi/QSx7SSEgwywM/bddrixF7yZX6nRYifeOHvH4JQtib0sNVx5wTaBozak9BpgoWt4XwQ1TeXpPtL2sVZbE4JyBtcretm8AoUi3Srn0rU8uBrRmbBYWeUO20M+XJM3SOiX07ML2pymt6Wer9CWze18+YO9atX9yjg2qC8P2t/Q6NWiWNp2p+mCqnpuc4bsVbloyDQgbe4d5Bsjg29aGcxwGS+OIGstOXKt0+9No3c6emxyNlTT13KnwA5EmNhOXU+R9WXbOVNLAsY+kp/TYdZc8t5SrzWi68UvBo9dCvQS2dST2qaGTDuFe8XAcFfAc9qd69vgNHHWK8vAcjBAbTHZPuY2RVSqzgLbQXWCcBxj3UB+LAneIgudNFhzuAUfJaN/x+WwHnjiIio7+6duwZCE5s1Sx4PSsFYOA/jp6z3rCC6p5SDZm9MJovtBtXckqz6T/aNe2slr+0NnbQRfy4bwD9w/52EnRGjeN52ehP78Du4FytSJBgQlZh+sJyXp8zt7YiWpu8sIN4FefDFfm3rIXjInSQddKiVJf9I/9oDtlDaRoZqffy8vtQg+WoyRK1O3MLFHhK+ay+6x6B1Bostm/1jKSjJ2rkwIwTUbaw5UKVko/tLOx6Y2xiNjnA/zfjNbYyMpn/WkFQQpckMxLJc/nwsGaWfR8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P194MB1442.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(53546011)(2616005)(6506007)(8676002)(83380400001)(8936002)(66574015)(86362001)(66446008)(19627405001)(66946007)(91956017)(4001150100001)(508600001)(966005)(64756008)(71200400001)(76116006)(66476007)(66556008)(110136005)(5660300002)(6512007)(186003)(122000001)(82960400001)(2906002)(6486002)(38100700002)(166002)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 2 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VUN5Ymd3ZEg4UlplNEdVWG8rR1Qrc0lOem5ncWYyUXkvZ0Ivb25JOU5EUytM?= =?utf-8?B?UXl6VXhnUnNOazU5MHYrMmNERWM3VGNFcllSb0pNSzVlNityRStEeFcvUWdW?= =?utf-8?B?VExSdmpYZ2tpb1BwVk41aFArQmQ2cEx6VWZxVm5Ib3U1L2JmdVNDYXFYZU1S?= =?utf-8?B?bDZWTUd1NFNiQzE2U0V5WGJHLzJKVTVLZFlGS2RhUnZvVW9XVkF3M3Myb1hQ?= =?utf-8?B?eXkvcDdMNTNnaDNyeXozaGFVSWYzUTVQSS9hTGhocTVrdEhJZEpjU0duaThH?= =?utf-8?B?eFNUaVAvQUdwUmZKRzJqUVdaS1piakw4VXJGaktZUmVUSUFRcFZyK1g4TWRD?= =?utf-8?B?Y1JNVCtyZFV0bUlST2tlTURGNWsram5WVXpDNHdJQk5DWURLVzVYZEpQVEJw?= =?utf-8?B?aDlraVlFQ0N5VGxHbDZHOFdBNFJVQjBIMVNLVUtGc0pST2FFcmc4VEM4THU0?= =?utf-8?B?STF3d01NU0FvMnpFbkhmY1VsZGZTbzdpYzlITStDbWhnTXdFNDVCNmF3dUFI?= =?utf-8?B?UjZ4N3JMSk1ZVkcyaHd4dk1XT01iS2N5cTlBRldrL2hmYlVleTE2Z3NXWXpD?= =?utf-8?B?cm9Tam51VFNuZm0zOXU3RjczaDBhQjZjNmVTZnBkZ1ZEUEYrNmt6U3RselZ1?= =?utf-8?B?aHFneGxtT2YzNDNGNDNDem5TcGZLeDFVN3NxWkw3WngxWDdoOE1YNUVKNFlK?= =?utf-8?B?NDdveGtzNEszUTUvdmtxNFE3NmRncnpSVkJxaGVCY0ZTN093T0JqYXdUdnlH?= =?utf-8?B?NExJZ0puQzQ2OW40bHk5UTdMVUM2eCtuS3VOMDJxZ2dJOG16Yk01NnZiV2lR?= =?utf-8?B?cGM4cGdZSWk3TWpUYjlqaGQ4RjlPdlFwRTd0RW9Sa24vbjVwZFpVMS9KbXBS?= =?utf-8?B?dWI4NnBaYStnT2lrYXRXZkJXaGNJSmFVaWw5aXZzZUQ2SCtvS3FiQUZQSW1T?= =?utf-8?B?YmV1RnJaUlFWNVBDSkpDQVVSTkVYVERmUTM5YnNPZlR3ZFBMeGRBTTJMNWV5?= =?utf-8?B?OUhWaGpyZmdSb1ROZ0V0NmJBc2RPM1BvcDYrVnVwOFdSN09US25RNWVDS2pa?= =?utf-8?B?eWU1Vm9hOHNXMXNKNW0ya0d0SWhoRVRobjJDSUJZa3d4elI2Tk4xb0hjcWxM?= =?utf-8?B?Z2JSS1MwZzg5QmN4NXZENFFHNXJKN3B4aUlmMVRKU3MwNURGVWR2OGpnZktU?= =?utf-8?B?MDNkTWRyVXZJSHB4dk5RWTJqRUJ4NWNWbjR0eTJoRmZWYTg4Z0hSc1Rtenox?= =?utf-8?B?ZEpJVEp2TkRvblh1QSs2QnhMMTJZcysxOTN6RUh1NzUwYjdhV2ZtOUNZNFND?= =?utf-8?B?cFVHSDVHbW5VTDBqTE14T3o2WDE5YXRLNmRVeDM2K3NBSDhDKzN4YUtmVk9X?= =?utf-8?B?VU04OVd2algxMUpTdnVDOEhMVGt5ZFZReTlzeUFNRmVNSk5na2FSay9xTVM4?= =?utf-8?B?T1NSUlI2YlZocGlQU2xSS0dTekVEOWNyMWdaRkFrZTA3U01zUi9xQXZUTUpt?= =?utf-8?B?b2hUWmFUbkFDeXlBZzlpRDZvSm4wVnBuQ1Ivd1dXL2FYMVU0L2hNSFU1eUpl?= =?utf-8?B?T2Z6M0xBN1BGbzgxbi9JOGRhOVNlTTF3TkQ0VjRwY1ljUkpKQUhpZ1lRL3l2?= =?utf-8?B?QmRyakRkN2I0TXQxMkdxdXNTOUU1RzZpa21ONE1OVHF5Z1ZOdEdtNnRlbkZ6?= =?utf-8?B?WWc2WWYvY202RGFNemwvSWZKWXZmWWNzcEdLMnNuMXpiOUR6Skk5bkMreW94?= =?utf-8?B?RUdpajBGU21rNUVuNldhK21meXdMNDN5d2tDeThXbDJiY2EvQ1F0Mk83TU5x?= =?utf-8?B?anRaNTVWS1dVWEFaSnUvR1VEVlJpdklXbTZuRHZYek02YzJRSTJ5OGRkTE5H?= =?utf-8?B?a2t1OTliMVVGbk0wOENMWXdXYkVBUmhrUzdyQVVuNXN3OGp5SlVUMXYzTzJk?= =?utf-8?B?a3l5M2NpZkgwSktWYTF2VUFpRzg1eHppZU02eWx0QjlOWWJpZUZtSnZWZVRp?= =?utf-8?B?VVg0aFljQVdBZnpNNERzMnNLNGFKeTgwaUQ3NHFUNnFWM1h1aExtSTR6WVpZ?= =?utf-8?B?VWdkT1JSUElyMkZ6V1QwV01SS1hVd1I2RFhldTdNZnlYRGl3dWxIYVo3Q3F1?= =?utf-8?B?ZmV1RGtlc2t2RkhLWFlVUE5BSFdtTWZPblRPYXlSUUZ2WVdhRUwydTl1RnJy?= =?utf-8?B?WHJxQ01LVTNtQ0Y3N29JZmtmSXVtbzhuNXAxN0QzczRYSVpOTDNCc0pobk5m?= =?utf-8?B?cGRRZ04wUzRnUjB2WTBNb1RLVGVLNXg1eCtqU0FmeTJLWU0yVDNuQ09Keiti?= =?utf-8?B?ZnZ2eGduNlFlZzdUbXBQVUp1dXBML2REVFpVc1R4ekJPTkZRT2RGUzJOYk41?= =?utf-8?Q?1EI38BIQ1TUaQ6K/FtXnohSjnetBELpobrAgdGCW9ExBD?= x-ms-exchange-antispam-messagedata-1: swjTAGGiZ5pNcw== Content-Type: multipart/alternative; boundary="_000_ea2d4c1520f401e99d62110bb0f81d40d36ff974camelaisecfraun_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9P194MB1442.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c207afc6-7f44-453c-f7cb-08d9bedbad2f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2021 08:28:16.0859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sqgzEhjZ7BFCQlGUDYhRy8zKdlp535iJL0rbSxB9NtG1J8+cjNeFn880JSwqcifb53ROlO2F7URMtnq+5TxiBXdFcnmvJ6CGaG19HTcNfLR8t/T3UqfseUSlemRjo609 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0338 X-OriginatorOrg: aisec.fraunhofer.de Archived-At: Subject: Re: [Lake] Review EDHOC-v12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 08:28:33 -0000 --_000_ea2d4c1520f401e99d62110bb0f81d40d36ff974camelaisecfraun_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR8O2cmFuLA0KDQp0aGFua3MgZm9yIGFkZHJlc3NpbmcgbXkgY29tbWVudHMhDQoNCkl0IGxv b2tzIGdvb2QgdG8gbWUuIEkgd291bGQgbGlrZSB0byBzdWdnZXN0IG9ubHkgdG8gYWRkIHRoZSBy ZWxldmFudCBSRkMgcmVmZXJlbmNlcyByZWdhcmRpbmcgcmV2b2NhdGlvbiBpbiB0aGUgc2VjdGlv biAiSW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlvbiIuDQoNCkJlc3QgcmVnYXJkcywNClN0ZWZh bg0KDQoNCk9uIE1vbiwgMjAyMS0xMi0xMyBhdCAxNDo1NyArMDAwMCwgR8O2cmFuIFNlbGFuZGVy IHdyb3RlOg0KSGkgU3RlZmFuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIEl0IGlzIHJlY29y ZGVkIGFzIGdpdGh1YiBpc3N1ZSAjMTk0IGFuZCBhIHByb3Bvc2VkIHVwZGF0ZSB0byB0aGUgZHJh ZnQgaXMgaW4gUFIgIzIwMC4NCg0KQ29tbWVudHMgaW5saW5lLiBQbGVhc2UgbGV0IHVzIGtub3cg aWYgeW91IGhhdmUgZnVydGhlciBjb21tZW50cyBvciBpZiBpdCBpcyBPSyB0byBtZXJnZSAjMjAw IGFuZCBjbG9zZSAjMTk0Lg0KDQoNCkZyb206IExha2UgPGxha2UtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIEhyaXN0b3pvdiwgU3RlZmFuIDxzdGVmYW4uaHJpc3Rvem92QGFpc2VjLmZy YXVuaG9mZXIuZGU+DQpEYXRlOiBUaHVyc2RheSwgNCBOb3ZlbWJlciAyMDIxIGF0IDEyOjQzDQpU bzogbGFrZUBpZXRmLm9yZyA8bGFrZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtMYWtlXSBSZXZpZXcg RURIT0MtdjEyDQpIaSBhbGwsDQoNCnBsZWFzZSBmaW5kIGJlbG93IG15IHJldmlldyBvZiBkcmFm dC1pZXRmLWxha2UtZWRob2MtMTIuDQoNCkJlc3QgcmVnYXJkcywNClN0ZWZhbg0KDQoNCjIuIE91 dGxpbmUNCiJJRF9DUkVEX0kgYW5kIElEX0NSRURfUiBhcmUgY3JlZGVudGlhbCBpZGVudGlmaWVy cyBlbmFibGluZyB0aGUgcmVjaXBpZW50IHBhcnR5IHRvIHJldHJpZXZlIHRoZSBjcmVkZW50aWFs IG9mIEkgYW5kIFIsIHJlc3BlY3RpdmVseS4iDQpJIHdpbGwgcmVwbGFjZSB0aGlzIGRlZmluaXRp b24gd2l0aCBzb21ldGhpbmcgbGlrZToNCklEX0NSRURfSSBhbmQgSURfQ1JFRF9SIGFyZSB1c2Vk IHRvIGlkZW50aWZ5IGFuZCBvcHRpb25hbGx5IHRyYW5zcG9ydCB0aGUgYXV0aGVudGljYXRpb24g a2V5cyBvZiB0aGUgSW5pdGlhdG9yIGFuZCB0aGUgUmVzcG9uZGVyLCByZXNwZWN0aXZlbHkuDQoN CltHU10gRG9uZSBpbiBQUiAjMjAwLg0KDQozLjggRUFEDQpJcyBFQUQgZGF0YSBnZW5lcmF0ZWQg YnkgdGhlIGFwcGxpY2F0aW9uIG9yIGRhdGEgdGhhdCBpcyBwcmUtcHJvdmlzaW9uZWQgb3Igb2J0 YWluZWQgZnJvbSBzb21ld2hlcmUuIElmIHRoZSBmb3JtZXIgaXMgdHJ1ZSBJIHdvdWxkIGxpa2Ug dG8gc3VnZ2VzdCB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGFsbG93cyBmb3IgaW1wbGVtZW50YXRp b25zIHdoZXJlIGFsbCBpbnB1dHMgYW5kIG91dHB1dCB0aGF0IGFyZSBnZW5lcmF0ZWQgYXQgcnVu IHRpbWUgYnkgdGhlIGFwcGxpY2F0aW9uIGFyZSBwcm92aWRlZCBpbiBub24tZW5jb2RlZCBmb3Jt IHRvIHRoZSBFREhPQyBpbXBsZW1lbnRhdGlvbi4gSW4gdGhpcyB3YXksIHRoZSBpbnRlcmZhY2Ug dG8gdGhlIGFwcGxpY2F0aW9uIHdpbGwgYmUgc2ltcGxlciBhbmQgQ0JPUiBlbmNvZGluZyBhbmQg ZGVjb2RpbmcgY2FuIGJlIGNvbXBsZXRlbHkgaGlkZGVuIGZyb20gdGhlIGFwcGxpY2F0aW9uIGRl dmVsb3Blci4gVGhpcyBhcHBsaWVzIGVzcGVjaWFsbHkgZm9yIEVBRCwgc2VlIGlzc3VlICMxODYu IFRoZSBnZW5lcmFsIHF1ZXN0aW9uIGlzIHdobyBpcyBzdXBwb3NlZCB0byBlbmNvZGUvZGVjb2Rl IEVBRD8gVGhlIGFwcGxpY2F0aW9uIG9yIHRoZSBFREhPQyBpbXBsZW1lbnRhdGlvbj8gQXMgZmFy IEkgdW5kZXJzdGFuZCB0aGUgc3BlY2lmaWNhdGlvbiBub3cgb25seSB0aGUgYXBwbGljYXRpb24g a25vd3MgaG93IHRvIGVuY29kZSBhbmQgZGVjb2RlIEVBRC4NCg0KW0dTXSBDb3JyZWN0LCB0aGUg YXBwbGljYXRpb24gZW5jb2Rlcy9kZWNvZGVzIEVBRC4gSG93ZXZlciwgZm9yIGNlcnRhaW4gRUFE IHVzZSBjYXNlcyBpdCBtYXkgYmUgbW9zdCBhcHByb3ByaWF0ZSB0byBpbXBsZW1lbnQgcGFydCBv ZiB0aGUgYXBwbGljYXRpb24gYW5kIEVESE9DIHRvZ2V0aGVyLiBXZSB3aWxsIGFkZCBhbiBhcHBl bmRpeCB3aGljaCBwcm92aWRlcyBzb21lIGV4YW1wbGVzIG9mIHRoaXMsIG5ldyBpc3N1ZSAjMjEw LiBHb29kIHBvaW50IGFib3V0IGlucHV0IGFuZCBvdXRwdXQgaW4gbm9uLWVuY29kZWQgZm9ybSwg dGhhdCBzaG91bGQgYWxzbyBiZSBpbmNsdWRlZCBpbiB0aG9zZSBleGFtcGxlcy4gQVBJcyBhcmUg bGVmdCBvdXQgb2Ygc2NvcGUsIGJ1dCBpdCBtYWtlcyBzZW5zZSB0aGF0IEVESE9DIGltcGxlbWVu dGF0aW9uIENCT1IgZW5jb2RlcyB0aGUgbm9uLWVuY29kZWQgaW5mb3JtYXRpb24uDQoNCg0KNS4y LjENCiJJZiB0aGUgbW9zdCBwcmVmZXJyZWQgY2lwaGVyIHN1aXRlIGlzIHNlbGVjdGVkIHRoZW4g U1VJVEVTX0kgaXMgZW5jb2RlZCBhcyB0aGF0IGNpcGhlciBzdWl0ZSwgaS5lLiwgYXMgYW4gaW50 LiINCkFtIEkgdW5kZXJzdGFuZGluZyB0aGF0IGNvcnJlY3RseTogSWYgb3RoZXIgc3VpdGVzIGFy ZSBzdXBwb3J0ZWQgaW4gYWRkaXRpb24gdGhleSBhcmUgbm90IHNlbnQsIGUuZy4sIGlmIHRoZSBp bml0aWF0b3Igc3VwcG9ydHMgc3VpdGVzIDEsMiwzLCB3aGVyZSAxIGlzIHByZWZlcnJlZCBhbmQg c2VsZWN0ZWQsIDEgaXMgc2VudCBhcyBpbnQgYW5kIDIsMyBhcmUgbm90IHNlbnQ/IElmIHNvIEkg d2lsbCBzdWdnZXN0IG1ha2luZyB0aGlzIHNlbnRlbmNlIG1vcmUgY2xlYXIuDQoNCltHU10gWWVz LCB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4gU2luY2UgdGhlIHByb2NlZHVyZSBwcmVz Y3JpYmVzIG9ubHkgc2VuZGluZyB0aGUgY2lwaGVyIHN1aXRlIHdoaWNoIGlzIHNlbGVjdGVkIGFu ZCBtb3JlIHByZWZlcnJlZCBzdXBwb3J0ZWQgY2lwaGVyIHN1aXRlcywgaWYgdGhlIHNlbGVjdGVk IGlzIHRoZSBtb3N0IHByZWZlcnJlZCB0aGVuIG9ubHkgdGhhdCBjaXBoZXIgc3VpdGUgaXMgc2Vu dC4gSSB0cmllZCB0byBjbGFyaWZ5IHRoZSBzZW50ZW5jZSBmdXJ0aGVyLCBzZWUgUFIjMjAwLg0K DQoNCjYgRXJyb3IgSGFuZGxpbmcNCldoYXQgaXMgdGhlIHVzZSBjYXNlIGZvciBhIHN1Y2Nlc3Mg ZXJyb3IgY29kZT8gUHJvYmFibHkgaXQgaXMgZ29vZCB0byBnaXZlIHNvbWUgZXhhbXBsZSBvciBy ZWZlcmVuY2Ugd2h5IGl0IGlzIHVzZWZ1bCB0byBsb2cgc3VjY2Vzc2VzIHVzaW5nIGEgcHJlZGVm aW5lZCBlcnJvciBjb2RlIGFuZCBlbmNvZGluZy4gSXMgbG9nZ2luZyB0aGUgb25seSB1c2UgY2Fz ZSBmb3IgdGhlIHN1Y2Nlc3MgZXJyb3IgY29kZT8gRm9yIGV4YW1wbGUsIG15IGltcGxlbWVudGF0 aW9uIGxvZ3MgbWFueSB0aGluZ3MgZm9yIGRlYnVnZ2luZyBwdXJwb3Nlcy4gSG93ZXZlciwgSSBu ZXZlciBuZWVkZWQgYSBzdWNjZXNzIGVycm9yIGNvZGUuDQoNCltHU10gVGhlIGVycm9yIGNvZGUg Zm9yIHN1Y2Nlc3MgY2FtZSBhYm91dCBmcm9tIGEgbWFpbCBleGNoYW5nZSBvbiB0aGUgSU9UT1BT IFdHIG1haWxpbmcgbGlzdCBbMV06ICIyLiByZXNlcnZlIG9uZSBvZiB0aGUgc3RhdHVzIGNvZGVz IGZvciBzdWNjZXNzLCBzbyB0aGF0IHRoZSBzdGF0dXMgcmVwb3J0aW5nIGNhbiBhbHNvIHVzZSB0 aGUgc3RhbmRhcmQgdmFsdWUgaW4gY2FzZSBvZiBubyBlcnJvciIuIEkgYWRkZWQgdGhpcyBleHBs YW5hdGlvbiB0byB0aGUgdGV4dCBpbiBQUiAjMjAwLg0KDQpbMV0gaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9pb3RvcHMvdDlMVHBNaVpfX2tGR1pwY2VMQ0JhQ1VITjQ0Lw0K DQoNClRoZSBzcGVjIHNheXMgdGhhdCBzdWNjZXNzIGVycm9yIGNvZGUgbXVzdCBub3QgYmUgc2Vu dCwgdGhlcmVmb3JlIHRoZSBzZW50ZW5jZSAiRXJyb3IgY29kZSAwIE1BWSBiZSB1c2VkIGludGVy bmFsbHkuLiIgbmVlZHMgdG8gYmUgIkVycm9yIGNvZGUgMCBNQVkgYmUgdXNlZCBfb25seV8gaW50 ZXJuYWxseS4uIj8NCg0KW0dTXSBJIHRoaW5rICJNQVkgb25seSBiZSB1c2VkIGludGVybmFsbHki IGlzIHBlcmhhcHMgc3RhdGluZyB0b28gbXVjaCAoZGVwZW5kaW5nIG9uIGV4YWN0IG1lYW5pbmcg b2YgaW50ZXJuYWxseSkuIFdlIGFscmVhZHkgc3RhdGUgdGhhdCB0aGUgc3VjY2VzcyBjb2RlIE1V U1QgTk9UIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgRURIT0MgbWVzc2FnZSBmbG93LiBJJ20gbm90 IHN1cmUgd2Ugc2hvdWxkIGJlIG1vcmUgYmUgZXhwbGljaXQgYWJvdXQgaG93IHN1Y2Nlc3MgY29k ZXMgYXJlIHVzZWQuIFdoZXRoZXIgdGhlIHN1Y2Nlc3MgY29kZSB3b3VsZCBzb21laG93IGJlIGV4 cG9zZWQgdGhyb3VnaCBhbiBhcHBsaWNhdGlvbiBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIHByb3Rv Y29sIElNSE8uIFNvIEkga2VwdCAiTUFZIGJlIHVzZWQgaW50ZXJuYWxseSIgd2hpY2ggd2Ugc2Vl bSB0byBhZ3JlZSBhYm91dCBhbHRob3VnaCBpdCBpcyBub3QgYSBjb21wbGV0ZSBjaGFyYWN0ZXJp emF0aW9uIG9mIHRoZSBwb3RlbnRpYWwgdXNlIG9mIHN1Y2Nlc3MgY29kZXMuDQoNCg0KIkVSUl9J TkZPIGNhbiBjb250YWluIGFueSB0eXBlIG9mIENCT1IgaXRlbSIsIHNlZSBmaWd1cmUgNy4gV2hv IGRlY2lkZXMgd2hhdCBpcyB0aGUgdHlwZSBvZiB0aGUgQ0JPUiBpdGVtPyBJcyB0aGlzIHRoZSBF REhPQyBpbXBsZW1lbnRhdGlvbiBkZXZlbG9wZXI/DQoNCltHU10gVGhpcyBpcyBpbnRlbnRpb25h bGx5IGxlZnQgb3Blbi4gUmV0dXJuaW5nIHRvIHRoZSBleGFtcGxlIHdoaWNoIG1vdGl2YXRlZCB0 aGUgZGVmaW5pdGlvbiBvZiBhIHN1Y2Nlc3MgY29kZSwgdGhlIHVzZSBvZiBFUlJfSU5GTyBpbiBh IHN1Y2Nlc3NmdWwgc3RhdHVzIHJlcG9ydCBhbGxvd3MgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBy ZWxldmFudCB0byB0aGUgYXBwbGljYXRpb24gdG8gY29tcGxlbWVudCB0aGUgaW5mb3JtYXRpb24g dGhhdCB0aGlzIGlzIHQgIm5vIGVycm9yIi4gVGhpcyBtYXkgYmUgYSBmZWF0dXJlIG9mIGEgcGFy dGljdWxhciBFREhPQyBpbXBsZW1lbnRhdGlvbiwgYW4gaW5mb3JtYXRpb24gZWxlbWVudCByZXF1 aXJlZCBieSBhIHBhcnRpY3VsYXIgYXBwbGljYXRpb24sIGV0Yy4gYnV0IHdoYXQgQ0JPUiB0eXBl IGlzIHVzZWQgaXMgbm90IGRpcmVjdGx5IGltcGFjdGluZyB0aGUgcHJvdG9jb2wgYW5kIHRoZXJl Zm9yZSBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBzcGVjaWZpY2F0aW9uLiBJIGFkZGVkIHRoZSBs YXR0ZXIgdG8gdGhlIHRleHQgaW4gUFIgIzIwMC4NCg0KDQoNCjcgTWFuZGF0b3J5LXRvLUltcGxl bWVudCBDb21wbGlhbmNlIFJlcXVpcmVtZW50cw0KIkNvbnN0cmFpbmVkIGVuZHBvaW50cyBTSE9V TEQgaW1wbGVtZW50IGNpcGhlciBzdWl0ZSAwIG9yIGNpcGhlciBzdWl0ZSAyLiINClRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gMCBhbmQgMSBhbmQgYmV0d2VlbiAyIGFuZCAzIGlzIG9ubHkgdGhlIHNp emUgb2YgdGhlIHRhZywgaS5lLiB0aGUgdXNlZCBhbGdvcml0aG1zIGFyZSB0aGUgc2FtZS4gLT4g SSB3aWxsIHN1Z2dlc3QgY2hhbmdpbmcgdG8gIi4uLnN1aXRlIDAvMSBvciBjaXBoZXIgc3VpdGUg Mi8zIiBvciBzaW1pbGFyLg0KDQpbR1NdIEdvb2QgcG9pbnQsIEkgbWFkZSBhIHNlcGFyYXRlIGlz c3VlICMyMDkuIEEgcHJvcG9zZWQgdGV4dCBpcyBpbmNsdWRlZCBpbiBQUiAjMjAwLg0KDQpFcnJv ciBtZXNzYWdlcyB3aXRoIHdoaWNoIGVycm9yIGNvZGVzIGFyZSBtYW5kYXRvcnkgdG8gaW1wbGVt ZW50PyBJcyBvbmx5IGFuIGVycm9yIG1lc3NhZ2Ugd2l0aCBFUlJfQ09ERSAyIG1hbmRhdG9yeSB0 byBpbXBsZW1lbnQ/DQoNCltHU10gU2VjdGlvbiA3IG9mIHZlcnNpb24gLTEyIGFjdHVhbGx5IHNh eXM6DQoiRXJyb3IgY29kZXMgMSBhbmQgMiBNVVNUIGJlIHN1cHBvcnRlZC4iDQpJIGFkZGVkICJF UlJfQ09ERSIgdG8gdGhlIHNlbnRlbmNlIGluIFBSICMyMDAgZm9yIGVhc3kgc2VhcmNoLg0KDQoN Cg0KOC43IEltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb24NCiJUaGUgc2VsZWN0aW9uIG9mIHRy dXN0ZWQgQ0FzIHNob3VsZCBiZSBkb25lIHZlcnkgY2FyZWZ1bGx5IGFuZCBjZXJ0aWZpY2F0ZSBy ZXZvY2F0aW9uIHNob3VsZCBiZSBzdXBwb3J0ZWQuIg0KDQpJcyBPQ1NQIChSRkM2OTYwKSB3aGF0 IHNob3VsZCBiZSB1c2VkIGZvciBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGNoZWNraW5nPw0KDQpb R1NdIFJldm9jYXRpb24gaXMgc3BlY2lmaWVkIGluIHNlcGFyYXRlIFJGQ3MgZGVwZW5kaW5nIG9u IGNlcnRpZmljYXRlIGZvcm1hdCwgc28gdGhhdCBpcyBvbmUgZXhhbXBsZS4NCg0KSG93IHJldm9j YXRpb24gY2FuIGJlIGFjY29tcGxpc2hlZCB3aXRoIEM1MDk/DQoNCltHU10gQzUwOSBoYXMgZGVm aW5lZCBDUkxzIGJ1dCBub3QgeWV0IGVuY29kaW5nIG9mIE9TQ1AuIFRoZSB0b3BpYyB3YXMgYnJv dWdodCB1cCBhdCB0aGUgQ09TRSBXRyBtZWV0aW5nIElFVEYgMTEyLCBidXQgbm8gZGV0YWlscyBh cmUgcHJvdmlkZWQgeWV0Lg0KDQpIb3cgT0NTUCBhbmQgRURIT0MgaW50ZXJhY3Q/IENhbiBPQ1NQ IHN0YXBsaW5nIGJlIHVzZWQgd2l0aCBFREhPQz8gQ2FuIHdlIGNvbWJpbmUgT0NTUCBzdGFwbGlu ZyB3aXRoIEVBRD8NCg0KW0dTXSBBcyBtZW50aW9uZWQsIHRoZSB1c2Ugb2YgT0NTUCB3aXRoIENP U0UgaXMgbm90IGRlZmluZWQgeWV0LiBPbmNlIGRlZmluaXRpb24gaXQgc2hvdWxkIGFsc28gaW5j bHVkZSBDT1NFIGhlYWRlciBwYXJhbWV0ZXIgd2hpY2ggdGhlbiBjYW4gYmUgdXNlZCBmb3IgdHJh bnNwb3J0IGluIElEX0NSRURfeCBpbiBFREhPQywgb3IgYWx0ZXJuYXRpdmVseSB3aXRoIEVBRC4g VGhpcyBjYW4gYmUgZGVmaW5lZCBzZXBhcmF0ZWx5Lg0KDQpBZGRpdGlvbmFsbHksIHRvIHZlcmlm eSBhIGNlcnRpZmljYXRlIHRoZSBkZXZpY2Ugc2hvdWxkIGJlIGF3YXJlIG9mIHRoZSB0aW1lLCB3 aGljaCBpcyBvZnRlbiBwcm9ibGVtYXRpYyBvbiBjb25zdHJhaW5lZCBkZXZpY2VzLCBpLmUuIHdo ZW4gY2VydGlmaWNhdGVzIGFyZSB1c2VkIHRoZSBkZXZpY2UgbXVzdCBoYXZlIGEgUmVhbC1UaW1l IENsb2NrIChSVEMpLg0KDQpbR1NdIEdvb2QgcG9pbnQuIFZlcmlmaWNhdGlvbiBvZiB2YWxpZGl0 eSBtYXkgcmVxdWlyZSB0aGUgdXNlIG9mIGEgUmVhbC1UaW1lIENsb2NrIChSVEMpLCBidXQgYXMg ZmFyIGFzIEkgdW5kZXJzdGFuZCwgT0NTUCBzdGFwbGluZyBkb2VzIG5vdC4gSSBhZGRlZCBhIHNl bnRlbmNlIGluIFBSICMyMDAuDQoNCg0KVGhhbmtzDQpHw7ZyYW4NCg0KDQotLQ0KDQpTdGVmYW4g SHJpc3Rvem92DQpEZXBhcnRtZW50IEhhcmR3YXJlIFNlY3VyaXR5DQpGcmF1bmhvZmVyIEluc3Rp dHV0ZSBmb3IgQXBwbGllZCBhbmQgSW50ZWdyYXRlZCBTZWN1cml0eSBBSVNFQw0KTGljaHRlbmJl cmdzdHJhw59lIDExLCA4NTc0OCBHYXJjaGluZyBuZWFyIE11bmljaCwgR2VybWFueQ0KVGVsLiAr NDkgODkgMzIyOTkgODYgMTU3DQpzdGVmYW4uaHJpc3Rvem92QGFpc2VjLmZyYXVuaG9mZXIuZGU8 bWFpbHRvOnN0ZWZhbi5ocmlzdG96b3ZAYWlzZWMuZnJhdW5ob2Zlci5kZT4NCmh0dHBzOi8vd3d3 LmFpc2VjLmZyYXVuaG9mZXIuZGUvDQo= --_000_ea2d4c1520f401e99d62110bb0f81d40d36ff974camelaisecfraun_ Content-Type: text/html; charset="utf-8" Content-ID: <83B2D1797872804AA6FDCFDDAC1C3203@EURP194.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIHN0eWxlPSJkaXNwbGF5Om5vbmU7Ij4gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206 MDt9IDwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciIgc3R5bGU9InRleHQtYWxpZ246 bGVmdDsgZGlyZWN0aW9uOmx0cjsiIGJnY29sb3I9IiNmZmZmZmYiIHRleHQ9IiMzZDNkM2QiIGxp bms9IiM1MzUzNTMiIHZsaW5rPSIjM2QzZDNkIj4NCjxkaXY+SGkgR8O2cmFuLDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+dGhhbmtzIGZvciBhZGRyZXNzaW5nIG15IGNvbW1lbnRzITwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SXQgbG9va3MgZ29vZCB0byBtZS4gSSB3b3Vs ZCBsaWtlIHRvIHN1Z2dlc3Qgb25seSB0byBhZGQgdGhlIHJlbGV2YW50IFJGQyByZWZlcmVuY2Vz IHJlZ2FyZGluZyByZXZvY2F0aW9uIGluIHRoZSBzZWN0aW9uICZxdW90O0ltcGxlbWVudGF0aW9u IGNvbnNpZGVyYXRpb24mcXVvdDsuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZXN0 IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2PlN0ZWZhbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PbiBNb24sIDIwMjEtMTItMTMgYXQg MTQ6NTcgKzAwMDAsIEfDtnJhbiBTZWxhbmRlciB3cm90ZTo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6MnB4ICM3Mjlm Y2Ygc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIFN0ZWZhbiwgPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlRoYW5rcyBmb3IgdGhlIHJldmlldy4gSXQgaXMgcmVjb3JkZWQgYXMgZ2l0aHViIGlzc3Vl ICMxOTQgYW5kIGEgcHJvcG9zZWQgdXBkYXRlIHRvIHRoZSBkcmFmdCBpcyBpbiBQUiAjMjAwLjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Db21tZW50cyBpbmxpbmUuIFBsZWFzZSBsZXQgdXMga25v dyBpZiB5b3UgaGF2ZSBmdXJ0aGVyIGNvbW1lbnRzIG9yIGlmIGl0IGlzIE9LIHRvIG1lcmdlICMy MDAgYW5kIGNsb3NlICMxOTQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7IGJvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7bWFyZ2luLWJvdHRvbTox Mi4wcHQiPg0KPGEgbmFtZT0iX01haWxPcmlnaW5hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PC9hPjxzcGFuIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+TGFrZSAmbHQ7 bGFrZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSHJpc3Rvem92LCBTdGVmYW4g Jmx0O3N0ZWZhbi5ocmlzdG96b3ZAYWlzZWMuZnJhdW5ob2Zlci5kZSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VGh1cnNkYXksIDQgTm92ZW1iZXIgMjAyMSBhdCAxMjo0Mzxicj4NCjxiPlRvOiA8L2I+ bGFrZUBpZXRmLm9yZyAmbHQ7bGFrZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ W0xha2VdIFJldmlldyBFREhPQy12MTI8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj5IaSBhbGwsPC9zcGFuPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+cGxlYXNlIGZpbmQgYmVsb3cgbXkgcmV2 aWV3IG9mPHNwYW4gY2xhc3M9ImgxIj4gZHJhZnQtaWV0Zi1sYWtlLWVkaG9jLTEyLjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj5CZXN0IHJlZ2FyZHMsPC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 OyBjb2xvcjpibGFjayI+U3RlZmFuPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Mi4gT3V0bGluZSA8L3NwYW4+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0 eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+JnF1b3Q7 SURfQ1JFRF9JIGFuZCBJRF9DUkVEX1IgYXJlIGNyZWRlbnRpYWwgaWRlbnRpZmllcnMgZW5hYmxp bmcgdGhlIHJlY2lwaWVudCBwYXJ0eSB0byByZXRyaWV2ZSB0aGUgY3JlZGVudGlhbCBvZiBJIGFu ZCBSLCByZXNwZWN0aXZlbHkuJnF1b3Q7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+SSB3aWxsIHJlcGxhY2Ug dGhpcyBkZWZpbml0aW9uIHdpdGggc29tZXRoaW5nIGxpa2U6DQo8L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsg Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNw YW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj5J RF9DUkVEX0kgYW5kIElEX0NSRURfUiBhcmUgdXNlZCB0byBpZGVudGlmeSBhbmQgb3B0aW9uYWxs eSB0cmFuc3BvcnQgdGhlIGF1dGhlbnRpY2F0aW9uIGtleXMgb2YgdGhlIEluaXRpYXRvciBhbmQg dGhlIFJlc3BvbmRlciwgcmVzcGVjdGl2ZWx5Lg0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+W0dTXSBEb25lIGluIDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQpQ UiAjMjAwLjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsg Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNw YW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4z LjggRUFEPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0OyBjb2xvcjpibGFjayI+SXMgRUFEIGRhdGEgZ2VuZXJhdGVkIGJ5IHRoZSBhcHBs aWNhdGlvbiBvciBkYXRhIHRoYXQgaXMgcHJlLXByb3Zpc2lvbmVkIG9yIG9idGFpbmVkIGZyb20g c29tZXdoZXJlLiBJZiB0aGUgZm9ybWVyIGlzIHRydWUgSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3Qg dGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBhbGxvd3MgZm9yIGltcGxlbWVudGF0aW9ucyB3aGVyZQ0K IGFsbCBpbnB1dHMgYW5kIG91dHB1dCB0aGF0IGFyZSBnZW5lcmF0ZWQgYXQgcnVuIHRpbWUgYnkg dGhlIGFwcGxpY2F0aW9uIGFyZSBwcm92aWRlZCBpbiBub24tZW5jb2RlZCBmb3JtIHRvIHRoZSBF REhPQyBpbXBsZW1lbnRhdGlvbi4gSW4gdGhpcyB3YXksIHRoZSBpbnRlcmZhY2UgdG8gdGhlIGFw cGxpY2F0aW9uIHdpbGwgYmUgc2ltcGxlciBhbmQgQ0JPUiBlbmNvZGluZyBhbmQgZGVjb2Rpbmcg Y2FuIGJlIGNvbXBsZXRlbHkgaGlkZGVuIGZyb20NCiB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVy LiBUaGlzIGFwcGxpZXMgZXNwZWNpYWxseSBmb3IgRUFELCBzZWUgaXNzdWUgIzE4Ni4gVGhlIGdl bmVyYWwgcXVlc3Rpb24gaXMgd2hvIGlzIHN1cHBvc2VkIHRvIGVuY29kZS9kZWNvZGUgRUFEPyBU aGUgYXBwbGljYXRpb24gb3IgdGhlIEVESE9DIGltcGxlbWVudGF0aW9uPyBBcyBmYXIgSSB1bmRl cnN0YW5kIHRoZSBzcGVjaWZpY2F0aW9uIG5vdyBvbmx5IHRoZSBhcHBsaWNhdGlvbiBrbm93cyBo b3cNCiB0byBlbmNvZGUgYW5kIGRlY29kZSBFQUQuPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+W0dTXSBDb3JyZWN0LCB0aGUgYXBwbGljYXRpb24gZW5jb2Rlcy9kZWNv ZGVzIEVBRC4gSG93ZXZlciwgZm9yIGNlcnRhaW4gRUFEIHVzZSBjYXNlcyBpdCBtYXkgYmUgbW9z dCBhcHByb3ByaWF0ZSB0byBpbXBsZW1lbnQgcGFydCBvZiB0aGUgYXBwbGljYXRpb24gYW5kIEVE SE9DIHRvZ2V0aGVyLiBXZSB3aWxsIGFkZCBhbiBhcHBlbmRpeCB3aGljaA0KIHByb3ZpZGVzIHNv bWUgZXhhbXBsZXMgb2YgdGhpcywgbmV3IGlzc3VlICMyMTAuIEdvb2QgcG9pbnQgYWJvdXQgaW5w dXQgYW5kIG91dHB1dCBpbiBub24tZW5jb2RlZCBmb3JtLCB0aGF0IHNob3VsZCBhbHNvIGJlIGlu Y2x1ZGVkIGluIHRob3NlIGV4YW1wbGVzLiBBUElzIGFyZSBsZWZ0IG91dCBvZiBzY29wZSwgYnV0 IGl0IG1ha2VzIHNlbnNlIHRoYXQgRURIT0MgaW1wbGVtZW50YXRpb24gQ0JPUiBlbmNvZGVzIHRo ZSBub24tZW5jb2RlZCBpbmZvcm1hdGlvbi48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+NS4yLjE8L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsg Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNw YW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4m cXVvdDtJZiB0aGUgbW9zdCBwcmVmZXJyZWQgY2lwaGVyIHN1aXRlIGlzIHNlbGVjdGVkIHRoZW4g U1VJVEVTX0kgaXMgZW5jb2RlZCBhcyB0aGF0IGNpcGhlciBzdWl0ZSwgaS5lLiwgYXMgYW4gaW50 LiZxdW90Ow0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+QW0gSSB1bmRlcnN0YW5kaW5nIHRoYXQgY29ycmVj dGx5OiBJZiBvdGhlciBzdWl0ZXMgYXJlIHN1cHBvcnRlZCBpbiBhZGRpdGlvbiB0aGV5IGFyZSBu b3Qgc2VudCwgZS5nLiwgaWYgdGhlIGluaXRpYXRvciBzdXBwb3J0cyBzdWl0ZXMgMSwyLDMsIHdo ZXJlIDEgaXMgcHJlZmVycmVkIGFuZCBzZWxlY3RlZCwgMSBpcyBzZW50IGFzIGludCBhbmQNCiAy LDMgYXJlIG5vdCBzZW50PyBJZiBzbyBJIHdpbGwgc3VnZ2VzdCBtYWtpbmcgdGhpcyBzZW50ZW5j ZSBtb3JlIGNsZWFyLjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3Bh biBzdHlsZT0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPltH U10gWWVzLCB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4gU2luY2UgdGhlIHByb2NlZHVy ZSBwcmVzY3JpYmVzIG9ubHkgc2VuZGluZyB0aGUgY2lwaGVyIHN1aXRlIHdoaWNoIGlzIHNlbGVj dGVkIGFuZCBtb3JlIHByZWZlcnJlZCBzdXBwb3J0ZWQgY2lwaGVyIHN1aXRlcywgaWYgdGhlIHNl bGVjdGVkIGlzIHRoZSBtb3N0IHByZWZlcnJlZA0KIHRoZW4gb25seSB0aGF0IGNpcGhlciBzdWl0 ZSBpcyBzZW50LiBJIHRyaWVkIHRvIGNsYXJpZnkgdGhlIHNlbnRlbmNlIGZ1cnRoZXIsIHNlZSBQ UiMyMDAuPC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 OyBjb2xvcjpibGFjayI+NiBFcnJvciBIYW5kbGluZzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+V2hhdCBpcyB0aGUgdXNl IGNhc2UgZm9yIGEgc3VjY2VzcyBlcnJvciBjb2RlPyBQcm9iYWJseSBpdCBpcyBnb29kIHRvIGdp dmUgc29tZSBleGFtcGxlIG9yIHJlZmVyZW5jZSB3aHkgaXQgaXMgdXNlZnVsIHRvIGxvZyBzdWNj ZXNzZXMgdXNpbmcgYSBwcmVkZWZpbmVkIGVycm9yIGNvZGUgYW5kIGVuY29kaW5nLiBJcyBsb2dn aW5nIHRoZSBvbmx5DQogdXNlIGNhc2UgZm9yIHRoZSBzdWNjZXNzIGVycm9yIGNvZGU/IEZvciBl eGFtcGxlLCBteSBpbXBsZW1lbnRhdGlvbiBsb2dzIG1hbnkgdGhpbmdzIGZvciBkZWJ1Z2dpbmcg cHVycG9zZXMuIEhvd2V2ZXIsIEkgbmV2ZXIgbmVlZGVkIGEgc3VjY2VzcyBlcnJvciBjb2RlLg0K PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw Y207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsg Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNw YW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5b R1NdIDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5UaGUgZXJyb3IgY29kZSBmb3Igc3VjY2VzcyBjYW1lIGFib3V0 IGZyb20gYSBtYWlsIGV4Y2hhbmdlIG9uIHRoZSBJT1RPUFMgV0cgbWFpbGluZyBsaXN0IFsxXTo8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0OyBmb250LWZhbWlseTomcXVvdDt2YXIoLS1i cy1mb250LW1vbm9zcGFjZSkmcXVvdDssc2VyaWY7IGNvbG9yOiMyMTI1MjkiPiZxdW90Ozwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7dmFyKC0tYnMtZm9udC1tb25vc3BhY2UpJnF1b3Q7LHNlcmlmOyBjb2xv cjojMjEyNTI5Ij4yLg0KIHJlc2VydmUgb25lIG9mIHRoZSBzdGF0dXMgY29kZXMgZm9yIHN1Y2Nl c3MsIHNvIHRoYXQgdGhlIHN0YXR1cyByZXBvcnRpbmcgY2FuIGFsc28gdXNlIHRoZSBzdGFuZGFy ZCB2YWx1ZSBpbiBjYXNlIG9mIG5vIGVycm9yPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDsgZm9udC1mYW1pbHk6JnF1 b3Q7dmFyKC0tYnMtZm9udC1tb25vc3BhY2UpJnF1b3Q7LHNlcmlmOyBjb2xvcjojMjEyNTI5Ij4m cXVvdDsuDQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBhZGRlZCB0aGlzIGV4cGxhbmF0aW9uIHRvIHRoZSB0 ZXh0IGluDQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPlBSICMyMDA8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Ljwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bMV0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9pb3RvcHMvdDlMVHBNaVpfX2tGR1pwY2VMQ0JhQ1VITjQ0Lzwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3Bh biBzdHlsZT0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj5UaGUgc3BlYyBzYXlzIHRoYXQg c3VjY2VzcyBlcnJvciBjb2RlIG11c3Qgbm90IGJlIHNlbnQsIHRoZXJlZm9yZSB0aGUgc2VudGVu Y2UgJnF1b3Q7RXJyb3IgY29kZSAwIE1BWSBiZSB1c2VkIGludGVybmFsbHkuLiZxdW90OyBuZWVk cyB0byBiZSAmcXVvdDtFcnJvciBjb2RlIDAgTUFZIGJlIHVzZWQgX29ubHlfIGludGVybmFsbHku LiZxdW90Oz8NCjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+W0dTXSBJIHRoaW5rICZxdW90O01BWSBvbmx5IGJlIHVz ZWQgaW50ZXJuYWxseSZxdW90OyBpcyBwZXJoYXBzIHN0YXRpbmcgdG9vIG11Y2ggKGRlcGVuZGlu ZyBvbiBleGFjdCBtZWFuaW5nIG9mIGludGVybmFsbHkpLiBXZSBhbHJlYWR5IHN0YXRlIHRoYXQg dGhlIHN1Y2Nlc3MgY29kZSBNVVNUIE5PVCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlIEVESE9DIG1l c3NhZ2UNCiBmbG93LiBJJ20gbm90IHN1cmUgd2Ugc2hvdWxkIGJlIG1vcmUgYmUgZXhwbGljaXQg YWJvdXQgaG93IHN1Y2Nlc3MgY29kZXMgYXJlIHVzZWQuIFdoZXRoZXIgdGhlIHN1Y2Nlc3MgY29k ZSB3b3VsZCBzb21laG93IGJlIGV4cG9zZWQgdGhyb3VnaCBhbiBhcHBsaWNhdGlvbiBpcyBvdXQg b2Ygc2NvcGUgb2YgdGhlIHByb3RvY29sIElNSE8uIFNvIEkga2VwdCAmcXVvdDtNQVkgYmUgdXNl ZCBpbnRlcm5hbGx5JnF1b3Q7IHdoaWNoIHdlIHNlZW0gdG8gYWdyZWUgYWJvdXQNCiBhbHRob3Vn aCBpdCBpcyBub3QgYSBjb21wbGV0ZSBjaGFyYWN0ZXJpemF0aW9uIG9mIHRoZSBwb3RlbnRpYWwg dXNlIG9mIHN1Y2Nlc3MgY29kZXMuPC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPiZxdW90O0VSUl9JTkZPIGNhbiBjb250YWlu IGFueSB0eXBlIG9mIENCT1IgaXRlbSZxdW90Oywgc2VlIGZpZ3VyZSA3LiBXaG8gZGVjaWRlcyB3 aGF0IGlzIHRoZSB0eXBlIG9mIHRoZSBDQk9SIGl0ZW0/IElzIHRoaXMgdGhlIEVESE9DIGltcGxl bWVudGF0aW9uIGRldmVsb3Blcj8NCjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyI+DQo8c3BhbiBzdHlsZT0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPltHU10gVGhpcyBpcyBpbnRlbnRpb25hbGx5IGxlZnQgb3Blbi4gUmV0dXJuaW5nIHRv IHRoZSBleGFtcGxlIHdoaWNoIG1vdGl2YXRlZCB0aGUgZGVmaW5pdGlvbiBvZiBhIHN1Y2Nlc3Mg Y29kZSwgdGhlIHVzZSBvZiBFUlJfSU5GTyBpbiBhIHN1Y2Nlc3NmdWwgc3RhdHVzIHJlcG9ydCBh bGxvd3MgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiByZWxldmFudA0KIHRvIHRoZSBhcHBsaWNhdGlv biB0byBjb21wbGVtZW50IHRoZSBpbmZvcm1hdGlvbiB0aGF0IHRoaXMgaXMgdCAmcXVvdDtubyBl cnJvciZxdW90Oy4gVGhpcyBtYXkgYmUgYSBmZWF0dXJlIG9mIGEgcGFydGljdWxhciBFREhPQyBp bXBsZW1lbnRhdGlvbiwgYW4gaW5mb3JtYXRpb24gZWxlbWVudCByZXF1aXJlZCBieSBhIHBhcnRp Y3VsYXIgYXBwbGljYXRpb24sIGV0Yy4gYnV0IHdoYXQgQ0JPUiB0eXBlIGlzIHVzZWQgaXMgbm90 IGRpcmVjdGx5IGltcGFjdGluZyB0aGUNCiBwcm90b2NvbCBhbmQgdGhlcmVmb3JlIGlzIG91dCBv ZiBzY29wZSBmb3IgdGhlIHNwZWNpZmljYXRpb24uIEkgYWRkZWQgdGhlIGxhdHRlciB0byB0aGUg dGV4dCBpbg0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj5QUiAjMjAwPC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPi48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9y OmJsYWNrIj43IE1hbmRhdG9yeS10by1JbXBsZW1lbnQgQ29tcGxpYW5jZSBSZXF1aXJlbWVudHM8 L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7IGNvbG9yOmJsYWNrIj4mcXVvdDtDb25zdHJhaW5lZCBlbmRwb2ludHMgU0hPVUxEIGltcGxl bWVudCBjaXBoZXIgc3VpdGUgMCBvciBjaXBoZXIgc3VpdGUgMi4mcXVvdDs8L3NwYW4+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi Pg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJs YWNrIj5UaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDAgYW5kIDEgYW5kIGJldHdlZW4gMiBhbmQgMyBp cyBvbmx5IHRoZSBzaXplIG9mIHRoZSB0YWcsIGkuZS4gdGhlIHVzZWQgYWxnb3JpdGhtcyBhcmUg dGhlIHNhbWUuIC0mZ3Q7IEkgd2lsbCBzdWdnZXN0IGNoYW5naW5nIHRvICZxdW90Oy4uLnN1aXRl IDAvMSBvciBjaXBoZXIgc3VpdGUgMi8zJnF1b3Q7IG9yIHNpbWlsYXIuICZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPltHU10gR29vZCBwb2ludCwgSSBtYWRl IGEgc2VwYXJhdGUgaXNzdWUgIzIwOS4gQSBwcm9wb3NlZCB0ZXh0IGlzIGluY2x1ZGVkIGluIFBS ICMyMDAuPC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0i Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPkVycm9yIG1lc3Nh Z2VzIHdpdGggd2hpY2ggZXJyb3IgY29kZXMgYXJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQ/IElz IG9ubHkgYW4gZXJyb3IgbWVzc2FnZSB3aXRoIEVSUl9DT0RFIDIgbWFuZGF0b3J5IHRvIGltcGxl bWVudD8gJm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFu IHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29s b3I6YmxhY2siPltHU10gU2VjdGlvbiA3IG9mIHZlcnNpb24gLTEyIGFjdHVhbGx5IHNheXM6DQo8 L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBj bTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0K PHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkVycm9yIGNv ZGVzIDEgYW5kIDIgTVVTVCBiZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5zdXBwb3J0ZWQuPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVv dDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPkkgYWRkZWQgJnF1b3Q7RVJS X0NPREUmcXVvdDsgdG8gdGhlIHNlbnRlbmNlIGluIFBSICMyMDAgZm9yIGVhc3kgc2VhcmNoLjwv c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNt OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8 c3BhbiBzdHlsZT0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw Y207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBj b2xvcjpibGFjayI+OC43IEltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRpb248L3NwYW4+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4mcXVvdDtUaGUg c2VsZWN0aW9uIG9mIHRydXN0ZWQgQ0FzIHNob3VsZCBiZSBkb25lIHZlcnkgY2FyZWZ1bGx5IGFu ZCBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIHNob3VsZCBiZSBzdXBwb3J0ZWQuJnF1b3Q7DQo8L3Nw YW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsg Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNw YW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9y OmJsYWNrIj5JcyBPQ1NQIChSRkM2OTYwKSB3aGF0IHNob3VsZCBiZSB1c2VkIGZvciBjZXJ0aWZp Y2F0ZSByZXZvY2F0aW9uIGNoZWNraW5nPw0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPltHU10g UmV2b2NhdGlvbiBpcyBzcGVjaWZpZWQgaW4gc2VwYXJhdGUgUkZDcyBkZXBlbmRpbmcgb24gY2Vy dGlmaWNhdGUgZm9ybWF0LCBzbyB0aGF0IGlzIG9uZSBleGFtcGxlLg0KPC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFu IHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+SG93 IHJldm9jYXRpb24gY2FuIGJlIGFjY29tcGxpc2hlZCB3aXRoIEM1MDk/DQo8L3NwYW4+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gc3R5bGU9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsg Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNw YW4gc3R5bGU9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBj b2xvcjpibGFjayI+W0dTXSBDNTA5IGhhcyBkZWZpbmVkIENSTHMgYnV0IG5vdCB5ZXQgZW5jb2Rp bmcgb2YgT1NDUC4gVGhlIHRvcGljIHdhcyBicm91Z2h0IHVwIGF0IHRoZSBDT1NFIFdHIG1lZXRp bmcgSUVURiAxMTIsIGJ1dCBubyBkZXRhaWxzIGFyZSBwcm92aWRlZCB5ZXQuPC9zcGFuPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207 IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxz cGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+ SG93IE9DU1AgYW5kIEVESE9DIGludGVyYWN0PyBDYW4gT0NTUCBzdGFwbGluZyBiZSB1c2VkIHdp dGggRURIT0M/IENhbiB3ZSBjb21iaW5lIE9DU1Agc3RhcGxpbmcgd2l0aCBFQUQ/PC9zcGFuPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0 eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw Y207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDsgY29sb3I6YmxhY2siPltHU10gQXMgbWVudGlvbmVkLCB0aGUgdXNlIG9mIE9DU1Agd2l0aCBD T1NFIGlzIG5vdCBkZWZpbmVkIHlldC4gT25jZSBkZWZpbml0aW9uIGl0IHNob3VsZCBhbHNvIGlu Y2x1ZGUgQ09TRSBoZWFkZXIgcGFyYW1ldGVyIHdoaWNoIHRoZW4gY2FuIGJlIHVzZWQgZm9yIHRy YW5zcG9ydCBpbiBJRF9DUkVEX3ggaW4gRURIT0MsDQogb3IgYWx0ZXJuYXRpdmVseSB3aXRoIEVB RC4gVGhpcyBjYW4gYmUgZGVmaW5lZCBzZXBhcmF0ZWx5Ljwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyI+DQo8c3BhbiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29s b3I6YmxhY2siPkFkZGl0aW9uYWxseSwgdG8gdmVyaWZ5IGEgY2VydGlmaWNhdGUgdGhlIGRldmlj ZSBzaG91bGQgYmUgYXdhcmUgb2YgdGhlIHRpbWUsIHdoaWNoIGlzIG9mdGVuIHByb2JsZW1hdGlj IG9uIGNvbnN0cmFpbmVkIGRldmljZXMsIGkuZS4gd2hlbiBjZXJ0aWZpY2F0ZXMgYXJlIHVzZWQg dGhlIGRldmljZSBtdXN0IGhhdmUgYSBSZWFsLVRpbWUgQ2xvY2sNCiAoUlRDKS48L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPHNwYW4gc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPltHU10g R29vZCBwb2ludC4gVmVyaWZpY2F0aW9uIG9mIHZhbGlkaXR5IG1heSByZXF1aXJlIHRoZSB1c2Ug b2YgYSBSZWFsLVRpbWUgQ2xvY2sgKFJUQyksIGJ1dCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCBP Q1NQIHN0YXBsaW5nIGRvZXMgbm90LiBJIGFkZGVkIGEgc2VudGVuY2UgaW4gUFIgIzIwMC48L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0OyBj b2xvcjpibGFjayI+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwY207IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxlPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtOyBmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iIj48L3NwYW4+DQo8ZGl2IGlkPSJTaWduYXR1cmUi Pg0KPGRpdj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0OyBjb2xvcjpibGFjayI+VGhhbmtzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0OyBjb2xvcjpibGFjayI+R8O2cmFuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBjbTsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiPg0KPHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 OyBjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxzcGFuPg0KPHByZT4tLSA8YnI+ PC9wcmU+DQo8ZGl2IHN0eWxlPSJ3aWR0aDogNzFjaDsiPlN0ZWZhbiBIcmlzdG96b3Y8L2Rpdj4N CjxkaXYgc3R5bGU9IndpZHRoOiA3MWNoOyI+RGVwYXJ0bWVudCBIYXJkd2FyZSBTZWN1cml0eTwv ZGl2Pg0KPGRpdiBzdHlsZT0id2lkdGg6IDcxY2g7Ij5GcmF1bmhvZmVyIEluc3RpdHV0ZSBmb3Ig QXBwbGllZCBhbmQgSW50ZWdyYXRlZCBTZWN1cml0eSBBSVNFQzwvZGl2Pg0KPGRpdiBzdHlsZT0i d2lkdGg6IDcxY2g7Ij5MaWNodGVuYmVyZ3N0cmHDn2UgMTEsIDg1NzQ4IEdhcmNoaW5nIG5lYXIg TXVuaWNoLCBHZXJtYW55PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3aWR0aDogNzFjaDsiPlRlbC4gKzQ5 IDg5IDMyMjk5IDg2IDE1NzwvZGl2Pg0KPGRpdiBzdHlsZT0id2lkdGg6IDcxY2g7Ij48YSBocmVm PSJtYWlsdG86c3RlZmFuLmhyaXN0b3pvdkBhaXNlYy5mcmF1bmhvZmVyLmRlIj5zdGVmYW4uaHJp c3Rvem92QGFpc2VjLmZyYXVuaG9mZXIuZGU8L2E+PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3aWR0aDog NzFjaDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmFpc2VjLmZyYXVuaG9mZXIuZGUvIj5odHRwczov L3d3dy5haXNlYy5mcmF1bmhvZmVyLmRlLzwvYT48L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_ea2d4c1520f401e99d62110bb0f81d40d36ff974camelaisecfraun_-- From nobody Tue Dec 14 05:43:41 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D713A0781 for ; Tue, 14 Dec 2021 05:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_T_9N2Ed0Fj for ; Tue, 14 Dec 2021 05:43:32 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05lp2112.outbound.protection.outlook.com [104.47.18.112]) (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 98D8A3A0CAB for ; Tue, 14 Dec 2021 05:43:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mYGjm2a4AWsNwrrnX82KnNs78i1PP4WwVHeXNIT/LoO/Fai6NYrC4oGMq+MEvHVwIKhYw9ZOqZYBkDlQv+2JzwTdM4xzBRwgqw3BVt4YOSUcYuR+r6LLtMyn+hbl/Mh+yn/4mPfesvXaYL8XRUrljxs1uZITmViAY4hCXvDXKd2RNqh2PaZwHyUgP9y6mc9oapnkhhtWy2v4LWlptaBSEnigdLIcyfOWXV4Tubq8JcvS8WbPC/pusi5EA/7JmHSOC8H15sZROvOXh2ljBqHUcNsXivEEAvElDnkr31pOJI9JcUmoG5Qw9PoKmwIuqOo3ZC//JrSbvE6qAXezi4s2VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HyFx0NlGnYFiPdgUeCLoe2H3HYoamO2TQP8WBw6ZJrY=; b=cYXrKtvAf6yKzqYjh3pixlmn4m3RCgxHenfRRz9MS0/vMsOmN6UvtwqY368YnBaVUbJ3E9coxzVif5yK99cIo5w6rQKKUIrlyiO5Mc6emZP7eCErYDn8z+9XdoaCWzfJtCo9SVYDYrvj6TFGb7nmgD6kttsXoekIlNHbKfT9sVPEygjnMApOoIJ76RAS0oJ2jLEz7MH8wJbOyLvzrjvk/exK0eyKUh5W52D7cyLwd01OTZEQDGGl+yqxaHPIdRFK5zJzT9pyzDX2i8DYnoisp/iw7eFhmTaK2Y52wj495xaDov4mxsjSGZP4jCWbLPI/icfjhF1rYpGFMWW8/dU/XA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HyFx0NlGnYFiPdgUeCLoe2H3HYoamO2TQP8WBw6ZJrY=; b=dv/VNoOxhZ1tmxuM/taFMhe1ZVLSgWpUe1qRNKlCnNk4gq0jTzGVWe4bEOngj9SkjcF5BU00XWffLNwgK5P3E8vuKgyYsWRJPClzjyni1EzI3eAv1vbevxX5NjIXmPPc0ZmT4KdwGNIof43eNGC4dg4g4lkLYBE2xz78dUbzRkA= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM0PR07MB5540.eurprd07.prod.outlook.com (2603:10a6:208:ff::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.13; Tue, 14 Dec 2021 13:43:28 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4801.014; Tue, 14 Dec 2021 13:43:28 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Stephen Farrell , "lake@ietf.org" Thread-Topic: [Lake] review of edhoc-12 Thread-Index: AQHX1pSHud9VJIFTG0q8L0TEZX8U9qwnIA+q Date: Tue, 14 Dec 2021 13:43:28 +0000 Message-ID: References: <617ce86c-8b4f-84e2-8eec-ae388cf023cf@cs.tcd.ie> In-Reply-To: <617ce86c-8b4f-84e2-8eec-ae388cf023cf@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 0c5f1a08-3969-f99e-9b07-b3b17776bfd3 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1cb0f5e9-65bf-44bc-de79-08d9bf07b590 x-ms-traffictypediagnostic: AM0PR07MB5540:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KpoPQKEdb5tBJo2z70TFJPlqSdHZu3xzdcxr9aRQufAhZqFPMvomIxSRxV5TqgHLeEftLVyImn3II2ggxt2AbJlQJyuVbD5soqjaKSjsWPdu/HaHR0HAAH4ejUCw5f0z4DbwRgIdFvVWtGneXK3gxGdskQh8frSJ2zZc9FlWs+4bjgdKiwWXdubN4GqsPwTRMyZvTQ0uHW5wxZVeyfAro0rVpRSsY26HExLXJ8LBVkIS6MOFYTOaL+Ad8b9Wy3YRsvO0fHHkxK/SxlDs/oEcTcZRQOw/CSbucgJOEDYBzGp8tmfb/pacFoBpIoB/TaK8Fn+1yqKDVSKqGWO0d0nsewoDqRffth6O2cfud7Qu/t66U1xwsu4wp0Axbug1+DmGJ9Ycj6UbP6ZitQZBYc5gx1uqyMVI/4lbnio7mRT5eLbcu0/5/gn4/QiOSZlrEDJ58hWisBb7Tz9dYjOk4YLxHN/Fj5/pkMuSHC39vUEADrjYA0J/KQAziAANJcJPP6djoabRbouxHu7CNjQYJ8dEVJ/Tq5IXVzFTTb6iBTo/It06f0z167M7oqXBu15wU9UYVHFGrO216CJHd1/Q10a4EhNxOx1YGQS6MRMwgcqtvd3XULo+Vii9XGqqg8ZzOrrkTCf8inupHq4HHzmDO6Zcd/nbvo86EESRB8C5U0TPD1u8fdOO6NF9KOFTozsxZfthoqY3LvpWNBebLh4mT24wHGK+hkM5AuhSUS+wtmh3vIVKpVQ7Yx1kKWt/E4F9sX99P1BjPE30upboTa44qXQb9MQLdkjOSpBiETgvLkq3aB/grig+owhJpgBRcD8cCEHYRr1tuw0123hAEkRDJjga/g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(19627405001)(38070700005)(33656002)(38100700002)(122000001)(86362001)(110136005)(66574015)(83380400001)(166002)(26005)(186003)(71200400001)(5660300002)(55016003)(296002)(316002)(66946007)(9686003)(966005)(53546011)(508600001)(30864003)(66446008)(64756008)(76116006)(91956017)(52536014)(8936002)(8676002)(66556008)(66476007)(82960400001)(2906002)(6506007)(7696005)(579004)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Nf20l2Ygg3hbTWyN9jbYuZv1nLk6AC4ihseGgL+ZBWy+wBIIaSZ0EtmjtP?= =?iso-8859-1?Q?MFAN503QuYRWGAwkd2E+CUeAUDY0/lUvQuIOom+f9j9SqMrEuziEhkZwri?= =?iso-8859-1?Q?BdxQAt81ArL9aE9P0f+AXqbvuWEfmW+EcD93P2nj2MfYyqounG25VaTXe0?= =?iso-8859-1?Q?cKHg+JmQZVIS4yQP+PNXqcL1lUChR4lc8+voKP9F05Uh9p1WavZV7FOqD+?= =?iso-8859-1?Q?JwL6CgklDF4eOrvf7Kr5FAUPj5SqWqSB0+PHRD6lRnayO37RbFTpeKW2Vv?= =?iso-8859-1?Q?db0bTxpxSaf0vHyWiZNRPTCVtEnb7iYIq0+eMuR36QVPIyoMaEj4mYV3mi?= =?iso-8859-1?Q?+f1mL/h9STyVteJnqurbnuzk4mJCg8+RQQnRLb32gXQ4Kir5q7uejVlyad?= =?iso-8859-1?Q?E5xoUS7B7RrJRCWmjRUXXRPL1qMi09BN5eemYahVCchtuzsZdvpZgBCJxS?= =?iso-8859-1?Q?WRbhQF51qtkGcrmAX8oQ11Vir8vpE5RpiweE6ymXOky4u2puP2fakXRkYd?= =?iso-8859-1?Q?DJVPiuG0BsMAofzMfezA1iywba1kBIcmxw8wyQpb66JFfCTxoc+WZkFeEt?= =?iso-8859-1?Q?yDeHolNGdVehY3iCwxEgt/7IqwONHrjESL4LGwI8lrjZT2aNOXa3kcM9WY?= =?iso-8859-1?Q?BGfTPpowTfEW/STV2Tbb3yYGZnC1jPI0iaZVFt4Q1My525Tgia/nhNHKHR?= =?iso-8859-1?Q?RDJ/ATebMmzsxStdmiD/HzSPZXWF4Z8hwnRulpcNbOU/syi9RwGvjluuh3?= =?iso-8859-1?Q?f7jQFdS3cQOAnfbkkuRBPtKOPTPt7fDV+lPtYPu9td6tGEHBhPIXSjtH3G?= =?iso-8859-1?Q?0Squhxv5uUb3mLaYIzAB+GZHtUCloZyPnBLpPxLNWPOTJ8fuSABNN1Qq/1?= =?iso-8859-1?Q?J99DOh0WxVTteFuPmE/rS0mfp/Sk3xHHMdCJUFW+sK0X5QRMJ2AmF4fqfU?= =?iso-8859-1?Q?FsNTnPYgNczK+aJ0CXVZjucKwAEI19Q9zP/ZQSe7KcyjcAnAjeGi0tlTJp?= =?iso-8859-1?Q?ZNERxdp2QvQuiZecT8flXik3OQufiKEZy/r7pbpiTfVSled351RZt6ihf9?= =?iso-8859-1?Q?c0UdKjmFvaHDyg8ajZd4Zhn3YAJAPFMfJIEdLBWckrr1Yl6VSobaHh5jqQ?= =?iso-8859-1?Q?9hcy7nLqLXzjw1QXrrjIbjUBptYOGeDD3smhQVph5GKE49rr+1xJEofWcQ?= =?iso-8859-1?Q?82WUq6Qd5n4+1TScXoGmxPj13ZXNC3bv0boXGE+arXaUXVcwbOAdnk1Ecj?= =?iso-8859-1?Q?Gi6Syhpc059Fd5q0bdpFQIaXYuUp+KnrXo0GBuusz62KXMG4jyTBE3f0hu?= =?iso-8859-1?Q?xoSfskiENXZ96A/LHtZhBxlLjDzEfVanNSiUnAuOvzm/x0/ytqSPq5kTN5?= =?iso-8859-1?Q?QlaULQm8lmqviKR8kH+inCECnPJvBGVaBzwXN79wFaajaJxhL773d+AajY?= =?iso-8859-1?Q?4CaluwBz2p5qgXBYgM6b0AUkWYKwH15VZUJPgfIDkCUFpM+BsC+pVxZxAP?= =?iso-8859-1?Q?ww+JLnGcRgorQP7I9DIOyn8U2dvhXPyeotyImPiVlPHxQmUUYBaEJFaiba?= =?iso-8859-1?Q?72uEfWOAXiy78AO4cDwNueZQ5YGysgyuiJg1eS19ExYLqWYGtaqhAgIYQw?= =?iso-8859-1?Q?tvSeILASCUQFmauLy0bAhUmFMolFI84QmwJfgphSLAWBTTlmlPuD0nqXSc?= =?iso-8859-1?Q?ianW3cZigi/xxrsHR4ep12gUwdeq4XYJZFkFKrTjBSPQPkYg2qIKnHjCHP?= =?iso-8859-1?Q?tBaw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB2195AAF05ECB2A7D7B0597AAF46E9AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1cb0f5e9-65bf-44bc-de79-08d9bf07b590 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2021 13:43:28.0857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8w8rKl94xsxhG0+eDNA3rLlFCBpL7kcpbUJMsBJsoRMqAR2PvApgI7h2SXu/fJipEXRLjiR7i4WjL8ReW9+9PraJz/DG4l/27TJ7y55VPSg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5540 Archived-At: Subject: Re: [Lake] review of edhoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 13:43:38 -0000 --_000_AM4PR0701MB2195AAF05ECB2A7D7B0597AAF46E9AM4PR0701MB2195_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks for the review, it is recorded as github issue #202. Comments below. A proposed update to the draft is in PR #211, but some of the comments we m= ade into separate issues or additions to existing issues, as detailed in th= e comments. From: Lake on behalf of Stephen Farrell Date: Thursday, 11 November 2021 at 01:39 To: lake@ietf.org Subject: [Lake] review of edhoc-12 Hiya, At our last interim I also promised to review edhoc. This is my late (apologies;-) review. This is all review by me as just another participant, not as co-chair. (So please do feel entirely free to ignore bits or just say no.) Generally, I guess I could implement from this, were I fluent in CBOR/COSE etc, so I think it's in good shape. All but my first comment are editorial. I assumed that we'll have others who do crypto analysis and implementers who'll provide yet more detailed feedback as we go, so we're not quite there yet but getting pretty close IMO. Good job! Cheers, S. - Connection identifiers (which can be byte-strings) are sent in clear which could enable various network observer attacks for protocols that later send values obviously derived from connection IDs in clear. (I see from A.3 that one main use case does expose these values anyway.). To given an example of how this could be concerning, if some proxy (that just muxes packets) sits between I and R then those cleartext identifiers could allow an observer on that link to more easily do traffic analysis of a specific initiator's traffic. Was any consideration given to deriving such identifiers in a less obvious manner? I'm not claiming that that'd be a great improvement, just asking. {GS: John provided a response in github issue #202 (second post on the issu= e). The discussion also continues on the future-OSCORE-update repo [1]. Her= e is my attempt to summarize the topic: 1. Connection identifiers are selected in EDHOC and may be used with EDHOC = (as in A.3) or in OSCORE (as Sender/Recipient IDs). 2. The selection of connection IDs allows very short locally unique identif= iers. Derived stochastically unique connection IDs would be much longer. 3. Connection IDs, either when used as in A.3 or in OSCORE, work as key ide= ntifiers to facilitate retrieval of the security context used to decrypt th= e message and therefore need to be in plain text when used for this purpose= . 4. Connection IDs can become more difficult to trace by negotiating multipl= e connection IDs for one security context and/or by updating the identities= in ways that does not reveal the binding in plain text. OSCORE is not usin= g multi-path and therefore we don't need multiple connection IDs like e.g.= in QUIC. The update of identities is proposed to be included in Key Update= for OSCORE (KUDOS, [2]) instead of in EDHOC because: a. KUDOS assumes an e= xisting OSCORE security context which can be used to encrypt the first mess= age, and b. although it would be possible to link different messages of a s= ingle EDHOC key exchange to the same endpoints performing A.3, the main pri= vacy implication is most likely on the application protocol. With this in mind we propose to not change how connection IDs are establish= ed and used in EDHOC, but we should make a security consideration about thi= s for which we opened a separate issue #213. Is this sufficient? [1] Potential things to add to future update =B7 Issue #263 =B7 core-wg/osc= ore =B7 GitHub [2] https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/ (Note also issue/PR #188/189 about padding of plaintext, the lenght of whic= h also can be used to identify an endpoint.) } Editorial: - 80 pages is still big, I understand its hard to delete stuff but hope we keep trying:-) [GS: Yes. There are things we can do, e.g. as you point out in sections 1.2= (gone in PR #211) and 3.5, and avoid repetition of key derivation in secti= ons 4 and 5. But there is also a limit to what is worth the effort, and som= etimes readability is improved by somewhat overlapping text although differ= ent in structure. We are now at 40 pages excluding security considerations = / IANA / refs and appendices - how long should an AKE be? (As a comparison= , when I did my masters prof. Gabriel Barton told me that a master thesis i= s 10 pages long, anything else goes into appendices :-) ] - 1.1, CWT, CSS and C509 could do with expansion here on 1st use. (Perversely, X.509 is probably sufficiently well known and disliked to not need such:-) That might also make the text before (or caption of) Figure 1 easier to read. [GS: Done] - section 1.2: last para - this is repetitive, suggest making these points just once [GS: Content of 1.2 now merged into with 1.1 and shortened.] (Aside on figures/captions: I always find it a useful exercise to ensure that a figure+caption can, by itself, make a meaningful slide to present with no additions. And then I remove most text that's already in the caption from elsewhere in the document. Might be worth a try.) [GS: I sympathize with this and gave it a try but had some problems in prac= tice. The explanation of the content in Figure 1 is already 7 lines of comp= act text with expanded abbreviations and references which I think better st= ay immediately above the figure than in the caption. The terminology in Fig= ure 2 is explaned in 10 lines of text which is better structured as current= ly with bullets rather than running text in a caption. Figure 3 includes 10= types of protocol elements/primitives which again would make the caption u= nwieldly. While this principle was difficult to apply in general, it can make sense t= o expand the captions in Figures 8 and 9 to provide more text about the cip= her suite negotiation so I tried there. I also made a consistency check of = the figures harmonizing capitalization and minor updates (except Figure 4 w= hich I already worked on in another PR, to avoid merge conflicts). ] - Figure 1: I don't get how the "Figure 1 shows..." sentence results in those example message sizes. I'm not doubting the numbers, but the text could be improved (maybe, as suggested above via caption text.) [GS: The reference in the preceding sentence also applies here, we added th= at reference again.] - 1.4: are "EDHOC authenticated with digital signatures" and "EDHOC authenticated with signature keys" different things? If not, using one term is likely better. If so, using terms that are more clearly different would be good. [GS: Replaced "digital signature" with "signature keys" consistently.] - 1.5: which is normative, CDDL or English language text? We seem to have a bit of a mixture. [GS: CDDL defines the formats, and English language text complements the fo= rmat definitions. While there may be a potential conflict, I didn't find an= y examples of that. The only places where I see an overlap are places like = this: "message_2 SHALL be a CBOR Sequence (see {{CBOR}}) as defined below ~~~~~~~~~~~ CDDL message_2 =3D ( G_Y_CIPHERTEXT_2 : bstr, C_R : bstr / int, ) ~~~~~~~~~~~ " In this case the CDDL indicates that message_2 is a CDDL group (Section 2.1= (.2) in RFC 8610), and the English text makes this more specifc in that th= e particular group in this case is a CBOR Sequence. Unless there is an actu= al conflict, I'm not sure it adds to understanding neither to talk about a = potential non-existing conflicts in general terms, nor to talk about CDDL g= roups in this document. ] - Figure 2: I see why message 2 doesn't also use an AEAD(), but probably no harm to say that more explicitly here. Maybe moving some of the relevant text from section 8 to here would work. [GS: Giving the precise reason may be too much for a caption, but it includ= es now at least a high level motivation and the search item "SIGMA". ] - Figure 2: consider showing the AAD as an input to the AEAD() construct in the figure. That might be too cumbersome or it may help, not sure. {GS: We have changed notation in this figure a few times :-) AAD was includ= ed in e.g. [3]. AAD input has several components so does not make for simple figures. Hard = to get right level of information and keep message content on one line. Fur= ther suggestions are welcome! } [3] https://datatracker.ietf.org/doc/html/draft-selander-ace-cose-ecdhe-09 - 3.5.1, 3.5.2 and 3.5.3: this might be some text to shorten a lot - how much is it really needed? Could it be cut down to the stuff with 2119 terms and a bit more? (I'd keep the examples though.) [GS: Section 3.5 is 6 pages long, so, yes there is a potential to shortenin= g. (Not that we haven't restructured it before ;-) Let's have another look,= I made it a separate issue, #212.] - 3.6: does EDHOC *really* support hash based sigs? What'd be the consequence for EDHOC of using a private key too many times or loss of state? (Are you missing a reference to rfc8778 there too or is one embedded in COSE stuff somewhere?) [GS: In principle, yes, with a private cipher suite, using algorithms as de= fined in COSE, which should have the relevant references. The same would go= for, e.g., RSA. But since this is not a main use case I removed this examp= le from the main text on cipher suites in section 3.6 and just left the not= e in the PQC considerations section 8.4. ] - 4.1: Be good to clarify that the PRK_ labels in 4.1.x are basically local key names. (Same for others in 4.2.) [GS: I didn't get this comment. I assume "label" here does not refer to the= 'label part of the info data structure, since PRK_ is not included in= any label. Did you want the text to be explicit that the different PRK_ are names of pseudo-random keys? (I added this.) ] - 4.1.2/3: You need to define R and I in each of these as (I guess) the static DH secret and not as the identities of the initiator and recipient which were (I thought) the previous uses of I and R. Might be better to use different names though. [GS: You are right that I and R are also used for something else, but not a= s identities of I and R, rather as abbreviation/shorthand for "Initiator" a= nd "Responder", respectively. We thought it was OK to overload I and R on t= his point since there should be very small risk of confusion. (I wouldn't k= now how to calculate an ECDH shared secret from a public key and a public f= ixed text string.) I and R in the sense used in 4.1.2/3 is defined in 3.5.2= , I added a reminder about that in 4.1.2/3 with reference. ] - 5.2.2: What does "truncated after the cipher suite selected for this session" mean? (Also be good to say order of preference means first in network byte order is most-preferred.) I'm also puzzled by "but all cipher suites which are more preferred than the selected cipher suite in the list MUST be included in SUITES_I." [GS: I made some updates to the text, have a look and see if it reads bette= r: https://github.com/lake-wg/edhoc/pull/211/commits/a72bad2a I wonder if the first part changed needs a different structure, here is a p= otential change which I didn't make, do you think I should? OLD * SUITES_I - array of cipher suites which the Initiator supports in order o= f preference, starting with the most preferred and ending with the cipher s= uite selected for this session. If the most preferred cipher suite is selec= ted then SUITES_I is encoded as that cipher suite, i.e., as an int. The pro= cessing steps are detailed below and in {{wrong-selected}}. ALTERNATIVE * SUITES_I - array of cipher suites complying with the following conditions= (processing steps are detailed in {{init-proc-msg1}} and {{wrong-selected}= }): * All cipher suites in SUITES_I are supported by I * The cipher suites in SUITES_I are listed in order of preference by I,= i.e., the first in network byte order is most preferred, etc. * The last cipher suite in SUITES_I is selected by I to be used in this= EDHOC session * If the most preferred cipher suite coincides with the selected cipher= suite (i.e. first cipher suite =3D last cipher suite in SUITES_I) then SUI= TES_I is encoded as that cipher suite, i.e., as an int instead of an array. ] - 5.3.2: This seems to be the first occurrence of the "<<..>>" symbolism. A forward ref to C.1 would be good. [GS: Done] - 5.3.3: is it ok to pass EAD_2 to the application before checking authentication? [GS: Good question. If EAD_2 indeed contains external authorization data (e= .g. information about identity of intended endpoint), then EAD_2 needs to b= e processed before you can verify the identity of the other endpoint and th= e integrity of the message. But if we look at EAD_3, the same things apply,= but we also claim that EAD_3 is protected between Initiator and Responder,= which with the current order of things isn't verified at the time when EAD= processed. I added this to issue #210. ] - section 6: I found this v. hard to follow. Suspect a re-write for clarity would be good. [GS] Thanks for sharing. Could you be a little bit more specifc what is har= d to follow? Is a) the general error handling, b) the format of the error m= essage, c) the currently defined error codes or how they are used, d) speci= fically the cipher suite negotation , e) all above, or something else? Note: Stefan also commented on ERR_CODE 0 for which we made an update of se= ction 6.1 Success, see PR #200. - section 8: "EDHOC provides a minimum of 64-bit security..." could do with a reference to wherever that conclusion is derived. And 64-bit security isn't quite "in line" with TLS is it? [GS: Thanks, this text needs to be improved. The statement that the MAC mus= t be at least 8 bytes is a change already included in master branch post -1= 2, but the security level is also dependent on what algorithm is used. We r= emoved "This is in line with IPsec, TLS, and COSE." and we added this to is= sue #201.] - 8.7: stating that a "truly random seed MUST" be provided isn't a sensible use of 2119, and isn't entirely under the control of an implementer (maybe the section title could be re-thought?). [GS: Right, here is a proposed update: OLD If no true random number generator is available, a truly random seed MUST b= e provided from an external source and used with a cryptographically secure= pseudorandom number generator. NEW If no true random number generator is available, a random seed must be prov= ided from an external source and used with a cryptographically secure pseud= orandom number generator. About the section title, this is a subsection of the security consideration= s and the content does have relevance when deciding about implementations, = what would you propose instead? ] - 8.7 (or somewhere): if some random values are visible (connection identifiers?) then it can make sense to derive those from a different random stream compared to that used for randomly picking secrets. That way the publicly visible random numbers are less likely to leak information about the state of the PRNG used for secrets. Could be worth a mention. [GS: Good point. New issue #214.] - 8.7: discarding a message_1 because of G_X collision/reflection should also be stated earlier - it could very easily be missed here. [GS: Agree. We should add into the processing of message_1. This point is a= dded to issue #201.] - 8.7: TEE =3D> "cannot" be tampered is a little optimistic IMO. {GS: Agree, this is taken from the abstract of [4]: "A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment." [4] https://datatracker.ietf.org/doc/html/draft-ietf-teep-architecture-15 Proposed change: OLD The use of a TEE enforces that code within that environment cannot be tampe= red with, and that any data used by such code cannot be read or tampered wi= th by code outside that environment. NEW The use of a TEE aims at preventing code within that environment to be tamp= ered with, and preventing data used by such code to be read or tampered wit= h by code outside that environment. } - 9.10: The well-known URI is not mentioned at all in the body of the spec but only here and then in an appendix. A forward ref to A.3 from 9.10 is probably enough to fix. The same may apply to other IANA registrations I guess. [GS: Done] - 10.1: are we confident that all the normative I-Ds will become RFCs in a sufficiently timely manner? I've no specific reason to think they won't, and they're all far along the process, but sometimes transitive dependencies can cause a lot of delay. (Very sadly, we can't just ask Jim about this.) [GS: We think so. Those which are not RFCs would probably be OK as informat= ive references.] - A.1: "byte string shaped"? what's that mean? [GS: The parenthesis containing this text is removed. The meaning is hopefu= lly explained by the example.] - Appendix D: Point 6 mentions an EUI-64. I'm not clear how that'd be used in edhoc. [GS: Reference to example in 3.5.3 added.] - The URL for SIGMA can use https so change to [1] [1] https://webee.technion.ac.il/~hugo/sigma-pdf.pdf [GS: Done] G=F6ran --_000_AM4PR0701MB2195AAF05ECB2A7D7B0597AAF46E9AM4PR0701MB2195_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stephen,&nbs= p;

 

Thanks for the revie= w, it is recorded as github issue #202. Comments below. 

 

A proposed update to= the draft is in PR #211, but some of the comments we made into separate is= sues or additions to existing issues, as detailed in the comments. 

 

 

 

From: Lake <lake-bounces@ietf.org> on behalf of Stephen = Farrell <stephen.farrell@cs.tcd.ie>
Date: Thursday, 11= November 2021 at 01:39
To: lake@ietf.org = <lake@ietf.org>
Subject: [Lake] re= view of edhoc-12 


Hiya,

At our last interim I also promised to review edhoc. This
is my late (apologies;-) review. This is all review by me
as just another participant, not as co-chair. (So please
do feel entirely free to ignore bits or just say no.)

Generally, I guess I could implement from this, were I
fluent in CBOR/COSE etc, so I think it's in good shape.
All but my first comment are editorial. I assumed that
we'll have others who do crypto analysis and implementers
who'll provide yet more detailed feedback as we go, so
we're not quite there yet but getting pretty close IMO.
Good job!

Cheers,
S.


- Connection identifiers (which can be byte-strings) are
sent in clear which could enable various network observer
attacks for protocols that later send values obviously
derived from connection IDs in clear. (I see from A.3 that
one main use case does expose these values anyway.). To
given an example of how this could be concerning, if some
proxy (that just muxes packets) sits between I and R then
those cleartext identifiers could allow an observer on that
link to more easily do traffic analysis of a specific
initiator's traffic. Was any consideration given to deriving
such identifiers in a less obvious manner? I'm not claiming
that that'd be a great improvement, just asking. 

{GS: John provided a re= sponse in github issue #202 (second post on the issue). The discussion also= continues on the future-OSCORE-update repo [1]. Here is my attempt to summ= arize the topic: 

1. Connection identifie= rs are selected in EDHOC and may be used with EDHOC (as in A.3) or in OSCOR= E (as Sender/Recipient IDs). 

2. The selection of con= nection IDs allows very short locally unique identifiers. Derived stochasti= cally unique connection IDs would be much longer. 

3. Connection IDs, eith= er when used as in A.3 or in OSCORE, work as key identifiers to facilitate = retrieval of the security context used to decrypt the message and therefore= need to be in plain text when used for this purpose. 

4. Connection IDs can b= ecome more difficult to trace by negotiating multiple connection IDs for on= e security context and/or by updating the identities in ways that does not = reveal the binding in plain text. OSCORE is not using multi-path and therefore we don't  need multiple connection IDs like= e.g. in QUIC. The update of identities is proposed to be included in Key U= pdate for OSCORE (KUDOS, [2]) instead of in EDHOC because: a. KUDOS assumes an existing OSCORE security context which = can be used to encrypt the first message, and b. although it would be possi= ble to link different messages of a single EDHOC key exchange to the same e= ndpoints performing A.3, the main privacy implication is most likely on the application protocol. =

With this in mind we pr= opose to not change how connection IDs are established and used in EDHOC, b= ut we should make a security consideration about this for which we opened a= separate issue #213. 

Is this sufficient? 

[1] Potential things to add to future update =B7 Issue #263 =B7 core-wg/oscore =B7 GitHu= b&= nbsp;

[2] https://datatracker.ietf.org/doc/d= raft-ietf-core-oscore-key-update/ 

(Note also issue/PR #18= 8/189 about padding of plaintext, the lenght of which also can be used to i= dentify an endpoint.)
} 



Editorial:

- 80 pages is still big, I understand its hard to delete
   stuff but hope we keep trying:-)
 

[GS: Yes. There are thi= ngs we can do, e.g. as you point out in sections 1.2 (gone in PR #211) and = 3.5, and avoid repetition of key derivation in sections 4 and 5. But there = is also a limit to what is worth the effort, and sometimes readability is improved by somewhat overlapping text= although different in structure. We are now at 40 pages excluding security= considerations / IANA / refs and appendices -  how long should an AKE be? (As a comparison, when I did my masters prof. Gabri= el Barton told me that a master thesis is 10 pages long, anything else goes= into appendices :-)
] 


- 1.1, CWT, CSS and C509 could do with expansion here on
   1st use.  (Perversely, X.509 is probably sufficiently
well known and disliked to not need such:-) That might also
make the text before (or caption of) Figure 1 easier to
read. 

[GS: Done] 


- section 1.2: last para - this is repetitive, suggest
   making these points just once 

[GS: Content of 1.2 now= merged into with 1.1 and shortened.]

(Aside on figures/captions: I always find it a useful
exercise to ensure that a figure+caption can, by itself,
make a meaningful slide to present with no additions. And
then I remove most text that's already in the caption from
elsewhere in the document. Might be worth a try.) 

[GS: I sympathize with = this and gave it a try but had some problems in practice. The explanation o= f the content in Figure 1 is already 7 lines of compact text with expanded = abbreviations and references which I think better stay immediately above the figure than in the caption. The te= rminology in Figure 2 is explaned in 10 lines of text which is better struc= tured as currently with bullets rather than running text in a caption. Figu= re 3 includes 10 types of protocol elements/primitives which again would make the caption unwieldly.  

While this principle wa= s difficult to apply in general, it can make sense to expand the captions i= n Figures 8 and 9 to provide more text about the cipher suite negotiation s= o I tried there. I also made a consistency check of the figures harmonizing capitalization and minor updates (except = Figure 4 which I already worked on in another PR, to avoid merge conflicts)= .
] 



- Figure 1: I don't get how the "Figure 1 shows..."
   sentence results in those example message sizes. I'm not
doubting the numbers, but the text could be improved
(maybe, as suggested above via caption text.) 

[GS: The reference in t= he preceding sentence also applies here, we added that reference again.]

- 1.4: are "EDHOC authenticated with digital signatures"
   and "EDHOC authenticated with signature keys" differ= ent
things? If not, using one term is likely better. If so,
using terms that are more clearly different would be good.
 

[GS: Replaced "dig= ital signature" with "signature keys" consistently.]&nb= sp;


- 1.5: which is normative, CDDL or English language text?
   We seem to have a bit of a mixture. 

[GS: CDDL defines the f= ormats, and English language text complements the format definitions. While= there may be a potential conflict, I didn't find any examples of that. The= only places where I see an overlap are places like this: 

"message_2 SHALL be a CBOR Sequence (see {= {CBOR}}) as defined below 

~~~~~~~~~~~ CDDL
message_2 =3D (
  G_Y_C= IPHERTEXT_2 : bstr,
  C_R := bstr / int,
)
~~~~~~~~~~~ " 

In this case the CDDL i= ndicates that message_2 is a CDDL group (Section 2.1 (.2) in RFC 8610), and= the English text makes this more specifc in that the particular group in t= his case is a CBOR Sequence. Unless there is an actual conflict, I'm not sure it adds to understanding neither= to talk about a potential non-existing conflicts in general terms, nor to = talk about CDDL groups in this document. 
] 


- Figure 2: I see why message 2 doesn't also use an AEAD(),
   but probably no harm to say that more explicitly here.
Maybe moving some of the relevant text from section 8 to
here would work. 

[GS: Giving the precise= reason may be too much for a caption, but it includes now at least a high = level motivation and the search item "SIGMA".
] 



- Figure 2: consider showing the AAD as an input to the
   AEAD() construct in the figure. That might be too
cumbersome or it may help, not sure. 

{GS: We have changed no= tation in this figure a few times :-) AAD was included in e.g. [3].&n= bsp; 
AAD input has several components so does not make for simple figures. Hard = to get right level of information and keep message content on one line. Fur= ther suggestions are welcome!
} 

[3] https://datatracker= .ietf.org/doc/html/draft-selander-ace-cose-ecdhe-09 =



- 3.5.1, 3.5.2 and 3.5.3: this might be some text to
   shorten a lot - how much is it really needed? Could it be
cut down to the stuff with 2119 terms and a bit more? (I'd
keep the examples though.) 

[GS: Section 3.5 is 6 p= ages long, so, yes there is a potential to shortening. (Not that we haven't= restructured it before ;-) Let's have another look, I made it a separate i= ssue, #212.]

- 3.6: does EDHOC *really* support hash based sigs? What'd
   be the consequence for EDHOC of using a private key too
many times or loss of state?  (Are you missing a reference
to rfc8778 there too or is one embedded in COSE stuff
somewhere?)
 

[GS: In principle, yes,= with a private cipher suite, using algorithms as defined in COSE, which sh= ould have the relevant references. The same would go for, e.g., RSA. But si= nce this is not a main use case I removed this example from the main text on cipher suites in section 3.6 and just l= eft the note in the PQC considerations section 8.4.
]


- 4.1: Be good to clarify that the PRK_<foo> labels in
   4.1.x are basically local key names. (Same for others in
4.2.)
 

[GS: I didn't get this = comment. I assume "label" here does not refer to the 'label part = of the info data structure, since PRK_<foo> is not included in any la= bel. = Did you want the text to be explicit that the different PRK_<foo> are na= mes of pseudo-random keys? (I added this.)
]
&nb= sp;



- 4.1.2/3: You need to define R and I in each of these as
   (I guess) the static DH secret and not as the identities
of the initiator and recipient which were (I thought) the
previous uses of I and R. Might be better to use different
names though. 

[GS: You are right that= I and R are also used for something else, but not as identities of I and R= , rather as abbreviation/shorthand for "Initiator" and "Resp= onder", respectively. We thought it was OK to overload I and R on this point since there should be very small risk of confusion. = (I wouldn't know how to calculate an ECDH shared secret from a public key a= nd a public fixed text string.) I and R in the sense used in 4.1.2/3 is def= ined in 3.5.2,  I added a reminder about that in 4.1.2/3 with reference. 
] 


- 5.2.2: What does "truncated after the cipher suite
   selected for this session" mean? (Also be good to say
order of preference means first in network byte order is
most-preferred.) I'm also puzzled by "but all cipher suites
which are more preferred than the selected cipher suite in
the list MUST be included in SUITES_I."
 

[GS: I made some update= s to the text, have a look and see if it reads better: 

https://github.com/lake= -wg/edhoc/pull/211/commits/a72bad2a 

I wonder if the first p= art changed needs a different structure, here is a potential change which I= didn't make, do you think I should? 

OLD
* SUITES_I - array of ci= pher suites which the Initiator supports in order of preference, starting w= ith the most preferred and ending with the cipher suite selected for this s= ession. If the most preferred cipher suite is selected then SUITES_I is encoded as that cipher suite, i.e., as = an int. The processing steps are detailed below and in {{wrong-selected}}.<= /span> = ;

ALTERNATIVE
* SUITES_I - array of cipher suites complying with the following conditions= (processing steps are detailed in {{init-proc-msg1}} and {{wrong-selected}= }):
    = * All cipher suites in SUITES_I are supported by I
    = * The cipher suites in SUITES_I are listed in order of preference by= I, i.e., the first in network byte order is most preferred, etc.
    = * The last cipher suite in SUITES_I is selected by I to be used in t= his EDHOC session
    = * If the most preferred cipher suite coincides with the selected cip= her suite (i.e. first cipher suite =3D last cipher suite in SUITES_I) then = SUITES_I is encoded as that cipher suite, i.e., as an int instead of an array. 

] 


- 5.3.2: This seems to be the first occurrence of the
   "<<..>>" symbolism. A forward ref to C.1= would be good.

 

[GS: Done] 

 


- 5.3.3: is it ok to pass EAD_2 to the application before
   checking authentication?

&nbs= p;

[GS: Good question. If = EAD_2 indeed contains external authorization data (e.g. information about i= dentity of intended endpoint), then EAD_2 needs to be processed before you = can verify the identity of the other endpoint and the integrity of the message. But if we look at EAD_3, the sa= me things apply, but we also claim that EAD_3 is protected between Initiato= r and Responder, which with the current order of things isn't verified at t= he time when EAD processed. I added this to issue #210.
] 


- section 6: I found this v. hard to follow. Suspect a
   re-write for clarity would be good. 

[GS] Thanks for sharing= . Could you be a little bit more specifc what is hard to follow? Is a) the = general error handling, b) the format of the error message, c) the currentl= y defined error codes or how they are used, d) specifically the cipher suite negotation , e) all above, or somet= hing else? 

Note: Stefan also comme= nted on ERR_CODE 0 for which we made an update of section 6.1 Success, see = PR #200. 


- section 8: "EDHOC provides a minimum of 64-bit
   security..." could do with a reference to wherever that conclusion is derived. And 64-bit security isn't quite "in
line" with TLS is it? 

[GS: Thanks, this text = needs to be improved. The statement that the MAC must be at least 8 bytes i= s a change already included in master branch post -12, but the security lev= el is also dependent on what algorithm is used. We removed "This is in line with IPsec, TLS, and COSE."= and we added this to issue #201.] 



- 8.7: stating that a "truly random seed MUST" be provided
   isn't a sensible use of 2119, and isn't entirely under
the control of an implementer (maybe the section title
could be re-thought?).

&nbs= p;

[GS: Right, here is a p= roposed update: 

OLD
If no true random number= generator is available, a truly random seed MUST be provided from an exter= nal source and used with a cryptographically secure pseudorandom number gen= erator.
NEW
If no true random number= generator is available, a random seed must be provided from an external source and used with a cryptographically secure = pseudorandom number generator. 

About the section title= , this is a subsection of the security considerations and the content does = have relevance when deciding about implementations, what would you propose = instead? 

] 


- 8.7 (or somewhere): if some random values are visible
   (connection identifiers?) then it can make sense to
derive those from a different random stream compared to
that used for randomly picking secrets. That way the
publicly visible random numbers are less likely to leak
information about the state of the PRNG used for secrets.
Could be worth a mention. 

[GS: Good point. New is= sue #214.] 



- 8.7: discarding a message_1 because of G_X
   collision/reflection should also be stated earlier - it
could very easily be missed here.

&nbs= p;

[GS: Agree. We should a= dd into the processing of message_1. This point is added to issue #201.] 

 


- 8.7: TEE =3D> "cannot" be tampered is a little optimistic    IMO. 

{GS: Agree, this is tak= en from the abstract of [4]: 

&n= bsp; &= quot;&n= bsp;  that an= y code within that environment cannot be tampered with, and 

&n= bsp;  that an= y data used by such code cannot be read or tampered with by 

&n= bsp;  any cod= e outside that environment." 

 

[4] https://datatracker= .ietf.org/doc/html/draft-ietf-teep-architecture-15 <= /span>

Proposed change:&n= bsp;

OLD
The use of a TEE enforce= s that code within that environment cannot be tampered with, and that any d= ata used by such code cannot be read or tampered with by code outside that = environment. 

NEW
The use of a TEE aims at preventing code within that environment=  to<= /span> be tampered with, and preventing = data used by such code to be read or tampered with by code outside that environment. 

}

- 9.10: The well-known URI is not mentioned at all in the
   body of the spec but only here and then in an appendix. A
forward ref to A.3 from 9.10 is probably enough to fix. The
same may apply to other IANA registrations I guess. 
=

[GS: Done] 



- 10.1: are we confident that all the normative I-Ds will
   become RFCs in a sufficiently timely manner? I've no
specific reason to think they won't, and they're all far
along the process, but sometimes transitive dependencies
can cause a lot of delay.  (Very sadly, we can't just ask
Jim about this.)

 

[GS: We think so. Those= which are not RFCs would probably be OK as informative references.]&n= bsp;


- A.1: "byte string shaped"? what's that mean? 

[GS: The parenthesis co= ntaining this text is removed. The meaning is hopefully explained by the ex= ample.] 



- Appendix D: Point 6 mentions an EUI-64. I'm not clear how
   that'd be used in edhoc. 

[GS: Reference to examp= le in 3.5.3 added.] 



- The URL for SIGMA can use https so change to [1]
   [1] 
<= /span>https://webee.technion.ac.il/~hugo/sigma-pdf.pdf 

[GS: Done] 


G=F6ran

--_000_AM4PR0701MB2195AAF05ECB2A7D7B0597AAF46E9AM4PR0701MB2195_-- From nobody Tue Dec 14 05:52:36 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECDD3A0C3D for ; Tue, 14 Dec 2021 05:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ePcGMZlTZcUr for ; Tue, 14 Dec 2021 05:52:27 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2050.outbound.protection.outlook.com [104.47.2.50]) (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 7C2613A0CAC for ; Tue, 14 Dec 2021 05:52:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aTUAyJZvLkU1PJUcCaN3DzuL4GtGQfdeEHulkveOZSm9k1+XqAsdZx45nPTxo7hGlfXihIcmOfX3lQI9WFWr1FdzWecy81Io+JUWaomAXMNjsdmVDuHxHywTkiJHO//5rP9ENKygdMxOOabUpAHIbwH4kc9RrhnTRPbaD2tuWxJ6BVDg/EckJlBkEWqNQLnQyMNKlDzzasWLl8BTzQXauVGNqodzQYyWGSjAv8ALyXXSfIJdZvVv79Q1GFhnh0RhfNS4WZGvUiRcxIXYt646BLvnBiDm/Xo8Zqn3fenc//s2YRFo7XK2zP5lmTVXtX168rpZ3aZICjGSttZlkUJVLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5vxhzJegn6h7VhuILE9l+jvjvKLIY4TM/aW633bm0Pk=; b=P3UGPQW7C0Q5Y5ns3H8VbZFn7SMzDR5ZVEFI/zjihQaZUjP7xg8qDdPj7HB+z3/ir5GFeJZ/D+sOXPfTMGWPgRAtAkGg7h960zq/xPZuJXljh5K2Z7AOJhrhHWKo1AoehzdV7mX9VNc1xkXDgCMGtvzXw07uJ6LpBc7zKsnHIKMaXE8wzBwXiUoApLoQmX6c2RXlHYrO1jlb8LqHiaSesjjv9v2x1rYTjBRPLhSmUGs6aTeUgnoV8zJOMgdmMsReqvUO+wn/vENqdXhnriW9NzA77UaWsF+dwp7RhPOj4JRqPC5wpDSqxYZ802ks4ynn5yEz4lxNd9dHG1147I5Z5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5vxhzJegn6h7VhuILE9l+jvjvKLIY4TM/aW633bm0Pk=; b=EktzYLe+qG9TTZxKGFwfZSsBueHjQDEAobsvvYoUf5L4ysAxjFLhs1xO9HsZahKJKOpMIgP52IueStjjnXpiJS7q5Jw0XPeBiPOHRcU1QhvRh8GMmR6Pp62geWR2yt7HJjOF2BLWh6h7uZpB7IgjKVC2HgONMnNB3HRQezpRzac= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM0PR07MB4019.eurprd07.prod.outlook.com (2603:10a6:208:47::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.13; Tue, 14 Dec 2021 13:52:20 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4801.014; Tue, 14 Dec 2021 13:52:20 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Kathleen Moriarty , "lake@ietf.org" Thread-Topic: [Lake] EDHOC Review Thread-Index: AQHX0nyfqlrr8JvoSkeI14FHHhU5saww5XUk Date: Tue, 14 Dec 2021 13:52:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 1bb31f91-7265-3e45-0485-3c0171b494a5 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8854939c-0f2f-4746-671b-08d9bf08f2e9 x-ms-traffictypediagnostic: AM0PR07MB4019:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CWWSEKLKE3SPxhJdCVVbewDEfBWj7UDZgZYDEOUFonm6T4g77tSLRjC6i/sqpsbhtczk0gmHF7VGbUPHfybUxpoLcWdzVgjN+lXlIwJul5imOIzn3grF5qMnn3plNtSQHFUGZ+Ms+hOXrDdX3Lkn6tGRRs1O0SJPLoNrYfUQWhjduANvjjDq8L/E8+K3JmcdMqb95e2PoCcKBCkUZF2Os2OTpzmredEwgrJvWi+mNJOjrklSENu4kRrXMrtp2YZNyEXyj7Jbxa+qxCdHNOyo1+u8e9Ue87N59eMX6VtjdAk9jh4cjg/soyI8O6QGh+dQ+nAyDo7EBHgLW55oQF++jAA8uh0WJASDOysa+fnobi2mZqXufMctQ7ZRmgHwhAMkRXEifZmMO3ELbhESlDDVJxAToKrHg0GoZCjbo4WlDsugNSEkBipJKxpKWNKdyGw9w1GzdOQWBE914T9NyNv+8OfJYwz3KIwrMmFFBCwg6p+F4BKGlho4fxlejxkUkGj8Ve/eJhFYI46VMKs6LHoUgVPbMet4Wkmqm4SNvXli218ysyUzK2iG+PvOrskkNo8FhLPzxrB1N8p+6gqoN5H6Ll+ss122arH0TO5ygZ6rcwtHBUkNgaR7VUrhSjzXlfGIGmsEKzZ/MsZikUFiiVQK2LC+GK7xzyC5rs+SCOGnuHakN7Sflm1MexTRS2iLLYqjJnlOs3PpLftYFOzAwOxp3J0qA726AkIOF6vpNrlZG4STL2626hq3qRG5Z4MraHEfodIDVuh1jL0S55G27ZZRVJbJPNCWAP61lDT4WQkphXVB3+r9FDgXYQIkYr52nqvhDRzn3ip3IJuJo9/lEOZFVWgo3vCFwCe0fiXLlzLfGeHdXo9CoqQa59Yfiwn1L9JU x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(83380400001)(38070700005)(38100700002)(122000001)(82960400001)(52536014)(66446008)(64756008)(66556008)(66476007)(66946007)(110136005)(76116006)(91956017)(8936002)(8676002)(316002)(66574015)(55016003)(5660300002)(9686003)(186003)(26005)(2906002)(53546011)(508600001)(966005)(71200400001)(86362001)(6506007)(33656002)(7696005)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?34mO1oReC7ky7Ie4z7PQDCPez/XeN/R5715OOomPpQMMNC1ZcTErdCffi7?= =?iso-8859-1?Q?d8pq9aF8E6xUsWqQ67H9C9P+BkhIEf8JiF/+lwQOvZJMUq2MUayhgSY203?= =?iso-8859-1?Q?fV+XOJINWTTI37/yr/8YrA5I2uywVMi59i3chXVeyG85hgRxWEoBuF5o6B?= =?iso-8859-1?Q?nCoK+jILZ3kbrTnUVr2NCqlRbR1la4VJpst3mMXd/hg+wZr0Y+CDxkZBFA?= =?iso-8859-1?Q?PhYqLUbl46lq/SIa6t9V7IuYeBJtlR4abaozpC24x417r4Awg8k2MQVzwD?= =?iso-8859-1?Q?qnP2vNzd00B3S4OeunSCHtvSN0Uf08RKDz+6eyIs7C5zlBwbubewbbsVPC?= =?iso-8859-1?Q?i15htNJOqW0Ihj7Dzc1NE3MYLy88vAblEuhVj8D1q1Euo4XO/Z45R960mE?= =?iso-8859-1?Q?RtHzsTSiee8JB5zk+5/Zq1MTpmRzhjMWhd6jICuOxgJmmlaSnm/wmrJph/?= =?iso-8859-1?Q?zkQsrPW3UfE5ikLORW9JOFuhkgc0dJ2EpwHUBQEBCGN3pezB6wcdNX3dXN?= =?iso-8859-1?Q?HjWckqeSqTKpZVWjBiugsIaB7A2VtHP+l9lnZO0dKIPhl/HM76eoMvVNwD?= =?iso-8859-1?Q?3e6Y37gC5Z+pv1mOjNFAxxDT6dkjFgwlkC774PlCxUkhN0xgN5FQm6drnW?= =?iso-8859-1?Q?zMl40NfPXOYg22mAiR3OzdeXBZ8940e4S58z4icMJe8l0ET2YM54YhTF/V?= =?iso-8859-1?Q?eOWIlCFUjyY71F7SlYL/uBR1SBaHp9azbdqwLDtMeF0sC8q0nJeRmmyHxX?= =?iso-8859-1?Q?RJ7sitERYzOWOJjUhYmnZJLAf0FglZe8gwGwkcriE4DB5FfkKCFsGlFYm1?= =?iso-8859-1?Q?6YJVT48LWM7wcfk4NlXZ2a4xLVeUUdVnyilw56lCrn/X/MzxADc0+P3E13?= =?iso-8859-1?Q?XexMv90z32U+UOOFSZ+e7nKcleV6FPCfoWB1Nki1osRHEtx5VtSPSCC/Mn?= =?iso-8859-1?Q?Sf8kEMwWvLe4gycrEQ1+0lHt0vdHypjLjRjkNuMlrxRqxGIRYiNSlSjlzp?= =?iso-8859-1?Q?61arM2tznPZ0T8JC/CNGPEzlYDD0te6FJBJf6QN8xhkAiw2hEExI+rQdnh?= =?iso-8859-1?Q?NkWLIHgRU4TB7s8KZKCeEGZdxUv1LXHaDURpf3aWm5DHL1Qiol9XFFOkne?= =?iso-8859-1?Q?X0tUBuzvRQJJ0BnDdl7K8ao6hz4Vg0g/vTqID2sJ2m6xCQnE6AHPYJTR7S?= =?iso-8859-1?Q?flMj/K3iYv85KDFuX4qv2+OE/Q19pSMbmrILR8oKahGzZpeEFi4oLmV4Q3?= =?iso-8859-1?Q?/lbFFmOQJAlKFdLLtRHoFnUGaciqo5DDNXCBogU7vjKgrvqRB6YT1RiQKz?= =?iso-8859-1?Q?KXuuewLkj+Mo81H2zpDinVvmq3CZs/UhvO2wQyS1gs4JnZkxLaa4C51RyR?= =?iso-8859-1?Q?ppA2Tbz2yzW3GaZ8ndpQ5jRU0wtDzLTz7U71jtWUxxVxgQmv9CagnXJpCA?= =?iso-8859-1?Q?oH3OtL8a+2eqhyS9kHv0IqrleOfuJJg50hbG6Wd3MMaziXBRVdgMBqg4+C?= =?iso-8859-1?Q?TgVTFrLyXvNus0HKFlTgTSXPlxxGPexNcCJL6oFmB4hBupNb9K+rBsT113?= =?iso-8859-1?Q?1T3tGy1SYdEZ369RAnSP8b+8sTomyZP5s3C1jiTDygmQoEFNpChavuhcO4?= =?iso-8859-1?Q?f+wk1NKfanv39fUU1g2QzT99YWg6Rlchs9moUOAa55kK6g4oiUduq9Dx3J?= =?iso-8859-1?Q?eJQwrkyYy6KTS3XYqyRSnBfJHuh3IkUGpDhVHk/mqkD4AEhXsfOM2DFT8M?= =?iso-8859-1?Q?Fb1A=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8854939c-0f2f-4746-671b-08d9bf08f2e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2021 13:52:20.4880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /zMbTaDymcpZPCw0yeNY19oDbH6PAD4+Xh2o6CiQhVVp5gJ1RydWEq3vcWEovDiGM2CWcSsZ62ZPbo27DEw1/Vw9B9ZVyl9ep930rhkVqxU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4019 Archived-At: Subject: Re: [Lake] EDHOC Review X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 13:52:33 -0000 Hi Kathleen,=0A= =0A= Thanks for the review. It is recorded as github issue #196 and the updates = have already been integrated in the master branch:=0A= https://github.com/lake-wg/edhoc/commit/a4b182a=0A= except for the last comment:=0A= =0A= > IANA Registries=0A= >=0A= > I see for the registries created that Expert review [RFC8126] is required= . =0A= > What documentation is required? Is it also Specification required or is = =0A= > here other guidance for the experts when considering updates? =0A= > I see this is discussed in 9.14, but perhaps adding specification recomme= nded =0A= > in each of the places a registry is created would be helpful.=0A= =0A= We discussed documentation at the Oct 5 interim and the conclusion was tha= t expert review would be sufficient as a general scheme for these registers= (see also github issue #167 [0] which was therefore closed). But your comm= ent made us take another look at the registers. In particular for the EDHOC= method type registry it does really make sense to require a specification.= Therefore we reopened the issue and will revisit the topic on the interim = meeting tomorrow.=0A= =0A= [0] https://github.com/lake-wg/edhoc/issues/167=0A= =0A= =0A= Thanks!=0A= G=F6ran=0A= ________________________________________=0A= From: Lake on behalf of Kathleen Moriarty =0A= Sent: Friday, November 5, 2021 8:36 PM=0A= To: lake@ietf.org=0A= Subject: [Lake] EDHOC Review=0A= =0A= Greetings!=0A= =0A= I had offered to contribute a review at the last interim and am very glad t= o see this document come to this part of the process after the large effort= s that went into its development and demonstrating it's value for use with = constrained devices.=0A= =0A= Here are a few nits to consider:=0A= =0A= =0A= Section 1.1 Nit=0A= =0A= OLD:=0A= =0A= EDHOC does=0A= =0A= currently not support pre-shared key (PSK) authentication as=0A= =0A= authentication with static Diffie-Hellman public keys by reference=0A= =0A= produces equally small message sizes but with much simpler key=0A= =0A= distribution and identity protection.=0A= =0A= =0A= NEW:=0A= =0A= EDHOC does not=0A= =0A= currently support pre-shared key (PSK) authentication as=0A= =0A= authentication with static Diffie-Hellman public keys by reference=0A= =0A= produces equally small message sizes but with much simpler key=0A= =0A= distribution and identity protection.=0A= =0A= =0A= Section 1.2:=0A= =0A= =0A= The intent of the following sentence is to convey that these libraries are = already in use for OSCORE, but the wording of the following sentence could = be a bit more clear:=0A= =0A= OLD:=0A= =0A= By reusing existing libraries, the additional code size can be kept very=0A= =0A= low.=0A= =0A= PROPOSED:=0A= =0A= In using libraries already in the code base for OSCORE, the additional code= size can be kept very=0A= =0A= low.=0A= =0A= =0A= =0A= Section 3.8=0A= =0A= S/enrolment/enrollment/=0A= =0A= =0A= Section 4.3=0A= =0A= S/kan/can/=0A= =0A= In the following sentence: in most encryption algorithms the same key kan b= e=0A= =0A= =0A= IANA Registries=0A= =0A= =0A= I see for the registries created that Expert review [RFC8126] is required. = What documentation is required? Is it also Specification required or is the= re other guidance for the experts when considering updates? I see this is d= iscussed in 9.14, but perhaps adding specification recommended in each of t= he places a registry is created would be helpful.=0A= =0A= =0A= Thank you for your work on this document and protocol!=0A= =0A= --=0A= =0A= Best regards,=0A= Kathleen=0A= From nobody Tue Dec 14 05:53:06 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A483A0CAC for ; Tue, 14 Dec 2021 05:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-1.852, 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=cs.tcd.ie 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 G6TjyPohNlW1 for ; Tue, 14 Dec 2021 05:52:58 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::723]) (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 4B0253A0C3D for ; Tue, 14 Dec 2021 05:52:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MmRBrVyTJ8xuB+QyjYFNFB3CO/TrB1kwoUU0TTcgws0nreW4aezOmjMPVnYlAswBHizVhjW/rM2LFdYP9BlQOhKmEMD3WWEJ9un/cicMvzGI/DXcUUp8izqOHWYxVThjrQDEer+9mWM9uEuJv9t/llkx5v97X0Nu4HuEr+CPC2GY5imchGiWW8BJ5SYBGn2GsRosfH7SlgM+84caJov3YSSTpO6wSs8sIk+Bv3RiqJf0alnLnj1R3BqhFI7iblkGfaiWv6soK7rIR8tlwWcQQv/GIhQA+btaHYXulP9zxinrbxwmNNAJyYyXfXgHb19hfUsenFM/dgqRzy74FYYe9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MApnN7h+ZVLtQxvP9y4hFKH3PQ+O0Q6lMn7JhG6X7Fs=; b=EgZaQJ2xm0fbLQisnOy6HahA83feruFmZxPCyhPpRl8kNR/TCQXW8oIXadbvujmgX5Wc1or85i+xqOfiCpREJ667W+3fQF6OgyHnwCtMqyqXi4kAkW4qnI2mrrpKdgu0yO3E8q+hVAFJPz9017fFLWw/a2zAQQFxRLdpkWim+yYJd8Pdg0AMTcW+rH4I4rgKUOhaMgIVHvPbk5q1o+osbl1PD6YvLnThKszJL5s2fbbElUaJ172FuywP1fDvdqHpqX2S7wM9jh64/TNvGlPL2flGbHX0B0TDRTiPUqBv4L+BVX8y1Bsy599d5euhvGsSTgR64ikADdS0Jg6CEEJs7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MApnN7h+ZVLtQxvP9y4hFKH3PQ+O0Q6lMn7JhG6X7Fs=; b=Ay6VqtDhmsUGZpUKUY0LMWuKYna+dhFa2bvS1q7AZAPAIJWiZRLpVLsneFN+mFVQpUd53dM6HrX6qTeUSZmt+An2E3KUk2cxt1OVO/2MmUtyo1tKZtoXi19u8Olpp1ymW3JlwoN5dfUeSLxenhH5oixBsfQDJerklNZY1bpPlelqEYdnKcu6lM+G331agXBt+qM9fE6bgafFVQnxvWPi4uw+AWaMSzCPU18fGdoGS/ZAeZ0+6xj8aBZFLprbsqOHZbHlH7BLHkPxE3UWL1SjQK8IpyxSMiJLEH+GhV6SVOjOXWekQsoPdQEUSJt5o1UdK5uB8fS4uhV2K3Wsu45nSg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB6PR0201MB2376.eurprd02.prod.outlook.com (2603:10a6:4:34::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Tue, 14 Dec 2021 13:52:53 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4778.018; Tue, 14 Dec 2021 13:52:52 +0000 Message-ID: <7ee16a0b-e4f1-f65d-4032-ff759ddbd238@cs.tcd.ie> Date: Tue, 14 Dec 2021 13:50:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "lake@ietf.org" References: <617ce86c-8b4f-84e2-8eec-ae388cf023cf@cs.tcd.ie> From: Stephen Farrell In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------rBqricANwFTA0Xa0LFMxAC3Y" X-ClientProxiedBy: DU2PR04CA0086.eurprd04.prod.outlook.com (2603:10a6:10:232::31) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bb49d404-a25a-4e07-a8f7-08d9bf090618 X-MS-TrafficTypeDiagnostic: DB6PR0201MB2376:EE_ X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: //s7YNdNnZ3JbXq3lvWvliRNp+8WSNYVFfMLup7ZcyOkQ4bH/6dytHICMlxsdwuCNk2H70T6mJRudskzTKPSdM0TPqevJlNrq/n5hR8kJppUx9ufBEuI+idiGl8cYqWA8MhWJGBGdXTEHLgekMqTCLlsFZnT9tM8WOYH0kTarVc7RyEz0A/gHBrHkYXEjcpZFT7rP0+QkCUJL0DHMCWCsiOO1Q/SbTEkTVZE3cHiDkBVSjsXjRoX9xyR7JB74lFWdFh/cR5ePTuJ/PWEshmeU7krYTJ/2DfDpqVSgmWXLZxV3auXHsleeDIE0M8QBb39YPlpOAhB5uE/KbC7qybuRrDa08KT9Q3GmligIYZ9fNu4ZZpP9RXbqGPUg0dqt3WIz8bpThaXr4nbnf9E6w7rR3L7AYlb3YnMwOP8XayplHZb257FUkWDE8tzLQiAbovyv2UK2o7O4LW/SK1LK9KuTHYoqObszeLW+dnnXWBAZuxBkEqVnuI9/lRXNtXDgH7f9JgFV+f7Zmqpl9t+UUjxIU0pct177aj6o2/Fjs7/p7jHCebxh2pif+0UDxBFMyDhUjQovdbMK+r10N7gstNMBXWQKVatBWwNQZez6IODZ8KweEK4OwxHxf/2kQo5ev2MOSEePI0SPDTAVmITBX3GJmrQ53rd+Eul76SaPBGvbjce0Q1+MjsmZuJJf+Or+z2ub0axey/glfEqriVLVemLb0CSFJVnGUuVakw0nFLe+TIUy2OOfky2A6wnNJ9ywCC8k+RqzPAroAyuWuEASVp7zSrUpkjU1HEsXpWogdI6pc7R9q6obUxDr356VMukfGbf X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(36756003)(5660300002)(33964004)(45080400002)(38100700002)(235185007)(31696002)(8936002)(6506007)(110136005)(6666004)(53546011)(966005)(6512007)(2906002)(66476007)(8676002)(508600001)(786003)(86362001)(6486002)(26005)(30864003)(66556008)(66574015)(316002)(2616005)(83380400001)(186003)(31686004)(44832011)(21480400003)(66946007)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dStDSkZPdFNQNEJiZk9mVHNIUmFZQ3Jmc0dObWR1T2R3TFFXTzJJT0pOOWt4?= =?utf-8?B?bmY2cjRONDRhSkxpQzlUYm51N21nRXM5cHVkUUVUVGRaY0dyVUVBRk52Q1dr?= =?utf-8?B?S2x6UXZnVmRtU3llcDd3RCt3S3U3N0R1V1Z2N3pXY1ZuZTdTSUYySWxsSkxU?= =?utf-8?B?ekgycVpaZ0FZMkt3a1hTUHpvaSsyMFBXZFhCZk05cC9jcURUclJQb2Y0dFZh?= =?utf-8?B?ZmtnRGNSTUJmSTRrOXBERjVTTkxmMlJUK0dyYVZ3cDQ5U3hkMk9mM2U1blZR?= =?utf-8?B?WVozc0FCZU0xdnlJa1FLTTdEcHpwUkJEb3ZyUjVGOWMrUUk5WUNTQ29mSmJI?= =?utf-8?B?UW03c3MvcWNDSnBkUkdnUXh5bnlzVmRraElBYldFZmplKzYrR2tHeUZUemRB?= =?utf-8?B?cGFhNnBUaGVoL1BqMExDTUVjSmRkNk5lU256bmtLMFlUN3pZa0c4S0VHck9h?= =?utf-8?B?RWpWZ1BMTG1VN0RyckZabEFTdktsNlNmKzluWk1LR1FTZkRyeUJhRFpkZmE3?= =?utf-8?B?ekRpeGY0SUZKcjF0V1RUMDR2MWhoanJlOXdJWmNrK1pMQzAzR3NMZUVoRU1Z?= =?utf-8?B?SXFXZEFpTDM0ZFp5K2VTZ3BzVUM1RUZBQzA4amhCWU12NFEyaXdGQmNvQmF2?= =?utf-8?B?WXErMEN1b0RBb0F3K0lLS0o3cklYVWIzWTd0WVN6NHNHU3R6Q0pGWGV1eEwv?= =?utf-8?B?K1BvRTdhVGVHMUcva1N2dlpOcHYvY2dYMW9hVWtEUnV6QS9RRWdqVE5pZFlR?= =?utf-8?B?MUFzK1dheDNXRkNMZGtiZWJKUDhxTWNJQW1iYzNjbVZyTi9Rbytqc3BOMWl6?= =?utf-8?B?VkFIcG1CdDNqckdVMXFHUW1LOWRjOXhaUk1RU2lPNnpxeGZ0Z2JvYmozYlpD?= =?utf-8?B?RzlHRmxscitjQzZ2cFliZHZrQnNQd2VKdkpwSEErc1VkSzlCVUE0aUQxWFh2?= =?utf-8?B?dXFzR29Ybjh5NWlpYmszVW12R0pzekd1RTI1ZzZkYXo5NTgzWVhWYVZTUFFi?= =?utf-8?B?bmNncG5aZGdYZXlWWUFkdTRycW5TS3RUNDY2RjBMTnJSMjh2T2I3cWhLT3Fy?= =?utf-8?B?QVdONC8xRkNJQ0drSUloelhTUFZzUU9FY1FLQ3pzdVphNzZzU1hQcHltR0NJ?= =?utf-8?B?ZlZPdnZBdWpOS0RpUC9ZYmZvUURJL1RLd2JOZ3BnNTdmNHBuWVV6NklHdERp?= =?utf-8?B?V3NGSXdBOU1CNDc2TXhnTm9QamVqMjB3bzJwUzBKbGc2NUFUYWc3ZUhqQVJu?= =?utf-8?B?WmhSOG5CK3FZOVJBQVRGRmFwR3lnczFKR2dBUmU1eS9mK2VMQzJMV2lLbXFZ?= =?utf-8?B?ODNEMUtEY1VXeTFDM2JhdGZ1d1d6UmxnK2w0TVpSZjlXOUhvS2ZvUDNCUm5O?= =?utf-8?B?WGZGd2tYRTFuUkcyTXI5dHdTaUZPQ3phMVkyYnYvenJkblk1MWUyUGdKT0lM?= =?utf-8?B?ZkVHcTA4NitzRWtxSzQ4MzFXZXppUHpaQkFabnRRVG5URHZOWmx0emR6YlJr?= =?utf-8?B?cE9zVk9OaktYT0pEMXViT3h2ZEtVWjVJWXcrNXI0ZGdweStUS0xvRC94bXpo?= =?utf-8?B?WXFieWllSjFzSHNWd1hhcitSeVlZcUwrYS9OaFliZCtOaEdJK0wvSzdNM0VW?= =?utf-8?B?c1FRSFRXUDNXUC9xbTdZZ3hHSm80Y1FqdUg3bG00enc5bU5KUlFoYXBIWUJh?= =?utf-8?B?UllrVHdBemRZVnd0WUNEbHY1QmgyWmZvRUFQdXF0R0pEb1JTT0g2NEFGZTZ3?= =?utf-8?B?MVpCcHQrT3JaWGlrU3VPSE54ak1ncFNCdFl4QXgxbUR3ZnRQVkVxR3daSnIy?= =?utf-8?B?SDJOMUdIVStyWU9rM0YvV2hrQUlGOUgwUUsvQ21uZDRaWTBrcWFVVENUd00y?= =?utf-8?B?WWZmOE5JSnh0WGhsYTc1WnBEUktraW5JQXhzbFV0WVczcGtqNDErS25zWWx2?= =?utf-8?B?Q201RzgwRXZTekFpTDh1cjd1T0wwMEhqSGZRdDN1bGhGa1d2MXc4OGIrZEFE?= =?utf-8?B?NWVPbWpBRzV0MG52QXlUNlhwcit3NzZmaFZ5eG0yZ0lUVGRBZ1hMMlhZckx4?= =?utf-8?B?NTJjTFBlQTJUSnRwMEpNcmtxL0thaitsSDRHKzF5N3ZhcTVya3BPeWE3WXdQ?= =?utf-8?Q?5JYI=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: bb49d404-a25a-4e07-a8f7-08d9bf090618 X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2021 13:52:52.9095 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: OqvDSX5P5oCDu140QfpkBWafMvVGwPhm3cKlsJT2usKX8gYA3JvaUaI+m724X+As X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0201MB2376 Archived-At: Subject: Re: [Lake] review of edhoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 13:53:05 -0000 --------------rBqricANwFTA0Xa0LFMxAC3Y Content-Type: multipart/mixed; boundary="------------tgBFeII0jlFlelDtuhofaIhW"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "lake@ietf.org" Message-ID: <7ee16a0b-e4f1-f65d-4032-ff759ddbd238@cs.tcd.ie> Subject: Re: [Lake] review of edhoc-12 References: <617ce86c-8b4f-84e2-8eec-ae388cf023cf@cs.tcd.ie> In-Reply-To: --------------tgBFeII0jlFlelDtuhofaIhW Content-Type: multipart/mixed; boundary="------------m0SRsrSyMpHbRG5GbaWajFP9" --------------m0SRsrSyMpHbRG5GbaWajFP9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpIaXlhLA0KDQpPbiAxNC8xMi8yMDIxIDEzOjQzLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6 DQo+IEhpIFN0ZXBoZW4sDQo+IA0KPiBUaGFua3MgZm9yIHRoZSByZXZpZXcsIGl0IGlzIHJl Y29yZGVkIGFzIGdpdGh1YiBpc3N1ZSAjMjAyLiBDb21tZW50cw0KPiBiZWxvdy4NCj4gDQo+ IEEgcHJvcG9zZWQgdXBkYXRlIHRvIHRoZSBkcmFmdCBpcyBpbiBQUiAjMjExLCBidXQgc29t ZSBvZiB0aGUNCj4gY29tbWVudHMgd2UgbWFkZSBpbnRvIHNlcGFyYXRlIGlzc3VlcyBvciBh ZGRpdGlvbnMgdG8gZXhpc3RpbmcNCj4gaXNzdWVzLCBhcyBkZXRhaWxlZCBpbiB0aGUgY29t bWVudHMuDQoNCkknbGwgZ28gb3ZlciB0aGlzIGxhdGVyIGJ1dCBkbyB5b3UgcHJlZmVyIGEg bWFpbCB0aHJlYWQNCm9yIGRpc2N1c3Npb24gb24gdGhlIEdIIGlzc3VlIHdoZXJlIHRoZXJl J3Mgb25lPw0KDQpFaXRoZXIncyBmaW5lIGJ5IG1lLi4uDQoNCkNoZWVycywNClMuDQoNCj4g DQo+IA0KPiANCj4gRnJvbTogTGFrZSA8bGFrZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh bGYgb2YgU3RlcGhlbiBGYXJyZWxsDQo+IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiBE YXRlOiBUaHVyc2RheSwgMTEgTm92ZW1iZXIgMjAyMSBhdA0KPiAwMTozOSBUbzogbGFrZUBp ZXRmLm9yZyA8bGFrZUBpZXRmLm9yZz4gU3ViamVjdDogW0xha2VdIHJldmlldyBvZg0KPiBl ZGhvYy0xMg0KPiANCj4gSGl5YSwNCj4gDQo+IEF0IG91ciBsYXN0IGludGVyaW0gSSBhbHNv IHByb21pc2VkIHRvIHJldmlldyBlZGhvYy4gVGhpcyBpcyBteSBsYXRlDQo+IChhcG9sb2dp ZXM7LSkgcmV2aWV3LiBUaGlzIGlzIGFsbCByZXZpZXcgYnkgbWUgYXMganVzdCBhbm90aGVy DQo+IHBhcnRpY2lwYW50LCBub3QgYXMgY28tY2hhaXIuIChTbyBwbGVhc2UgZG8gZmVlbCBl bnRpcmVseSBmcmVlIHRvDQo+IGlnbm9yZSBiaXRzIG9yIGp1c3Qgc2F5IG5vLikNCj4gDQo+ IEdlbmVyYWxseSwgSSBndWVzcyBJIGNvdWxkIGltcGxlbWVudCBmcm9tIHRoaXMsIHdlcmUg SSBmbHVlbnQgaW4NCj4gQ0JPUi9DT1NFIGV0Yywgc28gSSB0aGluayBpdCdzIGluIGdvb2Qg c2hhcGUuIEFsbCBidXQgbXkgZmlyc3QNCj4gY29tbWVudCBhcmUgZWRpdG9yaWFsLiBJIGFz c3VtZWQgdGhhdCB3ZSdsbCBoYXZlIG90aGVycyB3aG8gZG8gY3J5cHRvDQo+IGFuYWx5c2lz IGFuZCBpbXBsZW1lbnRlcnMgd2hvJ2xsIHByb3ZpZGUgeWV0IG1vcmUgZGV0YWlsZWQgZmVl ZGJhY2sNCj4gYXMgd2UgZ28sIHNvIHdlJ3JlIG5vdCBxdWl0ZSB0aGVyZSB5ZXQgYnV0IGdl dHRpbmcgcHJldHR5IGNsb3NlIElNTy4gDQo+IEdvb2Qgam9iIQ0KPiANCj4gQ2hlZXJzLCBT Lg0KPiANCj4gDQo+IC0gQ29ubmVjdGlvbiBpZGVudGlmaWVycyAod2hpY2ggY2FuIGJlIGJ5 dGUtc3RyaW5ncykgYXJlIHNlbnQgaW4NCj4gY2xlYXIgd2hpY2ggY291bGQgZW5hYmxlIHZh cmlvdXMgbmV0d29yayBvYnNlcnZlciBhdHRhY2tzIGZvcg0KPiBwcm90b2NvbHMgdGhhdCBs YXRlciBzZW5kIHZhbHVlcyBvYnZpb3VzbHkgZGVyaXZlZCBmcm9tIGNvbm5lY3Rpb24NCj4g SURzIGluIGNsZWFyLiAoSSBzZWUgZnJvbSBBLjMgdGhhdCBvbmUgbWFpbiB1c2UgY2FzZSBk b2VzIGV4cG9zZQ0KPiB0aGVzZSB2YWx1ZXMgYW55d2F5LikuIFRvIGdpdmVuIGFuIGV4YW1w bGUgb2YgaG93IHRoaXMgY291bGQgYmUNCj4gY29uY2VybmluZywgaWYgc29tZSBwcm94eSAo dGhhdCBqdXN0IG11eGVzIHBhY2tldHMpIHNpdHMgYmV0d2VlbiBJDQo+IGFuZCBSIHRoZW4g dGhvc2UgY2xlYXJ0ZXh0IGlkZW50aWZpZXJzIGNvdWxkIGFsbG93IGFuIG9ic2VydmVyIG9u DQo+IHRoYXQgbGluayB0byBtb3JlIGVhc2lseSBkbyB0cmFmZmljIGFuYWx5c2lzIG9mIGEg c3BlY2lmaWMgDQo+IGluaXRpYXRvcidzIHRyYWZmaWMuIFdhcyBhbnkgY29uc2lkZXJhdGlv biBnaXZlbiB0byBkZXJpdmluZyBzdWNoDQo+IGlkZW50aWZpZXJzIGluIGEgbGVzcyBvYnZp b3VzIG1hbm5lcj8gSSdtIG5vdCBjbGFpbWluZyB0aGF0IHRoYXQnZCBiZQ0KPiBhIGdyZWF0 IGltcHJvdmVtZW50LCBqdXN0IGFza2luZy4ge0dTOiBKb2huIHByb3ZpZGVkIGEgcmVzcG9u c2UgaW4NCj4gZ2l0aHViIGlzc3VlICMyMDIgKHNlY29uZCBwb3N0IG9uIHRoZSBpc3N1ZSku IFRoZSBkaXNjdXNzaW9uIGFsc28NCj4gY29udGludWVzIG9uIHRoZSBmdXR1cmUtT1NDT1JF LXVwZGF0ZSByZXBvIFsxXS4gSGVyZSBpcyBteSBhdHRlbXB0IHRvDQo+IHN1bW1hcml6ZSB0 aGUgdG9waWM6IDEuIENvbm5lY3Rpb24gaWRlbnRpZmllcnMgYXJlIHNlbGVjdGVkIGluIEVE SE9DDQo+IGFuZCBtYXkgYmUgdXNlZCB3aXRoIEVESE9DIChhcyBpbiBBLjMpIG9yIGluIE9T Q09SRSAoYXMNCj4gU2VuZGVyL1JlY2lwaWVudCBJRHMpLiAyLiBUaGUgc2VsZWN0aW9uIG9m IGNvbm5lY3Rpb24gSURzIGFsbG93cyB2ZXJ5DQo+IHNob3J0IGxvY2FsbHkgdW5pcXVlIGlk ZW50aWZpZXJzLiBEZXJpdmVkIHN0b2NoYXN0aWNhbGx5IHVuaXF1ZQ0KPiBjb25uZWN0aW9u IElEcyB3b3VsZCBiZSBtdWNoIGxvbmdlci4gMy4gQ29ubmVjdGlvbiBJRHMsIGVpdGhlciB3 aGVuDQo+IHVzZWQgYXMgaW4gQS4zIG9yIGluIE9TQ09SRSwgd29yayBhcyBrZXkgaWRlbnRp ZmllcnMgdG8gZmFjaWxpdGF0ZQ0KPiByZXRyaWV2YWwgb2YgdGhlIHNlY3VyaXR5IGNvbnRl eHQgdXNlZCB0byBkZWNyeXB0IHRoZSBtZXNzYWdlIGFuZA0KPiB0aGVyZWZvcmUgbmVlZCB0 byBiZSBpbiBwbGFpbiB0ZXh0IHdoZW4gdXNlZCBmb3IgdGhpcyBwdXJwb3NlLiA0Lg0KPiBD b25uZWN0aW9uIElEcyBjYW4gYmVjb21lIG1vcmUgZGlmZmljdWx0IHRvIHRyYWNlIGJ5IG5l Z290aWF0aW5nDQo+IG11bHRpcGxlIGNvbm5lY3Rpb24gSURzIGZvciBvbmUgc2VjdXJpdHkg Y29udGV4dCBhbmQvb3IgYnkgdXBkYXRpbmcNCj4gdGhlIGlkZW50aXRpZXMgaW4gd2F5cyB0 aGF0IGRvZXMgbm90IHJldmVhbCB0aGUgYmluZGluZyBpbiBwbGFpbg0KPiB0ZXh0LiBPU0NP UkUgaXMgbm90IHVzaW5nIG11bHRpLXBhdGggYW5kIHRoZXJlZm9yZSB3ZSBkb24ndCAgbmVl ZA0KPiBtdWx0aXBsZSBjb25uZWN0aW9uIElEcyBsaWtlIGUuZy4gaW4gUVVJQy4gVGhlIHVw ZGF0ZSBvZiBpZGVudGl0aWVzDQo+IGlzIHByb3Bvc2VkIHRvIGJlIGluY2x1ZGVkIGluIEtl eSBVcGRhdGUgZm9yIE9TQ09SRSAoS1VET1MsIFsyXSkNCj4gaW5zdGVhZCBvZiBpbiBFREhP QyBiZWNhdXNlOiBhLiBLVURPUyBhc3N1bWVzIGFuIGV4aXN0aW5nIE9TQ09SRQ0KPiBzZWN1 cml0eSBjb250ZXh0IHdoaWNoIGNhbiBiZSB1c2VkIHRvIGVuY3J5cHQgdGhlIGZpcnN0IG1l c3NhZ2UsIGFuZA0KPiBiLiBhbHRob3VnaCBpdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBsaW5r IGRpZmZlcmVudCBtZXNzYWdlcyBvZiBhDQo+IHNpbmdsZSBFREhPQyBrZXkgZXhjaGFuZ2Ug dG8gdGhlIHNhbWUgZW5kcG9pbnRzIHBlcmZvcm1pbmcgQS4zLCB0aGUNCj4gbWFpbiBwcml2 YWN5IGltcGxpY2F0aW9uIGlzIG1vc3QgbGlrZWx5IG9uIHRoZSBhcHBsaWNhdGlvbiBwcm90 b2NvbC4gDQo+IFdpdGggdGhpcyBpbiBtaW5kIHdlIHByb3Bvc2UgdG8gbm90IGNoYW5nZSBo b3cgY29ubmVjdGlvbiBJRHMgYXJlDQo+IGVzdGFibGlzaGVkIGFuZCB1c2VkIGluIEVESE9D LCBidXQgd2Ugc2hvdWxkIG1ha2UgYSBzZWN1cml0eQ0KPiBjb25zaWRlcmF0aW9uIGFib3V0 IHRoaXMgZm9yIHdoaWNoIHdlIG9wZW5lZCBhIHNlcGFyYXRlIGlzc3VlICMyMTMuIA0KPiBJ cyB0aGlzIHN1ZmZpY2llbnQ/IFsxXSBQb3RlbnRpYWwgdGhpbmdzIHRvIGFkZCB0byBmdXR1 cmUgdXBkYXRlIMK3DQo+IElzc3VlICMyNjMgwrcgY29yZS13Zy9vc2NvcmUgwrcNCj4gR2l0 SHViPGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL29zY29yZS9pc3N1ZXMvMjYzPiBbMl0N Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW9z Y29yZS1rZXktdXBkYXRlLyANCj4gKE5vdGUgYWxzbyBpc3N1ZS9QUiAjMTg4LzE4OSBhYm91 dCBwYWRkaW5nIG9mIHBsYWludGV4dCwgdGhlIGxlbmdodA0KPiBvZiB3aGljaCBhbHNvIGNh biBiZSB1c2VkIHRvIGlkZW50aWZ5IGFuIGVuZHBvaW50LikgfQ0KPiANCj4gDQo+IEVkaXRv cmlhbDoNCj4gDQo+IC0gODAgcGFnZXMgaXMgc3RpbGwgYmlnLCBJIHVuZGVyc3RhbmQgaXRz IGhhcmQgdG8gZGVsZXRlIHN0dWZmIGJ1dA0KPiBob3BlIHdlIGtlZXAgdHJ5aW5nOi0pIFtH UzogWWVzLiBUaGVyZSBhcmUgdGhpbmdzIHdlIGNhbiBkbywgZS5nLiBhcw0KPiB5b3UgcG9p bnQgb3V0IGluIHNlY3Rpb25zIDEuMiAoZ29uZSBpbiBQUiAjMjExKSBhbmQgMy41LCBhbmQg YXZvaWQNCj4gcmVwZXRpdGlvbiBvZiBrZXkgZGVyaXZhdGlvbiBpbiBzZWN0aW9ucyA0IGFu ZCA1LiBCdXQgdGhlcmUgaXMgYWxzbyBhDQo+IGxpbWl0IHRvIHdoYXQgaXMgd29ydGggdGhl IGVmZm9ydCwgYW5kIHNvbWV0aW1lcyByZWFkYWJpbGl0eSBpcw0KPiBpbXByb3ZlZCBieSBz b21ld2hhdCBvdmVybGFwcGluZyB0ZXh0IGFsdGhvdWdoIGRpZmZlcmVudCBpbg0KPiBzdHJ1 Y3R1cmUuIFdlIGFyZSBub3cgYXQgNDAgcGFnZXMgZXhjbHVkaW5nIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIC8NCj4gSUFOQSAvIHJlZnMgYW5kIGFwcGVuZGljZXMgLSAgaG93IGxvbmcg c2hvdWxkIGFuIEFLRSBiZT8gKEFzIGENCj4gY29tcGFyaXNvbiwgd2hlbiBJIGRpZCBteSBt YXN0ZXJzIHByb2YuIEdhYnJpZWwgQmFydG9uIHRvbGQgbWUgdGhhdCBhDQo+IG1hc3RlciB0 aGVzaXMgaXMgMTAgcGFnZXMgbG9uZywgYW55dGhpbmcgZWxzZSBnb2VzIGludG8gYXBwZW5k aWNlcw0KPiA6LSkgXQ0KPiANCj4gLSAxLjEsIENXVCwgQ1NTIGFuZCBDNTA5IGNvdWxkIGRv IHdpdGggZXhwYW5zaW9uIGhlcmUgb24gMXN0IHVzZS4NCj4gKFBlcnZlcnNlbHksIFguNTA5 IGlzIHByb2JhYmx5IHN1ZmZpY2llbnRseSB3ZWxsIGtub3duIGFuZCBkaXNsaWtlZA0KPiB0 byBub3QgbmVlZCBzdWNoOi0pIFRoYXQgbWlnaHQgYWxzbyBtYWtlIHRoZSB0ZXh0IGJlZm9y ZSAob3IgY2FwdGlvbg0KPiBvZikgRmlndXJlIDEgZWFzaWVyIHRvIHJlYWQuIFtHUzogRG9u ZV0NCj4gDQo+IC0gc2VjdGlvbiAxLjI6IGxhc3QgcGFyYSAtIHRoaXMgaXMgcmVwZXRpdGl2 ZSwgc3VnZ2VzdCBtYWtpbmcgdGhlc2UNCj4gcG9pbnRzIGp1c3Qgb25jZSBbR1M6IENvbnRl bnQgb2YgMS4yIG5vdyBtZXJnZWQgaW50byB3aXRoIDEuMSBhbmQNCj4gc2hvcnRlbmVkLl0N Cj4gDQo+IChBc2lkZSBvbiBmaWd1cmVzL2NhcHRpb25zOiBJIGFsd2F5cyBmaW5kIGl0IGEg dXNlZnVsIGV4ZXJjaXNlIHRvDQo+IGVuc3VyZSB0aGF0IGEgZmlndXJlK2NhcHRpb24gY2Fu LCBieSBpdHNlbGYsIG1ha2UgYSBtZWFuaW5nZnVsIHNsaWRlDQo+IHRvIHByZXNlbnQgd2l0 aCBubyBhZGRpdGlvbnMuIEFuZCB0aGVuIEkgcmVtb3ZlIG1vc3QgdGV4dCB0aGF0J3MNCj4g YWxyZWFkeSBpbiB0aGUgY2FwdGlvbiBmcm9tIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQu IE1pZ2h0IGJlIHdvcnRoDQo+IGEgdHJ5LikgW0dTOiBJIHN5bXBhdGhpemUgd2l0aCB0aGlz IGFuZCBnYXZlIGl0IGEgdHJ5IGJ1dCBoYWQgc29tZQ0KPiBwcm9ibGVtcyBpbiBwcmFjdGlj ZS4gVGhlIGV4cGxhbmF0aW9uIG9mIHRoZSBjb250ZW50IGluIEZpZ3VyZSAxIGlzDQo+IGFs cmVhZHkgNyBsaW5lcyBvZiBjb21wYWN0IHRleHQgd2l0aCBleHBhbmRlZCBhYmJyZXZpYXRp b25zIGFuZA0KPiByZWZlcmVuY2VzIHdoaWNoIEkgdGhpbmsgYmV0dGVyIHN0YXkgaW1tZWRp YXRlbHkgYWJvdmUgdGhlIGZpZ3VyZQ0KPiB0aGFuIGluIHRoZSBjYXB0aW9uLiBUaGUgdGVy bWlub2xvZ3kgaW4gRmlndXJlIDIgaXMgZXhwbGFuZWQgaW4gMTANCj4gbGluZXMgb2YgdGV4 dCB3aGljaCBpcyBiZXR0ZXIgc3RydWN0dXJlZCBhcyBjdXJyZW50bHkgd2l0aCBidWxsZXRz DQo+IHJhdGhlciB0aGFuIHJ1bm5pbmcgdGV4dCBpbiBhIGNhcHRpb24uIEZpZ3VyZSAzIGlu Y2x1ZGVzIDEwIHR5cGVzIG9mDQo+IHByb3RvY29sIGVsZW1lbnRzL3ByaW1pdGl2ZXMgd2hp Y2ggYWdhaW4gd291bGQgbWFrZSB0aGUgY2FwdGlvbg0KPiB1bndpZWxkbHkuIFdoaWxlIHRo aXMgcHJpbmNpcGxlIHdhcyBkaWZmaWN1bHQgdG8gYXBwbHkgaW4gZ2VuZXJhbCwgaXQNCj4g Y2FuIG1ha2Ugc2Vuc2UgdG8gZXhwYW5kIHRoZSBjYXB0aW9ucyBpbiBGaWd1cmVzIDggYW5k IDkgdG8gcHJvdmlkZQ0KPiBtb3JlIHRleHQgYWJvdXQgdGhlIGNpcGhlciBzdWl0ZSBuZWdv dGlhdGlvbiBzbyBJIHRyaWVkIHRoZXJlLiBJIGFsc28NCj4gbWFkZSBhIGNvbnNpc3RlbmN5 IGNoZWNrIG9mIHRoZSBmaWd1cmVzIGhhcm1vbml6aW5nIGNhcGl0YWxpemF0aW9uDQo+IGFu ZCBtaW5vciB1cGRhdGVzIChleGNlcHQgRmlndXJlIDQgd2hpY2ggSSBhbHJlYWR5IHdvcmtl ZCBvbiBpbg0KPiBhbm90aGVyIFBSLCB0byBhdm9pZCBtZXJnZSBjb25mbGljdHMpLiBdDQo+ IA0KPiANCj4gLSBGaWd1cmUgMTogSSBkb24ndCBnZXQgaG93IHRoZSAiRmlndXJlIDEgc2hv d3MuLi4iIHNlbnRlbmNlIHJlc3VsdHMNCj4gaW4gdGhvc2UgZXhhbXBsZSBtZXNzYWdlIHNp emVzLiBJJ20gbm90IGRvdWJ0aW5nIHRoZSBudW1iZXJzLCBidXQgdGhlDQo+IHRleHQgY291 bGQgYmUgaW1wcm92ZWQgKG1heWJlLCBhcyBzdWdnZXN0ZWQgYWJvdmUgdmlhIGNhcHRpb24g dGV4dC4pIA0KPiBbR1M6IFRoZSByZWZlcmVuY2UgaW4gdGhlIHByZWNlZGluZyBzZW50ZW5j ZSBhbHNvIGFwcGxpZXMgaGVyZSwgd2UNCj4gYWRkZWQgdGhhdCByZWZlcmVuY2UgYWdhaW4u XQ0KPiANCj4gLSAxLjQ6IGFyZSAiRURIT0MgYXV0aGVudGljYXRlZCB3aXRoIGRpZ2l0YWwg c2lnbmF0dXJlcyIgYW5kICJFREhPQw0KPiBhdXRoZW50aWNhdGVkIHdpdGggc2lnbmF0dXJl IGtleXMiIGRpZmZlcmVudCB0aGluZ3M/IElmIG5vdCwgdXNpbmcNCj4gb25lIHRlcm0gaXMg bGlrZWx5IGJldHRlci4gSWYgc28sIHVzaW5nIHRlcm1zIHRoYXQgYXJlIG1vcmUgY2xlYXJs eQ0KPiBkaWZmZXJlbnQgd291bGQgYmUgZ29vZC4gW0dTOiBSZXBsYWNlZCAiZGlnaXRhbCBz aWduYXR1cmUiIHdpdGgNCj4gInNpZ25hdHVyZSBrZXlzIiBjb25zaXN0ZW50bHkuXQ0KPiAN Cj4gLSAxLjU6IHdoaWNoIGlzIG5vcm1hdGl2ZSwgQ0RETCBvciBFbmdsaXNoIGxhbmd1YWdl IHRleHQ/IFdlIHNlZW0gdG8NCj4gaGF2ZSBhIGJpdCBvZiBhIG1peHR1cmUuIFtHUzogQ0RE TCBkZWZpbmVzIHRoZSBmb3JtYXRzLCBhbmQgRW5nbGlzaA0KPiBsYW5ndWFnZSB0ZXh0IGNv bXBsZW1lbnRzIHRoZSBmb3JtYXQgZGVmaW5pdGlvbnMuIFdoaWxlIHRoZXJlIG1heSBiZQ0K PiBhIHBvdGVudGlhbCBjb25mbGljdCwgSSBkaWRuJ3QgZmluZCBhbnkgZXhhbXBsZXMgb2Yg dGhhdC4gVGhlIG9ubHkNCj4gcGxhY2VzIHdoZXJlIEkgc2VlIGFuIG92ZXJsYXAgYXJlIHBs YWNlcyBsaWtlIHRoaXM6ICJtZXNzYWdlXzIgU0hBTEwNCj4gYmUgYSBDQk9SIFNlcXVlbmNl IChzZWUge3tDQk9SfX0pIGFzIGRlZmluZWQgYmVsb3cgfn5+fn5+fn5+fn4gQ0RETCANCj4g bWVzc2FnZV8yID0gKCBHX1lfQ0lQSEVSVEVYVF8yIDogYnN0ciwgQ19SIDogYnN0ciAvIGlu dCwgKSANCj4gfn5+fn5+fn5+fn4gIiBJbiB0aGlzIGNhc2UgdGhlIENEREwgaW5kaWNhdGVz IHRoYXQgbWVzc2FnZV8yIGlzIGENCj4gQ0RETCBncm91cCAoU2VjdGlvbiAyLjEgKC4yKSBp biBSRkMgODYxMCksIGFuZCB0aGUgRW5nbGlzaCB0ZXh0IG1ha2VzDQo+IHRoaXMgbW9yZSBz cGVjaWZjIGluIHRoYXQgdGhlIHBhcnRpY3VsYXIgZ3JvdXAgaW4gdGhpcyBjYXNlIGlzIGEg Q0JPUg0KPiBTZXF1ZW5jZS4gVW5sZXNzIHRoZXJlIGlzIGFuIGFjdHVhbCBjb25mbGljdCwg SSdtIG5vdCBzdXJlIGl0IGFkZHMgdG8NCj4gdW5kZXJzdGFuZGluZyBuZWl0aGVyIHRvIHRh bGsgYWJvdXQgYSBwb3RlbnRpYWwgbm9uLWV4aXN0aW5nDQo+IGNvbmZsaWN0cyBpbiBnZW5l cmFsIHRlcm1zLCBub3IgdG8gdGFsayBhYm91dCBDRERMIGdyb3VwcyBpbiB0aGlzDQo+IGRv Y3VtZW50LiBdDQo+IA0KPiAtIEZpZ3VyZSAyOiBJIHNlZSB3aHkgbWVzc2FnZSAyIGRvZXNu J3QgYWxzbyB1c2UgYW4gQUVBRCgpLCBidXQNCj4gcHJvYmFibHkgbm8gaGFybSB0byBzYXkg dGhhdCBtb3JlIGV4cGxpY2l0bHkgaGVyZS4gTWF5YmUgbW92aW5nIHNvbWUNCj4gb2YgdGhl IHJlbGV2YW50IHRleHQgZnJvbSBzZWN0aW9uIDggdG8gaGVyZSB3b3VsZCB3b3JrLiBbR1M6 IEdpdmluZw0KPiB0aGUgcHJlY2lzZSByZWFzb24gbWF5IGJlIHRvbyBtdWNoIGZvciBhIGNh cHRpb24sIGJ1dCBpdCBpbmNsdWRlcyBub3cNCj4gYXQgbGVhc3QgYSBoaWdoIGxldmVsIG1v dGl2YXRpb24gYW5kIHRoZSBzZWFyY2ggaXRlbSAiU0lHTUEiLiBdDQo+IA0KPiANCj4gLSBG aWd1cmUgMjogY29uc2lkZXIgc2hvd2luZyB0aGUgQUFEIGFzIGFuIGlucHV0IHRvIHRoZSBB RUFEKCkNCj4gY29uc3RydWN0IGluIHRoZSBmaWd1cmUuIFRoYXQgbWlnaHQgYmUgdG9vIGN1 bWJlcnNvbWUgb3IgaXQgbWF5IGhlbHAsDQo+IG5vdCBzdXJlLiB7R1M6IFdlIGhhdmUgY2hh bmdlZCBub3RhdGlvbiBpbiB0aGlzIGZpZ3VyZSBhIGZldyB0aW1lcw0KPiA6LSkgQUFEIHdh cyBpbmNsdWRlZCBpbiBlLmcuIFszXS4gQUFEIGlucHV0IGhhcyBzZXZlcmFsIGNvbXBvbmVu dHMgc28NCj4gZG9lcyBub3QgbWFrZSBmb3Igc2ltcGxlIGZpZ3VyZXMuIEhhcmQgdG8gZ2V0 IHJpZ2h0IGxldmVsIG9mDQo+IGluZm9ybWF0aW9uIGFuZCBrZWVwIG1lc3NhZ2UgY29udGVu dCBvbiBvbmUgbGluZS4gRnVydGhlciBzdWdnZXN0aW9ucw0KPiBhcmUgd2VsY29tZSEgfSBb M10NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zZWxh bmRlci1hY2UtY29zZS1lY2RoZS0wOQ0KPg0KPiANCj4gDQo+IC0gMy41LjEsIDMuNS4yIGFu ZCAzLjUuMzogdGhpcyBtaWdodCBiZSBzb21lIHRleHQgdG8gc2hvcnRlbiBhIGxvdCAtDQo+ IGhvdyBtdWNoIGlzIGl0IHJlYWxseSBuZWVkZWQ/IENvdWxkIGl0IGJlIGN1dCBkb3duIHRv IHRoZSBzdHVmZiB3aXRoDQo+IDIxMTkgdGVybXMgYW5kIGEgYml0IG1vcmU/IChJJ2Qga2Vl cCB0aGUgZXhhbXBsZXMgdGhvdWdoLikgW0dTOg0KPiBTZWN0aW9uIDMuNSBpcyA2IHBhZ2Vz IGxvbmcsIHNvLCB5ZXMgdGhlcmUgaXMgYSBwb3RlbnRpYWwgdG8NCj4gc2hvcnRlbmluZy4g KE5vdCB0aGF0IHdlIGhhdmVuJ3QgcmVzdHJ1Y3R1cmVkIGl0IGJlZm9yZSA7LSkgTGV0J3MN Cj4gaGF2ZSBhbm90aGVyIGxvb2ssIEkgbWFkZSBpdCBhIHNlcGFyYXRlIGlzc3VlLCAjMjEy Ll0NCj4gDQo+IC0gMy42OiBkb2VzIEVESE9DICpyZWFsbHkqIHN1cHBvcnQgaGFzaCBiYXNl ZCBzaWdzPyBXaGF0J2QgYmUgdGhlDQo+IGNvbnNlcXVlbmNlIGZvciBFREhPQyBvZiB1c2lu ZyBhIHByaXZhdGUga2V5IHRvbyBtYW55IHRpbWVzIG9yIGxvc3MNCj4gb2Ygc3RhdGU/ICAo QXJlIHlvdSBtaXNzaW5nIGEgcmVmZXJlbmNlIHRvIHJmYzg3NzggdGhlcmUgdG9vIG9yIGlz DQo+IG9uZSBlbWJlZGRlZCBpbiBDT1NFIHN0dWZmIHNvbWV3aGVyZT8pIFtHUzogSW4gcHJp bmNpcGxlLCB5ZXMsIHdpdGggYQ0KPiBwcml2YXRlIGNpcGhlciBzdWl0ZSwgdXNpbmcgYWxn b3JpdGhtcyBhcyBkZWZpbmVkIGluIENPU0UsIHdoaWNoDQo+IHNob3VsZCBoYXZlIHRoZSBy ZWxldmFudCByZWZlcmVuY2VzLiBUaGUgc2FtZSB3b3VsZCBnbyBmb3IsIGUuZy4sDQo+IFJT QS4gQnV0IHNpbmNlIHRoaXMgaXMgbm90IGEgbWFpbiB1c2UgY2FzZSBJIHJlbW92ZWQgdGhp cyBleGFtcGxlDQo+IGZyb20gdGhlIG1haW4gdGV4dCBvbiBjaXBoZXIgc3VpdGVzIGluIHNl Y3Rpb24gMy42IGFuZCBqdXN0IGxlZnQgdGhlDQo+IG5vdGUgaW4gdGhlIFBRQyBjb25zaWRl cmF0aW9ucyBzZWN0aW9uIDguNC4gXQ0KPiANCj4gLSA0LjE6IEJlIGdvb2QgdG8gY2xhcmlm eSB0aGF0IHRoZSBQUktfPGZvbz4gbGFiZWxzIGluIDQuMS54IGFyZQ0KPiBiYXNpY2FsbHkg bG9jYWwga2V5IG5hbWVzLiAoU2FtZSBmb3Igb3RoZXJzIGluIDQuMi4pIFtHUzogSSBkaWRu J3QNCj4gZ2V0IHRoaXMgY29tbWVudC4gSSBhc3N1bWUgImxhYmVsIiBoZXJlIGRvZXMgbm90 IHJlZmVyIHRvIHRoZSAnbGFiZWwNCj4gcGFydCBvZiB0aGUgaW5mbyBkYXRhIHN0cnVjdHVy ZSwgc2luY2UgUFJLXzxmb28+IGlzIG5vdCBpbmNsdWRlZCBpbg0KPiBhbnkgbGFiZWwuIERp ZCB5b3Ugd2FudCB0aGUgdGV4dCB0byBiZSBleHBsaWNpdCB0aGF0IHRoZSBkaWZmZXJlbnQN Cj4gUFJLXzxmb28+IGFyZSBuYW1lcyBvZiBwc2V1ZG8tcmFuZG9tIGtleXM/IChJIGFkZGVk IHRoaXMuKSBdDQo+IA0KPiANCj4gLSA0LjEuMi8zOiBZb3UgbmVlZCB0byBkZWZpbmUgUiBh bmQgSSBpbiBlYWNoIG9mIHRoZXNlIGFzIChJIGd1ZXNzKQ0KPiB0aGUgc3RhdGljIERIIHNl Y3JldCBhbmQgbm90IGFzIHRoZSBpZGVudGl0aWVzIG9mIHRoZSBpbml0aWF0b3IgYW5kDQo+ IHJlY2lwaWVudCB3aGljaCB3ZXJlIChJIHRob3VnaHQpIHRoZSBwcmV2aW91cyB1c2VzIG9m IEkgYW5kIFIuIE1pZ2h0DQo+IGJlIGJldHRlciB0byB1c2UgZGlmZmVyZW50IG5hbWVzIHRo b3VnaC4gW0dTOiBZb3UgYXJlIHJpZ2h0IHRoYXQgSQ0KPiBhbmQgUiBhcmUgYWxzbyB1c2Vk IGZvciBzb21ldGhpbmcgZWxzZSwgYnV0IG5vdCBhcyBpZGVudGl0aWVzIG9mIEkNCj4gYW5k IFIsIHJhdGhlciBhcyBhYmJyZXZpYXRpb24vc2hvcnRoYW5kIGZvciAiSW5pdGlhdG9yIiBh bmQNCj4gIlJlc3BvbmRlciIsIHJlc3BlY3RpdmVseS4gV2UgdGhvdWdodCBpdCB3YXMgT0sg dG8gb3ZlcmxvYWQgSSBhbmQgUg0KPiBvbiB0aGlzIHBvaW50IHNpbmNlIHRoZXJlIHNob3Vs ZCBiZSB2ZXJ5IHNtYWxsIHJpc2sgb2YgY29uZnVzaW9uLiAoSQ0KPiB3b3VsZG4ndCBrbm93 IGhvdyB0byBjYWxjdWxhdGUgYW4gRUNESCBzaGFyZWQgc2VjcmV0IGZyb20gYSBwdWJsaWMN Cj4ga2V5IGFuZCBhIHB1YmxpYyBmaXhlZCB0ZXh0IHN0cmluZy4pIEkgYW5kIFIgaW4gdGhl IHNlbnNlIHVzZWQgaW4NCj4gNC4xLjIvMyBpcyBkZWZpbmVkIGluIDMuNS4yLCAgSSBhZGRl ZCBhIHJlbWluZGVyIGFib3V0IHRoYXQgaW4NCj4gNC4xLjIvMyB3aXRoIHJlZmVyZW5jZS4g XQ0KPiANCj4gLSA1LjIuMjogV2hhdCBkb2VzICJ0cnVuY2F0ZWQgYWZ0ZXIgdGhlIGNpcGhl ciBzdWl0ZSBzZWxlY3RlZCBmb3INCj4gdGhpcyBzZXNzaW9uIiBtZWFuPyAoQWxzbyBiZSBn b29kIHRvIHNheSBvcmRlciBvZiBwcmVmZXJlbmNlIG1lYW5zDQo+IGZpcnN0IGluIG5ldHdv cmsgYnl0ZSBvcmRlciBpcyBtb3N0LXByZWZlcnJlZC4pIEknbSBhbHNvIHB1enpsZWQgYnkN Cj4gImJ1dCBhbGwgY2lwaGVyIHN1aXRlcyB3aGljaCBhcmUgbW9yZSBwcmVmZXJyZWQgdGhh biB0aGUgc2VsZWN0ZWQNCj4gY2lwaGVyIHN1aXRlIGluIHRoZSBsaXN0IE1VU1QgYmUgaW5j bHVkZWQgaW4gU1VJVEVTX0kuIiBbR1M6IEkgbWFkZQ0KPiBzb21lIHVwZGF0ZXMgdG8gdGhl IHRleHQsIGhhdmUgYSBsb29rIGFuZCBzZWUgaWYgaXQgcmVhZHMgYmV0dGVyOiANCj4gaHR0 cHM6Ly9naXRodWIuY29tL2xha2Utd2cvZWRob2MvcHVsbC8yMTEvY29tbWl0cy9hNzJiYWQy YSBJIHdvbmRlcg0KPiBpZiB0aGUgZmlyc3QgcGFydCBjaGFuZ2VkIG5lZWRzIGEgZGlmZmVy ZW50IHN0cnVjdHVyZSwgaGVyZSBpcyBhDQo+IHBvdGVudGlhbCBjaGFuZ2Ugd2hpY2ggSSBk aWRuJ3QgbWFrZSwgZG8geW91IHRoaW5rIEkgc2hvdWxkPyBPTEQgKg0KPiBTVUlURVNfSSAt IGFycmF5IG9mIGNpcGhlciBzdWl0ZXMgd2hpY2ggdGhlIEluaXRpYXRvciBzdXBwb3J0cyBp bg0KPiBvcmRlciBvZiBwcmVmZXJlbmNlLCBzdGFydGluZyB3aXRoIHRoZSBtb3N0IHByZWZl cnJlZCBhbmQgZW5kaW5nIHdpdGgNCj4gdGhlIGNpcGhlciBzdWl0ZSBzZWxlY3RlZCBmb3Ig dGhpcyBzZXNzaW9uLiBJZiB0aGUgbW9zdCBwcmVmZXJyZWQNCj4gY2lwaGVyIHN1aXRlIGlz IHNlbGVjdGVkIHRoZW4gU1VJVEVTX0kgaXMgZW5jb2RlZCBhcyB0aGF0IGNpcGhlcg0KPiBz dWl0ZSwgaS5lLiwgYXMgYW4gaW50LiBUaGUgcHJvY2Vzc2luZyBzdGVwcyBhcmUgZGV0YWls ZWQgYmVsb3cgYW5kDQo+IGluIHt7d3Jvbmctc2VsZWN0ZWR9fS4gQUxURVJOQVRJVkUgKiBT VUlURVNfSSAtIGFycmF5IG9mIGNpcGhlcg0KPiBzdWl0ZXMgY29tcGx5aW5nIHdpdGggdGhl IGZvbGxvd2luZyBjb25kaXRpb25zIChwcm9jZXNzaW5nIHN0ZXBzIGFyZQ0KPiBkZXRhaWxl ZCBpbiB7e2luaXQtcHJvYy1tc2cxfX0gYW5kIHt7d3Jvbmctc2VsZWN0ZWR9fSk6ICogQWxs IGNpcGhlcg0KPiBzdWl0ZXMgaW4gU1VJVEVTX0kgYXJlIHN1cHBvcnRlZCBieSBJICogVGhl IGNpcGhlciBzdWl0ZXMgaW4gU1VJVEVTX0kNCj4gYXJlIGxpc3RlZCBpbiBvcmRlciBvZiBw cmVmZXJlbmNlIGJ5IEksIGkuZS4sIHRoZSBmaXJzdCBpbiBuZXR3b3JrDQo+IGJ5dGUgb3Jk ZXIgaXMgbW9zdCBwcmVmZXJyZWQsIGV0Yy4gKiBUaGUgbGFzdCBjaXBoZXIgc3VpdGUgaW4N Cj4gU1VJVEVTX0kgaXMgc2VsZWN0ZWQgYnkgSSB0byBiZSB1c2VkIGluIHRoaXMgRURIT0Mg c2Vzc2lvbiAqIElmIHRoZQ0KPiBtb3N0IHByZWZlcnJlZCBjaXBoZXIgc3VpdGUgY29pbmNp ZGVzIHdpdGggdGhlIHNlbGVjdGVkIGNpcGhlciBzdWl0ZQ0KPiAoaS5lLiBmaXJzdCBjaXBo ZXIgc3VpdGUgPSBsYXN0IGNpcGhlciBzdWl0ZSBpbiBTVUlURVNfSSkgdGhlbg0KPiBTVUlU RVNfSSBpcyBlbmNvZGVkIGFzIHRoYXQgY2lwaGVyIHN1aXRlLCBpLmUuLCBhcyBhbiBpbnQg aW5zdGVhZCBvZg0KPiBhbiBhcnJheS4gXQ0KPiANCj4gLSA1LjMuMjogVGhpcyBzZWVtcyB0 byBiZSB0aGUgZmlyc3Qgb2NjdXJyZW5jZSBvZiB0aGUgIjw8Li4+PiINCj4gc3ltYm9saXNt LiBBIGZvcndhcmQgcmVmIHRvIEMuMSB3b3VsZCBiZSBnb29kLg0KPiANCj4gDQo+IFtHUzog RG9uZV0NCj4gDQo+IA0KPiAtIDUuMy4zOiBpcyBpdCBvayB0byBwYXNzIEVBRF8yIHRvIHRo ZSBhcHBsaWNhdGlvbiBiZWZvcmUgY2hlY2tpbmcNCj4gYXV0aGVudGljYXRpb24/DQo+IA0K PiANCj4gW0dTOiBHb29kIHF1ZXN0aW9uLiBJZiBFQURfMiBpbmRlZWQgY29udGFpbnMgZXh0 ZXJuYWwgYXV0aG9yaXphdGlvbg0KPiBkYXRhIChlLmcuIGluZm9ybWF0aW9uIGFib3V0IGlk ZW50aXR5IG9mIGludGVuZGVkIGVuZHBvaW50KSwgdGhlbg0KPiBFQURfMiBuZWVkcyB0byBi ZSBwcm9jZXNzZWQgYmVmb3JlIHlvdSBjYW4gdmVyaWZ5IHRoZSBpZGVudGl0eSBvZiB0aGUN Cj4gb3RoZXIgZW5kcG9pbnQgYW5kIHRoZSBpbnRlZ3JpdHkgb2YgdGhlIG1lc3NhZ2UuIEJ1 dCBpZiB3ZSBsb29rIGF0DQo+IEVBRF8zLCB0aGUgc2FtZSB0aGluZ3MgYXBwbHksIGJ1dCB3 ZSBhbHNvIGNsYWltIHRoYXQgRUFEXzMgaXMNCj4gcHJvdGVjdGVkIGJldHdlZW4gSW5pdGlh dG9yIGFuZCBSZXNwb25kZXIsIHdoaWNoIHdpdGggdGhlIGN1cnJlbnQNCj4gb3JkZXIgb2Yg dGhpbmdzIGlzbid0IHZlcmlmaWVkIGF0IHRoZSB0aW1lIHdoZW4gRUFEIHByb2Nlc3NlZC4g SQ0KPiBhZGRlZCB0aGlzIHRvIGlzc3VlICMyMTAuIF0NCj4gDQo+IC0gc2VjdGlvbiA2OiBJ IGZvdW5kIHRoaXMgdi4gaGFyZCB0byBmb2xsb3cuIFN1c3BlY3QgYSByZS13cml0ZSBmb3IN Cj4gY2xhcml0eSB3b3VsZCBiZSBnb29kLiBbR1NdIFRoYW5rcyBmb3Igc2hhcmluZy4gQ291 bGQgeW91IGJlIGEgbGl0dGxlDQo+IGJpdCBtb3JlIHNwZWNpZmMgd2hhdCBpcyBoYXJkIHRv IGZvbGxvdz8gSXMgYSkgdGhlIGdlbmVyYWwgZXJyb3INCj4gaGFuZGxpbmcsIGIpIHRoZSBm b3JtYXQgb2YgdGhlIGVycm9yIG1lc3NhZ2UsIGMpIHRoZSBjdXJyZW50bHkNCj4gZGVmaW5l ZCBlcnJvciBjb2RlcyBvciBob3cgdGhleSBhcmUgdXNlZCwgZCkgc3BlY2lmaWNhbGx5IHRo ZSBjaXBoZXINCj4gc3VpdGUgbmVnb3RhdGlvbiAsIGUpIGFsbCBhYm92ZSwgb3Igc29tZXRo aW5nIGVsc2U/IE5vdGU6IFN0ZWZhbiBhbHNvDQo+IGNvbW1lbnRlZCBvbiBFUlJfQ09ERSAw IGZvciB3aGljaCB3ZSBtYWRlIGFuIHVwZGF0ZSBvZiBzZWN0aW9uIDYuMQ0KPiBTdWNjZXNz LCBzZWUgUFIgIzIwMC4NCj4gDQo+IC0gc2VjdGlvbiA4OiAiRURIT0MgcHJvdmlkZXMgYSBt aW5pbXVtIG9mIDY0LWJpdCBzZWN1cml0eS4uLiIgY291bGQNCj4gZG8gd2l0aCBhIHJlZmVy ZW5jZSB0byB3aGVyZXZlciB0aGF0IGNvbmNsdXNpb24gaXMgZGVyaXZlZC4gQW5kDQo+IDY0 LWJpdCBzZWN1cml0eSBpc24ndCBxdWl0ZSAiaW4gbGluZSIgd2l0aCBUTFMgaXMgaXQ/IFtH UzogVGhhbmtzLA0KPiB0aGlzIHRleHQgbmVlZHMgdG8gYmUgaW1wcm92ZWQuIFRoZSBzdGF0 ZW1lbnQgdGhhdCB0aGUgTUFDIG11c3QgYmUgYXQNCj4gbGVhc3QgOCBieXRlcyBpcyBhIGNo YW5nZSBhbHJlYWR5IGluY2x1ZGVkIGluIG1hc3RlciBicmFuY2ggcG9zdCAtMTIsDQo+IGJ1 dCB0aGUgc2VjdXJpdHkgbGV2ZWwgaXMgYWxzbyBkZXBlbmRlbnQgb24gd2hhdCBhbGdvcml0 aG0gaXMgdXNlZC4NCj4gV2UgcmVtb3ZlZCAiVGhpcyBpcyBpbiBsaW5lIHdpdGggSVBzZWMs IFRMUywgYW5kIENPU0UuIiBhbmQgd2UgYWRkZWQNCj4gdGhpcyB0byBpc3N1ZSAjMjAxLl0N Cj4gDQo+IA0KPiAtIDguNzogc3RhdGluZyB0aGF0IGEgInRydWx5IHJhbmRvbSBzZWVkIE1V U1QiIGJlIHByb3ZpZGVkIGlzbid0IGENCj4gc2Vuc2libGUgdXNlIG9mIDIxMTksIGFuZCBp c24ndCBlbnRpcmVseSB1bmRlciB0aGUgY29udHJvbCBvZiBhbg0KPiBpbXBsZW1lbnRlciAo bWF5YmUgdGhlIHNlY3Rpb24gdGl0bGUgY291bGQgYmUgcmUtdGhvdWdodD8pLg0KPiANCj4g DQo+IFtHUzogUmlnaHQsIGhlcmUgaXMgYSBwcm9wb3NlZCB1cGRhdGU6IE9MRCBJZiBubyB0 cnVlIHJhbmRvbSBudW1iZXINCj4gZ2VuZXJhdG9yIGlzIGF2YWlsYWJsZSwgYSB0cnVseSBy YW5kb20gc2VlZCBNVVNUIGJlIHByb3ZpZGVkIGZyb20gYW4NCj4gZXh0ZXJuYWwgc291cmNl IGFuZCB1c2VkIHdpdGggYSBjcnlwdG9ncmFwaGljYWxseSBzZWN1cmUgcHNldWRvcmFuZG9t DQo+IG51bWJlciBnZW5lcmF0b3IuIE5FVyBJZiBubyB0cnVlIHJhbmRvbSBudW1iZXIgZ2Vu ZXJhdG9yIGlzDQo+IGF2YWlsYWJsZSwgYSByYW5kb20gc2VlZCBtdXN0IGJlIHByb3ZpZGVk IGZyb20gYW4gZXh0ZXJuYWwgc291cmNlIGFuZA0KPiB1c2VkIHdpdGggYSBjcnlwdG9ncmFw aGljYWxseSBzZWN1cmUgcHNldWRvcmFuZG9tIG51bWJlciBnZW5lcmF0b3IuIA0KPiBBYm91 dCB0aGUgc2VjdGlvbiB0aXRsZSwgdGhpcyBpcyBhIHN1YnNlY3Rpb24gb2YgdGhlIHNlY3Vy aXR5DQo+IGNvbnNpZGVyYXRpb25zIGFuZCB0aGUgY29udGVudCBkb2VzIGhhdmUgcmVsZXZh bmNlIHdoZW4gZGVjaWRpbmcNCj4gYWJvdXQgaW1wbGVtZW50YXRpb25zLCB3aGF0IHdvdWxk IHlvdSBwcm9wb3NlIGluc3RlYWQ/IF0NCj4gDQo+IC0gOC43IChvciBzb21ld2hlcmUpOiBp ZiBzb21lIHJhbmRvbSB2YWx1ZXMgYXJlIHZpc2libGUgKGNvbm5lY3Rpb24NCj4gaWRlbnRp ZmllcnM/KSB0aGVuIGl0IGNhbiBtYWtlIHNlbnNlIHRvIGRlcml2ZSB0aG9zZSBmcm9tIGEg ZGlmZmVyZW50DQo+IHJhbmRvbSBzdHJlYW0gY29tcGFyZWQgdG8gdGhhdCB1c2VkIGZvciBy YW5kb21seSBwaWNraW5nIHNlY3JldHMuDQo+IFRoYXQgd2F5IHRoZSBwdWJsaWNseSB2aXNp YmxlIHJhbmRvbSBudW1iZXJzIGFyZSBsZXNzIGxpa2VseSB0byBsZWFrIA0KPiBpbmZvcm1h dGlvbiBhYm91dCB0aGUgc3RhdGUgb2YgdGhlIFBSTkcgdXNlZCBmb3Igc2VjcmV0cy4gQ291 bGQgYmUNCj4gd29ydGggYSBtZW50aW9uLiBbR1M6IEdvb2QgcG9pbnQuIE5ldyBpc3N1ZSAj MjE0Ll0NCj4gDQo+IA0KPiAtIDguNzogZGlzY2FyZGluZyBhIG1lc3NhZ2VfMSBiZWNhdXNl IG9mIEdfWCBjb2xsaXNpb24vcmVmbGVjdGlvbg0KPiBzaG91bGQgYWxzbyBiZSBzdGF0ZWQg ZWFybGllciAtIGl0IGNvdWxkIHZlcnkgZWFzaWx5IGJlIG1pc3NlZCBoZXJlLg0KPiANCj4g DQo+IFtHUzogQWdyZWUuIFdlIHNob3VsZCBhZGQgaW50byB0aGUgcHJvY2Vzc2luZyBvZiBt ZXNzYWdlXzEuIFRoaXMNCj4gcG9pbnQgaXMgYWRkZWQgdG8gaXNzdWUgIzIwMS5dDQo+IA0K PiANCj4gLSA4Ljc6IFRFRSA9PiAiY2Fubm90IiBiZSB0YW1wZXJlZCBpcyBhIGxpdHRsZSBv cHRpbWlzdGljIElNTy4ge0dTOg0KPiBBZ3JlZSwgdGhpcyBpcyB0YWtlbiBmcm9tIHRoZSBh YnN0cmFjdCBvZiBbNF06ICJBIFRydXN0ZWQgRXhlY3V0aW9uDQo+IEVudmlyb25tZW50IChU RUUpIGlzIGFuIGVudmlyb25tZW50IHRoYXQgZW5mb3JjZXMgdGhhdCBhbnkgY29kZQ0KPiB3 aXRoaW4gdGhhdCBlbnZpcm9ubWVudCBjYW5ub3QgYmUgdGFtcGVyZWQgd2l0aCwgYW5kIHRo YXQgYW55IGRhdGENCj4gdXNlZCBieSBzdWNoIGNvZGUgY2Fubm90IGJlIHJlYWQgb3IgdGFt cGVyZWQgd2l0aCBieSBhbnkgY29kZSBvdXRzaWRlDQo+IHRoYXQgZW52aXJvbm1lbnQuIg0K PiANCj4gWzRdDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi10ZWVwLWFyY2hpdGVjdHVyZS0xNQ0KPg0KPiANClByb3Bvc2VkIGNoYW5nZToN Cj4gT0xEIFRoZSB1c2Ugb2YgYSBURUUgZW5mb3JjZXMgdGhhdCBjb2RlIHdpdGhpbiB0aGF0 IGVudmlyb25tZW50DQo+IGNhbm5vdCBiZSB0YW1wZXJlZCB3aXRoLCBhbmQgdGhhdCBhbnkg ZGF0YSB1c2VkIGJ5IHN1Y2ggY29kZSBjYW5ub3QNCj4gYmUgcmVhZCBvciB0YW1wZXJlZCB3 aXRoIGJ5IGNvZGUgb3V0c2lkZSB0aGF0IGVudmlyb25tZW50LiBORVcgVGhlDQo+IHVzZSBv ZiBhIFRFRSBhaW1zIGF0IHByZXZlbnRpbmcgY29kZSB3aXRoaW4gdGhhdCBlbnZpcm9ubWVu dCB0byBiZQ0KPiB0YW1wZXJlZCB3aXRoLCBhbmQgcHJldmVudGluZyBkYXRhIHVzZWQgYnkg c3VjaCBjb2RlIHRvIGJlIHJlYWQgb3INCj4gdGFtcGVyZWQgd2l0aCBieSBjb2RlIG91dHNp ZGUgdGhhdCBlbnZpcm9ubWVudC4gfQ0KPiANCj4gLSA5LjEwOiBUaGUgd2VsbC1rbm93biBV UkkgaXMgbm90IG1lbnRpb25lZCBhdCBhbGwgaW4gdGhlIGJvZHkgb2YgdGhlDQo+IHNwZWMg YnV0IG9ubHkgaGVyZSBhbmQgdGhlbiBpbiBhbiBhcHBlbmRpeC4gQSBmb3J3YXJkIHJlZiB0 byBBLjMgZnJvbQ0KPiA5LjEwIGlzIHByb2JhYmx5IGVub3VnaCB0byBmaXguIFRoZSBzYW1l IG1heSBhcHBseSB0byBvdGhlciBJQU5BDQo+IHJlZ2lzdHJhdGlvbnMgSSBndWVzcy4gW0dT OiBEb25lXQ0KPiANCj4gDQo+IC0gMTAuMTogYXJlIHdlIGNvbmZpZGVudCB0aGF0IGFsbCB0 aGUgbm9ybWF0aXZlIEktRHMgd2lsbCBiZWNvbWUgUkZDcw0KPiBpbiBhIHN1ZmZpY2llbnRs eSB0aW1lbHkgbWFubmVyPyBJJ3ZlIG5vIHNwZWNpZmljIHJlYXNvbiB0byB0aGluaw0KPiB0 aGV5IHdvbid0LCBhbmQgdGhleSdyZSBhbGwgZmFyIGFsb25nIHRoZSBwcm9jZXNzLCBidXQg c29tZXRpbWVzDQo+IHRyYW5zaXRpdmUgZGVwZW5kZW5jaWVzIGNhbiBjYXVzZSBhIGxvdCBv ZiBkZWxheS4gIChWZXJ5IHNhZGx5LCB3ZQ0KPiBjYW4ndCBqdXN0IGFzayBKaW0gYWJvdXQg dGhpcy4pDQo+IA0KPiANCj4gW0dTOiBXZSB0aGluayBzby4gVGhvc2Ugd2hpY2ggYXJlIG5v dCBSRkNzIHdvdWxkIHByb2JhYmx5IGJlIE9LIGFzDQo+IGluZm9ybWF0aXZlIHJlZmVyZW5j ZXMuXQ0KPiANCj4gLSBBLjE6ICJieXRlIHN0cmluZyBzaGFwZWQiPyB3aGF0J3MgdGhhdCBt ZWFuPyBbR1M6IFRoZSBwYXJlbnRoZXNpcw0KPiBjb250YWluaW5nIHRoaXMgdGV4dCBpcyBy ZW1vdmVkLiBUaGUgbWVhbmluZyBpcyBob3BlZnVsbHkgZXhwbGFpbmVkDQo+IGJ5IHRoZSBl eGFtcGxlLl0NCj4gDQo+IA0KPiAtIEFwcGVuZGl4IEQ6IFBvaW50IDYgbWVudGlvbnMgYW4g RVVJLTY0LiBJJ20gbm90IGNsZWFyIGhvdyB0aGF0J2QgYmUNCj4gdXNlZCBpbiBlZGhvYy4g W0dTOiBSZWZlcmVuY2UgdG8gZXhhbXBsZSBpbiAzLjUuMyBhZGRlZC5dDQo+IA0KPiANCj4g LSBUaGUgVVJMIGZvciBTSUdNQSBjYW4gdXNlIGh0dHBzIHNvIGNoYW5nZSB0byBbMV0gWzFd DQo+IGh0dHBzOi8vd2ViZWUudGVjaG5pb24uYWMuaWwvfmh1Z28vc2lnbWEtcGRmLnBkZiBb R1M6IERvbmVdDQo+IA0KPiBHw7ZyYW4NCj4gDQo= --------------m0SRsrSyMpHbRG5GbaWajFP9 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------m0SRsrSyMpHbRG5GbaWajFP9-- --------------tgBFeII0jlFlelDtuhofaIhW-- --------------rBqricANwFTA0Xa0LFMxAC3Y Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmG4oSgFAwAAAAAACgkQWrL68XsXK+rv 5w//RY6dH1/v/pAf7F+JCPqiQf3jMEZYsW3fQTn7lTZJqBE57Gcx+FFTfFqaioB/V9VlDN9LBOLs 7vbPiPnSh+sqwhmedenDRxCmfBmjL9nq2uroeKlHpJ73S+leYV1KNHuGHeXBcjUl8fJlemNasRTv MUMJebgTa2z87OzMkPIcq3LB/S0jImJdCXRuRSVObaDEiw0ox7BodduInVcTiQakX9jiZMBEkhe7 7VJh4l07s+GQT0bSVHrW9APXGyNgnD4UjvzyajTMngotinsMxiVk+8ptXZbQm3sOqGLpEiHGP4qB J+7Du9oVI+p3Z/3cKHfgR9k11f5k0KDCVXi1c+83EPd008XjezsVIkr9mUoAXKMBc9vbyqUOqoGP Xh57GvWPxmNZvs1j4IKKBxlPyLGK5BiX8MhsOX4eoyu2OvPRVblqAvOwU4hXZYBULN7jjyXLox2g 7/3jBatER6Jdpo8PpjNUc+iELD0XNv4oB4FrKowuzMVF5vgbXtPiaOIZ6Y1iGHB+VE3bnkhXvBHC d060FGeKqf9zsghUkiZIhLq3Csm0o6dukDwK0+fCa9reUM0E8PX97hc65Xx3ksfd4SknCZCWzT3Y oUcmYgxl7BVn14fFMExEh6NxxTx3Ak+HNqlDNWDMnD995+9ZRAL8ObG2TNsqwX1ow+td/beWQitz 6UI= =QaWb -----END PGP SIGNATURE----- --------------rBqricANwFTA0Xa0LFMxAC3Y-- From nobody Tue Dec 14 06:59:01 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48963A012B for ; Tue, 14 Dec 2021 06:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 wEwlYrIZIg1u for ; Tue, 14 Dec 2021 06:58:55 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294C03A033F for ; Tue, 14 Dec 2021 06:58:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CkA+TcWtPyKyiY5jgPzX9pFkBIBN1b6ay91bdJ66N84Rmx41XB8s6vToZ+YlkJsdhPFeRmszchOZyIe6D7RzswTWoIoguAT8Ox5kI5rLFw7mjfR7sBX78fmXYWEX0rq8T829Zp/rgziM+tXdjiAC5FlTCvrBEyRdrGQbBBbT7NMiWKZhb6JSSVNXDzww6A5HGD91Xo0yJx+dMsT2KZojHX0jBqS3WiL2I2YPwlFAIEbdLxf5xDXqkRHitTB9/zXEisD6u/8E7ce0tJXVN9FYLI4P4ugy0P0PYYhkQQOu/75d/Jiqpr8pN8/yHb4C4XBcfEsHvT2p0iQctseyXUfYjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ihnDjj/WVbbfHtibQpCwa7aaQ0urwNaJnlbiuRrVdiY=; b=XNDtB4NjOqq6bhJmXJbH7L78z/q11ki8ixDbv8pgqH2+UPrbs9VeatfpJRMUHSgkcabuvGWXqF0p9uR1mBW9C38QixAzJY3JWQZMTzEPhMUEImG2Y0TM6g6Lcrrgo9zj0aSjyjod8+zZ7g8O4q6I10mnjCBzdGNjSJSy7ol5U2/RnRRkBfZSLF3bmMkJ6DEJH7wJwOhQKlVRRA3w3WqDE5//+UxhdbPQLeGQE7+OGpYZvv2d/bpOxOV5UNKc1AkmbSr7dsO57BTZTxhHP6OMQccagMUrBwbMOjqmsa6hTI4rciAxz2bRJQ6/yaYnVgznK51dk+GcFd+8B0t7lBAjtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ihnDjj/WVbbfHtibQpCwa7aaQ0urwNaJnlbiuRrVdiY=; b=MWGTto1oDs+8MsgIrrp6okNtOkxh6ZUbaRjs7XPy/0w9ge1U1EWIXr+gKaR/bx7voHtUlso2Pwmo7YCDyNkMtDATZTlvxBAjj9Ot7wgjFuiT3h76VaPF6EMCcjM3vKpuZgoJWVSSz3MMwgs393mFr3uLgHiJpgsvG8qyjnqjnuw= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM0PR07MB5377.eurprd07.prod.outlook.com (2603:10a6:208:101::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.9; Tue, 14 Dec 2021 14:58:45 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4801.014; Tue, 14 Dec 2021 14:58:45 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Stephen Farrell , "lake@ietf.org" Thread-Topic: [Lake] review of edhoc-12 Thread-Index: AQHX8PqwOuxNWrPZJUSxJAbmHh0ySA== Date: Tue, 14 Dec 2021 14:58:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 6dd4d4c5-c8ed-6c47-883f-953b56a242f2 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 026eda56-c95b-4890-0b24-08d9bf1239f4 x-ms-traffictypediagnostic: AM0PR07MB5377:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jEcu1xHP7brbFIK14R4uESD0QCm71DmU6LlopDaJNHQUlIIyrdFnpFZtDnQqPiGutySE7LNcNPHRKuLVACgSX0XsdqOSNEzV+51xHqb6BYV9NnmT6aq1laQgRU+rToS1DHdADeor5yl4nlB9BP2YEH8flsVjteS+4j4B5AoXaO8qKTIG2U92bI+4R7VVFJPYvlKzPJo50M09X/Z+3sYkVyKVKGRqijyqFa1Psb4qrT9pYjJa6kc0zITew6GY5ABf+2r/UhQcfkdtSu+ZnVE9NaBc66pcNR0Dq+T7AMRoz8WJMEV71fqexugJVCA31eR738bKniXGDpwbondAe2S0yHvWkDjQSLtINS9v/mPPT7zqXS1EpN/NQnPMAdvm+koaZEaEOxQvEI2Gktu7aOQq5xKmLYtywNRi0VtWX4OvrCmdYAgOxod3IFgdrdBPs0zYmIOeZQP/fM/6MRLbPBW+b5y+ymZsRxF5XS8n2h3oh0p+ysX36GEK/vRxP6uneEfE5jBHPd7Lwm0ggRLL5LnsVHGXzx3oyNHV3+beVr7qpIXBSxZNWSL4tvbhjUhZmid83tEaX3R5PaNJF50ahSwDswOb+EHfQUym06tSP5TZMEMcTVKdz+6aQhGZZLyL9LWFHzO4Q00K1q49VfAeDhz+rw4uK+DYyagCzFHv5/EdocNRmC+vM8wJnq5TpFLRifRz3/r3paNYOGHvL4T3ApPSAY1Ci3tcEVJ5yGPTsoi3axp7jxRyoe7G6j/5+fRQnF+YcAmJtc9Xepi5uhH9Ip/e5Jd0bawtT9l08lPJPdkYsKuLKnf2fpISy1SiBr3CIc+xBdynCC3BnG7MG2YNegvb87iDFoLVAgqCV+Ra8pAPnEnL8E+YnJTYO6lMrPtDUZEk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(66446008)(55016003)(66476007)(508600001)(76116006)(296002)(6506007)(33656002)(64756008)(53546011)(52536014)(66946007)(2906002)(66574015)(9686003)(30864003)(8676002)(5660300002)(122000001)(8936002)(966005)(316002)(71200400001)(110136005)(26005)(38070700005)(186003)(38100700002)(83380400001)(86362001)(82960400001)(7696005)(91956017); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?jYfxyrs+H4CiFtGm6CnW6nF/A8/3WNCxk605bY7A9Zuw1DOwJkpyymhhim?= =?iso-8859-1?Q?PGWpOu5+gTbWAsqmeuOtzCFpMb/3UWu9YL1ggZlHgSvqOwbIGKxJAEAbNj?= =?iso-8859-1?Q?y1BYrMfotNWIrS1ogkIZmc7HfzNphhbnX0a80E0S08REPtpf89quAX67pN?= =?iso-8859-1?Q?tm64sTXnIWFeBI9UyNImCp7oXw1KBlxjrqWHj7536QtevX37gCClOiUILP?= =?iso-8859-1?Q?qGI+LyBwTCImL6KPz5gjXVfJxlry+l70AKFK1EMBanWZL8sm2UMAjkxwYn?= =?iso-8859-1?Q?SgR/bDxFq3YVj4Knyq7gx6EscOQYrWJbrUcptQx4Wsiv+0ZSF24h0OXceQ?= =?iso-8859-1?Q?1w0srgRcX7kkJCYADnobXLUI4CmW1s6+O8hucpxevC2x2FElRhvaS/NRZy?= =?iso-8859-1?Q?I6Vuhs8CufixPzwEglDivD+hZ+kEy03LUZKX9ubBwmQHl2wCAKkKDtHsE/?= =?iso-8859-1?Q?oONIfg70auckgZldCnCDY+tOb8RDSHnSWm2rxY3YTab+6W0NJGvlt3RrVw?= =?iso-8859-1?Q?GD4ZMKQ65DO5bFTvBEzxhxWr5aCr6XMLvpZCRmFhMyi1z7LMbMCsQ9GP07?= =?iso-8859-1?Q?pNuIgLRQLBQ9eI46ZmL3sa8KZbFRHkKAqx+tZUEHjYmfzKSnBqCUIWkXXC?= =?iso-8859-1?Q?ieGbN9/jTDq5cNcOWaxbr79/6Yt+MnRPx03zb2CVZy0OfOReLvBgRjtTR7?= =?iso-8859-1?Q?b9OcjnxKQHD6yiGONuA/F7Bo6fJHK23lmoq4SlY9QH/zLeMKm1OPibmiup?= =?iso-8859-1?Q?+f8z4hdinJXz7LI9LZ7cJQsDdmPvSHHwvswKyT9H/TwH0tAK7PDDElzvAt?= =?iso-8859-1?Q?oY+sNS54RhPM8UovgsOYxSZCnodOCLX7IotCuyqpsR3uMzaUSHMs6MbeCK?= =?iso-8859-1?Q?BLa9gytydgXxHobpENdPUDqyhU/2YzoD+myghyXWeIwFuPs738AOwdIwMi?= =?iso-8859-1?Q?SfpS8w3yLTVIHo7b7zHnn/lEYfcg5XguaIz0xpoN7plnQea1oREci7rr4R?= =?iso-8859-1?Q?EVFFvctwPu9QU410KYo9xzNzkBCjFO0L0ot8Y/kGqaEn4wCAxO4rJF0gw0?= =?iso-8859-1?Q?CM01iHoZ3c+csjaZQc+qhrj9TrKFAGaGc6kEpGVgyJG3Yrx2/l3UNOAYTc?= =?iso-8859-1?Q?bgwpKuRBJhVlAA8FrzMAqfwuisYNCfaT2bMzVWudVlmC+QkLP6wjXWUB5E?= =?iso-8859-1?Q?dnNPBYJ+pq7WQ/rNyUFtCq7za8UbsFkv0l0pyHuGiQchhvgC5Gv5Gl8LQp?= =?iso-8859-1?Q?5XAvjcTIlfTJUrNlzV1gLopOVavClyHXR191Cm4wNlIlq+Ve81dBVTQf45?= =?iso-8859-1?Q?ozxojNguDXZ91QukashovOpQwHJEOJMb5l64y1otnDaCtef+Fl6LDmW35O?= =?iso-8859-1?Q?gYpFzH1KVfq33DN7E0z4NvhuApLfIJJmdCc9wYLjmLgqJkTeDOEgJtAclb?= =?iso-8859-1?Q?JVqH6ukQs1nvjOegMq4EIvFKHdFD+ANQvw0+KIjCFhlIjYpJ6AvovdHJJJ?= =?iso-8859-1?Q?f67g4dXPbiXGK2s+0ysriMhSHeIUkAlQ/nkQKKlatPnt39uhkYxHsuSYt0?= =?iso-8859-1?Q?yR3Hbbq2bSEgxLY+mOqwslDhlAPrOhIArx4zixUQrkJfyfGihNa68B+J7b?= =?iso-8859-1?Q?3Ffqd5zcrexVnA7VOB/FxpL6sfo8FIoiIY91bJhYEEocfrphIRd24GQOCu?= =?iso-8859-1?Q?CrBZP2YCscUkWE6Nb0RoW1rkkiNx9YbS4gTUBlnynhFLpxDHQTV+2FqnLX?= =?iso-8859-1?Q?zxJg=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 026eda56-c95b-4890-0b24-08d9bf1239f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2021 14:58:45.1309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TGsecroTwS1CNOBZ6ZMhNDOin9B6cEaEiZJvGz/ggw4aiHOT5FvASO5LH18NUdZnI8DylkOIzxeJr3yQ9DKs89q5KlMo5G86eMEdDpXAi6w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5377 Archived-At: Subject: Re: [Lake] review of edhoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 14:59:01 -0000 Hi, =0A= =0A= > I'll go over this later but do you prefer a mail thread=0A= > or discussion on the GH issue where there's one?=0A= >=0A= > Either's fine by me...=0A= =0A= In this case we went for a mail thread to allow more visibility of the disc= ussion. =0A= =0A= Thanks=0A= G=F6ran=0A= =0A= =0A= > Cheers,=0A= >=0A= > S.=0A= =0A= =0A= =0A= > =0A= =0A= > =0A= =0A= > =0A= =0A= > From: Lake on behalf of Stephen Farrell=0A= =0A= > Date: Thursday, 11 November 2021 at=0A= =0A= > 01:39 To: lake@ietf.org Subject: [Lake] review of=0A= =0A= > edhoc-12=0A= =0A= > =0A= =0A= > Hiya,=0A= =0A= > =0A= =0A= > At our last interim I also promised to review edhoc. This is my late=0A= =0A= > (apologies;-) review. This is all review by me as just another=0A= =0A= > participant, not as co-chair. (So please do feel entirely free to=0A= =0A= > ignore bits or just say no.)=0A= =0A= > =0A= =0A= > Generally, I guess I could implement from this, were I fluent in=0A= =0A= > CBOR/COSE etc, so I think it's in good shape. All but my first=0A= =0A= > comment are editorial. I assumed that we'll have others who do crypto=0A= =0A= > analysis and implementers who'll provide yet more detailed feedback=0A= =0A= > as we go, so we're not quite there yet but getting pretty close IMO. =0A= =0A= > Good job!=0A= =0A= > =0A= =0A= > Cheers, S.=0A= =0A= > =0A= =0A= > =0A= =0A= > - Connection identifiers (which can be byte-strings) are sent in=0A= =0A= > clear which could enable various network observer attacks for=0A= =0A= > protocols that later send values obviously derived from connection=0A= =0A= > IDs in clear. (I see from A.3 that one main use case does expose=0A= =0A= > these values anyway.). To given an example of how this could be=0A= =0A= > concerning, if some proxy (that just muxes packets) sits between I=0A= =0A= > and R then those cleartext identifiers could allow an observer on=0A= =0A= > that link to more easily do traffic analysis of a specific =0A= =0A= > initiator's traffic. Was any consideration given to deriving such=0A= =0A= > identifiers in a less obvious manner? I'm not claiming that that'd be=0A= =0A= > a great improvement, just asking. {GS: John provided a response in=0A= =0A= > github issue #202 (second post on the issue). The discussion also=0A= =0A= > continues on the future-OSCORE-update repo [1]. Here is my attempt to=0A= =0A= > summarize the topic: 1. Connection identifiers are selected in EDHOC=0A= =0A= > and may be used with EDHOC (as in A.3) or in OSCORE (as=0A= =0A= > Sender/Recipient IDs). 2. The selection of connection IDs allows very=0A= =0A= > short locally unique identifiers. Derived stochastically unique=0A= =0A= > connection IDs would be much longer. 3. Connection IDs, either when=0A= =0A= > used as in A.3 or in OSCORE, work as key identifiers to facilitate=0A= =0A= > retrieval of the security context used to decrypt the message and=0A= =0A= > therefore need to be in plain text when used for this purpose. 4.=0A= =0A= > Connection IDs can become more difficult to trace by negotiating=0A= =0A= > multiple connection IDs for one security context and/or by updating=0A= =0A= > the identities in ways that does not reveal the binding in plain=0A= =0A= > text. OSCORE is not using multi-path and therefore we don't=A0 need=0A= =0A= > multiple connection IDs like e.g. in QUIC. The update of identities=0A= =0A= > is proposed to be included in Key Update for OSCORE (KUDOS, [2])=0A= =0A= > instead of in EDHOC because: a. KUDOS assumes an existing OSCORE=0A= =0A= > security context which can be used to encrypt the first message, and=0A= =0A= > b. although it would be possible to link different messages of a=0A= =0A= > single EDHOC key exchange to the same endpoints performing A.3, the=0A= =0A= > main privacy implication is most likely on the application protocol. =0A= =0A= > With this in mind we propose to not change how connection IDs are=0A= =0A= > established and used in EDHOC, but we should make a security=0A= =0A= > consideration about this for which we opened a separate issue #213. =0A= =0A= > Is this sufficient? [1] Potential things to add to future update =B7=0A= =0A= > Issue #263 =B7 core-wg/oscore =B7=0A= =0A= > GitHub [2]=0A= =0A= > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445= 555731-c589ab9ddcc753fd&q=3D1&e=3Df1d0e121-1c0d-422b-8b1b-ca672d8c8a74&u=3D= https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-oscore-key-updat= e%2F =0A= =0A= > (Note also issue/PR #188/189 about padding of plaintext, the lenght=0A= =0A= > of which also can be used to identify an endpoint.) }=0A= =0A= > =0A= =0A= > =0A= =0A= > Editorial:=0A= =0A= > =0A= =0A= > - 80 pages is still big, I understand its hard to delete stuff but=0A= =0A= > hope we keep trying:-) [GS: Yes. There are things we can do, e.g. as=0A= =0A= > you point out in sections 1.2 (gone in PR #211) and 3.5, and avoid=0A= =0A= > repetition of key derivation in sections 4 and 5. But there is also a=0A= =0A= > limit to what is worth the effort, and sometimes readability is=0A= =0A= > improved by somewhat overlapping text although different in=0A= =0A= > structure. We are now at 40 pages excluding security considerations /=0A= =0A= > IANA / refs and appendices -=A0 how long should an AKE be? (As a=0A= =0A= > comparison, when I did my masters prof. Gabriel Barton told me that a=0A= =0A= > master thesis is 10 pages long, anything else goes into appendices=0A= =0A= > :-) ]=0A= =0A= > =0A= =0A= > - 1.1, CWT, CSS and C509 could do with expansion here on 1st use.=0A= =0A= > (Perversely, X.509 is probably sufficiently well known and disliked=0A= =0A= > to not need such:-) That might also make the text before (or caption=0A= =0A= > of) Figure 1 easier to read. [GS: Done]=0A= =0A= > =0A= =0A= > - section 1.2: last para - this is repetitive, suggest making these=0A= =0A= > points just once [GS: Content of 1.2 now merged into with 1.1 and=0A= =0A= > shortened.]=0A= =0A= > =0A= =0A= > (Aside on figures/captions: I always find it a useful exercise to=0A= =0A= > ensure that a figure+caption can, by itself, make a meaningful slide=0A= =0A= > to present with no additions. And then I remove most text that's=0A= =0A= > already in the caption from elsewhere in the document. Might be worth=0A= =0A= > a try.) [GS: I sympathize with this and gave it a try but had some=0A= =0A= > problems in practice. The explanation of the content in Figure 1 is=0A= =0A= > already 7 lines of compact text with expanded abbreviations and=0A= =0A= > references which I think better stay immediately above the figure=0A= =0A= > than in the caption. The terminology in Figure 2 is explaned in 10=0A= =0A= > lines of text which is better structured as currently with bullets=0A= =0A= > rather than running text in a caption. Figure 3 includes 10 types of=0A= =0A= > protocol elements/primitives which again would make the caption=0A= =0A= > unwieldly. While this principle was difficult to apply in general, it=0A= =0A= > can make sense to expand the captions in Figures 8 and 9 to provide=0A= =0A= > more text about the cipher suite negotiation so I tried there. I also=0A= =0A= > made a consistency check of the figures harmonizing capitalization=0A= =0A= > and minor updates (except Figure 4 which I already worked on in=0A= =0A= > another PR, to avoid merge conflicts). ]=0A= =0A= > =0A= =0A= > =0A= =0A= > - Figure 1: I don't get how the "Figure 1 shows..." sentence results=0A= =0A= > in those example message sizes. I'm not doubting the numbers, but the=0A= =0A= > text could be improved (maybe, as suggested above via caption text.) =0A= =0A= > [GS: The reference in the preceding sentence also applies here, we=0A= =0A= > added that reference again.]=0A= =0A= > =0A= =0A= > - 1.4: are "EDHOC authenticated with digital signatures" and "EDHOC=0A= =0A= > authenticated with signature keys" different things? If not, using=0A= =0A= > one term is likely better. If so, using terms that are more clearly=0A= =0A= > different would be good. [GS: Replaced "digital signature" with=0A= =0A= > "signature keys" consistently.]=0A= =0A= > =0A= =0A= > - 1.5: which is normative, CDDL or English language text? We seem to=0A= =0A= > have a bit of a mixture. [GS: CDDL defines the formats, and English=0A= =0A= > language text complements the format definitions. While there may be=0A= =0A= > a potential conflict, I didn't find any examples of that. The only=0A= =0A= > places where I see an overlap are places like this: "message_2 SHALL=0A= =0A= > be a CBOR Sequence (see {{CBOR}}) as defined below ~~~~~~~~~~~ CDDL =0A= =0A= > message_2 =3D ( G_Y_CIPHERTEXT_2 : bstr, C_R : bstr / int, ) =0A= =0A= > ~~~~~~~~~~~ " In this case the CDDL indicates that message_2 is a=0A= =0A= > CDDL group (Section 2.1 (.2) in RFC 8610), and the English text makes=0A= =0A= > this more specifc in that the particular group in this case is a CBOR=0A= =0A= > Sequence. Unless there is an actual conflict, I'm not sure it adds to=0A= =0A= > understanding neither to talk about a potential non-existing=0A= =0A= > conflicts in general terms, nor to talk about CDDL groups in this=0A= =0A= > document. ]=0A= =0A= > =0A= =0A= > - Figure 2: I see why message 2 doesn't also use an AEAD(), but=0A= =0A= > probably no harm to say that more explicitly here. Maybe moving some=0A= =0A= > of the relevant text from section 8 to here would work. [GS: Giving=0A= =0A= > the precise reason may be too much for a caption, but it includes now=0A= =0A= > at least a high level motivation and the search item "SIGMA". ]=0A= =0A= > =0A= =0A= > =0A= =0A= > - Figure 2: consider showing the AAD as an input to the AEAD()=0A= =0A= > construct in the figure. That might be too cumbersome or it may help,=0A= =0A= > not sure. {GS: We have changed notation in this figure a few times=0A= =0A= > :-) AAD was included in e.g. [3]. AAD input has several components so=0A= =0A= > does not make for simple figures. Hard to get right level of=0A= =0A= > information and keep message content on one line. Further suggestions=0A= =0A= > are welcome! } [3]=0A= =0A= > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445= 555731-c91bc00ab62f9db5&q=3D1&e=3Df1d0e121-1c0d-422b-8b1b-ca672d8c8a74&u=3D= https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-selander-ace-cose-e= cdhe-09=0A= =0A= >=0A= =0A= > =0A= =0A= > =0A= =0A= > - 3.5.1, 3.5.2 and 3.5.3: this might be some text to shorten a lot -=0A= =0A= > how much is it really needed? Could it be cut down to the stuff with=0A= =0A= > 2119 terms and a bit more? (I'd keep the examples though.) [GS:=0A= =0A= > Section 3.5 is 6 pages long, so, yes there is a potential to=0A= =0A= > shortening. (Not that we haven't restructured it before ;-) Let's=0A= =0A= > have another look, I made it a separate issue, #212.]=0A= =0A= > =0A= =0A= > - 3.6: does EDHOC *really* support hash based sigs? What'd be the=0A= =0A= > consequence for EDHOC of using a private key too many times or loss=0A= =0A= > of state?=A0 (Are you missing a reference to rfc8778 there too or is=0A= =0A= > one embedded in COSE stuff somewhere?) [GS: In principle, yes, with a=0A= =0A= > private cipher suite, using algorithms as defined in COSE, which=0A= =0A= > should have the relevant references. The same would go for, e.g.,=0A= =0A= > RSA. But since this is not a main use case I removed this example=0A= =0A= > from the main text on cipher suites in section 3.6 and just left the=0A= =0A= > note in the PQC considerations section 8.4. ]=0A= =0A= > =0A= =0A= > - 4.1: Be good to clarify that the PRK_ labels in 4.1.x are=0A= =0A= > basically local key names. (Same for others in 4.2.) [GS: I didn't=0A= =0A= > get this comment. I assume "label" here does not refer to the 'label=0A= =0A= > part of the info data structure, since PRK_ is not included in=0A= =0A= > any label. Did you want the text to be explicit that the different=0A= =0A= > PRK_ are names of pseudo-random keys? (I added this.) ]=0A= =0A= > =0A= =0A= > =0A= =0A= > - 4.1.2/3: You need to define R and I in each of these as (I guess)=0A= =0A= > the static DH secret and not as the identities of the initiator and=0A= =0A= > recipient which were (I thought) the previous uses of I and R. Might=0A= =0A= > be better to use different names though. [GS: You are right that I=0A= =0A= > and R are also used for something else, but not as identities of I=0A= =0A= > and R, rather as abbreviation/shorthand for "Initiator" and=0A= =0A= > "Responder", respectively. We thought it was OK to overload I and R=0A= =0A= > on this point since there should be very small risk of confusion. (I=0A= =0A= > wouldn't know how to calculate an ECDH shared secret from a public=0A= =0A= > key and a public fixed text string.) I and R in the sense used in=0A= =0A= > 4.1.2/3 is defined in 3.5.2,=A0 I added a reminder about that in=0A= =0A= > 4.1.2/3 with reference. ]=0A= =0A= > =0A= =0A= > - 5.2.2: What does "truncated after the cipher suite selected for=0A= =0A= > this session" mean? (Also be good to say order of preference means=0A= =0A= > first in network byte order is most-preferred.) I'm also puzzled by=0A= =0A= > "but all cipher suites which are more preferred than the selected=0A= =0A= > cipher suite in the list MUST be included in SUITES_I." [GS: I made=0A= =0A= > some updates to the text, have a look and see if it reads better: =0A= =0A= > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445= 555731-f9b2427a5945f1a1&q=3D1&e=3Df1d0e121-1c0d-422b-8b1b-ca672d8c8a74&u=3D= https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fpull%2F211%2Fcommits%2Fa72bad2= a I wonder=0A= =0A= > if the first part changed needs a different structure, here is a=0A= =0A= > potential change which I didn't make, do you think I should? OLD *=0A= =0A= > SUITES_I - array of cipher suites which the Initiator supports in=0A= =0A= > order of preference, starting with the most preferred and ending with=0A= =0A= > the cipher suite selected for this session. If the most preferred=0A= =0A= > cipher suite is selected then SUITES_I is encoded as that cipher=0A= =0A= > suite, i.e., as an int. The processing steps are detailed below and=0A= =0A= > in {{wrong-selected}}. ALTERNATIVE * SUITES_I - array of cipher=0A= =0A= > suites complying with the following conditions (processing steps are=0A= =0A= > detailed in {{init-proc-msg1}} and {{wrong-selected}}): * All cipher=0A= =0A= > suites in SUITES_I are supported by I * The cipher suites in SUITES_I=0A= =0A= > are listed in order of preference by I, i.e., the first in network=0A= =0A= > byte order is most preferred, etc. * The last cipher suite in=0A= =0A= > SUITES_I is selected by I to be used in this EDHOC session * If the=0A= =0A= > most preferred cipher suite coincides with the selected cipher suite=0A= =0A= > (i.e. first cipher suite =3D last cipher suite in SUITES_I) then=0A= =0A= > SUITES_I is encoded as that cipher suite, i.e., as an int instead of=0A= =0A= > an array. ]=0A= =0A= > =0A= =0A= > - 5.3.2: This seems to be the first occurrence of the "<<..>>"=0A= =0A= > symbolism. A forward ref to C.1 would be good.=0A= =0A= > =0A= =0A= > =0A= =0A= > [GS: Done]=0A= =0A= > =0A= =0A= > =0A= =0A= > - 5.3.3: is it ok to pass EAD_2 to the application before checking=0A= =0A= > authentication?=0A= =0A= > =0A= =0A= > =0A= =0A= > [GS: Good question. If EAD_2 indeed contains external authorization=0A= =0A= > data (e.g. information about identity of intended endpoint), then=0A= =0A= > EAD_2 needs to be processed before you can verify the identity of the=0A= =0A= > other endpoint and the integrity of the message. But if we look at=0A= =0A= > EAD_3, the same things apply, but we also claim that EAD_3 is=0A= =0A= > protected between Initiator and Responder, which with the current=0A= =0A= > order of things isn't verified at the time when EAD processed. I=0A= =0A= > added this to issue #210. ]=0A= =0A= > =0A= =0A= > - section 6: I found this v. hard to follow. Suspect a re-write for=0A= =0A= > clarity would be good. [GS] Thanks for sharing. Could you be a little=0A= =0A= > bit more specifc what is hard to follow? Is a) the general error=0A= =0A= > handling, b) the format of the error message, c) the currently=0A= =0A= > defined error codes or how they are used, d) specifically the cipher=0A= =0A= > suite negotation , e) all above, or something else? Note: Stefan also=0A= =0A= > commented on ERR_CODE 0 for which we made an update of section 6.1=0A= =0A= > Success, see PR #200.=0A= =0A= > =0A= =0A= > - section 8: "EDHOC provides a minimum of 64-bit security..." could=0A= =0A= > do with a reference to wherever that conclusion is derived. And=0A= =0A= > 64-bit security isn't quite "in line" with TLS is it? [GS: Thanks,=0A= =0A= > this text needs to be improved. The statement that the MAC must be at=0A= =0A= > least 8 bytes is a change already included in master branch post -12,=0A= =0A= > but the security level is also dependent on what algorithm is used.=0A= =0A= > We removed "This is in line with IPsec, TLS, and COSE." and we added=0A= =0A= > this to issue #201.]=0A= =0A= > =0A= =0A= > =0A= =0A= > - 8.7: stating that a "truly random seed MUST" be provided isn't a=0A= =0A= > sensible use of 2119, and isn't entirely under the control of an=0A= =0A= > implementer (maybe the section title could be re-thought?).=0A= =0A= > =0A= =0A= > =0A= =0A= > [GS: Right, here is a proposed update: OLD If no true random number=0A= =0A= > generator is available, a truly random seed MUST be provided from an=0A= =0A= > external source and used with a cryptographically secure pseudorandom=0A= =0A= > number generator. NEW If no true random number generator is=0A= =0A= > available, a random seed must be provided from an external source and=0A= =0A= > used with a cryptographically secure pseudorandom number generator. =0A= =0A= > About the section title, this is a subsection of the security=0A= =0A= > considerations and the content does have relevance when deciding=0A= =0A= > about implementations, what would you propose instead? ]=0A= =0A= > =0A= =0A= > - 8.7 (or somewhere): if some random values are visible (connection=0A= =0A= > identifiers?) then it can make sense to derive those from a different=0A= =0A= > random stream compared to that used for randomly picking secrets.=0A= =0A= > That way the publicly visible random numbers are less likely to leak =0A= =0A= > information about the state of the PRNG used for secrets. Could be=0A= =0A= > worth a mention. [GS: Good point. New issue #214.]=0A= =0A= > =0A= =0A= > =0A= =0A= > - 8.7: discarding a message_1 because of G_X collision/reflection=0A= =0A= > should also be stated earlier - it could very easily be missed here.=0A= =0A= > =0A= =0A= > =0A= =0A= > [GS: Agree. We should add into the processing of message_1. This=0A= =0A= > point is added to issue #201.]=0A= =0A= > =0A= =0A= > =0A= =0A= > - 8.7: TEE =3D> "cannot" be tampered is a little optimistic IMO. {GS:=0A= =0A= > Agree, this is taken from the abstract of [4]: "A Trusted Execution=0A= =0A= > Environment (TEE) is an environment that enforces that any code=0A= =0A= > within that environment cannot be tampered with, and that any data=0A= =0A= > used by such code cannot be read or tampered with by any code outside=0A= =0A= > that environment."=0A= =0A= > =0A= =0A= > [4]=0A= =0A= > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445= 555731-5a3bbcb6fcd7b5fb&q=3D1&e=3Df1d0e121-1c0d-422b-8b1b-ca672d8c8a74&u=3D= https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-architect= ure-15=0A= =0A= >=0A= =0A= > =0A= =0A= Proposed change:=0A= =0A= > OLD The use of a TEE enforces that code within that environment=0A= =0A= > cannot be tampered with, and that any data used by such code cannot=0A= =0A= > be read or tampered with by code outside that environment. NEW The=0A= =0A= > use of a TEE aims at preventing code within that environment to be=0A= =0A= > tampered with, and preventing data used by such code to be read or=0A= =0A= > tampered with by code outside that environment. }=0A= =0A= > =0A= =0A= > - 9.10: The well-known URI is not mentioned at all in the body of the=0A= =0A= > spec but only here and then in an appendix. A forward ref to A.3 from=0A= =0A= > 9.10 is probably enough to fix. The same may apply to other IANA=0A= =0A= > registrations I guess. [GS: Done]=0A= =0A= > =0A= =0A= > =0A= =0A= > - 10.1: are we confident that all the normative I-Ds will become RFCs=0A= =0A= > in a sufficiently timely manner? I've no specific reason to think=0A= =0A= > they won't, and they're all far along the process, but sometimes=0A= =0A= > transitive dependencies can cause a lot of delay.=A0 (Very sadly, we=0A= =0A= > can't just ask Jim about this.)=0A= =0A= > =0A= =0A= > =0A= =0A= > [GS: We think so. Those which are not RFCs would probably be OK as=0A= =0A= > informative references.]=0A= =0A= > =0A= =0A= > - A.1: "byte string shaped"? what's that mean? [GS: The parenthesis=0A= =0A= > containing this text is removed. The meaning is hopefully explained=0A= =0A= > by the example.]=0A= =0A= > =0A= =0A= > =0A= =0A= > - Appendix D: Point 6 mentions an EUI-64. I'm not clear how that'd be=0A= =0A= > used in edhoc. [GS: Reference to example in 3.5.3 added.]=0A= =0A= > =0A= =0A= > =0A= =0A= > - The URL for SIGMA can use https so change to [1] [1]=0A= =0A= > https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445= 555731-8ca11aa0b522bd93&q=3D1&e=3Df1d0e121-1c0d-422b-8b1b-ca672d8c8a74&u=3D= https%3A%2F%2Fwebee.technion.ac.il%2F%7Ehugo%2Fsigma-pdf.pdf [GS: Done]=0A= =0A= > =0A= =0A= > G=F6ran=0A= =0A= > =0A= =0A= =0A= =0A= From nobody Tue Dec 14 08:34:23 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E203A0E38 for ; Tue, 14 Dec 2021 08:34:19 -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, FREEMAIL_FROM=0.001, 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=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 jmgkKtyZ3LIH for ; Tue, 14 Dec 2021 08:34:14 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 E1F3F3A0791 for ; Tue, 14 Dec 2021 08:34:13 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id t13so35795797uad.9 for ; Tue, 14 Dec 2021 08:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=44BMDr06nXj4lCDxie+n0h3n3lS9LP/WCz3KuvSuxMA=; b=QbPs9fuY+pleKNAQbv6gVg/XDNm/Wk0My7FHNtRznzkHvcAQatQw3b8GekmkndW7eW qYO7B1M2cAmgPicM54RqYBP1FYFX1WkjJGvGZvuqBtKTrUG463qWu7wB+ZXqWYu17DUV n9rf4a6YnSEc5wrqmixNL/pWP5YfqS65sKkrHFNcwnjnJTVI3Eg3N6MjxboMMc6poH5n qMc2kdjdM+G4BVGJmHPK7k8JgDcryBMZrNhp2C/gLI/b7VccOtiWtRNTY8eW9LXGwztF V4sZ3aZk4dQEMG4kb574nAkUAfonbGs9JYf4sHLwcgpZGhwZn/MBfcL1cEa1TMlhkVKM 4zfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=44BMDr06nXj4lCDxie+n0h3n3lS9LP/WCz3KuvSuxMA=; b=etwEgashZihr0qVY/liS4awk73nwBfk4i0+r2wmKScWJFu0lgVxR8E+ycAukbmNVx5 VWZZ1ZcCS6w9+8djhX7YVDLyEvglaey3vgl9rHP3Ncs0O28fBD3nYUJ6EHk6cBr9R6R0 K5dn+b5ZbktQ0oVducgU1TNOLmqetvOm8Oxvojb51vd4kstfjdletUDI0RjUFPAljGio +L+aqjWHe+M2Ob+clCaugcwtPTw6iUA/BOiFZhqQDpGWCJWC/lCdqXiq7I4DlhbQD0pw Ty+tLZGgF5Bmm7FZoWaPTSIJ7ySTgfzToVKLDbEdMW3ejproSU1vpTnwdTB2LbnzT7Nk yzDg== X-Gm-Message-State: AOAM531IbppSpQqaMFjUnptsMfitPPUn68G3Ouij1gi0k2ctiI2wY/sa CN9kqLl3cKPO3FMgEWHe4t5lmyoJ5lw1sqmMdXw2OeMp X-Google-Smtp-Source: ABdhPJzxCMrkL74gq3Q//WPYFCwgCg5mWnxs238ITPRlAOZqL0XTX8ixL9NEHKhOr10HEDsSHzYz9OuWkqhWvEj0Tyg= X-Received: by 2002:ab0:4405:: with SMTP id m5mr6518674uam.11.1639499650720; Tue, 14 Dec 2021 08:34:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kathleen Moriarty Date: Tue, 14 Dec 2021 11:33:34 -0500 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: "lake@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004a67ca05d31dc2b6" Archived-At: Subject: Re: [Lake] EDHOC Review X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 16:34:20 -0000 --0000000000004a67ca05d31dc2b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Goran! Congratulations, it's great to see the work at this point. Best regards, Kathleen On Tue, Dec 14, 2021 at 8:52 AM G=C3=B6ran Selander wrote: > Hi Kathleen, > > Thanks for the review. It is recorded as github issue #196 and the update= s > have already been integrated in the master branch: > https://github.com/lake-wg/edhoc/commit/a4b182a > except for the last comment: > > > IANA Registries > > > > I see for the registries created that Expert review [RFC8126] is > required. > > What documentation is required? Is it also Specification required or is > > here other guidance for the experts when considering updates? > > I see this is discussed in 9.14, but perhaps adding specification > recommended > > in each of the places a registry is created would be helpful. > > We discussed documentation at the Oct 5 interim and the conclusion was > that expert review would be sufficient as a general scheme for these > registers (see also github issue #167 [0] which was therefore closed). Bu= t > your comment made us take another look at the registers. In particular fo= r > the EDHOC method type registry it does really make sense to require a > specification. Therefore we reopened the issue and will revisit the topic > on the interim meeting tomorrow. > > [0] https://github.com/lake-wg/edhoc/issues/167 > > > Thanks! > G=C3=B6ran > ________________________________________ > From: Lake on behalf of Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> > Sent: Friday, November 5, 2021 8:36 PM > To: lake@ietf.org > Subject: [Lake] EDHOC Review > > Greetings! > > I had offered to contribute a review at the last interim and am very glad > to see this document come to this part of the process after the large > efforts that went into its development and demonstrating it's value for u= se > with constrained devices. > > Here are a few nits to consider: > > > Section 1.1 Nit > > OLD: > > EDHOC does > > currently not support pre-shared key (PSK) authentication as > > authentication with static Diffie-Hellman public keys by reference > > produces equally small message sizes but with much simpler key > > distribution and identity protection. > > > NEW: > > EDHOC does not > > currently support pre-shared key (PSK) authentication as > > authentication with static Diffie-Hellman public keys by reference > > produces equally small message sizes but with much simpler key > > distribution and identity protection. > > > Section 1.2: > > > The intent of the following sentence is to convey that these libraries ar= e > already in use for OSCORE, but the wording of the following sentence coul= d > be a bit more clear: > > OLD: > > By reusing existing libraries, the additional code size can be kept very > > low. > > PROPOSED: > > In using libraries already in the code base for OSCORE, the additional > code size can be kept very > > low. > > > > Section 3.8 > > S/enrolment/enrollment/ > > > Section 4.3 > > S/kan/can/ > > In the following sentence: in most encryption algorithms the same key kan > be > > > IANA Registries > > > I see for the registries created that Expert review [RFC8126] is required= . > What documentation is required? Is it also Specification required or is > there other guidance for the experts when considering updates? I see this > is discussed in 9.14, but perhaps adding specification recommended in eac= h > of the places a registry is created would be helpful. > > > Thank you for your work on this document and protocol! > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --0000000000004a67ca05d31dc2b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Goran!=C2=A0 Congratulations, it's great to= see the work at this point.

Best regards,
Kat= hleen

On Tue, Dec 14, 2021 at 8:52 AM G=C3=B6ran Selander <goran.selander@ericsson.com>= wrote:
Hi Kathl= een,

Thanks for the review. It is recorded as github issue #196 and the updates = have already been integrated in the master branch:
https://github.com/lake-wg/edhoc/commit/a4b182a except for the last comment:

> IANA Registries
>
> I see for the registries created that Expert review [RFC8126] is requi= red.
> What documentation is required? Is it also Specification required or i= s
> here other guidance for the experts when considering updates?
> I see this is discussed in 9.14, but perhaps adding specification reco= mmended
> in each of the places a registry is created would be helpful.

We discussed documentation at the Oct 5 interim=C2=A0 and the conclusion wa= s that expert review would be sufficient as a general scheme for these regi= sters (see also github issue #167 [0] which was therefore closed). But your= comment made us take another look at the registers. In particular for the = EDHOC method type registry it does really make sense to require a specifica= tion. Therefore we reopened the issue and will revisit the topic on the int= erim meeting tomorrow.

[0] https://github.com/lake-wg/edhoc/issues/167


Thanks!
G=C3=B6ran
________________________________________
From: Lake <l= ake-bounces@ietf.org> on behalf of Kathleen Moriarty <kathleen.moriart= y.ietf@gmail.com>
Sent: Friday, November 5, 2021 8:36 PM
To: lake@ietf.org Subject: [Lake] EDHOC Review

Greetings!

I had offered to contribute a review at the last interim and am very glad t= o see this document come to this part of the process after the large effort= s that went into its development and demonstrating it's value for use w= ith constrained devices.

Here are a few nits to consider:


Section 1.1 Nit

OLD:

EDHOC does

=C2=A0 =C2=A0currently not support pre-shared key (PSK) authentication as
=C2=A0 =C2=A0authentication with static Diffie-Hellman public keys by refer= ence

=C2=A0 =C2=A0produces equally small message sizes but with much simpler key=

=C2=A0 =C2=A0distribution and identity protection.


NEW:

EDHOC does not

=C2=A0 =C2=A0currently support pre-shared key (PSK) authentication as

=C2=A0 =C2=A0authentication with static Diffie-Hellman public keys by refer= ence

=C2=A0 =C2=A0produces equally small message sizes but with much simpler key=

=C2=A0 =C2=A0distribution and identity protection.


Section 1.2:


The intent of the following sentence is to convey that these libraries are = already in use for OSCORE, but the wording of the following sentence could = be a bit more clear:

OLD:

By reusing existing libraries, the additional code size can be kept very
=C2=A0 =C2=A0low.

PROPOSED:

In using libraries already in the code base for OSCORE, the additional code= size can be kept very

=C2=A0 =C2=A0low.



Section 3.8

S/enrolment/enrollment/


Section 4.3

S/kan/can/

In the following sentence: in most encryption algorithms the same key kan b= e


IANA Registries


I see for the registries created that Expert review [RFC8126] is required. = What documentation is required? Is it also Specification required or is the= re other guidance for the experts when considering updates? I see this is d= iscussed in 9.14, but perhaps adding specification recommended in each of t= he places a registry is created would be helpful.


Thank you for your work on this document and protocol!

--

Best regards,
Kathleen


--

Best regards,
Kathleen
--0000000000004a67ca05d31dc2b6-- From nobody Tue Dec 14 22:35:13 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B483A05A0 for ; Tue, 14 Dec 2021 22:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWt7TjmaFPVB for ; Tue, 14 Dec 2021 22:35:05 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 44A2E3A040C for ; Tue, 14 Dec 2021 22:35:05 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id o17so20869492qtk.1 for ; Tue, 14 Dec 2021 22:35:05 -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=m9Z13AEPhSiGD8vgCzGaAIJv+Uvzeeex6qv3IQtdS3U=; b=FIFWVk2KBFJtlp5bYVl5XIcfYkmspdLjIplqVPgnQfhNsbq4TrNMkPfTxtowzBmaSq dxBwzMyKlq5ICO0KHAh/ZRp08iWosjkaOrlS+6GNQ+nX1tO6A4ieUsTMihB0jNGPGmNK biwBvxTGGrOUFjuBzoS1IcbNGALa4W/rhvBcE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=m9Z13AEPhSiGD8vgCzGaAIJv+Uvzeeex6qv3IQtdS3U=; b=0zD8/uXIFZtok/TWi0k10Wqa7S2og9aNiMmNM0k/8scdAQ/Azl4bUnpoZqBrKcyqlk do3/1eBZvAIQaedikmZEB2Z+5iu4O0ey1siLIHiuFSAy8fhr2sxsLb9RK7iDICfS+p1a 4s6l4OzxkiNweGm/MVrUadH96xz/pjGGlBDRNObCvkXFXb1niHH9sEXhjBuO3zrjeR/s 0xnR5iWZVKu2nf5DVKV6GLH3CNwLBacFbLuU3ZKp19ftSo7IBQcHLyD7i0E3/lcHlfVu 41z45EISXjDHCk3XZXvHjORwuyEoidZEKfxzZt3z1HN7Y288ZhcEyLtGzxfVdXGTBR3F qAdg== X-Gm-Message-State: AOAM533UTB/Lcvo2y4aglH/F5RUF+0W9KzqiLwBJUM+ggybAJJ/pb3v2 PYkf2v/wDy3Ck+99/GEEVrjEU2zQnE9WFQ== X-Google-Smtp-Source: ABdhPJy08AZavlfXwkaLsB+zQgehHRwzm1DrjjuPvJu6BZhadz1xmbeF+2nYcJSfqogiY9FGqn1dgg== X-Received: by 2002:a05:622a:11cf:: with SMTP id n15mr10250576qtk.557.1639550101926; Tue, 14 Dec 2021 22:35:01 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id w13sm619366qko.20.2021.12.14.22.35.01 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Dec 2021 22:35:01 -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 14.0 \(3654.120.0.1.13\)) Message-Id: <1B6DD418-03D8-4B78-9C26-3C821DF2DB9E@sn3rd.com> Date: Wed, 15 Dec 2021 01:35:00 -0500 To: LAKE List X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [Lake] spt review of echoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 06:35:11 -0000 Like others I agreed to review the edhoc I-D at the last meeting. I did = not have a chance to make sure that I am not repeating comments from = others. To save the WG some time, I tried to categorize these along the = lines of questions/nits where discuss might need some f2f time and nits, = I believe, can be dealt with by the authors as they see fit. Disclaimers: 0) I am not a cryptographer or security researcher. 1) It = is entirely possible I am entirely missing the plot/point.=20 Apologies: I ran out of time to submit these as Issues/PRs. I can do so = after the interim, including those that got rejected at the 12/15 = interim for posterity sake.=20 s1.2 (nit): If s1.2 is supposed to be an applicability statement in the = context of RFC 2026, can we call it that. i.e., r/Use of = EDHOC/Applicability Statement.=20 revised: And then, I see section 3.9. Maybe instead of renaming s1.2, a = forward pointer to s3.9 is all that is needed to say that an = applicability statement is required? s2, 2nd para (nit): refer to both because it=E2=80=99s (D)TLS and not = just TLS? I.e., s/(D)TLS 1.3 [RFC8446]/(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13] s2, 2nd para (nit): I think you can safely drop the 2nd reference to = IKEv2 s/like IKEv2 [RFC7296],/like IKEv2, s3.2/s3.5.2 (question): Smarter people than I have devised plans to = allow mixing of different METHODs. How does this impact the key usage = extension present in certificates? In other words, are METHODS 1 and 2 = suggesting that a DS and DH key be used together and does that violate = any kind of restrictions on the key usage settings for certificates? s3.4 (nit): Is transport of error messages, as noted by s6 (2nd para), = needed in the list. s3.5 para after the bullets (nit): I think you are trying to say the = credentials have to be the same type, i.e., you can=E2=80=99t have PGP = one one side and x.509 on the other. I am not sure that the following is = the best wording: s/Identical authentication credentials need to be established in both = endpoints to be able to verify integrity./The same type of = authentication credentials are needed baby the endpoints to be able to = verify integrity. s3.5.1, 1st para (nit): At first I thought for sure this had to be a = MUST, but it says or application so I am not sure: The EDHOC implementation or the application must enforce information = about the intended endpoint =E2=80=A6 s3.5.1 (nit): expand on first use NAI & EUI s3.5.1, 1st bullet (nit): Often we refer to this a Proof-of-Possession = so maybe you could say that: s/EDHOC provides proof that the other party possesses the private authentication key corresponding to the public authentication key in its certificate./EDHOC provides proof that the other party possesses the private authentication key corresponding to the public authentication key in its certificate, which is also known as proof-of-possesion. s3.5.1, 1st bullet (question): This seems like the =E2=80=9Cmixing=E2=80=9D= discussed in s3.2, relies on the identity provide in the certificate? The certification path provides proof that the subject of the certificate owns the public key in the certificate. s3.5.2 (question): related to comment on s3.2. s3.5.3, 2nd para (nit): Could point to RFC 3279/5480 for some key usages = for ECDSA and RFC 8410 for x25519/x448. In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement" [RFC3279][RFC8410]. s3.6 (nit): refer to both?: s/TLS 1.3 [RFC8446]/ (D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13] s3.5.3 (question): EDHOC seems to assume you only provide the reference = for the initiator's/responder=E2=80=99s. Was there any thought it to = providing references for the rest of the certification path up to but = not including the Root CA=E2=80=99s certificate? I mean technically they = can also be in there certificate provided so not necessarily needed. s3.6, CNSA ref (nit): I made a similar comment against the ZRTP spec = when they said their alg suites were compliant with Suite B =E2=80=A6 = probably best to say Suite 24 and 25 use algorithms in CNSA and leave = the word =E2=80=9Ccompatible=E2=80=9D for =E2=80=9Cthem=E2=80=9D to say. s3.8 (comment): Wow .. so you can send in the CSR in EAD, if it works = then you can use the cert in the later messages (e.g., kind of like = EAP)? Sure hope there=E2=80=99s no kind of CSR-related error. And, you = know that the CA gets to decide the name right. Sorry just trying to = digest it all. s4.3 (nit): s/kan/can s4.4/s5.1 (question): Do you need to provide advice on when to delete = the old PRK_4x3m? I.e., does the peer that sent this need to wait for = some kind of confirmation before deleting it? s5.1 (question): Is a state diagram needed? One thing people clamored = for from TLS was a state machine. Maybe a diagram isn=E2=80=99t needed = because there are so few states? s5.1 (comment, no action required): Cute. Deduplication is how to deal = with message reply ;) s5.2.1, s.5.3.1, s5.4.1, s5.5.1 (nit): is the =E2=80=9C,=E2=80=9D before = the closing bracket right? e.g., OLD: ? EAD_1 : ead, } NEW: ? EAD_1 : ead } s5.2.2 (question): If this this initiator processing section, how does = the initiator know to truncate? =E2=80=A6, truncated after the cipher suite selected for this session. s5.2.3, s5.3.3, s5.4.3, s5.5.3, last sentence (question - probably being = pedantic): If there is an error but an error message is not sent, is the = session discontinued? How does the peer know it was discontinued if an = error is not sent? s5.2.3, s5.3.3, s5.4.3, s5.5.3 (nit, which I am sure the RFC editor fix = better than I could, but I couldn=E2=80=99t help myself): Instead of the = e.g., in middle of the MAY sentence maybe: OLD: Sending error messages is essential for debugging but MAY e.g., be skipped if a session cannot be found or due to denial-of-service reasons, see Section 8.6. NEW: Sending error messages is essential for debugging but MAY be skipped if, for example, a session cannot be found or due to denial-of-service reasons, see Section 8.6. s6.1 (nit): To stop loops, should any peer that receives an ERR_CODE=3D0 = discontinue the session? I.e., is that worth stating in the I-D? s6.2 (nit): It=E2=80=99s really more =E2=80=9CFreeform=E2=80=9D than = unspecified right? I mean the string is required so it=E2=80=99s = definitely not unspecified per se. s6.3.2, 2nd to last para (nit): s/shall/SHALL s6.3.2/s5.2.1 (nit): Might be worth noting earlier that SUITES_R is not = important. Also, s5.2.1, mentioned SUITES_I, but s5.2.2 does not mention = SUITES_R. s7, last para (nit): s/To enable as much interoperability as we can reasonably achieve,/To enable as much interoperability as possible, s8 (question): Isn=E2=80=99t some kind of consideration needed to = address the use of PSKs shared by more than two? See RFC 8773 for some = considerations wrt to group key sharing and that sharing impact on = authentication. s8.3 (nit): You can informatively refer to RFC 6194 to slam the door on = SHA-1. s9 and onwaard (apologies): I ran out of steam. s? (question): Is a peer supposed to check status information for its = peer=E2=80=99s certificate/key?=20 I-D Nit complaints (not all of them because the DOWNREFs (mostly) looked = intentional): =3D=3D Missing Reference: 'RFC9052' is mentioned on line 2411, but not = defined Cheers, spt= From nobody Wed Dec 15 04:56:26 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EF3A0BB3 for ; Wed, 15 Dec 2021 04:56:23 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 GTKPyjFzSLXH for ; Wed, 15 Dec 2021 04:56:19 -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 E43583A0B75 for ; Wed, 15 Dec 2021 04:56:18 -0800 (PST) IronPort-Data: =?us-ascii?q?A9a23=3AOnSHUqoOq5kvwrxLc1BEP4FeG/xeBmI0ZxIvgKr?= =?us-ascii?q?LsJaIsI5as4F+vmQXXGyDafmCamX2etBzbIyx/RgPuJGHyYJnSAJt/nwyQiMRo?= =?us-ascii?q?6IpJ/zJdxaqZ3v6wu7rFR88sZ1GMrEsFC2FJ5Pljk/F3oPJ8D8shclkepKmULS?= =?us-ascii?q?dY3ooGFc+IMscoUkLd9AR09cAbeeRU1vlVePa+6UzCXf9s9JGGjp8B5Gr9HuDi?= =?us-ascii?q?M/PVAYw5TTSUxzkUGj2zBH5BLpHTU24wuCRroN8RoZWTM6bpF21E/+wwvsjNj+?= =?us-ascii?q?luu6TnkwiWbvOJQOKi3dQR+6rmgBGq0Te0I5narxHMgEN02/PxYgvoDlOncXYp?= =?us-ascii?q?QMBO6TImf8UFQdFGCB4PKZu+bndIHH5v9b7I0juKiK1mq4yXB5e0Yowv7wf7Xt?= =?us-ascii?q?13fgRKz0lbx2fiaSx2r3TdwXGrqzPN+HuO4kevG0lkW+cVq1jRcyZGf2Uo9RC2?= =?us-ascii?q?j4/gdpHW/DTe6IkhfNUREyoS3Vy1p0/UfrSRNuVu0Q=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AGqCTbqPcxGKk3MBcTt6jsMiBIKoaSvp037BL?= =?us-ascii?q?7SpMoHNuHfBw+/rEoB1f73/JYUgqKRIdcKG7VZVoKEm0naKdo7N+AV7IZmXbUQ?= =?us-ascii?q?WTTb2KlbGSoQHdJw=3D=3D?= X-IronPort-AV: E=Sophos; i="5.88,207,1635199200"; d="scan'208,217"; a="11113487" Received: from mobint-46-33-l42206.crnagora.net (HELO smtpclient.apple) ([46.33.202.206]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2021 13:56:17 +0100 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: multipart/alternative; boundary="Apple-Mail=_0A5DDA62-47BA-4CEC-BF8F-16FA9BC4D366" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Wed, 15 Dec 2021 13:56:15 +0100 References: <21712AC9-58F1-42C1-A366-3F35525C4542@inria.fr> To: lake@ietf.org In-Reply-To: <21712AC9-58F1-42C1-A366-3F35525C4542@inria.fr> Message-Id: <41A99A42-6F76-45AA-B280-8CD8C451F647@inria.fr> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Lake] LAKE interim Wednesday 1800 UTC X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2021 12:56:24 -0000 --Apple-Mail=_0A5DDA62-47BA-4CEC-BF8F-16FA9BC4D366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We are still looking for a volunteer note taker for today=E2=80=99s = meeting, please drop us a line at lake-chairs@ietf.org = . Mali=C5=A1a -- Mali=C5=A1a Vu=C4=8Dini=C4=87 Research Scientist, Inria Co-chair, IETF LAKE > On 13 Dec 2021, at 23:44, Mali=C5=A1a Vu=C4=8Dini=C4=87 = wrote: >=20 > All, >=20 > As a reminder, our group will be meeting this Wednesday, 15 December = 2021 at 1800 UTC. We posted the agenda and it is available at [1]. The = webex link is available at [2]. >=20 > I kindly ask the presenters to upload the slides by Wednesday noon = UTC. We will be going over the latest changes, status and the reviews of = draft-ietf-lake-edhoc and draft-ietf-lake-traces. >=20 > In case you would like to help with taking notes, please drop us an = email.=20 >=20 > Talk to you on Wednesday ! >=20 > Mali=C5=A1a and Stephen >=20 > [1] = https://datatracker.ietf.org/doc/agenda-interim-2021-lake-05-lake-01/ = > [2] = https://ietf.webex.com/ietf/j.php?MTID=3Dme537335f0364ae8993f92970a387a9c5= = >=20 > --=20 > Lake mailing list > Lake@ietf.org > https://www.ietf.org/mailman/listinfo/lake --Apple-Mail=_0A5DDA62-47BA-4CEC-BF8F-16FA9BC4D366 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = are still looking for a volunteer note taker for today=E2=80=99s = meeting, please drop us a line at lake-chairs@ietf.org.

Mali=C5=A1a
--
Mali=C5=A1a = Vu=C4=8Dini=C4=87
Research Scientist, = Inria
Co-chair, IETF LAKE

On 13 Dec 2021, at 23:44, Mali=C5=A1a Vu=C4=8Dini=C4=87 = <malisa.vucinic@inria.fr> wrote:

All,

As a = reminder, our group will be meeting this Wednesday, 15 December 2021 at = 1800 UTC. We posted the agenda and it is available at [1]. The webex = link is available at [2].

I kindly ask the = presenters to upload the slides by Wednesday noon UTC. We will be going = over the latest changes, status and the reviews of draft-ietf-lake-edhoc = and draft-ietf-lake-traces.

In case you = would like to help with taking notes, please drop us an email. 

Talk to you on Wednesday !

Mali=C5=A1a and Stephen

[1] https://datatracker.ietf.org/doc/agenda-interim-2021-lake-05-la= ke-01/
--
Lake mailing list
Lake@ietf.org
https://www.ietf.org/mailman/listinfo/lake

= --Apple-Mail=_0A5DDA62-47BA-4CEC-BF8F-16FA9BC4D366-- From nobody Thu Dec 16 00:38:35 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008DD3A109D for ; Thu, 16 Dec 2021 00:38:33 -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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 wNYAe7zHKQFy for ; Thu, 16 Dec 2021 00:38:28 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 CAE8E3A1097 for ; Thu, 16 Dec 2021 00:38:27 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4JF59Z2B9jz1yL2 for ; Thu, 16 Dec 2021 09:38:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1639643906; bh=Ku7A9RPiFtN+Lrk0DJIX+bWIHX5LI9B5zSyswxs9JVw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UyEZsX7j9SsPGjnTkYNT8PO8DgsHPwQw5nlnYxJrzzmXyYHtUsiAhp/fMUXsDLsZv EmS68p8f8i90jXwFfheuDrSdJb8jKxs9KGNWHums/wfAsrmdo01Hm7uJ3G/4YDA8xF CfUCOFytJVrUOW/w2ddwOicElxufMpn9UjmGF4D3GHAx8mEqtCmAfY4ZTmRWKmEcKJ ov10w5Z+4Q+BdUb2Y2M7fWvnun/lcqL2VbQKme+yzqcAFq3uiSe2htOfgoXRw6B9o/ z0pnrzcdJi00e4cYB0+hjCb9kH7HrUFSo99r7YhThUKgkb4hjF+LfqeMepQl5mHwyy ZWUNet7XEBqyA== From: To: LAKE List Thread-Topic: [Lake] spt review of echoc-12 Thread-Index: AQHX8X3uxF7w8Gi+BE61rcPrHjIC8Kw0yPuw Date: Thu, 16 Dec 2021 08:38:25 +0000 Message-ID: <30272_1639643906_61BAFB02_30272_304_2_d6452e85d0e643d5a0aaa541002e6ea0@orange.com> References: <1B6DD418-03D8-4B78-9C26-3C821DF2DB9E@sn3rd.com> In-Reply-To: <1B6DD418-03D8-4B78-9C26-3C821DF2DB9E@sn3rd.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2021-12-16T08:38:24Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2021-12-16T08:38:24Z msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_method: Standard msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_name: Orange_restricted_external.2 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_siteid: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_actionid: 262bc799-05a6-4d88-9f81-3eaa33ac85e7 msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0 x-originating-ip: [10.115.27.52] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Lake] spt review of echoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 08:38:33 -0000 SGVsbG8gTEFLRSwNCg0KU29ycnkgZm9yIHRoaXMgdmVyeSBsYXRlIHJlbWFyay4gQnV0IGl0IHNl ZW1zIHRoYXQgIkVkRFNBIiBpcyBub3QgdGhlIHByb3BlciB3b3JkaW5nIHRvIHVzZSBpbiB0aGUg ZHJhZnQgKGF0IGxlYXN0IGluIFNlY3Rpb24gOS4yKS4gSSBxdW90ZSB0aGUgb3JpZ2luYWwgcGFw ZXIgYnkgQmVybnN0ZWluLCBEdWlmLCBMYW5nZSwgU2Nod2FiZSBhbmQgWWFuZyBbMV06IA0KLSAi IFRoaXMgc2VjdGlvbiBzcGVjaWZpZXMgdGhlIHNpZ25hdHVyZSBzeXN0ZW0gdXNlZCBpbiB0aGlz IHBhcGVyLCBhbmQgYSBnZW5lcmFsaXplZCBzaWduYXR1cmUgc3lzdGVtIEVkRFNBIHRoYXQgY2Fu IGJlIHVzZWQgd2l0aCBvdGhlciBjaG9pY2VzIG9mIGVsbGlwdGljIGN1cnZlcy4iDQotICIgT3Vy IHJlY29tbWVuZGVkIGN1cnZlIGZvciBFZERTQSBpcyBhIHR3aXN0ZWQgRWR3YXJkcyBjdXJ2ZSBi aXJhdGlvbmFsbHkgZXF1aXZhbGVudCB0byB0aGUgY3VydmUgQ3VydmUyNTUxOSBbLi4uXSBXZSB1 c2UgdGhlIG5hbWUgRWQyNTUxOSBmb3IgRWREU0Egd2l0aCB0aGlzIHBhcnRpY3VsYXIgY2hvaWNl IG9mIGN1cnZlLiINClRoZXJlZm9yZSAiRWQyNTUxOSIgc2hvdWxkIGJlIHVzZWQgaW4gcGxhY2Ug b2YgIkVkRFNBIiAoYXQgbGVhc3QgaW4gU2VjdGlvbiA5LjIpLiANCg0KV2hhdCBkbyB5b3UgcmVj a29uPw0KDQpCZXN0IHJlZ2FyZHMNCg0KWzFdIEhpZ2gtc3BlZWQgaGlnaC1zZWN1cml0eSBzaWdu YXR1cmUsIEJlcm5zdGVpbiwgRHVpZiwgTGFuZ2UsIFNjaHdhYmUgYW5kIFlhbmcsIDIwMTEuIGh0 dHBzOi8vZWQyNTUxOS5jci55cC50by9lZDI1NTE5LTIwMTEwOTI2LnBkZg0KDQpMb8OvYyBGZXJy ZWlyYQ0KT3JhbmdlIExhYnMg4oCTIEFwcGxpZWQgQ3J5cHRvZ3JhcGh5IEdyb3VwDQorMzMgKDAp MiAzMSAxNSA5MSAyNA0KbG9pYy5mZXJyZWlyYUBvcmFuZ2UuY29tDQoNCg0KT3JhbmdlIFJlc3Ry aWN0ZWQNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBMYWtlIDxsYWtlLWJv dW5jZXNAaWV0Zi5vcmc+IERlIGxhIHBhcnQgZGUgU2VhbiBUdXJuZXINCkVudm95w6nCoDogbWVy Y3JlZGkgMTUgZMOpY2VtYnJlIDIwMjEgMDc6MzUNCsOAwqA6IExBS0UgTGlzdCA8bGFrZUBpZXRm Lm9yZz4NCk9iamV0wqA6IFtMYWtlXSBzcHQgcmV2aWV3IG9mIGVjaG9jLTEyDQoNCkxpa2Ugb3Ro ZXJzIEkgYWdyZWVkIHRvIHJldmlldyB0aGUgZWRob2MgSS1EIGF0IHRoZSBsYXN0IG1lZXRpbmcu IEkgZGlkIG5vdCBoYXZlIGEgY2hhbmNlIHRvIG1ha2Ugc3VyZSB0aGF0IEkgYW0gbm90IHJlcGVh dGluZyBjb21tZW50cyBmcm9tIG90aGVycy4gVG8gc2F2ZSB0aGUgV0cgc29tZSB0aW1lLCBJIHRy aWVkIHRvIGNhdGVnb3JpemUgdGhlc2UgYWxvbmcgdGhlIGxpbmVzIG9mIHF1ZXN0aW9ucy9uaXRz IHdoZXJlIGRpc2N1c3MgbWlnaHQgbmVlZCBzb21lIGYyZiB0aW1lIGFuZCBuaXRzLCBJIGJlbGll dmUsIGNhbiBiZSBkZWFsdCB3aXRoIGJ5IHRoZSBhdXRob3JzIGFzIHRoZXkgc2VlIGZpdC4NCg0K RGlzY2xhaW1lcnM6IDApIEkgYW0gbm90IGEgY3J5cHRvZ3JhcGhlciBvciBzZWN1cml0eSByZXNl YXJjaGVyLiAxKSBJdCBpcyBlbnRpcmVseSBwb3NzaWJsZSBJIGFtIGVudGlyZWx5IG1pc3Npbmcg dGhlIHBsb3QvcG9pbnQuIA0KDQpBcG9sb2dpZXM6IEkgcmFuIG91dCBvZiB0aW1lIHRvIHN1Ym1p dCB0aGVzZSBhcyBJc3N1ZXMvUFJzLiBJIGNhbiBkbyBzbyBhZnRlciB0aGUgaW50ZXJpbSwgaW5j bHVkaW5nIHRob3NlIHRoYXQgZ290IHJlamVjdGVkIGF0IHRoZSAxMi8xNSBpbnRlcmltIGZvciBw b3N0ZXJpdHkgc2FrZS4gDQoNCnMxLjIgKG5pdCk6IElmIHMxLjIgaXMgc3VwcG9zZWQgdG8gYmUg YW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgaW4gdGhlIGNvbnRleHQgb2YgUkZDIDIwMjYsIGNh biB3ZSBjYWxsIGl0IHRoYXQuIGkuZS4sIHIvVXNlIG9mIEVESE9DL0FwcGxpY2FiaWxpdHkgU3Rh dGVtZW50LiANCg0KcmV2aXNlZDogQW5kIHRoZW4sIEkgc2VlIHNlY3Rpb24gMy45LiBNYXliZSBp bnN0ZWFkIG9mIHJlbmFtaW5nIHMxLjIsIGEgZm9yd2FyZCBwb2ludGVyIHRvIHMzLjkgaXMgYWxs IHRoYXQgaXMgbmVlZGVkIHRvIHNheSB0aGF0IGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IGlz IHJlcXVpcmVkPw0KDQpzMiwgMm5kIHBhcmEgKG5pdCk6IHJlZmVyIHRvIGJvdGggYmVjYXVzZSBp dOKAmXMgKEQpVExTIGFuZCBub3QganVzdCBUTFM/ICBJLmUuLCBzLyhEKVRMUyAxLjMgW1JGQzg0 NDZdLyhEKVRMUyAxLjMgW1JGQzg0NDZdIFtJLUQuaWV0Zi10bHMtZHRsczEzXQ0KDQpzMiwgMm5k IHBhcmEgKG5pdCk6IEkgdGhpbmsgeW91IGNhbiBzYWZlbHkgZHJvcCB0aGUgMm5kIHJlZmVyZW5j ZSB0byBJS0V2MiBzL2xpa2UgSUtFdjIgW1JGQzcyOTZdLC9saWtlIElLRXYyLA0KDQpzMy4yL3Mz LjUuMiAocXVlc3Rpb24pOiBTbWFydGVyIHBlb3BsZSB0aGFuIEkgaGF2ZSBkZXZpc2VkIHBsYW5z IHRvIGFsbG93IG1peGluZyBvZiBkaWZmZXJlbnQgTUVUSE9Ecy4gSG93IGRvZXMgdGhpcyBpbXBh Y3QgdGhlIGtleSB1c2FnZSBleHRlbnNpb24gcHJlc2VudCBpbiBjZXJ0aWZpY2F0ZXM/IEluIG90 aGVyIHdvcmRzLCBhcmUgTUVUSE9EUyAxIGFuZCAyIHN1Z2dlc3RpbmcgdGhhdCBhIERTIGFuZCBE SCBrZXkgYmUgdXNlZCB0b2dldGhlciBhbmQgZG9lcyB0aGF0IHZpb2xhdGUgYW55IGtpbmQgb2Yg cmVzdHJpY3Rpb25zIG9uIHRoZSBrZXkgdXNhZ2Ugc2V0dGluZ3MgZm9yIGNlcnRpZmljYXRlcz8N Cg0KczMuNCAobml0KTogSXMgdHJhbnNwb3J0IG9mIGVycm9yIG1lc3NhZ2VzLCBhcyBub3RlZCBi eSBzNiAoMm5kIHBhcmEpLCBuZWVkZWQgaW4gdGhlIGxpc3QuDQoNCnMzLjUgcGFyYSBhZnRlciB0 aGUgYnVsbGV0cyAobml0KTogSSB0aGluayB5b3UgYXJlIHRyeWluZyB0byBzYXkgdGhlIGNyZWRl bnRpYWxzIGhhdmUgdG8gYmUgdGhlIHNhbWUgdHlwZSwgaS5lLiwgeW91IGNhbuKAmXQgaGF2ZSBQ R1Agb25lIG9uZSBzaWRlIGFuZCB4LjUwOSBvbiB0aGUgb3RoZXIuIEkgYW0gbm90IHN1cmUgdGhh dCB0aGUgZm9sbG93aW5nIGlzIHRoZSBiZXN0IHdvcmRpbmc6DQoNCnMvSWRlbnRpY2FsIGF1dGhl bnRpY2F0aW9uIGNyZWRlbnRpYWxzIG5lZWQgdG8gYmUgZXN0YWJsaXNoZWQgaW4gYm90aCBlbmRw b2ludHMgdG8gYmUgYWJsZSB0byB2ZXJpZnkgaW50ZWdyaXR5Li9UaGUgc2FtZSB0eXBlIG9mIGF1 dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIGFyZSBuZWVkZWQgYmFieSB0aGUgZW5kcG9pbnRzIHRv IGJlIGFibGUgdG8gdmVyaWZ5IGludGVncml0eS4NCg0KczMuNS4xLCAxc3QgcGFyYSAobml0KTog QXQgZmlyc3QgSSB0aG91Z2h0IGZvciBzdXJlIHRoaXMgaGFkIHRvIGJlIGEgTVVTVCwgYnV0IGl0 IHNheXMgb3IgYXBwbGljYXRpb24gc28gSSBhbSBub3Qgc3VyZToNCg0KVGhlIEVESE9DIGltcGxl bWVudGF0aW9uIG9yIHRoZSBhcHBsaWNhdGlvbiBtdXN0IGVuZm9yY2UgaW5mb3JtYXRpb24gYWJv dXQgdGhlIGludGVuZGVkIGVuZHBvaW50IOKApg0KDQpzMy41LjEgKG5pdCk6IGV4cGFuZCBvbiBm aXJzdCB1c2UgTkFJICYgRVVJDQoNCnMzLjUuMSwgMXN0IGJ1bGxldCAobml0KTogT2Z0ZW4gd2Ug cmVmZXIgdG8gdGhpcyBhIFByb29mLW9mLVBvc3Nlc3Npb24gc28gbWF5YmUgeW91IGNvdWxkIHNh eSB0aGF0Og0KDQpzL0VESE9DIHByb3ZpZGVzDQogICAgICBwcm9vZiB0aGF0IHRoZSBvdGhlciBw YXJ0eSBwb3NzZXNzZXMgdGhlIHByaXZhdGUgYXV0aGVudGljYXRpb24NCiAgICAgIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoZSBwdWJsaWMgYXV0aGVudGljYXRpb24ga2V5IGluIGl0cw0KICAgICAg Y2VydGlmaWNhdGUuL0VESE9DIHByb3ZpZGVzDQogICAgICBwcm9vZiB0aGF0IHRoZSBvdGhlciBw YXJ0eSBwb3NzZXNzZXMgdGhlIHByaXZhdGUgYXV0aGVudGljYXRpb24NCiAgICAgIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoZSBwdWJsaWMgYXV0aGVudGljYXRpb24ga2V5IGluIGl0cw0KICAgICAg Y2VydGlmaWNhdGUsIHdoaWNoIGlzIGFsc28ga25vd24gYXMgcHJvb2Ytb2YtcG9zc2VzaW9uLg0K DQpzMy41LjEsIDFzdCBidWxsZXQgKHF1ZXN0aW9uKTogVGhpcyBzZWVtcyBsaWtlIHRoZSDigJxt aXhpbmfigJ0gZGlzY3Vzc2VkIGluIHMzLjIsIHJlbGllcyBvbiB0aGUgaWRlbnRpdHkgcHJvdmlk ZSBpbiB0aGUgY2VydGlmaWNhdGU/DQoNCiAgICBUaGUgY2VydGlmaWNhdGlvbiBwYXRoIHByb3Zp ZGVzIHByb29mIHRoYXQgdGhlDQogICAgc3ViamVjdCBvZiB0aGUgY2VydGlmaWNhdGUgb3ducyB0 aGUgcHVibGljIGtleSBpbiB0aGUgY2VydGlmaWNhdGUuDQoNCnMzLjUuMiAocXVlc3Rpb24pOiBy ZWxhdGVkIHRvIGNvbW1lbnQgb24gczMuMi4NCg0KczMuNS4zLCAybmQgcGFyYSAobml0KTogQ291 bGQgcG9pbnQgdG8gUkZDIDMyNzkvNTQ4MCBmb3Igc29tZSBrZXkgdXNhZ2VzIGZvciBFQ0RTQSBh bmQgUkZDIDg0MTAgZm9yIHgyNTUxOS94NDQ4Lg0KDQpJbg0KICAgWC41MDkgYW5kIEM1MDkgY2Vy dGlmaWNhdGVzLCBzaWduYXR1cmUga2V5cyB0eXBpY2FsbHkgaGF2ZSBrZXkgdXNhZ2UNCiAgICJk aWdpdGFsU2lnbmF0dXJlIiBhbmQgRGlmZmllLUhlbGxtYW4gcHVibGljIGtleXMgdHlwaWNhbGx5 IGhhdmUga2V5DQogICB1c2FnZSAia2V5QWdyZWVtZW50IiBbUkZDMzI3OV1bUkZDODQxMF0uDQoN CnMzLjYgKG5pdCk6IHJlZmVyIHRvIGJvdGg/Og0Kcy9UTFMgMS4zIFtSRkM4NDQ2XS8NCihEKVRM UyAxLjMgW1JGQzg0NDZdIFtJLUQuaWV0Zi10bHMtZHRsczEzXQ0KDQpzMy41LjMgKHF1ZXN0aW9u KTogRURIT0Mgc2VlbXMgdG8gYXNzdW1lIHlvdSBvbmx5IHByb3ZpZGUgdGhlIHJlZmVyZW5jZSBm b3IgdGhlIGluaXRpYXRvcidzL3Jlc3BvbmRlcuKAmXMuIFdhcyB0aGVyZSBhbnkgdGhvdWdodCBp dCB0byBwcm92aWRpbmcgcmVmZXJlbmNlcyBmb3IgdGhlIHJlc3Qgb2YgdGhlIGNlcnRpZmljYXRp b24gcGF0aCB1cCB0byBidXQgbm90IGluY2x1ZGluZyB0aGUgUm9vdCBDQeKAmXMgY2VydGlmaWNh dGU/IEkgbWVhbiB0ZWNobmljYWxseSB0aGV5IGNhbiBhbHNvIGJlIGluIHRoZXJlIGNlcnRpZmlj YXRlIHByb3ZpZGVkIHNvIG5vdCBuZWNlc3NhcmlseSBuZWVkZWQuDQoNCnMzLjYsIENOU0EgcmVm IChuaXQpOiBJIG1hZGUgYSBzaW1pbGFyIGNvbW1lbnQgYWdhaW5zdCB0aGUgWlJUUCBzcGVjIHdo ZW4gdGhleSBzYWlkIHRoZWlyIGFsZyBzdWl0ZXMgd2VyZSBjb21wbGlhbnQgd2l0aCBTdWl0ZSBC IOKApiBwcm9iYWJseSBiZXN0IHRvIHNheSBTdWl0ZSAyNCBhbmQgMjUgdXNlIGFsZ29yaXRobXMg aW4gQ05TQSBhbmQgbGVhdmUgdGhlIHdvcmQg4oCcY29tcGF0aWJsZeKAnSBmb3Ig4oCcdGhlbeKA nSB0byBzYXkuDQoNCnMzLjggKGNvbW1lbnQpOiBXb3cgLi4gc28geW91IGNhbiBzZW5kIGluIHRo ZSBDU1IgaW4gRUFELCBpZiBpdCB3b3JrcyB0aGVuIHlvdSBjYW4gdXNlIHRoZSBjZXJ0IGluIHRo ZSBsYXRlciBtZXNzYWdlcyAoZS5nLiwga2luZCBvZiBsaWtlIEVBUCk/IFN1cmUgaG9wZSB0aGVy ZeKAmXMgbm8ga2luZCBvZiBDU1ItcmVsYXRlZCBlcnJvci4gQW5kLCB5b3Uga25vdyB0aGF0IHRo ZSBDQSBnZXRzIHRvIGRlY2lkZSB0aGUgbmFtZSByaWdodC4gU29ycnkganVzdCB0cnlpbmcgdG8g ZGlnZXN0IGl0IGFsbC4NCg0KczQuMyAobml0KTogcy9rYW4vY2FuDQoNCnM0LjQvczUuMSAocXVl c3Rpb24pOiBEbyB5b3UgbmVlZCB0byBwcm92aWRlIGFkdmljZSBvbiB3aGVuIHRvIGRlbGV0ZSB0 aGUgb2xkIFBSS180eDNtPyBJLmUuLCBkb2VzIHRoZSBwZWVyIHRoYXQgc2VudCB0aGlzIG5lZWQg dG8gd2FpdCBmb3Igc29tZSBraW5kIG9mIGNvbmZpcm1hdGlvbiBiZWZvcmUgZGVsZXRpbmcgaXQ/ DQoNCnM1LjEgKHF1ZXN0aW9uKTogSXMgYSBzdGF0ZSBkaWFncmFtIG5lZWRlZD8gT25lIHRoaW5n IHBlb3BsZSBjbGFtb3JlZCBmb3IgZnJvbSBUTFMgd2FzIGEgc3RhdGUgbWFjaGluZS4gTWF5YmUg YSBkaWFncmFtIGlzbuKAmXQgbmVlZGVkIGJlY2F1c2UgdGhlcmUgYXJlIHNvIGZldyBzdGF0ZXM/ DQoNCnM1LjEgKGNvbW1lbnQsIG5vIGFjdGlvbiByZXF1aXJlZCk6IEN1dGUuIERlZHVwbGljYXRp b24gaXMgaG93IHRvIGRlYWwgd2l0aCBtZXNzYWdlIHJlcGx5IDspDQoNCnM1LjIuMSwgcy41LjMu MSwgczUuNC4xLCBzNS41LjEgKG5pdCk6IGlzIHRoZSDigJws4oCdIGJlZm9yZSB0aGUgY2xvc2lu ZyBicmFja2V0IHJpZ2h0PyBlLmcuLA0KDQpPTEQ6DQoNCiAgICA/IEVBRF8xIDogZWFkLA0KfQ0K DQpORVc6DQoNCiAgICA/IEVBRF8xIDogZWFkDQp9DQoNCnM1LjIuMiAocXVlc3Rpb24pOiBJZiB0 aGlzIHRoaXMgaW5pdGlhdG9yIHByb2Nlc3Npbmcgc2VjdGlvbiwgaG93IGRvZXMgdGhlIGluaXRp YXRvciBrbm93IHRvIHRydW5jYXRlPw0KDQogIOKApiwgdHJ1bmNhdGVkIGFmdGVyIHRoZSBjaXBo ZXIgc3VpdGUgc2VsZWN0ZWQgZm9yIHRoaXMNCiAgc2Vzc2lvbi4NCg0KczUuMi4zLCBzNS4zLjMs IHM1LjQuMywgczUuNS4zLCBsYXN0IHNlbnRlbmNlIChxdWVzdGlvbiAtIHByb2JhYmx5IGJlaW5n IHBlZGFudGljKTogSWYgdGhlcmUgaXMgYW4gZXJyb3IgYnV0IGFuIGVycm9yIG1lc3NhZ2UgaXMg bm90IHNlbnQsIGlzIHRoZSBzZXNzaW9uIGRpc2NvbnRpbnVlZD8gSG93IGRvZXMgdGhlIHBlZXIg a25vdyBpdCB3YXMgZGlzY29udGludWVkIGlmIGFuIGVycm9yIGlzIG5vdCBzZW50Pw0KDQpzNS4y LjMsIHM1LjMuMywgczUuNC4zLCBzNS41LjMgKG5pdCwgd2hpY2ggSSBhbSBzdXJlIHRoZSBSRkMg ZWRpdG9yIGZpeCBiZXR0ZXIgdGhhbiBJIGNvdWxkLCBidXQgSSBjb3VsZG7igJl0IGhlbHAgbXlz ZWxmKTogSW5zdGVhZCBvZiB0aGUgZS5nLiwgaW4gbWlkZGxlIG9mIHRoZSBNQVkgc2VudGVuY2Ug bWF5YmU6DQoNCk9MRDoNCg0KICAgU2VuZGluZyBlcnJvcg0KICAgbWVzc2FnZXMgaXMgZXNzZW50 aWFsIGZvciBkZWJ1Z2dpbmcgYnV0IE1BWSBlLmcuLCBiZSBza2lwcGVkIGlmIGENCiAgIHNlc3Np b24gY2Fubm90IGJlIGZvdW5kIG9yIGR1ZSB0byBkZW5pYWwtb2Ytc2VydmljZSByZWFzb25zLCBz ZWUNCiAgIFNlY3Rpb24gOC42Lg0KDQpORVc6DQoNCiAgIFNlbmRpbmcgZXJyb3INCiAgIG1lc3Nh Z2VzIGlzIGVzc2VudGlhbCBmb3IgZGVidWdnaW5nIGJ1dCBNQVkgYmUgc2tpcHBlZCBpZiwgZm9y DQogICBleGFtcGxlLCBhDQogICBzZXNzaW9uIGNhbm5vdCBiZSBmb3VuZCBvciBkdWUgdG8gZGVu aWFsLW9mLXNlcnZpY2UgcmVhc29ucywgc2VlDQogICBTZWN0aW9uIDguNi4NCg0KczYuMSAobml0 KTogVG8gc3RvcCBsb29wcywgc2hvdWxkIGFueSBwZWVyIHRoYXQgcmVjZWl2ZXMgYW4gRVJSX0NP REU9MCBkaXNjb250aW51ZSB0aGUgc2Vzc2lvbj8gSS5lLiwgaXMgdGhhdCB3b3J0aCBzdGF0aW5n IGluIHRoZSBJLUQ/DQoNCnM2LjIgKG5pdCk6IEl04oCZcyByZWFsbHkgbW9yZSDigJxGcmVlZm9y beKAnSB0aGFuIHVuc3BlY2lmaWVkIHJpZ2h0PyBJIG1lYW4gdGhlIHN0cmluZyBpcyByZXF1aXJl ZCBzbyBpdOKAmXMgZGVmaW5pdGVseSBub3QgdW5zcGVjaWZpZWQgcGVyIHNlLg0KDQpzNi4zLjIs IDJuZCB0byBsYXN0IHBhcmEgKG5pdCk6IHMvc2hhbGwvU0hBTEwNCg0KczYuMy4yL3M1LjIuMSAo bml0KTogTWlnaHQgYmUgd29ydGggbm90aW5nIGVhcmxpZXIgdGhhdCBTVUlURVNfUiBpcyBub3Qg aW1wb3J0YW50LiBBbHNvLCBzNS4yLjEsIG1lbnRpb25lZCBTVUlURVNfSSwgYnV0IHM1LjIuMiBk b2VzIG5vdCBtZW50aW9uIFNVSVRFU19SLg0KDQpzNywgbGFzdCBwYXJhIChuaXQpOiBzL1RvIGVu YWJsZSBhcyBtdWNoIGludGVyb3BlcmFiaWxpdHkgYXMgd2UgY2FuDQogICByZWFzb25hYmx5IGFj aGlldmUsL1RvIGVuYWJsZSBhcyBtdWNoIGludGVyb3BlcmFiaWxpdHkgYXMgcG9zc2libGUsDQoN CnM4IChxdWVzdGlvbik6IElzbuKAmXQgc29tZSBraW5kIG9mIGNvbnNpZGVyYXRpb24gbmVlZGVk IHRvIGFkZHJlc3MgdGhlIHVzZSBvZiBQU0tzIHNoYXJlZCBieSBtb3JlIHRoYW4gdHdvPyBTZWUg UkZDIDg3NzMgZm9yIHNvbWUgY29uc2lkZXJhdGlvbnMgd3J0IHRvIGdyb3VwIGtleSBzaGFyaW5n IGFuZCB0aGF0IHNoYXJpbmcgaW1wYWN0IG9uIGF1dGhlbnRpY2F0aW9uLg0KDQpzOC4zIChuaXQp OiBZb3UgY2FuIGluZm9ybWF0aXZlbHkgcmVmZXIgdG8gUkZDIDYxOTQgdG8gc2xhbSB0aGUgZG9v ciBvbiBTSEEtMS4NCg0KczkgYW5kIG9ud2FhcmQgKGFwb2xvZ2llcyk6IEkgcmFuIG91dCBvZiBz dGVhbS4NCg0Kcz8gKHF1ZXN0aW9uKTogSXMgYSBwZWVyIHN1cHBvc2VkIHRvIGNoZWNrIHN0YXR1 cyBpbmZvcm1hdGlvbiBmb3IgaXRzIHBlZXLigJlzIGNlcnRpZmljYXRlL2tleT8gDQoNCkktRCBO aXQgY29tcGxhaW50cyAobm90IGFsbCBvZiB0aGVtIGJlY2F1c2UgdGhlIERPV05SRUZzIChtb3N0 bHkpIGxvb2tlZCBpbnRlbnRpb25hbCk6DQoNCj09IE1pc3NpbmcgUmVmZXJlbmNlOiAnUkZDOTA1 MicgaXMgbWVudGlvbmVkIG9uIGxpbmUgMjQxMSwgYnV0IG5vdCBkZWZpbmVkDQoNCkNoZWVycywN CnNwdA0KLS0NCkxha2UgbWFpbGluZyBsaXN0DQpMYWtlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xha2UNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Dec 16 01:19:37 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D5E3A117A for ; Thu, 16 Dec 2021 01:19:35 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 s4oZxGjtjktp for ; Thu, 16 Dec 2021 01:19:34 -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 D88D53A1179 for ; Thu, 16 Dec 2021 01:19:33 -0800 (PST) IronPort-Data: =?us-ascii?q?A9a23=3AfAiGv6oYYBT/MqEuoq/p6lroyYpeBmILZxIvgKr?= =?us-ascii?q?LsJaIsI5as4F+vjMYD26BOPeJa2qnLt53bN+xoRsB68KAmNM3HVNorSo9QiMRo?= =?us-ascii?q?6IpJ/zJdxaqZ3v6wu7rFR88sZ1GMrEsFC2FJ5Pljk/F3oPJ8D8shclkepKmULS?= =?us-ascii?q?dY3ooG1c+IMscoUkLd9AR09cAbeeRU1vlVePa+6UzCXf9s9JGGjp8B5Gr9HuDi?= =?us-ascii?q?M/PVAYw5TTSUxzkUGj2zBH5BLpHTU24wuCRroN8RoZWTM6bpF21E/+wwvsjNj+?= =?us-ascii?q?luu6TnkwiWbvOJQOKi3dQR+6rmgBGq0Te0I5kZbxFNRwR0mzQ2Ykvk72htrTpI?= =?us-ascii?q?estFqjFnOUGWl9GDip/O6xN0L7BO3m298KJp6HDWyG9mqwxVCnaOqVdoI6bG1p?= =?us-ascii?q?m8fUbJRgMYwyNweWsz9qGpkNE7ig4BJa6etpD4Tc5lGifVKh9Ka0vip7ivbdwt?= =?us-ascii?q?ArcTOgXdRoGW/ckVA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AwCGDEakgd1tUXJJurHB0DY/sZTXpDfIr3DAb?= =?us-ascii?q?v31ZSRFFG/FwWfrDoB17726XtN9/YhodcLy7UpVoBEmzyXcX2/hzAV7BZmbbUQ?= =?us-ascii?q?KTRelfBMnZogEIcBefygcp79YHT0EIMqyWMbEVt6vHCXGDYrIdKY68gcWVuds?= =?us-ascii?q?=3D?= X-IronPort-AV: E=Sophos;i="5.88,211,1635199200"; d="scan'208";a="291170" Received: from unknown (HELO smtpclient.apple) ([79.143.111.163]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2021 10:19:31 +0100 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Message-Id: Date: Thu, 16 Dec 2021 10:19:23 +0100 To: lake@ietf.org X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 09:19:36 -0000 All, (chair hat off) As discussed during the interim yesterday, the current text in -12 on = MTI requirements (Section 7) reads as follows: > For many constrained IoT devices it is problematic to support more > than one cipher suite. Existing devices can be expected to support > either ECDSA or EdDSA. To enable as much interoperability as we = can > reasonably achieve, less constrained devices SHOULD implement both > cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES- > CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA- > 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained > endpoints SHOULD implement cipher suite 0 or cipher suite 2. > Implementations only need to implement the algorithms needed for > their supported methods. I see two issues here: 1) imprecise language; 2) normative text that = implies interoperability only in case when both peers implement both = suites 0 and 2. When it comes to the devices and their capabilities, we have so far been = using the precisely defined terms from RFC 7228. This is not the case = here and we use terms such as =E2=80=9Cless constrained devices=E2=80=9D, = =E2=80=9Cconstrained endpoints=E2=80=9D. This is all very confusing. Why = endpoint and not device? What does =E2=80=9Cless constrained device=E2=80=9D= actually mean in terms of RFC 7228? Assuming that the =E2=80=9Cconstrained endpoint=E2=80=9D is a typo and = instead means =E2=80=9Cconstrained device=E2=80=9D, the normative = statement in this text, i.e. implementing 0 OR 2, implies that we can = achieve interoperability only in the case when both peers implement both = 0 and 2 cipher suites. Requiring the implementation of two cipher suites = on each device to achieve interoperability is far from the lightweight = aspect of LAKE, so I would like to hear what are the working group=E2=80=99= s thoughts on this. Mali=C5=A1a From nobody Thu Dec 16 01:50:52 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211423A11F8 for ; Thu, 16 Dec 2021 01:50:50 -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, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 LB2PWnDb0JwD for ; Thu, 16 Dec 2021 01:50:44 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2056.outbound.protection.outlook.com [104.47.14.56]) (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 63CE53A11F6 for ; Thu, 16 Dec 2021 01:50:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HnqUzQYfvYrcuWv0T+j4U3oq1TNfGO/IDuD45vd6TZRjDc2aOpzWiqXR3Ob8znf18cncrO3ZnZqWpHICGMiegwGRKoGss8IcxqUrqVEul1/lnH3F6s5TJmZe8if/ju9F9TypPn8hET6z05mEykaBEXUvny/I3IUpixtfHOii/xzm5dBKBEKHVVc8NRNzb1EaUIMZHLApc+NXQ8zu0rDI0/Eaer8UvPLiv9xJgKWxKGqq7oHAEERvO2EI/jDUBqBFWyDEbSKRjRQdLc7t0JT5IAbs0sZ88gJ26J30UVwMR5fOQYOnbJDisLjBRVEM1s6170x8ZBbNFZ8L1Iu4ALBIcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VuymhJwxtJQCJaDq7YQYVJd6oIuXj8coFfZuzl4AXcI=; b=O3yT3FNfi1xLXJbt+MJR5N0wJ/kJGFaCQ+czn2bfzZyVs4kZtXyLT6eOcz9R1wpmMOaKytmYxX71X4ujZG6DCP4TXqTUYCRdSd8gOOhN28rT6pkC8qlV3lHKo9+A4a8+6xEi3U1p86b4sFDj4dYXjIRPTPvvavHofrv6HyPkcQbZatgGq/LmXxarAosk53bI+/WtTbnTw5L1dNPBeCMhGgsYIPXmxtixg/GTV1f3Em8mjkViaRYN8M1cMtaWCMSaq0TPrT8Zgi/qn2C9sMWtFoh9LdzFbks46jmIuzdFVCeQjPAh/frPpVBSDgBLIg4IWLD8pyOvohhtQkaq8iAxEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VuymhJwxtJQCJaDq7YQYVJd6oIuXj8coFfZuzl4AXcI=; b=pNNopM1c4NIR6mf6mHUYPc2REXdUfXhgnEANwJvZyslZ4u6WsXDj6SlnXgbncGseJhf8RdAezFBDURLN1wCh61DISWf9UTrISVgSc8CYa1v/ROF3WKMKorpAFyRMSjUX6nfot262B2wHydPBzu9+BglOk3xkiupyd/4MOeUPV1w= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM9PR07MB7937.eurprd07.prod.outlook.com (2603:10a6:20b:2fe::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.8; Thu, 16 Dec 2021 09:50:38 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4801.014; Thu, 16 Dec 2021 09:50:38 +0000 From: =?Windows-1252?Q?G=F6ran_Selander?= To: "loic.ferreira@orange.com" , LAKE List Thread-Topic: [Lake] spt review of echoc-12 Thread-Index: AQHX8X3yIMthA1ETQ0yDBuI/L+vrwaw0zZiAgAATpQ4= Date: Thu, 16 Dec 2021 09:50:38 +0000 Message-ID: References: <1B6DD418-03D8-4B78-9C26-3C821DF2DB9E@sn3rd.com> <30272_1639643906_61BAFB02_30272_304_2_d6452e85d0e643d5a0aaa541002e6ea0@orange.com> In-Reply-To: <30272_1639643906_61BAFB02_30272_304_2_d6452e85d0e643d5a0aaa541002e6ea0@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=True; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2021-12-16T08:38:24.0000000Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f82151fb-ee12-4ffd-7cc7-08d9c0798400 x-ms-traffictypediagnostic: AM9PR07MB7937:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ni67KQBoKCHbPMKLN8jlU9bokUYZIHb9bShKkPzIDG1tvBn9tjbOmHzImUQn2aLL3xKwbVRew0j8eykuwytHYS91N0Z7rW/tS6MFN9OtYro8syQXfLMPa+47BWWuPgueBW0W961VvEj8g16yy2uzFCDsnw5k0foxPpbzfCvKwKMZonc3BG+XF9reos8rUZGT8mba8v5DKFx6ep8w3+LP1pOECu9cD24l0W7XziQUiEOYRWOSUTm3f5IvMO9Iy9rZTceyW8whUMKuxxd53sD4A3siVycEJZvGWxefZC6nrfe8PDJvh4ywnNSdsifrieSuBzDMsAeoPmxKxsuL5Ltb+zTB/qWen4CGNyBpwq61pWM8W3+k9CBye5TkRCCPuTAdmHYVdsETyVgQm96BntqUJ9s2sb8Ug5djnNrTojkGUJGy1I3pxpdVJhN/JdLURtY/JtqO48wL4geibXyFDHzBWwxyhm6gaiNIvPVoggHhurRh8auXuiFmqYAUxEI2sU7LR8E9YWBU3B/sALKdn3t4lwC9JNRJArMYO+bue1s7kd8qjvO3VL16o2VnA0GD5sp1Sp2D83PF4BcX+R7+5y+LG9M8ZVUBpSyd0HNiB1hIMbBKNUhY3orPozj5iPCFEp7WS3lwfvzhrlo4eI+3FLUPn001q/7UJqhMSJt73dKJCnl4SywoquI0VRK4xgQ3MSd/DGmMSwAGw4aE/cwssTUfpDUYY+DBenuR7ykF0ioZOuE/5banJvmup8BVn/IzcX87e8+6M1cQ/qjwJ3q+y3n95Viy5rF49eUG4DAUmYh0+NQHxDmOt4L1w69sjLQe3FV31CWXbRcThJ2La97N4zVCKz8IOCpjhyTux5ODu/5xf5K6mQek9/dzDL5qJDSVs8Oa x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(52536014)(91956017)(66946007)(71200400001)(9686003)(5660300002)(30864003)(82960400001)(76116006)(64756008)(66476007)(508600001)(8676002)(66556008)(66574015)(316002)(6506007)(53546011)(8936002)(966005)(55016003)(33656002)(186003)(26005)(66446008)(7696005)(83380400001)(110136005)(86362001)(38100700002)(122000001)(166002)(38070700005)(2906002)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?IWEEI93DP4xmNwsptzHVeJpqjlKzDNWo8GmmMKIe958rI9eLZZMbXjUx?= =?Windows-1252?Q?CM8KDDRdFtRFP2LhLa50EFC7CBiI4fFrTRiQMWYb3DrxrXlFXQn27wsG?= =?Windows-1252?Q?Y10EZRNhB18HOQM3buTH0z1wSAr1zVxvR/BBFzVGIkwcDNzXB7JCZRqK?= =?Windows-1252?Q?aOvw+EddOMtH60IiCqoiBsx+yaZODONcNqnNxJWn87ZsBgVoPSmnrPh7?= =?Windows-1252?Q?ausENYCZSngZIgK1wSBJYYxaku26Df8XXsWLMAPrEHTbPTFuGNEOyyg7?= =?Windows-1252?Q?XiNgLnAoIrl19p5al2CqWS6azsnyklqzXle/yTHdEZc/Nrj8EVO2oD1O?= =?Windows-1252?Q?KPXk2AkXQWfj9Wy5zMKQ4fK5o9MeDyuP/TIH0jeI5gHH0s3O3n+rq+ak?= =?Windows-1252?Q?cCtNWZj5VwpRjZ5Zx+2adX0cr/LThRunMTWSJU+uzVEC1W4yRFQVtuTw?= =?Windows-1252?Q?MbGuSqDa1aloZxo/AadnZFp7kews9PTzthvxxRR72Fr/nynfweTH/4Xb?= =?Windows-1252?Q?RHrLxUMtxazRrnt83Irm2gNGqO1QLk66dznioO4v3ZeXWhoG5gxjpvvb?= =?Windows-1252?Q?H8zdLI9Cl7JQoIqpdc79a8dwZHqdnHeLoYCq2qpS1uVUvIz2rpRKVArG?= =?Windows-1252?Q?mEAltYGWH0YzmBeH7C05l8R5iAzkVt3+P1L4Nd7wi1O4ECAJKIod0ZGo?= =?Windows-1252?Q?/RmYdhZk+ks6kjWw6kJaDgl07zcYGTAgb425ssjLpe3LFEySIiODGLNg?= =?Windows-1252?Q?AzSi5RAdkfvJeweK1XILEQx/WeLfX85iSbtKaAdre0WKPtWgPsBfkdyP?= =?Windows-1252?Q?rJ0OFunfFbilEAX1vmT2jmGS3adK5palZLOBDCfMBKNwHiY5nUc6FNU1?= =?Windows-1252?Q?/qYghbZL5C5YpiBz0h9HFNuXUwI7dThjM7w3IV0EXg/iTTdzH0TSwgny?= =?Windows-1252?Q?jjsDgsMiCv/UxrNEeUga+cXgwPmALKNU657tXublHHg1VNWuA7Ah6MZG?= =?Windows-1252?Q?wmbwHD4izb1XsLAW1cRfHDtOG1VwxqkZMhLjZpUGsf/ziTXTgG5ftPTi?= =?Windows-1252?Q?hGP8eRWnKQ1+ygrl28HIgiHpx/4NtYQCuqkcuREomk5vy2Pri016CRRZ?= =?Windows-1252?Q?lHYHb8K2nqRoQE67gQnUtsGVEsoSVRnI+APTlcAZ9aV8LXN4se3n/W6+?= =?Windows-1252?Q?C5+hDxfmCwbHi3CaTxFE84uWRc8FFwVGFf+8u6Fc8TJjSm7KwdHFKP87?= =?Windows-1252?Q?Va8etPk2yiogV+ShOU1XWqES/zH+rP0aG55ArfCMNdyJ/DKXrgN8A8Co?= =?Windows-1252?Q?mq8fp5FuCDq6CITuLX4rMolhQlfW1gW/k9uMIwVuyTB1VpP3Qh3cSHDS?= =?Windows-1252?Q?6XYhj/KltnP8e5CXRKrOFI0khylHPnxSVbiU201ZaxWIeybOjkLuqPTp?= =?Windows-1252?Q?QZk4tbKsmAduPJ01gJk93h2p717Y78qMlbp6/TSXyCByRqxQgrDj8rxS?= =?Windows-1252?Q?dlVQZhiihDJFEJPbdchzsiiryg7Ltnt9JPtHddZll+zQk54JsA3Z9Ysf?= =?Windows-1252?Q?+4VWL963qDwzLATsH7GR54fOtckZxQDcDXGGt+nthImNA03nECRi7Zzr?= =?Windows-1252?Q?7oZr7g+L1gUe3CHF47EFYBAgWTStQ5xLk6KnZ0kUj+sIAW8kgtX5FkP0?= =?Windows-1252?Q?lloxFuN58f5ENeDKEICXiv8B29H9I9xh4zBcf0HSUx8Wjt+jt/X+VJdA?= =?Windows-1252?Q?+ffpl2/ebHHWVhWH1BHa8LVw9qJLYCR4RFgBnsF5NsaE9LIRd9KyehUc?= =?Windows-1252?Q?dsj/dYdMth0g+uFCz3kVo3eW/+Y=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB21957B4EC826E64C386F20E7F4779AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f82151fb-ee12-4ffd-7cc7-08d9c0798400 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2021 09:50:38.7054 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sYXeU2MopNwhQ7YVz5CrOOhynKDgegOSKW1r/zI1LnL4OoJ/mh0IE3+cNlDExupSemup+enVLWROYvJTpKJd4uCKkgZi4lb3bfqIAtA5aVM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR07MB7937 Archived-At: Subject: Re: [Lake] spt review of echoc-12 X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 09:50:50 -0000 --_000_AM4PR0701MB21957B4EC826E64C386F20E7F4779AM4PR0701MB2195_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Lo=EFc, Thanks for the comment. It is not too late and makes sense to me. I opened = an issue: https://github.com/lake-wg/edhoc/issues/218 G=F6ran From: Lake on behalf of loic.ferreira@orange.com Date: Thursday, 16 December 2021 at 09:40 To: LAKE List Subject: Re: [Lake] spt review of echoc-12 Hello LAKE, Sorry for this very late remark. But it seems that "EdDSA" is not the prope= r wording to use in the draft (at least in Section 9.2). I quote the origin= al paper by Bernstein, Duif, Lange, Schwabe and Yang [1]: - " This section specifies the signature system used in this paper, and a g= eneralized signature system EdDSA that can be used with other choices of el= liptic curves." - " Our recommended curve for EdDSA is a twisted Edwards curve birationally= equivalent to the curve Curve25519 [...] We use the name Ed25519 for EdDSA= with this particular choice of curve." Therefore "Ed25519" should be used in place of "EdDSA" (at least in Section= 9.2). What do you reckon? Best regards [1] High-speed high-security signature, Bernstein, Duif, Lange, Schwabe and= Yang, 2011. https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22= d327-454445555731-1b801206d8bfce4f&q=3D1&e=3D371d7c78-5c57-49c2-8785-e20bf0= 38bf86&u=3Dhttps%3A%2F%2Fed25519.cr.yp.to%2Fed25519-20110926.pdf Lo=EFc Ferreira Orange Labs =96 Applied Cryptography Group +33 (0)2 31 15 91 24 loic.ferreira@orange.com Orange Restricted -----Message d'origine----- De : Lake De la part de Sean Turner Envoy=E9 : mercredi 15 d=E9cembre 2021 07:35 =C0 : LAKE List Objet : [Lake] spt review of echoc-12 Like others I agreed to review the edhoc I-D at the last meeting. I did not= have a chance to make sure that I am not repeating comments from others. T= o save the WG some time, I tried to categorize these along the lines of que= stions/nits where discuss might need some f2f time and nits, I believe, can= be dealt with by the authors as they see fit. Disclaimers: 0) I am not a cryptographer or security researcher. 1) It is e= ntirely possible I am entirely missing the plot/point. Apologies: I ran out of time to submit these as Issues/PRs. I can do so aft= er the interim, including those that got rejected at the 12/15 interim for = posterity sake. s1.2 (nit): If s1.2 is supposed to be an applicability statement in the con= text of RFC 2026, can we call it that. i.e., r/Use of EDHOC/Applicability S= tatement. revised: And then, I see section 3.9. Maybe instead of renaming s1.2, a for= ward pointer to s3.9 is all that is needed to say that an applicability sta= tement is required? s2, 2nd para (nit): refer to both because it=92s (D)TLS and not just TLS? = I.e., s/(D)TLS 1.3 [RFC8446]/(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13] s2, 2nd para (nit): I think you can safely drop the 2nd reference to IKEv2 = s/like IKEv2 [RFC7296],/like IKEv2, s3.2/s3.5.2 (question): Smarter people than I have devised plans to allow m= ixing of different METHODs. How does this impact the key usage extension pr= esent in certificates? In other words, are METHODS 1 and 2 suggesting that = a DS and DH key be used together and does that violate any kind of restrict= ions on the key usage settings for certificates? s3.4 (nit): Is transport of error messages, as noted by s6 (2nd para), need= ed in the list. s3.5 para after the bullets (nit): I think you are trying to say the creden= tials have to be the same type, i.e., you can=92t have PGP one one side and= x.509 on the other. I am not sure that the following is the best wording: s/Identical authentication credentials need to be established in both endpo= ints to be able to verify integrity./The same type of authentication creden= tials are needed baby the endpoints to be able to verify integrity. s3.5.1, 1st para (nit): At first I thought for sure this had to be a MUST, = but it says or application so I am not sure: The EDHOC implementation or the application must enforce information about = the intended endpoint =85 s3.5.1 (nit): expand on first use NAI & EUI s3.5.1, 1st bullet (nit): Often we refer to this a Proof-of-Possession so m= aybe you could say that: s/EDHOC provides proof that the other party possesses the private authentication key corresponding to the public authentication key in its certificate./EDHOC provides proof that the other party possesses the private authentication key corresponding to the public authentication key in its certificate, which is also known as proof-of-possesion. s3.5.1, 1st bullet (question): This seems like the =93mixing=94 discussed i= n s3.2, relies on the identity provide in the certificate? The certification path provides proof that the subject of the certificate owns the public key in the certificate. s3.5.2 (question): related to comment on s3.2. s3.5.3, 2nd para (nit): Could point to RFC 3279/5480 for some key usages fo= r ECDSA and RFC 8410 for x25519/x448. In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement" [RFC3279][RFC8410]. s3.6 (nit): refer to both?: s/TLS 1.3 [RFC8446]/ (D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13] s3.5.3 (question): EDHOC seems to assume you only provide the reference for= the initiator's/responder=92s. Was there any thought it to providing refer= ences for the rest of the certification path up to but not including the Ro= ot CA=92s certificate? I mean technically they can also be in there certifi= cate provided so not necessarily needed. s3.6, CNSA ref (nit): I made a similar comment against the ZRTP spec when t= hey said their alg suites were compliant with Suite B =85 probably best to = say Suite 24 and 25 use algorithms in CNSA and leave the word =93compatible= =94 for =93them=94 to say. s3.8 (comment): Wow .. so you can send in the CSR in EAD, if it works then = you can use the cert in the later messages (e.g., kind of like EAP)? Sure h= ope there=92s no kind of CSR-related error. And, you know that the CA gets = to decide the name right. Sorry just trying to digest it all. s4.3 (nit): s/kan/can s4.4/s5.1 (question): Do you need to provide advice on when to delete the o= ld PRK_4x3m? I.e., does the peer that sent this need to wait for some kind = of confirmation before deleting it? s5.1 (question): Is a state diagram needed? One thing people clamored for f= rom TLS was a state machine. Maybe a diagram isn=92t needed because there a= re so few states? s5.1 (comment, no action required): Cute. Deduplication is how to deal with= message reply ;) s5.2.1, s.5.3.1, s5.4.1, s5.5.1 (nit): is the =93,=94 before the closing br= acket right? e.g., OLD: ? EAD_1 : ead, } NEW: ? EAD_1 : ead } s5.2.2 (question): If this this initiator processing section, how does the = initiator know to truncate? =85, truncated after the cipher suite selected for this session. s5.2.3, s5.3.3, s5.4.3, s5.5.3, last sentence (question - probably being pe= dantic): If there is an error but an error message is not sent, is the sess= ion discontinued? How does the peer know it was discontinued if an error is= not sent? s5.2.3, s5.3.3, s5.4.3, s5.5.3 (nit, which I am sure the RFC editor fix bet= ter than I could, but I couldn=92t help myself): Instead of the e.g., in mi= ddle of the MAY sentence maybe: OLD: Sending error messages is essential for debugging but MAY e.g., be skipped if a session cannot be found or due to denial-of-service reasons, see Section 8.6. NEW: Sending error messages is essential for debugging but MAY be skipped if, for example, a session cannot be found or due to denial-of-service reasons, see Section 8.6. s6.1 (nit): To stop loops, should any peer that receives an ERR_CODE=3D0 di= scontinue the session? I.e., is that worth stating in the I-D? s6.2 (nit): It=92s really more =93Freeform=94 than unspecified right? I mea= n the string is required so it=92s definitely not unspecified per se. s6.3.2, 2nd to last para (nit): s/shall/SHALL s6.3.2/s5.2.1 (nit): Might be worth noting earlier that SUITES_R is not imp= ortant. Also, s5.2.1, mentioned SUITES_I, but s5.2.2 does not mention SUITE= S_R. s7, last para (nit): s/To enable as much interoperability as we can reasonably achieve,/To enable as much interoperability as possible, s8 (question): Isn=92t some kind of consideration needed to address the use= of PSKs shared by more than two? See RFC 8773 for some considerations wrt = to group key sharing and that sharing impact on authentication. s8.3 (nit): You can informatively refer to RFC 6194 to slam the door on SHA= -1. s9 and onwaard (apologies): I ran out of steam. s? (question): Is a peer supposed to check status information for its peer= =92s certificate/key? I-D Nit complaints (not all of them because the DOWNREFs (mostly) looked in= tentional): =3D=3D Missing Reference: 'RFC9052' is mentioned on line 2411, but not defi= ned Cheers, spt -- Lake mailing list Lake@ietf.org https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-45444555= 5731-49a34bb25e2c1426&q=3D1&e=3D371d7c78-5c57-49c2-8785-e20bf038bf86&u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. -- Lake mailing list Lake@ietf.org https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-45444555= 5731-49a34bb25e2c1426&q=3D1&e=3D371d7c78-5c57-49c2-8785-e20bf038bf86&u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake --_000_AM4PR0701MB21957B4EC826E64C386F20E7F4779AM4PR0701MB2195_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Lo=EFc,

 

Thanks for the comment. It is not too late and makes= sense to me. I opened an issue:

https://github.com/lake-wg/edhoc/issues/218

 

G=F6ran

 

 

From: Lake <lake-bounc= es@ietf.org> on behalf of loic.ferreira@orange.com <loic.ferreira@ora= nge.com>
Date: Thursday, 16 December 2021 at 09:40
To: LAKE List <lake@ietf.org>
Subject: Re: [Lake] spt review of echoc-12

Hello LAKE,

Sorry for this very late remark. But it seems that "EdDSA" is not= the proper wording to use in the draft (at least in Section 9.2). I quote = the original paper by Bernstein, Duif, Lange, Schwabe and Yang [1]:
- " This section specifies the signature system used in this paper, an= d a generalized signature system EdDSA that can be used with other choices = of elliptic curves."
- " Our recommended curve for EdDSA is a twisted Edwards curve biratio= nally equivalent to the curve Curve25519 [...] We use the name Ed25519 for = EdDSA with this particular choice of curve."
Therefore "Ed25519" should be used in place of "EdDSA" = (at least in Section 9.2).

What do you reckon?

Best regards

[1] High-speed high-security signature, Bernstein, Duif, Lange, Schwabe and= Yang, 2011. https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-45444555= 5731-1b801206d8bfce4f&q=3D1&e=3D371d7c78-5c57-49c2-8785-e20bf038bf8= 6&u=3Dhttps%3A%2F%2Fed25519.cr.yp.to%2Fed25519-20110926.pdf

Lo=EFc Ferreira
Orange Labs =96 Applied Cryptography Group
+33 (0)2 31 15 91 24
loic.ferreira@orange.com


Orange Restricted

-----Message d'origine-----
De : Lake <lake-bounces@ietf.org> De la part de Sean Turner
Envoy=E9 : mercredi 15 d=E9cembre 2021 07:35
=C0 : LAKE List <lake@ietf.org>
Objet : [Lake] spt review of echoc-12

Like others I agreed to review the edhoc I-D at the last meeting. I did not= have a chance to make sure that I am not repeating comments from others. T= o save the WG some time, I tried to categorize these along the lines of que= stions/nits where discuss might need some f2f time and nits, I believe, can be dealt with by the authors a= s they see fit.

Disclaimers: 0) I am not a cryptographer or security researcher. 1) It is e= ntirely possible I am entirely missing the plot/point.

Apologies: I ran out of time to submit these as Issues/PRs. I can do so aft= er the interim, including those that got rejected at the 12/15 interim for = posterity sake.

s1.2 (nit): If s1.2 is supposed to be an applicability statement in the con= text of RFC 2026, can we call it that. i.e., r/Use of EDHOC/Applicability S= tatement.

revised: And then, I see section 3.9. Maybe instead of renaming s1.2, a for= ward pointer to s3.9 is all that is needed to say that an applicability sta= tement is required?

s2, 2nd para (nit): refer to both because it=92s (D)TLS and not just TLS?&n= bsp; I.e., s/(D)TLS 1.3 [RFC8446]/(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13= ]

s2, 2nd para (nit): I think you can safely drop the 2nd reference to IKEv2 = s/like IKEv2 [RFC7296],/like IKEv2,

s3.2/s3.5.2 (question): Smarter people than I have devised plans to allow m= ixing of different METHODs. How does this impact the key usage extension pr= esent in certificates? In other words, are METHODS 1 and 2 suggesting that = a DS and DH key be used together and does that violate any kind of restrictions on the key usage settings f= or certificates?

s3.4 (nit): Is transport of error messages, as noted by s6 (2nd para), need= ed in the list.

s3.5 para after the bullets (nit): I think you are trying to say the creden= tials have to be the same type, i.e., you can=92t have PGP one one side and= x.509 on the other. I am not sure that the following is the best wording:<= br>
s/Identical authentication credentials need to be established in both endpo= ints to be able to verify integrity./The same type of authentication creden= tials are needed baby the endpoints to be able to verify integrity.

s3.5.1, 1st para (nit): At first I thought for sure this had to be a MUST, = but it says or application so I am not sure:

The EDHOC implementation or the application must enforce information about = the intended endpoint =85

s3.5.1 (nit): expand on first use NAI & EUI

s3.5.1, 1st bullet (nit): Often we refer to this a Proof-of-Possession so m= aybe you could say that:

s/EDHOC provides
      proof that the other party possesses the pri= vate authentication
      key corresponding to the public authenticati= on key in its
      certificate./EDHOC provides
      proof that the other party possesses the pri= vate authentication
      key corresponding to the public authenticati= on key in its
      certificate, which is also known as proof-of= -possesion.

s3.5.1, 1st bullet (question): This seems like the =93mixing=94 discussed i= n s3.2, relies on the identity provide in the certificate?

    The certification path provides proof that the
    subject of the certificate owns the public key in the ce= rtificate.

s3.5.2 (question): related to comment on s3.2.

s3.5.3, 2nd para (nit): Could point to RFC 3279/5480 for some key usages fo= r ECDSA and RFC 8410 for x25519/x448.

In
   X.509 and C509 certificates, signature keys typically have key= usage
   "digitalSignature" and Diffie-Hellman public keys ty= pically have key
   usage "keyAgreement" [RFC3279][RFC8410].

s3.6 (nit): refer to both?:
s/TLS 1.3 [RFC8446]/
(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13]

s3.5.3 (question): EDHOC seems to assume you only provide the reference for= the initiator's/responder=92s. Was there any thought it to providing refer= ences for the rest of the certification path up to but not including the Ro= ot CA=92s certificate? I mean technically they can also be in there certificate provided so not necessarily needed.<= br>
s3.6, CNSA ref (nit): I made a similar comment against the ZRTP spec when t= hey said their alg suites were compliant with Suite B =85 probably best to = say Suite 24 and 25 use algorithms in CNSA and leave the word =93compatible= =94 for =93them=94 to say.

s3.8 (comment): Wow .. so you can send in the CSR in EAD, if it works then = you can use the cert in the later messages (e.g., kind of like EAP)? Sure h= ope there=92s no kind of CSR-related error. And, you know that the CA gets = to decide the name right. Sorry just trying to digest it all.

s4.3 (nit): s/kan/can

s4.4/s5.1 (question): Do you need to provide advice on when to delete the o= ld PRK_4x3m? I.e., does the peer that sent this need to wait for some kind = of confirmation before deleting it?

s5.1 (question): Is a state diagram needed? One thing people clamored for f= rom TLS was a state machine. Maybe a diagram isn=92t needed because there a= re so few states?

s5.1 (comment, no action required): Cute. Deduplication is how to deal with= message reply ;)

s5.2.1, s.5.3.1, s5.4.1, s5.5.1 (nit): is the =93,=94 before the closing br= acket right? e.g.,

OLD:

    ? EAD_1 : ead,
}

NEW:

    ? EAD_1 : ead
}

s5.2.2 (question): If this this initiator processing section, how does the = initiator know to truncate?

  =85, truncated after the cipher suite selected for this
  session.

s5.2.3, s5.3.3, s5.4.3, s5.5.3, last sentence (question - probably being pe= dantic): If there is an error but an error message is not sent, is the sess= ion discontinued? How does the peer know it was discontinued if an error is= not sent?

s5.2.3, s5.3.3, s5.4.3, s5.5.3 (nit, which I am sure the RFC editor fix bet= ter than I could, but I couldn=92t help myself): Instead of the e.g., in mi= ddle of the MAY sentence maybe:

OLD:

   Sending error
   messages is essential for debugging but MAY e.g., be skipped i= f a
   session cannot be found or due to denial-of-service reasons, s= ee
   Section 8.6.

NEW:

   Sending error
   messages is essential for debugging but MAY be skipped if, for=
   example, a
   session cannot be found or due to denial-of-service reasons, s= ee
   Section 8.6.

s6.1 (nit): To stop loops, should any peer that receives an ERR_CODE=3D0 di= scontinue the session? I.e., is that worth stating in the I-D?

s6.2 (nit): It=92s really more =93Freeform=94 than unspecified right? I mea= n the string is required so it=92s definitely not unspecified per se.

s6.3.2, 2nd to last para (nit): s/shall/SHALL

s6.3.2/s5.2.1 (nit): Might be worth noting earlier that SUITES_R is not imp= ortant. Also, s5.2.1, mentioned SUITES_I, but s5.2.2 does not mention SUITE= S_R.

s7, last para (nit): s/To enable as much interoperability as we can
   reasonably achieve,/To enable as much interoperability as poss= ible,

s8 (question): Isn=92t some kind of consideration needed to address the use= of PSKs shared by more than two? See RFC 8773 for some considerations wrt = to group key sharing and that sharing impact on authentication.

s8.3 (nit): You can informatively refer to RFC 6194 to slam the door on SHA= -1.

s9 and onwaard (apologies): I ran out of steam.

s? (question): Is a peer supposed to check status information for its peer= =92s certificate/key?

I-D Nit complaints (not all of them because the DOWNREFs (mostly) looked in= tentional):

=3D=3D Missing Reference: 'RFC9052' is mentioned on line 2411, but not defi= ned

Cheers,
spt
--
Lake mailing list
Lake@ietf.org
https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445= 555731-49a34bb25e2c1426&q=3D1&e=3D371d7c78-5c57-49c2-8785-e20bf038b= f86&u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

--
Lake mailing list
Lake@ietf.org
https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445= 555731-49a34bb25e2c1426&q=3D1&e=3D371d7c78-5c57-49c2-8785-e20bf038b= f86&u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake=

--_000_AM4PR0701MB21957B4EC826E64C386F20E7F4779AM4PR0701MB2195_-- From nobody Thu Dec 16 02:45:03 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933C33A0955 for ; Thu, 16 Dec 2021 02:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 u8QwOAQXW-Nv for ; Thu, 16 Dec 2021 02:44:55 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2055.outbound.protection.outlook.com [104.47.12.55]) (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 0FDAD3A094E for ; Thu, 16 Dec 2021 02:44:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XcVz+s/t/DUCaJCsMbQDnKlfJ7MjW7JwcRbOWc2ECyUyG/LZPAfgIqRxc80dtVf+tZsj+pm4QcKj5zNPvmC9Vnwugy87l0I1JKVodLbo35Vb5678+TdeBxGr0pAnDxtRkgAhiMbkh+EEeiZc0AWHK1zz4NYi+IofJxCL6ogvJCuoIDPaSGMWpdt1ahN8uaqNIPJDIFt12IhEkEe/R70uvlJwue891Bs2tQODoXxUYpkg+LoEqw6XjBpJOpmqObWYpYfakCH/R1qEJ4/HggrArZqLMVpucON/F4ZnwhvpVdSeCgoTKxpmkptKhwQmqR6yVLFjRz8Jv0eGfXk9XUOFIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5r0WjAmt9w6eiqzny5NBeRrsL9iYb2n7dVA4aII5fyo=; b=i/N2sbrM9ok7yEbjPHorr26G1ga3XJQ9Hdo3+4HCQ1bd/SZ2JKhQLC2+S4zbWXZHs6164IT2IKEx5Y7veSxCvUmwWvNyTNKhyOVFwVjl/xx6u3rDK/Mha0gUyl4Jbk/2PZKGgOnQpjqhXoUQq0rIR6v3YSnoXI9PxIfGomBxcLNUCB62c+JEYnWWzEBsXvoeOvHdR2lZCovB2Usk+m8xwUZUvFX9vK+A6tryiK9LQys5BSxMAZxpM4NkHNaMvaQJLIizgke3CwWCw1QMZ0v585MoBFS9tLk8O0pSx9lVhS99R8BCsOUyORzsaIww1PNjoggzyx1CvqL5gS7CIafoeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5r0WjAmt9w6eiqzny5NBeRrsL9iYb2n7dVA4aII5fyo=; b=l6LIjQ3YU7GxmF127dhzDHguqSR/XbL7l/q8t9dtjkyNowhsjMehf/M/q2pymuFTvuoBDNqNsOrgics6AVCvPVGIragpOPrcsffuKKiyRKRfMvp4P2UNTaDWineLD8Ckiku+C1zDI6hscvFD7yDm1CELuMW2XLxGHEmjLYicr/M= Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com (2603:10a6:200:45::6) by AM0PR07MB4019.eurprd07.prod.outlook.com (2603:10a6:208:47::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.13; Thu, 16 Dec 2021 10:44:44 +0000 Received: from AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b]) by AM4PR0701MB2195.eurprd07.prod.outlook.com ([fe80::90a9:5a2d:efb8:744b%4]) with mapi id 15.20.4801.014; Thu, 16 Dec 2021 10:44:44 +0000 From: =?windows-1250?Q?G=F6ran_Selander?= To: =?windows-1250?Q?Mali=9Aa_Vu=E8ini=E6?= , "lake@ietf.org" Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4UKGsyqHqbrk6AWNVQ4aqbJqw04BiN Date: Thu, 16 Dec 2021 10:44:44 +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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42984eef-6198-4740-e2f4-08d9c08112e4 x-ms-traffictypediagnostic: AM0PR07MB4019:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zGsrh0Rn1HB+zM54Rdq3LAeAyTB9Hxz/B368Fl75UPisA+4gLMItEWa6ThnN3sWeSxqSB/7RCxI97SGL1NVluNPJgWNHKpR9YtSUg80GeGyyOSUPhVrtNlRGWxY/4B8Hoou8c+KbFJst2DcHNefLdR9CTqXlnpjRRml4AIb85mZM2f5AdWulSprslhn9/AJF2vqfO2PwhE3bm3PidI6nnM7GacWjqoxwdbxwwSsYGo3dyFLp/6bVAA+YHuKMBqe9/2wC7H+TrSG6ZnN4YjJwKL110JmJuXjZfnUnN0o5hqPJTyzWBB7a5KvQG59ZFAKUQBv8x10pPn+y0LW2pl3iXiKyhgwbWIwQnfswPGsKNDwmw8uLfq1lISOsufnsOMHpxZRzVyQ/WQ+QPk3EN+SbsABsPEMpi8xeC4XBa8+edR504jD84S4S+ExUXzv6wWcDParWiQ7CMYdAPEMukTaxPxekQ9uPtoNAkeKc46w2pOAlS4SAigdEh5RCiypCyguQ8cLro7qn+gHSVhTAdm6UZ79rs9aykhxtHkQ6ksPvfYqwUhCBhak62zVxpnCjp7nILLCdSEWr0JmMAIM5G/8svh86FfoSVYbyDywFagd0IFhxJQdG9Rm/86yMz0kThGp1MBgpQA6QdOoerZh8PcJhfB3m0MbLE8fK0APNP556XNrbzJ4fl6HZJwGACXdb2mzu2RRTMMmh4VTyrNOMpUhShlpPR6jNIwHfEBxGhN0Nr0XgPm9LBb2dYgkc9LQZ4jWviG4lkMdBGYUiwmoWBgpSCdcUZd4N1W042ijenJ4J9OiXhuvKt4CC1xunJ98PbfbJdnY5TitsKlcQ663oMQhkJgE/QyxvqDiG/GpwJanyUzzdPs1cfWUr5LgMwo3s+9QD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR0701MB2195.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(26005)(186003)(2906002)(55016003)(5660300002)(66574015)(33656002)(508600001)(966005)(53546011)(71200400001)(86362001)(9686003)(166002)(7696005)(6506007)(38070700005)(110136005)(91956017)(52536014)(64756008)(66556008)(66446008)(66476007)(8936002)(8676002)(316002)(66946007)(76116006)(82960400001)(122000001)(38100700002)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?windows-1250?Q?KQta/a7Bx9/FQiqPjVp/uZ4fDC3R8HnB8qe15MRplnoBFjufmYUXfpxZ?= =?windows-1250?Q?BDtLFfAQdBTjRqkGHmwC7/pmNX31IhOvxt+u+nBvd4LtevygZF2v1PHf?= =?windows-1250?Q?x0b7znnboS4rSX6UFGuyY4Et8NIDi9gYsKJt7zGunc2yRqR8Gr2d5dwD?= =?windows-1250?Q?hNdIrzVA4E7w1/1WegSmNIHQbMzunShWvPt6RzfyYRFRRE6oUd9HAxGa?= =?windows-1250?Q?Fl7gEukoW5SGhsFwudahxPI+rxKuS3Fr1Aiy1cnRN74tW0/WvaVozJB0?= =?windows-1250?Q?j0OmldC1mIssSktUPhQxqNW0JiejEFnMsmEl4N4MSV+EFt2mKW56vzE8?= =?windows-1250?Q?PE3Vi/E+dVgjqVBXcxqhDTGwn5Qhl0cxhmhoYacpfKaFvhid1wJJy/T3?= =?windows-1250?Q?eEFTg0w7aeQlwiF2INyfKQnFkn4++caARV0J3DS1pUdtea9E+GP72WVS?= =?windows-1250?Q?y4YQvE3rh0b2Bm+gIc6meq8jEXnHMrCfcyOmObE0prVlkySVA6D6Cf44?= =?windows-1250?Q?0O5AprFspKfuAmfLWkoOKz3mGul/QkFsI76SK3uTf5PPJk+1EEpKpOdt?= =?windows-1250?Q?A6EPtkaJpKH/KAjnZX/Mx9xvy19dZo21SY//9isSn+JBQ9deKdZl1TD4?= =?windows-1250?Q?sjoS6uyKoBo5KAdhp5nDcPzpszXR5BMJD0N6519YG7OuIjHEpuuAsd8s?= =?windows-1250?Q?1LEvzPyxMoGU9zQiCBC0RG1PyMsxOcnC37neIkw3VZrMWEIBIfsYy5UQ?= =?windows-1250?Q?y8ktd0GllfxpZKJ1kNsRbNYN1TPS+ISO0PixHvkz7M1N/72mpqBWIdmJ?= =?windows-1250?Q?HLetQKLaw7glbt0gpEjDyccJGCtmttrNqSjgvXOYpkfVFvwBmVi4sBIz?= =?windows-1250?Q?VfKfy1Vjg3wCZiKn2pZNaSBMp9yeGnLoqYYGIEc+0CYHFErk3ewW+27V?= =?windows-1250?Q?++Kq0pfEQfKFr5sM0KeR/6xJ4xf93uQxevAowrwQAnFYe5J9d+JttSJO?= =?windows-1250?Q?EKRzy/Cb3ojSOyMyXkERYEPxdSjbRP095ZZUg72prKNgvjuwnjUkFC+V?= =?windows-1250?Q?ktgNEOUNgXab7v4A6UDblrI2iKaMa7JRIGK3MeiVuPw8lokmOd9Wx+BF?= =?windows-1250?Q?pGDcIfsv7aNvRVQ8l47WLuOZ9JIA0PEk8YESkN+Q0h1YTW8+H7en7UXz?= =?windows-1250?Q?71mYGH4IdLYVMI6DGHoKwK532tDyhHcTpnWXsqSDEgVblgbSBCj7Dm7w?= =?windows-1250?Q?aIsz+pdxf6EdsW5hdmmg5efU8ju3nAF+6rA+x5T7h/h23e++wtt2vPrv?= =?windows-1250?Q?KHWjdLXENZUI41ioyZqYWkt94JIVNjhGlHp9Zp5QgkNYBcijktagPfrA?= =?windows-1250?Q?ZRZ0HcCYLjizMC+0z52JtJztkdOFbXBpdQtWaALw446JCWSK+qD4xa8b?= =?windows-1250?Q?RjJuynw88KdGTJbapaAf+xe99h4+9YrWbfckuUnaursET+NWzg9/+VDD?= =?windows-1250?Q?S38S+8vChManm4LvS+kGNGWLZ/RKeFEXx0z3YKEKecpK0w/akD1A69cb?= =?windows-1250?Q?ub5Mud3PVzOHxwk2DF1KILhTmirP62RzlwKjCYH5LL2fUYnUCsKUURZJ?= =?windows-1250?Q?Jj+QfSbwwXwAN6TuViOHmejVl5KsG6w2jvrEvq9SyjCPS3w547MXMpkI?= =?windows-1250?Q?ZxRe5lRtuZmWJEM1dCipHfxG3y/zBJzHA42+AqtgGuZHGHGYxmr+ITHa?= =?windows-1250?Q?1YhfGhWSwfj3QrS/aHT5ma01wOKYUCB3xa9iQTgJnJy4WPpJtFr28clg?= =?windows-1250?Q?bjVWohhC1YAQWAz20tlBUlWxbg4=3D?= Content-Type: multipart/alternative; boundary="_000_AM4PR0701MB219547DF96AC36046E81BD95F4779AM4PR0701MB2195_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR0701MB2195.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42984eef-6198-4740-e2f4-08d9c08112e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2021 10:44:44.9159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G3yMlWvTnZmg/TJ0S6BnNaUBKoVbhsmpMjLuzx7j5gPyY8nbIVXAc3ofj8KjwchEVHaI6o8y0MJSQRJgfy1epLbtUcQtzAl5WVSrJxtM/Mo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4019 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 10:45:01 -0000 --_000_AM4PR0701MB219547DF96AC36046E81BD95F4779AM4PR0701MB2195_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi Mali=9Aa, This mail is not responding to your questions below, more a comment about p= rocess. I was surprised to have this discussion in the meeting yesterday since the = intent was to talk about Stefan's proposal (issue #209) and not the overall= MTI topic (issue #22), for which John had started another mail thread: https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/ As Carsten pointed out the issues are orthogonal. If the WG decides on "MUS= T implement cipher suite 2" on #22, we would also mandate cipher suite 3 if= we follow the proposal in #209. (If anyone disagrees to that, please post = in #209.) I think it would be good if people who have an opinion on the topic respond= s to John's mail which summarizes the previous discussion well. There is al= so a proposal for procedure to come to a decision at the end to his mail. W= hatever procedure we take it would be great if the chairs would announce in= advance to allow those who have a strong opinion to take part in the threa= d and the decision. G=F6ran From: Lake on behalf of Mali=9Aa Vu=E8ini=E6 Date: Thursday, 16 December 2021 at 10:19 To: lake@ietf.org Subject: [Lake] Ambiguous text on Mandatory to Implement suite All, (chair hat off) As discussed during the interim yesterday, the current text in -12 on MTI r= equirements (Section 7) reads as follows: > For many constrained IoT devices it is problematic to support more > than one cipher suite. Existing devices can be expected to support > either ECDSA or EdDSA. To enable as much interoperability as we can > reasonably achieve, less constrained devices SHOULD implement both > cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES- > CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA- > 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained > endpoints SHOULD implement cipher suite 0 or cipher suite 2. > Implementations only need to implement the algorithms needed for > their supported methods. I see two issues here: 1) imprecise language; 2) normative text that implie= s interoperability only in case when both peers implement both suites 0 and= 2. When it comes to the devices and their capabilities, we have so far been us= ing the precisely defined terms from RFC 7228. This is not the case here an= d we use terms such as =93less constrained devices=94, =93constrained endpo= ints=94. This is all very confusing. Why endpoint and not device? What does= =93less constrained device=94 actually mean in terms of RFC 7228? Assuming that the =93constrained endpoint=94 is a typo and instead means = =93constrained device=94, the normative statement in this text, i.e. implem= enting 0 OR 2, implies that we can achieve interoperability only in the cas= e when both peers implement both 0 and 2 cipher suites. Requiring the imple= mentation of two cipher suites on each device to achieve interoperability i= s far from the lightweight aspect of LAKE, so I would like to hear what are= the working group=92s thoughts on this. Mali=9Aa -- Lake mailing list Lake@ietf.org https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-45444555= 5731-49a34bb25e2c1426&q=3D1&e=3Dad041382-e3a6-40b4-a5f3-15ae63819e02&u=3Dht= tps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake --_000_AM4PR0701MB219547DF96AC36046E81BD95F4779AM4PR0701MB2195_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

Hi Mali=9Aa,

 

This mail is not responding to your questions below,= more a comment about process.

 

I was surprised to have this discussion in the meeti= ng yesterday since the intent was to talk about Stefan's proposal (issue #2= 09) and not the overall MTI topic (issue #22), for which John had started another mail thread:

 

https://mailarchive.ietf.org/arch/msg/lake/75nRaD6cz= YG6RqLT06Qe8C_lsaM/

 

As Carsten pointed out the issues are orthogonal. If= the WG decides on "MUST implement cipher suite 2" on #22, we wou= ld also mandate cipher suite 3 if we follow the proposal in #209. (If anyone disagrees to that, please post in #209.)=

 

I think it would be good if people who have an opini= on on the topic responds to John's mail which summarizes the previous discu= ssion well. There is also a proposal for procedure to come to a decision at the end to his mail. Whatever procedure= we take it would be great if the chairs would announce in advance to allow= those who have a strong opinion to take part in the thread and the decisio= n.

 

G=F6ran

 

 

From: Lake <lake-bounc= es@ietf.org> on behalf of Mali=9Aa Vu=E8ini=E6 <malisa.vucinic@inria.= fr>
Date: Thursday, 16 December 2021 at 10:19
To: lake@ietf.org <lake@ietf.org>
Subject: [Lake] Ambiguous text on Mandatory to Implement suite<= /o:p>

All,

(chair hat off)

As discussed during the interim yesterday, the current text in -12 on MTI r= equirements (Section 7) reads as follows:

>    For many constrained IoT devices it is problematic t= o support more
>    than one cipher suite.  Existing devices can be= expected to support
>    either ECDSA or EdDSA.  To enable as much inter= operability as we can
>    reasonably achieve, less constrained devices SHOULD = implement both
>    cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X2551= 9, EdDSA, AES-
>    CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-= 16-64-128, SHA-
>    256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256).&n= bsp; Constrained
>    endpoints SHOULD implement cipher suite 0 or cipher = suite 2.
>    Implementations only need to implement the algorithm= s needed for
>    their supported methods.

I see two issues here: 1) imprecise language; 2) normative text that implie= s interoperability only in case when both peers implement both suites 0 and= 2.

When it comes to the devices and their capabilities, we have so far been us= ing the precisely defined terms from RFC 7228. This is not the case here an= d we use terms such as =93less constrained devices=94, =93constrained endpo= ints=94. This is all very confusing. Why endpoint and not device? What does =93less constrained device=94 actually = mean in terms of RFC 7228?

Assuming that the =93constrained endpoint=94 is a typo and instead means = =93constrained device=94, the normative statement in this text, i.e. implem= enting 0 OR 2, implies that we can achieve interoperability only in the cas= e when both peers implement both 0 and 2 cipher suites. Requiring the implementation of two cipher suites on each device t= o achieve interoperability is far from the lightweight aspect of LAKE, so I= would like to hear what are the working group=92s thoughts on this.

Mali=9Aa

--
Lake mailing list
Lake@ietf.org
https://protect2.fireeye.com/v1/u= rl?k=3D31323334-501d5122-fe22d327-454445555731-49a34bb25e2c1426&q=3D1&a= mp;e=3Dad041382-e3a6-40b4-a5f3-15ae63819e02&u=3Dhttps%3A%2F%2Fwww.ietf.= org%2Fmailman%2Flistinfo%2Flake=

--_000_AM4PR0701MB219547DF96AC36046E81BD95F4779AM4PR0701MB2195_-- From nobody Thu Dec 16 05:00:08 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBEA3A0E7B for ; Thu, 16 Dec 2021 05:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fKk7JInmHaI for ; Thu, 16 Dec 2021 05:00:00 -0800 (PST) Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 5D3963A0E75 for ; Thu, 16 Dec 2021 04:59:59 -0800 (PST) Received: from LLEX2019-2.mitll.ad.local (llex2019-2.llan.ll.mit.edu [172.25.4.124] (may be forged)) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 1BGCxukY408565 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 16 Dec 2021 07:59:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=ktRXtzM+1oyOPSO77ge/3J7hAreFunDQ9HpV3chddf8TbfiyB0QqlV9X971/CcbOJ9h1HVLWRdI90+E527Dc1vyaZEDayXe9teEK0JUADGyb72YZ4pXJ1/xh7+QsiKdBOcppqmJMn4iIj5pRaPnYK9MXDjwQUjzbW1IOnbcPed1oqx5eeca/t4tL1oCGSPKnyc3aOmSYa9qHYS+E1BhwuRyJmFby7+6RbHLsRBawNtT9CFC9q4OUvCFJLwO8DQCEK20Gf9peHzcm5SZXHU1T2V8fXz1Q6cf3pEGlABX42SPxiq6E7zr70cI+o4zyDL2UDArNM/gLuUi0mHpbp5P4tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ecBxynenZxzCKTHdNJV7hK1tQq8CQDfdySbL8HCXrow=; b=sVJ5LhBvLLfIIwsnE5vnZvz8xwjECW3Q5r2ZdOck4iMQ/JXfwWdirjBkhzBztczqnBFNmocv26vartDdhEBcPwSTaTSs9hUR268uWPnroBukAiBhyBBfqZsepxxxjHZ0XHUkJn6nL5a5SEzgjo6KN5M2dY+xedxjBJrFdlrrJkhbktxKwPxv9Tg+wcw3q61Y8urM/pgjyVTmbTpQcRu0sRogp12sK8+y3+efv6CUOxQ/3qxUkQF0EwnIECSLlY2iSthHDvW6kamqhTGSN6hYVG5RYLyUzla76Y8DKnWj5a9RYZIZi8jZfstF/O7wjm2ef7aNRZli8boiJ3B4X+WjAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: "lake@ietf.org" Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4ifJvzqXdSI0a5MKRvRKOSqqw07yMA///R8YA= Date: Thu, 16 Dec 2021 12:59:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22476c6e-7ec7-4f1b-4d5a-08d9c093f4aa x-ms-traffictypediagnostic: PH1P110MB1129: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fYam11mQCIm5HMeAUmUQCvdHT94qKusqgsvTVpSKrwBZXJJ10Q89EWCiGWN+pLZ+Q/NR5tR1vcWa1VIaxfbRSOlo/qbYeawkCNlrrcY/de9wTXtA5KglrpX5UhAV4rPy75WElT/RhNNuhj+8iAHU/WCtIwaYfI82Up5fL5iPM/LHdB7ptPoSVu7JBTaR/kgfbt9t+fLY4B/9FzBGDOtI1Z2Jzw3b6Fr6el96f2ifA/YsQtQXIaeoJdG40s9ZEurELNlhXXIloyXwuLCsbfA69VHMnNuHo9xNR5kS9ADnpNJxkjQ58+DhyDDDD+oM00/qmCT1nidlRLmoCPYLLCRDbhdP0pUfYgTps7EPUFj9FgiOMF5qrTnoJPt5FNxHR9nmDdxBH3sEyMi0UWyj8QNpugjCmbpQ5s1p9jfCTMzFNI9BLmrWpvwUHY/nRDPcPJNHExIvHmESSUkztDpG1uUvnjamELfdzpTw+f/tp08dP0O+XZCzpPZpfo2yByoOWQg/F9SGEsexEAqiH4iOCEvC9+9U3S0uX9f4/J88oKk2eAZmeh41NaDMVUlYEh4mRfTeR+KQ02K6+zy0hXIOSZ1h9fhhTdgRkHRSL1tMNwyafI3GvTyd1/Xd0kvVC1cFeEKgHHvXOVT8HDnNUartVbDQ9SKq04UX/jo5DbZvdS5TkY1yzQnPmxHQXjm2auA9mfa4AEEy4FazEP58tuGV/m+QfvM2oDNetqL+j7VldsoEvMnoPFt1PMbZknqWqXKPTMAvVEEAJONqQHPFxueBsKmc2fySI83u6x1dSWj+bzVJ8viNvpG4qXSIXStmZ13nNXIE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH1P110MB1412.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(86362001)(66946007)(26005)(71200400001)(6916009)(8676002)(83380400001)(6486002)(53546011)(75432002)(76116006)(66446008)(8936002)(66574015)(66556008)(6506007)(186003)(66476007)(2906002)(64756008)(33656002)(966005)(38100700002)(498600001)(166002)(99936003)(6512007)(5660300002)(122000001)(2616005)(38070700005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VGsxaHRNOFFPd2JQdGtQZ245QklDR3NsYU93eSsxUUhnSWdYR2VVTXNJRVdR?= =?utf-8?B?YnY0ajNDZkF2aTVtRmFNVTdORFhBRmNGZC9Vd21oWWg2S1dOTndFUjBnZ3Jz?= =?utf-8?B?bFlXNmw1dHVLdXA3NXNtVjA3Yk9jZHIrTllWcUJSejBCSjJNQXJnWUY5SHFy?= =?utf-8?B?LzZ4OE5Ya01RcGpZdjJRaVJ2QVB1NjFzM291b09tRjcra1Z6VlpxUW93Vmtn?= =?utf-8?B?OVJ4dXNhTXZGSnpPU3VJYTdsamF3RWpIMVREWVc5amx4R2RKaDkrT1B2ZVRY?= =?utf-8?B?d1d5RVlLVEd6Q0R1cDF1eFR2OHNZcS94aDh6TUlPZGNzd0NYNjJpenVXeXU3?= =?utf-8?B?VXE5R1VZWnRaRU44RWZ5NUNDT1V6NURKZDA3U3FmNExpOFoxMnJ3bUtaUFZU?= =?utf-8?B?TmtUNnZRcDZWa3laZmJMSTcydTE1a0p5azFTQW5uZFJDVEU2ajY4RlJheXpt?= =?utf-8?B?b3Zaa2JDVXhDVVBjT0txNXNvTGxBOUFLSEpGV0pIeWp4dG5tck5nZjd6ZTBT?= =?utf-8?B?TndocnJhWlRmUWlRTjJsMVlyR0FqWk1Ud0pQQkdpUWpIazBTQlhPZURYcWpp?= =?utf-8?B?WUpQZDRkVFBWa0xKQjYwMWZBRm5HOUlQbUt5UHhwZjh5NTVwdTJtMDViTHBu?= =?utf-8?B?c3U0cVRlK3o2bmY1bWRWRnJnaFQ5TjZnbnhsdTY4NjVWYWw4WlVSOXM5cWc3?= =?utf-8?B?OElkcnZRZXpreEVmNkRDeWU1N0tlYlI0WVE3eGJWMFZCWmZ0NDc4ejlzcnUz?= =?utf-8?B?eGE1YXJobkwzR2kzMm9UTWNzN2dDUGwxRG5rU0N3V0lQQmxZemlPTnFtR3NQ?= =?utf-8?B?TkszcXpqcnY0bTl1aWcrQmtmNzl1ek1nQmJTOU9pdG9OVmE4VUx0TlROV3lU?= =?utf-8?B?UFlRTndDRmtTYjRpeEllV2tuWVZEMkhXcUgwODN6UUgxMUlDNDh4a3JJSmdM?= =?utf-8?B?bWszdkJvWHJWTlRWVjhUS29RTFdPb0tTenpKOXM4L0ZURC90VXM0TWMyUFFS?= =?utf-8?B?SFZ2Zi9ZVEJoYXUwbUpsSE9XcTlacFladHJvanFDQ3JEUk8xYjlNbFozbmMr?= =?utf-8?B?UlhMQ2cxMkJ3TDV0WjVuZHBWb0xPU2ZiZ0pGbUxWM1dRSmlpcW9qZVJOcTEv?= =?utf-8?B?NnZoMlI5WkRrMjlXQTdyZ2ZnbEdNT0NQRklNUllKNkhJZTdNb3hKdzFRVjRj?= =?utf-8?B?TCtaa2E5RDhHTUEwKzlXa1I0RXoyNEJkaXZkQ1MwbHBpYkI0dU9KNW16bFJR?= =?utf-8?B?cVNIei9nMFVYVFdaTFhXYTVDekg0UFhzWEZ4L21oMnBOamUxa1NURnM2WGo4?= =?utf-8?B?aHMybE5KS245WGkwUnk2UTlvZVVVNEx0bXRMdk5MT1FWNnlYQmpYOVRseFY3?= =?utf-8?B?NThHVGtnTGZ5U0Z4YzV6MkIxRG96SVV2K2tteVo1Z1g5QThSTTg0R1NKYWQv?= =?utf-8?B?OGZGWGVGalFFMHlrQlVxNmJpQ2Y5WDh2NmJaWDF1R0tvN2ZZM1ZkdlVCV2pH?= =?utf-8?B?c0g2NWZBR2JraVZLMmVCeUpyQzhoOHpXOVBaOW1Hb0J1MTkxNzBtTE1MNTF2?= =?utf-8?B?ZVp1aHVYWGt3eVQyajJLTzE3N3RNa2JLcG5idTYzZUlHK29Mb3FLUHk3NGRM?= =?utf-8?B?cDRwcmdJWXFhOTJhaHIxeUsvZ1JGV0lpaVFDdnkyVS9sdEdUYUl3MkJ0RDA3?= =?utf-8?Q?b8c5OBixPD4acx0JyN2j?= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3722486393_1106560037" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH1P110MB1412.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 22476c6e-7ec7-4f1b-4d5a-08d9c093f4aa X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2021 12:59:54.6505 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH1P110MB1129 X-Proofpoint-ORIG-GUID: J88CoI5w5i10bCbm0W-oojtQ9_oQy_MH X-Proofpoint-GUID: J88CoI5w5i10bCbm0W-oojtQ9_oQy_MH X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-16_04:2021-12-15, 2021-12-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 malwarescore=0 spamscore=0 adultscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112160072 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 13:00:05 -0000 --B_3722486393_1106560037 Content-type: multipart/alternative; boundary="B_3722486393_805614599" --B_3722486393_805614599 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Speaking of MTI suites =E2=80=93 I=E2=80=99d like to see at least one offering 256-bit = level of security. =20 -- Regards, Uri =20 There are two ways to design a system. One is to make it so simple there ar= e obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. = - C. A. R. Hoare =20 =20 From: Lake on behalf of G=C3=B6ran Selander Date: Thursday, December 16, 2021 at 05:46 To: Mali=C5=A1a Vu=C4=8Dini=C4=87 , "lake@ietf.org" Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite =20 Hi Mali=C5=A1a, =20 This mail is not responding to your questions below, more a comment about p= rocess.=20 =20 I was surprised to have this discussion in the meeting yesterday since the = intent was to talk about Stefan's proposal (issue #209) and not the overall = MTI topic (issue #22), for which John had started another mail thread:=20 =20 https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/ =20 As Carsten pointed out the issues are orthogonal. If the WG decides on "MUS= T implement cipher suite 2" on #22, we would also mandate cipher suite 3 if = we follow the proposal in #209. (If anyone disagrees to that, please post in= #209.) =20 I think it would be good if people who have an opinion on the topic respond= s to John's mail which summarizes the previous discussion well. There is als= o a proposal for procedure to come to a decision at the end to his mail. Wha= tever procedure we take it would be great if the chairs would announce in ad= vance to allow those who have a strong opinion to take part in the thread an= d the decision. =20 G=C3=B6ran =20 =20 From: Lake on behalf of Mali=C5=A1a Vu=C4=8Dini=C4=87 Date: Thursday, 16 December 2021 at 10:19 To: lake@ietf.org Subject: [Lake] Ambiguous text on Mandatory to Implement suite All, (chair hat off) As discussed during the interim yesterday, the current text in -12 on MTI r= equirements (Section 7) reads as follows: > For many constrained IoT devices it is problematic to support more > than one cipher suite. Existing devices can be expected to support > either ECDSA or EdDSA. To enable as much interoperability as we can > reasonably achieve, less constrained devices SHOULD implement both > cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES- > CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA- > 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained > endpoints SHOULD implement cipher suite 0 or cipher suite 2. > Implementations only need to implement the algorithms needed for > their supported methods. I see two issues here: 1) imprecise language; 2) normative text that implie= s interoperability only in case when both peers implement both suites 0 and = 2. When it comes to the devices and their capabilities, we have so far been us= ing the precisely defined terms from RFC 7228. This is not the case here and= we use terms such as =E2=80=9Cless constrained devices=E2=80=9D, =E2=80=9Cconstrained endpoin= ts=E2=80=9D. This is all very confusing. Why endpoint and not device? What does =E2=80= =9Cless constrained device=E2=80=9D actually mean in terms of RFC 7228? Assuming that the =E2=80=9Cconstrained endpoint=E2=80=9D is a typo and instead means =E2=80= =9Cconstrained device=E2=80=9D, the normative statement in this text, i.e. implement= ing 0 OR 2, implies that we can achieve interoperability only in the case wh= en both peers implement both 0 and 2 cipher suites. Requiring the implementa= tion of two cipher suites on each device to achieve interoperability is far = from the lightweight aspect of LAKE, so I would like to hear what are the wo= rking group=E2=80=99s thoughts on this. Mali=C5=A1a --=20 Lake mailing list Lake@ietf.org https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-4544455557= 31-49a34bb25e2c1426&q=3D1&e=3Dad041382-e3a6-40b4-a5f3-15ae63819e02&u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake --B_3722486393_805614599 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Speaking of MTI suites =E2=80=93 I=E2=80=99d like to see at least one offering= 256-bit level of security.

 

--

Regards,=

Uri=

 

<= i>There are two ways to design a = system. One is to make it so simple there are obviously no deficiencies.

The other is to= make it so complex there are no obvious deficiencies.

=      &nb= sp;              = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;           -&nbs= p; C. A. R. Hoare=

 

 

From: Lake <lake-bounces@ietf.org> on b= ehalf of G=C3=B6ran Selander <goran.selander=3D40ericsson.com@dmarc.ietf.org>= ;
Date: Thursday, December 16, 2021 at 05:46
To: Mali=C5=A1a= Vu=C4=8Dini=C4=87 <malisa.vucinic@inria.fr>, "lake@ietf.org" <la= ke@ietf.org>
Subject: Re: [Lake] Ambiguous text on Mandatory to= Implement suite

 

=

Hi Mali=C5=A1a,

 

This mail is= not responding to your questions below, more a comment about process. =

 

I was surprised to have this disc= ussion in the meeting yesterday since the intent was to talk about Stefan's = proposal (issue #209) and not the overall MTI topic (issue #22), for which J= ohn had started another mail thread:

 <= /span>

https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_l= saM/

 

As Carsten pointed out t= he issues are orthogonal. If the WG decides on "MUST implement cipher s= uite 2" on #22, we would also mandate cipher suite 3 if we follow the p= roposal in #209. (If anyone disagrees to that, please post in #209.)

 

I think it would be good if people w= ho have an opinion on the topic responds to John's mail which summarizes the= previous discussion well. There is also a proposal for procedure to come to= a decision at the end to his mail. Whatever procedure we take it would be g= reat if the chairs would announce in advance to allow those who have a stron= g opinion to take part in the thread and the decision.

=

<= o:p> 

G=C3=B6ran

 

 

From: Lake <lake-bounces@ietf.org> on behalf of Mali=C5=A1a= Vu=C4=8Dini=C4=87 <malisa.vucinic@inria.fr>
Date: Thursday, 16 Dece= mber 2021 at 10:19
To: lake@ietf.org <lake@ietf.org>
S= ubject: [Lake] Ambiguous text on Mandatory to Implement suite=

All,

(chair hat off)

As discussed during = the interim yesterday, the current text in -12 on MTI requirements (Section = 7) reads as follows:

>    For many constrained IoT = devices it is problematic to support more
>    than one= cipher suite.  Existing devices can be expected to support
>&nbs= p;   either ECDSA or EdDSA.  To enable as much interoperabili= ty as we can
>    reasonably achieve, less constrained = devices SHOULD implement both
>    cipher suite 0 (AES-= CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-
>    CCM= -16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA-
>&nbs= p;   256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256).  Cons= trained
>    endpoints SHOULD implement cipher suite 0 = or cipher suite 2.
>    Implementations only need to im= plement the algorithms needed for
>    their supported = methods.

I see two issues here: 1) imprecise language; 2) normative t= ext that implies interoperability only in case when both peers implement bot= h suites 0 and 2.

When it comes to the devices and their capabilities= , we have so far been using the precisely defined terms from RFC 7228. This = is not the case here and we use terms such as =E2=80=9Cless constrained devices=E2=80=9D= , =E2=80=9Cconstrained endpoints=E2=80=9D. This is all very confusing. Why endpoint and = not device? What does =E2=80=9Cless constrained device=E2=80=9D actually mean in terms o= f RFC 7228?

Assuming that the =E2=80=9Cconstrained endpoint=E2=80=9D is a typo an= d instead means =E2=80=9Cconstrained device=E2=80=9D, the normative statement in this te= xt, i.e. implementing 0 OR 2, implies that we can achieve interoperability o= nly in the case when both peers implement both 0 and 2 cipher suites. Requir= ing the implementation of two cipher suites on each device to achieve intero= perability is far from the lightweight aspect of LAKE, so I would like to he= ar what are the working group=E2=80=99s thoughts on this.

Mali=C5=A1a

--=
Lake mailing list
Lake@ietf.org
https:= //protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-454445555731-49a3= 4bb25e2c1426&q=3D1&e=3Dad041382-e3a6-40b4-a5f3-15ae63819e02&u=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake

--B_3722486393_805614599-- --B_3722486393_1106560037 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAUW1xDL1n3IkFBHAAAABRbXMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMjEwNzA2MjM0ODI1WhcNMjYwMzAy MjM1OTU5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMRXUPN5Fz28jb9GOca2/6HDq5EE4Hu T1enB0TiMEnOTipW88pgPmSZ/AAFyJF7AWX7PYPw94Ed/Bbs7yCCa6WZS7cQzdHOWppx9gRZ AxkR8+TgosxPcHoCMXmI/hXtVdZ7mwZlpBGJvyBe6YRmxOWLl3WiCRi/gBThwEWsiQZOfhEN 7hC2GhgCKetpNlTRPxslLmkStNlnjNAxhet8Vm/KSYJFVPOx3qytdLwnO6sz4AfIJJQkFX26 6oP0F/4bjRGlIZrZpdUPGiydpJl1r5SRcYs1ZE7JHErULWSyiAIzBDHUCTcN2GnFoR+9fz92 q2VIHvNHx7bV1hd0E0zlC9UCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBSQ5IixU+wo9uUYNUB4 G/ea7vuWEjAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAICZO a7qQQMDGZzRUaX+Mm/3meVo0nTEdNby178MGq6uYGUS4keIkljEoI+KiEMbT8rtCOBZwomnO HdJmLuRUEgrVAos27V4yjvoic8QKsz+qEhxslFg/2EYMAbTsyLqg34R+wG5o6K95ohUrgLud fPxAmcLOFBtIZBr/3DUIlzw4xHKiX2ruex7YOrQccgXb2qGtNB7tG6jAaXqFb+NZTJhj+3pd OiZiZanzpZvPLIH6Xe4awqDrok7q9ImwwSSQorNrJxKKtA3vLUW3DGvom3XDiOjDqpzhmqXC u6Wf7JfrSJRaudU2WyvYfPk7NQlkLR/1G6Xz+zKqO/cBt2aNATGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDKjeD+HAaZu8FY3qiw8L2l8VxHsAKZusgDohdK DezmxDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEyMTYx MjU5NTNaMA0GCSqGSIb3DQEBAQUABIIBAA9of6UuGX4JyAJKrsMU4NUY0nSOw1hD8ctonnFG dJK+709px6eUneGqwnTuJQBFYUsB2oxOPBUJdD+zWXe0HdNbADnBEOXcELVVnC7CAu6Sf21/ JYAfJPTy7Y1W4CNyAvHJf/p7SAsttcLuEdtvEcQCmUuslvhn2HFe0qcvkh9LLPgEQZfEl91+ Koo+Bl1g3BM/UgikPFpNNOXtXn3ikemYW1EJsaZGU/FnDu1o0ACqLjFfoo5ZmtBreHj+zTMr RJAFC0qe7XfLNf4/JPcuFjHX8tBxW1/Xbz/4l5HWO5mpYNxY7YmoXp4v5+cU5OLvtVp8zYcK ruj1H/ErStxJ0Ck= --B_3722486393_1106560037-- From nobody Thu Dec 16 05:27:46 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542B23A0EA4 for ; Thu, 16 Dec 2021 05:27:44 -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 nGQrjD2xj_DY for ; Thu, 16 Dec 2021 05:27: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 E4FF73A0EA0 for ; Thu, 16 Dec 2021 05:27:38 -0800 (PST) IronPort-Data: =?us-ascii?q?A9a23=3ApgyDR6va9B22L3Jheeq7iDZJYOfnVGBcMUV32f8?= =?us-ascii?q?akzHdYEJGY0x3yGodXT/SaKqPZmb8e912PIng/UoB7MeBy4BhTQBuqiFgHilAw?= =?us-ascii?q?SbnLYTAfx2oZ0t+DeWaERk5t51GAjX4wXFdokb0/n9BCZC86yksvU20buCkUre?= =?us-ascii?q?dYHkvHVUMpBoJ0nqPpcZo2+aEvvDpW2thifuqyyHuEAfNNwxcagr42IrfwP9bh?= =?us-ascii?q?8kejRtD1rAIiV+ni3eF/5UdJMp3yahctBIUSKEMdgKxb76rIL1UYgrkExkR5tO?= =?us-ascii?q?Nyt4Xc2URR6LKNgyPh3xKHaG6mhxPzsAw+vlqcqNAMgEO0mzPxo4qoDlOncXYp?= =?us-ascii?q?QMBO6TImf8UFQdFGCB4PKZu+bndIHH5v9b7I0juKCGwma0/ZK0xFchCkgptOkl?= =?us-ascii?q?B8uYRLnYWYxSKge672pq2UOhnnd8kKo/gO4Z3knVpzjzxDPs6T9bEWaqi2DPy9?= =?us-ascii?q?F/cnegRTLCHO5FfMGM2Kk2eOHVy1p4sIMpWtI+VarPXKVW0cG6omJc=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AnkHncKv40BNF6zpwRCOteyfH7skDutV00zEX?= =?us-ascii?q?/kB9WHVpm6yj+vxGUs5rryMc7wxhJE3I+OrwRZVoJEmsiqKdjrNhWotKMDOW3F?= =?us-ascii?q?dAabsSiLcKoAeQeBEWlNQtrJuIGpIWYLabYTdHZITBkWuF+r0bsaG6Gc6T9Jzj?= =?us-ascii?q?JrRWIz1CWuVP6w94D0K8CU15RA5PAN4cGICH7sRK4xqMEE5nCPhTykNlYwELnb?= =?us-ascii?q?32qK4=3D?= X-IronPort-AV: E=Sophos;i="5.88,211,1635199200"; d="scan'208,217";a="324209" Received: from unknown (HELO smtpclient.apple) ([79.143.111.163]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2021 14:27:36 +0100 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_44A4DECC-585E-474B-8E65-20C3B3EE0DD4" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Thu, 16 Dec 2021 14:27:27 +0100 In-Reply-To: Cc: "lake@ietf.org" To: =?utf-8?Q?G=C3=B6ran_Selander?= References: X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 13:27:44 -0000 --Apple-Mail=_44A4DECC-585E-474B-8E65-20C3B3EE0DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Goran, My email was not a process-related email, thus the hats off disclaimer. = I suppose we should make out of it another complimentary issue and just = make sure that we have clear language in the spec. Mali=C5=A1a > On 16 Dec 2021, at 11:44, G=C3=B6ran Selander = wrote: >=20 > Hi Mali=C5=A1a, > =20 > This mail is not responding to your questions below, more a comment = about process. > =20 > I was surprised to have this discussion in the meeting yesterday since = the intent was to talk about Stefan's proposal (issue #209) and not the = overall MTI topic (issue #22), for which John had started another mail = thread:=20 > =20 > = https://mailarchive.ietf.org/arch/msg/lake/75nRaD6czYG6RqLT06Qe8C_lsaM/ = > =20 > As Carsten pointed out the issues are orthogonal. If the WG decides on = "MUST implement cipher suite 2" on #22, we would also mandate cipher = suite 3 if we follow the proposal in #209. (If anyone disagrees to that, = please post in #209.) > =20 > I think it would be good if people who have an opinion on the topic = responds to John's mail which summarizes the previous discussion well. = There is also a proposal for procedure to come to a decision at the end = to his mail. Whatever procedure we take it would be great if the chairs = would announce in advance to allow those who have a strong opinion to = take part in the thread and the decision. > =20 > G=C3=B6ran > =20 > =20 > From: Lake on behalf of Mali=C5=A1a Vu=C4=8Dini=C4= =87 > Date: Thursday, 16 December 2021 at 10:19 > To: lake@ietf.org > Subject: [Lake] Ambiguous text on Mandatory to Implement suite >=20 > All, >=20 > (chair hat off) >=20 > As discussed during the interim yesterday, the current text in -12 on = MTI requirements (Section 7) reads as follows: >=20 > > For many constrained IoT devices it is problematic to support = more > > than one cipher suite. Existing devices can be expected to = support > > either ECDSA or EdDSA. To enable as much interoperability as we = can > > reasonably achieve, less constrained devices SHOULD implement = both > > cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, = AES- > > CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, = SHA- > > 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained > > endpoints SHOULD implement cipher suite 0 or cipher suite 2. > > Implementations only need to implement the algorithms needed for > > their supported methods. >=20 > I see two issues here: 1) imprecise language; 2) normative text that = implies interoperability only in case when both peers implement both = suites 0 and 2. >=20 > When it comes to the devices and their capabilities, we have so far = been using the precisely defined terms from RFC 7228. This is not the = case here and we use terms such as =E2=80=9Cless constrained devices=E2=80= =9D, =E2=80=9Cconstrained endpoints=E2=80=9D. This is all very = confusing. Why endpoint and not device? What does =E2=80=9Cless = constrained device=E2=80=9D actually mean in terms of RFC 7228? >=20 > Assuming that the =E2=80=9Cconstrained endpoint=E2=80=9D is a typo and = instead means =E2=80=9Cconstrained device=E2=80=9D, the normative = statement in this text, i.e. implementing 0 OR 2, implies that we can = achieve interoperability only in the case when both peers implement both = 0 and 2 cipher suites. Requiring the implementation of two cipher suites = on each device to achieve interoperability is far from the lightweight = aspect of LAKE, so I would like to hear what are the working group=E2=80=99= s thoughts on this. >=20 > Mali=C5=A1a >=20 > --=20 > Lake mailing list > Lake@ietf.org > = https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d327-4544455= 55731-49a34bb25e2c1426&q=3D1&e=3Dad041382-e3a6-40b4-a5f3-15ae63819e02&u=3D= https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flake = --Apple-Mail=_44A4DECC-585E-474B-8E65-20C3B3EE0DD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Goran,

My email was = not a process-related email, thus the hats off disclaimer. I suppose we = should make out of it another complimentary issue and just make sure = that we have clear language in the spec.

Mali=C5=A1a

On 16 Dec 2021, at 11:44, G=C3=B6ran Selander <goran.selander@ericsson.com> wrote:

Hi Mali=C5=A1a,
 
This mail is not = responding to your questions below, more a comment about process.
 
I was surprised to = have this discussion in the meeting yesterday since the intent was to = talk about Stefan's proposal (issue #209) and not the overall MTI topic = (issue #22), for which John had started another mail thread: 
 
 
As Carsten pointed = out the issues are orthogonal. If the WG decides on "MUST implement = cipher suite 2" on #22, we would also mandate cipher suite 3 if we = follow the proposal in #209. (If anyone disagrees to that, please post = in #209.)
 
I think it would be = good if people who have an opinion on the topic responds to John's mail = which summarizes the previous discussion well. There is also a proposal = for procedure to come to a decision at the end to his mail. Whatever = procedure we take it would be great if the chairs would announce in = advance to allow those who have a strong opinion to take part in the = thread and the decision.
 
G=C3=B6ran
 
 

From: Lake <lake-bounces@ietf.org> on behalf of Mali=C5=A1a = Vu=C4=8Dini=C4=87 <malisa.vucinic@inria.fr>
Date: Thursday, 16 December = 2021 at 10:19
To: lake@ietf.org <lake@ietf.org>
Subject: [Lake] Ambiguous text = on Mandatory to Implement suite

All,

(chair hat off)

As discussed during the interim yesterday, the = current text in -12 on MTI requirements (Section 7) reads as follows:

>    For many constrained = IoT devices it is problematic to support more
>    than one cipher suite.  Existing = devices can be expected to support
>    = either ECDSA or EdDSA.  To enable as much interoperability as we = can
>    reasonably achieve, less = constrained devices SHOULD implement both
>    cipher suite 0 (AES-CCM-16-64-128, = SHA-256, 8, X25519, EdDSA, AES-
>    = CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA-
>    256, 8, P-256, ES256, = AES-CCM-16-64-128, SHA-256).  Constrained
>    endpoints SHOULD implement cipher = suite 0 or cipher suite 2.
>    = Implementations only need to implement the algorithms needed for
>    their supported methods.

I see two issues here: 1) imprecise language; = 2) normative text that implies interoperability only in case when both = peers implement both suites 0 and 2.

When = it comes to the devices and their capabilities, we have so far been = using the precisely defined terms from RFC 7228. This is not the case = here and we use terms such as =E2=80=9Cless constrained devices=E2=80=9D, = =E2=80=9Cconstrained endpoints=E2=80=9D. This is all very confusing. Why = endpoint and not device? What does =E2=80=9Cless constrained device=E2=80=9D= actually mean in terms of RFC 7228?

Assuming= that the =E2=80=9Cconstrained endpoint=E2=80=9D is a typo and instead = means =E2=80=9Cconstrained device=E2=80=9D, the normative statement in = this text, i.e. implementing 0 OR 2, implies that we can achieve = interoperability only in the case when both peers implement both 0 and 2 = cipher suites. Requiring the implementation of two cipher suites on each = device to achieve interoperability is far from the lightweight aspect of = LAKE, so I would like to hear what are the working group=E2=80=99s = thoughts on this.

Mali=C5=A1a

-- 
Lake mailing = list
Lake@ietf.org
https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-fe22d= 327-454445555731-49a34bb25e2c1426&q=3D1&e=3Dad041382-e3a6-40b4-a5f= 3-15ae63819e02&u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fl= ake

= --Apple-Mail=_44A4DECC-585E-474B-8E65-20C3B3EE0DD4-- From nobody Thu Dec 16 07:23:47 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6603A1008 for ; Thu, 16 Dec 2021 07:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 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, NICE_REPLY_A=-1.852, 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 xqvdBSSdnykC for ; Thu, 16 Dec 2021 07:23:41 -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 78C103A1001 for ; Thu, 16 Dec 2021 07:23:41 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id m192so23600707qke.2 for ; Thu, 16 Dec 2021 07:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to:content-transfer-encoding; bh=vjNkpo5D46iVp/9ROYQiBnfMYHJQAKbR0ZHI80P/9Yw=; b=IrFPearmgJ1E8HEch02jgy9rkmkM8M4PRcoY1uVLZjUCvz/1eVrbecm1MECXEBCbM7 Dl1RVCH0vnhKup0RGKwd3ADCdGvFO9Pm9rjdfF//16iM72NSlzVknurIxO7mpHS18vvp w5WHwC9HgLSlVE7TYhrQITMxBzvkPy6LHCzAcYwr3lSyllsIp5pVf3dyggT149kZd2KY 1e6yjuTr+QA5qlioApuQn27Rhic2sqQ99C592EASjkNloR6zRiiiBXlzgCG/9vsGDFwe 4znD/WshAGY4YQhqgHMKutR2qGuWE1ERjCyAA/fhsZ2IEcO9yu+V4iTU4jY+UGrMUYn7 NSgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=vjNkpo5D46iVp/9ROYQiBnfMYHJQAKbR0ZHI80P/9Yw=; b=UK6J6PlVFgmRqkX1GxsZcvEfMmRjzLb/PqaV+YL/GP42w7XDZaiIepPY7Yd3tu7e4r 8a631Hd9akczz6/C9fXfn7BS+heGVK8gC48tl6dZIeUG+NVaIoeD3GImEbHqx+ryf3fO NB6rHL+IgblIvung2CGWT+0KKURrB0gfrGPcMdvPG1WqciezYHe8F/FI0whHFDfFrk1+ F8+CMy7D6RJGm0pOn4+ghPI5+E0eF1xF395rwwQSEL/qNKb9z9RHwKv9CWe4IQVlJTob Lqmz94JWppLcehLejNBFxQYrwb1iVssaF0vmsw+Fp1O/PZy7NYU+onWOHxBNFhHgaj4p a/Dg== X-Gm-Message-State: AOAM531dzjUyuBwnWuawipqtjw9TJzWNmtNkoPxonzuE8APXh5MSLlX1 EuvvLKK/lVW5GspOLEiZlhFu0U0HNpI= X-Google-Smtp-Source: ABdhPJyfl2mbFGpQan/5xpTEFc+eDBrr3plHUuq6tg3OlUxJcverkX1euEKRK49Wr+r6ZizYU03i7w== X-Received: by 2002:a05:620a:886:: with SMTP id b6mr12743740qka.332.1639668219567; Thu, 16 Dec 2021 07:23:39 -0800 (PST) Received: from ?IPV6:2607:fea8:8a0:1397:c5ec:34d3:c298:1de4? ([2607:fea8:8a0:1397:c5ec:34d3:c298:1de4]) by smtp.gmail.com with ESMTPSA id b6sm4303072qtk.91.2021.12.16.07.23.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 07:23:38 -0800 (PST) Message-ID: <487f30c8-392e-d2ae-1c6b-72e254c2b607@gmail.com> Date: Thu, 16 Dec 2021 10:23:20 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , lake@ietf.org References: From: Rene Struik In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 15:23:46 -0000 Hi Malisa: If one has to implement both Suites #0 and #2, one has to implement both SHA-512 and SHA-256 (since EdDSA uses SHA-512 under the hood). I still do believe EdDSA is insecure in the environments this WG is targeting and should be ditched. How can one still possibly defend including a deterministic signature scheme in a specification that clearly contravenes the stability and side-channel resistance stipulations for MTI algorithms of BCP 201/RFC 7696, despite dozens of publications about trivial implementation attacks? Please also see my email of  a year ago, Dec 18, 2020, on Guidance on MTI algorithms [1]. It is too bad that nobody ever pursued attempts to rectify this (such as in https://datatracker.ietf.org/doc/draft-mattsson-cfrg-det-sigs-with-noise/, originally suggested two years ago, on Dec 17, 2019). Pretending that the issue is going away is without action is, however, not credible. {Of course, one could still try and stick an RFC 8032 label on something that isn't, but I wonder whether IETF would then devalue to simply a marketing label issuing body, where an external shadow spec would have to redefine things to make specs work. } Currently, the only secure signature scheme that uses Curve25519 under the hood is ECDSA25519, as specified in the lwig curve document [2]. This scheme also uses SHA256 as hash function, thereby obviating the need to implement two hash functions if one were to have to implement both the "NIST" suite and another one. Side question: whatever happened with the suggestion in John Mattson's Feb 11, 2021 email re including ECDSA25519 in the formal analysis [3]? Ref: [1]https://mailarchive.ietf.org/arch/msg/lake/_sy7LSHk8idGAV_408JQOafi6LQ/ [2] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-22#section-4.3 [3] https://mailarchive.ietf.org/arch/msg/lake/UYaV56yxz_zUWOqU32SoVozSw4I/ On 2021-12-16 4:19 a.m., Mališa Vučinić wrote: > All, > > (chair hat off) > > As discussed during the interim yesterday, the current text in -12 on MTI requirements (Section 7) reads as follows: > >> For many constrained IoT devices it is problematic to support more >> than one cipher suite. Existing devices can be expected to support >> either ECDSA or EdDSA. To enable as much interoperability as we can >> reasonably achieve, less constrained devices SHOULD implement both >> cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES- >> CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA- >> 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained >> endpoints SHOULD implement cipher suite 0 or cipher suite 2. >> Implementations only need to implement the algorithms needed for >> their supported methods. > I see two issues here: 1) imprecise language; 2) normative text that implies interoperability only in case when both peers implement both suites 0 and 2. > > When it comes to the devices and their capabilities, we have so far been using the precisely defined terms from RFC 7228. This is not the case here and we use terms such as “less constrained devices”, “constrained endpoints”. This is all very confusing. Why endpoint and not device? What does “less constrained device” actually mean in terms of RFC 7228? > > Assuming that the “constrained endpoint” is a typo and instead means “constrained device”, the normative statement in this text, i.e. implementing 0 OR 2, implies that we can achieve interoperability only in the case when both peers implement both 0 and 2 cipher suites. Requiring the implementation of two cipher suites on each device to achieve interoperability is far from the lightweight aspect of LAKE, so I would like to hear what are the working group’s thoughts on this. > > Mališa > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 From nobody Thu Dec 16 07:44:04 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B81F3A1033 for ; Thu, 16 Dec 2021 07:44:01 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 NmLTzdW0pa08 for ; Thu, 16 Dec 2021 07:43: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 5E1053A102D for ; Thu, 16 Dec 2021 07:43:55 -0800 (PST) IronPort-Data: =?us-ascii?q?A9a23=3AMTBLga0+2VvN2965a/bD5fxzkn2cJEfYwER7XOP?= =?us-ascii?q?LsXnJgjMngz0HmGEXW2zQP6rbYGT0fNl3boSw9E5XuceGz4A2QQE+nZ1PZyIT+?= =?us-ascii?q?JCdXbx1DW+pYnjMdpWbJK5fAnR3huDodKjYdVeB4Ef9WlTdhSMkj/jRHOOiULS?= =?us-ascii?q?s1h1ZHmeIdg9w0HqPpMZp2uaEsfDha++8kYuaT//3YDdJ6BYoWo4g0J9vnTs01?= =?us-ascii?q?BjEVJz0iXRlDRxDlAe2e3D4l/vzL4npR5fzatE88uJX24/+IL+FEmPxp3/BC/u?= =?us-ascii?q?+l6rjeUkLT7jOewGWkn5bM0SgqkcT4HVuieBibaNaMBkM49mKt4kZJNFlsJW0S?= =?us-ascii?q?BwgeLPRk+UbUhJwEidkPKQA9qWvzX2X6JXIkBycKSGEL/JGSRte0Zcj0vttAEl?= =?us-ascii?q?K8bodKSxLYxye78qyybG2YuhhmsplK9PkVL7zEFkIISrxUqdgGMyYBfyTvJkBg?= =?us-ascii?q?mxYuyyHJt6GD+JxVNalRE2ePXWj4msqNa8=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AgGBCE6gi3b1U8Cfdugg6rhgKqXBQXsMji2hC?= =?us-ascii?q?6mlwRA09TyVXraGTdZUgvyMc5wx+ZJhNo7u90de7Lk80hKQZ3WB5B97LYOCMgg?= =?us-ascii?q?eVxe9ZjbcKuweQeBHDyg=3D=3D?= X-IronPort-AV: E=Sophos;i="5.88,211,1635199200"; d="p7s'?scan'208,217";a="11379222" Received: from unknown (HELO smtpclient.apple) ([79.143.111.163]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2021 16:43:43 +0100 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3AB54C5C-BC76-4C16-8EDF-2675E8FEB253"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Thu, 16 Dec 2021 16:43:40 +0100 In-Reply-To: Cc: "lake@ietf.org" To: "Blumenthal, Uri - 0553 - MITLL" References: X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 15:44:02 -0000 --Apple-Mail=_3AB54C5C-BC76-4C16-8EDF-2675E8FEB253 Content-Type: multipart/alternative; boundary="Apple-Mail=_863DA93B-0A94-4E4C-BF24-21D9854D7449" --Apple-Mail=_863DA93B-0A94-4E4C-BF24-21D9854D7449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Uri, Cipher suites 24 and 25 are intended to be for high-security = applications [1]. Could you comment if these do not meet your needs?=20 [1] = https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-9.2= = Mali=C5=A1a > On 16 Dec 2021, at 13:59, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > Speaking of MTI suites =E2=80=93 I=E2=80=99d like to see at least one = offering 256-bit level of security. > =20 > -- > Regards, > Uri > =20 > There are two ways to design a system. One is to make it so simple = there are obviously no deficiencies. > The other is to make it so complex there are no obvious deficiencies. > = - C. A. = R. Hoare --Apple-Mail=_863DA93B-0A94-4E4C-BF24-21D9854D7449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Uri,

Cipher= suites 24 and 25 are intended to be for high-security applications [1]. = Could you comment if these do not meet your needs? 


Mali=C5=A1a

On 16 Dec 2021, at 13:59, Blumenthal, Uri - 0553 - MITLL = <uri@ll.mit.edu> = wrote:

Speaking of MTI suites =E2=80=93 I=E2=80=99d like to see at = least one offering 256-bit level of security.
 
--
Regards,
Uri
 
There are two = ways to design a system. One is to make it so simple there are obviously = no deficiencies.
The other is to = make it so complex there are no obvious deficiencies.
          &nb= sp;       =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =     -  C. A. R. Hoare
<= br class=3D"">
= --Apple-Mail=_863DA93B-0A94-4E4C-BF24-21D9854D7449-- --Apple-Mail=_3AB54C5C-BC76-4C16-8EDF-2675E8FEB253 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCB0Qw ggN+MIIDBKADAgECAhB2kCF9/l3WwsRQJ8Xc0VomMAoGCCqGSM49BAMDMIGIMQswCQYDVQQGEwJV UzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IEVDQyBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0yMDAyMTgwMDAwMDBaFw0zMzA1MDEyMzU5NTlaMEoxCzAJBgNVBAYTAk5M MRkwFwYDVQQKExBHRUFOVCBWZXJlbmlnaW5nMSAwHgYDVQQDExdHRUFOVCBQZXJzb25hbCBFQ0Mg Q0EgNDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBhnZxHg7m192ySDY02jfjo2jKh6dCNaFZAS VNBD5uuYzGvmV5bUB+kAn1uxpRp2wIkmcDnJwUhNiNd+X9e98+SjggGLMIIBhzAfBgNVHSMEGDAW gBQ64QmG1M8ZwpZ2dEl23OA1xmNjmjAdBgNVHQ4EFgQUqC1tgTJkjeayT6z+EfJlmYUTqW4wDgYD VR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMDgGA1UdIAQxMC8wLQYEVR0gADAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28u Y29tL0NQUzBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRy dXN0RUNDQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUF BzAChjNodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0RUNDQWRkVHJ1c3RDQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wCgYIKoZIzj0EAwMDaAAwZQIx AIJfo/faijtGIAiTUMh6RkycUZnBj7EmhnkfIKEZzU1y66meHsTO6SvUScv4zICE1wIwPoOVIxYT kj744G/OedfWemO+e0twqiACsA+MuCUYZ7KYW3hTql3Lv8LT+aIcI+4MMIIDvjCCA2OgAwIBAgIR AOvxfCqkar048v2ri/opeGwwCgYIKoZIzj0EAwIwSjELMAkGA1UEBhMCTkwxGTAXBgNVBAoTEEdF QU5UIFZlcmVuaWdpbmcxIDAeBgNVBAMTF0dFQU5UIFBlcnNvbmFsIEVDQyBDQSA0MB4XDTIxMTAx ODAwMDAwMFoXDTIzMTAxODIzNTk1OVowgaoxHjAcBgNVBAkTFUxBIFBMQUlORSBERSBWT0xVQ0VB VTEXMBUGA1UECAwOw45sZS1kZS1GcmFuY2UxCzAJBgNVBAYTAkZSMUkwRwYDVQQKE0BJTlNUSVRV VCBOQVRJT05BTCBERSBSRUNIRVJDSEUgRU4gSU5GT1JNQVRJUVVFIEVUIEVOIEFVVE9NQVRJUVVF MRcwFQYDVQQDEw5NYWxpc2EgVlVDSU5JQzB2MBAGByqGSM49AgEGBSuBBAAiA2IABBvUXPz6l0vv iwhyrUS51ClMIBlYcChYselkrF4kL1wYei6sJsz52uhxrQ44yW5t1ExfrBa6/PHa+I76rsbe84AN kVlsuBc0vmbeLdBKcsSuKtDZ0SItTOW3iFEkNbRgL6OCAaowggGmMB8GA1UdIwQYMBaAFKgtbYEy ZI3msk+s/hHyZZmFE6luMB0GA1UdDgQWBBTb3Gl52C8+lzZUVoSVUaFMdtN7wDAOBgNVHQ8BAf8E BAMCB4AwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwPwYDVR0g BDgwNjA0BgsrBgEEAbIxAQICTzAlMCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQ UzBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vR0VBTlQuY3JsLnNlY3RpZ28uY29tL0dFQU5UUGVy c29uYWxFQ0NDQTQuY3JsMHsGCCsGAQUFBwEBBG8wbTBABggrBgEFBQcwAoY0aHR0cDovL0dFQU5U LmNydC5zZWN0aWdvLmNvbS9HRUFOVFBlcnNvbmFsRUNDQ0E0LmNydDApBggrBgEFBQcwAYYdaHR0 cDovL0dFQU5ULm9jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXbWFsaXNhLnZ1Y2luaWNAaW5y aWEuZnIwCgYIKoZIzj0EAwIDSQAwRgIhAKgxyHzDZWljsM6Vq4XgOTM9ehZZ77V/Y8m726bb7NMo AiEAwhkZceKQ6LaoC1MQZSklNCXP95CK3MAz4XotwsYUSr0xggFVMIIBUQIBATBfMEoxCzAJBgNV BAYTAk5MMRkwFwYDVQQKExBHRUFOVCBWZXJlbmlnaW5nMSAwHgYDVQQDExdHRUFOVCBQZXJzb25h bCBFQ0MgQ0EgNAIRAOvxfCqkar048v2ri/opeGwwDQYJYIZIAWUDBAIBBQCgaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEyMTYxNTQzNDBaMC8GCSqGSIb3DQEJ BDEiBCBZ/XL0qijchPfuJjDyR1B4OuFAtmK8iAUO1fU/y+wvmTAJBgcqhkjOPQIBBGYwZAIwL54p oc2H1Ju3kNL3EgfMf7K/azBEV1fKh/qYdi/ejcRz27IsvBNpfl/u1DogFH7xAjB7m1L+WKa4eJS8 dtayn8mA2Q+HWL217AV+cEdrL9awqyOVpKFynDaHVoldtI6eCF4AAAAAAAA= --Apple-Mail=_3AB54C5C-BC76-4C16-8EDF-2675E8FEB253-- From nobody Thu Dec 16 08:38:42 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306D53A1143 for ; Thu, 16 Dec 2021 08:38:40 -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, 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 nwD7_PxRvwnq for ; Thu, 16 Dec 2021 08:38:35 -0800 (PST) Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 4DFE53A113E for ; Thu, 16 Dec 2021 08:38:34 -0800 (PST) Received: from LLEX2019-2.mitll.ad.local (llex2019-2.llan.ll.mit.edu [172.25.4.124]) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 1BGGcWXl168331 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Dec 2021 11:38:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=SnIE98sxQKbEakTrhntzyfXbwKrEXyW5ysjb0zle0kInkw60duKW/xcrRAiSq4fLOiBFU0OnNEKN9AHUqUcDoGHCQ2m2RZjAgmVS+KBCOHvICbyhl97Fl1DImTTdFZuqHf246cj7YTaWm55jhFdKxpQ/dk5cmNVR1pWWLrQTlpMFGFqWwiLuucAkSYDls+vBj3jGHoLlKbY30kTQhXE6GBYugHBaY0SkYQRyvUn5C3NJ4xf/Jtp85vcj1+9QxqC9Y6eeXoUPq3phwkhIng7ENB5HUyGFo8hfUKF3+HucAq23qN+SVEnxIk8Y5O3j79Apk6N4fwbVeDz2OcWjSUU3Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8T9mK9sw8aJjxNmcJaSeedV8+NIu7ooWWtqbA5YEzQM=; b=wixWoUTHaT5oDr8leAsNBW0vVr4Y+7eySlxlnfd4ThFWOiyntRGao3nJ9VOHr7oZ0iLzTIQ8wGYa1P/iNUni5AcBADoYd1mvrRhL23EcAzvsYjfIsJI9sNPeTuDROyx884Gyml8LBdcW/9SXTQHaG7ksbuusz8SuMFR5CDKbkz6mYVyuPNgT5tGM+Cg9+Heqa7bLQSzBNWd4rXbpv0PlnyETBxbomedsKaxzw0EIPpgQIQ9x2GZU29XgGfU7QQ017REAUTs6X2Dwbyddb5LHXLOo8XqybIIBW6BiUxNEAAnO8GbMMosCUD0HDClS86UA6L0O15HDcCUj9ahZCf3Eqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= CC: "lake@ietf.org" Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4ifJvzqXdSI0a5MKRvRKOSqqw07yMA///R8YCAAIGUAIAAD1GA Date: Thu, 16 Dec 2021 16:38:31 +0000 Message-ID: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d124e017-a830-4004-b861-08d9c0b27edf x-ms-traffictypediagnostic: PH1P110MB1330: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iZZNwcXaQJn8JILMjtiSyJPJ4vfkbjruHQ3ISIbwSyr07huuBBVQUssQeJ7tGh4j9HS7m2yaiXcXo8TNXp8P3L0+nZe0vt0VHbuEHcFFwxXqBbqzqg3aDWfBknYY2BVK5rwWsCphDAnZueTKbW3p+8cKM2a45NXjfG2TnffA09tNbWtd3C5xCg/fFf0pfEE6Y3+X0bWnxMCn8Jl4s6wkGjkm4yTAb+3zkyR0Fs5erCrs2ZJqb2f/EeQp+HLYRaAgtzr4KMtuQ9nfRSuxMcq0vGcCDw7y9b9idB0s8Kna7MEGLETncSKCaxd338O8k2kHTkK3sJ4gOleofwgY+oa+q76bNhUKNWqRleJ+Ide3nsyHERuPWwbiMROE6Lw+er/PW4+vcFXieIimjEk6ybEURT8/ek410dsAhty2Vf5o2XdnCpBJTyQ8eMIW+snUTzowntuluYffYyz7iduNa/8DH913SKZc/QbWSRCtZ+WQ7ReJOyOBKlIL7Qcy+MRjUNMHVVomuUzBfJw3fFNQN9iNF9nct5zd2AGBBfSN2Uv8Rl1q8wrMnoWz8wykz6b/lHyGD9t8Q/t+tqk0/3GaO6hXJ6ktsDveeBVTr930SKkLZk59NHzYUfirX9VOaZxtp+3qnxuSI4vZWNSugEgr6ec2DGrXoM5WlP0p8z/fXlNKxYE9f5bP1lj/bHLsim3PutK9EpDq+g+TX8TIoI7G5IztMvFSqkYlcsfvqSVrqbZc7LH1zimokKweC74mc21mhiIXFvFXJT0q18RLZmbjzY8krrlRBl5BSENuEBnBgU/7HEcz4yJTkG0AdWW7Q/GXlCCB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH1P110MB1412.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(64756008)(66446008)(66476007)(38070700005)(33656002)(166002)(316002)(2616005)(2906002)(186003)(66574015)(83380400001)(8676002)(966005)(122000001)(8936002)(6506007)(5660300002)(4326008)(66946007)(508600001)(76116006)(66556008)(53546011)(99936003)(86362001)(6486002)(6512007)(71200400001)(75432002)(4744005)(6916009)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MklJTHBRQ3NGQUxld1hsc0lBeUhxeXk1NkEvSHd1RkdQTmswM2srY3pheUpS?= =?utf-8?B?UlJ3WnB0dnU3U1JXQ29BRk0rMXpGSGxaYmF2N3lyOGpXNGZFZVBLZnc5YnBJ?= =?utf-8?B?VE53bGZydFBHa2VmdU5NbmhJV1ZQOEJ5QS9oTElVblNNb0kvTkhxcG9HVjNI?= =?utf-8?B?RjEyV2hsRzBvc1I1OG1qTE5JVHRWeDhPMEJSQXZEQ21XcWpOWmdEVTVsYSsy?= =?utf-8?B?V1RTQVZPUERoa09ic1U3Q0t1THhFdzV6SFFHZk1nZU1KUEZiWHg1UnhKUDhR?= =?utf-8?B?VHJHNE1uV0ZxK3FUMXlnejdCM0xPQ29VTnZJbHNQU1ROYnFpNE5BOWZ2dlJz?= =?utf-8?B?eHhXRVBEUmVwVG9GRXRrWTByL0Z6a1dWbHY0RG9FbG5PSFEzcE04Z0dIVVNQ?= =?utf-8?B?RWtxck1YdDIzNW4yQlh6MUFsZVNpaTRBaHRmMHBlUDYyTzVRd3FqTHJRYjlh?= =?utf-8?B?TkE4Rkl0RDRYZEQ3c1Btb3k1c3d6V1RkU1J3ZW54WFdqUDQwNWJsYUFyS0dV?= =?utf-8?B?VVdCTnhCczlXR2ZsSE9hRWFTbG1JbFVLb0dqSjc1b1ZDQzB3K3REUGhKOEdt?= =?utf-8?B?LzFyeWhKV0pCTDFmVFZHL0FiR3ZkR2tmWlFsanV0dzFva3F0MXFpWmYwMGVV?= =?utf-8?B?RzlsTkF4US8xR0RoS2NiKzVKSVZHeCsvTHFGN3dwc3kvZnlFVEViVDY0YlM2?= =?utf-8?B?eGp0KzdMK1pMVW9lNXd3L0piZ3BNcGdmSUc1TTQ1ZHkyY0liRWxrV3djSnV0?= =?utf-8?B?RVA3eWlXYWVzZWJhUVR6di8zT2poWU82UG5rUDNxSTBzVTRvUGwrRnBweGpX?= =?utf-8?B?OCtDdDRrOGtyZG03d0xodzlJVXc1MHJqdHFFZ2RGZGZnNXhlZ0psOTFTN3Zt?= =?utf-8?B?Y1czRGhQdWt5c3BWa1NIY29jMlhXakc4bFBLNWFYYWxGaWxqczhlaWxqMExW?= =?utf-8?B?VDdxSUJOc1hvSWtLdFovUnhpOWQ3YlJqV1JveW9vblJXeFQ4aWVoQnIzSkln?= =?utf-8?B?L09xbmlHNW9oWGppZzdIdklRS2xhOWdzbjlPY1c2VXJOL1hVbW9NMXRzRkpv?= =?utf-8?B?N29GeDYzV2YzaDRmcEpjYVBFOVR5R2JDOU9wUnNxY3cyNGZoY2lvRi94NHZk?= =?utf-8?B?c1Y5b3hFdEExNDB5QS9IYnhnWnVVME5DRnVPTGNhVUtTcGRyNkYzU3B5c3FW?= =?utf-8?B?V1JIVVZVdXB0TjZzVVVEVjZzRjhoTzA4ZzdXaGx2bVEvNnRuOUxVRG5OaXhU?= =?utf-8?B?cURVYmdvL2xzNjhQUWVsM3pvcCt1YXpnK09ZdW1RSnhUaEV6ZnFqbFFFT2ZP?= =?utf-8?B?Tm9Cb0Nzb0dRWnVSUlFBRXpEMXlzajdBT2pWMkl0RHFsWWhXOFhsU2Q1MlNi?= =?utf-8?B?UG5JMXZWUkZpRThTWUN0Y0hXTVBQRlg1NTBPT3l5c3QrcUUxTE02VGI0ZUQ1?= =?utf-8?B?TUNJRzNmSWlwYWJaQldDTnNjQTJQQmp3NjRMcVFlbHFPMVNGYzA2alppdktY?= =?utf-8?Q?75ohtaq4dIGF97VMi/RGtX3n/cK?= Content-Type: multipart/signed; boundary="Apple-Mail-CE22B07A-EFEC-409F-A4C8-629400CC76F8"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH1P110MB1412.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d124e017-a830-4004-b861-08d9c0b27edf X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2021 16:38:31.4241 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH1P110MB1330 X-Proofpoint-ORIG-GUID: SZsyCJ3cC8bmXepEP4RCH26UQB0Hz2lW X-Proofpoint-GUID: SZsyCJ3cC8bmXepEP4RCH26UQB0Hz2lW X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-16_05:2021-12-15, 2021-12-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 malwarescore=0 spamscore=0 adultscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112160092 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 16:38:40 -0000 --Apple-Mail-CE22B07A-EFEC-409F-A4C8-629400CC76F8 Content-Type: multipart/alternative; boundary=Apple-Mail-109352A9-1A26-4E0D-AA1A-B114C516725E Content-Transfer-Encoding: 7bit --Apple-Mail-109352A9-1A26-4E0D-AA1A-B114C516725E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WWVzIEkgY2FuLCBhbmQgeWVzIHRoZXkgZG8uIA0KDQpNeSBvbmx5IGNvbmNlcm4vd2lzaCBpcyBo YXZpbmcgb25lIG9mIHRoZW0gKHNheSwgMjQpIGFzIE1USSAtIGFzIG9wcG9zZWQgdG8gbWVyZWx5 IOKAnGRlZmluZWTigJ0uDQoNClRoYW5rcw0KDQpSZWdhcmRzLA0KVXJpDQoNCj4gT24gRGVjIDE2 LCAyMDIxLCBhdCAxMDo0NCwgTWFsacWhYSBWdcSNaW5pxIcgPG1hbGlzYS52dWNpbmljQGlucmlh LmZyPiB3cm90ZToNCj4gDQo+IO+7v1VyaSwNCj4gDQo+IENpcGhlciBzdWl0ZXMgMjQgYW5kIDI1 IGFyZSBpbnRlbmRlZCB0byBiZSBmb3IgaGlnaC1zZWN1cml0eSBhcHBsaWNhdGlvbnMgWzFdLiBD b3VsZCB5b3UgY29tbWVudCBpZiB0aGVzZSBkbyBub3QgbWVldCB5b3VyIG5lZWRzPyANCj4gDQo+ IFsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbGFr ZS1lZGhvYy0xMiNzZWN0aW9uLTkuMg0KPiANCj4gTWFsacWhYQ0KPiANCj4+IE9uIDE2IERlYyAy MDIxLCBhdCAxMzo1OSwgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMIDx1cmlAbGwubWl0 LmVkdT4gd3JvdGU6DQo+PiANCj4+IFNwZWFraW5nIG9mIE1USSBzdWl0ZXMg4oCTIEnigJlkIGxp a2UgdG8gc2VlIGF0IGxlYXN0IG9uZSBvZmZlcmluZyAyNTYtYml0IGxldmVsIG9mIHNlY3VyaXR5 Lg0KPj4gIA0KPj4gLS0NCj4+IFJlZ2FyZHMsDQo+PiBVcmkNCj4+ICANCj4+IFRoZXJlIGFyZSB0 d28gd2F5cyB0byBkZXNpZ24gYSBzeXN0ZW0uIE9uZSBpcyB0byBtYWtlIGl0IHNvIHNpbXBsZSB0 aGVyZSBhcmUgb2J2aW91c2x5IG5vIGRlZmljaWVuY2llcy4NCj4+IFRoZSBvdGhlciBpcyB0byBt YWtlIGl0IHNvIGNvbXBsZXggdGhlcmUgYXJlIG5vIG9idmlvdXMgZGVmaWNpZW5jaWVzLg0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0gIEMuIEEuIFIuIEhvYXJlDQo+IA0K --Apple-Mail-109352A9-1A26-4E0D-AA1A-B114C516725E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPlllcyBJIGNhbiwg YW5kIHllcyB0aGV5IGRvLiZuYnNwOzxkaXY+PGJyPjwvZGl2PjxkaXY+TXkgb25seSBjb25jZXJu L3dpc2ggaXMgaGF2aW5nIG9uZSBvZiB0aGVtIChzYXksIDI0KSBhcyBNVEkgLSBhcyBvcHBvc2Vk IHRvIG1lcmVseSDigJxkZWZpbmVk4oCdLjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzPGJyPjxk aXY+PGJyPjxkaXYgZGlyPSJsdHIiPlJlZ2FyZHMsPGRpdj5Vcmk8L2Rpdj48L2Rpdj48ZGl2IGRp cj0ibHRyIj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gRGVjIDE2LCAyMDIxLCBhdCAx MDo0NCwgTWFsacWhYSBWdcSNaW5pxIcgJmx0O21hbGlzYS52dWNpbmljQGlucmlhLmZyJmd0OyB3 cm90ZTo8YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 ZGl2IGRpcj0ibHRyIj7vu788bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+VXJpLDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi PjwvZGl2PjxkaXYgY2xhc3M9IiI+Q2lwaGVyIHN1aXRlcyAyNCBhbmQgMjUgYXJlIGludGVuZGVk IHRvIGJlIGZvciBoaWdoLXNlY3VyaXR5IGFwcGxpY2F0aW9ucyBbMV0uIENvdWxkIHlvdSBjb21t ZW50IGlmIHRoZXNlIGRvIG5vdCBtZWV0IHlvdXIgbmVlZHM/Jm5ic3A7PC9kaXY+PGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5bMV0mbmJzcDs8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbGFrZS1lZGhv Yy0xMiNzZWN0aW9uLTkuMiIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLWxha2UtZWRob2MtMTIjc2VjdGlvbi05LjI8L2E+PC9kaXY+PGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5NYWxpxaFhPGJyIGNs YXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+PGRpdiBjbGFzcz0iIj5PbiAxNiBEZWMgMjAyMSwgYXQgMTM6NTksIEJsdW1lbnRoYWwsIFVy aSAtIDA1NTMgLSBNSVRMTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVyaUBsbC5taXQuZWR1IiBjbGFz cz0iIj51cmlAbGwubWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjwvZGl2PjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+PGRpdiBjbGFzcz0iIj48bWV0YSBjaGFyc2V0PSJVVEYtOCIg Y2xhc3M9IiI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rp b24xOyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBp bjsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5TcGVha2luZyBv ZiBNVEkgc3VpdGVzIOKAkyBJ4oCZZCBsaWtlIHRvIHNlZSBhdCBsZWFzdCBvbmUgb2ZmZXJpbmcg MjU2LWJpdCBsZXZlbCBvZiBzZWN1cml0eS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj48ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEy cHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2 IGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9IiI+LS08bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5SZWdhcmRzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsiIGNsYXNzPSIiPlVyaTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwaW4gMC41aW47IGZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48aSBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L3NwYW4+PC9pPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGkg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGNsYXNzPSIiPlRoZXJlIGFy ZSB0d28gd2F5cyB0byBkZXNpZ24gYSBzeXN0ZW0uIE9uZSBpcyB0byBtYWtlIGl0IHNvIHNpbXBs ZSB0aGVyZSBhcmUgb2J2aW91c2x5IG5vIGRlZmljaWVuY2llcy48L3NwYW4+PC9pPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMHB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5UaGUgb3RoZXIgaXMgdG8gbWFrZSBpdCBz byBjb21wbGV4IHRoZXJlIGFyZSBubyBvYnZpb3VzIGRlZmljaWVuY2llcy48L3NwYW4+PC9pPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDsgQy4gQS4gUi4gSG9hcmU8L3NwYW4+ PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+ PC9kaXY+PGJyIGNsYXNzPSIiPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48 L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-109352A9-1A26-4E0D-AA1A-B114C516725E-- --Apple-Mail-CE22B07A-EFEC-409F-A4C8-629400CC76F8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE4Uw ggTAMIIDqKADAgECAgEGMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3Qg Q0EtMjAeFw0xNzAzMDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExM IENBLTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q 83Uv0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0gvYe HO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2TnQz0TkO jG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342seGy2s9YxNDnS E+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQv77vG DR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8B Af8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJodHRwOi8vY3JsLmxsLm1pdC5l ZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3Aw NAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTFJDQTIwgZIG A1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzAN BgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMB DjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ 91K7e2mA2Nj10W0o5JMHYkaa+ctL8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXh f0nsiY7TWJwAKw4AiO/yJ37/oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZra BjVe7PL95PhS7D+22NffInzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xW hSTQFWlhyA0/kkIi9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF 5IqgIfnSBWIrm3rfLhpZZJ/xJ7Yf6DCCBMAwggOooAMCAQICARMwDQYJKoZIhvcNAQELBQAwVjEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE5MDcwODExMTAwMFoXDTI5MDcwODExMTAw MFowUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNV BAsMA1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAI9k9IaGVzgPlD6/Eg/0XoChgxw38/vItW5vnBlfVdmcbNV8WKwgW50we/QLbmEdvRyH+h37 FK7KiR+oELabRbbsfEK1qsduYjhOLYNsnklZq3P2QeH0X7nyotInatiANd5CYGEPMQi6SIgRJvG3 uy85c/Zhk9FFYEXtyOSZLvd+Wu6Tgdqhxx+jhlkrPQDj4iXaOKEllGy+R9x+TJmQiPE90Y+3aG5q 0WDrFAAyOZJKrzn+6NY9PV+19quEPns+CR4Bky08Y76Me0BA2IJWTDIfagdkhqb4QpCqGd/9OW09 aArdj2+IkezJREza8ov5s2bjo39oGmKblsHmFYdjct8CAwEAAaOCAZwwggGYMBIGA1UdEwEB/wQI MAYBAf8CAQAwHQYDVR0OBBYEFJOQRwNCwU20Mx7UQpefoeArcL+IMB8GA1UdIwQYMBaAFP/JyWVM U4DxqQw8Ia6CKsfu+DL7MA4GA1UdDwEB/wQEAwIBhjBnBggrBgEFBQcBAQRbMFkwLgYIKwYBBQUH MAKGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTFJDQTIwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMUkNBMjCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3 EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqG SIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0G CSqGSIb3DQEBCwUAA4IBAQC58Mvss4f9kr6cAvKvBCnQ0FvC8VpwzOeg3B5uc4H4tFnxLEIvMMXF dlW9ngjbOo9DaH3YLEj+5PQyei5g7PnX2RJg9t/q/c5TISOkEHMJb6vnIE6ziKFHGXfN6Mkx69Io OSBcta/RaZxtNPz+TFfs8Zk20w1yYwvFYMalpdiIZz5PM69BXCStAaGB7b+zR3guFmzR0GQkH/VD EgwC3FUdt2GXplos5hCtjHJYY79BPrO5i2Z9ACtN8wkEr8EK47ftmM0uyfDMVpUQOXDY9WzW507S LhFD6S0mILDfEPirPX35PQ+8lLfDaP57bn+kd/Lf993NC0wkifQCII8+4VBzMIIE9jCCA96gAwIB AgITWQAFFtcQy9Z9yJBQRwAAAAUW1zANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRM TCBDQS01MB4XDTIxMDcwNjIzNDgyNVoXDTI2MDMwMjIzNTk1OVowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz EV1DzeRc9vI2/RjnGtv+hw6uRBOB7k9XpwdE4jBJzk4qVvPKYD5kmfwABciRewFl+z2D8PeBHfwW 7O8ggmulmUu3EM3RzlqacfYEWQMZEfPk4KLMT3B6AjF5iP4V7VXWe5sGZaQRib8gXumEZsTli5d1 ogkYv4AU4cBFrIkGTn4RDe4QthoYAinraTZU0T8bJS5pErTZZ4zQMYXrfFZvykmCRVTzsd6srXS8 JzurM+AHyCSUJBV9uuqD9Bf+G40RpSGa2aXVDxosnaSZda+UkXGLNWROyRxK1C1ksogCMwQx1Ak3 DdhpxaEfvX8/dqtlSB7zR8e21dYXdBNM5QvVAgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQUkOSIsVPs KPblGDVAeBv3mu77lhIwDgYDVR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MH Owh29ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBCzAl BgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAZBgNVHREEEjAQgQ51cmlAbGwu bWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACAmTmu6kEDAxmc0VGl/jJv95nla NJ0xHTW8te/DBqurmBlEuJHiJJYxKCPiohDG0/K7QjgWcKJpzh3SZi7kVBIK1QKLNu1eMo76InPE CrM/qhIcbJRYP9hGDAG07Mi6oN+EfsBuaOiveaIVK4C7nXz8QJnCzhQbSGQa/9w1CJc8OMRyol9q 7nse2Dq0HHIF29qhrTQe7RuowGl6hW/jWUyYY/t6XTomYmWp86WbzyyB+l3uGsKg66JO6vSJsMEk kKKzaycSirQN7y1Ftwxr6Jt1w4jow6qc4Zqlwruln+yX60iUWrnVNlsr2Hz5OzUJZC0f9Rul8/sy qjv3AbdmjQEwggT/MIID56ADAgECAhMwAAQ9wAOburb0nIZmAAAABD3AMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQL DANQS0kxEzARBgNVBAMMCk1JVExMIENBLTYwHhcNMjExMDIyMTUyMTQ4WhcNMjYxMDIxMTUyMTQ4 WjBXMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEOMAwGA1UE CxMFT3RoZXIxFzAVBgNVBAMMDnVyaUBsbC5taXQuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAoUeiggiG3r2OnBPgPNC40iS0wroeSIPJMxQ0L7Rc6yBlhMfkIgHSgA4AlkZxGlcL 0dyqRXjtf3TV1iiociEBW04GTGzahBj/PnBOcVauK0qz2fRDckdNSJuTfUMoYYMxxZRqDxKurGy3 7uxbQhMsz1D1Z5NKVayWrRFkxhbQzhO9VuOuBOXJJivtIZBwy0hPFRL2wJpEGG4oekQhaDMFY+Fn hgJRXqLA3e2EQVu73zAGHKbyDwmDXo0hZOouOAHTt0FVtgWn1AZigDd05YhE6hPcjm+p/NheozG5 7LQBHJIHZFKIii/7cS3+zjschIfqK1dSPjwU6mwsXdWsWc3HjwIDAQABo4IByDCCAcQwDgYDVR0P AQH/BAQDAgbAMCwGA1UdJQEB/wQiMCAGCCsGAQUFBwMCBgorBgEEAYI3CgMMBggrBgEFBQcDBDAd BgNVHQ4EFgQUL4XCXxxFpPouQ8HeF9f9NEFqzTowGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUw HwYDVR0jBBgwFoAUk5BHA0LBTbQzHtRCl5+h4Ctwv4gwMwYDVR0fBCwwKjAooCagJIYiaHR0cDov L2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNhNjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKG IWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9sbGNhNjAnBggrBgEFBQcwAYYbaHR0cDovL29j c3AubGwubWl0LmVkdS9vY3NwMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2H FYPq8EWFtqEfHYTm7WmD5K1oAgFkAgEPMBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwMwYJKwYB BAGCNxQCBCYeJABMAEwATQBvAGIAaQBsAGUAQQBXAFMAQQB1AHQAaAAtAFMAVzANBgkqhkiG9w0B AQsFAAOCAQEAVxlweroBdl6S+TInEjyfhNZFonqpFLnoZXDWjgWvFu+zWGDFHiCjSOjoW+Zjn/L0 0jWoMDoyBdeMbRRiOro+T5geZVNW/VIRbqU+/M3Wx48ysPfFCpzW0Xksl0pH+Za8/yE/AmKRxk+Z e98PiiuKhc4UgirxAWMR/OOcCXv2BwINXEkRvro0JhtoL650jCVgNonHtVayz91qOs2gG/Lyxals TkC/COy0NUjLucW9wzPJ1BRXYlBDYlrUX8og82W5zxIoMONDzWAxljgfxpb0QxGt83GDbnQ57inD a0g69Ir43ddPviTToabnQfMnJdZ/ORGHsEDxqH1t26SPEByoxzGCAvQwggLwAgEBMGgwUTELMAkG A1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsMA1BLSTET MBEGA1UEAwwKTUlUTEwgQ0EtNgITMAAEPcADm7q29JyGZgAAAAQ9wDANBglghkgBZQMEAgEFAKCC AV0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjExMjE2MTYzODI5 WjAvBgkqhkiG9w0BCQQxIgQgHSq8bfQjMvcc//nYH4PaFQuziy0eq21x0BoVnyiOVvUwdwYJKwYB BAGCNxAEMWowaDBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01AhNZAAUW1xDL1n3IkFBHAAAABRbX MHkGCyqGSIb3DQEJEAILMWqgaDBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01AhNZAAUW1xDL1n3I kFBHAAAABRbXMA0GCSqGSIb3DQEBCwUABIIBAAPq7XIkXe5RV4tEFERDiHa+i/DXPkkTCMXoWsv4 yviVcThCpXbHNVuRPOicIwTNmNIgPr01Ug6wP7b7OZXp9Fr+lw3Jr+ZzXHcuAug005g71EcbxfiQ DBcAtfU5JVV+9wLTSPJMMYw9OqUUc7qjWS2c47QF3e4cuiNLAgX98UQ85mO9GkwCxJIveipGuE7C z6VmuEf2SSUAhXp+ydu8dLqG6SZJcjTazGuzOPy8NLmxFQEOzLMxrUR2AFrw/6+G96Sc9d6ud5pC HjW+rLYdpfjv/v0Ewln3t4jKJ0unkI/LylFZOGgfKhx022UF1Qq8JZDe6COQBZBk+FiW/QF9Ub8A AAAAAAA= --Apple-Mail-CE22B07A-EFEC-409F-A4C8-629400CC76F8-- From nobody Thu Dec 16 09:09:31 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AA13A1289 for ; Thu, 16 Dec 2021 09:09:30 -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, 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 DJhFlz13EN-r for ; Thu, 16 Dec 2021 09:09:25 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C103A1284 for ; Thu, 16 Dec 2021 09:09:24 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JFJW33xprzDCjc; Thu, 16 Dec 2021 18:09:19 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> Date: Thu, 16 Dec 2021 18:09:19 +0100 Cc: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , "lake@ietf.org" X-Mao-Original-Outgoing-Id: 661367359.001254-99479b0278e1439f5da9bd7a38aa63d0 Content-Transfer-Encoding: quoted-printable Message-Id: <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> To: "Blumenthal, Uri - 0553 - MITLL" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 17:09:31 -0000 On 2021-12-16, at 17:38, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > My only concern/wish is having one of them (say, 24) as MTI - as = opposed to merely =E2=80=9Cdefined=E2=80=9D. Mandatory to implement as in =E2=80=9CMUST (BUT WE KNOW YOU WON'T)=E2=80=9D= (RFC 6919)? I don=E2=80=99t think a lot of very constrained systems will go for = this. Or do you want (0&1) | (2&3) | (24|25) ? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 17 11:00:49 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2056F3A0823 for ; Fri, 17 Dec 2021 11:00:48 -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 n5s4j3DWirKf for ; Fri, 17 Dec 2021 11:00:43 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475FA3A081E for ; Fri, 17 Dec 2021 11:00:42 -0800 (PST) Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 8E54D1F479; Fri, 17 Dec 2021 19:00:40 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0E3211A021C; Fri, 17 Dec 2021 14:00:39 -0500 (EST) From: Michael Richardson To: Carsten Bormann , "lake\@ietf.org" In-reply-to: <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Thu, 16 Dec 2021 18:09:19 +0100." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Fri, 17 Dec 2021 14:00:39 -0500 Message-ID: <48074.1639767639@dooku> Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 19:00:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > On 2021-12-16, at 17:38, Blumenthal, Uri - 0553 - MITLL > wrote: >>=20 >> My only concern/wish is having one of them (say, 24) as MTI - as >> opposed to merely =E2=80=9Cdefined=E2=80=9D. > Mandatory to implement as in =E2=80=9CMUST (BUT WE KNOW YOU WON'T)=E2= =80=9D (RFC 6919)? > I don=E2=80=99t think a lot of very constrained systems will go for t= his. Ditto. I think that we need to replace the "MTI" concept for constrained systems. Fundamentally, it's not about strength, it's about: 1) encouraging some defense programming in the face of algorithm agility 2) being able to switch algorithms on relatively short notice (Moving from AES128 to AES256 is not necessarily useful if AES* turned out = to be thing which is flawed) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmG83lYACgkQlUzhVv38 QpDDeAf9FScHPtVurs4UIvMfbsNxPk/JiU0CL21qXgDcxvAbUS26+VcXBFSQL7I0 pdyYxaR9BAjpHpzU1Rpq4PlGzZ5J/0ZDhGRIuvwUbc9blrFuYSHy7xjgh0pisKov 7popR9DFomzJ8CozhQbDuF5E2DxrDEUsYN9kC905zxG8jbU3rCgAOttRAhganwn2 qKiqX5kZ3CQHzjUheZ6j8VUQ04lcOGQuhNOmVC2iYjIm18g59uNtpbBc2p2a82Sr ppCPM24lEt8T0xBt3SL40vyTL+v8TLoTMbENzPESshgYhTXTdZtM38kezuKQbE6x E4xi2SVVQlTJ7mhyXSvVd6SYu/5IMw== =1PVZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 17 12:22:54 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8663A0A90 for ; Fri, 17 Dec 2021 12:22:53 -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, MIME_QP_LONG_LINE=0.001, 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 JblZLLkC1gQJ for ; Fri, 17 Dec 2021 12:22:50 -0800 (PST) Received: from MX3.LL.MIT.EDU (mx3.ll.mit.edu [129.55.12.52]) (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 1FA863A0A70 for ; Fri, 17 Dec 2021 12:22:49 -0800 (PST) Received: from LLEX2019-2.mitll.ad.local ([172.25.4.124]) by MX3.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 1BHKMmI6007310 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Dec 2021 15:22:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=ylGqVAzUft67xqPJ3DSaucPM7uWXupvGQKfnnWGPobcdYmrG2jiRDJjlU22vfYZzMImWEvYznIoKS6l5qlqRd/VXTr3xgsWaYxQQfeO2UbkEaqIY1d9kHWxITGtHd4T0yZs78ZpGgfQmuqA6flLv3z37+bXEh8FOl1AAFPz5HwlxzuW1MpfBFjY2UzT1WbxHO8QQus2yxhG0nFvc0LXwVd2GqavCmdcI1TjndidapdK68zXnJ936Mz9Acdr/1pOVVQXyU/3uTBVJd+Js3PdDAKIl9lsxi0IX/pWFUClPsD/aUZJUQGQrMiL4IStn51TjRgAbAtNiwaGWvUSjspYuOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V5Xr5IETmDKKdwfykgmZG2sVI8wS8yWR+i36GETQaGg=; b=dE85wMKaTEPvWo0VQS6PqX5u4fcsmHj9JNsrXAFsj4I3jksUVfKNjqpSLILAqYkse4FKXTOuKoyEBqRbBXIhB/9dTpCGbjvcR3kuqnMIhzD3jV5JxZ6gmYFnCwY/Fy8DPUk5Ord02CGYHZVuJg1Go1P3HJrRRf0X+wkf7nZe40CUufmROILFev/JjwnWkxX2ne9ffPK2SuNRdsKPzixpTp2rmbrldPAupRXUiagJptZZ37vGQlY/zcuPFUkAjI/lindZOqlut1KCqazSuiET1nuTP+QrB/fBMzyEOc/7nrHk3YGa33UmxYDhV4aKcJ8yUQDzkwDOYzC6LadVf27dVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: Michael Richardson , Carsten Bormann , "lake@ietf.org" Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4ifJvzqXdSI0a5MKRvRKOSqqw07yMA///R8YCAAIGUAIAAD1GAgAAInYCAAbFwgP//wx+A Date: Fri, 17 Dec 2021 20:22:45 +0000 Message-ID: <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> In-Reply-To: <48074.1639767639@dooku> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4950b34-aefa-4122-9222-08d9c19afcd1 x-ms-traffictypediagnostic: BN0P110MB1577: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JN0qVuRGy8JBKQpiokLAievHok22lQ3n7mbxQWkf++DtubCHNIOJRALR/j5h/PcGLRpX6xKB4unAHlzQvp32hTqh2tiICIUqc/HX/eidR77grR0ZT78YPj7m9sIEq8OTjCO9YMpqGZ5gXv/xgKLGkuoRehP8GJomR5cLbTNpQDYLcgBpFP2ekjIT1bqwvzaAW95SRJ9hl7Jmhzui5bxEbzxGIJYvMegGni9GDKx+95afA9KHe2NxSctww02TbEUB9i2bmfTYQs5CozgX5/EFV7HcJHfcIc1QHEChpivY3xKrV6cAxDT7f1g/e8xp9XHK1QsbMGQdMoBcCZAD++TxwrSQXHBA2SwbcITX2mhBMK2xUiQWwKO7PLUsl1zPdOLHQND2Y6+tABRmL0U6h5Fym9lG6APkysb1IfxTNfJz3/JnRrZCwaqUJcYXr28hweTHRNB1Aa+A5oR/oHjTjdpH3KXT4i2ZR4tJFeFkv8HIaw3zUkGnyCCD39ocgdQiD33GWAVmcB8Sn9/m5vXHXNNdIXQw143aBICjmqs609B/mbSil8QpqA0nr7lcvIRbuqZvjaLLG5IlqC/SeDcsmfXCg1ubmagq9ucvjJ628IJWYMKcNH919PJu2BPyFfsMzq0QYBQbPDxh8ZV+bFmGvvfOvO4uOrWiyx1EUOOvidofGGI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(2906002)(26005)(5660300002)(6512007)(6506007)(83380400001)(6486002)(38070700005)(110136005)(86362001)(99936003)(66556008)(33656002)(316002)(8676002)(8936002)(66946007)(75432002)(66476007)(66446008)(508600001)(71200400001)(66574015)(2616005)(64756008)(76116006)(186003)(38100700002)(122000001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: I9T0zrxAXbIV+RjAC/G4mYtYAZOwjTzs2yoOP6SyQw0U3pDzxbDvQgQvuWRjbk+AbLtGKQTBz+H1lG9QVe6u4/A64ORj7Boi4ksTYHM6+AoutrXu0urHMuyrb9P4JSwwbUwM6wzsJNID0OBO/QRv3w== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3722599365_1273849082" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f4950b34-aefa-4122-9222-08d9c19afcd1 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2021 20:22:45.8769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB1577 X-Proofpoint-GUID: JchUdyadgKbcKm2LMcA-2_0qRX4Kotkd X-Proofpoint-ORIG-GUID: JchUdyadgKbcKm2LMcA-2_0qRX4Kotkd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-17_06:2021-12-15, 2021-12-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112170114 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 20:22:53 -0000 --B_3722599365_1273849082 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > >> My only concern/wish is having one of them (say, 24) as MTI - as > >> opposed to merely =E2=80=9Cdefined=E2=80=9D. > > > Mandatory to implement as in =E2=80=9CMUST (BUT WE KNOW YOU WON'T)=E2=80=9D (RFC 69= 19)? > > I don=E2=80=99t think a lot of very constrained systems will go for this. What alternative do you suggest? Don't say "MUST" at all, since you don't e= xpect "a lot of systems" to comply anyway? > Ditto. > I think that we need to replace the "MTI" concept for constrained systems= . Respectfully disagree.=20 MTI is about guarantee (to a reasonable degree) of interoperability between= implementations/products. > Fundamentally, it's not about strength, it's about: Actually, it *is* about strength. Though yes, your other two points also ma= tter.=20 > 1) encouraging some defense programming in the face of algorithm agility Already (being) done, with _very_ variable degree of success. > 2) being able to switch algorithms on relatively short notice Yeah... It's not your friendly desktop Web browser, y'know... Peter Gutman = can probably tell you much more about SCADA and embedded devices, how freque= ntly they "switch algorithms", and how short those notices are... Let's be realistic here, please. Especially since you don't think that (eve= n) requiring to implement stronger cipher-suites would be honored by the imp= lementers. > (Moving from AES128 to AES256 is not necessarily useful if AES* turned > out to be thing which is flawed) My bet is that AES* won't "turn out to be the thing...", but you're missing= my point - for some applications AES128 is not acceptable to begin with. Oh, on the AES128 vs. AES256 conversation: if you care to know, Russian GOS= T 28147-89 block cipher (released, as you can guess, in 1989) had 256-bit ke= y. Go figure. --B_3722599365_1273849082 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAUW1xDL1n3IkFBHAAAABRbXMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMjEwNzA2MjM0ODI1WhcNMjYwMzAy MjM1OTU5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMRXUPN5Fz28jb9GOca2/6HDq5EE4Hu T1enB0TiMEnOTipW88pgPmSZ/AAFyJF7AWX7PYPw94Ed/Bbs7yCCa6WZS7cQzdHOWppx9gRZ AxkR8+TgosxPcHoCMXmI/hXtVdZ7mwZlpBGJvyBe6YRmxOWLl3WiCRi/gBThwEWsiQZOfhEN 7hC2GhgCKetpNlTRPxslLmkStNlnjNAxhet8Vm/KSYJFVPOx3qytdLwnO6sz4AfIJJQkFX26 6oP0F/4bjRGlIZrZpdUPGiydpJl1r5SRcYs1ZE7JHErULWSyiAIzBDHUCTcN2GnFoR+9fz92 q2VIHvNHx7bV1hd0E0zlC9UCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBSQ5IixU+wo9uUYNUB4 G/ea7vuWEjAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAICZO a7qQQMDGZzRUaX+Mm/3meVo0nTEdNby178MGq6uYGUS4keIkljEoI+KiEMbT8rtCOBZwomnO HdJmLuRUEgrVAos27V4yjvoic8QKsz+qEhxslFg/2EYMAbTsyLqg34R+wG5o6K95ohUrgLud fPxAmcLOFBtIZBr/3DUIlzw4xHKiX2ruex7YOrQccgXb2qGtNB7tG6jAaXqFb+NZTJhj+3pd OiZiZanzpZvPLIH6Xe4awqDrok7q9ImwwSSQorNrJxKKtA3vLUW3DGvom3XDiOjDqpzhmqXC u6Wf7JfrSJRaudU2WyvYfPk7NQlkLR/1G6Xz+zKqO/cBt2aNATGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCbfiAIbvg+5sDzHzaOukcKA7nuJO1NTw3yYBsD 44J89zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEyMTcy MDIyNDVaMA0GCSqGSIb3DQEBAQUABIIBAA85FAVnLrA+jwLtVEsbZLn+asHoQRSVNSOPrTor aW022J2wkoCDGDOkdPPx/vuAHpVPAbyxJLeZai8qF/YdBCMRVu/t2AzaSgyyJAuLHn+JnFYC CcNMn7oHQqQ7Fe6ID3UL8shHk2lHSqavC3P3jz1XuTXEliW2NDnv+PzlSVqHbIYKz/OAeGRt 1gyg32tb/u6dyMyR8p/nuaLK+oEI042TmGC3DoE3LelBfxjAZKgdUm5YYfL9fuVmfccaby1e xh1oO2e4hkvzW5sjqv42gpyagjwdYCXSCUVE2VAKR9hGNLf9nt86G2cSYDb+GgGOcRxgEoIj X5pqDSzvZpwOQsw= --B_3722599365_1273849082-- From nobody Fri Dec 17 14:05:01 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5A3A096E for ; Fri, 17 Dec 2021 14:04:54 -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, 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 QuJhlex5fTPB for ; Fri, 17 Dec 2021 14:04:49 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AAB3A0930 for ; Fri, 17 Dec 2021 14:04:49 -0800 (PST) Received: from smtpclient.apple (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JG31T2c1rzDCbg; Fri, 17 Dec 2021 23:04:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> Date: Fri, 17 Dec 2021 23:04:44 +0100 Cc: Michael Richardson , "lake@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> To: "Blumenthal, Uri - 0553 - MITLL" X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 22:05:00 -0000 On 17. Dec 2021, at 21:22, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 >> I think that we need to replace the "MTI" concept for constrained = systems. >=20 > Respectfully disagree.=20 >=20 > MTI is about guarantee (to a reasonable degree) of interoperability = between implementations/products. This concept is very useful for standards that essentially establish a = plug-and-play environment. A standard like EDHOC which is a component in a larger environment does = not necessarily need its own plug-and-play; this should come from the = system standards where it is embedded. (Well, maybe unless the decision is a slam-dunk, which apparently it is = not in this case.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 17 14:49:48 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084EF3A0B1A for ; Fri, 17 Dec 2021 14:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 KQTYTqAxCeSq for ; Fri, 17 Dec 2021 14:49:41 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1EA3A0B19 for ; Fri, 17 Dec 2021 14:49:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0DA9F38A4B; Fri, 17 Dec 2021 17:53:56 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zFvBFzBWUTeG; Fri, 17 Dec 2021 17:53:54 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 52A0D38A49; Fri, 17 Dec 2021 17:53:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1639781634; bh=wYCBO84aHlGMfTAwqniD5yR75UQDibnNLPQUe6tdh08=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=koede/qwdvftH5dnXWY8uSWAPm9+1Ex1z2fRDMr1W3m/9mb7H+qubkGHVUUxArUFZ tVXEUGy0hgqMPRxb0oK4dotrPvBYFnhwhmnKq4Sz5TL7wpvKOM9BRgC7Cq7JNG/N5r RUvmiZJiD0tqjpzGYsxJSgQ4Jpdm07gDg2921CysZ+CLBjbQRXnjNP5oZ+didWwJPk w031V1NEWy5f9U8jc7DX9qa2EVPWqsUo3kU3hFKs6KW1UGLUI8w0MZSzErRCj5Y8bV hNHErL+WIxqeK1LhHnpbCLtSBOq/+4wls7O2jcdCT9rw7A9uEnSHwMrUNTcHQYdd24 MNfTrLi14nUsA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D4A525E8; Fri, 17 Dec 2021 17:49:34 -0500 (EST) From: Michael Richardson To: "Blumenthal\, Uri - 0553 - MITLL" cc: Carsten Bormann , "lake\@ietf.org" In-Reply-To: <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 22:49:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Blumenthal, Uri - 0553 - MITLL wrote: >> (Moving from AES128 to AES256 is not necessarily useful if AES* turn= ed >> out to be thing which is flawed) > My bet is that AES* won't "turn out to be the thing...", but you're > missing my point - for some applications AES128 is not acceptable to > begin with. Not missing your point. Some ecosystem where AES128 is not strong enough will need AES256 (or GOST). In such an ecosystem, not only would AES128 be forbidden by policy, it might even be that it needs to be removed from the code base so that it can't be used by mistake. That goes entirely against what is normally intended by M= TI. (MTI does not equal mandatory to use, which is often missed by people outsi= de the IETF, btw. Some think that if it's in the IANA table that it can be used) As Carsten says, EDHOC will be used in a bigger profile, and that profile will need to decide what we need. IPsec did a good job of making this suggestion clearer as to what to implement, but IPsec has never (alas!!!!), experienced random two nodes on the Internet use. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmG9E/4ACgkQgItw+93Q 3WVndggAoORPhRQe2X//Jvt6WYYemVrV+ewvKkKY5JRO71G3UB0gRclej6ybDWAi aryUHg4skeo/OUtyzGZegnskFhS9GpTRMEI16xW5Axu92d91NQQxfXM9Dzdpia0G qkqDnczC57OKrWkg100Q/wmFMbKdbfhpdk18+Vo+FHfM00klw+t7/thFS8U2GEWo 1V9/2GEDTIyVSn+JNxD6Bh+SfF3gTXnrte2PDMIhuKoXQPHHnmlexA11GpazuFb5 GQnrnwD7EgaWCyWDtOWb8Jb5SpP1MVSOnkpDQdBU5PdTazHXoF/g3pcbpqP1XvHx B5Wo3kWWxlJ5UNzoodlXGZ2pMOnZ9g== =94V5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Dec 18 04:23:43 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B94D3A0E1C for ; Sat, 18 Dec 2021 04:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 NJ4wX3c8I0Xb for ; Sat, 18 Dec 2021 04:23:36 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2051.outbound.protection.outlook.com [104.47.14.51]) (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 943363A0C41 for ; Sat, 18 Dec 2021 04:23:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O/JLQECm6oojFW5WBLgkCBovigXTmJXPZczoL65oAmLmF4VGE52i7skYVZ2wPRfi9C4chIvkfErvzxikIBYuK8VkVzbffSmvYqE/T9WPVr4upE6o0QUwgQhTokzjLUNnyN5Qg8NMximK6TpyV6FSc6LL+LDfEJ0iuFy1XyNQ800aKwMJvf/zQ3R7yt7d3peRQ1hpM/oGUwDQ5+Hu+JGPL2q6THsIV9io+hIH67o5ihjwrBEzT0Dt0aMsen8SU9EuM2YTu8vaA8OfOF7ngHU4zoCF+tW3bowkD8Gc21YF4aOSsy0ejMhmWL2gLNciZoU48E/uqSi5o3ioWkuxhYT0OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jeMNcWXDK31jtamw+vy5kCcpGuhRM/LqmCVLR/HVtSw=; b=hum6s5JxW3q8ws0CmImbO4LU3tFMAc077X6UxkrwO7BJ/gUjdckHKEBmDjHqkEllx37W9z5EZRobrrQibts/9dmopAwczWyTfzc0oV3R0IdX6vZt/UMBO3dmgPr9gix5xBdGWgceWpeXgVyY/ru2LAzrKtYwnz9dSeGSgGv0xUODLxXkeGl6Sk61zYwsh14mi/wLTWBFMec56oLjQhm5fk/x6DI2QKX4tUVOPOUN0ayU23qiIOPMbsfTZx7x/2iQj1UbUvXW27TfWK6ASTD/ELpZt2RorZFMl4hYP4o2AxXRJX0HJuCCn/OsWQs06t0oB6W1SF+/JKxBIVJxVPbj8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jeMNcWXDK31jtamw+vy5kCcpGuhRM/LqmCVLR/HVtSw=; b=p/CThG3G2mRDwe/wELCNHlTxL9IYN/ce+2D4NsBLwiIxU2uf1asRAMjMfyPAKG+M7V9zRG2F5QRRw49bVQq/FmfiVx2fBPI0VXZOOWI8IDsf3trkZtxV4bjGm7brMESfssHK+b62ZqX0imiAkRMwneUu1YsT5N5LV9AVjT9/M5k= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by AM6PR0702MB3765.eurprd07.prod.outlook.com (2603:10a6:209:10::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.14; Sat, 18 Dec 2021 12:23:30 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::acd7:51e8:bdfe:c133]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::acd7:51e8:bdfe:c133%7]) with mapi id 15.20.4823.011; Sat, 18 Dec 2021 12:23:29 +0000 From: John Mattsson To: "lake@ietf.org" Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4VsOHFv4hJf0eYryujwTYNmKw07yMAgAAlxACAAC3BAIAAD1SAgAAIm4CAAbFwgIAAFvCAgAApBQCAANVCpA== Date: Sat, 18 Dec 2021 12:23:29 +0000 Message-ID: References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> <3819.1639781374@localhost> In-Reply-To: <3819.1639781374@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f8be0311-f0f7-49fa-5afa-08d9c221332f x-ms-traffictypediagnostic: AM6PR0702MB3765:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EC5qmSOtRJoME/jJ15I0B/jE0k/21xwIdtWp0KM7H2l72mr4JYKXX8+DQY28PXHvUitfx355oOY1Oh9aOxqOYRAbqZaOzZYcFb66CV1SI5QQAzQMkfRp01P44jVLHliaxKoIac3wdSVptrL06nD7Zdr2eLlk9OVOvdKxZqZa3Lcy45SzM4cV2FiGo1IdHmx9F0WYppFUI+3t7J7YdFIQwQ+EkdFb4x3MTcGAwBbJIxaSB4XgsLdTb/9aAYGEKN4H5GiybqFklZYj0G5bBirzvGkFE8uQt08e0/dzH8NKhZcEVowyCQZX2hnTiSQTz1/fR5xK7wRZI0OO5alD0L0n4zeje7l57vAvE3f37ozgxRR7bmzmKxdAAx7DBbGJeJFxpTpvxMLnLlW4CFnUSUp5965TZwdy2zE8kwuajYljqwgQH8k4uH7izZTC0ItHlkaYOY672jILIX0C4hpKIxKfGRhqyEq5XahnRUcu5F6I/txierIMfL8nGeONmbQBcA5kjyY9r3ZalmqJ5PnYpc4mmdiKgWFsARvOVQtSeNZW6TqY0mURVfU3NjrM/jKWtdshOGmM/MLLg1v1pvCdQdbKwD5vx1+D+kmoK2dGpyng1QA78y7n73IfF+GZYvMrXxWoElUnKdREahQajK0SllaEQw0aUKEEEfWmVnOYHz3qg3ioe8cOWytlqvExU6qmVGK4AvX2++yyT7O1UBGtgEQfVmam+1HmBRjLjh/Sw7gkoE6xXYL7PieJee1XucqCFl0u x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(6506007)(66476007)(38100700002)(52536014)(66446008)(33656002)(71200400001)(9686003)(122000001)(316002)(8936002)(8676002)(7696005)(38070700005)(26005)(186003)(76116006)(86362001)(66946007)(91956017)(64756008)(6916009)(83380400001)(66556008)(508600001)(44832011)(2906002)(82960400001)(5660300002)(55016003)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2M4szNd2thE0f+s0H9bm0rmerQgkE1WbxPUkrStxjFScmBC/bI5xACuVNJHg?= =?us-ascii?Q?Z2Sg2OoyZoEWXGPOmOMhJnV8xyBrATOvFL7MnBwUpdqdgWmcqwXzVVzGius/?= =?us-ascii?Q?lqnpyhiiQj455/N0kDriagbi3E5kYfrQI0YukhF5ROwjXA2RXosKv5UkzeCp?= =?us-ascii?Q?MzdOg7qlL5UD1STAYzu+5NmKWVeIat2iWHmJz/z0G6o671gTgHwq1dWho/Yl?= =?us-ascii?Q?J24yEidQfPa+oNEQsWdvmclNCQf2hqA1gKcUFkAU2tpTaceiGpsGhxCj4u/7?= =?us-ascii?Q?i4etgvVQ1XTplsPnvIhUqjUovNVJLNbkdKXAU8fDLp2Js1+xdwR0qotne1nq?= =?us-ascii?Q?A2CwAzDqkCpzOCjwluTTxJQB2CXd+aWgJ3kLT/UM+wCSfj3p8grcL0tupw4j?= =?us-ascii?Q?kF5T2AC92TF3N8SCpv4T5pKdm2+nJ62LfOTee9JDiMtanVb48IO4hgU/obyy?= =?us-ascii?Q?zUnXjsImIQ/9S9fyKhhtsRcQccR0d1drScEC7kdhFRReLlKCsOh8cVmvbupo?= =?us-ascii?Q?T2ri3DWcC4oumNh3N/kf+UKG7P1mTTZMpIWKOfWumtxjuS99idBdrzck38am?= =?us-ascii?Q?ccCD0B7u4XPg0+DE4D5srWESBZGnkBly/Ts+vjqGI8B2pXToc2houmwCTg1t?= =?us-ascii?Q?Ny1YCdPSW6gatzZ5Rcjxm8Jxu9Y9rhIJsBe8KAjUY5K/NjVYiIWb1P7flv4E?= =?us-ascii?Q?yujiB/fBUxxHCBN//9HNjVIMLaJjm7+TDQ7EuXoHgCw+LanKXUyIyVmZba9s?= =?us-ascii?Q?mUF+wweWQclpsIwq7EZ6raColemwqw+vWtKvco/1DAvmahodfxMhF75bizuV?= =?us-ascii?Q?pgUhoSkk79xadRB8y0V+6GkS5APiudlPkmR5gAfbrcQz9veACb+eEwvtLCZ5?= =?us-ascii?Q?3j1uaoYQQKwPVVp+Z5i+cZqR34iTE+q9aJLH3Ob9HUZxWwFZ0+558U2zpIHN?= =?us-ascii?Q?P7LGpBHb8g/u/SVUjycczJ0kXs2tVJ4sALqFBYMPqCgY9uDj5GEIsPxEp89z?= =?us-ascii?Q?mr8zKOqvUDnY545srtSyxmn63NQOcz05dx47QHKT/PonKsV4/MDxSf9HQ5tb?= =?us-ascii?Q?aDnLHl7PFu6q5hQdzreoe9YGsTIDK7EmpYeL7JUDdXdSWOiVE6wCAG0wPlB/?= =?us-ascii?Q?QXsdrz6jGip28gKpmeyWZLi8pVtHkkiGqYz3d8+N/fn8zhgJHuJqI/tjBKmk?= =?us-ascii?Q?MyqpJu+tNN0ypTnwDtnu6/znAYtpemmew/6aQMQzEjLzL4USSScE+fH2iJ0H?= =?us-ascii?Q?/+fCRsdkerHNmMP7qj30fUjYE2RK4NeCD2d6bnTYHdaRyy3tgImbTDRuL5am?= =?us-ascii?Q?4iG86roBcYK239oN6hbXq5d/nQ7tWO/URDuTbRRJW+MJNmY4M2GtZPukfJ84?= =?us-ascii?Q?k6O80SrjcpZaq5/Qp1SeFSrsj2VWGI2a6RXHOdmq8Fl7VTYt5rrcLGZOZTAA?= =?us-ascii?Q?ZLJxYSSmYDvh1dYo/F2I3tIECG7BTVW/R/WNoBmpGausVXdrXCPutZuTtyhH?= =?us-ascii?Q?6HRkRC5HP2fL6s5q2vlMOlgsPq3RysTNqqMktparfN69CLfTGzEIuNwnw8Ig?= =?us-ascii?Q?V15Tjxmu/Gs7S79eVcuFaOcgDlnEWyywnsiy/MFAaQj78nkQZPFm2Pfq4PEp?= =?us-ascii?Q?wYbFDaBErLHbLl2U0cGn4pUhlD+EGNgNZzKeHWQA/jFXmEYxJM04/SeypD1P?= =?us-ascii?Q?bnz7xVkzbdKlHtMfDW7Ipc8lDZM=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050866F1EFEA411D8F2180B89799HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8be0311-f0f7-49fa-5afa-08d9c221332f X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2021 12:23:29.4458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ns3EGFRwP9htIcrIdrPOdU9BK/TIYpwqQu5trs/bH/w7WWT87nkWMEuwjtO6087Hep73W6AtDi6dVNy/joRcL7/xc67jM/FanVte78XUJy8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3765 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2021 12:23:41 -0000 --_000_HE1PR0701MB3050866F1EFEA411D8F2180B89799HE1PR0701MB3050_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My two cents: - Interoperability: I don't understand this focus on MTI cipher suite and i= nteroperability. EDHOC works mostly like COSE where different applications = and deployments can choose from a smorgasbord of options to optimize what f= its their specific environment. I think this approach has been very success= ful for COSE. Two implementations will not be interoperable unless they imp= lement the same: - 1. Transport protocol - 2. EDHOC method (0, 1, 2, 3, ......) - 3. ID_CRED_R COSE header parameter (kid, kid_context, x5t, x5chain, x5= bag, x5u, kcwt, kcct, c5u, c5t, c5b, c5c, ....) - 4. CRED_R COSE credential type (CWT, CCS, X.509, C509, ..... ) with a = matching credential profile. - 5. Use and type of external authorization data (EAD_1, EAD_2, EAD_3, E= AD_4) - 6. Identifier used as identity of endpoint - 7. If message_4 shall be sent/expected - 8. Subsequent application protocol - 9. Data sent over the subsequent application protocol - 10. Cipher suite. Implementing the same cipher suite is just a quite small piece in interoper= ability between two endpoints. - Having a MTI cipher suite has significant drawbacks. TLS 1.2 mandates sup= port of TLS_RSA_WITH_AES_128_CBC_SHA. This cipher suite has at least 3 majo= r weaknesses: static RSA, CBC padding attacks, and SHA1. Each one of these = weaknesses could independently warrant a must not support. This causes a lo= t of problems, as many industries are very keen on compliance with standard= s. With TLS 1.2 an implementation can be either compliant or weak. I person= ally think the IPsec approach is better: "The specification of suites that = MUST and SHOULD be supported for interoperability has been removed from thi= s document because they are likely to change more rapidly than this documen= t evolves.". I don't see any reason to force local IoT deployments wanting = to use EdDSA + X25519 or the CNSA cipher suite to also implement cipher sui= te 0. I can live with something like the current proposal from Stephen, but= my personal preference would be to not mandate any specific cipher suite a= t all. - 256 bit: There are definitely interest in using EDHOC with high-security = cipher suites like 24 and 25. One reason is compliance with requirements su= ch as the US CNSA. As TLS, DTLS, QUIC do not mandate high security cipher s= uites, it would maybe be a bit strange if EDHOC which has a strong focus on= very constrained environments did so. I don't think it make sense to force= e.g., 6TiSCH devices to implement cipher suite 24 or 25. AES-128 will prov= ide excellent security for most deployments for the foreseeable future. We = should also not force deployments using 24 or 25 to support, 0,1,2, or 3. Cheers, John --_000_HE1PR0701MB3050866F1EFEA411D8F2180B89799HE1PR0701MB3050_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

My two cents:=

 

- Interoperability: I don't und= erstand this focus on MTI cipher suite and interoperability. EDHOC works mo= stly like COSE where different applications and deployments can choose from= a smorgasbord of options to optimize what fits their specific environment. I think this approach has been very = successful for COSE. Two implementations will not be interoperable unless t= hey implement the same:

 

  -  1. Transport pro= tocol

  -  2. EDHOC method = (0, 1, 2, 3, ......)

  -  3. ID_CRED_R COS= E header parameter (kid, kid_context, x5t, x5chain, x5bag, x5u, kcwt, kcct,= c5u, c5t, c5b, c5c, ....)

  -  4. CRED_R COSE c= redential type (CWT, CCS, X.509, C509, ..... ) with a matching credential p= rofile.

  -  5. Use and type = of external authorization data (EAD_1, EAD_2, EAD_3, EAD_4)

  -  6. Identifier us= ed as identity of endpoint

  -  7. If message_4 = shall be sent/expected

  -  8. Subsequent ap= plication protocol

  -  9. Data sent ove= r the subsequent application protocol

  - 10. Cipher suite.=

 

Implementing the same cipher su= ite is just a quite small piece in interoperability between two endpoints.

 

- Having a MTI cipher suite has= significant drawbacks. TLS 1.2 mandates support of TLS_RSA_WITH_AES_128_CB= C_SHA. This cipher suite has at least 3 major weaknesses: static RSA, CBC p= adding attacks, and SHA1. Each one of these weaknesses could independently warrant a must not support. This caus= es a lot of problems, as many industries are very keen on compliance with s= tandards. With TLS 1.2 an implementation can be either compliant or weak. I= personally think the IPsec approach is better: "The specification of suites that MUST and SHOULD be suppo= rted for interoperability has been removed from this document because they = are likely to change more rapidly than this document evolves.". I don'= t see any reason to force local IoT deployments wanting to use EdDSA + X25519 or the CNSA cipher suite to also implement c= ipher suite 0. I can live with something like the current proposal from Ste= phen, but my personal preference would be to not mandate any specific ciphe= r suite at all.

 

- 256 bit: There are definitely= interest in using EDHOC with high-security cipher suites like 24 and 25. O= ne reason is compliance with requirements such as the US CNSA. As TLS, DTLS= , QUIC do not mandate high security cipher suites, it would maybe be a bit strange if EDHOC which has a strong= focus on very constrained environments did so. I don't think it make sense= to force e.g., 6TiSCH devices to implement cipher suite 24 or 25. AES-128 = will provide excellent security for most deployments for the foreseeable future. We should also not force = deployments using 24 or 25 to support, 0,1,2, or 3.

Cheers,
John

--_000_HE1PR0701MB3050866F1EFEA411D8F2180B89799HE1PR0701MB3050_-- From nobody Sat Dec 18 18:25:25 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEFE3A13C6 for ; Sat, 18 Dec 2021 18:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 aVc4SQrJLtiS for ; Sat, 18 Dec 2021 18:25:19 -0800 (PST) Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 BEF6D3A13C4 for ; Sat, 18 Dec 2021 18:25:18 -0800 (PST) Received: from LLEX2019-1.mitll.ad.local (llex2019-1.llan.ll.mit.edu [172.25.4.123]) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 1BJ2PFVX418745 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 18 Dec 2021 21:25:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=aFuYBz6lUN6z9r4HXj88/GExP+7yeouwHCs+jdHhEWwbsdyJT5Da2CCdpBna81Wnk3/VaXIv/mJLLd2mB8K/X/4xCITUvZ8Ec1fLr+cYjI/NSj+ol8f2VkAvyBAmiKlYlyV1MAWg2Yp5wmpYgiH1BuLu/qpaipwNgx3sqHc5ULe0KK2BLlVXPW8AecIak0qBexQpQdVcz3dlTXK8bua6jBHhhTFG2BJ0xbaK07FQQ4gNVXivYuQ2NTx2h99eYG4BPlSLhN3E3qGbDtvBsSsp/3uROcphKoyFCbcvS9RUVPr2qQxtR4Nb+k7CG1aoSbMikpfpveZWE0K0vka7dDXadg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BT5NceA8uM2xJddqt38qtJQX+649KvlfInZBU3Xoi0k=; b=PTgFvckUpLHnlAGhkiMPPq8t5X3xeGd4wMP8+knYyfuJqIPEQHlREZbBsG0koOR9I+VkiIRmZrbBnWM3uH01GsZA2LgtmE+lMQR9zv323cGBmydlYOG0nA1AJZ/bMpP7WnyZE9YPaBOJ0zSO3cCaj0yLWtxwjIwm8q9Au6uO9y0Yogt/1rsndUt+jeBChJ6bAMZ5vXs6YDF1IBDILcP4a5VL4q8LM5VcVITmBcYP+7nW+UDM+TiVbGzv2JlQbdsoxGrfMFiEd5loLq0WxgeAgDu8/bTVLwP9FYqdI1EKklCnPQ5iuxZqO1X5xVv36QsEiYkLJmGftrpmckVb95jJBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: "lake@ietf.org" Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4ifJvzqXdSI0a5MKRvRKOSqqw07yMA///R8YCAAIGUAIAAD1GAgAAInYCAAbFwgP//wx+AgAB81wCAAONogIAAl1eA Date: Sun, 19 Dec 2021 02:25:10 +0000 Message-ID: References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> <3819.1639781374@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3dcb8bb4-83c5-45a7-8737-08d9c296c836 x-ms-traffictypediagnostic: BN0P110MB1062: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /vmn0PaLCYK6mub0IZPKBwb12U2lVM+o2CTlN8f5tF0+w0xWNFJ5PqmGB2HdKa6GtEEwDCJir7YSDXWA1qCUhNsmsLnkhd2Lw0dsiAJ4Rbe24DU1AGDenOgK8zjaw0hElZrPnrluaQo0s09JHzs8nIIECcmjQ7x+88nKhYT9Cf9oCW9ZcQqPGv6XrHR81ndx4uPMy74XSmGfBPIsdpQNBz0oLSFDSrORVtHvHOjanwLeFlwmYZxEzOz++IqzQ0iezMLv8EWqGN/T1IzsSCjlccHgqFegaKwKEgmkETDIRQ+ZSo5o0kTsw3y7Rfb+ME3aU9iPKECWsPQWsTpCQ6m0M8jd3G4LtZDFGxn5Y6ox341mRnBb8Ez5OngjjEHl1UnaeQHmRqTgFS53fn6TQR2noePw7NPoURVJO001TgUMK0f28z9IZFo0QQIF87HhwOeLnpQOc6FLcJd6fLqA7Di8wdQKGNePs7wHRcTBYB9/6A/WFyh8k4bb3qPA/IZyqUQdPol1gZUz95gaLfAaeq2TS13PyjceTkoELRejqZyKm9RXb6PmDUx1UnV4zx8ifmdY405nKII7XAB/PZ4hlX5BwuDqxlluHSyeXgCjgqgzjfi1nLVkg3WCDTiVWAAqWjEiBgi1vuH+gqDYSAPop2GngyZ50XXHqlWR9AsPOtkd76C7Q2iKQxz3HLdKR39S8NcjeHls6pzVWB05qqenXhLdtIDQm/WCzgZrqJd7cPlm1VQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(2616005)(33656002)(66476007)(66946007)(64756008)(6916009)(66556008)(66446008)(186003)(8676002)(86362001)(6512007)(8936002)(5660300002)(71200400001)(83380400001)(6486002)(38100700002)(99936003)(6506007)(122000001)(53546011)(26005)(75432002)(38070700005)(498600001)(2906002)(76116006)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eTR6dFpyRnovc2hsaDgvYVNBcnJkUjZ6dUFBMzVlc2R3bzhtcm04R2lZS21Q?= =?utf-8?B?anFzTEJUbDExaHM1UXFiSFFWeXdCNGd5YUlHUVdYbVJvYUF6NTRkSzE0dE1i?= =?utf-8?B?a0V4RUFTd0V3c2pXVG1OcVNzTGVYS0pmWG5uT1h1WGlWdlVVTzNXR3VVOG9u?= =?utf-8?B?K2hudEFPZXV6aFF2UklGWjhwSmkwVFJ1VDExVkg0aUUzNTdycWZNRkFqWWky?= =?utf-8?B?TEo5WGJsdUt6eStVOGVSQ3liNGlBRGRyOVpGSDNudnhCQkl1M3ZTMzRKY3lK?= =?utf-8?B?dzlYRFlpbFh3bnFicFdOTHgzU1U5VHJ0YUp6Um82WVdRVFBXTkViUkU2VEFB?= =?utf-8?B?OHRIOHVwc0d3VlZkSE5KdGJlMXFJazQ1Ty9UeGtpSnMzS01rSk5oRHZ6b1dz?= =?utf-8?B?MDkrN2tFNjdNZyszclF0N0VHamd4a1ViOUdoMExFcDBpWGpFWk96cnFVSWdX?= =?utf-8?B?SW5oN2dUVzdFMEFaSk1leGtnR1I1eWN3eHBoUXE1dUFDWkpoc096QnV0R2s5?= =?utf-8?B?THBTclk1eU9GS0R1czBNRHV1elJLRkl4Ymc3ZHdwNUFpbUlvL29obDVtM3k2?= =?utf-8?B?aHZOZUxMdnZmV3JtbTlpUW9qSXZ2SDVYMEtjM0VJeXlYemFGNWdmcmxmOWxZ?= =?utf-8?B?SDFLNUpZZzFkb0ZtVzRoVmZjTU56ZE5SemxEU0M4bVJ1VnJjSGNFWGlWYXZO?= =?utf-8?B?NTAwd1FzUE04cU8yL01Uakx5N0lPSmJLMnBuWTRGZmNkeUF2WDViWWxUbkh5?= =?utf-8?B?SVZUUjRKSGlzKy9ZN2pXOERpTGtEK1F0bUorVVhjcVJiRVh1TDFQQk9IQUlu?= =?utf-8?B?WkZ1UnI5dHQzeVZjTmQ5YzlqOHhvRzUydzNYU09GSzVXV3FvcXJha1ZJWXRM?= =?utf-8?B?UEV2c2xhWDJ6LzRFbWdrbkRnVXU1eDlPamlINUdaVW4xSUF5MTAyVFlZeUJV?= =?utf-8?B?R3loVUZuVERybXk5VXU0NXdUajNKM0NCMTVzOFZ4R1dreG5DSkJKN0UySlRK?= =?utf-8?B?U0hHUDJMZDAvZ2pmWVVjVWVtY1NxRENGUldtbTNsM0xQSDZUazluR2lDWE9K?= =?utf-8?B?Rkt5emNRa0hsdHAyNkZXaUNXOC9VR2R2T1BJTlVwSGhjZDh2L0txWmpqZkpY?= =?utf-8?B?TDgwYnVDcHZHWlBzNkxOQ0JBbXB0bjRBRGhQU3NDQXNta2hEYjBHUTBlWENh?= =?utf-8?B?NzMwQURKTGJkaTlWZ3pCKytGNERDbHZ4Y1RNTG0rUkl0YkZMMmNGUC92UTJD?= =?utf-8?B?SFRVMFlrMFdOQWwyYkFOUTBpWGZhRzcyV2hQOEpCNktYR1lVOEpJK1ZTT1Bq?= =?utf-8?B?Y1lsRkFMdFliMVo5bmJQKzZKYk9JVXRqTWcwR3lUa3ZGd0lQOUR3ZzFENmV6?= =?utf-8?B?SnBpMnpJZVRVYmMvc2pHK2NZV1l1Qi8yMm5FT3kzNUVWb0o3VVNKaThwd0NI?= =?utf-8?B?djlJd2taZFQzdEVtQTk5VlQwOUQrZGgrRlpZWVA5dlNVbU9jN2czVml1c2tk?= =?utf-8?B?ZmI0WDVJL3R6MDJaOTFsc2xvbHREdlc2Vmw0ZVpCOVRJRFBiQ2htR3Axd2s4?= =?utf-8?B?WDdyRUhIaHc3UlBDSUtqVjUrSWVHbC9DeHU2RzM2SGw5TDRGUUZ2alFKMWVs?= =?utf-8?B?VWw4NnV4ekxiR1R0QVZzUlFsNExVc0tOSEQ3cW9pdW5YSTdYZTZWWjBvaFhy?= =?utf-8?Q?yNyN14Fe7uHj0jjRPuFy?= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3722707509_140005052" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3dcb8bb4-83c5-45a7-8737-08d9c296c836 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2021 02:25:10.8938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB1062 X-Proofpoint-GUID: AIa6KLKYVn_wdqLGPL5ggDwgOnyrWeQd X-Proofpoint-ORIG-GUID: AIa6KLKYVn_wdqLGPL5ggDwgOnyrWeQd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-18_08:2021-12-15, 2021-12-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 phishscore=0 spamscore=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112190012 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2021 02:25:23 -0000 --B_3722707509_140005052 Content-type: multipart/alternative; boundary="B_3722707509_1651064768" --B_3722707509_1651064768 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable John, =20 You made a great point that I missed. Thank you! =20 Indeed, I wouldn=E2=80=99t want suites 0,1,2,3 enabled in my apps, so the MTI con= sideration is moot. =20 My apologies for taking everybody=E2=80=99s time. -- Regards, Uri =20 There are two ways to design a system. One is to make it so simple there ar= e obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. = - C. A. R. Hoare =20 =20 From: Lake on behalf of John Mattsson Date: Saturday, December 18, 2021 at 07:24 To: "lake@ietf.org" Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite =20 Hi, =20 My two cents: =20 - Interoperability: I don't understand this focus on MTI cipher suite and i= nteroperability. EDHOC works mostly like COSE where different applications a= nd deployments can choose from a smorgasbord of options to optimize what fit= s their specific environment. I think this approach has been very successful= for COSE. Two implementations will not be interoperable unless they impleme= nt the same: =20 - 1. Transport protocol - 2. EDHOC method (0, 1, 2, 3, ......) - 3. ID_CRED_R COSE header parameter (kid, kid_context, x5t, x5chain, x5= bag, x5u, kcwt, kcct, c5u, c5t, c5b, c5c, ....) - 4. CRED_R COSE credential type (CWT, CCS, X.509, C509, ..... ) with a = matching credential profile. - 5. Use and type of external authorization data (EAD_1, EAD_2, EAD_3, E= AD_4) - 6. Identifier used as identity of endpoint - 7. If message_4 shall be sent/expected - 8. Subsequent application protocol - 9. Data sent over the subsequent application protocol - 10. Cipher suite. =20 Implementing the same cipher suite is just a quite small piece in interoper= ability between two endpoints.=20 =20 - Having a MTI cipher suite has significant drawbacks. TLS 1.2 mandates sup= port of TLS_RSA_WITH_AES_128_CBC_SHA. This cipher suite has at least 3 major= weaknesses: static RSA, CBC padding attacks, and SHA1. Each one of these we= aknesses could independently warrant a must not support. This causes a lot o= f problems, as many industries are very keen on compliance with standards. W= ith TLS 1.2 an implementation can be either compliant or weak. I personally = think the IPsec approach is better: "The specification of suites that MUST a= nd SHOULD be supported for interoperability has been removed from this docum= ent because they are likely to change more rapidly than this document evolve= s.". I don't see any reason to force local IoT deployments wanting to use Ed= DSA + X25519 or the CNSA cipher suite to also implement cipher suite 0. I ca= n live with something like the current proposal from Stephen, but my persona= l preference would be to not mandate any specific cipher suite at all. =20 - 256 bit: There are definitely interest in using EDHOC with high-security = cipher suites like 24 and 25. One reason is compliance with requirements suc= h as the US CNSA. As TLS, DTLS, QUIC do not mandate high security cipher sui= tes, it would maybe be a bit strange if EDHOC which has a strong focus on ve= ry constrained environments did so. I don't think it make sense to force e.g= ., 6TiSCH devices to implement cipher suite 24 or 25. AES-128 will provide e= xcellent security for most deployments for the foreseeable future. We should= also not force deployments using 24 or 25 to support, 0,1,2, or 3. Cheers, John --B_3722707509_1651064768 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

John,

 

You made a great point that I missed. Thank you!

 =

Indeed, I= wouldn=E2=80=99t want suites 0,1,2,3 enabled in my apps, so the MTI consideration= is moot.

 

My apologies for taking everybody=E2=80=99s time.

--<= /o:p>

Regards,

Uri

 

There are = two ways to design a system. One is to make it so simple there are obviously= no deficiencies.=

The other is to make it so complex there are no obvious deficiencies.<= /span>

<= p class=3DMsoNormal>  =             &nbs= p;              =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;  -  C. A. R. Hoare

 

 

Fr= om: Lake <lake-boun= ces@ietf.org> on behalf of John Mattsson <john.mattsson=3D40ericsson.com= @dmarc.ietf.org>
Date: Saturday, December 18, 2021 at 07:24
= To: "lake@ietf.org" <lake@ietf.org>
Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite

 

Hi,

 

My two c= ents:

 <= /o:p>

- Interoperability: I d= on't understand this focus on MTI cipher suite and interoperability. EDHOC w= orks mostly like COSE where different applications and deployments can choos= e from a smorgasbord of options to optimize what fits their specific environ= ment. I think this approach has been very successful for COSE. Two implement= ations will not be interoperable unless they implement the same:<= /p>

 

  -  1. Transport protocol

  -  2. EDH= OC method (0, 1, 2, 3, ......)

  -  3. ID_CRED_R COSE header parameter (kid, kid_con= text, x5t, x5chain, x5bag, x5u, kcwt, kcct, c5u, c5t, c5b, c5c, ....)

  -  4. CRED_R= COSE credential type (CWT, CCS, X.509, C509, ..... ) with a matching creden= tial profile.

&nbs= p; -  5. Use and type of external authorization data (EAD_1, EAD_2, EAD= _3, EAD_4)

  = -  6. Identifier used as identity of endpoint

  -  7. If message_4 shall be sen= t/expected

  = -  8. Subsequent application protocol

  -  9. Data sent over the subsequent app= lication protocol

=   - 10. Cipher suite.

 

Im= plementing the same cipher suite is just a quite small piece in interoperabi= lity between two endpoints.

 

= - Having a MTI cipher suite has significant drawbacks. TLS 1.2 mandates supp= ort of TLS_RSA_WITH_AES_128_CBC_SHA. This cipher suite has at least 3 major = weaknesses: static RSA, CBC padding attacks, and SHA1. Each one of these wea= knesses could independently warrant a must not support. This causes a lot of= problems, as many industries are very keen on compliance with standards. Wi= th TLS 1.2 an implementation can be either compliant or weak. I personally t= hink the IPsec approach is better: "The specification of suites that MU= ST and SHOULD be supported for interoperability has been removed from this d= ocument because they are likely to change more rapidly than this document ev= olves.". I don't see any reason to force local IoT deployments wanting = to use EdDSA + X25519 or the CNSA cipher suite to also implement cipher suit= e 0. I can live with something like the current proposal from Stephen, but m= y personal preference would be to not mandate any specific cipher suite at a= ll.

 

- 256 bit: There are definitely interest= in using EDHOC with high-security cipher suites like 24 and 25. One reason = is compliance with requirements such as the US CNSA. As TLS, DTLS, QUIC do n= ot mandate high security cipher suites, it would maybe be a bit strange if E= DHOC which has a strong focus on very constrained environments did so. I don= 't think it make sense to force e.g., 6TiSCH devices to implement cipher sui= te 24 or 25. AES-128 will provide excellent security for most deployments fo= r the foreseeable future. We should also not force deployments using 24 or 2= 5 to support, 0,1,2, or 3.

<= span style=3D'font-size:11.0pt'>Cheers,
John

--B_3722707509_1651064768-- --B_3722707509_140005052 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAUW1xDL1n3IkFBHAAAABRbXMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMjEwNzA2MjM0ODI1WhcNMjYwMzAy MjM1OTU5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMRXUPN5Fz28jb9GOca2/6HDq5EE4Hu T1enB0TiMEnOTipW88pgPmSZ/AAFyJF7AWX7PYPw94Ed/Bbs7yCCa6WZS7cQzdHOWppx9gRZ AxkR8+TgosxPcHoCMXmI/hXtVdZ7mwZlpBGJvyBe6YRmxOWLl3WiCRi/gBThwEWsiQZOfhEN 7hC2GhgCKetpNlTRPxslLmkStNlnjNAxhet8Vm/KSYJFVPOx3qytdLwnO6sz4AfIJJQkFX26 6oP0F/4bjRGlIZrZpdUPGiydpJl1r5SRcYs1ZE7JHErULWSyiAIzBDHUCTcN2GnFoR+9fz92 q2VIHvNHx7bV1hd0E0zlC9UCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBSQ5IixU+wo9uUYNUB4 G/ea7vuWEjAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAICZO a7qQQMDGZzRUaX+Mm/3meVo0nTEdNby178MGq6uYGUS4keIkljEoI+KiEMbT8rtCOBZwomnO HdJmLuRUEgrVAos27V4yjvoic8QKsz+qEhxslFg/2EYMAbTsyLqg34R+wG5o6K95ohUrgLud fPxAmcLOFBtIZBr/3DUIlzw4xHKiX2ruex7YOrQccgXb2qGtNB7tG6jAaXqFb+NZTJhj+3pd OiZiZanzpZvPLIH6Xe4awqDrok7q9ImwwSSQorNrJxKKtA3vLUW3DGvom3XDiOjDqpzhmqXC u6Wf7JfrSJRaudU2WyvYfPk7NQlkLR/1G6Xz+zKqO/cBt2aNATGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDSO2hLk5eJtOetU14M26wSLiT9Ku8l0PhOC2ot tkCxYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEyMTkw MjI1MDlaMA0GCSqGSIb3DQEBAQUABIIBAGVLJn+AvLtnFzeU2yqwr5Y2avTuxm5WY/MnzZ/8 fijDoqPvlXmHv/74w+JO+Pf3ijqQmSJCCmqiNBCI9sfpLz+O2eur94uEdk4s6CX1JsY4E65m 3DAD1MvrLVlpefLZ25yptUwW6gLttiuhgSL33KtnWjNb0WjLpFAaaFEm82ym6pk5OdP3t0A8 37SE5Okzo5NRa7dxWUqlht+mew9HVJcWGTOECjZ0i80lj7jRLt3QCTpy3uMQ3VaRdnOUhQgi yw0+bctRXGCgmq+wF9rO+rbL4qZQ+iCR1nt7bJD+OonogK6PrYKsEDbD3Okk6RuxWvVUpQwH ENmHA78l1vm6vME= --B_3722707509_140005052-- From nobody Sat Dec 18 23:30:22 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0755B3A09B7 for ; Sat, 18 Dec 2021 23:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 Psmy7Z2NlGtG for ; Sat, 18 Dec 2021 23:30:17 -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 2C1683A09AC for ; Sat, 18 Dec 2021 23:30:17 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id y83-20020a1c7d56000000b003456dfe7c5cso6302018wmc.1 for ; Sat, 18 Dec 2021 23:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:from:to:subject; bh=+2JF6ksdcYKxFFBjq0Qz+W12gMwQtT6RwehNHH2Ei4g=; b=HuIcV9dPtp4WmYgOg+7AMZjL6LHqxwK05Pgl+1z34jEeqYL6My4ZUB1oaI0V9DKAtw zAadhiWtn89r+S7jb+X9gTYcZrJtEUHRGwcKnWBQPfjQJi4UtK88QpS8VeK7faRpY3eu JE1Rf7QXqPHp2NkfiGvl4dMqJmZNJeMrw7s0UZmMUMlbDM5+ISv3VNd7evJyp2FWf7Js FHODulcTwhDsX87hjzCmH58Xz6DMCVCYaD4o5OtizQkeyzrjWTJmoBS3JjBbZ2wxKIrI 1gL+zGVY2l5BIu4MNRK992aG9uQEqgQxw3ilLU+JVo2JB+w5Jswe5RdWTbCA2bEZjFRj +nNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:from:to:subject; bh=+2JF6ksdcYKxFFBjq0Qz+W12gMwQtT6RwehNHH2Ei4g=; b=x7Xnj1KyptVxuzB2DuqDgNHIZnsi8EwJGuDtaHgQcLHyJHoIIeEI/swfD5cJx1p7/d 6jBwJfT+sqAPwrK7cntHrtvXjeLr223yoQuyUVXWJHhV6nVMVIH6Y19oOcVKJJKI++GO eTTINTcUhzUhDfM58853QYoRAybmDE3acLsmF/1PxeSHsp7M96dOsGtQgjp68IeE8212 rxNuTIwu4kYTfIOHcEOtDeQ2wRWN3XlTvfDvqF/KDmmyAUNhyX5p3YlxaM/djyPltEFq QqgncKaimK4oCVNzC6lTOZ8iJMAQMrp2NLOZku5d0rcHtlLRX4Hj8joD/EgZ1l/u5swx JNdQ== X-Gm-Message-State: AOAM532bbUKtYAodFtiDY/+fAWEYKwBxSsW8kX5ICozpdwsOHd5Noz5L nroKr5h9yi0JM8RQ3nlQs9Rb/RqwEWM= X-Google-Smtp-Source: ABdhPJxiej+eXNY1mp0TGP01z6JKq4Ztuw5w5j+0Z2laqY/Du8rcY8bN/paFMlSeye1HKDi6FeY0ig== X-Received: by 2002:a05:600c:4998:: with SMTP id h24mr4249822wmp.188.1639899014038; Sat, 18 Dec 2021 23:30:14 -0800 (PST) Received: from basil.dsg.cs.tcd.ie (basil.dsg.cs.tcd.ie. [134.226.36.138]) by smtp.gmail.com with ESMTPSA id n4sm12771458wrc.1.2021.12.18.23.30.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Dec 2021 23:30:13 -0800 (PST) Message-ID: <61bedf85.1c69fb81.8962a.db20@mx.google.com> Date: Sat, 18 Dec 2021 23:30:13 -0800 (PST) Content-Type: multipart/alternative; boundary="===============1381460932885449068==" MIME-Version: 1.0 From: Webmaster via GitHub API To: lake@ietf.org Archived-At: Subject: [Lake] Weekly github digest (reqs, edhoc) X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2021 07:30:20 -0000 --===============1381460932885449068== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * lake-wg/edhoc (+2/-6/=F0=9F=92=AC22) 2 issues created: - Ed25519 instead of EdDSA (by gselander) https://github.com/lake-wg/edhoc/issues/218=20 - Sean Turner's review of -12 (by gselander) https://github.com/lake-wg/edhoc/issues/217=20 14 issues received 22 new comments: - #218 Ed25519 instead of EdDSA (2 by emanjon, malishav) https://github.com/lake-wg/edhoc/issues/218=20 - #215 Verification of identities in X.509 and CWT (1 by emanjon) https://github.com/lake-wg/edhoc/issues/215=20 - #209 Change MTI cipher suite to (0 AND 1) OR (2 AND 3) (3 by emanjon, m= alishav) https://github.com/lake-wg/edhoc/issues/209 [Close?] [Done in master]=20 - #208 Error message =3D> Discontinue (1 by emanjon) https://github.com/lake-wg/edhoc/issues/208=20 - #204 Length of labels, removal of master (1 by chrysn) https://github.com/lake-wg/edhoc/issues/204 [Close?] [PR exists] [Inter= im 15 Dec 2021]=20 - #202 Stephen Farrell 's review of -12 (2 by chrysn, emanjon) https://github.com/lake-wg/edhoc/issues/202 [Close?] [PR exists]=20 - #196 Kathleen Moriarty's review of -12 (1 by gselander) https://github.com/lake-wg/edhoc/issues/196 [Done in master]=20 - #193 Allow COSE HPKE algorithms for method 0? (1 by emanjon) https://github.com/lake-wg/edhoc/issues/193 [Close?]=20 - #192 Marco Tiloca's review of -12 (1 by gselander) https://github.com/lake-wg/edhoc/issues/192 [PR exists]=20 - #189 Optional padding to hide length of ID_CRED_I and ID_CRED_R? (1 by = emanjon) https://github.com/lake-wg/edhoc/issues/189 [PR exists] [Interim 15 Dec= 2021]=20 - #185 Test Vectors - more suits (4 by emanjon, gselander) https://github.com/lake-wg/edhoc/issues/185 [traces and test vectors]=20 - #167 Registration procedures for the new EDHOC registries (2 by emanjon= , gselander) https://github.com/lake-wg/edhoc/issues/167 [Close?]=20 - #84 Make .well-known/edhoc specific to OSCORE (1 by chrysn) https://github.com/lake-wg/edhoc/issues/84 [Close?]=20 - #81 Effects of limited amounts of randomness (1 by chrysn) https://github.com/lake-wg/edhoc/issues/81 [Close?] [PR exists]=20 6 issues closed: - Allow COSE HPKE algorithms for method 0? https://github.com/lake-wg/edh= oc/issues/193 [Close?]=20 - Make .well-known/edhoc specific to OSCORE https://github.com/lake-wg/ed= hoc/issues/84 [Close?]=20 - Kathleen Moriarty's review of -12 https://github.com/lake-wg/edhoc/issu= es/196 [Done in master]=20 - Stefan Hristozov's review of -12 https://github.com/lake-wg/edhoc/issue= s/194 [PR exists]=20 - EAD internal structure and the EAD API https://github.com/lake-wg/edhoc= /issues/186 [PR exists]=20 - Marco Tiloca's review of -12 https://github.com/lake-wg/edhoc/issues/19= 2 [PR exists]=20 Pull requests ------------- * lake-wg/edhoc (+2/-3/=F0=9F=92=AC1) 2 pull requests submitted: - Security considerations on connection IDs (by emanjon) https://github.com/lake-wg/edhoc/pull/219=20 - Minor update on method support (by gselander) https://github.com/lake-wg/edhoc/pull/216=20 1 pull requests received 1 new comments: - #200 Updates following Stefan's review (1 by gselander) https://github.com/lake-wg/edhoc/pull/200=20 3 pull requests merged: - Updates following Stefan's review https://github.com/lake-wg/edhoc/pull/200=20 - EAD internal structure and the EAD API (issue #186) https://github.com/lake-wg/edhoc/pull/206=20 - Updates following Marco's review https://github.com/lake-wg/edhoc/pull/199=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/lake-wg/reqs * https://github.com/lake-wg/edhoc --===============1381460932885449068== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (reqs, edhoc)

Sunday December 19, 2021

Issues

lake-wg/edhoc (+2/-6/=F0=9F=92=AC22)

2 issues created:

14 issues received 22 new comments:

6 issues closed:

Pull requests

lake-wg/edhoc (+2/-3/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

3 pull requests merged:

Repositories tracked by this digest:
--===============1381460932885449068==-- From nobody Mon Dec 20 00:01:04 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CA43A0A50 for ; Mon, 20 Dec 2021 00:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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_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=sony.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 y9-XefpCaOE6 for ; Mon, 20 Dec 2021 00:00:50 -0800 (PST) Received: from mx07-001d1705.pphosted.com (mx07-001d1705.pphosted.com [185.132.183.11]) (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 C56A43A100D for ; Mon, 20 Dec 2021 00:00:49 -0800 (PST) Received: from pps.filterd (m0209326.ppops.net [127.0.0.1]) by mx08-001d1705.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1BK3gWvX011806 for ; Mon, 20 Dec 2021 08:00:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sony.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=S1; bh=4AT6Dj16b3w+/Xf2OHgL6wwu+ynHlPECc7INlUAaj6k=; b=IQ+7X303FamN0IC4oQ97d8/9R4+Pqm4NbXqL0WzHB8SJqZUe28R43l2eaU84c9ovncHF tMcEzNsFLtamoUPCdyWdoVCG1bwafAco8Y/8WmHy99qJk43TFzGZsF2W/v/sBvrr2g61 BDqhVNlaT80cONxwUSjxkahWN6v6RyEH7r5qvMeD+5B1wuUFMP1K06HDf9Al+P4Zz8Ti UAJk84sQ35+L5TazBVZ3MT+Dj0PFKy28vXZcc+qVa2W5+FttpJ6NS6dUsF9samAqysXp wck5m3fFtcnCZg3ihhhrQmiotHzmyON02AfHQ2/EYeDAaEDJLzzhQrnPASaSVRVWa62X PQ== Received: from eur02-he1-obe.outbound.protection.outlook.com (mail-he1eur02lp2052.outbound.protection.outlook.com [104.47.5.52]) by mx08-001d1705.pphosted.com with ESMTP id 3d15uj1898-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 20 Dec 2021 08:00:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AqFq7kqsbjNMIVfzJeqy58ykGFWX3tDYmo45VGWi+17o8llOXlQ4A5Hg1VnrNkVOXlkJNbnVAmRx08PEtbQfn8EHjtNv0T+R2pI8afdehLCYG32PLq2gUBEjCrwNEr0q14CBQEs3bLTWVfFL8jyQH+Ka7P/N2W2LK6KNvMCVczobaEzi4HBNtR/vJOAwWAOWtFjhyu84K5MjkqQnhpHjV6hA7mAU2qIHIUqGa2ymL84HSXMcnYaNnBwvcG+NJpoTRNNYjACxk1sQnXvt6AT9/7wyRPf3aQvDj5lRsPpzatXGzHJNOyRM2RKcUKzURPkx7UpJFt4ymBpFTFeRusqehw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4AT6Dj16b3w+/Xf2OHgL6wwu+ynHlPECc7INlUAaj6k=; b=iv4hqfHo8WgLSwpf28CdP5vcf6SwODrgSS0DyIZUzsjoZPYp0ksTxdv54ZFKHI3AWPqOaMKFdeXSKfNjhyxNMv41nWXV9oSZl3njZQTjaHQyb3NhWW9D/L8X952cYXayFO3EV/uNoUol825ZsHB6ApJtamKT99fanFbkfoHXZpWFZfrt15lJb3YC8MQkhBZ1PtbdwSfBrbHvCmCZNWI5tko673/shlsCx1xNhqzThoJMamVUbIiQtWMWgpglTCIZXyevjYLq2ZLuSyyXynt+MRME2BJCRFuuDGjpHMNW2sZKBDxNxfLjYHNefmtDnrkMN/EZpsGjW+TfHvfMC00WTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sony.com; dmarc=pass action=none header.from=sony.com; dkim=pass header.d=sony.com; arc=none Received: from AM8P193MB0979.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:1ea::23) by AM0P193MB0468.EURP193.PROD.OUTLOOK.COM (2603:10a6:208:58::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.15; Mon, 20 Dec 2021 07:59:33 +0000 Received: from AM8P193MB0979.EURP193.PROD.OUTLOOK.COM ([fe80::d0f7:a264:76e5:b7b7]) by AM8P193MB0979.EURP193.PROD.OUTLOOK.COM ([fe80::d0f7:a264:76e5:b7b7%4]) with mapi id 15.20.4801.020; Mon, 20 Dec 2021 07:59:32 +0000 From: To: Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4TLRIcNjTfSUyliAOyWYVd9aw07yMAgAAlxACAAC3BAIAAD1SAgAAIm4CAAbFwgIAAFvCAgAApBQCAAONogIAA6yoAgAHokqA= Date: Mon, 20 Dec 2021 07:59:32 +0000 Message-ID: References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> <3819.1639781374@localhost> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9dc4ce0f-c3b3-40ed-a593-08d9c38ea872 x-ms-traffictypediagnostic: AM0P193MB0468:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BJVHuJYqlbTWz9wsiOcEqlBCTR40w/u4hkz9N4mPlgNX+laEDhme5Ra5xGEAvoc8z4J6vwaKeiyUoz9+KuFDsPZXkBFlt5JOBqIL2sSFuM6mvIGzSVN5RWa2VmzkaESlUmk4OrX5/+KfisoRiMia/Sj9uX+HHXATLGfxHcw0XX0pZ/nkuEr+PH22gYE7kZ/OV5Zc17oN5+1n3qcDqv39lCmK4SeaYiCmTJrBfFMU34SWOs/XSV9j1gib6KaFhPvgpJzyAv/67HyAYCuKHb8VyJ0/oisufrZfAqvVtFUMPhbolNc8TolcQbRUA0qjB/9rL5BVN1Ke0wONh/zLsQyMde6zLyHVtpfIzHUia0f2aXxgqJOsmEBznhTNyvmalFse5pJ8VFkQgZqfmOXJ3T/GadHhZ9ssijNV8v9fYYmIj0k9/eN7yA2W/kFSRuF2Fg4lhegNygrSKk7ygfpB+cmB1JoDHinFDoPChVNg375jqTZIfN3RxKfIEDSJ7QSdJiB8uho+gtMMPC2AdsPAUs1FLXCmFMEC+5zMBBAikSgglSIbJI0uzzD7N2JJQQR4vvGV+s2whupwoQhhhvH/4GhJCA0uDg5E8AJZWgV7QiipN27aLuJEumnm8soLKpxYz8W4AyNSELDmjF3TVqlU4fsTeHqJwnLMVByrjFvDlWnc+TafghLwJK/lyYvF5F3ScyE13zecDNAMLN9WnWNVvDwMvg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P193MB0979.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(26005)(86362001)(82960400001)(71200400001)(9686003)(33656002)(8676002)(52536014)(6506007)(186003)(508600001)(55016003)(83380400001)(53546011)(8936002)(38100700002)(66946007)(7696005)(2906002)(66446008)(66476007)(76116006)(66556008)(64756008)(316002)(122000001)(6916009)(38070700005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NW1lQys5Y3FZbkF6d0M3YVlGSjh5RmVINnl0ck9HV0pwNW5FcEJkOU1pdG1v?= =?utf-8?B?UlVyTXF2YnBDWVR6Y2RtYm0vcDllTUJhdDNsWVppRXBnZmUvNmF2RGh2ZUE4?= =?utf-8?B?UVA4NDA1ck9kZ3NENEZiRHo4RzBDSnowSDBGdTFYYzl6SDVrR0VpN00yOCs2?= =?utf-8?B?ZHg0Q24yMG9DeW5WelNqODY2VVRrL0tzQ2xTSFNTbGxhTktjdURIMm83VFNU?= =?utf-8?B?a0VSNUpZUXBab08wbEdFTjlKTGxyZFBucERvOGpTeXY4ME1VSWVsQnp1QjdC?= =?utf-8?B?VEoxSHZ6VytpYytYWTNDZjNwRU93d3lTUWRWeWxoQ0NaM2svSGhSR1hvNnYy?= =?utf-8?B?Y1hJRG45NmV3UGl1R25CYUJpd040ajhWNytCcisvcmVJelE2S1p4eVRSWTdJ?= =?utf-8?B?ZEV2Q3JlcjVkTDlTSlBIYWFaanJXQ0ZTQW9wM0VZMWFJK085WWZzdWQwZ3Jy?= =?utf-8?B?WlpoaEhLR3R2M254dXdHMUVVZ1BmQlIvNHRlSE5IeFc3ZFlXZlpZWmZ3QjV1?= =?utf-8?B?TnIyNlhyUG03VDlaN1NOcWU4SktDSXZGc245VkdSaFFGZkNxWkNrQlFmaGw0?= =?utf-8?B?Q0t4dDc0VDRBNkZDYWRTc1FITEEyTmZzZUtxYW9lZTJYcjIraFNPS0kzcndF?= =?utf-8?B?bXNTZDRqeHVjT1RuSHdUQWZKS2x3SHd3YUphbjY0VFAwOEJJV0pCUlNzZjF5?= =?utf-8?B?NSthNHd2a1g2ajJkMXpKanZ2NGVvdUFPUEhUSmxCSG1yZEhIcE5VU0FOWDlw?= =?utf-8?B?b1lBSnVydkI5RGt1V2lWT2U0TURra2VDZlJQY1Fhc09vWmN5NmkzRUxhZXZs?= =?utf-8?B?WW52dzZnUEFlWVlqV3JTdlBvVnZsZ0syM0U4b3ZBVlk0YW1vQnRHdklCdDhN?= =?utf-8?B?Nnh0bUNGOGZ1b2FuaVpOR0ppd3ZmM2lMYjlEZTZtTEFOTWh2Zm9tMDNNNUNL?= =?utf-8?B?VXpXLzFaQ004cHQ1RG0vVXFGZHJOSU1GNFZOc3Z0aHhDNzBkWm43czRjWTgy?= =?utf-8?B?bURTaVRkTjkrQ1pBK0FBamVWT0owMnVHZXR5ZVIvM0NpVEUwcHFZL2NrMFVE?= =?utf-8?B?UGorQ29XNkIvaUg1MHdleTBkNll4bS8yTGZuSUpDREltd0FjOGJnTFNTWCs3?= =?utf-8?B?Q0hKdW1HS3c2bWRxQVp5YndVd090ekE1blpHTDBUWlNWUUVCSUhkVnhIaWs5?= =?utf-8?B?ZHpTYk1YWXllcUFQRTkrTmR2NzMwbVVXSDVsNXRHbHhGQ1V1STlxRWt4dEZL?= =?utf-8?B?dFNQcFdtT24zSk5MaDNVbmJ3bnljem5oTTFpWm9PMzh5MnRiVkgycW42QTJQ?= =?utf-8?B?dUE4S05zWXJMWGtUeVBTU09qMzkvK2JJbk9wV1NTWVFQb3RjbVp6SHJNc05C?= =?utf-8?B?OUl3TEEvRkczQkJwa3diVkNGaURuYitJMkhsLy93WTB1OFJBd1ladFB1a1d0?= =?utf-8?B?aEVtYk1kRGZhYTl3VE8yV0lHcGovR1pieHRXckpWd2FoOGZramNFL0MvVlFs?= =?utf-8?B?dFplWHBmUjFOUnljc1UrcFRXOFFncXJyVHlBclpSN2xzcEFhcUxQVlRyME4r?= =?utf-8?B?Y3Y5bXUrODB2dkhtZFVTVTdybExBZFA4aDk3K0V6TklUNHVrV2pUalVJeEVC?= =?utf-8?B?eXlDQ2JPRStrcjhMTFk3NitkU2NjN1RqNGFQRjc0dTEyT21yRGNtZ0dtcEhn?= =?utf-8?B?RnU2QWl5SVpBdHBlOW0ySzNiL0ZGKy9nZFpPZkVNUDlMV3gvaUNvdzc4UEFX?= =?utf-8?B?Q1M3K0I1Y0VKZE1ybzRSSVo4NTlwaFdpOGFvODVCTk5KTnl0SXlsblpOYTk2?= =?utf-8?B?TGpVV2NoMVJkV3o0bll2VzE5eW1uYkxhZnNLNGQ0Y1J0ck4rKzkvMWJFV2po?= =?utf-8?B?WjZZN1NDa2hLRWYzeUU0Mlo3NHRkUDdDSHA1cXdiMi9LZjM5cnllQjdUeEJs?= =?utf-8?B?cHJLa3NpamVLQitRSlF2ZWRuMnlqcGs2Q0hhV1ZvTDRPcVFjZGVxa0Q1NEkv?= =?utf-8?B?a2grblZXUXZQaUtNMDdXVHdUc1Y1RTF6Qkt0RFB5NHlGaGVhSm02UWp5L3Rh?= =?utf-8?B?Z2dleHlkb1gvQ0JMR202ZGNxZnplUDlQNmFJU2lQdXhhOGVkMXZHMHJ6bWNE?= =?utf-8?B?VUhhT2k5TjQ2OXNHRHF2Z2owc1REb1FtcHhjYWVZdTMvZitLZjNaSEMxd3R6?= =?utf-8?B?SFltL0hST3FSNlFIUS8rRVo0cXJSMkgxTjlIRk5jNFFoZEhuU1lJbHo5WEww?= =?utf-8?B?NGt2SWwyVzJzUVY5SGJkZVR2QjdBPT0=?= Content-Type: multipart/alternative; boundary="_000_AM8P193MB0979B363CE7C41BECBB2D9F0837B9AM8P193MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: sony.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P193MB0979.EURP193.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9dc4ce0f-c3b3-40ed-a593-08d9c38ea872 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2021 07:59:32.7869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 66c65d8a-9158-4521-a2d8-664963db48e4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /RqCgs8/jFJINyqPVJgYWOLIy97qBT+zMGvvV22T3D4/aSRyHlYomAgT0V7/p0omz+/ljTGd5o+FUiBxkXWN4vwI8B/vZ5DIU2ENj+Z4Z28= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P193MB0468 X-Proofpoint-GUID: WcvqlSxRMdhbFCGRWAlyXwRy7s9HTKNe X-Proofpoint-ORIG-GUID: WcvqlSxRMdhbFCGRWAlyXwRy7s9HTKNe X-Sony-Outbound-GUID: WcvqlSxRMdhbFCGRWAlyXwRy7s9HTKNe X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-20_04,2021-12-16_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 impostorscore=0 clxscore=1011 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112200046 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 08:00:59 -0000 --_000_AM8P193MB0979B363CE7C41BECBB2D9F0837B9AM8P193MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgTVRJIGFuZCBpbnRlcm9wZXJhYmlsaXR5IGRpc2N1c3Npb24gaXMgYSBrZXkg dG9waWM6DQpUaGUgdGhvdWdodCBvZiBhIG1pbmltYWwgc2V0IGFsbG93aW5nIG15IGRlcGxveW1l bnQgdG8gaW50ZXJ3b3JrIHdpdGggYW4gYXJiaXRyYXJ5IG9uZSBpcyB2ZXJ5IGFwcGVhbGluZy4N Cg0KSG93ZXZlciwgZ2l2ZW4gdGhlIHZhcmlhdGlvbiBpbiBwcmUtY29uZGl0aW9ucyBhbmQgcHJp b3JpdGllcyBpbiBkaWZmZXJlbnQgZW52aXJvbm1lbnRzIHRvZ2V0aGVyIHdpdGggdGhlIG9wdGlv bnMgbGlzdGVkIGJ5IEpvaG4sDQpJIG11c3Qgc2F5IGl0IHNlZW1zIGxpa2UgKGEgY29tcGFjdCkg 4oCcb25lIHNpemXigJ0gd2lsbCBub3QgZml0IGFsbCBhbmQgYSBsYXJnZXIgc2NvcGUgb2YgTVRJ IHdpbGwgYmUgYSBidXJkZW4gaW4gY29uc3RyYWluZWQgZGVwbG95bWVudHM6DQpJIGZpbmQgaXQg cmVhbGx5IGhhcmQgdG8gc2F5IHdoaWNoIG9mIHRoZSAxLTEwIHRoYXQgd291bGQgYmUgYWNjZXB0 YWJsZSBhbmQgbWFrZSBzZW5zZSAgLSBmb3IgYWxsIGRlcGxveW1lbnRzIC0gaW4gdGVybXMgb2Yg a2V5IG1hbmFnZW1lbnQsIHNlY3VyaXR5IGxldmVsLCBtZXNzYWdlIHNpemVzIGV0Yy4NCg0KDQoN CkJlc3QNClBldGVyDQoNCg0KRnJvbTogTGFrZSA8bGFrZS1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMDQpTZW50OiBkZW4gMTkgZGVj ZW1iZXIgMjAyMSAwMzoyNQ0KVG86IGxha2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTGFrZV0g QW1iaWd1b3VzIHRleHQgb24gTWFuZGF0b3J5IHRvIEltcGxlbWVudCBzdWl0ZQ0KDQpKb2huLA0K DQpZb3UgbWFkZSBhIGdyZWF0IHBvaW50IHRoYXQgSSBtaXNzZWQuIFRoYW5rIHlvdSENCg0KSW5k ZWVkLCBJIHdvdWxkbuKAmXQgd2FudCBzdWl0ZXMgMCwxLDIsMyBlbmFibGVkIGluIG15IGFwcHMs IHNvIHRoZSBNVEkgY29uc2lkZXJhdGlvbiBpcyBtb290Lg0KDQpNeSBhcG9sb2dpZXMgZm9yIHRh a2luZyBldmVyeWJvZHnigJlzIHRpbWUuDQotLQ0KUmVnYXJkcywNClVyaQ0KDQpUaGVyZSBhcmUg dHdvIHdheXMgdG8gZGVzaWduIGEgc3lzdGVtLiBPbmUgaXMgdG8gbWFrZSBpdCBzbyBzaW1wbGUg dGhlcmUgYXJlIG9idmlvdXNseSBubyBkZWZpY2llbmNpZXMuDQpUaGUgb3RoZXIgaXMgdG8gbWFr ZSBpdCBzbyBjb21wbGV4IHRoZXJlIGFyZSBubyBvYnZpb3VzIGRlZmljaWVuY2llcy4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtICBDLiBBLiBSLiBIb2FyZQ0KDQoNCkZyb206IExha2UgPGxha2UtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bGFrZS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb249NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOmpvaG4ubWF0dHNzb249NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0K RGF0ZTogU2F0dXJkYXksIERlY2VtYmVyIDE4LCAyMDIxIGF0IDA3OjI0DQpUbzogImxha2VAaWV0 Zi5vcmc8bWFpbHRvOmxha2VAaWV0Zi5vcmc+IiA8bGFrZUBpZXRmLm9yZzxtYWlsdG86bGFrZUBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0xha2VdIEFtYmlndW91cyB0ZXh0IG9uIE1hbmRhdG9y eSB0byBJbXBsZW1lbnQgc3VpdGUNCg0KSGksDQoNCk15IHR3byBjZW50czoNCg0KLSBJbnRlcm9w ZXJhYmlsaXR5OiBJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBmb2N1cyBvbiBNVEkgY2lwaGVyIHN1 aXRlIGFuZCBpbnRlcm9wZXJhYmlsaXR5LiBFREhPQyB3b3JrcyBtb3N0bHkgbGlrZSBDT1NFIHdo ZXJlIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgYW5kIGRlcGxveW1lbnRzIGNhbiBjaG9vc2UgZnJv bSBhIHNtb3JnYXNib3JkIG9mIG9wdGlvbnMgdG8gb3B0aW1pemUgd2hhdCBmaXRzIHRoZWlyIHNw ZWNpZmljIGVudmlyb25tZW50LiBJIHRoaW5rIHRoaXMgYXBwcm9hY2ggaGFzIGJlZW4gdmVyeSBz dWNjZXNzZnVsIGZvciBDT1NFLiBUd28gaW1wbGVtZW50YXRpb25zIHdpbGwgbm90IGJlIGludGVy b3BlcmFibGUgdW5sZXNzIHRoZXkgaW1wbGVtZW50IHRoZSBzYW1lOg0KDQogIC0gIDEuIFRyYW5z cG9ydCBwcm90b2NvbA0KICAtICAyLiBFREhPQyBtZXRob2QgKDAsIDEsIDIsIDMsIC4uLi4uLikN CiAgLSAgMy4gSURfQ1JFRF9SIENPU0UgaGVhZGVyIHBhcmFtZXRlciAoa2lkLCBraWRfY29udGV4 dCwgeDV0LCB4NWNoYWluLCB4NWJhZywgeDV1LCBrY3d0LCBrY2N0LCBjNXUsIGM1dCwgYzViLCBj NWMsIC4uLi4pDQogIC0gIDQuIENSRURfUiBDT1NFIGNyZWRlbnRpYWwgdHlwZSAoQ1dULCBDQ1Ms IFguNTA5LCBDNTA5LCAuLi4uLiApIHdpdGggYSBtYXRjaGluZyBjcmVkZW50aWFsIHByb2ZpbGUu DQogIC0gIDUuIFVzZSBhbmQgdHlwZSBvZiBleHRlcm5hbCBhdXRob3JpemF0aW9uIGRhdGEgKEVB RF8xLCBFQURfMiwgRUFEXzMsIEVBRF80KQ0KICAtICA2LiBJZGVudGlmaWVyIHVzZWQgYXMgaWRl bnRpdHkgb2YgZW5kcG9pbnQNCiAgLSAgNy4gSWYgbWVzc2FnZV80IHNoYWxsIGJlIHNlbnQvZXhw ZWN0ZWQNCiAgLSAgOC4gU3Vic2VxdWVudCBhcHBsaWNhdGlvbiBwcm90b2NvbA0KICAtICA5LiBE YXRhIHNlbnQgb3ZlciB0aGUgc3Vic2VxdWVudCBhcHBsaWNhdGlvbiBwcm90b2NvbA0KICAtIDEw LiBDaXBoZXIgc3VpdGUuDQoNCkltcGxlbWVudGluZyB0aGUgc2FtZSBjaXBoZXIgc3VpdGUgaXMg anVzdCBhIHF1aXRlIHNtYWxsIHBpZWNlIGluIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0d28g ZW5kcG9pbnRzLg0KDQotIEhhdmluZyBhIE1USSBjaXBoZXIgc3VpdGUgaGFzIHNpZ25pZmljYW50 IGRyYXdiYWNrcy4gVExTIDEuMiBtYW5kYXRlcyBzdXBwb3J0IG9mIFRMU19SU0FfV0lUSF9BRVNf MTI4X0NCQ19TSEEuIFRoaXMgY2lwaGVyIHN1aXRlIGhhcyBhdCBsZWFzdCAzIG1ham9yIHdlYWtu ZXNzZXM6IHN0YXRpYyBSU0EsIENCQyBwYWRkaW5nIGF0dGFja3MsIGFuZCBTSEExLiBFYWNoIG9u ZSBvZiB0aGVzZSB3ZWFrbmVzc2VzIGNvdWxkIGluZGVwZW5kZW50bHkgd2FycmFudCBhIG11c3Qg bm90IHN1cHBvcnQuIFRoaXMgY2F1c2VzIGEgbG90IG9mIHByb2JsZW1zLCBhcyBtYW55IGluZHVz dHJpZXMgYXJlIHZlcnkga2VlbiBvbiBjb21wbGlhbmNlIHdpdGggc3RhbmRhcmRzLiBXaXRoIFRM UyAxLjIgYW4gaW1wbGVtZW50YXRpb24gY2FuIGJlIGVpdGhlciBjb21wbGlhbnQgb3Igd2Vhay4g SSBwZXJzb25hbGx5IHRoaW5rIHRoZSBJUHNlYyBhcHByb2FjaCBpcyBiZXR0ZXI6ICJUaGUgc3Bl Y2lmaWNhdGlvbiBvZiBzdWl0ZXMgdGhhdCBNVVNUIGFuZCBTSE9VTEQgYmUgc3VwcG9ydGVkIGZv ciBpbnRlcm9wZXJhYmlsaXR5IGhhcyBiZWVuIHJlbW92ZWQgZnJvbSB0aGlzIGRvY3VtZW50IGJl Y2F1c2UgdGhleSBhcmUgbGlrZWx5IHRvIGNoYW5nZSBtb3JlIHJhcGlkbHkgdGhhbiB0aGlzIGRv Y3VtZW50IGV2b2x2ZXMuIi4gSSBkb24ndCBzZWUgYW55IHJlYXNvbiB0byBmb3JjZSBsb2NhbCBJ b1QgZGVwbG95bWVudHMgd2FudGluZyB0byB1c2UgRWREU0EgKyBYMjU1MTkgb3IgdGhlIENOU0Eg Y2lwaGVyIHN1aXRlIHRvIGFsc28gaW1wbGVtZW50IGNpcGhlciBzdWl0ZSAwLiBJIGNhbiBsaXZl IHdpdGggc29tZXRoaW5nIGxpa2UgdGhlIGN1cnJlbnQgcHJvcG9zYWwgZnJvbSBTdGVwaGVuLCBi dXQgbXkgcGVyc29uYWwgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBub3QgbWFuZGF0ZSBhbnkgc3Bl Y2lmaWMgY2lwaGVyIHN1aXRlIGF0IGFsbC4NCg0KLSAyNTYgYml0OiBUaGVyZSBhcmUgZGVmaW5p dGVseSBpbnRlcmVzdCBpbiB1c2luZyBFREhPQyB3aXRoIGhpZ2gtc2VjdXJpdHkgY2lwaGVyIHN1 aXRlcyBsaWtlIDI0IGFuZCAyNS4gT25lIHJlYXNvbiBpcyBjb21wbGlhbmNlIHdpdGggcmVxdWly ZW1lbnRzIHN1Y2ggYXMgdGhlIFVTIENOU0EuIEFzIFRMUywgRFRMUywgUVVJQyBkbyBub3QgbWFu ZGF0ZSBoaWdoIHNlY3VyaXR5IGNpcGhlciBzdWl0ZXMsIGl0IHdvdWxkIG1heWJlIGJlIGEgYml0 IHN0cmFuZ2UgaWYgRURIT0Mgd2hpY2ggaGFzIGEgc3Ryb25nIGZvY3VzIG9uIHZlcnkgY29uc3Ry YWluZWQgZW52aXJvbm1lbnRzIGRpZCBzby4gSSBkb24ndCB0aGluayBpdCBtYWtlIHNlbnNlIHRv IGZvcmNlIGUuZy4sIDZUaVNDSCBkZXZpY2VzIHRvIGltcGxlbWVudCBjaXBoZXIgc3VpdGUgMjQg b3IgMjUuIEFFUy0xMjggd2lsbCBwcm92aWRlIGV4Y2VsbGVudCBzZWN1cml0eSBmb3IgbW9zdCBk ZXBsb3ltZW50cyBmb3IgdGhlIGZvcmVzZWVhYmxlIGZ1dHVyZS4gV2Ugc2hvdWxkIGFsc28gbm90 IGZvcmNlIGRlcGxveW1lbnRzIHVzaW5nIDI0IG9yIDI1IHRvIHN1cHBvcnQsIDAsMSwyLCBvciAz Lg0KQ2hlZXJzLA0KSm9obg0K --_000_AM8P193MB0979B363CE7C41BECBB2D9F0837B9AM8P193MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iU1YiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB0aGluayB0aGUgTVRJIGFuZCBpbnRlcm9wZXJhYmlsaXR5 IGRpc2N1c3Npb24gaXMgYSBrZXkgdG9waWM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgdGhvdWdodCBvZiBhIG1pbmltYWwgc2V0 IGFsbG93aW5nIG15IGRlcGxveW1lbnQgdG8gaW50ZXJ3b3JrIHdpdGggYW4gYXJiaXRyYXJ5IG9u ZSBpcyB2ZXJ5IGFwcGVhbGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SG93ZXZlciwgZ2l2ZW4gdGhlIHZhcmlhdGlv biBpbiBwcmUtY29uZGl0aW9ucyBhbmQgcHJpb3JpdGllcyBpbiBkaWZmZXJlbnQgZW52aXJvbm1l bnRzIHRvZ2V0aGVyIHdpdGggdGhlIG9wdGlvbnMgbGlzdGVkIGJ5IEpvaG4sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIG11c3Qgc2F5 IGl0IHNlZW1zIGxpa2UgKGEgY29tcGFjdCkg4oCcb25lIHNpemXigJ0gd2lsbCBub3QgZml0IGFs bCBhbmQgYSBsYXJnZXIgc2NvcGUgb2YgTVRJIHdpbGwgYmUgYSBidXJkZW4gaW4gY29uc3RyYWlu ZWQgZGVwbG95bWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JIGZpbmQgaXQgcmVhbGx5IGhhcmQgdG8gc2F5IHdoaWNoIG9mIHRo ZSAxLTEwIHRoYXQgd291bGQgYmUgYWNjZXB0YWJsZSBhbmQgbWFrZSBzZW5zZSAmbmJzcDstIGZv ciBhbGwgZGVwbG95bWVudHMgLSBpbiB0ZXJtcyBvZiBrZXkgbWFuYWdlbWVudCwgc2VjdXJpdHkg bGV2ZWwsIG1lc3NhZ2Ugc2l6ZXMNCiBldGMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CZXN0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5QZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+IExha2UgJmx0O2xha2UtYm91bmNlc0BpZXRmLm9yZyZndDsN CjxiPk9uIEJlaGFsZiBPZiA8L2I+Qmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMPGJyPg0K PGI+U2VudDo8L2I+IGRlbiAxOSBkZWNlbWJlciAyMDIxIDAzOjI1PGJyPg0KPGI+VG86PC9iPiBs YWtlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTGFrZV0gQW1iaWd1b3VzIHRl eHQgb24gTWFuZGF0b3J5IHRvIEltcGxlbWVudCBzdWl0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kb2huLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Z b3UgbWFkZSBhIGdyZWF0IHBvaW50IHRoYXQgSSBtaXNzZWQuIFRoYW5rIHlvdSE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+SW5kZWVkLCBJIHdvdWxkbuKAmXQgd2FudCBzdWl0ZXMgMCwxLDIsMyBlbmFibGVkIGluIG15 IGFwcHMsIHNvIHRoZSBNVEkgY29uc2lkZXJhdGlvbiBpcyBtb290LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5NeSBh cG9sb2dpZXMgZm9yIHRha2luZyBldmVyeWJvZHnigJlzIHRpbWUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPi0tPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+VXJpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGk+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5UaGVyZSBhcmUgdHdvIHdheXMgdG8gZGVz aWduIGEgc3lzdGVtLiBPbmUgaXMgdG8gbWFrZSBpdCBzbyBzaW1wbGUgdGhlcmUgYXJlIG9idmlv dXNseSBubyBkZWZpY2llbmNpZXMuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+VGhlIG90aGVyIGlzIHRvIG1ha2UgaXQgc28gY29tcGxleCB0 aGVyZSBhcmUgbm8gb2J2aW91cyBkZWZpY2llbmNpZXMuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7IEMuIEEuIFIuIEhvYXJlPC9zcGFuPjwvaT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkxha2UgJmx0OzxhIGhyZWY9Im1h aWx0bzpsYWtlLWJvdW5jZXNAaWV0Zi5vcmciPmxha2UtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBKb2huIE1hdHRzc29uICZsdDs8YSBocmVmPSJtYWlsdG86am9obi5tYXR0 c3Nvbj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+am9obi5tYXR0c3Nvbj00MGVyaWNz c29uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5 LCBEZWNlbWJlciAxOCwgMjAyMSBhdCAwNzoyNDxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmxha2VAaWV0Zi5vcmciPmxha2VAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bGFrZUBpZXRmLm9yZyI+bGFrZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbTGFrZV0gQW1iaWd1b3VzIHRleHQgb24gTWFuZGF0b3J5IHRvIElt cGxlbWVudCBzdWl0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5NeSB0d28gY2VudHM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4tIEludGVyb3BlcmFiaWxpdHk6IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlz IGZvY3VzIG9uIE1USSBjaXBoZXIgc3VpdGUgYW5kIGludGVyb3BlcmFiaWxpdHkuIEVESE9DIHdv cmtzIG1vc3RseSBsaWtlIENPU0Ugd2hlcmUgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBhbmQgZGVw bG95bWVudHMgY2FuIGNob29zZSBmcm9tIGEgc21vcmdhc2JvcmQNCiBvZiBvcHRpb25zIHRvIG9w dGltaXplIHdoYXQgZml0cyB0aGVpciBzcGVjaWZpYyBlbnZpcm9ubWVudC4gSSB0aGluayB0aGlz IGFwcHJvYWNoIGhhcyBiZWVuIHZlcnkgc3VjY2Vzc2Z1bCBmb3IgQ09TRS4gVHdvIGltcGxlbWVu dGF0aW9ucyB3aWxsIG5vdCBiZSBpbnRlcm9wZXJhYmxlIHVubGVzcyB0aGV5IGltcGxlbWVudCB0 aGUgc2FtZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAtJm5ic3A7IDEuIFRyYW5zcG9ydCBwcm90 b2NvbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgLSZuYnNwOyAyLiBF REhPQyBtZXRob2QgKDAsIDEsIDIsIDMsIC4uLi4uLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7IC0mbmJzcDsgMy4gSURfQ1JFRF9SIENPU0UgaGVhZGVyIHBhcmFtZXRl ciAoa2lkLCBraWRfY29udGV4dCwgeDV0LCB4NWNoYWluLCB4NWJhZywgeDV1LCBrY3d0LCBrY2N0 LCBjNXUsIGM1dCwgYzViLCBjNWMsIC4uLi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAtJm5ic3A7IDQuIENSRURfUiBDT1NFIGNyZWRlbnRpYWwgdHlwZSAoQ1dULCBD Q1MsIFguNTA5LCBDNTA5LCAuLi4uLiApIHdpdGggYSBtYXRjaGluZyBjcmVkZW50aWFsIHByb2Zp bGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAtJm5ic3A7IDUuIFVz ZSBhbmQgdHlwZSBvZiBleHRlcm5hbCBhdXRob3JpemF0aW9uIGRhdGEgKEVBRF8xLCBFQURfMiwg RUFEXzMsIEVBRF80KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgLSZu YnNwOyA2LiBJZGVudGlmaWVyIHVzZWQgYXMgaWRlbnRpdHkgb2YgZW5kcG9pbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7IC0mbmJzcDsgNy4gSWYgbWVzc2FnZV80IHNo YWxsIGJlIHNlbnQvZXhwZWN0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7IC0mbmJzcDsgOC4gU3Vic2VxdWVudCBhcHBsaWNhdGlvbiBwcm90b2NvbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgLSZuYnNwOyA5LiBEYXRhIHNlbnQgb3ZlciB0 aGUgc3Vic2VxdWVudCBhcHBsaWNhdGlvbiBwcm90b2NvbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsgLSAxMC4gQ2lwaGVyIHN1aXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW1w bGVtZW50aW5nIHRoZSBzYW1lIGNpcGhlciBzdWl0ZSBpcyBqdXN0IGEgcXVpdGUgc21hbGwgcGll Y2UgaW4gaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIHR3byBlbmRwb2ludHMuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPi0gSGF2aW5nIGEgTVRJIGNpcGhlciBzdWl0ZSBoYXMgc2lnbmlmaWNhbnQgZHJhd2Jh Y2tzLiBUTFMgMS4yIG1hbmRhdGVzIHN1cHBvcnQgb2YgVExTX1JTQV9XSVRIX0FFU18xMjhfQ0JD X1NIQS4gVGhpcyBjaXBoZXIgc3VpdGUgaGFzIGF0IGxlYXN0IDMgbWFqb3Igd2Vha25lc3Nlczog c3RhdGljIFJTQSwgQ0JDIHBhZGRpbmcgYXR0YWNrcywNCiBhbmQgU0hBMS4gRWFjaCBvbmUgb2Yg dGhlc2Ugd2Vha25lc3NlcyBjb3VsZCBpbmRlcGVuZGVudGx5IHdhcnJhbnQgYSBtdXN0IG5vdCBz dXBwb3J0LiBUaGlzIGNhdXNlcyBhIGxvdCBvZiBwcm9ibGVtcywgYXMgbWFueSBpbmR1c3RyaWVz IGFyZSB2ZXJ5IGtlZW4gb24gY29tcGxpYW5jZSB3aXRoIHN0YW5kYXJkcy4gV2l0aCBUTFMgMS4y IGFuIGltcGxlbWVudGF0aW9uIGNhbiBiZSBlaXRoZXIgY29tcGxpYW50IG9yIHdlYWsuIEkgcGVy c29uYWxseQ0KIHRoaW5rIHRoZSBJUHNlYyBhcHByb2FjaCBpcyBiZXR0ZXI6ICZxdW90O1RoZSBz cGVjaWZpY2F0aW9uIG9mIHN1aXRlcyB0aGF0IE1VU1QgYW5kIFNIT1VMRCBiZSBzdXBwb3J0ZWQg Zm9yIGludGVyb3BlcmFiaWxpdHkgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIHRoaXMgZG9jdW1lbnQg YmVjYXVzZSB0aGV5IGFyZSBsaWtlbHkgdG8gY2hhbmdlIG1vcmUgcmFwaWRseSB0aGFuIHRoaXMg ZG9jdW1lbnQgZXZvbHZlcy4mcXVvdDsuIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24NCiB0byBmb3Jj ZSBsb2NhbCBJb1QgZGVwbG95bWVudHMgd2FudGluZyB0byB1c2UgRWREU0EgKyBYMjU1MTkgb3Ig dGhlIENOU0EgY2lwaGVyIHN1aXRlIHRvIGFsc28gaW1wbGVtZW50IGNpcGhlciBzdWl0ZSAwLiBJ IGNhbiBsaXZlIHdpdGggc29tZXRoaW5nIGxpa2UgdGhlIGN1cnJlbnQgcHJvcG9zYWwgZnJvbSBT dGVwaGVuLCBidXQgbXkgcGVyc29uYWwgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBub3QgbWFuZGF0 ZSBhbnkgc3BlY2lmaWMgY2lwaGVyDQogc3VpdGUgYXQgYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+LSAyNTYgYml0OiBUaGVyZSBhcmUgZGVmaW5pdGVseSBpbnRlcmVzdCBpbiB1c2luZyBFREhP QyB3aXRoIGhpZ2gtc2VjdXJpdHkgY2lwaGVyIHN1aXRlcyBsaWtlIDI0IGFuZCAyNS4gT25lIHJl YXNvbiBpcyBjb21wbGlhbmNlIHdpdGggcmVxdWlyZW1lbnRzIHN1Y2ggYXMgdGhlIFVTIENOU0Eu IEFzIFRMUywgRFRMUywgUVVJQyBkbyBub3QgbWFuZGF0ZSBoaWdoIHNlY3VyaXR5IGNpcGhlciBz dWl0ZXMsIGl0IHdvdWxkDQogbWF5YmUgYmUgYSBiaXQgc3RyYW5nZSBpZiBFREhPQyB3aGljaCBo YXMgYSBzdHJvbmcgZm9jdXMgb24gdmVyeSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMgZGlkIHNv LiBJIGRvbid0IHRoaW5rIGl0IG1ha2Ugc2Vuc2UgdG8gZm9yY2UgZS5nLiwgNlRpU0NIIGRldmlj ZXMgdG8gaW1wbGVtZW50IGNpcGhlciBzdWl0ZSAyNCBvciAyNS4gQUVTLTEyOCB3aWxsIHByb3Zp ZGUgZXhjZWxsZW50IHNlY3VyaXR5IGZvciBtb3N0IGRlcGxveW1lbnRzIGZvcg0KIHRoZSBmb3Jl c2VlYWJsZSBmdXR1cmUuIFdlIHNob3VsZCBhbHNvIG5vdCBmb3JjZSBkZXBsb3ltZW50cyB1c2lu ZyAyNCBvciAyNSB0byBzdXBwb3J0LCAwLDEsMiwgb3IgMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow Y207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4w cHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaGVlcnMs PGJyPg0KSm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_AM8P193MB0979B363CE7C41BECBB2D9F0837B9AM8P193MB0979EURP_-- From nobody Mon Dec 20 06:37:25 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472143A0E12 for ; Mon, 20 Dec 2021 06:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 UorrthOfiiid for ; Mon, 20 Dec 2021 06:37:19 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B189A3A0E19 for ; Mon, 20 Dec 2021 06:37:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 949043957C; Mon, 20 Dec 2021 09:41:41 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4_VYHwRl41Qi; Mon, 20 Dec 2021 09:41:40 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 64E043957B; Mon, 20 Dec 2021 09:41:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640011300; bh=sMWZUxl28JcXoGN9D0MGxAuso899IvgSwMwFmxhPd0U=; h=From:To:Subject:In-Reply-To:References:Date:From; b=dPAAE9ZIlW8JyaXRlSIRaHvWyoUvfctD65dxXRgVizRh40/K4Qzj1I3yiISIZwiRy 2anT7TsZJMMK451bbPG2DFUa/tnfKbgBFl0MXEikhDMDgC8984CvGqcZ79XR63RL8f ZieXnecY+yi+UdZFyroRpSZJn/lliqQNlDR+mCyxNKlLiWEhDJxx5qJnfS8CsuJWJQ +QXqit1nhw3T5XRuy3w8ORH9PNTMYVa6MWGBM+ZfTOTtd+0BO4plMCIYkQVavkwjO4 IL6Y7gINP42tOf+n2fQe21yPrZg0wCT49VVzwA/RPNnI4jtnX+nn0Rv1o3fKgf36oB 3DlrwcRt0fyfg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E990998E; Mon, 20 Dec 2021 09:37:10 -0500 (EST) From: Michael Richardson To: Peter.Blomqvist@sony.com, lake@ietf.org In-Reply-To: References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> <3819.1639781374@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 14:37:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable wrote: > I think the MTI and interoperability discussion is a key topic: > The thought of a minimal set allowing my deployment to interwork with > an arbitrary one is very appealing. Agreed. We just need a diety to give us the one true encryption algorithm = :-) > I find it really hard to say which of the 1-10 that would be acceptab= le > and make sense - for all deployments - in terms of key management, > security level, message sizes etc. What I see is that constrained libraries will have compile-time options, an= d that non-constrained systems will attempt to support them all with runtime polic= ies. The biggest challenge in target systems will be having a CBOR/COSE library that is both minimal enough, but also capable enough to support EDHOC. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHAlRYACgkQgItw+93Q 3WWZ1wgAs8GMa0u0+CkLba30dissjRkTEmfNVPIC+N7fQYtz8H33fGtnYKaIz4ar ySuN94DQvl2Nxiy3UHIAiJgMcCm1bFE2NLlJ2DpXmnCSeC9qIMpsw7m+XQADK7xJ S4tjJrRBrnUr2OxamyU0oTP9ER0IyNe29anLH6pT2E1HVZV8qEQmt77yz1knKC+K qHuMZlWGLdR7WY++2vmH7G590H62t70fDq4KH8N6VMjNN8nZ4j7loLpDCCkRr7qr xLw4JOz+vYX/28TtINusBbsQZDIMt2d4jgT6w6rkTRRd604GzkJkq2hG1UUPXUPV O1jK6yKuPACJ4krizbX5jI2zw/qSgA== =RBvg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 20 09:45:18 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4263A0044 for ; Mon, 20 Dec 2021 09:45:16 -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 LATwsNtudJBe for ; Mon, 20 Dec 2021 09:45:10 -0800 (PST) Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (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 B30AC3A003F for ; Mon, 20 Dec 2021 09:45:10 -0800 (PST) Received: from LLEX2019-3.mitll.ad.local (llex2019-3.llan.ll.mit.edu [172.25.4.125]) by MX2.LL.MIT.EDU (8.16.1.2/8.16.1.2) with ESMTPS id 1BKHj7qn125613 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 20 Dec 2021 12:45:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=b64EgocHjYCMZndnzHciCn8jHiUdDtI/8IA46Ax4tQR1ErgTjrRAIhL0MsiwgrzRH6tjNbB9HC7KIY/C4irdcNjiRP9CzqnEIayW0nbFxolj4CVzBM8bTsvvoF0VverkL7qwc+UgUePIPfpNSh3lMyvQBZSr1jB0MuoUNaOSVAmqVW3jdKSWUFxhkTZShZ0uU/x8bVB6ts8spofS36zCT8+uxOLC2QrJ1xAe+zVrLuH/gkQ2DKyNH2eYwZYtvtlkG32OtWa1qeqG5WbrZYDiIKuK/ODLxJvsQiOtIfhq5ykYtAo9kxCK4hsCZqCjaZXHd62di3mu4QJBn4qo/8IweQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=O+yxnfCY3fKEkm044fmSMSOjijQoIK0jlDIj05ikdlA=; b=Sbcys7luA5DqNBwZYKwssA/FKifkVPlODqvlXzZ3ZQgN+Szlw6gjAicjuKLUDpqw6jwBecdGooR94yGU7jYO3px7GwL3I2tivgb4QlQH5lpDA5JWwRouH7KZGsp7uzTInCYKlsz5BF9Y4HzOUPa/7f1jSUZSnz1dNNxYlTOqi4KoC+fc1OGXYRbSXB2Jkajd9yQJDlSoj6BcJmzFn6YME7pDz5ARNDeBlxETKT1rigYYi5Ffk1aG1SgvpEj1TUtfIqckksgS2NVEbSUVIxoByRG2PgIgDqTOXVGJAptaQ11AOkrbWaWUUo/SnNPvlKFW+OgT+/AsoBt6Fh9kWt7jNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: Michael Richardson , "Peter.Blomqvist@sony.com" , "lake@ietf.org" Thread-Topic: [Lake] Ambiguous text on Mandatory to Implement suite Thread-Index: AQHX8l4ifJvzqXdSI0a5MKRvRKOSqqw07yMA///R8YCAAIGUAIAAD1GAgAAInYCAAbFwgP//wx+AgAB81wCAAONogIAAl1eAgAJDkwCAAG8ZAP//4LEA Date: Mon, 20 Dec 2021 17:45:07 +0000 Message-ID: References: <07072A66-FFC2-47B8-B02E-46CC90BC96F1@ll.mit.edu> <4F36291F-D798-44FA-8AD1-AB954CCEAC7F@tzi.org> <48074.1639767639@dooku> <56ADA2B3-ACC1-496D-B51D-1107A31BF703@ll.mit.edu> <3819.1639781374@localhost> <21314.1640011030@localhost> In-Reply-To: <21314.1640011030@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 26ebadc3-7365-4e63-e60d-08d9c3e0764b x-ms-traffictypediagnostic: BN0P110MB1466: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sHEdQAH8r45/MmOYYkbiIygGZff3GUDaQd/YTYwlfzLJubnwtoxfxuIQcwkGezkghMwWW0niI+qNT0LcO4kRzjZRuxcIvJFtj1upfu2OtFiPzVayUM1dc1IPAxCMkC4cdq/QTRPlg4Oua++c4F0aVHWFBUtpghBvG8AOkVlHPi84FmKfSSUoYTSa4ZX8OgkmADsIbLGlVYdG93RgKQKUL1DWywU2hdYfzdR/eUSMMnRalNjGNjdrqYzyUEorzK7c8Tlo3DIPnZxRf/XOQRGSEisF3GrHcWx59pLJEUWckuV6hzeWHlrOuhSg55qktm9WoebnB3TD2n34v4Do3AnyItlRa4QPdg+EBveS+dCvinFfzGb3PKhO8p77eTjzwbYOjam2AYO5vXpeNzppd++NqaKKPRFDvKilmoreX39tLSdR6lWT41pxfeRk4Wxn226VvxKdIQts8QXYz/pqw/OjNC9+gAr8BjlzoMfS8QyNzXp5A8Sj+97FqNySUtcyHI39kUFUzyEX+DRD/Yxtq7PzsNpuxQkf7fL7wh+ALyts4mLthj8+2FqVHVJ5IiXXcFuogNIQL6u9SB80BhUesDBcXDuPB1am1UG+NIU/oh3nm9pcCAEOPeDwmnygh3/rO/efM5Zs6PUttfyX//6QYAXvbt8GdZYvsSoKsA4jS4D6ajQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(186003)(316002)(71200400001)(8936002)(86362001)(26005)(38070700005)(75432002)(76116006)(33656002)(6506007)(99936003)(2906002)(53546011)(508600001)(66476007)(66446008)(66556008)(2616005)(66946007)(64756008)(38100700002)(6486002)(6512007)(8676002)(83380400001)(4744005)(5660300002)(122000001)(110136005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 5EQ8mGq77YMNQWJeO9LhQDU44DnkeRntn3qKMKxDdDPe+Gd3/ex7IyWp5VTTw3NS0WqQPwIouVGDaisfPuTAOBMe7olm84pZKpD6kcEwxpNe1Xt276fBwTqVzirS/mGHc28QqYyFXV8A1V4a7e2k/A== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3722849106_484002732" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 26ebadc3-7365-4e63-e60d-08d9c3e0764b X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2021 17:45:07.2669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB1466 X-Proofpoint-GUID: idKEH6HBU85pgciw-Wt8B0mLMH-Azhsq X-Proofpoint-ORIG-GUID: idKEH6HBU85pgciw-Wt8B0mLMH-Azhsq X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-20_08:2021-12-20, 2021-12-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 phishscore=0 spamscore=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112200098 Archived-At: Subject: Re: [Lake] Ambiguous text on Mandatory to Implement suite X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 17:45:17 -0000 --B_3722849106_484002732 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 12/20/21, 09:38, "Lake on behalf of Michael Richardson" wrote: > wrote: > > I think the MTI and interoperability discussion is a key topic: > > The thought of a minimal set allowing my deployment to interwork with > > an arbitrary one is very appealing. > > Agreed. We just need a deity to give us the one true encryption algorithm :-) For now, that algorithm is AES. :-) ;-) Have it, and enjoy! :D > > I find it really hard to say which of the 1-10 that would be acceptable > > and make sense - for all deployments - in terms of key management, > > security level, message sizes etc. > > What I see is that constrained libraries will have compile-time options, and that > non-constrained systems will attempt to support them all with runtime policies. > The biggest challenge in target systems will be having a CBOR/COSE library > that is both minimal enough, but also capable enough to support EDHOC. In one word - yes. --B_3722849106_484002732 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAUW1xDL1n3IkFBHAAAABRbXMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMjEwNzA2MjM0ODI1WhcNMjYwMzAy MjM1OTU5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMRXUPN5Fz28jb9GOca2/6HDq5EE4Hu T1enB0TiMEnOTipW88pgPmSZ/AAFyJF7AWX7PYPw94Ed/Bbs7yCCa6WZS7cQzdHOWppx9gRZ AxkR8+TgosxPcHoCMXmI/hXtVdZ7mwZlpBGJvyBe6YRmxOWLl3WiCRi/gBThwEWsiQZOfhEN 7hC2GhgCKetpNlTRPxslLmkStNlnjNAxhet8Vm/KSYJFVPOx3qytdLwnO6sz4AfIJJQkFX26 6oP0F/4bjRGlIZrZpdUPGiydpJl1r5SRcYs1ZE7JHErULWSyiAIzBDHUCTcN2GnFoR+9fz92 q2VIHvNHx7bV1hd0E0zlC9UCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBSQ5IixU+wo9uUYNUB4 G/ea7vuWEjAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAICZO a7qQQMDGZzRUaX+Mm/3meVo0nTEdNby178MGq6uYGUS4keIkljEoI+KiEMbT8rtCOBZwomnO HdJmLuRUEgrVAos27V4yjvoic8QKsz+qEhxslFg/2EYMAbTsyLqg34R+wG5o6K95ohUrgLud fPxAmcLOFBtIZBr/3DUIlzw4xHKiX2ruex7YOrQccgXb2qGtNB7tG6jAaXqFb+NZTJhj+3pd OiZiZanzpZvPLIH6Xe4awqDrok7q9ImwwSSQorNrJxKKtA3vLUW3DGvom3XDiOjDqpzhmqXC u6Wf7JfrSJRaudU2WyvYfPk7NQlkLR/1G6Xz+zKqO/cBt2aNATGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADyHaxtc8GrYDIrgAAAAPIdjANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAG4tP65bpxK3e0kDRohZcY3yBLU3F2dsVshM06 7jr4JTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEyMjAx NzQ1MDZaMA0GCSqGSIb3DQEBAQUABIIBAJEwHqeRhlKmxncacPAe2Y34xeW+EQNAiYUDYhKG kNSHNRui2VX9Dyg+716Byfq5YgycmazbZy0TdCYImYbD8mLB7FR4q8N1XkvB0hMIZ/6/9re6 jbX3pX99WfjDFU2Hesr74ji6qpINcLW+eT9z5zPNIk5F/33gvGyYB08DLrRgA9w344ecf3vJ QX65bSI8orCMWLo3iprTfi90L4eaRpFwSZPe7pffyw0CTXLU63VupbwycjsEE6Xh45cAtnDr ikYVbfkLpkvUtVGHfq1GdtyW9MCnQOPt5IOogH2UaYKbqTl8UiyTQtuXhWHk35N4pGst7/Ul UdJSxNQhhGCM3DY= --B_3722849106_484002732-- From nobody Tue Dec 21 01:50:56 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6C3A0942 for ; Tue, 21 Dec 2021 01:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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 (1024-bit key) header.d=ericsson.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 X644hfnBHoJp for ; Tue, 21 Dec 2021 01:50:49 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0208.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1e::208]) (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 15C6C3A0944 for ; Tue, 21 Dec 2021 01:50:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SL12FR9Tq5kRpnzHTN7N4UvetO+H62wJy7JgL1r3LGq/l1c9cdEtBAZsUvk2uPZMDFxE4nQZ6qpGUiWLu4KbkJQs0opYGMRZzjnsMOgYQHH86DStmv2FCWSIHUgMW84F5921oSyTK+2BGXC4zRYdBmMZfDh9hjc5NQRPhr/6in1pvdlSIq8C4zg3rp7mcNhxLWC8VQT1T0nocqxuLowQQ7wdbbzSuF6w3gfjt4mFmnruV1T6FQ9uMzHxouCk2inLTx/aIgI0Wzoj+TEwNp3a7t2m9fLbZ12YMyofPFJpMOxALPIVsaqLKJ+rfcHohcwKNg/nj1lWGTrPD4H4lT9bfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qAh7yFEBHcpCyQi/vwz/14xS977HX83uiCnGnMSbMks=; b=MFCBVeAp521SyIXufU+nicMswhovZmWlFawl962LkAiw0dyWdiSkqjl9tGisQw7iJV+ICX6obRXSQaZUfxXv2kuLGIkCHDgDLonI4FjRkclZqFF/0moOackqgf167p2yUN7rmaVh+Ai1GFikX1ECxgte3G2ymD8ga+F2i5pX5CCwcStbIEfA8jS8zPqNYPNdn6ccBTmdTU7RV4E1iXw9VoRGSKRWDbkE2HYuloYdF53HgheWRA4WEyggmMnAt3bePOwkakQxqwxpLbIjufAWu3mS6Zet/KSqNi94FoMuxTG+vCCfuQsxsXbCwt9XN259IP2aTZPetmC6287NHq9R6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qAh7yFEBHcpCyQi/vwz/14xS977HX83uiCnGnMSbMks=; b=Wu7OD0D2PbDMSCNG2LrQPPu+pAkkR6by4/hiGr84VxlUoAgfFuij7iTLrDsOMR/aDowXJSnyWecS1vtFRvH+KUMFDTPe0JRATEsqqrSG09/frB74gpULBVzkakmg1zZz0MD0LV4D3D28IjmnL+Ygp9e+2SY5yUn8tWPi09cVKdI= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by DB6PR07MB3494.eurprd07.prod.outlook.com (2603:10a6:6:21::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.7; Tue, 21 Dec 2021 09:50:44 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::acd7:51e8:bdfe:c133]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::acd7:51e8:bdfe:c133%7]) with mapi id 15.20.4823.014; Tue, 21 Dec 2021 09:50:43 +0000 From: John Mattsson To: "lake@ietf.org" Thread-Topic: Status and plans for JSON test vectors and draft-traces Thread-Index: AQHX9kzR7ntar57kv0KjlmrW11QGUg== Date: Tue, 21 Dec 2021 09:50:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb02587e-d78f-4397-74b4-08d9c4675b0a x-ms-traffictypediagnostic: DB6PR07MB3494:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6aJj9uzfECONVDjtsuSutDKYYKVri72B+UpfOYFF0aTJXvtVP1Z+bQzTiAIX8soWz72GNv+4YI/2GCtadYvfCnt3cwj6SCuBlJbojqfibEhcZM9JBtDZaQy/ey6i4yp+T7HtkFXTl8EoGDiR4zj9MaIM/ROG/M8EPiAf++JLomjZaUslzkDYvJoEZiuwWRcNSCzvO6xHThvDLyhJXO+4XvdiIGwL5aD+8YTlBDcUrnCRTTEAVACBOc2VtqOkms5iEhCj4R9zz0nUpD5RWFhbst+XxAaecFzqPYngIsqHR9W2hmIj0GfOM155KOzmIwvt7nEsFo2JSSUNw3ykQNrW9m9UFthaWXkho1t648OQVG/BcIknl62JiM1GK7bQx/rid5/FJWLJRXOKhhSIgZDTswzwK9CBdt6Em2OV4sZupkmFSPasRd6uhTRZpxBNnT1rqC+/rDY25NoUmSbHU7WlzC3idBpUEBH5jF2SGEh8z2El4w0yB/c4mz+nzopKSgcB+0Ua+uzKZbZmRpkzk9WVuwBQKjf741HptJf6jgB/vs/HSmG7BYO8xVyvIjcbNx5/OT+XSd18ApKtCB4NsBkGs+HAzic1jmzzzq3/X/A+z/ngyC2GxiyY7hrE8uIPdbKzZSA/y1aQfJyKic7+ZIiaXHLNglwRxgggcJeZzK+Yl+CKpVSoXHGBHPeZ0WClKE7cswS8FRSMm6X78/37ri1wqRuabtzmWsEPPldxjhZDqoMXn2V3sHDeRpaRbv+pR4YLJHLLdLNggxGMizjsDVLTrQALIVb6xA9mONFvarOfm/NRXEa+HfxCerDLFS6CGQLGD3npsVabdXwSnJuL2hjE7RMMssxAeSWoY/dNtqZG1AYfUrpHbL6AiNNaQb/1ZxKc x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(2906002)(38100700002)(44832011)(122000001)(8936002)(71200400001)(316002)(508600001)(7696005)(86362001)(6506007)(76116006)(66946007)(6916009)(91956017)(186003)(9686003)(966005)(38070700005)(52536014)(5660300002)(55016003)(33656002)(66446008)(64756008)(82960400001)(66556008)(66476007)(26005)(8676002)(83380400001)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Il+qQsScmapbAw5eET50cXNdZig8buB3FHz6By1FQl21D9vB8hHIczyGMKUI?= =?us-ascii?Q?e1swZhmgTqg5NDHbxNcFKKynCd1gSBsVtFGFWCyCEoqiWt2gCb3TUFsrAfgp?= =?us-ascii?Q?z+2oUbxT9ulKY711YJYXAiUiDHSznDDHdqAerGnRFyFFqNuZotHgiYnepbW4?= =?us-ascii?Q?0sgFBxmX4BsonzZaGJJW5oPgwl5o+6FJboNODrfraTZndiGx09NjB9uXz+eP?= =?us-ascii?Q?GZryXXLYoCky24n6V3+Xr5y92fhdfQyrjGu78NkPKBRqC508w2ULhUI9g66O?= =?us-ascii?Q?VUHfXXpPTrQFXZ4QhBUohjDWtBar/Wqv0TLQv8mtOehXjpaC7rrIMLRuXsJl?= =?us-ascii?Q?XaTnkzujJDcJYRpSrM1zvv+eXl10rDzVca2NPIVRwGU8EhvJcjlALSWIK/9q?= =?us-ascii?Q?TyxZM4CP/shiOzTDHox6y6YmhwyLoxbgeFEEILwz96KQxJcces3aD2YaB91Y?= =?us-ascii?Q?dfQyVg7NQFYBJNklx+s+iO0qk2eHdtF/xMeszVtKlooPsh4v1jq9OTYTeq6S?= =?us-ascii?Q?g+/Cm55vMQCK5xSOosHh0bZiCm0XUGQascPMb8YJw+9XsiIKM5qUep1RNNi1?= =?us-ascii?Q?cbqoJ9FUt45TVAo0NpLWDn0TCrWVyDitx6bxQqrNjkG0SJnDjbczkuAm0qHs?= =?us-ascii?Q?ZPvHTFStU0JWfstc6uQalZphzFsAibI1qraTMr4K7pFsmXvz9XAboinFuaRs?= =?us-ascii?Q?L5dQuhpzt6gjerZQ86mDnz21pGdVMsh15O830SbssZbj2T/JyMkWGEM41V9m?= =?us-ascii?Q?lUyH7/7nS8w/kizKfPazgf6OO+MXoZRh2KVqOmuNGwasB4gfKnyG+eX5QhZf?= =?us-ascii?Q?lBDmInEvAqdVOG5iJc6CO+HGdf+3d1NZ2AxJJ3f7tceSM6L+msV3fQlCPHcO?= =?us-ascii?Q?gEocJK/HTYNxLIyjo12/007nS7C5QhXK1vXFhs72h8CbG1KLAOLXeuxStyFm?= =?us-ascii?Q?V4IgFFoynUJDTuFVCR0/vB3x2ZK+ZpMIFz0jHgjuvncLQCdfAr9QWDhA4twR?= =?us-ascii?Q?LEXTOeIrlX9bQxoZlQoYGm7M6kLPbJqZBQDf5pe/4eRvzCoj8+fsz8mShgMQ?= =?us-ascii?Q?igYoEcByVYlzOsbCpAS1bzOQ3AGM1qzoxn9hFifxDdIIobA5zETlQZ+BAujH?= =?us-ascii?Q?mDrhxUaA8PMY1K7KF4LquRjnmnPzkRWMHdrH7NuBaV34JWazyMR7YMZ6Xb1C?= =?us-ascii?Q?Gdom9AcAk7SYb9CyfedkBUaY09nvBdbBCu87mtgGMzYurbnwWpiH/vnNvxCU?= =?us-ascii?Q?AD5dgVsurJ5JyjPW9kD5GpxfZx7SI/WwLvZeBZleGm+IYt6xbnuT1xdm81sO?= =?us-ascii?Q?TNwpZg/omCmU3rEwLc85OZM+dnpNMnHRLQcm3LD3113xT5rvWZFI0OcAbwpQ?= =?us-ascii?Q?OhT5JBC+oOFKMDXpBmdqTqc3c0ZOWWK9vKfVDIzldnEK5TlGW7R0jrRnlrgs?= =?us-ascii?Q?p37n32BVwttwsRcMS3QWw0EhgH5JvZrTFjQLteFcHgDT2INtFxcZGsyFY5mr?= =?us-ascii?Q?YQyXG6Qo4PCkwKtM7xHyyfCi44LUZrwPNaUdQwG1qnY3ZbuPQrOOcwXywrJ3?= =?us-ascii?Q?vzY+b08WJwyKg4yMVk9EWPw5zQECosM+837uDCcJMq0f7EYX1bp1gT8lOkZg?= =?us-ascii?Q?3VXNi71d9lOuD3hjxHxkkyOrA8byValtUa9dAEz1eQ67f3TVYBnBgh2WBOo0?= =?us-ascii?Q?5+6lSu4lxEMaNaMWgSappUyttl8=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30504387E109E54389F64F18897C9HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb02587e-d78f-4397-74b4-08d9c4675b0a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2021 09:50:43.5674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9XnOmxChILNwvY4Fb82/W/ym2dhJhtFul9EOP5voHWgsjPfVB3Ksi5MqTNOcE4l5gpND4qo1i0lsSWof7V9IhEkmkniVLLT/dEi0lduEOew= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3494 Archived-At: Subject: [Lake] Status and plans for JSON test vectors and draft-traces X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 09:50:54 -0000 --_000_HE1PR0701MB30504387E109E54389F64F18897C9HE1PR0701MB3050_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JSON test vectors ---------------------------------------- These are test vectors intended for testing implementations. There is no li= mit to the number of JSON test vectors. Currently there are 13 test vectors with s= uite 0 and 1: https://github.com/lake-wg/edhoc/blob/master/test-vectors-11/vectors-json.t= xt We are getting supprisingly little comments on the JSON test vectors and su= prisingly many comments on draft-traces... Current plans: - Combine the current 13 test vectors with equally many test vectors for su= ite 2 and 3 #185 https://github.com/stoprocent/edhoc/tree/feature/mbedtls/test-vectors-11 - Add a table of contents #187 - Add a list of cipher suites that I and R supports #188 If people have JSON test vectors in the same format for other suite such as= 24 and 25 these can be added as well. There is no limit to the number of test vectors here. The= more the merrier. draft-ietf-lake-traces ---------------------------------------- draft-ietf-lake-traces is intented to be a small documented subset of the J= SON test vectors intended to increase understanding for a human reader. For testing implemen= tations, the JSON test vectors should be used. Currently there are two traces in the document. Current plans: - Align with JSON test vectors and add a list of cipher suites that I and R= supports #188 - Change SIG-SIG trace to cipher suite 2 (ECDSA) and use a "real" X509 cert= ificate. There seems to be consensus that the two items in the current plan is an im= provement. There does not seem to be consensus on how to expand draft-traces with more than two traces. We= will not add any additional traces before there there is consensus on what to add. We likely= have to come back to this at a future meeting. ---------------------------------------- I would like to see more comments on the JSON test vectors and draft-ietf-l= ake-traces as a package. Please do also provide motivation for any suggeste= d changes/additions. Cheers, John --_000_HE1PR0701MB30504387E109E54389F64F18897C9HE1PR0701MB3050_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JSON test vectors

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

 

These are test vectors intended for testing implemen= tations. There is no limit to

the number of JSON test = vectors. Currently there are 13 test vectors with suite 0 and 1:

 

https://github.com/lake-wg/edhoc/blob/master/test-ve= ctors-11/vectors-json.txt

 

We are getting supprisingly little comments on the J= SON test vectors and suprisingly

many comments on draft-traces...

 

Current plans:

 

- Combine the current 13 test vectors with equally m= any test vectors for suite 2 and 3 #185

  https://github.com/stoprocent/edhoc/tree/feat= ure/mbedtls/test-vectors-11

- Add a table of contents #187

- Add a list of cipher suites that I and R supports = #188

 

If people have JSON test vectors in the same format = for other suite such as 24 and 25 these can

be added as well. There is no limit to the number of= test vectors here. The more the merrier.

 

 

 

draft-ietf-lake-traces

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

 

draft-ietf-lake-traces is intented to be a small doc= umented subset of the JSON test vectors

intended to increase understanding for a human reade= r. For testing implementations, the JSON

test vectors should be used.

 

Currently there are two traces in the document.

 

Current plans:

 

- Align with JSON test vectors and add a list of cip= her suites that I and R supports #188

- Change SIG-SIG trace to cipher suite 2 (ECDSA) and use a "real" X509 certificate.

 

There seems to be consensus that the two items in th= e current plan is an improvement. There does not seem

to be consensus on how to expand draft-traces with m= ore than two traces. We will not add any

additional traces before there there is consensus on= what to add. We likely have to come back to this at

a future meeting.

 

 

----------------------------------------<= /p>

 

 

I would like to see more commen= ts on the JSON test vectors and draft-ietf-lake-traces as a package. Please do = also provide motivation for any suggested changes/additions.

 

Cheers,

John

--_000_HE1PR0701MB30504387E109E54389F64F18897C9HE1PR0701MB3050_-- From nobody Thu Dec 23 08:48:45 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1633A067B for ; Thu, 23 Dec 2021 08:48:42 -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 x9dAAuJeA8Hb for ; Thu, 23 Dec 2021 08:48: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 D7B973A0651 for ; Thu, 23 Dec 2021 08:48:39 -0800 (PST) IronPort-Data: =?us-ascii?q?A9a23=3AfmAnRamw5d2d1qCdPS7O1K/o5gySJERdPkR7XQ2?= =?us-ascii?q?eYbTBsI5bpzYFzWEfCGHXOv6PMGXxft11YI2080IE6J/RmoNnQANs+CA2RRqmi?= =?us-ascii?q?+KVXIXDdh+Y0wC6d5CYEho/t63yUjRxRSwNZie0SiyFb/6x/RGQ6YnSHuClUbS?= =?us-ascii?q?eYXgqLeNZYHxJZSxLyrdRbrFA0YDR7zOl4bsekuWHULOX82Yc3lE8t8pvnChSU?= =?us-ascii?q?MHa41v0iLCRicdj5zcyn1FNZH4WyDrYw3HQGuG4FcbiLwrPIS3Qw4/Xw/stIov?= =?us-ascii?q?NfrfTaUgWWrXWPAWIljxfQ7Cmj3CupARtg+BiaKFaMB4OzWzWwbidy/0U3XC0Y?= =?us-ascii?q?QIgOqzXkaIDThJZFSB1FaxA4r7OZ3al2SCW5xyfLSO9kp2CC2lzZ+X04N1fBWh?= =?us-ascii?q?N+NQZJSwDKBeZiIqLLBiTIgV3rptyapC3Z8VG4ygmlG6HZcvKiKvrG83ijeK0F?= =?us-ascii?q?h9p7iyWIcvjWg=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AQRVe5a65OT3ZqYNZXgPXwNHXdLJyesId70hD?= =?us-ascii?q?6qkXc3Fom62j/fxG88576faZsl0ssQ8b9+xoSZPtfZq0z/cc3WB7B9iftWfd2F?= =?us-ascii?q?dAVLsSjrff/w=3D=3D?= X-IronPort-AV: E=Sophos;i="5.88,230,1635199200"; d="scan'208";a="916099" Received: from unknown (HELO smtpclient.apple) ([79.143.111.176]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2021 17:48:38 +0100 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Message-Id: <58C5EE31-F1DD-4F9B-9416-C62D76F5FA91@inria.fr> Date: Thu, 23 Dec 2021 17:48:29 +0100 To: lake@ietf.org X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: [Lake] LAKE interim mid-December: Minutes X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 16:48:43 -0000 Dear all, Thank you for attending the interim meeting last Wednesday. We have now = uploaded the minutes [1] and the recording is available on YouTube [2]. = Many, many thanks to Marco for taking notes! Please send any corrections of the minutes you might have to = lake-chairs@ietf.org. We will launch a poll for the mid-January interim beginning of January. = In the meantime, enjoy the holiday season! Mali=C5=A1a and Stephen [1] = https://datatracker.ietf.org/doc/minutes-interim-2021-lake-05-202112151900= / [2] https://www.youtube.com/watch?v=3DCzEQnCB9Ugs From nobody Sat Dec 25 23:30:23 2021 Return-Path: X-Original-To: lake@ietfa.amsl.com Delivered-To: lake@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FA43A1181 for ; Sat, 25 Dec 2021 23:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 WwKhoGJsByxV for ; Sat, 25 Dec 2021 23:30:17 -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 392783A1180 for ; Sat, 25 Dec 2021 23:30:17 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id s1so25737834wra.6 for ; Sat, 25 Dec 2021 23:30:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:from:to:subject; bh=Xxci0DGhID91qjG32aGplRCuI9i7MdpaTQw7hBvi4Us=; b=AQ+0kbphp76TiRCj8Yu6g4uaM9nFWObx22IHQeLYqnCVMDY4r0T4dLHQadXF7P9WUd 6mSI904+6EVtJGTJuXADtxhjKIn5aZbflos5ecfaIYin6WEQX4xrhZnljt94wZfov6Lh 2664V0fTonYTBFDdJNxoDtHpczM3yMLCtq9vHick9nPNbNlWba+QRjfmg/R2bBRWzc+M Rfq2r1FFz5VlXYgO+HaTU3qSXmbkwOX88dvQPtPUPu/bxbiI0Xr9tzZLuEB3h/cFYQrg EGNt5r6Fw53yKvejTeWo3MARrA1WSy/zFm0vlJNCjKn1i6JUe4/SbDIE6T6bBSMn8Dpl pw9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:from:to:subject; bh=Xxci0DGhID91qjG32aGplRCuI9i7MdpaTQw7hBvi4Us=; b=S2OI+hvOk7VMzUfscweFKhfJuzv3Y7SRO1tBpYO7YBN4DxvutoqYBAbBSc9MVi35R6 Gw0CdqnapOomq7FEWosPgUhEvFH60SqNXm4Xp33JkL2BPuZ1+bJ01009vHjctZbtS0xt ejTxdOFhNHxt2g7lp49r9GswrnlT1Xpzf9kahC0InT/xQh5Oe0ujT7jSU3KwkXKYMEkZ jwQnaBNnwWMatyjHelV/LXXKCUneCB3RwtKNHC2D87UTucNaHYqQFckLSl4Z9RWvWOJX 6/GZ0l7kKXC4rScr/i/xcVFflglF+1Au3WuMH/4CPQl+4hh35z9NpoIMNT69mDVSJr3K VMmw== X-Gm-Message-State: AOAM532eKw/xh1l00Z4/29/aUjkfFIs366u5/QXszaJPkbNGKUZ2ZxDV XriO0x/YDhz3OlvpoTYHTehEGRChAlM= X-Google-Smtp-Source: ABdhPJyyPvXhHl7vAyoHuaAzf6pukFkXFndBNedFPopqYeS65bwWeXhhX7RNm6x7WI3rz6FQLvYpRA== X-Received: by 2002:a5d:6146:: with SMTP id y6mr8898035wrt.693.1640503810664; Sat, 25 Dec 2021 23:30:10 -0800 (PST) Received: from basil.dsg.cs.tcd.ie (basil.dsg.cs.tcd.ie. [134.226.36.138]) by smtp.gmail.com with ESMTPSA id h19sm11911907wmm.13.2021.12.25.23.30.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Dec 2021 23:30:10 -0800 (PST) Message-ID: <61c81a02.1c69fb81.71d33.3988@mx.google.com> Date: Sat, 25 Dec 2021 23:30:10 -0800 (PST) Content-Type: multipart/alternative; boundary="===============2076929493978449785==" MIME-Version: 1.0 From: Webmaster via GitHub API To: lake@ietf.org Archived-At: Subject: [Lake] Weekly github digest (reqs, edhoc) X-BeenThere: lake@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Lightweight Authenticated Key Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2021 07:30:21 -0000 --===============2076929493978449785== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * lake-wg/edhoc (+1/-0/=F0=9F=92=AC18) 1 issues created: - Feedback regarding test vectors (by StefanHri) https://github.com/lake-wg/edhoc/issues/222=20 6 issues received 18 new comments: - #222 Feedback regarding test vectors (1 by emanjon) https://github.com/lake-wg/edhoc/issues/222=20 - #218 Ed25519 instead of EdDSA (2 by emanjon) https://github.com/lake-wg/edhoc/issues/218=20 - #208 Error message =3D> Discontinue (1 by emanjon) https://github.com/lake-wg/edhoc/issues/208=20 - #189 Optional padding to hide length of ID_CRED_I and ID_CRED_R? (6 by = emanjon, gselander, marco-tiloca-sics) https://github.com/lake-wg/edhoc/issues/189 [PR exists] [Interim 15 Dec= 2021]=20 - #185 Test Vectors - more suits (7 by emanjon, gselander, marco-tiloca-s= ics, stoprocent) https://github.com/lake-wg/edhoc/issues/185 [traces and test vectors]=20 - #178 Security considerations of TOFU (1 by emanjon) https://github.com/lake-wg/edhoc/issues/178=20 Pull requests ------------- * lake-wg/edhoc (+2/-0/=F0=9F=92=AC0) 2 pull requests submitted: - Ed25519 instead of EdDSA #218 (by emanjon) https://github.com/lake-wg/edhoc/pull/221=20 - Minor cryptographic explanations (by emanjon) https://github.com/lake-wg/edhoc/pull/220=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/lake-wg/reqs * https://github.com/lake-wg/edhoc --===============2076929493978449785== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (reqs, edhoc)

Sunday December 26, 2021

Issues

lake-wg/edhoc (+1/-0/=F0=9F=92=AC18)

1 issues created:

6 issues received 18 new comments:

Pull requests

lake-wg/edhoc (+2/-0/=F0=9F=92=AC0)

2 pull requests submitted:

Repositories tracked by this digest:
--===============2076929493978449785==--