Re: [Last-Call] Iotdir telechat review of draft-ietf-core-oscore-edhoc-10

[Marco Tiloca <[e-mail]>]

Hello Emmanuel,

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=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9528%23name-post-quantum-considerations&data=05%7C02%7Cmarco.tiloca%40ri.se%7C2d6e5c9984784c258b7608dc4e5a6d08%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638471397482833516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=28GJ9TNhVSG6TSB4iG5LUqhtqiumo6Kw0CzD6In5g70%3D&reserved=0  ?
>

==>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: [phone]

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

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se