Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

Marco Tiloca <marco.tiloca@ri.se> Fri, 28 October 2022 18:06 UTC

Return-Path: <marco.tiloca@ri.se>
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 B8627C14CF02 for <lake@ietfa.amsl.com>; Fri, 28 Oct 2022 11:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.007
X-Spam-Level:
X-Spam-Status: No, score=-7.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ac4--z-d5clj for <lake@ietfa.amsl.com>; Fri, 28 Oct 2022 11:06:27 -0700 (PDT)
Received: from emea01-obe.outbound.protection.outlook.com (mail-swedencentralazlp170120004.outbound.protection.outlook.com [IPv6:2a01:111:f403:c202::4]) (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 E6E09C14F74B for <lake@ietf.org>; Fri, 28 Oct 2022 11:06:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gD47l12gaMBxwEK17RK0ZshVYTEjU7RgQn8loOYz549m0+tIBVTO2jsE5W0ymrb8ORlsGg2qbjMAmNSALIjvIQPcs7dK1iGoqoRordIapQ9TJHT5I2VrjnvfPSoBsH14+3+J1B3DsrWTaQw2oznKFE3xMaVQUgHtUJyUpy60BPPK8CDnqKE/k3njm+S9OhJelghE1yn8lXRfm7Q3E1PQzqqqgTl4lkU9a5cGEibI2OhphVbm+igW+Gh9PSH76Yks5zn0oMULHZtoCk+k/FDUujYeKiX5eOQ2bxuTyiEdNBAN0RgE55PAz54vhAunGafPipAQ9qzq8CYzS6BDFPAOPA==
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=Ab3WKeAfNhDcgrSnqMYQa9HVBmM08hQqAf+RfZgGviw=; b=NNb029mYiNzFbUbX9eOMV3tc5+/bvZ2COMNNKkkqdQCCEwOwMWtw/TDr+U8S5PZTTx9NYYxPnihMTN2+uoYDfaRrp81DmRj+4BzfIC8xlrKboZp1AjJ9Nlhzsz5r22kXHNhGFm0J3OYANX4UjU8fhgk2yKzZy8Xu//N1J0i/2QAdZnJ57kTE0mNdSLU0VdJIxX+ZvHpOwzW56iZbsXHM8gtoDo92vnlSXEqtSfSXxZOCxwh4sBhILu8BaNnTRLAiwNyf2nAa9OIZUvavw+9RdYQu1sBOw30++S1gzDOqeBPvHHPXoq/11gKrjSgOrXV8k89X5Mfw+ye7B3+imRDJNw==
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=Ab3WKeAfNhDcgrSnqMYQa9HVBmM08hQqAf+RfZgGviw=; b=HdnbNKPaqOyN5oT9bL9ShrW4/w3bk/HOOff8CYjCWuwruQvLSCPmsCr2ozow6kO1OfK7D6t3PqSDESlsL+E4vBvgNprRkfbRpIDEqCLrHRcGYqCT92W96d58TsCc42XUYMU4AlntqW6uRu4YFq5M2jVQBe8uVHDKK5WQYHnf1MU=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se;
Received: from GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:37::17) by MM0P280MB0197.SWEP280.PROD.OUTLOOK.COM (2603:10a6:190:c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.28; Fri, 28 Oct 2022 18:06:20 +0000
Received: from GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM ([fe80::3608:eefa:dfb7:78ca]) by GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM ([fe80::3608:eefa:dfb7:78ca%8]) with mapi id 15.20.5769.014; Fri, 28 Oct 2022 18:06:20 +0000
Message-ID: <7a0088ce-db7a-7602-df77-29bd4bd16f6a@ri.se>
Date: Fri, 28 Oct 2022 20:06:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-US
To: Mališa Vučinić <malisa.vucinic@inria.fr>, lake@ietf.org
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
From: Marco Tiloca <marco.tiloca@ri.se>
In-Reply-To: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------w5QuY6iQbmGgCSA1uTNygThm"
X-ClientProxiedBy: FR3P281CA0103.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a1::19) To GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM (2603:10a6:150:37::17)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: GVYP280MB0464:EE_|MM0P280MB0197:EE_
X-MS-Office365-Filtering-Correlation-Id: c534188b-126e-4743-6613-08dab90f1dcd
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Ml5QOW6ElAeJaCh2Jen749z5k0vLSPE/GzZx3dg3JssYDZoH5dJLrgDTX8WcY8YvOtuquT53/V7L3Um9wJcUR/G/TxVqkCHR3eRJX2H4mr2N4lIMI2AMvJ4RXQnn1dgZIFNSTVBgY6NBizoY3ugzXU4rS9Skioz6R+bP9BE0K8GfkrWi32Z6MsW8aVbpjD6Bjr+stR2scCDrcDdIP9UV9Dc5Nu7Vp0sliUVPJpG3CezkWy+HTa0FNaRCCrDjFefiAipx07JctO3eOG/sSGu1a0Qb98pyjQQjWHEf6zIWw3yGic5WCUK5m6irwls3MYuCtXmmvUabXhLBzBnjpqplfLzkg0LQW/iOlKGbf4NmjW1qZEjC2FAGrQ7WgF9Qtn4DH9sTVaBJHEG5JeK0aicbNQ5lVK9gMeC8F6HvoqH+PKBVOyKJdPYvvzZUgCdPQgfl/JMHmY/xkio6cTvzZQinSym4o3Z/aBdqvw+t+xVLG/XgdlgCB3gc1aEA/74a3QsXgZnh473ATX8mjWz8wJ6TQ9KKQTTeDt1bOkBjkHivqaMpACWQCWMPK5zBXx0OMJ0X9SBKfJG1DI4ANvxlW7RARELgvwWqZIKxT/4xEALypAR0lD59uuxkqxXBR7r9Cfi4gY8A5h1xirI6C7+VBXFCti4EI3JeaFBxyE4l1TsyEpA6F39yb0/f3lJcde8ruSlg7+qZKRhgjWMq9I0Mp0Q6WUDZnAl0OvW6Y0BwOb9l6ybz+6a1lXrCptxVVHjUpAkx6wcahBbXYiK0ujkyKiyMBjTPnWnVT/IeOH4248j1WkpsKyfoqgoCCbzo5y1IkkSY
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(4636009)(136003)(376002)(346002)(396003)(39860400002)(366004)(451199015)(45080400002)(316002)(31696002)(30864003)(44832011)(4001150100001)(2906002)(31686004)(86362001)(66946007)(235185007)(66476007)(66556008)(8936002)(5660300002)(166002)(38100700002)(966005)(186003)(6486002)(478600001)(26005)(6512007)(2616005)(21480400003)(66574015)(83380400001)(36756003)(41300700001)(53546011)(6506007)(33964004)(45980500001)(43740500002)(579004); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: aS7IXAJiDtwzeelqxQgei2DZyHymvIce078Mw/4ok7iE2FQFNW+s0ulkbTwF978NsrZ3jsmrt+OF7apuMfUShfCp82Djt37eB0cJj0Ae5G4M+NIQ1lLn9G/KuHqdR31dEUI0ghdkLd8RTShSjzMXtVXWt83PX3D17SJbJcFkQW50VnQlw5aF2S6/LzUHiYtZxcSXL/MGV5DYCmLZgCtwZ31RV8CV+2K2IzG9SRrovgVyurF1hruyY9qkmxMYDC4w2FkT9koAaKaGHoE0PBtFLFVPwu71D2hWOwY/aHIjLMieaxVBR+nbb2rAg4Vxrew++ovMHdZO/eLyBUM3wZXNOosm1TJ0HEsT6IKYgwfKMQjnkPyyTNwv2TbbgX4EFVTuxsZbNMiXz7BmpxHact8kKclk2/PJcPVAX1IZnP0u1w7SvmUit4o/JaALMSMxCbyXTTnVnaxNudCZCxtbeHLtu3cR9emzYrZgGLulzwlok9El8TYk5wX0f9zb26gAY7Na4/TpSHSHQD+hgH40AYbNJdHfCv+uLmmYZLsqfawMkJbllBxZIpYzVQvisJLHUKq6n4NDtKvZPGvPmzvNxDztywRJe5XtGZy1+iQWDhzVOP1F1Pv5xeVtXDu1ZEqHl8zSwbDcIZwI38qtLQAvtRBgB4iCvKLNA+JWq9+drdJZ0n2FtAiWkLJ8SAfKITCwC+0Zh/wI1nMQyLRF28r35RdUZgFWYmpQYPMJ+6MqNz9fpdEyJ3Xbsj1IFxtD0lEzcmLamvoLcAV30kQ80k0zf7TKe1V1+wHt5QVAb3nDlvo0jER2Tj3Kw+qykZNvoCjEH2NeEcYPxPp39a1DFRbVE8/97fOdXYAdlrtWsValieTpVbJgAT5j6T0H5gII+C39iCUTU2adxbdxJJkyvmK4+MXPIqYOid2lPc1uxWfYKUEWYrlxfNYkgdbyOntjwAwmo5G1rc+bGNE9OZZ5lfTq2wlibDHFpgDKtrdS6q5tsYRFtL2xykZD3hNiDFIM/YRWSVi3+GRTLYIuu0Btrpr9I+Kkel5qe1Vb9B6ls/GQnqQDLjXcye5Uv48LIE6RM4lSgWS7SxwqakMc3CPjz1U0XW3BDJ9afBpwmgeVtgu6ETXjkDicrQ4b15gNSLGNdsuKxF56GXUF/sZUR0yE2zwIWaKQ3/0jdkQjOK/ZCbbEX8R0qXMAvGB6Wk0DF6JPjOG58NmepjptktmbEyp9YxDgacS7Y44fmFab8Ec5DsRfRXl7Fp1k2u4Tp7HiUi4K72JQRWHSQKSe7sz8QQQGUcl9RwfK0J05q/DEbT5eykjae4by+1COJnYx4qfmoyeOaO2dl3q7TlrPzk13iA4LVcmOLIsHhou5hhzlXmfhtDCGOnP/BACW8b00jq9c03WvWkPAUQVGbvZCPZZ4pwZ3CbyjH3/280JFxn5kXbTQzevGZXW8b2mgsRBCSe5j+j2V4W4Dz63UJqxJtq32AqzVRVuqjCAe+d9rOzw4KRJMDacI5oX98HuyD7Zn+sgzMmVurWDEw6iOuAzoKMxVokVY40oB39P60wKzunJfITJpQa/dM1z29sH63jkNdBdxUwEmHRMiDABg
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: c534188b-126e-4743-6613-08dab90f1dcd
X-MS-Exchange-CrossTenant-AuthSource: GVYP280MB0464.SWEP280.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2022 18:06:20.3713 (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: LKH2rnzoYVou0PSKflmH0rja0EBf+aWOOdpi9qTwnfgeb51coSLOk+ZcOyoFi5Y7mr8KPNlUOEHaWun3weiwRA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MM0P280MB0197
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/zbGxtirpWllLDtXkAUwfdNQOrSo>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 28 Oct 2022 18:06:34 -0000

Hi all,

I think that this document is in a very good shape!

Please see below some detailed comments.

Best,
/Marco


[Section 2]

* "... using keys derived from the shared secret."

    This should be the ECDH shared secret derived from G_X and G_Y. It 
has not been introduced before, and it appears a little later for the 
first time. Hence, here it can be confused with the "shared secret key 
PRK_out" mentioned before, in the first paragraph after Figure 2.


[Section 3.3]

* s/certain byte string identifiers/certain identifiers


[Section 3.3.2]

* A lot of text in this section takes CBOR byte strings as a starting 
point. However, as mentioned in Section 3.3.0, "Connection identifiers 
in EDHOC are intrinsically byte strings."

    I read this as "raw byte strings", rather than "CBOR byte strings". 
One may still choose to generate and store the identifiers precisely as 
CBOR byte strings, but they are still raw byte strings at their core.

    Then, I think the following editorial changes would make the text in 
this section simpler and less prone to confusion.

    - Remove the sentence: "This correspondence between integers and 
byte strings is a natural mapping between the byte strings with CBOR 
diagnostic notation h'00', h'01', ..., h'37' (except h'18', h'19', ..., 
h'1F') and integers which are CBOR encoded as one byte."

    - s/are encoded as normal CBOR byte strings/are simply encoded as 
CBOR byte strings

    - The text "h'21' is represented by 0x21 (CBOR encoding of the 
integer -2), not by 0x4121." becomes: "0x21 is represented by 0x21 (CBOR 
encoding of the integer -2), not by the CBOR encoding 0x4121."

    - The text "h'0D' is represented by 0x0D (CBOR encoding of the 
integer 13), not by 0x410D." becomes: "0x0D is represented by 0x0D (CBOR 
encoding of the integer 13), not by the CBOR encoding 0x410D."

    - The text "h'18' is represented by 0x4118." becomes: "0x18 is 
represented by 0x4118 (CBOR encoding of the byte string 0x18)."

    - The text "h'38' is represented by 0x4138." becomes: "0x38 is 
represented by 0x4138 (CBOR encoding of the byte string 0x38)."

    - The text "h'ABCD' is represented by 0x42ABCD." becomes: "0xABCD is 
represented by 0x42ABCD (CBOR encoding of the byte string 0xABCD)."

    - The text "A byte string which parses as a CBOR int in the range 
-24,..., 23 is just copied directly into the message" becomes: "A byte 
string which parses as the 1-byte CBOR encoding of an integer in the 
range -24, ..., 23 is just copied directly into the message".

    - The text "produces a byte string or an integer depending on its 
value." becomes: "produces a CBOR byte string or a CBOR integer 
depending on the value of the byte string identifier."


[Section 3.4]

* s/fragmentation/fragmentation and reassembly


[Section 3.5.1]

* "The authentication key algorithm needs to be compatible with the 
method and the cipher suite"

    This should be specifically the selected cipher suite, right?


[Section 3.5.2]

* s/on a specific encoding of the credential/on the specific encoding of 
the credentials

* "When the authentication credential is a COSE_Key in a CWT, CRED_x 
SHALL be the untagged CWT."

    This should be: "When the authentication credential is a CWT 
including a COSE_Key, then CRED_x SHALL be the untagged CWT."

* "When the authentication credential is a COSE_Key but not in a CWT, 
CRED_x SHALL be an untagged CCS."

    This should be: "When the authentication credential includes a 
COSE_Key but it is not a CWT, then CRED_x SHALL be an untagged CCS."


[Section 3.5.3]

* s/the sender's credential/the message sender's credential

* "the integer representation of byte string identifiers in Section 
3.3.2 MUST be applied."

    I think it would be clearer to say: "the same representation used 
for EDHOC connection identifiers and defined in Section 3.3.2 MUST be 
applied."


[Section 3.6]

* s/The MAC length MUST be/The EDHOC MAC length MUST be

* s/independently of the cipher suite/independently of the selected 
cipher suite

* "Note that AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with 
the IEEE CCM* mode."

    This should be: "Note that AES-CCM-16-64-128 and AES-CCM-16-128-128 
are compatible with the IEEE CCM* mode."


[Section 3.8]

* "If an endpoint receives a critical EAD item it does not recognize or 
a critical EAD item that contains information that it cannot process, 
the EDHOC protocol MUST be discontinued."

    Must an EDHOC error message also be sent before discontinuing the 
protocol?

    Is it something that must be specified by the 
application/specification that defines the EAD item and its processing 
when used as critical?

    See also later comments about Section 5.x on sending an EDHOC error 
message if any processing step fails.


[Section 3.9]

* "For some parameters, ... the receiver is able to verify compliance 
with the application profile"

    It's better to explicitly say "the receiver of an EDHOC message". 
Later on in the same section, it occurs again in "the receiver need to 
be able to determine ..."

* "Other conditions may be part of the application profile, such as 
target application or use (if there is more than one application/use) to 
the extent that EDHOC can distinguish between them."

    Proposed rephrasing: "Other conditions may be part of the 
application profile, such as the different target application or use (if 
there is more than one application/use), in which case EDHOC needs to be 
able to distinguish between them."

* "for example based on URI or external authorization data type."

    What URI? I guess this means the URI pointing to an EDHOC resource 
where an EDHOC message is sent. In that case, an application profile is 
associated with one or more EDHOC resources, identified by the 
corresponding URIs and targeted by the EDHOC messages sent to that node.


[Section 4.1.2]

* In the bullet list above Figure 7, the description of "key_length" and 
of "iv_length" should also conclude with "of the selected cipher suite", 
just like for "hash_length".


[Section 5.1]

Let's say that we have: the Initiator acting as CoAP client and not 
supporting EDHOC message_4; and the Responder that instead supports 
EDHOC message_4.

Eventually, the Initiator sends EDHOC message_3. Since the Initiator 
does not support EDHOC message_4, it moves to a protocol state where the 
only expected, next EDHOC message is an EDHOC error message.

Then, the Responder sends back EDHOC message_4 as a response. This is 
not wrong to do per se. In fact, an application profile can say that 
message_4 shall be sent, but it cannot really say that it shall not be 
sent. Besides, the Initiator might generally not be aware of the 
application profile.

This is actually only a specific example of something more general. That 
is, what should the Initiator do after having sent EDHOC message_3, if 
it receives as a reply something not expected as per its current 
protocol state?

This is still a processing failure (see second from last paragraph of 
Section 5.1). However, should the Initiator still send an EDHOC error 
message and thus discontinue EDHOC even in this case where the protocol 
is basically complete?

I believe the answer is "no, it should be fine with that, unless there 
is a very strong reason to do otherwise." In that spirit, I propose to 
extend the second from last paragraph of Section 5.1 with some text 
along these lines:

    "After having sent EDHOC message_3, the Initiator remains ready to 
possibly receive as following EDHOC messages: i) EDHOC message_4 or an 
EDHOC error message, if the Initiator supports EDHOC message_4; or ii) 
an EDHOC error message, if the Initiator does not support EDHOC message_4.

    If, after having sent EDHOC message_3, the Initiator receives an 
EDHOC message that does not match with what it expects or that results 
in a processing failure, then the Initiator SHOULD NOT send an EDHOC 
error message and SHOULD NOT discontinue the EDHOC protocol. An 
exception applies in case the Initiator supports EDHOC message_4 and is 
aware of the application profile that states that EDHOC message_4 shall 
be sent.

    After having sent EDHOC message_4, the Responder remains ready to 
possibly receive a following EDHOC error message. If, after having sent 
EDHOC message_4, the Responder receives an EDHOC message that does not 
match with what it expects or that results in a processing failure, then 
the Responder MUST NOT send an EDHOC error message and MUST NOT 
discontinue the EDHOC protocol."


[Section 5.2.3]

* "If any processing step fails, the Responder MUST send an EDHOC error 
message back ..."

    Does "processing" cover also the actual EAD processing, or only the 
act of making EAD_1 available to the application?


[Section 5.3.2]

* "The transcript hash TH_2 is a CBOR encoded bstr ..."

    Well, TH_2 as output of H() is simply raw bytes, i.e, not a CBOR 
item. Only later on is a CBOR-encoded TH_2 used, e.g., when building 
context_2.

    Then it should be ok to simply remove the quoted text.

* "Compute KEYSTREAM_2 as in ..."

    Here it's good to give a pointer to Appendix I "Long PLAINTEXT_2".

* "Verify Signature_or_MAC_2 using ..."

    It's worth mentioning that, after this step, the Initiator might 
have to get back to processing some EAD items from EAD_2, that were 
previously made available to the application but not (entirely) 
processed yet.

    This is the case, e.g., if their processing requires to first 
achieve proof-of-possession of the Responder's private key, which 
happens after having successfully verified Signature_or_MAC_2.

* "If any processing step fails, the Initiator MUST send an EDHOC error 
message back ..."

    Does "processing" cover also the actual EAD processing, or only the 
act of making EAD_2 available to the application?


[Section 5.4.2]

* "The transcript hash TH_3 is a CBOR encoded bstr ..."

    Like in a comment above, TH_3 as output of H() is simply raw bytes, 
i.e., not a CBOR item. Only later on is a CBOR-encoded TH_3 used, e.g., 
when building context_3.

    Then it should be ok to simply remove the quoted text.

* "The transcript hash TH_4 is a CBOR encoded bstr ..."

    Like in the comment above, TH_4 as output of H() is simply raw 
bytes, i.e, not a CBOR item. Only later on is a CBOR-encoded TH_4 used, 
e.g., as input to EDHOC-KDF.

    Then it should be ok to simply remove the quoted text.


[Section 5.4.3]

* "Verify Signature_or_MAC_3 using ..."

    It's worth mentioning that, after this step, the Responder might 
have to get back to processing some EAD items from EAD_3, that were 
previously made available to the application but not (entirely) 
processed yet.

    This is the case, e.g., if their processing requires to first 
achieve proof-of-possession of the Initiator's private key, which 
happens after having successfully verified Signature_or_MAC_3.

* "If any processing step fails, the Responder MUST send an EDHOC error 
message back ..."

    Does "processing" cover also the actual EAD processing, or only the 
act of making EAD_3 available to the application?


[Section 5.5.3]

* "If any processing step fails, the Initiator MUST send an EDHOC error 
message back ..."

    Does "processing" cover also the actual EAD processing, or only the 
act of making EAD_4 available to the application?


[Section 6.3]

* "ERR_INFO is in this case denoted SUITES_R"

    This should be, e.g., "In this case, ERR_INFO specifies SUITES_R"

* "SUITES_R MAY include a single cipher suite, i.e., be encoded as an int."

    This should be "SUITES_R MAY include a single cipher suite, in which 
case it is encoded as an int."

* "selects its most preferred and the Responder sends an error with 
supported cipher suites."

    This should be "selects its most preferred cipher suites and the 
Responder sends an error with its supported cipher suites."


[Section 8.1]

* "A single session of EDHOC does not include negotiation of cipher suites"

    Perhaps do you mean "a single exchange of two EDHOC messages" ?

* "... until the Initiator has verified an OSCORE message or message_4 
from the Responder.

    Like in Section 5.4.2, this should be: "... until the Initiator has 
verified message_4 or a message protected with a derived application 
key, such as an OSCORE message, from the Responder."


[Section 8.3]

* "... so that a sufficient security level is maintained for 
certificates, EDHOC, and the protection of application data."

    Does "certificates" actually mean "authentication credentials"? Does 
"EDHOC" actually mean "EDHOC executions" or "EDHOC messages"?


[Section 8.8]

* "Note that part of KEYSTREAM_2 is also non-secret randomness as it is 
known or predictable to an attacker."

    Proposed rephrasing: "Note that part of KEYSTREAM_2 does not enjoy 
non-secret randomness either, as it is known or predictable to an attacker."


[Section 9]

* Throughout the whole section:

    - s/group name/registry group

    - When mentioning a registration procedure, refer to RFC 8126 (to be 
added as normative reference).


[Section 9.7]

* You can remove "under the group name "Well-Known URIs"".


[Appendix A]

* s/when OSCORE is used with EDHOC/when EDHOC is used to key OSCORE


[Appendix A.2]

* "with response codes analogously to message_2"

    This should be: "with response codes analogous to those of the 
response to message_2".

* "In case of an error message in response to message_4, it is sent 
analogously to errors in response to message_2."

    This should be: "In case of an error message sent as reply to 
message_4, it is sent analogously to an error message sent as reply to 
message_2."

* s/See Figure 13/See Figure 13 for an example

* s/See Figure 14/See Figure 14 for an example

* s/to these messages/to the CoAP messages that transport an EDHOC 
message prepended by a connection identifier


[Appendix A.2.1]

* "When using EDHOC over CoAP for establishing an OSCORE Security 
Context, EDHOC error messages ..."

    The following text about error responses and response code applies 
also in case EDHOC is used for keying something different than OSCORE.

    Hence the sentence can be shortened as: "When using EDHOC over CoAP, 
EDHOC error messages ..."


[Appendix J]

* "The change of PRK_out causes a change to PRK_exporter and keys 
derived using EDHOC-Exporter."

    This refers specifically to EDHOC-KeyUpdate, which certainly causes 
a change to PRK_exporter, but not directly to existing keys previously 
derived using EDHOC-Exporter.

    I would expect that existing application keys derived from the old 
PRK_exporter remain unchanged, at least at the end of EDHOC-KeyUpdate.

    At the same time, the final goal of an application triggering 
EDHOC-KeyUpdate is practically to update application keys. So perhaps 
the quoted sentence can be rephrased to say that:

    i) the newly derived PRK_exporter is used from then on in order to 
derive new application keys with EDHOC-Exporter;

    and

    ii) current, existing application keys previously derived with 
EDHOC-Exporter can be re-derived using the new PRK_exporter. The newly 
derived applications keys supersede the old ones.  When to delete the 
old application keys and how to verify that they are not needed is up to 
the application.



[Nits]

* Section 1.1:
--- s/criteria/criterion
--- s/prohibitive/prohibitively large

* Section 2:
--- s/Like (D)TLS/Like in (D)TLS
--- s/the application, EDHOC/the application. EDHOC

* Section 3.2:
--- s/indicate protocol/indicate the protocol

* Section 3.3:
--- s/or in subsequent/or may be used in subsequent
--- s/CBOR ints/CBOR integers
--- s/associated to the/associated with the

* Section 3.3.2:
--- s/encoding: A byte/encoding: a byte
--- s/message, a byte string which doesn't/message; a byte string which 
does not
--- s/representation it can/representation, it can

* Section 3.3.3:
--- s/results in same/results in the same

* Section 3.4:
--- s/In addition to transport/In addition to the transport

* Section 3.5.1:
--- s/Note that for most signature/Note that, for most signature
--- s/keys are denoted I/keys are denoted as I

* Section 3.5.3:
--- s/within EDHOC, for example/within EDHOC. For example

* Section 3.6:
--- s/follows from COSE/follow from COSE

* Section 3.7:
--- s/In COSE compact/In COSE, compact

* Section 3.8:
--- s/registers their own/registers its own
--- s/non-critical, determined by/non-critical, as determined by

* Section 3.9:
--- s/because of wrong/because of a wrong
--- s/uses public/uses a public

* Section 4.1.2:
--- s/is used is specified/is used are specified

* Section 5.1
--- s/associated to an/associated with an

* Section 5.4.2:
--- s/for acknowledgement/for an acknowledgement

* Section 5.5:
--- s/of such deployments:/of such deployments are:

* Section 6:
--- s/Errors messages in EDHOC/Error messages in EDHOC
--- s/associated to the/associated with the

* Section 6.3.2:
--- s/so therefore selects/therefore it selects
--- s/The initiator prepends/The Initiator prepends

* Section 7
--- s/differ in size of/differ in the size of
--- s/is no essential difference/is of no essential difference

* Section 8.1
--- s/and send its own/and then sending its own
--- s/Either of these provide/Both of them provide
--- s/in the application protocol fail/in the application protocol fails

* Section 8.2
--- s/future EHDOC methods/future EDHOC methods

* Section 8.3
--- s/whole authentication credential/whole authentication credentials

* Section 8.5
--- s/update the connection identifier/update the connection identifiers

* Section 8.6
--- s/An passive attacker/A passive attacker

* Section 8.8
--- s/PNRG/PRNG  (2 occurrences)
--- s/to select its connection identifiers/to select the connection 
identifier
--- s/ongoing EDHOC protocol/ongoing EDHOC protocol execution
--- s/sets that will be/sets will be
--- s/do not make use/does not make use
--- s/hash, this/hash. This

* Section 9.11
--- s/Expert should consider/Experts should consider

* Appendix A.2.1
--- s/EDHOC and OSCORE protocols/the EDHOC and OSCORE protocols

* Appendix C
--- s/to simplify for implementors/to help implementors

* Appendix C.1
--- s/occurrance/occurrence

* Appendix D.2
--- s/associated to the/associated with the

* Appendix E
--- s/external authorization related data/related external authorization 
data

* Appendix F
--- s/with value empty/with value the empty

* Appendix G
--- s/acknowledgement on CoAP messaging layer/acknowledgement on the 
CoAP messaging layer
--- s/processing on CoAP messaging layer/processing on the CoAP 
messaging layer
--- s/differences which compromises/differences which compromise

* Appendix I
--- s/algorithm the length/algorithm, the length




On 2022-10-14 12:24, Mališa Vučinić wrote:
> Hi all,
>
> As discussed during the interim on 5 October 2022, this email triggers 
> the working group last call for the version 17 of the EDHOC draft, the 
> main item on the agenda of the LAKE working group.
>
> The draft can be found at: 
> https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/ 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lake-edhoc%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C36fc35a558794f391e3e08daadce48e7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638013398754135915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wjvDg0%2BASToZTxT0WlDtNLMLCV7I63fNGE3y3VwNcb0%3D&reserved=0>
>
> Please state your position and comments to the list by 4 November 2022 
> so we can discuss them during the IETF 115 meeting in London.
>
> Thanks,
> Mališa, for the chairs
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: +46 (0)70 60 46 501

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se