Re: [core] secdir review of draft-ietf-core-oscore-edhoc

[Marco Tiloca <[e-mail]>]

Hello Wes,

(adding also CoRE in CC)

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 
[SECDIR-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 -10 of the document.

Thanks,
/Marco

[SECDIR-PR] https://github.com/core-wg/oscore-edhoc/pull/18


On 2023-11-16 00:12, Wes Hardaker wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The summary of the review is: almost ready
>
> Note: this is an early review, per request
>
> In general, the document reads quiet well but I have a number of
> comments and suggestions below that may help if you choose to use them.
>
> Please note that I'm not an expert in CoAP and OSCORE and EDHOC, which
> makes anything I say questionable from the start :-)
>
> Questions/comments:
>
> - Section 2, P4: you might mention that the reverse is only usable in
>    the classic case.  I know you're describing the classic/generic case
>    here, but it would be helpful to pre-seed the reader that this mode
>    won't work with this draft.

==>MT

Section 2 is explicitly intended to be only an informative overview of 
the original use of EDHOC as-is, without mentioning any new contribution 
introduced by the present document.

Therefore, we believe that it would be premature to raise this point 
already in Section 2, and that Section 3 is the right place to do so, 
now in its second paragraph:

 > This approach can be used only if the default, forward message flow 
of EDHOC is used, i.e., when the client acts as Initiator and the server 
acts as Responder. That is, it cannot be used in the case with reversed 
roles as per the reverse message flow of EDHOC.

Please also note that the reverse flow as such actually does work with 
this draft.

That is, the reverse flow does not work together with the optimized 
workflow defined in Section 3. Except for that, it works and it is 
relevant to the other sections of the draft defining mechanisms for 
EDHOC used with CoAP and OSCORE.

<==

>
> - Section 2, P7: you state that the server replies with 2.04 (Changed)
>    -- is this *always* the case?  Aren't there cases where an error or
>    other response might occur?  (reminder: I'm not a CoAP expert)

==>MT

It is not always the case. If EDHOC error messages are sent by the CoAP 
server acting as a Responder, those are transported in the payload of 
CoAP error responses, according to what is defined in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-errors-in-edhoc-over-coap

Since the text describes a successful execution of EDHOC, and thus no 
error messages are sent in the considered example, we have rephrased as 
follows.

OLD
 > Figure 1 shows a CoAP client and a CoAP server running EDHOC as 
Initiator and Responder, respectively. In particular, it extends ...

NEW
 > Figure 1 shows a successful execution of EDHOC, with a CoAP client 
and a CoAP server running EDHOC as Initiator and Responder, 
respectively. In particular, Figure 1 extends ...

<==

>
> - Section 3, "Since EDHOC message_3 may be too large..." ... "EDHOC
>    message_3 has instead to be transported in tho CoAP payload... ".
>    It's unclear to me reading if this is *always* the case, or only if
>    it's too large do you do that.  [note for implementation simplicity:
>    doing it the same way either way requires less decisions to be made]

==>MT

Yes, it is always the case.

This approach does *not* propose two alternatives that one can choose 
from on a per message basis. That is, EDHOC message_3 is always 
transported in the payload of the CoAP request.

In order to avoid confusion and overall clarify where EDHOC C_R and 
EDHOC message_3 are transported, we have revised the bullet list 
introduced by "That is, the EDHOC + OSCORE request ..." to become as 
follows.

 > That is, the EDHOC + OSCORE request is composed of the following two 
parts combined together in a single CoAP message:
 >
 > * The OSCORE Request from Figure 1, which is also in this case sent 
to a protected resource, with the correct CoAP method and options 
intended for accessing that resource.
 >
 > * EDHOC data consisting of the pair (C_R, EDHOC message_3) required 
for completing the EDHOC session, transported as follows:
 >    * C_R is the OSCORE Sender ID of the client and hence transported 
in the 'kid' field of the OSCORE Option (see Section 6.1 of RFC 8613). 
Unlike in the sequential workflow shown in Figure 1, C_R is thus not 
transported in the payload of the EDHOC + OSCORE request.
 >    * EDHOC message_3 is transported in the payload of the EDHOC + 
OSCORE request, prepended to the payload of the OSCORE Request. This is 
because EDHOC message_3 may be too large to be included in a CoAP 
Option, e.g., when conveying a large public key certificate chain as 
ID_CRED_I (see Section 3.5.3 of [I-D.ietf-lake-edhoc]) or when conveying 
large External Authorization Data as EAD_3 (see Section 3.8 of 
[I-D.ietf-lake-edhoc]).

<==

>
> - I admit confusion after reading the whole thing about where C_R, kid
>    and the responder identifier comes from and when they're equal, etc
>    ("is both the server's Receiptient ID (IE.e the client's sender ID)
>    and the EDHOC Connection Identifier C_R of the server", but later "The
>    Responder MUST choose a C_R" seem in conflict).  I thought I
>    understood it at one point (and with another read I'm sure I'd get
>    more clarity), but it caused my secdir focused brain to think "well,
>    if the client specifies the value and the server has to use it to
>    distinguish between different clients, then what happens if 2 clients
>    end up deriving/using the same value?"  I think clarity about this,
>    maybe with a solid example, would help.  I was very happy to read
>    later in the security considerations that "Even if a client did not
>    fulfill this requirement, it would not have any impact in terms of
>    security.", but in the end without a better understanding I remain
>    skeptical (note: mostly that's my job as a reviewer here).

==>MT

We reply to this comment separately for each of its points.


*Point 1 - What C_R is for EDHOC and where it comes from*

As defined in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-connection-identifiers 
, C_R is the EDHOC connection identifier of the Responder and is chosen 
by the EDHOC Responder when composing its outgoing EDHOC message_2.

Both in the original EDHOC execution overviewed in Section 2 as well as 
in the optimized workflow introduced in Section 3:

* The CoAP server acting as EDHOC Responder chooses C_R as its own EDHOC 
identifier.

* The CoAP server provides the CoAP client with the chosen C_R, which is 
specified in EDHOC message_2, see 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-responder-composition-of-me 
. When doing so, C_R is encrypted, since it is part of PLAINTEXT_2 used 
to produce the ciphertext CIPHERTEXT_2, which is included in EDHOC 
message_2.

Without going into details that are already specified in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-responder-composition-of-me 
, Section 2 of the present document already reminds about this when saying:

 > This triggers the EDHOC execution at the server, which replies with a 
2.04 (Changed) response. The response payload consists of EDHOC 
message_2, which also includes the EDHOC connection identifier C_R of 
the server encoded as per Section 3.3 of [I-D.ietf-lake-edhoc].

We believe that the present document should not re-explain such details 
about C_R.


*Point 2 - What C_R is for OSCORE*

This is already defined in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-use-of-connection-identifie 
, which says:

 > For OSCORE, the choice of connection identifier results in the 
endpoint selecting its Recipient ID, ...

This is further discussed later in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-deriving-the-oscore-securit 
, which says:

 > The relationship between identifiers in OSCORE and EDHOC is specified 
in Section 3.3.3. The OSCORE Sender ID and Recipient ID SHALL be 
determined by the EDHOC connection identifiers C_R and C_I for the EDHOC 
session as shown in Figure 17.

That is, C_R is the OSCORE Recipient ID of the CoAP server. Therefore, 
as per OSCORE (RFC 8613), C_R is also the OSCORE Sender ID of the client.

We believe that the present document should not re-explain such details 
about C_R.

Yet, the use of EDHOC connection identifiers as OSCORE identifiers 
becomes relevant specifically when exchanging OSCORE-protected messages. 
Therefore, we have provided additional clarifications about that (see 
next point).

Please note that, Section 4.1 of the present document and its 
subsections provide additional guidance for the selection of the EDHOC 
Connection Identifiers at the two peers. This takes into account that 
such EDHOC Identifiers are going to be used as OSCORE identifiers, and 
thus have to comply with additional requirements set by RFC 8613.


*Point 3 - Where C_R is placed in the CoAP request from the CoAP client 
and including EDHOC message_3*

This depends on whether we are using the original EDHOC execution as in 
Section 2, or the optimized workflow as in Section 3.

In the former case (original EDHOC execution), the present document 
simply reminds what is defined in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-the-forward-message-flow 
as-is. Section 2 of the present document says:

 > Finally, the client sends a POST request to the same EDHOC resource 
used earlier when it sent EDHOC message_1. The request payload consists 
of the EDHOC connection identifier C_R encoded as per Section 3.3 of 
[I-D.ietf-lake-edhoc], concatenated with EDHOC message_3. The 
Content-Format of the request can be set to application/cid-edhoc+cbor-seq.

This is also shown in Figure 1, i.e.:

```
        | ----------------- EDHOC Request -----------------> |
        |   Header: 0.02 (POST)                              |
        |   Uri-Path: "/.well-known/edhoc"                   |
        |   Content-Format: application/cid-edhoc+cbor-seq   |
        |   Payload: C_R, EDHOC message_3                    |
```

In the latter case (optimized workflow), C_R is instead not included in 
the CoAP payload as prepended to EDHOC message_3.

In fact, since C_R is the OSCORE Sender ID of the CoAP client (see 
above), its value is already specified in the 'kid' field of the OSCORE 
option (see Section 5.0 and 6.1 of RFC 8613), in the request sent by the 
CoAP client and including also EDHOC message_3 in its payload.

The same will recur in any other OSCORE-protected request sent by the 
CoAP client.

This should become clearer through the same, revised bullet list in 
Section 3.0 introduced by "That is, the EDHOC + OSCORE request ..." also 
mentioned in the reply to the previous comment, i.e.:

 > That is, the EDHOC + OSCORE request is composed of the following two 
parts combined together in a single CoAP message:
 >
 > * The OSCORE Request from Figure 1, which is also in this case sent 
to a protected resource, with the correct CoAP method and options 
intended for accessing that resource.
 >
 > * EDHOC data consisting of the pair (C_R, EDHOC message_3) required 
for completing the EDHOC session, transported as follows:
 >    * C_R is the OSCORE Sender ID of the client and hence transported 
in the 'kid' field of the OSCORE Option (see Section 6.1 of RFC 8613). 
Unlike in the sequential workflow shown in Figure 1, C_R is thus not 
transported in the payload of the EDHOC + OSCORE request.
 >    * EDHOC message_3 is transported in the payload of the EDHOC + 
OSCORE request, prepended to the payload of the OSCORE Request. This is 
because EDHOC message_3 may be too large to be included in a CoAP 
Option, e.g., when conveying a large public key certificate chain as 
ID_CRED_I (see Section 3.5.3 of [I-D.ietf-lake-edhoc]) or when conveying 
large External Authorization Data as EAD_3 (see Section 3.8 of 
[I-D.ietf-lake-edhoc]).

In the same spirit and for consistency, also in Section 3.0 we have 
updated Figure 2 to show the inclusion of C_R in the CoAP OSCORE Option 
of the EDHOC + OSCORE request. That is:

OLD
```
        | -------------- EDHOC + OSCORE Request ------------> |
        |   Header: 0.02 (POST)                               |
        |   Payload: EDHOC message_3 + OSCORE-protected data  |

        ~snip

        | <--------------- OSCORE Response ------------------ |
        |                    Header: 2.04 (Changed)           |
        |                    Payload: OSCORE-protected data   |

```

NEW
```
        | -------------- EDHOC + OSCORE Request ------------> |
        |   Header: 0.02 (POST)                               |
        |   OSCORE: { ... ; kid: C_R }                        |
        |   Payload: EDHOC message_3 + OSCORE-protected data  |


        ~snip

        | <--------------- OSCORE Response ------------------ |
        |                    Header: 2.04 (Changed)           |
        |                    OSCORE: { ... }                  |
        |                    Payload: OSCORE-protected data   |
```

In Section 2, we have similarly updated Figure 1 to show the inclusion 
of C_R in the CoAP OSCORE Option of the OSCORE request. That is:

OLD
```
        | ---------------- OSCORE Request -----------------> |
        |   Header: 0.02 (POST)                              |
        |   Payload: OSCORE-protected data                   |

        ~ snip

        | <--------------- OSCORE Response ----------------- |
        |                 Header: 2.04 (Changed)             |
        |                 Payload: OSCORE-protected data     |
```

NEW
```
        | ---------------- OSCORE Request -----------------> |
        |   Header: 0.02 (POST)                              |
        |   OSCORE: { ... ; kid: C_R }                       |
        |   Payload: OSCORE-protected data                   |

        ~ snip

        | <--------------- OSCORE Response ----------------- |
        |                 Header: 2.04 (Changed)             |
        |                 OSCORE: { ... }                    |
        |                 Payload: OSCORE-protected data     |
```

Also in Section 2, we have extended the ninth paragraph as follows:

OLD
 > After this exchange takes place, and after successful verifications 
as specified in the EDHOC protocol, the client and server can derive an 
OSCORE Security Context, as defined in Appendix A.1 of 
[I-D.ietf-lake-edhoc]. After that, they can use OSCORE to protect their 
communications as per [RFC8613].

NEW
 > After this exchange takes place, and after successful verifications 
as specified in the EDHOC protocol, the client and server can derive an 
OSCORE Security Context, as defined in Appendix A.1 of 
[I-D.ietf-lake-edhoc]. After that, they can use OSCORE to protect their 
communications as per [RFC8613]. Note that the EDHOC Connection 
Identifier C_R is used as the OSCORE Sender ID of the client (see 
Appendix A.1 of [I-D.ietf-lake-edhoc]). Therefore, C_R is transported in 
the 'kid' field of the OSCORE Option of the OSCORE Request (see Section 
6.1 of RFC 8613).


*Point 4 - Security considerations*

Quoting the related part of the comment:

 >   I was very happy to read
 >   later in the security considerations that "Even if a client did not
 >   fulfill this requirement, it would not have any impact in terms of
 >   security.", but in the end without a better understanding I remain
 >   skeptical (note: mostly that's my job as a reviewer here).

The mentioned "requirement" actually refers to a different topic that is 
unrelated to EDHOC Connection identifiers and their possible collision 
(which is prevented by construction anyway, per the rules defined in 
Section 4).

As said in Section 7 "Security Considerations", the requirement in 
question is as follows:

 > Section 3.2 specifies that a client SHOULD NOT have multiple 
outstanding EDHOC + OSCORE requests pertaining to the same EDHOC session.

As discussed in the security considerations, the absence of security 
impact is due to the lockstep EDHOC processing as-is, and to the OSCORE 
processing of OSCORE-protected messages as-is.

<==

>
> - Section 3.2.1, last P: can you add a recommendation about what to do
>    when the performance advantage might be sub-optimal, or how to detect
>    algorithmically when this is the case?

==>MT

In earlier versions of this document, we had a whole appendix exactly 
about this, see 
https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-edhoc-06#name-considerations-on-using-blo

Based on feedback from the WG Last Call, it was agreed that those 
recommendations and algorithmic-based detections were excessive for this 
document, and are more suitable for a different Internet Draft or for a 
detailed documentation of an EDHOC library.

We plan to revive that content for inclusion in the more appropriate, 
recently started document 
https://datatracker.ietf.org/doc/draft-tiloca-lake-edhoc-implem-cons/ 
that provides guidelines and considerations for the implementation of 
the EDHOC protocol.

That said and back to the present document, the last paragraph of 
Section 3.2.1 is intentionally very short and simple, and we prefer to 
not discuss such considerations/recommendations in this document (see 
above).

At the same time, we have extended the paragraph as shown below, in 
order to make it explicit that the way to detect and amend inconvenient 
configurations is left to application policies to define.

 > The performance advantage of using the EDHOC + OSCORE request can be 
lost when used in combination with Block-wise transfers that rely on 
specific parameter values and block sizes. Application policies at the 
CoAP client can define when and how to detect whether the performance 
advantage is lost, and, if that is the case, whether to appropriately 
adjust the parameter values and block sizes, or instead to fall back on 
the sequential workflow of EDHOC.

<==

>
> - section 3.3 P4 (not bulleted): "the server has to make sure" -- why
>    isn't this a MUST?

==>MT

Quoting the full sentence:

 > As per Section 9.5 of [I-D.ietf-lake-edhoc], the server has to make 
sure that the error message does not reveal sensitive information.

Section 9.5 of draft-ietf-lake-edhoc at 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-unprotected-data-and-privac 
says:

 > The Initiator and the Responder must make sure that unprotected data 
and metadata do not reveal any sensitive information.

Therefore, the text of the present document is just reminding that what 
is said in draft-ietf-lake-edhoc also applies to this case.

Most important, draft-ietf-lake-edhoc is not using normative language to 
express that requirement, and we believe that the present document 
should not deviate by adding a normative MUST of its own.

<==

>
> - section 7 bullets "This is the sum of the 64-bit MACs": IMHO, this
>    wording doesn't match the real world math operations with the
>    probability of attacking two MACs.  I recognize that
>    draft-ietf-lake-edhoc also says this, but I argue it's not correctly
>    worded either.  When trying to break something with two independent
>    MACs, they're not "added" (summed) -- they're actually multiplied.

==>MT

Consistent with the work done on the security analysis of the EDHOC 
protocol, it is actually correct to say "added"/"summed", so we don’t 
think that there is a problem that needs to be solved.

Regardless, in the present document, we have rephrased the text in the 
two bullet points as follows.

OLD
 > * The Initiator is authenticated with 128-bit security against online 
attacks. This is the sum of the 64-bit MACs in EDHOC message_3 and of 
the MAC in the AEAD of the first OSCORE-protected CoAP request, as 
rebuilt at step 7 of Section 3.3.
 > * The Responder is authenticated with 128-bit security against online 
attacks. This is the sum of the 64-bit MACs in EDHOC message_2 and of 
the MAC in the AEAD of the first OSCORE-protected CoAP response.

NEW
 > * The Initiator is authenticated with 128-bit security against online 
attacks. As per Section 9.1 of [I-D.ietf-lake-edhoc], this results from 
the combination of the strength of the 64-bit MAC in EDHOC message_3 and 
of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP 
request, as rebuilt at step 7 of Section 3.3.1.
 > * The Responder is authenticated with 128-bit security against online 
attacks. As per Section 9.1 of [I-D.ietf-lake-edhoc], this results from 
the combination of the strength of the 64-bit MAC in EDHOC message_2 and 
of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP response.

<==

>
> - section 7: additionally, the 128-bit minimum is only assured with the
>    current defined algorithms.  I doubt future algorithms will be
>    standardized for use that will be weaker, but the wording could be
>    improved by saying "given the currently defined algorithms" or
>    something to explain this "feature" is actually dependent on the IANA
>    registry contents, eg.

==>MT

Section 9.3 "Cipher Suites and Cryptographic Algorithms" of 
draft-ietf-lake-edhoc-22 at 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-security-properties 
says (emphasis mine):

 > When using private cipher suite or *registering new cipher suites*, 
the choice of key length used in the different algorithms needs to be 
harmonized, so that a sufficient security level is maintained for 
authentication credentials, the EDHOC session, and the protection of 
application data.
 > ...
 > *The EDHOC MAC length MUST be at least 8 bytes and the tag length of 
the EDHOC AEAD algorithm MUST be at least 64-bits*.

Forward-pointing to that, Section 9.1 "Security Properties" of 
draft-ietf-lake-edhoc-22 at 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-security-properties 
says (emphasis mine):

 > Based on the cryptographic algorithms requirements Section 9.3, 
*EDHOC provides a minimum of 64-bit security against online brute force 
attacks* and a minimum of 128-bit security against offline brute force 
attacks.

That is, EDHOC is already mandating that (future) algorithms included in 
any possible future EDHOC cipher suite have to yield a minimum security 
level, i.e., 64-bit security against online attacks.

Since the security considerations of draft-ietf-lake-edhoc also hold for 
the present document, it follows that, when using the optimized workflow 
defined in the present document, mutual authentication is achieved with 
at least 128-bit security against online attacks, as discussed in 
Section 7 of the present document and as anticipated in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-security-properties

Therefore, we believe that the current claim is correct and that no 
clarifications are required on future algorithms.

<==

>
> - section 8.3: the registry is defined with ranges from -65536 to 65535,
>    which I note two issues with:  A) no where does the section actually
>    state this is the full range (even though the text assignment ranges
>    implies it), and B) this space is actually 2^17 in size which seems
>    odd.  If you're going to use negative values and want space that fits
>    into 16 bits, then the space should be -32768 to 32767.

==>MT

Yes, this is intended to be the full range. We have rephrased as follows.

OLD
 > The value can be an unsigned integer or a negative integer

NEW
 > The value can be an unsigned integer or a negative integer, in the 
range from -65536 to 65535.


Regarding the specifically defined ranges, this is a very typical choice 
when defining integer ranges to be used in constrained environments. 
Those integer values are expected to be represented as CBOR data items, 
hence as CBOR integers, see 
https://www.rfc-editor.org/rfc/rfc8949.html#name-major-types

In particular:

* Integer values from -24 to 23 result in a CBOR integer whose binary 
encoding is 1 byte in size.
* Integer values from -65536 to -25 and from 24 to 65535 result in a 
CBOR integer whose binary encoding is 2 or 3 bytes in size, depending on 
the exact integer value.
* Integer values less than -65536 and greater than 65535 result in a 
CBOR integer whose binary encoding is 5 or 9 bytes in size, depending on 
the exact integer value.

Like in many other registries, the rationale in defining such ranges is 
to be more demanding with the registrant, if the requested codepoint 
belongs to a range of values that are possible to encode in a small 
amount of bytes.

In turn, that's because the possible values are less in the first place, 
and their potential allocation should carefully consider whether it is 
actually important for the protocol or use case to acquire such a 
precious, shortly-encoded codepoint, or a different one is instead just 
fine.

Like in analogous IANA sections of other documents, we believe that the 
present document should not provide this sort of considerations.

<==

>
> Nits/suggestions:
>
> - Abstract: it would be helpful to start the abstract with the purpose
>    before the rest; simply move the third sentence to the first (with a
>    bit of rewording) and it will add clarity (IMHO).

==>MT

We prefer to keep the current structure, since we think that it would be 
quite hard to understand what the purpose really is if brought up 
without first providing context (i.e., the three involved protocols).

The current abstract provides: i) context; ii) contributions of the 
document; iii) the most important benefit of *one specific contribution* 
of the document.

Please note that the optimized flow defined in Section 3 is not the only 
contribution of the document. That is, Sections 4-6 define mechanisms 
for EDHOC used with CoAP and OSCORE, which are independent of the 
specifically used message flow.

<==

>
> - introduction, paragraph 2 (P2), sentence 1 (S1): add "with CoAP" after
>    "the EDHOC protocol"

==>MT

Starting from the suggestion and aligning with the document title, we 
have rephrased as follows:

 > This document details the use of the EDHOC protocol with CoAP and 
OSCORE, and specifies a number of additional and optional mechanisms.

<==

>    
> - For figure 1 and 2, the messages contain some things that are actualy
>    headers ("Content-Format:") and others that are labels ("Header:",
>    "Payload:"), which is kind of confusing to read.  A naive reader might
>    actually expect "Payload:" to be in the sent message.

==>MT

Please note that:

* "Header:" includes information from the CoAP Header, i.e., the 
request/response code.

* "Uri-Path:" and "Content-Format:" are CoAP options.

This same convention is used, e.g., in the examples in 
https://www.rfc-editor.org/rfc/rfc7252#appendix-A

<==

>
> - Figure 1, EDHOC Response: C_I is missing here.  In general, please
>    review all the messages of both Figure 1 and 2 for whether and where
>    C_I and C_R should be included.  It's a bit confusing because it might
>    be contained within a sub-element but is listed anyway for clarity,
>    etc, but IMHO it should be consistently put in or omitted in each
>    message based on some formula (included or explicit).  EG, C_R is
>    technically inside EDHOC message_3 (if I read the draft right), but
>    yet is explicitly listed as if it's separate in the payload.  This may
>    be intentional but if so then I think C_I should also be listed in
>    the message 2 flow (EDHOC response).  Same with figure 2's EDHOC
>    response and EDHOC + OSCORE request.

==>MT

*As to Section 2 and its Figure 1*:

This content is an overview of EDHOC as-is, aligned with 
draft-ietf-lake-edhoc. As explained in Section 2 of the present document:

 > Figure 1 shows a CoAP client and a CoAP server running EDHOC as 
Initiator and Responder, respectively. In particular, it extends Figure 
18 from Appendix A.2.1 of [I-D.ietf-lake-edhoc], by highlighting when 
the two peers perform EDHOC verification and establish the OSCORE 
Security Context, and by adding an exchange of OSCORE-protected CoAP 
messages after completing the EDHOC execution

Note that, with the CoAP client acting as EDHOC Initiator:

* C_I is included in EDHOC message_1, see 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-initiator-composition-of-me

* C_R is included in EDHOC message_2, as part of the encrypted 
CIPHERTEXT_2, see 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-responder-composition-of-me

* C_I is **NOT** an information included in EDHOC message_2

* C_I is **NOT** transported in the CoAP payload as prepended to EDHOC 
message_2. This is due to the message correlation properties of CoAP, 
which is also discussed in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-the-forward-message-flow

* C_R is **NOT** an information included in EDHOC message_3

* C_R **is** transported in the same CoAP payload, where it **is** 
prepended to EDHOC message_3. This is due to the message correlation 
properties of CoAP, which is also discussed in 
https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-the-forward-message-flow

This is consistent with the text describing Figure 2, i.e.:

 >  The request payload consists of the CBOR simple value "true" (0xf5) 
concatenated with EDHOC message_1, which also includes the EDHOC 
connection identifier C_I of the client encoded as per
Section 3.3 of [I-D.ietf-lake-edhoc].
 > ...
 > The response payload consists of EDHOC message_2, which also includes 
the EDHOC connection identifier C_R of the server encoded as per Section 
3.3 of [I-D.ietf-lake-edhoc].
 > ...
 >  The request payload consists of the EDHOC connection identifier C_R 
encoded as per Section 3.3 of [I-D.ietf-lake-edhoc], concatenated with 
EDHOC message_3.

This is all exactly as defined in draft-ietf-lake-edhoc.


*As to Section 3 and its Figure 2*:

For the CoAP messages transporting EDHOC message_1 and EDHOC message_2, 
the same as above applies.

For the EDHOC + OSCORE request, the CoAP payload does **NOT** transport 
C_R as prepended to EDHOC message_3. This is because the value of C_R, 
i.e., the OSCORE Sender ID of the CoAP client, is already included in 
the 'kid' field of the OSCORE option of that CoAP request.


Specifically about the inclusion of C_R, this should have become clearer 
through the updated text and figures in Section 2 and 3.0 (see replies 
to previous comments).

<==

>
> - Figure 2, EDHOC + OSCORE request: mention the option(s) in the
>    payload?  It might be helpful to indicate to the reader that this is
>    where the various options go since you're talking about them.

==>MT

Please note that there are no options in the CoAP payload.

The CoAP payload includes only EDHOC message_3 (as a CBOR byte string) 
concatenated with the OSCORE ciphertext.

The inclusion of CoAP options in a CoAP message is defined in 
https://www.rfc-editor.org/rfc/rfc7252#section-3

<==

>
> - Section 3.2 bullet 3: I note that COMB_PAYLOAD is not yet mentioned
>    and thus could use a brief definition or maybe just a reference to the
>    normative specification.

==>MT

There is no specification to refer to.

"COMB_PAYLOAD" is just a name introduced here, so that later on we can 
conveniently use it instead of repeating "the concatenation of 
EDHOC_MSG_3 and OSCORE_PAYLOAD".

<==

>
> - section 3.2: I'd be tempted to put the entire beginning of 3.2 into a
>    subsection 3.2.1, which would make referencing it in 3.2.1 (which
>    would become 3.2.2) less confusing and circular.  You'd likely need a
>    short intro before both sections though, but that should be easy
>    enough.  Same comment for Section 3.3 and 3.3.1.

==>MT

We have redistributed the content to become as follows:

* 3.2.0 Mention that the section is about client processing
     * 3.2.1 Content of current 3.2.0
     * 3.2.2 Content of current 3.2.1

* 3.3.0 Mention that the section is about server processing
     * 3.3.1 Content of current 3.3.0
     * 3.3.2 Content of current 3.3.1

<==

>
> - section 3.2, bullet 5: it seems odd that this is near the last step
>    instead of the first (IE, you're adding the signal long after doing
>    everything to support it).  Similarly, the last bullet in section 6
>    seems like it should really be the first bullet.

==>MT

*Regarding Section 3.2*:

Step 5 is the earliest moment when it makes sense to include the EDHOC 
option. Before then, anything might fail and the processing be aborted.

Only if step 5 if reached, does the client actually have a valid EDHOC + 
OSCORE combined request to send, and indicates the CoAP request to be an 
EDHOC + OSCORE request by including the EDHOC option.

We have noticed that the word "signal" may be confusing and suggest the 
separate "transmission of a signal" before sending the EDHOC + OSCORE 
request. Hence, we have rephrased as follows.

OLD
 > Signal the usage of this approach, by including the new EDHOC Option 
defined in Section 3.1 into the EDHOC + OSCORE request.

NEW
 > Include the new EDHOC Option defined in Section 3.1 into the EDHOC + 
OSCORE request.


*Regarding Section 6*:

The bullet points in this list do not have any particular order. Also, 
in a web link, the corresponding target attributes do not have to be 
included altogether and, when included, their position plays no role.

With particular reference to "ed-comb-req", irrespective of its position 
in a web link, its presence signals that the server hosting the EDHOC 
resource indicated by the link target supports the EDHOC optimized workflow.

<==

>
> - section 3.4 note to the editor: I don't understand why this note is
>    here or why you'd want to delete the last bullet.

==>MT

Quoting the text in question (emphasis mine):

 > Figure 4 shows an example of EDHOC + OSCORE Request transported over 
UDP. In particular, the example **assumes** that:
 > ...
 > * The EDHOC option is registered with CoAP option number 21.
 >
 > Note to RFC Editor: Please delete the last bullet point in the 
previous list, since, at the time of publication, the CoAP option number 
will be in fact registered.

The items in the bullet list are assumptions on which the examples build.

As it was suggested in a WG Last Call review, the EDHOC option will be 
registered with CoAP option number 21 at time of publication. Therefore, 
the text currently in the bullet point will be a fact rather than an 
assumption, and should be removed.

<==

>
> - section 3.4, description for figure 4: it would be helpful to specify
>    where a few of the other values come from (CBOR encoding), such as
>    the 93 and ff values.  TL;DR: some elements of your example get
>    encoded in ways that don't match the description (eg, EDHOC option
>    value) and could use an explanation.

==>MT

Please note that the only CBOR-encoded information is EDHOC message_3 
included in the CoAP payload, as per draft-ietf-lake-edhoc.

* As indicated in the text before Figure 4, the OSCORE option has 
**value** 0x090001. The preceding byte 0x93 indicates the option 
number's delta with respect to the previous CoAP option's number in the 
message (none, in this case) and the option length, see 
https://www.rfc-editor.org/rfc/rfc7252#section-3.1

* As defined in this document and indicated in the text before Figure 4, 
the EDHOC option has no value. The preceding byte 0xc0 indicates the 
option number's delta with respect to the previous CoAP option's number 
in the message (the OSCORE option, in this case) and the option length, 
see https://www.rfc-editor.org/rfc/rfc7252#section-3.1

* The byte 0xff is the payload marker that always precedes the CoAP 
payload, if any is present, see 
https://www.rfc-editor.org/rfc/rfc7252#section-3

Overall, the example encodes the fields of a CoAP message as per 
https://www.rfc-editor.org/rfc/rfc7252#section-3 .

We believe that the present document should not re-explain how fields of 
the CoAP messages are encoded.

<==

>
> - The separation between 3.1 and 4.1 confused me a bit, I would have put
>    them together but this stylistic.

==>MT

Please note that Sections 3, 4, 5, and 6 are each providing one of the 
different contributions of this document, and each of those is 
self-standing.

Please also note that there is no strong relation between the EDHOC 
Option in Section 3.1 (which is specific of the new, optimized 
workflow), and the normative requirements on choosing EDHOC connection 
identifiers in Section 4.1 (which is about EDHOC when used with CoAP and 
OSCORE, irrespective of using the original or the optimized message flow).

Therefore, we believe that the current organization of content is 
appropriate.

<==

>
> - 4.1.3: It seems weird that this is worded as a MUST with a bullet as
>    opposed to a MUST NOT.  I'd change the bullet into a MUST NOT and put
>    it as the first sentence maybe.

==>MT

Quoting the text in question:

 > If the following condition holds, the Initiator MUST abort the 
session and reply with an EDHOC error message with error code 1, 
formatted as defined in Section 6.2 of [I-D.ietf-lake-edhoc].
 >
 > * The EDHOC Connection Identifier C_I is equal to the EDHOC 
Connection Identifier C_R specified in EDHOC message_2.

If we switch to using "MUST NOT", the text would become something as 
shown below.

 > The EDHOC Connection Identifier C_I MUST NOT be equal to the EDHOC 
Connection Identifier C_R specified in EDHOC message_2. In case it is 
the following condition holds, the Initiator MUST abort the session and 
reply with an EDHOC error message with error code 1, formatted as 
defined in Section 6.2 of [I-D.ietf-lake-edhoc].

This formulation is not ideal and can be confusing, due to the "MUST 
NOT" at this point of the EDHOC execution covered by Section 4.1.3. That is:

* The Initiator has just received EDHOC message_2, hence:
    * The value of C_I was set in the past when the Initiator sent EDHOC 
message_1, and it can't be changed anymore in this EDHOC session.
    * The value of C_R was set in the past when the Responder sent the 
EDHOC message_2 in question, and the Initiator has no control over it 
altogether.

Therefore, from the point-of-view of the Initiator receiving EDHOC 
message_2, it feels strange to think that "C_I MUST NOT be equal to 
C_R", as it is too late for any better choice or correction.

The best possible think is that if C_R is equal to C_I (i.e., the 
Responder did not comply with what is defined in Section 4.1.2), then 
the Initiator MUST abort the EDHOC session, which is what Section 4.1.3 
is saying.

Based on this comment, we still noticed that an editorial improvement 
was possible, and we have revised the text in Section 4.1.3 to be more 
simply as follow.

 > If the EDHOC Connection Identifier C_I is equal to the EDHOC 
Connection Identifier C_R specified in EDHOC message_2, then the 
Initiator MUST abort the session and reply with an EDHOC error message 
with error code 1, formatted as defined in Section 6.2 of 
[I-D.ietf-lake-edhoc].

<==

>

-- 
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