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

[Marco Tiloca <[e-mail]>]

Hi Paul,

Thanks a lot for your review! Please see in line below our detailed reply.

Based on your comments, we have prepared the PR #14 at [1].

If there is no objection, we plan to merge the PR and submit the result 
as version -09 soon.

Best,
/Marco

[1] https://github.com/core-wg/oscore-edhoc/pull/14

On 2023-09-28 22:08, Paul Wouters wrote:
> Hi,
>
> Overall the document looks good. I have a few comments/nits below and 
> one issue.
>
> Issue:
>
>          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.
>
> A last minute change in EDHOC was to encrypt C_R. It is unfortunate that
> this now seems to send C_R in the clear again. Can this be avoided?

==>MT

TL;DR: per the EDHOC specification, the encrypted C_R is the one in 
EDHOC message_2. Instead, the plain C_R mentioned in the text is the one 
prepended to EDHOC message_3, both of which are conveyed in the CoAP 
payload. The latter C_R is not and cannot be encrypted by EDHOC.

The quoted text is part of the overview of EDHOC "as-is" and is aligned 
with draft-ietf-lake-edhoc, with no difference as to the prepending of 
C_R in EDHOC message_3 when transported in CoAP.

In fact, it is consistent with what is shown in Figure 18 at

https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-22#name-the-forward-message-flow

when considering the forward message flow of EDHOC transported over 
CoAP. In that Figure 18, the payload of the second request includes 
EDHOC message_3 prepended by C_R.

Please note that the mentioned C_R in the CoAP request message is not 
encrypted by EDHOC, since:

* C_R is not part of EDHOC message_3 in itself; and

* C_R has to be prepended to EDHOC message_3, due to the message 
correlation properties of CoAP

The recently introduced encryption of C_R is for the C_R included in 
EDHOC message_2, in which case C_R is indeed part of the PLAINTEXT_2 
processed when composing EDHOC message_2.

Also, please note that, irrespective of using the vanilla or the 
optimized workflow of EDHOC, C_R is later going to be repeatedly exposed 
in plain anyway when using OSCORE. That's because C_R is the OSCORE 
Sender ID of the CoAP Client (i.e., the EDHOC Initiator). Therefore, it 
is going to be included in the 'kid' field of the OSCORE Option in each 
OSCORE-protected CoAP request sent by the Client to the Server.

When discussing about encrypting C_R in the LAKE WG, the points above 
were also highlighted on the LAKE WG mailing list. In particular, please 
see:

https://mailarchive.ietf.org/arch/msg/lake/zTdTw7elW_al7D54DQWdKSVTIcg/

As an attempt to clarify that Section 2 and its Figure 1 of the present 
document overview EDHOC as-is, we have made the following updates in 
Section 2:

OLD
 > Appendix A.2 of [I-D.ietf-lake-edhoc] specifies how to transfer EDHOC 
over CoAP. That is, the EDHOC data (i.e., the EDHOC message possibly 
with a prepended connection identifier) are transported in the payload 
of CoAP requests and responses. The default, forward message flow of 
EDHOC consists in the CoAP client acting as Initiator and the CoAP 
server acting as Responder. Alternatively, the two roles can be 
reversed, as per the reverse message flow of EDHOC. In the rest of this 
document, EDHOC messages are considered to be transferred over CoAP.

NEW
 > Appendix A.2 of [I-D.ietf-lake-edhoc] specifies how to transfer EDHOC 
over CoAP. That is, the EDHOC data (i.e., the EDHOC message possibly 
with a prepended connection identifier) are transported in the payload 
of CoAP requests and responses. The default, forward message flow of 
EDHOC consists in the CoAP client acting as Initiator and the CoAP 
server acting as Responder (see Appendix A.2.1 of 
[I-D.ietf-lake-edhoc]). Alternatively, the two roles can be reversed, as 
per the reverse message flow of EDHOC (see Appendix A.2.2 of 
[I-D.ietf-lake-edhoc]). In the rest of this document, EDHOC messages are 
considered to be transferred over CoAP.


OLD
 > Figure 1 shows a CoAP client and a CoAP server running EDHOC as 
Initiator and Responder, respectively. That is, the client ...

NEW
 > 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.
 >
 > That is, the client ...

<==

>
> Comments:
>
>         This optimization is desirable, since the number of protocol
>         round trips influences the minimum number of flights,
>
> I don't fully understand this sentence. I think it is trying to say that
> doing two protocols fully sequencially one after the other causes more
> roundtrips and thus more latency? Perhaps that can be formulated without
> the use if "number of flights" ? (which to me is confusing, also because
> actual flights talk about legs :)

==>MT

Trying to avoid "flights" altogether, we have instead focused on 
"messages exchanges" and "round trips", and have updated the text as 
follows.

OLD
 > This optimization is desirable, since the number of protocol round 
trips influences the minimum number of flights, which in turn can have a 
substantial impact on the latency of conveying the first OSCORE request, 
when using certain radio technologies.
 >
 > Without this optimization, it is not possible, not even in theory, to 
achieve the minimum number of flights. This optimization makes it 
possible also in practice, since the last message of the EDHOC protocol 
can be made relatively small (see Section 1.2 of [I-D.ietf-lake-edhoc]), 
thus allowing additional OSCORE-protected CoAP data within target MTU sizes.

NEW
 > This optimization is desirable, since the number of message exchanges 
can have a substantial impact on the latency of conveying the first 
OSCORE request, when using certain radio technologies.
 >
 > 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 the message_3 of the EDHOC protocol can 
be made relatively small (see Section 1.2 of [I-D.ietf-lake-edhoc]), 
thus allowing additional OSCORE-protected CoAP data within target MTU sizes.

<==

>
>         That is, the EDHOC data (referred to as "EDHOC messages")
>
> Why not also just call it "EDHOC messages" in this document?

==>MT

They are two different things.

We consistently use "EDHOC data" to indicate the combination of the 
prepended connection identifier (if any) and the actual EDHOC message.

We have updated the sentence as follows:

OLD
 > That is, the EDHOC data (referred to as "EDHOC messages") ...

NEW
 > That is, the EDHOC data (i.e., the EDHOC message possibly with a 
prepended connection identifier) ...

<==

>
>         Finally, the client sends a POST request to the same EDHOC
>         resource used earlier to send EDHOC message_1.
>
> This really is confusing to read. I initially read it as "send EDHOC 
> message_1".
> How about:
>
>         Finally, the client sends a POST request to the same EDHOC
>         resource used earlier when it sent EDHOC message_1.

==>MT

Thanks, we have fixed it as suggested.

<==

>
> Section 3.2: Perhaps change the sentence in "Step 1" to:
>
>         Compose EDHOC message_3 into EDHOC_MSG_3 as per Section 5.4.2 
> of [I-D.ietf-lake-edhoc].
>
> so it properly introduces EDHOC_MSG_3 before its first use?

==>MT

Yes, good point. We have fixed it as suggested.

<==

>
>         the server discontinues the protocol [...]
>
>         the Initiator MUST discontinue the protocol [...]
>
> We changed "discontinues the protocol" to "aborts the session" in the 
> EDHOC document.
> You don't mean discontinue to use the protocol defined in this RFC :)

==>MT

Indeed. We have changed the text to say "the server aborts the session" 
(in Section 3.3) and "the Initiator MUST abort the session" (in Section 
4.1.3).

<==

>
>         The server MUST NOT establish a new OSCORE Security Context from
>         the present EDHOC session with the client, hence the CoAP response
>         conveying the EDHOC error message is not protected with OSCORE.
>
> I don't understand this sentence? Did you mean "as" instead of "hence" ?

==>MT

We really mean "hence". The order of event and their causal relation is:

- An OSCORE Security Context is not derived; hence
- The response transporting the EDHOC error message is not protected 
with OSCORE (as it cannot be).

In order to avoid confusion altogether, we simplified the sentence as 
follows:

NEW
 > The server MUST NOT establish a new OSCORE Security Context from the 
present EDHOC session with the client. The CoAP response conveying the 
EDHOC error message is not protected with OSCORE.

<==

>
>         The CoAP response conveying the EDHOC error message MUST have
>         Content-Format set to application/edhoc+cbor-seq defined in
>         Section 9.9 of [I-D.ietf-lake-edhoc].
>
> There is no section 9.9. I think you mean Section 10.9 (just as 
> Appendix A.2.3
> does that reference)

==>MT

We have fixed the numbers of the referred sections from 
draft-ietf-lake-edhoc.

<==

>
>        As per Section 3.3.2 of [I-D.ietf-lake-edhoc], when using the
>         purely-sequential flow shown in Figure 1, the same C_R with
>         value 0x01 would be encoded on the wire as the CBOR integer 1
>         (0x01 in CBOR encoding), and prepended to EDHOC message_3 in
>         the payload of the second EDHOC request.
>
> I'm a bit confused by "on the wire" of C_R because EDHOC message_3
> contains: AEAD( ID_CRED_I, Signature_or_MAC_3, EAD_3 )
> Do you mean as part of CoAP?


==>MT

In short: yes, as part of CoAP.

Indeed EDHOC message_3 includes only AEAD( ID_CRED_I, 
Signature_or_MAC_3, EAD_3 ), but this does not contradict the quoted text.

In the vanilla workflow, C_R is prepended to EDHOC message_3, and indeed 
it is not part of EDHOC message_3 in itself.

Yet, due to the message correlation properties of CoAP, C_R has to be 
prepended to the EDHOC message_3 in the payload of the CoAP request of 
the forward message flow (see also Appendix A.2.1 of draft-ietf-lake-edhoc).

Therefore, C_R is on the wire, since it is part of the payload of the 
sent CoAP message.

<==

>
>         The EDHOC Connection Identifier C_I is equal to the EDHOC
>         Connection Identifier C_R specified in EDHOC message_2 (i.e.,
>         after its decoding as per Section 3.3 of [I-D.ietf-lake-edhoc]).
>
> Since C_R is now encrypted in EDHOC message_2, I guess "decoding" is 
> no longer
> the right word. After decrypting ?

==>MT

As a clarification, CIPHERTEXT_2 has to be decrypted first. After that, 
one retrieves from PLAINTEXT_2 the wire-encoding of C_R, which has to be 
decoded into its native, binary form.

In order to avoid confusion altogether, we have simplified the quoted 
paragraph in Section 4.1.3 and an analogous paragraph in Section 4.1.2 
as follows:

OLD (Section 4.1.3)
 > The EDHOC Connection Identifier C_I is equal to the EDHOC Connection 
Identifier C_R specified in EDHOC message_2 (i.e., after its decoding as 
per Section 3.3 of [I-D.ietf-lake-edhoc]).

NEW (Section 4.1.3)
 > The EDHOC Connection Identifier C_I is equal to the EDHOC Connection 
Identifier C_R received in EDHOC message_2.


OLD (Section 4.1.2)
 > The Responder MUST choose a C_R that is neither used in any current 
EDHOC session as this peer's EDHOC Connection Identifier, nor is equal 
to the EDHOC Connection Identifier C_I specified in the EDHOC message_1 
of the present EDHOC session (i.e., after its decoding as per Section 
3.3 of [I-D.ietf-lake-edhoc]), nor is ...

NEW (Section 4.1.2)
 > The Responder MUST choose a C_R that is neither used in any current 
EDHOC session as this peer's EDHOC Connection Identifier, nor is equal 
to the EDHOC Connection Identifier C_I received in the EDHOC message_1 
of the present EDHOC session, nor is ...

<==

>
>         Section 9.10 of [I-D.ietf-lake-edhoc] registers the resource type
>         "core.edhoc"
>
> This should be Section 10.10.

==>MT

We have fixed the numbers of the referred sections from 
draft-ietf-lake-edhoc.

<==

>
>         which is taken from the 'Label' column of the "EDHOC External
>         Authorization Data" registry defined in Section 9.5 of
>         [I-D.ietf-lake-edhoc].
>
> Should be section 10.5. (Please check all section 9 references in the 
> doc for update)

==>MT

We have fixed the numbers of the referred sections from 
draft-ietf-lake-edhoc.

<==

>
>         by expanding their semantics and specifying admitted values.
>
> What does "admitted" here mean? Maybe "specifying additional values" ?

==>MT

We have rephrased as follows:

 > (Future documents may update the definition of the parameters 'ed-i', 
'ed-r', and 'ed-comb-req', by expanding their semantics and specifying 
what they can take as value.)

<==

>
>
>         the Change Controller is IESG,
>
> I believe the IESG preference is to list IETF as change controller ?


==>MT

We have changed it to "IETF".

<==

>
>
>
>
> nits:
>
> Personal pet peeve: I dislike using 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> and prefer +-------+---------+---+-------------+-----+ style :)
> I have also never seen the usage of open ended boxes, so I would change:
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Ver| T |  TKL  |      Code     |          Message ID   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Token (if any, TKL bytes) ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Observe Option| OSCORE Option ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | EDHOC Option  | Other Options (if any) ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |1 1 1 1 1 1 1 1| Payload ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> to:
>
> +---+---+-------+---------------+-------------------------------+
> |Ver| T |  TKL  |      Code     |          Message ID     |
> +---+---+-------+---------------+-------------------------------+
> | Token (if any, TKL bytes)     ~
> ~     ~
> +---------------+-----------------------------------------------+
> | Observe Option| OSCORE Option     ~
> +---------------+     ~
> ~     ~
> +---------------+-----------------------------------------------+
> | EDHOC Option  | Other Options (if any)    ~
> +---------------+     ~
> ~     ~
> +---------------+-----------------------------------------------+
> |1 1 1 1 1 1 1 1| Payload     ~
> +---------------+
> ~     ~
> +---------------------------------------------------------------+
>
>

==>MT

As also raised in

https://mailarchive.ietf.org/arch/msg/core/LBLmCFK_lY86iwlRGfAMWwQNNOw/

we have preferred to preserve the same style used since RFC 7252.

<==

> Paul
>

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