Draft: draft-ietf-lake-edhoc

Commentary: Added references to revocation according to final comment . 
 Separate issue from  '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 " 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 . 
 " 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 . 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 . 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 . 1 " 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 " 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 ? 7 Implementation consideration " The selection of trusted CAs should be done very carefully and certificate revocation should be supported . " Is  ( 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 .
Mailing list commentary: Hi all , please find below my review of draft - ietf - lake - edhoc-12 . Best regards , . 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 are used to identify and optionally transport the authentication keys of the Initiator and the Responder , respectively . 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 . 5.2.1 " 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 " ... suite 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 ? 8.7 Implementation consideration " The selection of trusted CAs should be done very carefully and certificate revocation should be supported . " Is  ( 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 ) . Department Hardware Security Fraunhofer Institute for Applied and Integrated Security AISEC , Garching near Munich , Germany Tel . +49 89 86 157
Paragraph (version A):
ID_CRED_I and ID_CRED_R are credential identifiers enabling the
recipient party to retrieve the credential of I and R,
respectively.
Paragraph (version B):
ID_CRED_I and ID_CRED_R are used to identify and optionally
transport the authentication keys of the Initiator and the
Responder, respectively.
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.
Paragraph (version A):
Error code 0 MAY be used internally in an application to indicate
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.
Paragraph (version B):
Error code 0 MAY be used internally in an application to indicate
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.
Paragraph (version A):
Implementations MAY support message_4.  Error codes 1 and 2 MUST be
supported.
Paragraph (version A):
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.
Paragraph (version B):
Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and
2 MUST be supported.
Paragraph (version B):
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.
Paragraph (version A):
The Initiator and the Responder are responsible for verifying the
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.
Paragraph (version B):
The Initiator and the Responder are responsible for verifying the
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.