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

[Paul Wouters <[e-mail]>]

Thanks, all looks good.

Paul

On Oct 12, 2023, at 16:51, Marco Tiloca <[e-mail]> wrote:

 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" rel="nofollow">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" rel="nofollow">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/" rel="nofollow">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/" rel="nofollow">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" rel="nofollow">https://www.ri.se

<OpenPGP_0xEE2664B40E58DA43.asc>