Re: [Lake] [core] 🔔 Working Group Last Call (WGLC) of draft-ietf-core-oscore-edhoc-06

[Marco Tiloca <[e-mail]>]

Hi John,

Thanks a lot for your review! We have addressed your comments in the new 
version -07.

Please find detailed answers in line.

Best,
/Marco

On 2023-02-25 18:21, John Mattsson wrote:
>
> Hi,
>
> I have reviewed draft-ietf-core-oscore-edhoc-06. I think it is ready 
> with issues.
>
> - "Profiling EDHOC for CoAP and OSCORE"
>
>   Not sure this is a suitable name. It does not really profile EDHOC.
>

==>MT
We have changed the document title to "Using EDHOC with CoAP and OSCORE".
<==

> - OLD "first subsequent OSCORE transaction" (several occurences)
>
> - NEW "first OSCORE transaction"
>
>   it is not subsequent anymore
>

==>MT
Fixed (4 occurrences).
<==

> - "CoAP [RFC7252], CBOR [RFC8949], CBOR sequences [RFC8742], OSCORE
>
> [RFC8613] and EDHOC [I-D.ietf-lake-edhoc]."
>
>   IETF uses the Oxford comma. (Probably several occurences).
>

==>MT
Fixed and revised the whole document.
<==

> - "may be set to application/cid-edhoc+cbor-seq." (several occurences)
>
>   Any reason this is not a normative MAY, also what is the reason for 
> not have SHOULD or SHALL?I don’t have a strong opinion.
>

==>MT
This is an "Overview" section, so we are avoiding normative language 
altogether and we don't want to restate (or suggest deviations from) 
what draft-ietf-lake-edhoc says. We especially avoid using SHOULD/SHALL 
since, in its section 3.1, draft-ietf-lake-edhoc simply says:

   "Media types that may be used for EDHOC are defined in Section 9.8."

We have anyway rephrased the three occurrences in this Section 2 to say 
"can be set to".
<==

> - OLD "not transported precisely in the request payload."
>
> - NEW "not transported in the request payload."
>
> But probably better to just say "as specified in Section 3.2, C_R is 
> transported in the OSCORE Option."
>

==>MT
Yes, it's even better to merge the two suggestions. We rephrased to say:

"as specified in Section 3.2, C_R is transported in the OSCORE Option 
rather than in the request payload"
<==

> - "using the new OSCORE Security Context established after receiving 
> EDHOC message_2."
>
> I think this should be "after creating EDHOC message_3"The context 
> depends on message_3.
>

==>MT
Yes; before generating and installing the OSCORE Security Context, you 
actually need to have successfully created EDHOC message_3, especially 
instead of an EDHOC error message.

We rephrased the whole step 2 in the client processing as follows:

OLD:
Encrypt the original CoAP request as per Section 8.1 of [RFC8613], using 
the new OSCORE Security Context established after receiving EDHOC message_2.

NEW:
Establish the new OSCORE Security Context and use it to encrypt the 
original CoAP request as per Section 8.1 of [RFC8613].

(which happens strictly after the previous step 1, where EDHOC message_3 
is composed)
<==

> - "Check that the EDHOC + OSCORE request includes the OSCORE option
>
>    and that the request payload is a CBOR sequence composed of two
>
>    CBOR byte strings."
>
> Should check for the EDHOC option as well
>

==>MT
Sure, however, that happens upfront. That is, the sequence of steps 
already refers to a message including the EDHOC option. Before the 
sequence of steps starts, the text says:

     "In order to process a request containing the EDHOC option, i.e., 
an EDHOC + OSCORE request, the server MUST perform the following steps."

So, no action taken.
<==

> - The document is not clear on if you can send back an EDHOC error 
> over OSCORE or not. Itshould be.
>

==>MT
This point underwent several good discussions. There was consensus on 
not encrypting the EDHOC error message. Consistently, we have updated 
the second from last paragraph in Section 3.3 "Server processing", which 
now reads as follows (new text between [NEW-START] and [NEW-END]):

"If step 4 (EDHOC processing) fails, the server discontinues the 
protocol as per Section 5.4.3 of [I-D.ietf-lake-edhoc] and responds with 
an EDHOC error message with error code 1, formatted as defined in 
Section 6.2 of [I-D.ietf-lake-edhoc]. [NEW-START]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. Furthermore,[NEW-END] 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]."
<==

> - As discussed in LAKE you can get 128-bit authenticatation security 
> by combinging two 64 bit tags. Has this been discussedin CORE?Ifthe 
> mechanism gives this propertyfor either peeris should be mentioned.
>

==>MT
We have added one more paragraph in Section 7 "Security Considerations", 
see current third paragraph and its inner bullet list.
<==

> - Is is clear what happens if the EDHOC + OSCORE Request is retransmitted?
>

==>MT
We think so, and we are not saying anything more than what is already 
defined in Section 5.1 of draft-ietf-lake-edhoc, i.e.:

     "Different instances of the same message MUST NOT be processed in 
one session. Note that processing will fail if the same message appears 
a second time for EDHOC processing in the same session because the state 
of the protocol has moved on and now expects something else."

Consistently, a retransmission of the EDHOC + OSCORE Request results in 
a failure at the server when performing step 4 of Section 3.3, in case 
the server has already successfully completed that EDHOC session. Later 
on in the same section, we inherit the error handling defined in the 
draft-ietf-lake-edhoc, including for this particular case.

This was also discussed at the 2023-03-01 CoRE interim meeting, where it 
was confirmed to defer this to the error handling already defined in EDHOC.

So, no action taken here.
<==

> - "where the ID Context has zero-length."
>
> This seems wrong. There is nothing special with the zero-length ID 
> Context.
>
> This should be "where the ID Context is not present"
>

==>MT
You're right, good catch!

Building on the overall new formulation from Christian's review, we have 
revised the content of Sections 4.1.1 and 4.1.2 to consider a non 
present ID Context, as you say.
<==

> - 'ead1', 'ead2', 'ead3' and 'ead4'
>
>   This makes no sense to me. Either you support EAD or not. Also 
> knowing that theother party support EAD is useless. You need to know 
> what kind of EAD. I stongly think thisshould use values from the EDHOC 
> External Authorization Data Registry.
>

==>MT
What you say was exactly our original intention; the text was not clear 
enough.

Following our more recent discussion on this point, we have further 
simplified this part in Section 6, by introducing only one target 
attribute ed-ead. Its value is the ead_label of an EAD item that the 
server supports, and it is indeed taken from the "EDHOC External 
Authorization Data" registry.

Thanks a lot again!
<==

> Cheers,
>
> John
>
> *From: *core <[e-mail]> on behalf of Carsten Bormann 
> <[e-mail]>
> *Date: *Wednesday, 15 February 2023 at 23:39
> *To: *Christian Amsüss <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [core] [Lake] 🔔Working Group Last Call (WGLC) of 
> draft-ietf-core-oscore-edhoc-06
>
> On 15. Feb 2023, at 23:25, Christian Amsüss <[e-mail]> wrote:
> >
> > * 3.2 step 3: "The first CBOR byte string is the EDHOC message_3
>
> Ah.
>
> We are using the term “byte string” to describe the generic data model 
> data item with that name (using major type 2 and enclosing a sequence 
> of bytes into a single data item).
>
> We are using the term “encoded CBOR data item” to describe the 
> sequence of bytes that results from encoding a CBOR data item (any 
> CBOR data item of course, not just a byte string).
>
> So where the byte string is h’010203’, the encoded CBOR data item 
> encoding that data item is 43010203 hex.
> The latter, of course, can be carried in another byte string 
> h’43010203’, which would then be encoded as 4443010203 hex.
> So it is really important not to confuse “CBOR byte string” with 
> “encoded CBOR data item”.
>
> (Of course, this distinction applies to any representation format that 
> can carry its own encodings, as in the JSON text
>
>     “{\”a\”: 1, \”b\”: 2}”
>
> which is obviously not the same as the JSON text
>
>     {“a”: 1, “b”: 2}
>
> In JSON this kind of embedding is rather expensive and thus done less 
> often, while in CBOR embedding encoded data items in byte strings is a 
> rather natural way to carry certain kinds of information.)
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=05%7C01%7Cmarco.tiloca%40ri.se%7C7f8bd53e47604b1b8f4808db1754de00%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638129425509247911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x9s3MfKi%2FGKGqQQ176SNUEKNUQzg3SSCS77efBbsgcI%3D&reserved=0>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

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