Draft: draft-ietf-lake-edhoc

Commentary: Done 
 From  's comment to changes following  's review : " identities to verify the ' sub ' ( subject ) claim of the CWT . " Should use the same text for X509 and CWT . Moreover , " sub " claim is just an example . CWT might add e.g. AltSub in the future . 
 If we change one of them we should change both . I think this issue is strongly related to and could be fixed together . 
 With PR , it is now clear that verification of identity is the responsibility of the application . Therefore Appendix D just gives examples , where this text now reads : Is this good enough ? 
 [ Section 1.1 ] " This specification focuses on referencing instead of transporting credentials to reduce message overhead . " It is possible to transport credentials both by reference and by value . What suggests the case of transport by reference to be the " focus " ? Perhaps you mean that it is possible and preferable / recommended to transport credentials by reference ? " future algorithms and credentials targeting IoT " This probably means " future algorithms and identity credential types targeting IoT " . s / compromise of the long - term keys / compromise of the long - term identity keys [ Section 1.3 ] s / the number of bytes in EDHOC + CoAP can be / the EDHOC message size in bytes when transferred in CoAP can be [ Section 1.5 ] " and CDDL [ RFC8610 ] . The Concise Data Definition Language ( CDDL ) is used to express CBOR data structures [ RFC8949 ] " can be rephrased as : " and the Concise Data Definition Language ( CDDL ) [ RFC8610 ] , which is used to express CBOR data structures [ RFC8949 ] " [ Section 2 ] " Verification of a common preferred cipher suite " Should n't this say : " Verification of a commonly supported cipher suite which is most preferred by the Initiator " ? [ Section 3.2 ] In Figure 4 , the second and third column can rather have labels " Initiator Authentication Key " and " Responder Authentication Key " . [ Section 3.3 ] " or in a subsequent application protocol " can be expanded as : " or of an application / security context in a subsequent application protocol " [ Section 3.4.1 ] " EDHOC transports that do not inherently provide correlation across all messages of an exchange " can be rephrased as : " Transports that do not inherently provide correlation across all EDHOC messages of an exchange " [ Section 3.5.1 ] " The EDHOC implementation or the application must enforce information about ... " can be rephrased as : " The EDHOC implementation or the application must take a decision on allowing or not a connection based on information about ... " s / if it is allowed to communicate with / if it is allowed to communicate with those [ Section 4.3 ] The context can for example be the empty ( zero - length ) sequence or a single CBOR byte string . Is n't the context supposed to be just a single CBOR byte string ? See how it is defined in Section 4.2 when introducing Expand . s / where H ( ) is the hash function / where H ( ) is the EDHOC hash algorithm [ Section 5.1 ] s / a second time for EDHOC processing / a second time for EDHOC processing within the same ongoing session [ Section 5.2.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 5.3.1 ] " GY , the ephemeral public key of the Responder , and ... " Just to avoid any risk to interpret this as the concatenation of three elements , I suggest to rephrase as : " GY ( i.e. , the ephemeral public key of the Responder ) and ... " [ Section 5.3.2 ] s / H ( ) is the hash function in / H ( ) is the EDHOC hash algorithm in " is the ' signature ' field of a COSESign1 object as defined in Section 4 of [ I - D.ietf - cose - rfc8152bis - struct ] using the signature algorithm ... " should be rephrased as : " is the ' signature ' field of a COSESign1 object as defined in Section 4.2 of [ I - D.ietf - cose - rfc8152bis - struct ] , computed as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... " [ Section 5.3.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 5.4.2 ] s / H ( ) is the hash function in / H ( ) is the EDHOC hash algorithm in " is the ' signature ' field of a COSESign1 object as defined in Section 4 of [ I - D.ietf - cose - rfc8152bis - struct ] using the signature algorithm ... " should be rephrased as : " is the ' signature ' field of a COSESign1 object as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] , computed as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... " s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] [ Section 5.4.3 ] s / or the prepended  / or the prepended CR s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? s / no other party than the Responder / no other party than the Initiator [ Section 5.5 ] " In deployments where no protected application message is sent from the Responder to the Initiator , the Responder  send  . " Consider to rephrase as : " In deployments where no protected application message is sent from the Responder to the Initiator ,  MUST be supported and the Responder  send message4 " [ Section 5.5.2 ] s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] [ Section 5.5.3 ] s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 6 ] s / error SHALL be / An error message SHALL be [ Section 6.3 ] " Error code 2 MUST only be used in a response to message1 ... " can be rephrased as : " Error code 2 MUST only be used when replying to message1 " , avoiding to use words like " request " and " response " . [ Section 6.3.2 ] s / the Responder shall only accept  if / the Responder SHALL accept  only if The last two paragraph are not further comments on the examples , but are rather related to the cipher suite negotiation . I think they better fit as last paragraphs of Section 6.3.1 . [ Section 8 ] " Compromise of PRK4x3 m leads to compromise of all exported keying material derived after the last invocation of the EDHOC - KeyUpdate function . " I suggest to expand as follows : " Compromise of PRK4x3 m leads to compromise of all exported keying material derived from that key through the EDHOC - Exporter function . If the EDHOC - KeyUpdate function has been used to renew PRK4x3 m , the compromise is limited to the exported keying material derived from the PRK4x3 m installed after the last invocation of the EDHOC - KeyUpdate function . " [ Section 8.6 ] The way the first paragraph starts is probably a remnant of when CoAP was still part of the document body rather than in    , as later discussed in Appendix A.3 , the Echo exchange is started by a CoAP server , regardless if it acts exactly as Responder . I suggest to rephrase the paragraph as follows . " EDHOC itself does not provide countermeasures against Denial - of - Service attacks . In particular , by sending a number of new or replayed  an attacker may cause the Responder to allocate state , perform cryptographic operations , and amplify messages . To mitigate such attacks , an implementation SHOULD rely on lower layer mechanisms . For instance , when EDHOC is transferred as an exchange of CoAP messages , the CoAP server can use the Echo option defined in [ I - D.ietf - core - echo - request - tag ] , which forces the CoAP client to demonstrate its reachability at its apparent network address . " [ 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 . [ Appendix A.3 ] " EDHOC message2 or the EDHOC error message is sent from the server to the client in the payload of a 2.04 ( Changed ) response . EDHOC message3 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  A.3.1 . The text above can rather , more generically , be : " The server sends to the client EDHOC message2 in the payload of a 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 message3 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 . " [ Appendix A.3.1 ] The last sentence can be extended , to mention what additionally is defined in draft - ietf - core - oscore - edhoc , besides the EDHOC+OSCORE request . This includes especially : a deterministic and efficient conversion from OSCORE Sender / Recipient IDs to EDHOC connection identifiers ; web - linking and target attributes for discovering of EDHOC resources . [ Nits ] Three instances of " key material " should be " keying material " for consistency . Section 3.3.1 , s / and sends in message2 / and sends it in message2 Section 3.3.2 , s / and a EDHOC connection / and an EDHOC connection Section 3.6 --- s / pre - defined int label / pre - defined integer label --- s / Implementation can either use / Implementations can either use Section 3.7 , s / requires an ' y ' parameter / requires a ' y ' parameter Section 3.8 , s / protected out of scope of EDHOC / whose protection is out of the scope of EDHOC Section 3.9 --- s / verifying cipher suite / verifying a cipher suite --- s / know identity of Responder / know identity of the Responder --- s / know identity of Initiator / know identity of the Initiator Section 4.3 , s / same key kan be / same key can be Section 5.1 , s / then process according to Section 6 , else process as / then process it according to Section 6 , else process it as Section 5.3.2 , s / facilitate retrieval of / facilitate the retrieval of Section 5.4.2 --- s / facilitate retrieval of / facilitate the retrieval of --- s / intialization vector / initialization vector --- s / or derived application keys / or derive application keys Section 5.4.2 , s / intialization vector / initialization vector Section 6.3.2 , s / then Responder  discontinue / then the Responder MUST discontinue Section 8 , s / protection is provided / protection are provided Section 8.2 --- s / and instead rely / and instead relies --- s / the Responders identity / the Responder 's identity --- s / Requirement for how / Requirements for how Section 8.6 --- s / forces the initiator / forces the Initiator Section 9.6 , s / an CWT Claims Set / a CWT Claims Set Section 9.14 , s / is defined as / are defined as Appendix A.3 , s / using resource directory / using a resource directory Appendix B , s / compatibily / compatibility Appendix C.1 , s / dignostic / diagnostic Appendix E --- s / which does not handle / which do not handle --- s / with respect the current / with respect to the current   , s / for message 1 / for message_1 
 [ Nits ] fixed in 
 review comments with small changes fixed in . The following was fixed : [ Section 1.3 ] s / the number of bytes in EDHOC + CoAP can be / the EDHOC message size in bytes when transferred in CoAP can be NEW the EDHOC message size when transferred in CoAP can be [ Section 1.5 ] " and CDDL [ RFC8610 ] . The Concise Data Definition Language ( CDDL ) is used to express CBOR data structures [ RFC8949 ] " can be rephrased as : " and the Concise Data Definition Language ( CDDL ) [ RFC8610 ] , which is used to express CBOR data structures [ RFC8949 ] " NEW and the Concise Data Definition Language ( CDDL , { { RFC8610 } } ) , which is used to express CBOR data structures . [ Section 2 ] " Verification of a common preferred cipher suite " Should n't this say : " Verification of a commonly supported cipher suite which is most preferred by the Initiator " ? NEW Verification of the selected cipher suite . [ Section 3.2 ] In Figure 4 , the second and third column can rather have labels " Initiator Authentication Key " and " Responder Authentication Key " . NEW ~~ { : #  - method - types title="Authentication Keys for Method Types " } { : artwork - align="center " } [ Section 3.3 ] " or in a subsequent application protocol " can be expanded as : " or of an application / security context in a subsequent application protocol " NEW < not done , did not see any reason to change this[Section 3.4.1 ] " EDHOC transports that do not inherently provide correlation across all messages of an exchange " can be rephrased as : " Transports that do not inherently provide correlation across all EDHOC messages of an exchange " NEW < changed as proposed[Section 3.5.1 ] s / if it is allowed to communicate with / if it is allowed to communicate with those OLD each party needs to have a trusted third party public key as trust anchor to verify the end - entity CWTs , and a specific identity or set of identities in the ' sub ' ( subject ) claim of the CWT to determine if it is allowed to communicate with . NEW each party needs to have a trusted third party public key as trust anchor to verify the end - entity CWTs , and a specific identity or set of identities to verify the ' sub ' ( subject ) claim of the CWT . [ Section 4.3 ] , [ Section 5.3.2 ] , [ Section 5.4.2 ] s / where H ( ) is the hash function / where H ( ) is the EDHOC hash algorithm NEW < changed as proposed[Section 5.1 ] s / a second time for EDHOC processing / a second time for EDHOC processing within the same ongoing session NEW < changed as proposed[Section 5.3.1 ] " GY , the ephemeral public key of the Responder , and ... " Just to avoid any risk to interpret this as the concatenation of three elements , I suggest to rephrase as : " GY ( i.e. , the ephemeral public key of the Responder ) and ... " NEW < changed as proposed[Section 5.3.2 ] " is the ' signature ' field of a COSESign1 object as defined in Section 4 of [ I - D.ietf - cose - rfc8152bis - struct ] using the signature algorithm ... " should be rephrased as : " is the ' signature ' field of a COSESign1 object as defined in Section 4.2 of [ I - D.ietf - cose - rfc8152bis - struct ] , computed as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... " NEW is the ' signature ' field of a COSESign1 object , computed as specified in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... [ Section 5.4.2 ] " is the ' signature ' field of a COSESign1 object as defined in Section 4 of [ I - D.ietf - cose - rfc8152bis - struct ] using the signature algorithm ... " should be rephrased as : " is the ' signature ' field of a COSESign1 object as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] , computed as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... " s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] NEW is the ' signature ' field of a COSESign1 object , computed as specified in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... [ Section 5.4.3 ] s / or the prepended  / or the prepended CR NEW < changed as proposeds / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] NEW < changed as proposed[Section 5.5.2 ] s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] NEW < changed as proposed[Section 5.5 ] " In deployments where no protected application message is sent from the Responder to the Initiator , the Responder  send  . " Consider to rephrase as : " In deployments where no protected application message is sent from the Responder to the Initiator ,  MUST be supported and the Responder  send message4 " NEW < changed as proposed[Section 5.5.3 ] s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] NEW < changed as proposed[Section 6 ] s / error SHALL be / An error message SHALL be NEW < no change , ' error ' refers to name of data structure[Section 6.3 ] " Error code 2 MUST only be used in a response to message1 ... " can be rephrased as : " Error code 2 MUST only be used when replying to message1 " , avoiding to use words like " request " and " response " . NEW < changed as proposed[Section 6.3.2 ] s / the Responder shall only accept  if / the Responder SHALL accept  only if NEW < changed as proposedThe last two paragraph are not further comments on the examples , but are rather related to the cipher suite negotiation . I think they better fit as last paragraphs of Section 6.3.1 . NEW < changed as proposed[Section 8.6 ] The way the first paragraph starts is probably a remnant of when CoAP was still part of the document body rather than in    , as later discussed in Appendix A.3 , the Echo exchange is started by a CoAP server , regardless if it acts exactly as Responder . I suggest to rephrase the paragraph as follows . " EDHOC itself does not provide countermeasures against Denial - of - Service attacks . In particular , by sending a number of new or replayed  an attacker may cause the Responder to allocate state , perform cryptographic operations , and amplify messages . To mitigate such attacks , an implementation SHOULD rely on lower layer mechanisms . For instance , when EDHOC is transferred as an exchange of CoAP messages , the CoAP server can use the Echo option defined in [ I - D.ietf - core - echo - request - tag ] , which forces the CoAP client to demonstrate its reachability at its apparent network address . " NEW < changed as proposedminus one instance of " its " [ Appendix A.3 ] " EDHOC message2 or the EDHOC error message is sent from the server to the client in the payload of a 2.04 ( Changed ) response . EDHOC message3 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  A.3.1 . The text above can rather , more generically , be : " The server sends to the client EDHOC message2 in the payload of a 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 message3 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 . " NEW The server sends to the client EDHOC message2 in the payload of a 2.04 ( Changed ) response , or an EDHOC error message in the payload of a response . If there is an error , then 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 message3 in the payload of a POST request . If there is an error , then the server sends to the client an EDHOC error message in the payload of a response . [ Appendix A.3.1 ] The last sentence can be extended , to mention what additionally is defined in draft - ietf - core - oscore - edhoc , besides the EDHOC+OSCORE request . This includes especially : a deterministic and efficient conversion from OSCORE Sender / Recipient IDs to EDHOC connection identifiers ; web - linking and target attributes for discovering of EDHOC resources . NEW That specification also contains conversion from OSCORE Sender / Recipient IDs to EDHOC connection identifiers , web - linking and target attributes for discovering of EDHOC resources . 
 Remaining comments not addressed . [ Section 1.1 ] " This specification focuses on referencing instead of transporting credentials to reduce message overhead . " It is possible to transport credentials both by reference and by value . What suggests the case of transport by reference to be the " focus " ? Perhaps you mean that it is possible and preferable / recommended to transport credentials by reference ? " future algorithms and credentials targeting IoT " This probably means " future algorithms and identity credential types targeting IoT " . s / compromise of the long - term keys / compromise of the long - term identity keys [ Section 3.5.1 ] " The EDHOC implementation or the application must enforce information about ... " can be rephrased as : " The EDHOC implementation or the application must take a decision on allowing or not a connection based on information about ... " [ Section 4.3 ] The context can for example be the empty ( zero - length ) sequence or a single CBOR byte string . Is n't the context supposed to be just a single CBOR byte string ? See how it is defined in Section 4.2 when introducing Expand . [ Section 5.2.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 5.3.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 5.4.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? s / no other party than the Responder / no other party than the Initiator [ Section 5.5.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 8 ] " Compromise of PRK4x3 m leads to compromise of all exported keying material derived after the last invocation of the EDHOC - KeyUpdate function . " I suggest to expand as follows : " Compromise of PRK4x3 m leads to compromise of all exported keying material derived from that key through the EDHOC - Exporter function . If the EDHOC - KeyUpdate function has been used to renew PRK4x3 m , the compromise is limited to the exported keying material derived from the PRK4x3 m installed after the last invocation of the EDHOC - KeyUpdate function . " [ 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 . 
  confirmed that comments are addressed 
 " By default , the message flow is as follows : " Text misses error as a result from 4 , that is not very default , but none of the error are .... " but intended to enable the use short identifiers in combination with simplifying the retrieval of the right security context in the application protocol . " of in " the use short " is missing Why would " enable " be better than " simplify " ? Do n't remember what EDHOC says , but simplify is absolutely a better word than enable for the use in COSE / OSCORE . Retrieval of the right security context is also for EDHOC . This change remove that by specifying " application protocol " . " identities to verify the ' sub ' ( subject ) claim of the CWT . " Should use the same text for X509 and CWT . Not in this PR , but " sub " claim is just an example . CTW might add AltSub in the future . "  MUST be supported and the Responder  send  . " Good change , but the " Responder  send  " is still strange , would about I ? Maybe just " message4 MUST be used " ?
Mailing list commentary: Hi all , As promised , please find below my review of EDHOC v -12 . Best , /Marco = = = = = = = = = = = = = [ Section 1.1 ] " This specification focuses on referencing instead of transporting credentials to reduce message overhead . " It is possible to transport credentials both by reference and by value . What suggests the case of transport by reference to be the " focus " ? Perhaps you mean that it is possible and preferable / recommended to transport credentials by reference ? " future algorithms and credentials targeting IoT " This probably means " future algorithms and identity credential types targeting IoT " . s / compromise of the long - term keys / compromise of the long - term identity keys [ Section 1.3 ] s / the number of bytes in EDHOC + CoAP can be / the EDHOC message size in bytes when transferred in CoAP can be [ Section 1.5 ] " and CDDL [ RFC8610 ] . The Concise Data Definition Language ( CDDL ) is used to express CBOR data structures [ RFC8949 ] " can be rephrased as : " and the Concise Data Definition Language ( CDDL ) [ RFC8610 ] , which is used to express CBOR data structures [ RFC8949 ] " [ Section 2 ] " Verification of a common preferred cipher suite " Should n't this say : " Verification of a commonly supported cipher suite which is most preferred by the Initiator " ? [ Section 3.2 ] In Figure 4 , the second and third column can rather have labels " Initiator Authentication Key " and " Responder Authentication Key " . [ Section 3.3 ] " or in a subsequent application protocol " can be expanded as : " or of an application / security context in a subsequent application protocol " [ Section 3.4.1 ] " EDHOC transports that do not inherently provide correlation across all messages of an exchange " can be rephrased as : " Transports that do not inherently provide correlation across all EDHOC messages of an exchange " [ Section 3.5.1 ] " The EDHOC implementation or the application must enforce information about ... " can be rephrased as : " The EDHOC implementation or the application must take a decision on allowing or not a connection based on information about ... " s / if it is allowed to communicate with / if it is allowed to communicate with those [ Section 4.3 ] The context can for example be the empty ( zero - length ) sequence or a single CBOR byte string . Is n't the context supposed to be just a single CBOR byte string ? See how it is defined in Section 4.2 when introducing Expand . s / where H ( ) is the hash function / where H ( ) is the EDHOC hash algorithm [ Section 5.1 ] s / a second time for EDHOC processing / a second time for EDHOC processing within the same ongoing session [ Section 5.2.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 5.3.1 ] " GY , the ephemeral public key of the Responder , and ... " Just to avoid any risk to interpret this as the concatenation of three elements , I suggest to rephrase as : " GY ( i.e. , the ephemeral public key of the Responder ) and ... " [ Section 5.3.2 ] s / H ( ) is the hash function in / H ( ) is the EDHOC hash algorithm in " is the ' signature ' field of a COSESign1 object as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] using the signature algorithm ... " should be rephrased as : " is the ' signature ' field of a COSESign1 object as defined in Section 4.2 of [ I - D.ietf - cose - rfc8152bis - struct ] , computed as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... " [ Section 5.3.3 ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 5.4.2 ] s / H ( ) is the hash function in / H ( ) is the EDHOC hash algorithm in " is the ' signature ' field of a COSESign1 object as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] using the signature algorithm ... " should be rephrased as : " is the ' signature ' field of a COSESign1 object as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] , computed as defined in Section 4.4 of [ I - D.ietf - cose - rfc8152bis - struct ] by using the signature algorithm ... " s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] [ Section 5.4.3 ] s / or the prepended  / or the prepended CR s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? s / no other party than the Responder / no other party than the Initiator [ Section 5.5 ] " In deployments where no protected application message is sent from the Responder to the Initiator , the Responder send  . " Consider to rephrase as : " In deployments where no protected application message is sent from the Responder to the Initiator ,  MUST be supported and the Responder send message4 " [ Section 5.5.2 ] s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] [ Section 5.5.3 ] s / as defined in Section 5.3 of [ I - D.ietf - cose - rfc8152bis - struct]/as defined in Sections 5.2 and 5.3 of [ I - D.ietf - cose - rfc8152bis - struct ] " If an error message is sent , the session MUST be discontinued . " Is this sentence actually required ? Regardless sending an error message or not , the session is discontinued if any processing step fails , which is the reason for possibly sending an error message . Or are there situations where an error message is sent even if no processing step fails ? [ Section 6 ] s / error SHALL be / An error message SHALL be [ Section 6.3 ] " Error code 2 MUST only be used in a response to message1 ... " can be rephrased as : " Error code 2 MUST only be used when replying to message1 " , avoiding to use words like " request " and " response " . [ Section 6.3.2 ] s / the Responder shall only accept  if / the Responder SHALL accept  only if The last two paragraph are not further comments on the examples , but are rather related to the cipher suite negotiation . I think they better fit as last paragraphs of Section 6.3.1 . [ Section 8 ] " Compromise of PRK4x3 m leads to compromise of all exported keying material derived after the last invocation of the EDHOC - KeyUpdate function . " I suggest to expand as follows : " Compromise of PRK4x3 m leads to compromise of all exported keying material derived from that key through the EDHOC - Exporter function . If the EDHOC - KeyUpdate function has been used to renew PRK4x3 m , the compromise is limited to the exported keying material derived from the PRK4x3 m installed after the last invocation of the EDHOC - KeyUpdate function . " [ Section 8.6 ] The way the first paragraph starts is probably a remnant of when CoAP was still part of the document body rather than in , as later discussed in Appendix A.3 , the Echo exchange is started by a CoAP server , regardless if it acts exactly as Responder . I suggest to rephrase the paragraph as follows . " EDHOC itself does not provide countermeasures against Denial - of - Service attacks . In particular , by sending a number of new or replayed  an attacker may cause the Responder to allocate state , perform cryptographic operations , and amplify messages . To mitigate such attacks , an implementation SHOULD rely on lower layer mechanisms . For instance , when EDHOC is transferred as an exchange of CoAP messages , the CoAP server can use the Echo option defined in [ I - D.ietf - core - echo - request - tag ] , which forces the CoAP client to demonstrate its reachability at its apparent network address . " [ 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 . [ Appendix A.3 ] " EDHOC message2 or the EDHOC error message is sent from the server to the client in the payload of a 2.04 ( Changed ) response . EDHOC message3 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 A.3.1 . The text above can rather , more generically , be : " The server sends to the client EDHOC message2 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 message3 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 . " [ Appendix A.3.1 ] The last sentence can be extended , to mention what additionally is defined in draft - ietf - core - oscore - edhoc , besides the EDHOC+OSCORE request . This includes especially : a deterministic and efficient conversion from OSCORE Sender / Recipient IDs to EDHOC connection identifiers ; web - linking and target attributes for discovering of EDHOC resources . [ Nits ] Three instances of " key material " should be " keying material " for consistency . Section 3.3.1 , s / and sends in message2 / and sends it in message2 Section 3.3.2 , s / and a EDHOC connection / and an EDHOC connection Section 3.6 --- s / pre - defined int label / pre - defined integer label --- s / Implementation can either use / Implementations can either use Section 3.7 , s / requires an ' y ' parameter / requires a ' y ' parameter Section 3.8 , s / protected out of scope of EDHOC / whose protection is out of the scope of EDHOC Section 3.9 --- s / verifying cipher suite / verifying a cipher suite --- s / know identity of Responder / know identity of the Responder --- s / know identity of Initiator / know identity of the Initiator Section 4.3 , s / same key kan be / same key can be Section 5.1 , s / then process according to Section 6 , else process as / then process it according to Section 6 , else process it as Section 5.3.2 , s / facilitate retrieval of / facilitate the retrieval of Section 5.4.2 --- s / facilitate retrieval of / facilitate the retrieval of --- s / intialization vector / initialization vector --- s / or derived application keys / or derive application keys Section 5.4.2 , s / intialization vector / initialization vector Section 6.3.2 , s / then Responder discontinue / then the Responder MUST discontinue Section 8 , s / protection is provided / protection are provided Section 8.2 --- s / and instead rely / and instead relies --- s / the Responders identity / the Responder 's identity --- s / Requirement for how / Requirements for how Section 8.6 --- s / forces the initiator / forces the Initiator Section 9.6 , s / an CWT Claims Set / a CWT Claims Set Section 9.14 , s / is defined as / are defined as Appendix A.3 , s / using resource directory / using a resource directory Appendix B , s / compatibily / compatibility Appendix C.1 , s / dignostic / diagnostic Appendix E --- s / which does not handle / which do not handle --- s / with respect the current / with respect to the current , s / for message 1 / for message_1
Paragraph (version A):
Some security solutions for such settings exist already.  CBOR Object
Signing and Encryption (COSE, I-D.ietf-cose-rfc8152bis-struct)
specifies basic application-layer security services efficiently
encoded in CBOR.  Another example is Object Security for Constrained
RESTful Environments (OSCORE, RFC8613) which is a lightweight
communication security extension to CoAP using CBOR and COSE.  In
order to establish good quality cryptographic keys for security
protocols such as COSE and OSCORE, the two endpoints may run an
authenticated Diffie-Hellman key exchange protocol, from which shared
secret key material can be derived.  Such a key exchange protocol
should also be lightweight; to prevent bad performance in case of
repeated use, e.g., due to device rebooting or frequent rekeying for
security reasons; or to avoid latencies in a network formation
setting with many devices authenticating at the same time.
Paragraph (version B):
Some security solutions for such settings exist already.  CBOR Object
Signing and Encryption (COSE, I-D.ietf-cose-rfc8152bis-struct)
specifies basic application-layer security services efficiently
encoded in CBOR.  Another example is Object Security for Constrained
RESTful Environments (OSCORE, RFC8613) which is a lightweight
communication security extension to CoAP using CBOR and COSE.  In
order to establish good quality cryptographic keys for security
protocols such as COSE and OSCORE, the two endpoints may run an
authenticated Diffie-Hellman key exchange protocol, from which shared
secret keying material can be derived.  Such a key exchange protocol
should also be lightweight; to prevent bad performance in case of
repeated use, e.g., due to device rebooting or frequent rekeying for
security reasons; or to avoid latencies in a network formation
setting with many devices authenticating at the same time.
Paragraph (version A):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including forward secrecy, identity protection,
and cipher suite negotiation.  Authentication can be based on raw
public keys (RPK) or public key certificates and requires the
application to provide input on how to verify that endpoints are
trusted.  This specification focuses on referencing instead of
transporting credentials to reduce message overhead.  EDHOC does not
currently support pre-shared key (PSK) authentication as
authentication with static Diffie-Hellman public keys by reference
produces equally small message sizes but with much simpler key
distribution and identity protection.
Paragraph (version A):
EDHOC makes use of known protocol constructions, such as SIGMA SIGMA
and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and
identification of credentials (including COSE_Key, CWT, CCS, X.509,
C509, see auth-cred).  COSE provides crypto agility and enables the
use of future algorithms and credentials targeting IoT.
Paragraph (version B):
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
lightweight authenticated key exchange protocol providing good
security properties including forward secrecy, identity protection,
and cipher suite negotiation.  Authentication can be based on raw
public keys (RPK) or public key certificates and requires the
application to provide input on how to verify that endpoints are
trusted.  This specification emphasizes the possibility to reference
rather than to transport credentials in order to reduce message
overhead, but the latter is also supported.  EDHOC does not currently
support pre-shared key (PSK) authentication as authentication with
static Diffie-Hellman public keys by reference produces equally small
message sizes but with much simpler key distribution and identity
protection.
Paragraph (version B):
EDHOC makes use of known protocol constructions, such as SIGMA SIGMA
and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and
identification of credentials (including COSE_Key, CWT, CCS, X.509,
C509, see auth-cred).  COSE provides crypto agility and enables the
use of future algorithms and credential types targeting IoT.
Paragraph (version A):
Compared to the DTLS 1.3 handshake I-D.ietf-tls-dtls13 with ECDHE and
connection ID, the number of bytes in EDHOC + CoAP can be less than
1/6 when RPK authentication is used, see I-D.ietf-lwig-security-
protocol-comparison. fig-sizes shows examples of message sizes for
EDHOC with different kinds of authentication keys and different COSE
header parameters for identification: static Diffie-Hellman keys or
signature keys, either in CBOR Web Token (CWT) / CWT Claims Set (CCS)
RFC8392 identified by a key identifier using 'kid' I-D.ietf-cose-
rfc8152bis-struct, or in X.509 certificates identified by a hash
value using 'x5t' I-D.ietf-cose-x509.
Paragraph (version B):
Compared to the DTLS 1.3 handshake I-D.ietf-tls-dtls13 with ECDHE and
connection ID, the EDHOC message size when transferred in CoAP can be
less than 1/6 when RPK authentication is used, see I-D.ietf-lwig-
security-protocol-comparison. fig-sizes shows examples of message
sizes for EDHOC with different kinds of authentication keys and
different COSE header parameters for identification: static Diffie-
Hellman keys or signature keys, either in CBOR Web Token (CWT) / CWT
Claims Set (CCS) RFC8392 identified by a key identifier using 'kid'
I-D.ietf-cose-rfc8152bis-struct, or in X.509 certificates identified
by a hash value using 'x5t' I-D.ietf-cose-x509.
Paragraph (version A):
Readers are expected to be familiar with the terms and concepts
described in CBOR RFC8949, CBOR Sequences RFC8742, COSE structures
and processing I-D.ietf-cose-rfc8152bis-struct, COSE algorithms I-
D.ietf-cose-rfc8152bis-algs, CWT and CWT Claims Set RFC8392, and CDDL
RFC8610.  The Concise Data Definition Language (CDDL) is used to
express CBOR data structures RFC8949.  Examples of CBOR and CDDL are
provided in CBOR.  When referring to CBOR, this specification always
refers to Deterministically Encoded CBOR as specified in Sections
encryption (including the authentication tag) is called "ciphertext",
following RFC5116.
Paragraph (version B):
Readers are expected to be familiar with the terms and concepts
described in CBOR RFC8949, CBOR Sequences RFC8742, COSE structures
and processing I-D.ietf-cose-rfc8152bis-struct, COSE algorithms I-
D.ietf-cose-rfc8152bis-algs, CWT and CWT Claims Set RFC8392, and the
Concise Data Definition Language (CDDL, RFC8610), which is used to
express CBOR data structures.  Examples of CBOR and CDDL are provided
in CBOR.  When referring to CBOR, this specification always refers to
Deterministically Encoded CBOR as specified in Sections 4.2.1 and
(including the authentication tag) is called "ciphertext", following
RFC5116.
Paragraph (version A):
A key material exporter and a key update function with forward
secrecy.
Paragraph (version A):
Verification of a common preferred cipher suite.
Paragraph (version B):
A keying material exporter and a key update function with forward
secrecy.
Paragraph (version B):
Verification of the selected cipher suite.
Paragraph (version A):
Connection identifiers may be used to correlate EDHOC messages and
facilitate the retrieval of protocol state during EDHOC protocol
execution (see transport) or in a subsequent application protocol,
e.g., OSCORE (see ci-oscore).  The connection identifiers do not have
any cryptographic purpose in EDHOC.
Paragraph (version B):
Connection identifiers may be used to correlate EDHOC messages and
facilitate the retrieval of protocol state during EDHOC execution
(see transport) or in subsequent applications of EDHOC, e.g., in
OSCORE (see ci-oscore).  The connection identifiers do not have any
cryptographic purpose in EDHOC.
Paragraph (version A):
C_I and C_R are chosen by I and R, respectively.  The Initiator
selects C_I and sends it in message_1 for the Responder to use as a
reference to the connection in communications with the Initiator.
The Responder selects C_R and sends in message_2 for the Initiator to
use as a reference to the connection in communications with the
Responder.
Paragraph (version B):
C_I and C_R are chosen by I and R, respectively.  The Initiator
selects C_I and sends it in message_1 for the Responder to use as a
reference to the connection in communications with the Initiator.
The Responder selects C_R and sends it in message_2 for the Initiator
to use as a reference to the connection in communications with the
Responder.
Paragraph (version A):
For OSCORE, the choice of a connection identifier results in the
endpoint selecting its Recipient ID, see Section 3.1 of RFC8613, for
which certain uniqueness requirements apply, see Section 3.3 of
RFC8613.  Therefore, the Initiator and the Responder MUST NOT select
connection identifiers such that it results in same OSCORE Recipient
ID.  Since the Recipient ID is a byte string and a EDHOC connection
identifier is either a CBOR byte string or a CBOR integer, care must
be taken when selecting the connection identifiers and converting
them to Recipient IDs.  A mapping from EDHOC connection identifier to
OSCORE Recipient ID is specified in edhoc-to-oscore.
Paragraph (version B):
For OSCORE, the choice of a connection identifier results in the
endpoint selecting its Recipient ID, see Section 3.1 of RFC8613, for
which certain uniqueness requirements apply, see Section 3.3 of
RFC8613.  Therefore, the Initiator and the Responder MUST NOT select
connection identifiers such that it results in same OSCORE Recipient
ID.  Since the Recipient ID is a byte string and an EDHOC connection
identifier is either a CBOR byte string or a CBOR integer, care must
be taken when selecting the connection identifiers and converting
them to Recipient IDs.  A mapping from EDHOC connection identifier to
OSCORE Recipient ID is specified in edhoc-to-oscore.
Paragraph (version A):
The transport needs to support the correlation between EDHOC messages
and facilitate the retrieval of protocol state during EDHOC protocol
execution, including an indication of a message being message_1.  The
correlation may reuse existing mechanisms in the transport protocol.
For example, the CoAP Token may be used to correlate EDHOC messages
in a CoAP response and an associated CoAP request.
Paragraph (version A):
Connection identifiers may be used to correlate EDHOC messages and
facilitate the retrieval of protocol state during EDHOC protocol
execution.  EDHOC transports that do not inherently provide
correlation across all messages of an exchange can send connection
identifiers along with EDHOC messages to gain that required
capability, e.g., by prepending the appropriate connection identifier
(when available from the EDHOC protocol) to the EDHOC message.
Transport of EDHOC in CoAP payloads is described in coap, which also
shows how to use connection identifiers and message_1 indication with
CoAP.
Paragraph (version B):
The transport needs to support the correlation between EDHOC messages
and facilitate the retrieval of protocol state and security context
during EDHOC protocol execution, including an indication of a message
being message_1.  The correlation may reuse existing mechanisms in
the transport protocol.  For example, the CoAP Token may be used to
correlate EDHOC messages in a CoAP response and an associated CoAP
request.
Paragraph (version B):
Connection identifiers may be used to correlate EDHOC messages and
facilitate the retrieval of protocol state/security context during
EDHOC protocol execution.  Transports that do not inherently provide
correlation across all EDHOC messages of an exchange can send
connection identifiers along with EDHOC messages to gain that
required capability, e.g., by prepending the appropriate connection
identifier (when available from the EDHOC protocol) to the EDHOC
message.  Transport of EDHOC in CoAP payloads is described in coap,
which also shows how to use connection identifiers and message_1
indication with CoAP.
Paragraph (version A):
The EDHOC implementation or the application must enforce information
about the intended endpoint, and in particular whether it is a
specific identity or a set of identities.  Either EDHOC passes
information about identity to the application for a decision, or
EDHOC needs to have access to relevant information and makes the
decision on its own.
Paragraph (version B):
The EDHOC implementation or the application must decide on allowing a
connection or not depending on the intended endpoint, and in
particular whether it is a specific identity or a set of identities.
Either EDHOC passes information about identity to the application for
a decision, or EDHOC needs to have access to relevant information and
makes the decision on its own.
Paragraph (version A):
Similarly, when a PKI is used with CWTs, each party needs to have
a trusted third party public key as trust anchor to verify the
end-entity CWTs, and a specific identity or set of identities in
the 'sub' (subject) claim of the CWT to determine if it is allowed
to communicate with.  The trusted third party public key can,
e.g., be stored in a self-signed CWT or in a CCS.
Paragraph (version B):
Similarly, when a PKI is used with CWTs, each party needs to have
at least one trusted third party public key as trust anchor to
verify the end-entity CWTs, and a specific identity or set of
identities it is allowed to communicate with to match against the
relevant claim, such as 'sub' (subject).  The trusted third party
public key can, e.g., be stored in a self-signed CWT or in a CCS.
Paragraph (version A):
Each cipher suite is identified with a pre-defined int label.
Paragraph (version B):
Each cipher suite is identified with a pre-defined integer label.
Paragraph (version A):
The ephemeral public keys in EDHOC (G_X and G_Y) use compact
representation of elliptic curve points, see comrep.  In COSE compact
representation is achieved by formatting the ECDH ephemeral public
keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and
parameter in G_X and G_Y.  For Elliptic Curve Keys of type EC2,
compact representation MAY be used also in the COSE_Key.  If the COSE
implementation requires an 'y' parameter, the value y = false SHALL
be used.  COSE always use compact output for Elliptic Curve Keys of
type EC2.
Paragraph (version B):
The ephemeral public keys in EDHOC (G_X and G_Y) use compact
representation of elliptic curve points, see comrep.  In COSE compact
representation is achieved by formatting the ECDH ephemeral public
keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and
parameter in G_X and G_Y.  For Elliptic Curve Keys of type EC2,
compact representation MAY be used also in the COSE_Key.  If the COSE
implementation requires a 'y' parameter, the value y = false SHALL be
used.  COSE always use compact output for Elliptic Curve Keys of type
EC2.
Paragraph (version A):
In order to reduce round trips and number of messages or to simplify
processing, external security applications may be integrated into
EDHOC by transporting authorization related data in the messages.
One example is third-party identity and authorization information
protected out of scope of EDHOC I-D.selander-ace-ake-authz.  Another
example is a certificate enrollment request or the resulting issued
certificate.
Paragraph (version B):
In order to reduce round trips and number of messages or to simplify
processing, external security applications may be integrated into
EDHOC by transporting authorization related data in the messages.
One example is third-party identity and authorization information
whose protection is out of scope of EDHOC I-D.selander-ace-ake-authz.
Another example is a certificate enrollment request or the resulting
issued certificate.
Paragraph (version A):
Identifier used as identity of endpoint; see identities.
Paragraph (version A):
The applicability statement may also contain information about
supported cipher suites.  The procedure for selecting and verifying
cipher suite is still performed as described in asym-msg1-form and
wrong-selected, but it may become simplified by this knowledge.
Paragraph (version B):
Identifier used as the identity of the endpoint; see identities.
Paragraph (version B):
The applicability statement may also contain information about
supported cipher suites.  The procedure for selecting and verifying a
cipher suite is still performed as described in asym-msg1-form and
wrong-selected, but it may become simplified by this knowledge.
Paragraph (version A):
where label is a registered tstr from the EDHOC Exporter Label
registry (exporter-label), context is a bstr defined by the
application, and length is a uint defined by the application.  The
(label, context) pair must be unique, i.e., a (label, context) MUST
NOT be used for two different purposes.  However an application can
re-derive the same key several times as long as it is done in a
secure way.  For example, in most encryption algorithms the same key
can be reused with different nonces.  The context can for example be
the empty (zero-length) sequence or a single CBOR byte string.
Paragraph (version A):
where H() is the hash function in the selected cipher suite.
Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and
transfer.
Paragraph (version B):
where label is a registered tstr from the EDHOC Exporter Label
registry (exporter-label), context is a bstr defined by the
application, and length is a uint defined by the application.  The
(label, context) pair must be unique, i.e., a (label, context) MUST
NOT be used for two different purposes.  However an application can
re-derive the same key several times as long as it is done in a
secure way.  For example, in most encryption algorithms the same key
can be reused with different nonces.  The context can for example be
the empty CBOR byte string.
Paragraph (version B):
where H() is the EDHOC hash algorithm in the selected cipher suite.
Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and
transfer.
Paragraph (version A):
If the message received is an error message, then process
according to error, else process as the expected next message
according to the protocol state.
Paragraph (version B):
If the message received is an error message, then process it
according to error, else process it as the expected next message
according to the protocol state.
Paragraph (version A):
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 because the state of the protocol
has moved on and now expects something else.  This assumes that
message duplication due to re-transmissions is handled by the
transport protocol, see transport.  The case when the transport does
not support message deduplication is addressed in duplication.
Paragraph (version B):
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.
This assumes that message duplication due to re-transmissions is
handled by the transport protocol, see transport.  The case when the
transport does not support message deduplication is addressed in
duplication.
Paragraph (version A):
Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R )
where H() is the hash function in the selected cipher suite.  The
transcript hash TH_2 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence.  Note that H(message_1) can be
computed and cached already in the processing of message_1.
Paragraph (version B):
Compute the transcript hash TH_2 = H( H(message_1), G_Y, C_R )
where H() is the EDHOC hash algorithm of the selected cipher
suite.  The transcript hash TH_2 is a CBOR encoded bstr and the
input to the hash function is a CBOR Sequence.  Note that
H(message_1) can be computed and cached already in the processing
of message_1.
Paragraph (version A):
Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H()
is the hash function in the selected cipher suite.  The transcript
hash TH_3 is a CBOR encoded bstr and the input to the hash
function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) can
be computed and cached already in the processing of message_2.
Paragraph (version B):
Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H()
is the EDHOC hash algorithm of the selected cipher suite.  The
transcript hash TH_3 is a CBOR encoded bstr and the input to the
hash function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2)
can be computed and cached already in the processing of message_2.
Paragraph (version A):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key
authentication).  The Initiator can securely derive application keys
and send protected application data.  However, the Initiator does not
know that the Responder has actually computed the key PRK_4x3m and
therefore the Initiator SHOULD NOT permanently store the keying
material PRK_4x3m and TH_4, or derived application keys, until the
Initiator is assured that the Responder has actually computed the key
PRK_4x3m (explicit key confirmation).  This is similar to waiting for
acknowledgement (ACK) in a transport protocol.  Explicit key
confirmation is e.g., assured when the Initiator has verified an
OSCORE message or message_4 from the Responder.
Paragraph (version B):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_4x3m (implicit key
authentication).  The Initiator can securely derive application keys
and send protected application data.  However, the Initiator does not
know that the Responder has actually computed the key PRK_4x3m and
therefore the Initiator SHOULD NOT permanently store the keying
material PRK_4x3m and TH_4, or derive application keys, until the
Initiator is assured that the Responder has actually computed the key
PRK_4x3m (explicit key confirmation).  This is similar to waiting for
acknowledgement (ACK) in a transport protocol.  Explicit key
confirmation is e.g., assured when the Initiator has verified an
OSCORE message or message_4 from the Responder.
Paragraph (version A):
Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token, the 5-tuple, or the
prepended C_I, see coap).
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Section 5.3 of
I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in
the selected cipher suite, and the parameters defined in asym-
msg3-proc.
Paragraph (version B):
Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token, the 5-tuple, or the
prepended C_R, see coap).
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD
algorithm in the selected cipher suite, and the parameters defined
in asym-msg3-proc.
Paragraph (version A):
After verifying message_3, the Responder is assured that the
Initiator has calculated the key PRK_4x3m (explicit key confirmation)
and that no other party than the Responder can compute the key.  The
Responder can securely send protected application data and store the
keying material PRK_4x3m and TH_4.
Paragraph (version B):
After verifying message_3, the Responder is assured that the
Initiator has calculated the key PRK_4x3m (explicit key confirmation)
and that no other party than the Initiator can compute the key.  The
Responder can securely send protected application data and store the
keying material PRK_4x3m and TH_4.
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Section 5.3 of
I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in
the selected cipher suite, and the parameters defined in asym-
msg4-proc.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD
algorithm in the selected cipher suite, and the parameters defined
in asym-msg4-proc.
Paragraph (version B):
If the selected cipher suite is not the first cipher suite which the
Responder supports in SUITES_I received in message_1, then the
Responder MUST discontinue the protocol, see resp-proc-msg1.  If
SUITES_I in message_1 is manipulated, then the integrity verification
of message_2 containing the transcript hash TH_2 will fail and the
Initiator will discontinue the protocol.
Paragraph (version A):
If the selected cipher suite is not the first cipher suite which the
Responder supports in SUITES_I received in message_1, then Responder
MUST discontinue the protocol, see resp-proc-msg1.  If SUITES_I in
message_1 is manipulated, then the integrity verification of
message_2 containing the transcript hash TH_2 will fail and the
Initiator will discontinue the protocol.
Paragraph (version A):
As described in SIGMA, different levels of identity protection is
provided to the Initiator and the Responder.  EDHOC protects the
credential identifier of the Initiator against active attacks and the
credential identifier of the Responder against passive attacks.  The
roles should be assigned to protect the most sensitive identity/
identifier, typically that which is not possible to infer from
routing information in the lower layers.
Paragraph (version B):
As described in SIGMA, different levels of identity protection are
provided to the Initiator and the Responder.  EDHOC protects the
credential identifier of the Initiator against active attacks and the
credential identifier of the Responder against passive attacks.  The
roles should be assigned to protect the most sensitive identity/
identifier, typically that which is not possible to infer from
routing information in the lower layers.
Paragraph (version A):
compromise of all exported keying material derived after the last
invocation of the EDHOC-KeyUpdate function.
Paragraph (version B):
compromise of all keying material derived with the EDHOC-Exporter
since the last invocation (if any) of the EDHOC-KeyUpdate function.
Paragraph (version A):
than the Responder can compute the key.  The Responder can securely
send protected application data and store the keying material
PRK_4x3m and TH_4.
Paragraph (version B):
than the Initiator can compute the key.  The Responder can securely
send protected application data and store the keying material
PRK_4x3m and TH_4.
Paragraph (version A):
To reduce message overhead EDHOC does not use explicit nonces and
instead rely on the ephemeral public keys to provide randomness to
each session.  A good amount of randomness is important for the key
generation, to provide liveness, and to protect against interleaving
attacks.  For this reason, the ephemeral keys MUST NOT be used in
more than one EDHOC message, and both parties SHALL generate fresh
random ephemeral key pairs.  Note that an ephemeral key may be used
to calculate several ECDH shared secrets.  When static Diffie-Hellman
authentication is used the same ephemeral key is used in both
ephemeral-ephemeral and ephemeral-static ECDH.
Paragraph (version B):
To reduce message overhead EDHOC does not use explicit nonces and
instead relies on the ephemeral public keys to provide randomness to
each session.  A good amount of randomness is important for the key
generation, to provide liveness, and to protect against interleaving
attacks.  For this reason, the ephemeral keys MUST NOT be used in
more than one EDHOC message, and both parties SHALL generate fresh
random ephemeral key pairs.  Note that an ephemeral key may be used
to calculate several ECDH shared secrets.  When static Diffie-Hellman
authentication is used the same ephemeral key is used in both
ephemeral-ephemeral and ephemeral-static ECDH.
Paragraph (version A):
As discussed in SIGMA, the encryption of message_2 does only need to
protect against passive attacker as active attackers can always get
the Responders identity by sending their own message_1.  EDHOC uses
the Expand function (typically HKDF-Expand) as a binary additive
stream cipher.  HKDF-Expand provides better confidentiality than AES-
CTR but is not often used as it is slow on long messages, and most
applications require both IND-CCA confidentiality as well as
integrity protection.  For the encryption of message_2, any speed
difference is negligible, IND-CCA does not increase security, and
integrity is provided by the inner MAC (and signature depending on
method).
Paragraph (version B):
As discussed in SIGMA, the encryption of message_2 does only need to
protect against passive attacker as active attackers can always get
the Responder's identity by sending their own message_1.  EDHOC uses
the Expand function (typically HKDF-Expand) as a binary additive
stream cipher.  HKDF-Expand provides better confidentiality than AES-
CTR but is not often used as it is slow on long messages, and most
applications require both IND-CCA confidentiality as well as
integrity protection.  For the encryption of message_2, any speed
difference is negligible, IND-CCA does not increase security, and
integrity is provided by the inner MAC (and signature depending on
method).
Paragraph (version A):
Requirement for how to securely generate, validate, and process the
ephemeral public keys depend on the elliptic curve.  For X25519 and
X448, the requirements are defined in RFC7748.  For secp256r1,
secp384r1, and secp521r1, the requirements are defined in Section 5
of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least
partial public-key validation MUST be done.
Paragraph (version B):
Requirements for how to securely generate, validate, and process the
ephemeral public keys depend on the elliptic curve.  For X25519 and
X448, the requirements are defined in RFC7748.  For secp256r1,
secp384r1, and secp521r1, the requirements are defined in Section 5
of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least
partial public-key validation MUST be done.
Paragraph (version A):
As CoAP provides Denial-of-Service protection in the form of the Echo
option I-D.ietf-core-echo-request-tag, EDHOC itself does not provide
countermeasures against Denial-of-Service attacks.  By sending a
number of new or replayed message_1 an attacker may cause the
Responder to allocate state, perform cryptographic operations, and
amplify messages.  To mitigate such attacks, an implementation SHOULD
rely on lower layer mechanisms such as the Echo option in CoAP that
forces the initiator to demonstrate reachability at its apparent
network address.
Paragraph (version B):
EDHOC itself does not provide countermeasures against Denial-of-
Service attacks.  In particular, by sending a number of new or
replayed message_1 an attacker may cause the Responder to allocate
state, perform cryptographic operations, and amplify messages.  To
mitigate such attacks, an implementation SHOULD rely on lower layer
mechanisms.  For instance, when EDHOC is transferred as an exchange
of CoAP messages, the CoAP server can use the Echo option defined in
I-D.ietf-core-echo-request-tag which forces the CoAP client to
demonstrate reachability at its apparent network address.
Paragraph (version A):
IANA has registered the following entries in the "COSE Header
Parameters" registry under the group name "CBOR Object Signing and
Encryption (COSE)".  The value of the 'kcwt' header parameter is a
COSE Web Token (CWT) RFC8392, and the value of the 'kccs' header
parameter is an CWT Claims Set (CCS), see term.  The CWT/CCS must
contain a COSE_Key in a 'cnf' claim RFC8747.  The Value Registry for
this item is empty and omitted from the table below.
Paragraph (version B):
IANA has registered the following entries in the "COSE Header
Parameters" registry under the group name "CBOR Object Signing and
Encryption (COSE)".  The value of the 'kcwt' header parameter is a
COSE Web Token (CWT) RFC8392, and the value of the 'kccs' header
parameter is a CWT Claims Set (CCS), see term.  The CWT/CCS must
contain a COSE_Key in a 'cnf' claim RFC8747.  The Value Registry for
this item is empty and omitted from the table below.
Paragraph (version A):
The IANA Registries established in this document is defined as
"Expert Review".  This section gives some general guidelines for what
the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.
Paragraph (version B):
The IANA Registries established in this document are defined as
"Expert Review".  This section gives some general guidelines for what
the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.