Original text:
CRED_I and CRED_R are the credentials containing the public authentication keys of I and R, respectively. <del> ID_CRED_I and ID_CRED_R are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively. </del>  Sig(I; . ) and Sig(R; . ) denote signatures made with the private authentication key of I and R, respectively. SUITES_I - array of cipher suites which the Initiator supports in order of preference, starting with the most preferred and ending with the cipher suite selected for this session.  If the most <del> preferred cipher suite is selected then SUITES_I is encoded as that cipher suite, i.e., as an int.  The processing steps are detailed below and in wrong-selected. </del>  G_X - the ephemeral public key of the Initiator 6.1. Error code 0 MAY be used internally in an application to indicate <del> success, e.g., in log files.  ERR_INFO can contain any type of CBOR item.  Error code 0 MUST NOT be used as part of the EDHOC message exchange flow. </del>  6.2. Implementations MUST support the EDHOC-Exporter.  Implementations SHOULD support EDHOC-KeyUpdate. <del> Implementations MAY support message_4.  Error codes 1 and 2 MUST be supported. </del>  Implementations MAY support EAD. <del> For many constrained IoT devices it is problematic to support more than one cipher suite.  Existing devices can be expected to support either ECDSA or EdDSA.  To enable as much interoperability as we can reasonably achieve, less constrained devices SHOULD implement both cipher suite 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES- CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA- 256, 8, P-256, ES256, AES-CCM-16-64-128, SHA-256).  Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2. Implementations only need to implement the algorithms needed for their supported methods. </del>  8. derivation is completed. The Initiator and the Responder are responsible for verifying the <del> integrity of certificates.  The selection of trusted CAs should be done very carefully and certificate revocation should be supported. The private authentication keys MUST be kept secret, only the Responder SHALL have access to the Responder's private authentication key and only the Initiator SHALL have access to the Initiator's private authentication key. </del>  The Initiator and the Responder are allowed to select the connection identifiers C_I and C_R, respectively, for the other party to use in

Reviewer comments:
Added references to revocation according to final comment.
Separate issue from Stefan's review : "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 "URL 0/1 or cipher suite 2/3" or similar.
Relates to . I think this is a good idea.
A proposal in PR
This makes sense to me
I propose we merge this once we converge on
and are very independant. I think 1 and 3 should probably be recommended for transports that can handle 53 byte payloads without significant performance degradation.
There was discussion during the meeting regarding endpoint / device. The current draft use both as a well as implementation. I think device is useful when we talk about "constrained devices" but not otherwise. The endpoint does in general not need to be a "device". It might be software in the cloud or some chip where EDHOC is used on the internal bus.
URL Outline "IDCREDI and IDCREDR are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively." I will replace this definition with something like: IDCREDI and IDCREDR are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively. 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 . 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. "If the most preferred cipher suite is selected then SUITESI 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. 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. 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.."? "ERRINFO 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? 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 "URL 0/1 or cipher suite 2/3" or similar. Error messages with which error codes are mandatory to implement? Is only an error message with ERRCODE 2 mandatory to implement? 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? How revocation can be accomplished with C509? How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP stapling with EAD? 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).
opened to address this review.
Looks good to me. I have just read the PR, not checked how the PR corresponds to the review. Hi all, please find below my review of draft-ietf-lake-edhoc-12. Best regards, Stefan Outline "IDCREDI and IDCREDR are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively." I will replace this definition with something like: IDCREDI and IDCREDR are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively. 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 . 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. "If the most preferred cipher suite is selected then SUITESI 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. 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. 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.."? "ERRINFO 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? 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 "URL 0/1 or cipher suite 2/3" or similar. Error messages with which error codes are mandatory to implement? Is only an error message with ERR_CODE 2 mandatory to implement? 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? How revocation can be accomplished with C509? How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP stapling with EAD? 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). Stefan Hristozov Department Hardware Security Fraunhofer Institute for Applied and Integrated Security AISEC Lichtenbergstraße 11, 85748 Garching near Munich, Germany Tel. +49 89 32299 86 157 EMAIL URL URL

Revised text:
CRED_I and CRED_R are the credentials containing the public authentication keys of I and R, respectively.  <ins> ID_CRED_I and ID_CRED_R are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively. </ins> Sig(I; . ) and Sig(R; . ) denote signatures made with the private authentication key of I and R, respectively. SUITES_I - array of cipher suites which the Initiator supports in order of preference, starting with the most preferred and ending with the cipher suite selected for this session.  If the most  <ins> preferred cipher suite is selected then SUITES_I contains only that cipher suite and is encoded as an int.  The processing steps are detailed below and in wrong-selected. </ins> G_X - the ephemeral public key of the Initiator 6.1. Error code 0 MAY be used internally in an application to indicate  <ins> success, i.e., as a standard value in case of no error, e.g., in status reporting or log files.  ERR_INFO can contain any type of CBOR item, the content is out of scope for this specification.  Error code 0 MUST NOT be used as part of the EDHOC message exchange flow. </ins> 6.2. Implementations MUST support the EDHOC-Exporter.  Implementations SHOULD support EDHOC-KeyUpdate.  <ins> Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and 2 MUST be supported. </ins> Implementations MAY support EAD.  <ins> For many constrained IoT devices it is problematic to support several crypto primitives.  Existing devices can be expected to support either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256, 8, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and 1 (AES-CCM- 16-128-128, SHA-256, 16, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) only differ in size of the MAC length, so supporting one or both of these is no essential difference.  Similarly for cipher suites 2 (AES-CCM-16-64-128, SHA-256, 8, P-256, ES256, AES-CCM-16-64-128, SHA- 256) and 3 (AES-CCM-16-128-128, SHA-256, 16, P-256, ES256, AES-CCM- 16-64-128, SHA-256).  To enable as much interoperability as we can reasonably achieve, less constrained devices SHOULD implement all four cipher suites 0-3.  Constrained endpoints SHOULD implement cipher suites 0 and 1, or cipher suites 2 and 3.  Implementations only need to implement the algorithms needed for their supported methods. </ins> 8. derivation is completed. The Initiator and the Responder are responsible for verifying the  <ins> integrity and validity of certificates.  The selection of trusted CAs should be done very carefully and certificate revocation should be supported.  The choice of revocation mechanism is left to the application.  For example, in case of X.509 certificates, Certificate Revocation Lists RFC5280 or OCSP RFC6960 may be used.  Verification of validity may require the use of a Real-Time Clock (RTC).  The private authentication keys MUST be kept secret, only the Responder SHALL have access to the Responder's private authentication key and only the Initiator SHALL have access to the Initiator's private authentication key. </ins> The Initiator and the Responder are allowed to select the connection identifiers C_I and C_R, respectively, for the other party to use in