Re: [Lake] Review of draft-ietf-lake-edhoc-12

[Marco Tiloca <[e-mail]>]

Hi Göran,

Thanks for addressing my comments!

Please, see below my reply to three points from your response. Other 
than that, PR #199 looks good to be merged.

Best,
/Marco


On 2021-12-13 15:47, Göran Selander wrote:
>
> Hi Marco,
>
> Thanks for the review. It is recorded as github issue #192 and a 
> proposed update to the draft is in PR #199.
>
> Comments inline. Please let us know if you have further comments on 
> the updates made or if it is OK to merge #199 and close #192.
>
>
> *From: *Lake <[e-mail]> on behalf of Marco Tiloca 
> <marco.tiloca=[e-mail]>
> *Date: *Wednesday, 3 November 2021 at 17:26
> *To: *[e-mail] <[e-mail]>
> *Subject: *[Lake] Review of draft-ietf-lake-edhoc-12
>
> Hi all,
>
> As promised, please find below my review of EDHOC v -12.
>
> Best,
> /Marco
>
> =============
>
> [Section 1.1]
>

==>MT
(trimming)
<==

> * s/compromise of the long-term keys/compromise of the long-term
> identity keys
>
> [GS] The term "identity key" is not used elsewhere in the document. 
> The term "long-term key" is used throughout the document including the 
> security considerations and is a common term used in protocol analysis 
> which is what this text talks about. So I think it makes sense to not 
> change here. The alternative would be to talk about "private 
> authentication key" which is also used in the document, but more in 
> the context of identities.
>

==>MT
I see, then it's good to keep "long-term keys".
<==

>
> [Section 8.7]
>
> * "... but intended to simplify ..."
>
>     Since "security context" is mentioned in the following sentences, it
> is better to explicitly mention that they are referring to the
> application protocol and not to EDHOC anymore.
>
> [GS] I didn't make this proposed change because "security context" is 
> not limited to OSCORE, so this sentence applies also to EDHOC. If you 
> still find this misleading, please explain in what way it is so.
>

==>MT
Ok, I think the confusion comes from not using "security context" as 
related to the EDHOC execution earlier in the document. That has rather 
been referred as "protocol state".

Perhaps it's worth clarifying this in Section 3.4.1, that now states 
twice "the retrieval of protocol state during EDHOC protocol execution." 
This may become "the retrieval of protocol state and its security 
context during EDHOC protocol execution".
<==

>
> [Appendix A.3]
>
> * "EDHOC message_2 or the EDHOC error message is sent from the server to
> the client in the payload of a 2.04 (Changed) response. EDHOC message_3
> or the EDHOC error message is sent from the client to the server's
> resource in the payload of a POST request. If needed, an EDHOC error
> message is sent from the server to the client in the payload of a 2.04
> (Changed) response."
>
>     This text should also be a remnant of old versions. When using EDHOC
> for OSCORE, EDHOC error messages as CoAP responses are sent as error
> responses, see the first paragraph in Appendix A.3.1. The text above can
> rather, more generically, be:
>
>     "The server sends to the client EDHOC message_2 in the payload of a
> 2.04 (Changed) response, or an EDHOC error message in the payload of a
> response. If needed, the client sends to the server an EDHOC error
> message in the payload of a POST request. Otherwise, the client sends to
> the server EDHOC message_3 in the payload of a POST request. If needed,
> the server sends to the client an EDHOC error message in the payload of
> a response."
>
> [GS] Good spotted, I modifed the original text in a different way:
>
> NEW
> EDHOC message_2 or the EDHOC error message is sent from the server to 
> the client in the payload of the response, in the former case with 
> response code 2.04 (Changed), in the latter with response code as 
> specified in Section 8.3.1 EDHOC message_3 or the EDHOC error message 
> is sent from the client to the server's resource in the payload of a 
> POST request. If EDHOC message_4 is used, or in case of an error 
> message, it is sent from the server to the client in the payload of 
> the response, with response codes analogously to message_2.
>

==>MT
Looks good, although I guess you meant "as specified in Appendix A.3.1. 
EDHOC message_3 ..." , rather than "as specified in Section 8.3.1 EDHOC 
message_3 ..."
<==

> Thanks!
>
> Göran
>
>
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)