Thanks a lot for your review! Please find in line below our detailed replies to your comments.
A Github PR where we have addressed your comments is available at [PR].
Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews), and to submit the result as version -11 of the document.
Thanks,
/Marco
[PR] https://github.com/core-wg/oscore-edhoc/pull/22
On 2024-03-27 13:35, Emmanuel Baccelli
via Datatracker wrote:
Reviewer: Emmanuel Baccelli Review result: Ready with Nits Hello, I've been selected as the IoT Directorate for a review of this draft. The document is very clearly structured, and very well written. I have a few minor nits and optional suggestions, listed below. # Overall: What *might* add marginal value is a small subsection somewhere upfront, which summarizes crisply the applicability / limits of the EDHOC+OSCORE request which are for now scattered in the doc (second paragraph of section 3. and last paragraph of section 3.2.2., if I did not miss something).
==>MT
In Section 1 "Introduction", we have added the following text as new second-from-last paragraph.
> The minimum number of two round trips can be achieved only if the default, forward message flow of EDHOC is used, i.e., when a CoAP client acts as EDHOC Initiator and a CoAP server acts as EDHOC Responder. The performance advantage of using this optimization can be lost when used in combination with Block-wise transfers [RFC7959] that rely on specific parameter values and block sizes.
<==
# Section 1: "Without this optimization, it is not possible, not even in theory, to..." => Suggestion: just simplify to "Without this optimization, it is not possible to..."
==>MT
We have rephrased as follows.
OLD:
> Without this optimization, it is not possible, not even in theory, to achieve the minimum number of round trips. This optimization makes it possible also in practice, since ...
NEW:
> Without this optimization, it is not possible to achieve the minimum number of two round trips. This optimization makes it possible, since ...
<==
# Section 2: In Fig. 1 the caption ends by the mention "... without which that message needs no payload." => Suggestion: this mention is difficult to parse at first, and does not related obviously with the accompanying text. What about just removing this mention, or alternatively, rephrase?
==>MT
We have shortened the caption text as follows.
OLD:
> Figure 1: EDHOC and OSCORE run sequentially. The optional message_4 is included in this example, without which that message needs no payload.
NEW:
> Figure 1: EDHOC and OSCORE run sequentially. The optional message_4 is included in this example.
<==
# Section 6: "It would be convenient to ..." "It would be convenient that ..." => Suggestion: fells a little convoluted. Is there an opportunity to simplify the text here, and make it more direct like "In order to enable XYZ, we specify ABC"? "While a client may become aware of the application profile through several means..." => Suggestion: why not give an concrete example here.
==>MT
In Section 6 "Web Linking", the considered second and third paragraphs are intentionally giving background that is necessary to understand what the rest of the section specifies, which comes in the immediately following paragraph phrased exactly as "In order to enable XYZ, we specify ABC".
We have rephrased the second and third paragraphs as shown below. The next text is more assertive already when providing the background information. Also, it explicitly considers the discovery of EDHOC resources as an example of means to learn about EDHOC application profiles.
We believe that there is no need to extend this text to mention also alternative means, but just for information, some are defined in https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/ and https://datatracker.ietf.org/doc/draft-tiloca-lake-app-profiles/
OLD (emphasis mine):
> At the same time, the application profile associated with an EDHOC resource provides information describing how the EDHOC protocol can be used through that resource. **While a client may become aware of the application profile through several means, it would be convenient to obtain its information elements upon discovering the EDHOC resources at the server.** This might aim at discovering especially the EDHOC resources whose associated application profile denotes a way of using EDHOC which is most suitable to the client, e.g., with EDHOC cipher suites or authentication methods that the client also supports or prefers.
>
> That is, **it would be convenient that a client discovering an EDHOC resource contextually obtains relevant pieces of information from the application profile associated with that resource**. The resource discovery can occur by means of a direct interaction with the server, or instead by means of the CoRE Resource Directory [RFC9176], where the server may have registered the links to its resources.
NEW (emphasis mine):
> At the same time, the application profile associated with an EDHOC resource provides information describing how the EDHOC protocol can be used through that resource. **A client may become aware of the application profile, e.g., by obtaining its information elements upon discovering the EDHOC resources at the server. This allows the client to discover** especially the EDHOC resources whose associated application profile denotes a way of using EDHOC which is most suitable to the client, e.g., with EDHOC cipher suites or authentication methods that the client also supports or prefers.
>
> That is, **while discovering an EDHOC resource, a client can contextually obtain relevant pieces of information from the application profile associated with that resource**. The resource discovery can occur by means of a direct interaction with the server, or instead by means of the CoRE Resource Directory [RFC9176], where the server may have registered the links to its resources.
<==
# Section 7: "[...] a minimum of 128-bit security [...] is achieved" => Suggestion: A naive question that arises here is (caveat: I am not a cryptographer, as most readers aren't ;) does this 128-bit level hold post-quantum, as far as we can tell. If yes, mention that and maybe point to https://eur05.safelinks.protection.outlook.com/?url=""> ?
==>MT
Short answer: yes, it holds also for the post-quantum case, just as per Section 9.4 of RFC 9528.
In order to avoid (potentially confusing) restatements, we have simply added an explicit reference to that section as well. That is:
OLD (emphasis mine):
> When using the optimized workflow in Figure 2, a minimum of 128-bit security against online brute force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see **Section 9.1** of [I-D.ietf-lake-edhoc]).
NEW (emphasis mine):
> When using the optimized workflow in Figure 2, a minimum of 128-bit security against online brute force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see **Sections 9.1 and 9.4** of [RFC9528]).
<==
-- 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
Attachment:
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
