Re: [Lake] Review EDHOC-v12

"Hristozov, Stefan" <stefan.hristozov@aisec.fraunhofer.de> Tue, 14 December 2021 08:28 UTC

Return-Path: <stefan.hristozov@aisec.fraunhofer.de>
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 <lake@ietfa.amsl.com>; 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 <lake@ietfa.amsl.com>; 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 <lake@ietf.org>; 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" <stefan.hristozov@aisec.fraunhofer.de>
To: "goran.selander@ericsson.com" <goran.selander@ericsson.com>, "lake@ietf.org" <lake@ietf.org>
Thread-Topic: Review EDHOC-v12
Thread-Index: AQHX0W9vPW87iAHERUCkfmEyZh8LBawlx2dGgAwezoA=
Date: Tue, 14 Dec 2021 08:28:16 +0000
Message-ID: <ea2d4c1520f401e99d62110bb0f81d40d36ff974.camel@aisec.fraunhofer.de>
References: <AM9P194MB14421943CE1C8378C2A62CE6C38D9@AM9P194MB1442.EURP194.PROD.OUTLOOK.COM> <AM4PR0701MB219508E3C5E8F006A4809F85F46D9@AM4PR0701MB2195.eurprd07.prod.outlook.com>
In-Reply-To: <AM4PR0701MB219508E3C5E8F006A4809F85F46D9@AM4PR0701MB2195.eurprd07.prod.outlook.com>
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: <AM0P194MB033832DB62589F5F52DD4861C3759@AM0P194MB0338.EURP194.PROD.OUTLOOK.COM>
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: <https://mailarchive.ietf.org/arch/msg/lake/4LaKn4PHKm434WIE_6zqhzjl-vs>
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 <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Dec 2021 08:28:33 -0000

Hi Göran,

thanks for addressing my comments!

It looks good to me. I would like to suggest only to add the relevant RFC references regarding revocation in the section "Implementation consideration".

Best regards,
Stefan


On Mon, 2021-12-13 at 14:57 +0000, Göran Selander wrote:
Hi Stefan,

Thanks for the review. It is 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 close #194.


From: Lake <lake-bounces@ietf.org> on behalf of Hristozov, Stefan <stefan.hristozov@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
"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 authentication 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 that the specification allows for implementations where all inputs and output that are generated at run time by the application are provided in non-encoded form to the EDHOC implementation. In this way, the interface to the application will be simpler and CBOR encoding and decoding 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 application or the EDHOC implementation? As far I understand the specification 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 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 cipher suite, i.e., as an int."
Am I understanding that correctly: If other suites are supported in addition 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 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 suites, if the selected is the most preferred then only that cipher suite 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 predefined error code and encoding. Is logging the only use case for the success error code? For example, my implementation logs many things for debugging purposes. However, I never needed a success error code.

[GS] The error code for success came about from a mail exchange on the IOTOPS 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 error". I added this explanation to the text in PR #200.

[1] https://mailarchive.ietf.org/arch/msg/iotops/t9LTpMiZ__kFGZpceLCBaCUHN44/


The spec says that success error code must not be sent, therefore the sentence "Error code 0 MAY be used internally.." needs to be "Error code 0 MAY be used _only_ internally.."?

[GS] I think "MAY only be used internally" is perhaps stating too much (depending on exact meaning of internally). We already state that the success code 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 are used. Whether the success 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 agree 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 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 definition of a success code, the use of ERR_INFO in a successful status report allows additional information relevant to the application to complement 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 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
"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 an 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 format, 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 brought 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 definition it should also include COSE header parameter which then can be used 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 the 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 added a sentence in PR #200.


Thanks
Göran


--

Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC
Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. +49 89 32299 86 157
stefan.hristozov@aisec.fraunhofer.de<mailto:stefan.hristozov@aisec.fraunhofer.de>
https://www.aisec.fraunhofer.de/