Re: [Cfrg] Crypto-panel review of draft-selander-ace-cose-ecdhe-12

John Mattsson <john.mattsson@ericsson.com> Wed, 27 February 2019 10:35 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16042130EB0 for <cfrg@ietfa.amsl.com>; Wed, 27 Feb 2019 02:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 header.b=YiZ5kYsf; dkim=pass (1024-bit key) header.d=ericsson.com header.b=WAZQ0/EM
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 8VFsugqADMq9 for <cfrg@ietfa.amsl.com>; Wed, 27 Feb 2019 02:35:09 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.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 B6C6B128CF3 for <cfrg@irtf.org>; Wed, 27 Feb 2019 02:35:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551263706; x=1553855706; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tQGq4UOB5yyVFGBKRof+TIc7QdiOUPYGTAsSTjTE/bM=; b=YiZ5kYsfWMuw4fc8eNaJ2dcl87HCeiqU96ph2VCoKH1z3RZRPUTmgScS0I6fR+bF CP5VMGpuvArRfIeqo6vXJ3Hyug1ZB3WD208n7rW24jDEEt19k5GYsfbOQ4IexbfL +V0KaqJhAi452/0Abjr0kHSmu+wJVt+J4cRKrnQvgnU=;
X-AuditID: c1b4fb3a-5c9c29e00000672c-00-5c7667da59c4
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.B4.26412.AD7667C5; Wed, 27 Feb 2019 11:35:06 +0100 (CET)
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 27 Feb 2019 11:34:58 +0100
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 27 Feb 2019 11:34:57 +0100
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=tQGq4UOB5yyVFGBKRof+TIc7QdiOUPYGTAsSTjTE/bM=; b=WAZQ0/EMC6U6yvxtSzSBrh1Z60lbDWRQJuDD2yFnSj85amhOzb2CpGFfGI31wAiDZAGINMPZ9kn18PPV5IoFvy1/hthDxbRVykTYDNMoNkpKa/wjSzf0Znu5/oXuivTct1Snh++q3cIF6k8maum8Etrxaz2+3/vl5xTyAkiZXkM=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4329.eurprd07.prod.outlook.com (20.176.167.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.13; Wed, 27 Feb 2019 10:34:57 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc%5]) with mapi id 15.20.1665.012; Wed, 27 Feb 2019 10:34:57 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Russ Housley <housley@vigilsec.com>, IRTF CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Crypto-panel review of draft-selander-ace-cose-ecdhe-12
Thread-Index: AQHUzib+QC4KN/j0RkOLm525AK7wK6XzhJ8A
Date: Wed, 27 Feb 2019 10:34:57 +0000
Message-ID: <9EBFB09A-8A88-4D69-8662-355BB79895D7@ericsson.com>
References: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com> <57C131DC-1DDD-4F23-A9E8-FA822874465D@vigilsec.com>
In-Reply-To: <57C131DC-1DDD-4F23-A9E8-FA822874465D@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.0.190211
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2bc47905-fbf5-4f13-76e2-08d69c9f37fe
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4329;
x-ms-traffictypediagnostic: HE1PR07MB4329:
x-ms-exchange-purlcount: 4
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0MzI5OzIzOmh5NHUyNGt1QlRGR3ZlVml3WFUyTTBCNEJx?= =?utf-8?B?U1Bhb0dvaUVKUjY4S1IrY0RibE9ENjVOVTllNlVzUUx4eUhFSWVydHhyaDN3?= =?utf-8?B?MTRPRGF4dFJNZ2UxQUJpZ0VmYnc5ZVMxazJFUFJyblB3MVpZVGwwUG9qb3Y3?= =?utf-8?B?d2JYM2hkbEQvYWNwUGVESFVUZlVESG40RUd4c2RVM2lrdEpLL2k4WklUREFG?= =?utf-8?B?Uk1Help5OUJ1Y3NtcWN5MGlJd29XOGpydnYwWjQxSVhJWXdFcWRCQm44UHNh?= =?utf-8?B?a0lnTGxhZ08wV3ZxNWF1WDFBS213M3NDRVFhTitIVmt0WGF6Nkt6QjlyZjl0?= =?utf-8?B?UWtIeUR0QmoxRFp4U0EydkFuTVBHSHpBTGZWekU5cnY0d0xib2NOMzBKRTVa?= =?utf-8?B?Wit3bDYwYjZYQWNrNHFVblVaWXB3OU9ybXdPWWtsSnl3bHVQaDc1elF1eGlQ?= =?utf-8?B?aVlYNVdKY2lRVmpJM1pKKzF4ZngzS1c1b2RMWkJRYUhVNnZyaUFoQW5iK29w?= =?utf-8?B?UkNJbHRqQU1ybnBwbXZ5Q2lSa1ljNFhUNEoyYUVZdThyQTltN1Y3V1BDVWhL?= =?utf-8?B?WjNrdnpBbXROV2tJc0QxZEx3WndyOEthT21sTnhFUDd3aVErTkJHb3RnQ1Rz?= =?utf-8?B?dTNFelRaNVM0ajNZMmgxejhWWWc3Vmdtazk0SmxsMGN6VEhYUG9FYUV5ek9s?= =?utf-8?B?OXVwWWZNSUJ2eGRZNDdlNlNYY2NHWWk2MVpWOWNkUGR4VnFCY3RkbFFObC9w?= =?utf-8?B?b3h3SWpNS2U5R1BwNCs0eW9PdkRLeGYwQk9lOFRMMFFqbTQ5T1R2WFFha3E1?= =?utf-8?B?WldiSjJ6NGx2UG5BOStZR0NFTDFXWklPT2krUkQzVlQrY2hwUEt2NmJydDdM?= =?utf-8?B?eWZBbDEwK2VFMUdIRGNmd1lxc0FNUkJSUEFMUjRGUDlSWFFXL2dRcS92T2Nl?= =?utf-8?B?OG1yRVF4VGFLalJPZ2U2WkFkMzA2cGVxYzVVWXJpTi9xUlR2SDJUL2RuTG9M?= =?utf-8?B?MUVpQzVWZ1VIeDZidUZBck9rSE8xWW9yclg0Rk55TXRPWnJmbXJKT2hnb3Ew?= =?utf-8?B?aGl6NHF1c3FSRi9SSjdvb2hZYzdLYXVCaHlvMzB1ZnVkcDVGU1hOS2ZLblpV?= =?utf-8?B?Zkp6YUYwWVdMTElYY3FaMDZNUVFNR2cwS1Mvc1lxODZGRXRJaWRGS1Rpam41?= =?utf-8?B?NWh6MVRzTTJiRHZXdWEwV1NTOTYySG55bHJHUFluRDVFMTRObUl2Q2dCOHhL?= =?utf-8?B?eFprV2l6VjAvSWZYOXdIM3ljY2R2bW4yY2F5WjF0S2xTVm9ZNHRwNUtUOHlQ?= =?utf-8?B?cUhrbytzaVoyZkFvc3ovR2NuSmNTdlFNaHFBSjBORnV1aGNpU0FQRFFJVTNh?= =?utf-8?B?QWpiSVYyM3cxbGo2OEp0ZUFFdmJST3dRYklXcFlkY3oxVXRtWXRBS2VNakdR?= =?utf-8?B?czFnSUY5WTdhZHQzQllrYUU4UW9xalo2RWZycTR2UkhvWXVqNndqL0JMcFdN?= =?utf-8?B?Z2FPSHcvK1liWEhRVnZxcHN0bnNIZFdrYXd4Szc0SHVNbGM3WVBMRElEVG8w?= =?utf-8?B?ZTNjS2NPSk50d2Z4a2xvbnB0SXMrM2hmamVTeG9SL0FDb0hMcjNUUHdMMkpR?= =?utf-8?B?ZVgxd2FESjVqZXkxUzIzQXNZdHU3d25jNGhXK1VsUExtSFBTb0Z0YjFLdHBH?= =?utf-8?B?WGUwS2RSMU44V0pGN3hWWDNLSDhpS3pPRzlCTmx3Z3JISmxhMDEzcGlIN3Bo?= =?utf-8?B?REJFZkJPSmgxMFZPZDczMWJsemFiQkx5Y1RqaVY2S25zMnJxSlV1R3FlcEtK?= =?utf-8?B?UzdQNGtLdlpvak5SYVMySjV6bHhjVkhyRXNXZ3h2ZGJTc2dUak5rR20wMEpZ?= =?utf-8?Q?ATVHJkMrHXk=3D?=
x-microsoft-antispam-prvs: <HE1PR07MB4329C6A0112B13F5A925107E89740@HE1PR07MB4329.eurprd07.prod.outlook.com>
x-forefront-prvs: 0961DF5286
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(346002)(136003)(39860400002)(13464003)(51914003)(199004)(189003)(66066001)(58126008)(33656002)(966005)(110136005)(71200400001)(71190400001)(6306002)(82746002)(53546011)(97736004)(102836004)(8936002)(83716004)(478600001)(5660300002)(99286004)(6506007)(53936002)(2906002)(6512007)(6346003)(86362001)(316002)(6436002)(76176011)(68736007)(11346002)(2616005)(476003)(486006)(7736002)(44832011)(305945005)(36756003)(186003)(229853002)(81166006)(8676002)(6116002)(6486002)(81156014)(446003)(3846002)(256004)(14444005)(6246003)(25786009)(106356001)(105586002)(14454004)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4329; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DnOgcM8WnMkujiVG/yBu/kFyBrRiDNYHKwuur5kUI8/lSme5bLb7JPZ6j/w8Z+pz03572p7T0i6P8ijji6gU6uFl9fXOgl+XF7jbufg5jk7pKQ9nBx0R0Bjl6ZwIlTi78NLd5Y0BRp6Se9z90p4zafKA0Ea+6iX0UU6k3ZU4m5lGeXEP+0T5JKA1Lo9tUhe/mFMNTZLSklXqF3hTRpY4ViIlb0+4BlUk1wSzF8/ASbNanu1UOM42sMYmzFcbSCIEUmrNXtl8yo2BB7bVxa/asvDDeYk3P9lugTCkMYb/9IcIUmfGHwNcve1xwQondVJYP0nIzZGhdt6z01mJxMplvUQ1prAcNDqzMX70iIzwTqlRm2HJuaoZ9odloghKqGArv2gLHxFCd/f8Bcf3N3iWp1VgQkxAq8xoZoOlcDAfrqc=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5CE4BC9DE8A7F44EA4CF08CC86A8DD08@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bc47905-fbf5-4f13-76e2-08d69c9f37fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 10:34:57.1409 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4329
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUyM2J7ue6t9LIYg29HdS26fxxksnj14ia7 A5PH5I2H2TxW3fnCGsAUxWWTkpqTWZZapG+XwJXRfaORseBNSMW13a/ZGhivBHUxcnJICJhI LL97nLWLkYtDSOAIo8T0p2+hnG+MEot6+5ggnCVMEp2zdzKDOCwCE5glut+8giqbzCTR9KKV DcJ5xCjx/VwbK8hkNgEDibl7GthAbBEBJ4lfP08ygtjCAt4StyctY4aI+0i0zGyGqjGSOHHk FjuIzSKgKtF+8BOYzStgL7HgwSywGiGBIok5By+AzecUcJD4+Gcx2ExGATGJ76fWMIHYzALi EreezGeC+E5AYsme88wQtqjEy8f/wHpFBfQl1j9ZA1WjIPHn0iM2CFtW4tL8bkYI21di2/19 UPGbjBKzX2VB2FoSMye1skLYUhLvbqxjAXleQuCikMTUDTuhGrIlnv87BrSYA8iWkfjQrwpR 080mcefyWyaIZ1Illq9tZZzAqD8Lyd2zgFqYBTQl1u+CCntIdLw9xQJhK0pM6X7IPgscLIIS J2c+YVnAyLqKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzChHNzy22oH48HnjocYBTgYlXh4 H8SUxQixJpYVV+YeYpTgYFYS4dVPAArxpiRWVqUW5ccXleakFh9ilOZgURLn/SMkGCMkkJ5Y kpqdmlqQWgSTZeLglGpgjHj1uH7J5FJdHl3FhLjPT73y/2yKvCAkWx4+6eDNkt6QBywT31TO 4JX/+OlWB4fVrkS1HbmdIrOnTpi17LeFVOeiGB2tTwkMxa5JyXuexGrfzqu/eP6s+u9/x50X XzdwapmvcnzuysPGq1dKtwQYhX271Z90ck3zV16jItbfav8XSokqZOjkK7EUZyQaajEXFScC AJ+Q4F4kAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/1JX0lZd6AtP7pfHrPaxPzWuyQAk>
Subject: Re: [Cfrg] Crypto-panel review of draft-selander-ace-cose-ecdhe-12
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 10:35:12 -0000

Thanks for the review Russ!

Some comments inline

Cheers,
John

-----Original Message-----
From: Cfrg <cfrg-bounces@irtf.org> on behalf of Russ Housley <housley@vigilsec.com>
Date: Tuesday, 26 February 2019 at 23:59
To: IRTF CFRG <cfrg@irtf.org>
Subject: [Cfrg] Crypto-panel review of draft-selander-ace-cose-ecdhe-12

Document: draft-selander-ace-cose-ecdhe-12
Reviewer: Russ Housley
Review Date: 2019-02-26


>The CFRG Chairs asked the Crypto Panel to review this document.
>I am providing one review.  There may be others.
>
>
>Summary:
>
>The protocol seems to be as advertised, but the security considerations
>need to be expanded as described below.  In addition, I raise a concern
>about the connection identifiers, but I do not think that is hard to
>address.
>
>I did not look at the formal analysis in [1].  It is behind a paywall.
>
>I did not review the appendices.
>
>[1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf

The document is also freely available on one of the authors webpages, but I do not know if it is the exact same version.

https://alessandrobruni.name/papers/18-edhoc.pdf


>Major Concerns:
>
>I do not think the protocol provides mutual authentication when more
>than one party knows the signature private key.  This applies to both
>the raw public keys (RPK) and public key certificates.  I expected to
>see the protection requirements for the private key in Section 4.  I
>also expected the consequences for disclosure of the private key be
>discussed in Section 9.
>
>I do not think the protocol provides mutual authentication when
>symmetric keys are used for authentication unless the PSK is only known
>to the two parties involved in the protocol.  I expected to see the need
>for a pairwise PSK to be highlighted in Section 5.  I also expected the
>consequences for using a group PSK to be discussed in Section 9.

The protocol clearly do not provide mutual authentication when more than one party knows the private keys or PSK. I agree that this could be written out in Section 4 and 5 and that the consequences of disclosure should be discussed in Section 9. We will add that in the next version.


>Section 4.3.1 says:
>
>   C_U : bstr / nil,
>
>And then, Sections 4.3.3 says:
>
>   Retrieve the protocol state using the connection identifier C_U
>
>It seems odd to have the complexity of two options here.  I think it
>would be better to always send C_U or never send it.  Section 4.3.3
>needs to say how to process Message 2 if C_U is omitted.  Given the
>flexibility claimed in the Introduction, I am assuming that a
>connection-oriented transport is not required.  If this protocol is
>on top of a connectionless transport, I think C_U is required.
>
>Section 4.4.1 says:
>
>   C_V : bstr / nil,
>   
>And then, Sections 4.4.3 says:
>
>   Retrieve the protocol state using the connection identifier C_V
>
>I have the same comments as above regarding C_U.

Good points. 

- The stated flexibility has been tuned done in version 12, and it has been made clearer that the main focus is transport over CoAP. We do not want to forbid any other transports but we do not want to spend too much time specifying it either.

- I see now that the description of a null connection identifier is missing for one side. E.g. for message two it is stated that

"To reduce message overhead, party V can set the message field C_U in message_2 to null (still storing the actual value of C_U) if there is an external correlation mechanism (e.g. the Token in CoAP) that enables Party U to correlate message_1 and message_2."

Any guidance for Party U is missing, and vice verse for message_3. This needs to be added if the optimization is kept.

- It can be discussed if the added complexity of having two options are worth the savings. Assuming CoAP is used for transport and 1 byte connection identifiers are used (which allows a node to have 256 connections), the added complexity only saves a single byte. On the other hand, there are not many spare bytes if you want to fit EDHOC into three single 51 byte LoRaWAN frames.


>Minor Concerns:
>
>Section 2 includes Figure 1.  Next, it explains the elements used in the
>figure, which includes AEAD.  Next, it lists the things that need to be
>added to get a "full-fledged" protocol, which again includes AEAD.  AEAD
>should be removed from the second list.
>
>Section 3.2 says "... but only a subset of the parameters is included in
>the EDHOC messages."  Please list the subset or provide a pointer to the
>place where that can be found.
>
>Section 3.3 says:
>
>   For message_i the key, called K_i, SHALL be derived using other =
>   aad_i, where i = 2 or 3.
>
>Since there are only two cases, it would be clearer to say:
>
>   For message_2 and message_3, the keys SHALL be derived using other
>   set to aad_2 and aad_3, respectively.

Good suggestions, we'll change according to your suggestions.

>In addition, it would help the reader to provide a forward pointer to
>the sections define the aad_2 and aad_3 structures.

That was added to Section 3.3. in versrion 12: "where aad_2 and aad_3 are hashes of previous messages and data, defined in Sections 4.3.1 and 4.4.1." Is there any other place that would benefit from a pointers?

>The paragraph that follows talks about the IV_i.  Again, I think this
>simpler language would help the reader.
>
>Section 4.1, please avoid "for x = U or V" the first time it is used.
>I suggest: "where ID_CRED_U and ID_CRED_V are encoded in a COSE map."

Good suggestions, we'll change according to your suggestions.

>Section 4.3.1 says:
>
>   C_U : bstr / nil,
>
>And then, Sections 4.3.3 says:
>
>   Retrieve the protocol state using the connection identifier C_U
>
>It seems odd to have the complexity of two options here.  I think it
>would be better to always send C_U or never send it.  Section 4.3.3
>needs to say how to process message_2 if C_U is omitted.  Given the
>flexibility claimed in the Introduction, I am assuming that a
>connection-oriented protocol is not required.
>
>
>Nits:
>
>The point that EDHOC makes use of CBOR, CoAP, and COSE is repeated too
>many times.
>
>Both "perfect forward secrecy" and "perfect-forward secrecy" are used.
>Please pick one and use it everywhere.  I prefer the first spelling.
>
>Section 1: it seems better to end the first sentence as, "... or where
>the protection needs to work over a variety of underlying protocols."
>
>Section 1.1: s/systems often deals with/systems often deal with/
>
>Section 1.2: s/(CDDL) to express CBOR/(CDDL) is used to express CBOR/
>
>Section 7.1: s/It is recommended is to/It is recommended to/
>
>Section 9.2: s/provide aliveness/provide liveness/

Thanks for the nits, we will fix them.

>Prediction:
>
>The mandatory-to-implement algorithm will probably get debated if this
>document is adopted into a working group.

Yes, and any such discussion is welcome. Curve25519 and EdDSA have clear benefits when it comes to processing, but are clearly less supported by hardware and libraries. EdDSA also mandates SHA-512 while many IoT devices support only SHA-256. In EDHOC the choice between ECDH algorithms does not affect the message sizes, but if EDHOC is used with COSE x5chain or x5bag it would make a difference. The choice should likely be coordinated with Group OSCORE 

https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm

While EDHOC cannot be used to key the group communication in Group OSCORE, devices would likely implement both Group OSCORE and EDHOC, and EDHOC could be used to key the OSCORE connection between a single endpoint and the group manager in Group OSCORE.

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg