Re: [Lake] Review EDHOC-v12

["Hristozov, Stefan" <[e-mail]>]

Hi Göran,

thanks for addressing my comments!

It looks good to me. I would like to suggest only to add the relevant RFC references regarding revocation in the section "Implementation consideration".

Best regards,
Stefan


On Mon, 2021-12-13 at 14:57 +0000, Göran Selander wrote:
Hi Stefan,

Thanks for the review. It is recorded as github issue #194 and a proposed update to the draft is in PR #200.

Comments inline. Please let us know if you have further comments or if it is OK to merge #200 and close #194.


From: Lake <[e-mail]> on behalf of Hristozov, Stefan <[e-mail]>
Date: Thursday, 4 November 2021 at 12:43
To: [e-mail] <[e-mail]>
Subject: [Lake] Review EDHOC-v12
Hi all,

please find below my review of draft-ietf-lake-edhoc-12.

Best regards,
Stefan


2. Outline
"ID_CRED_I and ID_CRED_R are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively."
I will replace this definition with something like:
ID_CRED_I and ID_CRED_R are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively.

[GS] Done in PR #200.

3.8 EAD
Is EAD data generated by the application or data that is pre-provisioned or obtained from somewhere. If the former is true I would like to suggest that the specification allows for implementations where all inputs and output that are generated at run time by the application are provided in non-encoded form to the EDHOC implementation. In this way, the interface to the application will be simpler and CBOR encoding and decoding can be completely hidden from the application developer. This applies especially for EAD, see issue #186. The general question is who is supposed to encode/decode EAD? The application or the EDHOC implementation? As far I understand the specification now only the application knows how to encode and decode EAD.

[GS] Correct, the application encodes/decodes EAD. However, for certain EAD use cases it may be most appropriate to implement part of the application and EDHOC together. We will add an appendix which provides some examples of this, new issue #210. Good point about input and output in non-encoded form, that should also be included in those examples. APIs are left out of scope, but it makes sense that EDHOC implementation CBOR encodes the non-encoded information.


5.2.1
"If the most preferred cipher suite is selected then SUITES_I is encoded as that cipher suite, i.e., as an int."
Am I understanding that correctly: If other suites are supported in addition they are not sent, e.g., if the initiator supports suites 1,2,3, where 1 is preferred and selected, 1 is sent as int and 2,3 are not sent? If so I will suggest making this sentence more clear.

[GS] Yes, your understanding is correct. Since the procedure prescribes only sending the cipher suite which is selected and more preferred supported cipher suites, if the selected is the most preferred then only that cipher suite is sent. I tried to clarify the sentence further, see PR#200.


6 Error Handling
What is the use case for a success error code? Probably it is good to give some example or reference why it is useful to log successes using a predefined error code and encoding. Is logging the only use case for the success error code? For example, my implementation logs many things for debugging purposes. However, I never needed a success error code.

[GS] The error code for success came about from a mail exchange on the IOTOPS WG mailing list [1]: "2. reserve one of the status codes for success, so that the status reporting can also use the standard value in case of no error". I added this explanation to the text in PR #200.

[1] https://mailarchive.ietf.org/arch/msg/iotops/t9LTpMiZ__kFGZpceLCBaCUHN44/


The spec says that success error code must not be sent, therefore the sentence "Error code 0 MAY be used internally.." needs to be "Error code 0 MAY be used _only_ internally.."?

[GS] I think "MAY only be used internally" is perhaps stating too much (depending on exact meaning of internally). We already state that the success code MUST NOT be used as part of the EDHOC message flow. I'm not sure we should be more be explicit about how success codes are used. Whether the success code would somehow be exposed through an application is out of scope of the protocol IMHO. So I kept "MAY be used internally" which we seem to agree about although it is not a complete characterization of the potential use of success codes.


"ERR_INFO can contain any type of CBOR item", see figure 7. Who decides what is the type of the CBOR item? Is this the EDHOC implementation developer?

[GS] This is intentionally left open. Returning to the example which motivated the definition of a success code, the use of ERR_INFO in a successful status report allows additional information relevant to the application to complement the information that this is t "no error". This may be a feature of a particular EDHOC implementation, an information element required by a particular application, etc. but what CBOR type is used is not directly impacting the protocol and therefore is out of scope for the specification. I added the latter to the text in PR #200.



7 Mandatory-to-Implement Compliance Requirements
"Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2."
The difference between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. the used algorithms are the same. -> I will suggest changing to "...suite 0/1 or cipher suite 2/3" or similar.

[GS] Good point, I made a separate issue #209. A proposed text is included in PR #200.

Error messages with which error codes are mandatory to implement? Is only an error message with ERR_CODE 2 mandatory to implement?

[GS] Section 7 of version -12 actually says:
"Error codes 1 and 2 MUST be supported."
I added "ERR_CODE" to the sentence in PR #200 for easy search.



8.7 Implementation consideration
"The selection of trusted CAs should be done very carefully and certificate revocation should be supported."

Is OCSP (RFC6960) what should be used for certificate revocation checking?

[GS] Revocation is specified in separate RFCs depending on certificate format, so that is one example.

How revocation can be accomplished with C509?

[GS] C509 has defined CRLs but not yet encoding of OSCP. The topic was brought up at the COSE WG meeting IETF 112, but no details are provided yet.

How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP stapling with EAD?

[GS] As mentioned, the use of OCSP with COSE is not defined yet. Once definition it should also include COSE header parameter which then can be used for transport in ID_CRED_x in EDHOC, or alternatively with EAD. This can be defined separately.

Additionally, to verify a certificate the device should be aware of the time, which is often problematic on constrained devices, i.e. when certificates are used the device must have a Real-Time Clock (RTC).

[GS] Good point. Verification of validity may require the use of a Real-Time Clock (RTC), but as far as I understand, OCSP stapling does not. I added a sentence in PR #200.


Thanks
Göran


--

Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC
Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. [phone]
[e-mail]<mailto:[e-mail]>
https://www.aisec.fraunhofer.de/