Draft: draft-ietf-lake-edhoc

Commentary: Changes in , here are detailed responses , except : changes in EAD for which there is parallel work in comment on section 5.1 which we make into a separate thread . Please look through these responses and see if you have any comments . [ Section 2 ] " ... using keys derived from the shared secret . " This should be the ECDH shared secret derived from GX and GY . It has not been introduced before , and it appears a little later for the first time . Hence , here it can be confused with the " shared secret key PRKout " mentioned before , in the first paragraph after Figure 2 . GS : Rephrased as NEW " - crypto algorithms applied with keys derived from one or more shared secrets calculated during the protocol " [ Section 3.3 ] s / certain byte string identifiers / certain identifiers GS : DONE [ Section 3.3.2 ] A lot of text in this section takes CBOR byte strings as a starting point . However , as mentioned in Section 3.3.0 , " Connection identifiers in EDHOC are intrinsically byte strings . " I read this as " raw byte strings " , rather than " CBOR byte strings " . One may still choose to generate and store the identifiers precisely as CBOR byte strings , but they are still raw byte strings at their core . Then , I think the following editorial changes would make the text in this section simpler and less prone to confusion . Remove the sentence : " This correspondence between integers and byte strings is a natural mapping between the byte strings with CBOR diagnostic notation h'00 ' , h'01 ' , ... , h'37 ' ( except h'18 ' , h'19 ' , ... , h'1F ' ) and integers which are CBOR encoded as one byte . " GS : DONE s / are encoded as normal CBOR byte strings / are simply encoded as CBOR byte strings GS : DONE The text " h'21 ' is represented by 0x21 ( CBOR encoding of the integer -2 ) , not by 0x4121 . " becomes : " 0x21 is represented by 0x21 ( CBOR encoding of the integer -2 ) , not by the CBOR encoding 0x4121 . " The text " h'0D ' is represented by 0x0D ( CBOR encoding of the integer 13 ) , not by 0x410D. " becomes : " 0x0D is represented by 0x0D ( CBOR encoding of the integer 13 ) , not by the CBOR encoding 0x410D. " The text " h'18 ' is represented by 0x4118 . " becomes : " 0x18 is represented by 0x4118 ( CBOR encoding of the byte string 0x18 ) . " The text " h'38 ' is represented by 0x4138 . " becomes : " 0x38 is represented by  ( CBOR encoding of the byte string 0x38 ) . " The text " h'ABCD ' is represented by 0x42ABCD . " becomes : " 0xABCD is represented by 0x42ABCD ( CBOR encoding of the byte string 0xABCD ) . " GS : Did something similar : NEW 0x21 is represented by 0x21 ( CBOR encoding of the integer -2 ) , not by 0x4121 ( CBOR encoding of the byte string 0x21 ) . 0x0D is represented by 0x0D ( CBOR encoding of the integer 13 ) , not by 0x410D ( CBOR encoding of the byte string 0x0D ) . 0x18 is represented by 0x4118 ( CBOR encoding of the byte string 0x18 ) . 0x38 is represented by  ( CBOR encoding of the byte string 0x38 ) . 0xABCD is represented by 0x42ABCD ( CBOR encoding of the byte string 0xABCD ) . The text " A byte string which parses as a CBOR int in the range -24 , ... , 23 is just copied directly into the message " becomes : " A byte string which parses as the 1 - byte CBOR encoding of an integer in the range -24 , ... , 23 is just copied directly into the message " . GS : Did something similar : NEW A byte string which parses as the one - byte CBOR encoding of an integer ( i.e. integer in the interval -24 , ... , 23 ) is just copied directly into the message The text " produces a byte string or an integer depending on its value . " becomes : " produces a CBOR byte string or a CBOR integer depending on the value of the byte string identifier . " GS : DONE [ Section 3.4 ] s / fragmentation / fragmentation and reassembly GS : DONE [ Section 3.5.1 ] " The authentication key algorithm needs to be compatible with the method and the cipher suite " This should be specifically the selected cipher suite , right ? GS : DONE [ Section 3.5.2 ] s / on a specific encoding of the credential / on the specific encoding of the credentials GS : DONE " When the authentication credential is a COSEKey in a CWT , CREDx SHALL be the untagged CWT . " This should be : " When the authentication credential is a CWT including a COSEKey , then CREDx SHALL be the untagged CWT . " GS : DONE " When the authentication credential is a COSEKey but not in a CWT , CREDx SHALL be an untagged CCS . " This should be : " When the authentication credential includes a COSEKey but it is not a CWT , then CREDx SHALL be an untagged CCS . " GS : NEW " When the authentication credential includes a COSEKey but is not a CWT , then CREDx SHALL be an untagged CCS . " [ Section 3.5.3 ] s / the sender 's credential / the message sender 's credential GS : DONE " the integer representation of byte string identifiers in Section 2 MUST be applied . " I think it would be clearer to say : " the same representation used for EDHOC connection identifiers and defined in Section 3.3.2 MUST be applied . " GS : DONE [ Section 3.6 ] s / The MAC length MUST be / The EDHOC MAC length MUST be GS : DONE s / independently of the cipher suite / independently of the selected cipher suite GS : DONE " Note that AES - CCM-16 - 64 - 128 and AES - CCM-16 - 64 - 128 are compatible with the IEEE CCM mode . " This should be : " Note that AES - CCM-16 - 64 - 128 and AES - CCM-16 - 128 - 128 are compatible with the IEEE CCM mode . " GS : DONE [ Section 3.8 ] " If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it can not process , the EDHOC protocol MUST be discontinued . " Must an EDHOC error message also be sent before discontinuing the protocol ? Is it something that must be specified by the application / specification that defines the EAD item and its processing when used as critical ? See also later comments about Section 5.x on sending an EDHOC error message if any processing step fails . GS : NOT DONE - pending merging PR about EAD padding [ Section 3.9 ] " For some parameters , ... the receiver is able to verify compliance with the application profile " It 's better to explicitly say " the receiver of an EDHOC message " . Later on in the same section , it occurs again in " the receiver need to be able to determine ... " GS : DONE " Other conditions may be part of the application profile , such as target application or use ( if there is more than one application / use ) to the extent that EDHOC can distinguish between them . " Proposed rephrasing : " Other conditions may be part of the application profile , such as the different target application or use ( if there is more than one application / use ) , in which case EDHOC needs to be able to distinguish between them . " GS : I did not do the change in second part since that is removing an important remark ( that EDHOC may not be able to distinguish different uses ) and since the proposed new formulation is duplicating the content of the following sentence . NEW Other conditions may be part of the application profile , such as what is the target application or use ( if there is more than one application / use ) to the extent that EDHOC can distinguish between them . " for example based on URI or external authorization data type . " What URI ? I guess this means the URI pointing to an EDHOC resource where an EDHOC message is sent . In that case , an application profile is associated with one or more EDHOC resources , identified by the corresponding URIs and targeted by the EDHOC messages sent to that node . GS : Changed " URI " to " URI to which the EDHOC message is sent " [ Section 4.1.2 ] In the bullet list above Figure 7 , the description of " keylength " and of " ivlength " should also conclude with " of the selected cipher suite " , just like for " hashlength " . GS : DONE [ Section 5.1 ] Let 's say that we have : the Initiator acting as CoAP client and not supporting EDHOC message4 ; and the Responder that instead supports EDHOC message4 . Eventually , the Initiator sends EDHOC message3 . Since the Initiator does not support EDHOC message4 , it moves to a protocol state where the only expected , next EDHOC message is an EDHOC error message . Then , the Responder sends back EDHOC message4 as a response . This is not wrong to do per se . In fact , an application profile can say that  shall be sent , but it can not really say that it shall not be sent . Besides , the Initiator might generally not be aware of the application profile . This is actually only a specific example of something more general . That is , what should the Initiator do after having sent EDHOC message3 , if it receives as a reply something not expected as per its current protocol state ? This is still a processing failure ( see second from last paragraph of Section 5.1 ) . However , should the Initiator still send an EDHOC error message and thus discontinue EDHOC even in this case where the protocol is basically complete ? I believe the answer is " no , it should be fine with that , unless there is a very strong reason to do otherwise . " In that spirit , I propose to extend the second from last paragraph of Section 5.1 with some text along these lines : " After having sent EDHOC message3 , the Initiator remains ready to possibly receive as following EDHOC messages : i )   or an EDHOC error message , if the Initiator supports EDHOC message4 ; or ii ) an EDHOC error message , if the Initiator does not support EDHOC message4 . If , after having sent EDHOC message3 , the Initiator receives an EDHOC message that does not match with what it expects or that results in a processing failure , then the Initiator SHOULD NOT send an EDHOC error message and SHOULD NOT discontinue the EDHOC protocol . An exception applies in case the Initiator supports EDHOC message4 and is aware of the application profile that states that EDHOC message4 shall be sent . After having sent EDHOC message4 , the Responder remains ready to possibly receive a following EDHOC error message . If , after having sent EDHOC message4 , the Responder receives an EDHOC message that does not match with what it expects or that results in a processing failure , then the Responder MUST NOT send an EDHOC error message and MUST NOT discontinue the EDHOC protocol . " GS : I 'll make this a separate thread . [ Section 5.2.3 ] " If any processing step fails , the Responder  send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD1 available to the application ? GS : TBD pending merging PR about EAD padding [ Section 5.3.2 ] " The transcript hash TH2 is a CBOR encoded bstr ... " Well , TH2 as output of H ( ) is simply raw bytes , i.e , not a CBOR item . Only later on is a CBOR - encoded TH2 used , e.g. , when building  . Then it should be ok to simply remove the quoted text . GS : DONE "   as in ... " Here it 's good to give a pointer to Appendix I " Long PLAINTEXT2 " . GS : DONE " Verify SignatureorMAC2 using ... " It 's worth mentioning that , after this step , the Initiator might have to get back to processing some EAD items from EAD2 , that were previously made available to the application but not ( entirely ) processed yet . This is the case , e.g. , if their processing requires to first achieve proof - of - possession of the Responder 's private key , which happens after having successfully verified SignatureorMAC2 . GS : DONE " If any processing step fails , the Initiator MUST send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD2 available to the application ? GS : Yes , processing also covers EAD processing GS : TBD pending merging PR about EAD padding [ Section 5.4.2 ] " The transcript hash  is a CBOR encoded bstr ... " Like in a comment above , TH3 as output of H ( ) is simply raw bytes , i.e. , not a CBOR item . Only later on is a CBOR - encoded  used , e.g. , when building context3 . Then it should be ok to simply remove the quoted text . GS : DONE " The transcript hash TH4 is a CBOR encoded bstr ... " Like in the comment above , TH4 as output of H ( ) is simply raw bytes , i.e , not a CBOR item . Only later on is a CBOR - encoded TH4 used , e.g. , as input to EDHOC - KDF . Then it should be ok to simply remove the quoted text . GS : DONE [ Section 5.4.3 ] " Verify SignatureorMAC3 using ... " It 's worth mentioning that , after this step , the Responder might have to get back to processing some EAD items from EAD3 , that were previously made available to the application but not ( entirely ) processed yet . This is the case , e.g. , if their processing requires to first achieve proof - of - possession of the Initiator 's private key , which happens after having successfully verified SignatureorMAC3 . GS : DONE " If any processing step fails , the Responder  send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD3 available to the application ? GS : TBD pending merging PR about EAD padding [ Section 5.5.3 ] " If any processing step fails , the Initiator MUST send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD4 available to the application ? GS : TBD pending merging PR about EAD padding [ Section 6.3 ] " ERRINFO is in this case denoted SUITESR " This should be , e.g. , " In this case , ERRINFO specifies SUITESR " GS : I did n’t understand why “ specifies ” is more clear than “ is denoted ” . Proposal : NEW In this case , ERRINFO = SUITESR " SUITESR MAY include a single cipher suite , i.e. , be encoded as an int . " This should be " SUITESR MAY include a single cipher suite , in which case it is encoded as an int . " GS : DONE " selects its most preferred and the Responder sends an error with supported cipher suites . " This should be " selects its most preferred cipher suites and the Responder sends an error with its supported cipher suites . " GS : DONE [ Section 8.1 ] " A single session of EDHOC does not include negotiation of cipher suites " Perhaps do you mean " a single exchange of two EDHOC messages " ? GS : I think “ session ” is the right term here . We use that to describe a specific execution of the EDHOC protocol . The negotiation of cipher suites requires the discontinuation of one session and the start of a new , so it is not a single session of EDHOC . " ... until the Initiator has verified an OSCORE message or  from the Responder . Like in Section 5.4.2 , this should be : " ... until the Initiator has verified  or a message protected with a derived application key , such as an OSCORE message , from the Responder . " GS : DONE [ Section 8.3 ] " ... so that a sufficient security level is maintained for certificates , EDHOC , and the protection of application data . " Does " certificates " actually mean " authentication credentials " ? Does " EDHOC " actually mean " EDHOC executions " or " EDHOC messages " ? GS : Done , expanding “ EDHOC ” to “ the EDHOC protocol ” [ Section 8.8 ] " Note that part of  is also non - secret randomness as it is known or predictable to an attacker . " Proposed rephrasing : " Note that part of  does not enjoy non - secret randomness either , as it is known or predictable to an attacker . " GS : Not done , what is the issue with the current formulation ? " enjoy randomness " seems not being a common phrasing . [ Section 9 ] Throughout the whole section : s / group name / registry groupWhen mentioning a registration procedure , refer to RFC 8126 ( to be as normative reference ) . GS : DONE [ Section 9.7 ] You can remove " under the group name " Well - Known URIs " " . GS : DONE [ Appendix A ] s / when OSCORE is used with EDHOC / when EDHOC is used to key OSCORE GS : DONE [ Appendix A.2 ] " with response codes analogously to message2 " This should be : " with response codes analogous to those of the response to message2 " . " In case of an error message in response to message4 , it is sent analogously to errors in response to message2 . " This should be : " In case of an error message sent as reply to message4 , it is sent analogously to an error message sent as reply to message2 . " GS : DONE s / See Figure 13 / See Figure 13 for an example GS : DONE s / See Figure 14 / See Figure 14 for an example GS : DONE s / to these messages / to the CoAP messages that transport an EDHOC message prepended by a connection identifier GS : DONE in singular [ Appendix A.2.1 ] " When using EDHOC over CoAP for establishing an OSCORE Security Context , EDHOC error messages ... " The following text about error responses and response code applies also in case EDHOC is used for keying something different than OSCORE . Hence the sentence can be shortened as : " When using EDHOC over CoAP , EDHOC error messages ... " GS : DONE ( in commit labelled A.1 ) [ Appendix J ] " The change of PRKout causes a change to PRKexporter and keys derived using EDHOC - Exporter . " This refers specifically to EDHOC - KeyUpdate , which certainly causes a change to PRKexporter , but not directly to existing keys previously derived using EDHOC - Exporter . I would expect that existing application keys derived from the old PRKexporter remain unchanged , at least at the end of EDHOC - KeyUpdate . At the same time , the final goal of an application triggering EDHOC - KeyUpdate is practically to update application keys . So perhaps the quoted sentence can be rephrased to say that : i ) the newly derived PRKexporter is used from then on in order to derive new application keys with EDHOC - Exporter ; and ii ) current , existing application keys previously derived with EDHOC - Exporter can be re - derived using the new PRK_exporter . The newly derived applications keys supersed e the old ones . When to delete the old application keys and how to verify that they are not needed is up to the application . GS : DONE in paragraphs before and after pseudocode . [ Nits ] Section 1.1 : --- s / criteria / criterion --- s / prohibitive / prohibitively large GS : DONE Section 2 : --- s / Like ( D)TLS / Like in ( D)TLS --- s / the application , EDHOC / the application . EDHOC GS : DONE Section 3.2 : --- s / indicate protocol / indicate the protocol GS : DONE Section 3.3 : --- s / or in subsequent / or may be used in subsequent GS : Did “ or may be used in ” --- s / CBOR ints / CBOR integers GS : DONE and other similar --- s / associated to the / associated with the GS : DONE and other similar Section 3.3.2 : --- s / encoding : A byte / encoding : a byte --- s / message , a byte string which doesn't / message ; a byte string which does not --- s / representation it can / representation , it can GS : DONE Section 3.3.3 : --- s / results in same / results in the same GS : DONE Section 3.4 : --- s / In addition to transport / In addition to the transport GS : DONE Section 3.5.1 : --- s / Note that for most signature / Note that , for most signature GS : Not done . There are multiple occurrences of this , but it is consequently without comma . Either we change none or all , and I ’m currently inclined to do none . --- s / keys are denoted I / keys are denoted as I GS : DONE Section 3.5.3 : --- s / within EDHOC , for example / within EDHOC . For example GS : DONE Section 3.6 : --- s / follows from COSE / follow from COSE GS : DONE Section 3.7 : --- s / In COSE compact / In COSE , compact GS : DONE Section 3.8 : --- s / registers their own / registers its own --- s / non - critical , determined by / non - critical , as determined by GS : Not done yet - pending merge of EAD - padding PR Section 3.9 : --- s / because of wrong / because of a wrong GS : Not done , I think the current formulation is fine --- s / uses public / uses a public GS : DONE Section 4.1.2 : --- s / is used is specified / is used are specified GS : DONE Section 5.1 --- s / associated to an / associated with an GS : DONE Section 5.4.2 : --- s / for acknowledgement / for an acknowledgement GS : DONE Section 5.5 : --- s / of such deployments:/of such deployments are : GS : DONE Section 6 : --- s / Errors messages in EDHOC / Error messages in EDHOC --- s / associated to the / associated with the GS : DONE Section 6.3.2 : --- s / so therefore selects / therefore it selects GS : Not done , I think the current formulation is fine --- s / The initiator prepends / The Initiator prepends GS : DONE and other similar Section 7 --- s / differ in size of / differ in the size of GS : DONE --- s / is no essential difference / is of no essential difference GS : Not done , I think the current formulation is fine Section 8.1 --- s / and send its own / and then sending its own GS : DONE --- s / Either of these provide / Both of them provide GS : I want it to be clear that either one or the other of these methods , independently of each other , provides this property . “ both of them ” is less clear and may be confused with that both are needed to provide the property . I only fixed the grammar . --- s / in the application protocol fail / in the application protocol fails GS : Done in separate commit Section 8.2 --- s / future EHDOC methods / future EDHOC methods GS : DONE and other similar Section 8.3 --- s / whole authentication credential / whole authentication credentials GS : DONE Section 8.5 --- s / update the connection identifier / update the connection identifiers GS : DONE Section 8.6 --- s / An passive attacker / A passive attacker GS : DONE Section 8.8 --- s / PNRG / PRNG ( 2 occurrences ) GS : DONE --- s / to select its connection identifiers / to select the connection identifier GS : DONE --- s / ongoing EDHOC protocol / ongoing EDHOC protocol execution GS : Not done , I think the current formulation is fine --- s / sets that will be / sets will be OLD which of the parameter sets that will be used NEW which parameter set that will be used --- s / do not make use / does not make use GS : DONE --- s / hash , this / hash . This GS : DONE Section 9.11 --- s / Expert should consider / Experts should consider GS : DONE Appendix A.2.1 --- s / EDHOC and OSCORE protocols / the EDHOC and OSCORE protocols GS : DONE Appendix C --- s / to simplify for implementors / to help implementors GS : DONE Appendix C.1 --- s / occurrance / occurrence GS : DONE in other commit     / associated to the / associated with the GS : DONE Appendix E --- s / external authorization related data / related external authorization data GS : DONE     / with value empty / with value the empty GS : DONE     / acknowledgement on CoAP messaging layer / acknowledgement on the CoAP messaging layer GS : DONE --- s / processing on CoAP messaging layer / processing on the CoAP messaging layer GS : DONE --- s / differences which compromises / differences which compromise GS : DONE Appendix I --- s / algorithm the length / algorithm , the length GS : DONE 
 Thanks , it looks good ! Please see my replies on two specific points in the separate comments below . I understand that what is still open includes : Handling critical failure of EAD processing ( Sections 3.8 , 5.2.3 , 5.3.3 , 5.4.3 and 5.3.3 ) . Exceptions to discontinuing the protocol after having sent message_3 ( Section 5.1 ) . 
 So far , I 've always seen an " EDHOC execution " as consisting of " message exchanges " and " message processing " , during which an associated " session " is built and referred to . If " session " has to be intended as a specific " EDHOC execution " as a whole ( and not just an incrementally built environment associated with it ) , maybe it 's better to give an early definition of " session " . 
 Trimming the original sentence , I ca n't parse " part of  is non - secret randomness " . I think my problem here is seeing the verb " is " : while  is a " thing " , randomness is a possible property of that thing . Perhaps you mean " does not have secret randomness " ( better suggestion than " enjoy " ) , or " is not secretly random " . 
 [ Section 8.8 ] The term may be confusing , but it is used in the literature , e.g. in Krawczyk 's paper on The HKDF Scheme ( ): Also in this case , " non - secret randomness " is referring to a " thing " , namely an IV . Since the text in the draft is related to the discussion in the literature it is favorable if we can use the same terminology . 
 Thanks , I agree . With that context in mind , " KEYSTREAM_2 is also non - secret randomness " is just fine then . 
 [ Section 8.1 ] Yes , multiple terms are used . There was a change from " protocol instance " to " session " , and that has also been used in the security analysis . The terms are " EDHOC exchange " and " protocol execution " also makes sense to keep in certain instances . I session early in the text and also made some related changes in a separate PR Does this address your comment ? 
 Yes , that looks good . Thanks ! 
 [ Section 5.1 ] I agree with the general aim of this comment . Let 's see what if any needs to be rephrased . If the Initiator successfully completed its part of the message exchange there is no protocol to discontinue and therefore no reason to send error . Is this what needs to be clarified ? EDHOC requires certain parameters to be agreed upon between Initiator and Responder , including if message_4 shall be sent / expected . So from that point of view the Initiator should know if it has completed the protocol or not . ( If need to describe a change after message exchange is completed then " terminate session " is probably better terminology than " discontinue protocol " . ) 
 I made two more commits on PR . In the interest of harmonizing the terminology I went for " discontinue protocol " which is frequently used . I tried to capture  's comment on 5.1 . Please review 
 Closing this as is merged
Mailing list commentary: Hi all , I think that this document is in a very good shape ! Please see below some detailed comments . Best , /Marco [ Section 2 ] " ... using keys derived from the shared secret . " This should be the ECDH shared secret derived from GX and GY . It has not been introduced before , and it appears a little later for the first time . Hence , here it can be confused with the " shared secret key PRKout " mentioned before , in the first paragraph after Figure 2 . [ Section 3.3 ] s / certain byte string identifiers / certain identifiers [ Section 3.3.2 ] A lot of text in this section takes CBOR byte strings as a starting point . However , as mentioned in Section 3.3.0 , " Connection identifiers in EDHOC are intrinsically byte strings . " I read this as " raw byte strings " , rather than " CBOR byte strings " . One may still choose to generate and store the identifiers precisely as CBOR byte strings , but they are still raw byte strings at their core . Then , I think the following editorial changes would make the text in this section simpler and less prone to confusion . Remove the sentence : " This correspondence between integers and byte strings is a natural mapping between the byte strings with CBOR diagnostic notation h'00 ' , h'01 ' , ... , h'37 ' ( except h'18 ' , h'19 ' , ... , h'1F ' ) and integers which are CBOR encoded as one byte . " s / are encoded as normal CBOR byte strings / are simply encoded as CBOR byte strings The text " h'21 ' is represented by 0x21 ( CBOR encoding of the integer -2 ) , not by 0x4121 . " becomes : " 0x21 is represented by 0x21 ( CBOR encoding of the integer -2 ) , not by the CBOR encoding 0x4121 . " The text " h'0D ' is represented by 0x0D ( CBOR encoding of the integer 13 ) , not by 0x410D. " becomes : " 0x0D is represented by 0x0D ( CBOR encoding of the integer 13 ) , not by the CBOR encoding 0x410D. " The text " h'18 ' is represented by 0x4118 . " becomes : " 0x18 is represented by 0x4118 ( CBOR encoding of the byte string 0x18 ) . " The text " h'38 ' is represented by 0x4138 . " becomes : " 0x38 is represented by ( CBOR encoding of the byte string 0x38 ) . " The text " h'ABCD ' is represented by 0x42ABCD . " becomes : " 0xABCD is represented by 0x42ABCD ( CBOR encoding of the byte string 0xABCD ) . " The text " A byte string which parses as a CBOR int in the range -24 , ... , 23 is just copied directly into the message " becomes : " A byte string which parses as the 1 - byte CBOR encoding of an integer in the range -24 , ... , 23 is just copied directly into the message " . The text " produces a byte string or an integer depending on its value . " becomes : " produces a CBOR byte string or a CBOR integer depending on the value of the byte string identifier . " [ Section 3.4 ] s / fragmentation / fragmentation and reassembly [ Section 3.5.1 ] " The authentication key algorithm needs to be compatible with the method and the cipher suite " This should be specifically the selected cipher suite , right ? [ Section 3.5.2 ] s / on a specific encoding of the credential / on the specific encoding of the credentials " When the authentication credential is a COSEKey in a CWT , CREDx SHALL be the untagged CWT . " This should be : " When the authentication credential is a CWT including a COSEKey , then CREDx SHALL be the untagged CWT . " " When the authentication credential is a COSEKey but not in a CWT , CREDx SHALL be an untagged CCS . " This should be : " When the authentication credential includes a COSEKey but it is not a CWT , then CREDx SHALL be an untagged CCS . " [ Section 3.5.3 ] s / the sender 's credential / the message sender 's credential " the integer representation of byte string identifiers in Section 3.3.2 MUST be applied . " I think it would be clearer to say : " the same representation used for EDHOC connection identifiers and defined in Section 3.3.2 MUST be applied . " [ Section 3.6 ] s / The MAC length MUST be / The EDHOC MAC length MUST be s / independently of the cipher suite / independently of the selected cipher suite " Note that AES - CCM-16 - 64 - 128 and AES - CCM-16 - 64 - 128 are compatible with the IEEE CCM mode . " This should be : " Note that AES - CCM-16 - 64 - 128 and AES - CCM-16 - 128 - 128 are compatible with the IEEE CCM mode . " [ Section 3.8 ] " If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it can not process , the EDHOC protocol MUST be discontinued . " Must an EDHOC error message also be sent before discontinuing the protocol ? Is it something that must be specified by the application / specification that defines the EAD item and its processing when used as critical ? See also later comments about Section 5.x on sending an EDHOC error message if any processing step fails . [ Section 3.9 ] " For some parameters , ... the receiver is able to verify compliance with the application profile " It 's better to explicitly say " the receiver of an EDHOC message " . Later on in the same section , it occurs again in " the receiver need to be able to determine ... " " Other conditions may be part of the application profile , such as target application or use ( if there is more than one application / use ) to the extent that EDHOC can distinguish between them . " Proposed rephrasing : " Other conditions may be part of the application profile , such as the different target application or use ( if there is more than one application / use ) , in which case EDHOC needs to be able to distinguish between them . " " for example based on URI or external authorization data type . " What URI ? I guess this means the URI pointing to an EDHOC resource where an EDHOC message is sent . In that case , an application profile is associated with one or more EDHOC resources , identified by the corresponding URIs and targeted by the EDHOC messages sent to that node . [ Section 4.1.2 ] In the bullet list above Figure 7 , the description of " keylength " and of " ivlength " should also conclude with " of the selected cipher suite " , just like for " hashlength " . [ Section 5.1 ] Let 's say that we have : the Initiator acting as CoAP client and not supporting EDHOC message4 ; and the Responder that instead supports EDHOC message4 . Eventually , the Initiator sends EDHOC message3 . Since the Initiator does not support EDHOC message4 , it moves to a protocol state where the only expected , next EDHOC message is an EDHOC error message . Then , the Responder sends back EDHOC message4 as a response . This is not wrong to do per se . In fact , an application profile can say that  shall be sent , but it can not really say that it shall not be sent . Besides , the Initiator might generally not be aware of the application profile . This is actually only a specific example of something more general . That is , what should the Initiator do after having sent EDHOC message3 , if it receives as a reply something not expected as per its current protocol state ? This is still a processing failure ( see second from last paragraph of Section 5.1 ) . However , should the Initiator still send an EDHOC error message and thus discontinue EDHOC even in this case where the protocol is basically complete ? I believe the answer is " no , it should be fine with that , unless there is a very strong reason to do otherwise . " In that spirit , I propose to extend the second from last paragraph of Section 5.1 with some text along these lines : " After having sent EDHOC message3 , the Initiator remains ready to possibly receive as following EDHOC messages : i )   or an EDHOC error message , if the Initiator supports EDHOC message4 ; or ii ) an EDHOC error message , if the Initiator does not support EDHOC message4 . If , after having sent EDHOC message3 , the Initiator receives an EDHOC message that does not match with what it expects or that results in a processing failure , then the Initiator SHOULD NOT send an EDHOC error message and SHOULD NOT discontinue the EDHOC protocol . An exception applies in case the Initiator supports EDHOC message4 and is aware of the application profile that states that EDHOC message4 shall be sent . After having sent EDHOC message4 , the Responder remains ready to possibly receive a following EDHOC error message . If , after having sent EDHOC message4 , the Responder receives an EDHOC message that does not match with what it expects or that results in a processing failure , then the Responder MUST NOT send an EDHOC error message and MUST NOT discontinue the EDHOC protocol . " [ Section 5.2.3 ] " If any processing step fails , the Responder send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD1 available to the application ? [ Section 5.3.2 ] " The transcript hash TH2 is a CBOR encoded bstr ... " Well , TH2 as output of H ( ) is simply raw bytes , i.e , not a CBOR item . Only later on is a CBOR - encoded TH2 used , e.g. , when building  . Then it should be ok to simply remove the quoted text . "   as in ... " Here it 's good to give a pointer to Appendix I " Long PLAINTEXT2 " . " Verify SignatureorMAC2 using ... " It 's worth mentioning that , after this step , the Initiator might have to get back to processing some EAD items from EAD2 , that were previously made available to the application but not ( entirely ) processed yet . This is the case , e.g. , if their processing requires to first achieve proof - of - possession of the Responder 's private key , which happens after having successfully verified SignatureorMAC2 . " If any processing step fails , the Initiator MUST send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD2 available to the application ? [ Section 5.4.2 ] " The transcript hash  is a CBOR encoded bstr ... " Like in a comment above , TH3 as output of H ( ) is simply raw bytes , i.e. , not a CBOR item . Only later on is a CBOR - encoded  used , e.g. , when building context3 . Then it should be ok to simply remove the quoted text . " The transcript hash TH4 is a CBOR encoded bstr ... " Like in the comment above , TH4 as output of H ( ) is simply raw bytes , i.e , not a CBOR item . Only later on is a CBOR - encoded TH4 used , e.g. , as input to EDHOC - KDF . Then it should be ok to simply remove the quoted text . [ Section 5.4.3 ] " Verify SignatureorMAC3 using ... " It 's worth mentioning that , after this step , the Responder might have to get back to processing some EAD items from EAD3 , that were previously made available to the application but not ( entirely ) processed yet . This is the case , e.g. , if their processing requires to first achieve proof - of - possession of the Initiator 's private key , which happens after having successfully verified SignatureorMAC3 . " If any processing step fails , the Responder send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD3 available to the application ? [ Section 5.5.3 ] " If any processing step fails , the Initiator MUST send an EDHOC error message back ... " Does " processing " cover also the actual EAD processing , or only the act of making EAD4 available to the application ? [ Section 6.3 ] " ERRINFO is in this case denoted SUITESR " This should be , e.g. , " In this case , ERRINFO specifies SUITESR " " SUITESR MAY include a single cipher suite , i.e. , be encoded as an int . " This should be " SUITESR MAY include a single cipher suite , in which case it is encoded as an int . " " selects its most preferred and the Responder sends an error with supported cipher suites . " This should be " selects its most preferred cipher suites and the Responder sends an error with its supported cipher suites . " [ Section 8.1 ] " A single session of EDHOC does not include negotiation of cipher suites " Perhaps do you mean " a single exchange of two EDHOC messages " ? " ... until the Initiator has verified an OSCORE message or  from the Responder . Like in Section 5.4.2 , this should be : " ... until the Initiator has verified  or a message protected with a derived application key , such as an OSCORE message , from the Responder . " [ Section 8.3 ] " ... so that a sufficient security level is maintained for certificates , EDHOC , and the protection of application data . " Does " certificates " actually mean " authentication credentials " ? Does " EDHOC " actually mean " EDHOC executions " or " EDHOC messages " ? [ Section 8.8 ] " Note that part of  is also non - secret randomness as it is known or predictable to an attacker . " Proposed rephrasing : " Note that part of  does not enjoy non - secret randomness either , as it is known or predictable to an attacker . " [ Section 9 ] Throughout the whole section : s / group name / registry groupWhen mentioning a registration procedure , refer to RFC 8126 ( to be as normative reference ) . [ Section 9.7 ] You can remove " under the group name " Well - Known URIs " " . [ Appendix A ] s / when OSCORE is used with EDHOC / when EDHOC is used to key OSCORE [ Appendix A.2 ] " with response codes analogously to message2 " This should be : " with response codes analogous to those of the response to message2 " . " In case of an error message in response to message4 , it is sent analogously to errors in response to message2 . " This should be : " In case of an error message sent as reply to message4 , it is sent analogously to an error message sent as reply to message2 . " s / See Figure 13 / See Figure 13 for an example s / See Figure 14 / See Figure 14 for an example s / to these messages / to the CoAP messages that transport an EDHOC message prepended by a connection identifier [ Appendix A.2.1 ] " When using EDHOC over CoAP for establishing an OSCORE Security Context , EDHOC error messages ... " The following text about error responses and response code applies also in case EDHOC is used for keying something different than OSCORE . Hence the sentence can be shortened as : " When using EDHOC over CoAP , EDHOC error messages ... " [ Appendix J ] " The change of PRKout causes a change to PRKexporter and keys derived using EDHOC - Exporter . " This refers specifically to EDHOC - KeyUpdate , which certainly causes a change to PRKexporter , but not directly to existing keys previously derived using EDHOC - Exporter . I would expect that existing application keys derived from the old PRKexporter remain unchanged , at least at the end of EDHOC - KeyUpdate . At the same time , the final goal of an application triggering EDHOC - KeyUpdate is practically to update application keys . So perhaps the quoted sentence can be rephrased to say that : i ) the newly derived PRKexporter is used from then on in order to derive new application keys with EDHOC - Exporter ; and ii ) current , existing application keys previously derived with EDHOC - Exporter can be re - derived using the new PRK_exporter . The newly derived applications the old ones . When to delete the old application keys and how to verify that they are not needed is up to the application . [ Nits ] Section 1.1 : --- s / criteria / criterion --- s / prohibitive / prohibitively large Section 2 : --- s / Like ( D)TLS / Like in ( D)TLS --- s / the application , EDHOC / the application . EDHOC Section 3.2 : --- s / indicate protocol / indicate the protocol Section 3.3 : --- s / or in subsequent / or may be used in subsequent --- s / CBOR ints / CBOR integers --- s / associated to the / associated with the Section 3.3.2 : --- s / encoding : A byte / encoding : a byte --- s / message , a byte string which does n't / message ; a byte string which does not --- s / representation it can / representation , it can Section 3.3.3 : --- s / results in same / results in the same Section 3.4 : --- s / In addition to transport / In addition to the transport Section 3.5.1 : --- s / Note that for most signature / Note that , for most signature --- s / keys are denoted I / keys are denoted as I Section 3.5.3 : --- s / within EDHOC , for example / within EDHOC . For example Section 3.6 : --- s / follows from COSE / follow from COSE Section 3.7 : --- s / In COSE compact / In COSE , compact Section 3.8 : --- s / registers their own / registers its own --- s / non - critical , determined by / non - critical , as determined by Section 3.9 : --- s / because of wrong / because of a wrong --- s / uses public / uses a public Section 4.1.2 : --- s / is used is specified / is used are specified Section 5.1 --- s / associated to an / associated with an Section 5.4.2 : --- s / for acknowledgement / for an acknowledgement Section 5.5 : --- s / of such deployments:/of such deployments are : Section 6 : --- s / Errors messages in EDHOC / Error messages in EDHOC --- s / associated to the / associated with the Section 6.3.2 : --- s / so therefore selects / therefore it selects --- s / The initiator prepends / The Initiator prepends Section 7 --- s / differ in size of / differ in the size of --- s / is no essential difference / is of no essential difference Section 8.1 --- s / and send its own / and then sending its own --- s / Either of these provide / Both of them provide --- s / in the application protocol fail / in the application protocol fails Section 8.2 --- s / future EHDOC methods / future EDHOC methods Section 8.3 --- s / whole authentication credential / whole authentication credentials Section 8.5 --- s / update the connection identifier / update the connection identifiers Section 8.6 --- s / An passive attacker / A passive attacker Section 8.8 --- s / PNRG / PRNG ( 2 occurrences ) --- s / to select its connection identifiers / to select the connection identifier --- s / ongoing EDHOC protocol / ongoing EDHOC protocol execution --- s / sets that will be / sets will be --- s / do not make use / does not make use --- s / hash , this / hash . This Section 9.11 --- s / Expert should consider / Experts should consider Appendix A.2.1 --- s / EDHOC and OSCORE protocols / the EDHOC and OSCORE protocols Appendix C --- s / to simplify for implementors / to help implementors Appendix C.1 --- s / occurrance / occurrence     / associated to the / associated with the Appendix E --- s / external authorization related data / related external authorization data / with value empty / with value the empty   --- s / acknowledgement on CoAP messaging layer / acknowledgement on the CoAP messaging layer --- s / processing on CoAP messaging layer / processing on the CoAP messaging layer --- s / differences which compromises / differences which compromise Appendix I --- s / algorithm the length / algorithm , the length
Paragraph (version A):
The need for special protocols targeting constrained IoT deployments
extends also to the security domain I-D.ietf-lake-reqs.  Important
characteristics in constrained environments are the number of round
trips and protocol message sizes, which if kept low can contribute to
good performance by enabling transport over a small number of radio
frames, reducing latency due to fragmentation or duty cycles, etc.
Another important criteria is code size, which may be prohibitive for
certain deployments due to device capabilities or network load during
firmware update.  Some IoT deployments also need to support a variety
of underlying transport technologies, potentially even with a single
connection.
Paragraph (version B):
The need for special protocols targeting constrained IoT deployments
extends also to the security domain I-D.ietf-lake-reqs.  Important
characteristics in constrained environments are the number of round
trips and protocol message sizes, which if kept low can contribute to
good performance by enabling transport over a small number of radio
frames, reducing latency due to fragmentation or duty cycles, etc.
Another important criterion is code size, which may be prohibitively
large for certain deployments due to device capabilities or network
load during firmware update.  Some IoT deployments also need to
support a variety of underlying transport technologies, potentially
even with a single connection.
Paragraph (version A):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like IKEv2 RFC7296 and (D)TLS 1.3
RFC9147, EDHOC authenticated with signature keys is built on a
variant of the SIGMA protocol which provides identity protection of
the initiator (SIGMA-I) against active attackers, and like IKEv2,
EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol
shown in fig-sigma.
Paragraph (version B):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3
RFC9147, EDHOC authenticated with signature keys is built on a
variant of the SIGMA protocol which provides identity protection of
the Initiator (SIGMA-I) against active attackers, and like IKEv2,
EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol
shown in fig-sigma.
Paragraph (version A):
Enc(), AEAD(), and MAC() denotes encryption, authenticated
encryption with additional data, and message authentication code
using keys derived from the shared secret.
Paragraph (version B):
Enc(), AEAD(), and MAC() denotes encryption, authenticated
encryption with additional data, and message authentication code -
crypto algorithms applied with keys derived from one or more
shared secrets calculated during the protocol.
Paragraph (version A):
EDHOC is designed to encrypt and integrity protect as much
information as possible.  Symmetric keys and random material derived
using EDHOC-KDF are derived with as much previous information as
possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as
compact and lightweight as possible, in terms of message sizes,
processing, and the ability to reuse already existing CBOR, COSE, and
CoAP libraries.  Like (D)TLS, authentication is the responsibility of
the application, EDHOC identifies (and optionally transports)
authentication credentials, and provides proof-of-possession of the
private authentication key.
Paragraph (version B):
EDHOC is designed to encrypt and integrity protect as much
information as possible.  Symmetric keys and random material derived
using EDHOC-KDF are derived with as much previous information as
possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as
compact and lightweight as possible, in terms of message sizes,
processing, and the ability to reuse already existing CBOR, COSE, and
CoAP libraries.  Like in (D)TLS, authentication is the responsibility
of the application.  EDHOC identifies (and optionally transports)
authentication credentials, and provides proof-of-possession of the
private authentication key.
Paragraph (version A):
EDHOC does not have a dedicated message field to indicate protocol
version.  Breaking changes to EDHOC can be introduced by specifying
and registering new methods.
Paragraph (version B):
EDHOC does not have a dedicated message field to indicate the
protocol version.  Breaking changes to EDHOC can be introduced by
specifying and registering new methods.
Paragraph (version A):
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 except facilitating the retrieval of
security data associated to the protocol state.
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 may be used in applications of EDHOC, e.g., in
OSCORE (see ci-oscore).  The connection identifiers do not have any
cryptographic purpose in EDHOC except facilitating the retrieval of
security data associated with the protocol state.
Paragraph (version A):
Connection identifiers in EDHOC are intrinsically byte strings.  Most
constrained devices only have a few connections for which short
identifiers may be sufficient.  In some cases minimum length
identifiers are necessary to comply with overhead requirements.
However, CBOR byte strings - with the exception of the empty byte
string h'' which encodes as one byte (0x40) - are encoded as two or
more bytes.  To enable one-byte encoding of certain byte strings
while maintaining CBOR encoding, EDHOC represents certain byte string
identifiers as CBOR ints on the wire, see bstr-repr.
Paragraph (version B):
Connection identifiers in EDHOC are intrinsically byte strings.  Most
constrained devices only have a few connections for which short
identifiers may be sufficient.  In some cases minimum length
identifiers are necessary to comply with overhead requirements.
However, CBOR byte strings - with the exception of the empty byte
string h'' which encodes as one byte (0x40) - are encoded as two or
more bytes.  To enable one-byte encoding of certain byte strings
while maintaining CBOR encoding, EDHOC represents certain identifiers
as CBOR integers on the wire, see bstr-repr.
Paragraph (version A):
Implementation Note: When implementing the byte string identifier
representation it can in some programming languages help to define a
new type, or other data structure, which (in its user facing API)
behaves like a byte string, but when serializing to CBOR produces a
byte string or an integer depending on its value.
Paragraph (version B):
The integers with one-byte CBOR encoding are -24, ..., 23, see fig-
int-one-byte.
Paragraph (version B):
The byte strings which coincide with a one-byte CBOR encoding of an
integer MUST be represented by the CBOR encoding of that integer.
Other byte strings are simply encoded as CBOR byte strings.
Paragraph (version B):
0x21 is represented by 0x21 (CBOR encoding of the integer -2), not
by 0x4121 (CBOR encoding of the byte string 0x21).
Paragraph (version B):
0x0D is represented by 0x0D (CBOR encoding of the integer 13), not
by 0x410D (CBOR encoding of the byte string 0x0D).
Paragraph (version B):
0x18 is represented by 0x4118 (CBOR encoding of the byte string
0x18).
Paragraph (version B):
0x38 is represented by 0x4138 (CBOR encoding of the byte string
0x38).
Paragraph (version B):
0xABCD is represented by 0x42ABCD (CBOR encoding of the byte
string 0xABCD).
Paragraph (version B):
One way to view this representation of byte strings as a transport
encoding: a byte string which parses as the one-byte CBOR encoding of
an integer (i.e., integer in the interval -24, ..., 23) is just
copied directly into the message, a byte string which does not is
encoded as a CBOR byte string during transport.
Paragraph (version B):
Implementation Note: When implementing the byte string identifier
representation, it can in some programming languages help to define a
new type, or other data structure, which (in its user facing API)
behaves like a byte string, but when serializing to CBOR produces a
CBOR byte string or a CBOR integer depending on its value.
Paragraph (version B):
For OSCORE, the choice of 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 the same OSCORE
Recipient ID.  Since the connection identifier is a byte string, it
is converted to an OSCORE Recipient ID equal to the byte string.
Paragraph (version A):
A connection identifier 0x21 (represented in the EDHOC message as
the CBOR int 0x21, see bstr-repr) is converted to the OSCORE
Recipient ID 0x21.
Paragraph (version B):
A connection identifier 0x21 (represented in the EDHOC message as
the CBOR integer 0x21, see bstr-repr) is converted to the OSCORE
Recipient ID 0x21.
Paragraph (version A):
fragmentation,
Paragraph (version B):
fragmentation and reassembly,
Paragraph (version A):
The authentication key algorithm needs to be compatible with the
method and the cipher suite (see cs).  The authentication key
algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used, and
compatible with the EDHOC signature algorithm when signature
authentication is used.
Paragraph (version B):
The authentication key algorithm needs to be compatible with the
method and the selected cipher suite (see cs).  The authentication
key algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used, and
compatible with the EDHOC signature algorithm when signature
authentication is used.
Paragraph (version A):
Note that for most signature algorithms, the signature is determined
by the signature algorithm and the authentication key algorithm
together.  When using static Diffie-Hellman keys the Initiator's and
Responder's private authentication keys are denoted I and R,
respectively, and the public authentication keys are denoted G_I and
G_R, respectively.
Paragraph (version B):
Note that for most signature algorithms, the signature is determined
by the signature algorithm and the authentication key algorithm
together.  When using static Diffie-Hellman keys the Initiator's and
Responder's private authentication keys are denoted as I and R,
respectively, and the public authentication keys are denoted G_I and
G_R, respectively.
Paragraph (version A):
Since CRED_R is used in the integrity verification, see asym-
msg2-proc, it needs to be specified such that it is identical when
used by Initiator or Responder.  Similarly for CRED_I, see asym-
msg3-proc.  The Initiator and Responder are expected to agree on a
specific encoding of the credential, see applicability.
Paragraph (version B):
Since CRED_R is used in the integrity verification, see asym-
msg2-proc, it needs to be specified such that it is identical when
used by Initiator or Responder.  Similarly for CRED_I, see asym-
msg3-proc.  The Initiator and Responder are expected to agree on the
specific encoding of the credentials, see applicability.
Paragraph (version A):
When the authentication credential is a COSE_Key in a CWT, CRED_x
SHALL be the untagged CWT.
Paragraph (version A):
When the authentication credential is a COSE_Key but not in a CWT,
CRED_x SHALL be an untagged CCS.
Paragraph (version B):
When the authentication credential is a CWT including a COSE_Key,
then CRED_x SHALL be the untagged CWT.
Paragraph (version B):
When the authentication credential includes a COSE_Key but is not
in a CWT, CRED_x SHALL be an untagged CCS.
Paragraph (version A):
ID_CRED_x may contain the authentication credential CRED_x, but for
many settings it is not necessary to transport the authentication
credential within EDHOC, for example, it may be pre-provisioned or
acquired out-of-band over less constrained links.  ID_CRED_I and
ID_CRED_R do not have any cryptographic purpose in EDHOC since the
authentication credentials are integrity protected.
Paragraph (version B):
ID_CRED_x may contain the authentication credential CRED_x, but for
many settings it is not necessary to transport the authentication
credential within EDHOC.  For example, it may be pre-provisioned or
acquired out-of-band over less constrained links.  ID_CRED_I and
ID_CRED_R do not have any cryptographic purpose in EDHOC since the
authentication credentials are integrity protected.
Paragraph (version A):
Note that COSE header parameters in ID_CRED_x are used to identify
the sender's credential.  There is therefore no reason to use the
"-sender" header parameters, such as x5t-sender, defined in Section 3
of I-D.ietf-cose-x509.  Instead, the corresponding parameter without
"-sender", such as x5t, SHOULD be used.
Paragraph (version B):
Note that COSE header parameters in ID_CRED_x are used to identify
the message sender's credential.  There is therefore no reason to use
the "-sender" header parameters, such as x5t-sender, defined in
Section 3 of I-D.ietf-cose-x509.  Instead, the corresponding
parameter without "-sender", such as x5t, SHOULD be used.
Paragraph (version A):
The value of a COSE 'kid' parameter is a CBOR byte string.  For a
more compact representation, the CBOR map is replaced by a byte
string, see the definitions of plaintext in asym-msg2-proc and asym-
msg3-proc.  To allow one-byte encodings of ID_CRED_x with key
identifiers 'kid' the integer representation of byte string
identifiers in bstr-repr MUST be applied.
Paragraph (version A):
The CBOR map { 4 : h'FF' } is not encoded as 0xA10441FF but as the
CBOR byte string h'FF', i.e. 0x41FF.
Paragraph (version A):
The CBOR map { 4 : h'21' } is neither encoded as 0xA1044121, nor
as the CBOR byte string h'21', i.e. 0x4121, but as the CBOR
integer 0x21.
Paragraph (version B):
The value of a COSE 'kid' parameter is a CBOR byte string.  For a
more compact encoding, the CBOR map is replaced by a byte string, see
the definitions of plaintext in asym-msg2-proc and asym-msg3-proc.
To allow one-byte encodings of ID_CRED_x with key identifiers 'kid',
the same representation used for EDHOC connection identifiers defined
in bstr-repr MUST be applied.
Paragraph (version B):
The CBOR map { 4 : h'FF' } is not encoded as 0xA10441FF but as the
CBOR byte string h'FF', i.e., 0x41FF.
Paragraph (version B):
The CBOR map { 4 : h'21' } is neither encoded as 0xA1044121, nor
as the CBOR byte string h'21', i.e., 0x4121, but as the CBOR
integer 0x21.
Paragraph (version A):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  All algorithm names and definitions follows
from COSE algorithms RFC9053.  Note that COSE sometimes uses peculiar
names such as ES256 for ECDSA with SHA-256, A128 for AES-128, and
Ed25519 for the curve edwards25519.  Algorithms need to be specified
with enough parameters to make them completely determined.  The MAC
length MUST be at least 8 bytes.  Any cryptographic algorithm used in
the COSE header parameters in ID_CRED is selected independently of
the cipher suite.  EDHOC is currently only specified for use with key
exchange algorithms of type ECDH curves, but any Key Encapsulation
Method (KEM), including Post-Quantum Cryptography (PQC) KEMs, can be
used in method 0, see pqc.  Use of other types of key exchange
algorithms to replace static DH authentication (method 1,2,3) would
likely require a specification updating EDHOC with new methods.
Paragraph (version B):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  All algorithm names and definitions follow
from COSE algorithms RFC9053.  Note that COSE sometimes uses peculiar
names such as ES256 for ECDSA with SHA-256, A128 for AES-128, and
Ed25519 for the curve edwards25519.  Algorithms need to be specified
with enough parameters to make them completely determined.  The EDHOC
MAC length MUST be at least 8 bytes.  Any cryptographic algorithm
used in the COSE header parameters in ID_CRED is selected
independently of the selected cipher suite.  EDHOC is currently only
specified for use with key exchange algorithms of type ECDH curves,
but any Key Encapsulation Method (KEM), including Post-Quantum
Cryptography (PQC) KEMs, can be used in method 0, see pqc.  Use of
other types of key exchange algorithms to replace static DH
authentication (method 1,2,3) would likely require a specification
updating EDHOC with new methods.
Paragraph (version A):
Cipher suites 0-3, based on AES-CCM, are intended for constrained
IoT where message overhead is a very important factor.  Note that
AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with the
IEEE CCM* mode.
Paragraph (version B):
Cipher suites 0-3, based on AES-CCM, are intended for constrained
IoT where message overhead is a very important factor.  Note that
AES-CCM-16-64-128 and AES-CCM-16-128-128 are compatible with the
IEEE CCM* mode.
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
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 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 7.2 of RFC9053, but only including the 'x' parameter in G_X and
G_Y.  For Elliptic Curve Keys of type EC2, compact representation MAY
be used also in the COSE_Key.  COSE always uses compact output for
Elliptic Curve Keys of type EC2.  If the COSE implementation requires
a 'y' parameter, the value y = false or a calculated y-coordinate can
be used, see comrep.
Paragraph (version A):
The specification registering a new EAD label needs to describe under
what conditions the EAD item is critical or non-critical.
Paragraph (version B):
Each EAD field, EAD_x for x = 1, 2, 3 or 4, is a CBOR sequence (see
CBOR) of one or more EAD items ead defined in fig-ead-item.  See CDDL
for the CDDL definitions.
Paragraph (version B):
A security application using external authorization data needs to
register a positive ead_label and optionally an associated ead_value
format, for each EAD item it uses (see iana-ead).  Each application
registers its own EAD items and describes the associated processing
and security considerations.  The application may define multiple
uses of certain EAD items, e.g., the same EAD item may be used in
different EDHOC messages with the same application.  Multiple
occurrences of an EAD item in one EAD field may also be specified.
Paragraph (version B):
An EAD item can be either critical or non-critical, determined by the
sign of the ead_label in the EAD item transported in the EDHOC
message.  A negative value indicates that the EAD item is critical
and a non-negative value indicates that this EAD item is non-
critical.  The specification registering a new EAD label needs to
describe under what conditions the EAD item is critical or non-
critical, and thus whether the ead_label is used with negative or
positive sign. ead_label = 0 is used for padding, see padding.
Paragraph (version B):
Multiple occurrences of EAD items with ead_label = 0 are allowed.
Certain padding lengths require the use of at least two such EAD
items.
Paragraph (version A):
For some parameters, like METHOD, ID_CRED_x, type of EAD, the
receiver is able to verify compliance with the application profile,
and if it needs to fail because of incompliance, to infer the reason
why the protocol failed.
Paragraph (version A):
For other parameters, like the profile of CRED_x in the case that it
is not transported, it may not be possible to verify that
incompliance with the application profile was the reason for failure:
Integrity verification in message_2 or message_3 may fail not only
because of wrong credential.  For example, in case the Initiator uses
public key certificate by reference (i.e., not transported within the
protocol) then both endpoints need to use an identical data structure
as CRED_I or else the integrity verification will fail.
Paragraph (version B):
For some parameters, like METHOD, ID_CRED_x, type of EAD, the
receiver of an EDHOC message is able to verify compliance with the
application profile, and if it needs to fail because of incompliance,
to infer the reason why the protocol failed.
Paragraph (version B):
For other parameters, like the profile of CRED_x in the case that it
is not transported, it may not be possible to verify that
incompliance with the application profile was the reason for failure:
Integrity verification in message_2 or message_3 may fail not only
because of wrong credential.  For example, in case the Initiator uses
a public key certificate by reference (i.e., not transported within
the protocol) then both endpoints need to use an identical data
structure as CRED_I or else the integrity verification will fail.
Paragraph (version A):
Other conditions may be part of the application profile, such as
target application or use (if there is more than one application/use)
to the extent that EDHOC can distinguish between them.  In case
multiple application profiles are used, the receiver needs to be able
to determine which is applicable for a given session, for example
based on URI or external authorization data type.
Paragraph (version B):
Other conditions may be part of the application profile, such as what
is the target application or use (if there is more than one
application/use) to the extent that EDHOC can distinguish between
them.  In case multiple application profiles are used, the receiver
needs to be able to determine which is applicable for a given
session, for example based on URI to which the EDHOC message is sent,
or external authorization data type.
Paragraph (version A):
where L = 8*length, the output length in bits.
Paragraph (version B):
length, the output length in bits.
Paragraph (version A):
Further details of the key derivation and how the output keying
material is used is specified in asym.
Paragraph (version B):
Further details of the key derivation and how the output keying
material is used are specified in asym.
Paragraph (version A):
For each new/ongoing session, the endpoints are assumed to keep an
associated protocol state containing identifiers, keying material,
etc. used for subsequent processing of protocol related data.  The
protocol state is assumed to be associated to an application profile
(applicability) which provides the context for how messages are
transported, identified, and processed.
Paragraph (version B):
For each new/ongoing session, the endpoints are assumed to keep an
associated protocol state containing identifiers, keying material,
etc. used for subsequent processing of protocol related data.  The
protocol state is assumed to be associated with an application
profile (applicability) which provides the context for how messages
are transported, identified, and processed.
Paragraph (version B):
Compute the transcript hash TH_2 = H( G_Y, C_R, H(message_1) )
where H() is the EDHOC hash algorithm of the selected cipher
suite.  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 KEYSTREAM_2 as in expand, where plaintext_length is the
length of PLAINTEXT_2.
Paragraph (version B):
Compute KEYSTREAM_2 as in expand, where plaintext_length is the
length of PLAINTEXT_2.  For the case of plaintext_length
exceeding the EDHOC-KDF output size, see large-plaintext_2.
Paragraph (version A):
Verify Signature_or_MAC_2 using the algorithm in the selected
cipher suite.  The verification process depends on the method, see
asym-msg2-proc.
Paragraph (version B):
Verify Signature_or_MAC_2 using the algorithm in the selected
cipher suite.  The verification process depends on the method, see
asym-msg2-proc.  Make the result of the verification available to
the application.
Paragraph (version A):
Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R)
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 TH_3 can
be computed and cached already in the processing of message_2.
Paragraph (version B):
Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R)
where H() is the EDHOC hash algorithm of the selected cipher
suite.  The input to the hash function is a CBOR Sequence.  Note
that TH_3 can be computed and cached already in the processing of
message_2.
Paragraph (version A):
Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I)
where H() is the EDHOC hash algorithm of the selected cipher
suite.  The transcript hash TH_4 is a CBOR encoded bstr and the
input to the hash function is a CBOR Sequence.  Note that TH_4 can
be computed and cached already in the processing of message_3.
Paragraph (version B):
Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I)
where H() is the EDHOC hash algorithm of the selected cipher
suite.  The input to the hash function is a CBOR Sequence.  Note
that TH_4 can be computed and cached already in the processing of
message_3.
Paragraph (version A):
The Initiator SHOULD NOT persistently store PRK_out or application
keys until the Initiator has verified message_4 or a message
protected with a derived application key, such as an OSCORE message,
from the Responder.  This is similar to waiting for acknowledgement
(ACK) in a transport protocol.
Paragraph (version B):
The Initiator SHOULD NOT persistently store PRK_out or application
keys until the Initiator has verified message_4 or a message
protected with a derived application key, such as an OSCORE message,
from the Responder.  This is similar to waiting for an
acknowledgement (ACK) in a transport protocol.
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg3-proc.
Discard the padding PAD_3, if present.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg3-proc.
Paragraph (version A):
Verify Signature_or_MAC_3 using the algorithm in the selected
cipher suite.  The verification process depends on the method, see
asym-msg3-proc.
Paragraph (version B):
Verify Signature_or_MAC_3 using the algorithm in the selected
cipher suite.  The verification process depends on the method, see
asym-msg3-proc.  Make the result of the verification available to
the application.
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg4-proc.
Discard the padding PAD_4, if present.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg4-proc.
Paragraph (version A):
This section defines the format for error messages, and the
processing associated to the currently defined error codes.
Additional error codes may be registered, see error-code-reg.
Paragraph (version B):
This section defines the format for error messages, and the
processing associated with the currently defined error codes.
Additional error codes may be registered, see error-code-reg.
Paragraph (version A):
There are many kinds of errors that can occur during EDHOC
processing.  As in CoAP, an error can be triggered by errors in the
received message or internal errors in the receiving endpoint.
Except for processing and formatting errors, it is up to the
implementation when to send an error message.  Sending error messages
is essential for debugging but MAY be skipped if, for example, a
session cannot be found or due to denial-of-service reasons, see dos.
Errors messages in EDHOC are always fatal.  After sending an error
message, the sender MUST discontinue the protocol.  The receiver
SHOULD treat an error message as an indication that the other party
likely has discontinued the protocol.  But as the error message is
not authenticated, a received error message might also have been sent
by an attacker and the receiver MAY therefore try to continue the
protocol.
Paragraph (version B):
There are many kinds of errors that can occur during EDHOC
processing.  As in CoAP, an error can be triggered by errors in the
received message or internal errors in the receiving endpoint.
Except for processing and formatting errors, it is up to the
implementation when to send an error message.  Sending error messages
is essential for debugging but MAY be skipped if, for example, a
session cannot be found or due to denial-of-service reasons, see dos.
Error messages in EDHOC are always fatal.  After sending an error
message, the sender MUST discontinue the protocol.  The receiver
SHOULD treat an error message as an indication that the other party
likely has discontinued the protocol.  But as the error message is
not authenticated, a received error message might also have been sent
by an attacker and the receiver MAY therefore try to continue the
protocol.
Paragraph (version A):
Error code 2 MUST only be used when replying to message_1 in case the
cipher suite selected by the Initiator is not supported by the
Responder, or if the Responder supports a cipher suite more preferred
by the Initiator than the selected cipher suite, see resp-proc-msg1.
ERR_INFO is in this case denoted SUITES_R and is of type suites, see
asym-msg1-form.  If the Responder does not support the selected
cipher suite, then SUITES_R MUST include one or more supported cipher
suites.  If the Responder supports a cipher suite in SUITES_I other
than the selected cipher suite (independently of if the selected
cipher suite is supported or not) then SUITES_R MUST include the
supported cipher suite in SUITES_I which is most preferred by the
Initiator.  SUITES_R MAY include a single cipher suite, i.e., be
encoded as an int.  If the Responder does not support any cipher
suite in SUITES_I, then it SHOULD include all its supported cipher
suites in SUITES_R.
Paragraph (version B):
Error code 2 MUST only be used when replying to message_1 in case the
cipher suite selected by the Initiator is not supported by the
Responder, or if the Responder supports a cipher suite more preferred
by the Initiator than the selected cipher suite, see resp-proc-msg1.
In this case, ERR_INFO = SUITES_R and is of type suites, see asym-
msg1-form.  If the Responder does not support the selected cipher
suite, then SUITES_R MUST include one or more supported cipher
suites.  If the Responder supports a cipher suite in SUITES_I other
than the selected cipher suite (independently of if the selected
cipher suite is supported or not) then SUITES_R MUST include the
supported cipher suite in SUITES_I which is most preferred by the
Initiator.  SUITES_R MAY include a single cipher suite, in which case
it is encoded as an int.  If the Responder does not support any
cipher suite in SUITES_I, then it SHOULD include all its supported
cipher suites in SUITES_R.
Paragraph (version A):
If the Initiator intends to contact the Responder in the future, the
Initiator SHOULD remember which selected cipher suite to use until
the next message_1 has been sent, otherwise the Initiator and
Responder will likely run into an infinite loop where the Initiator
selects its most preferred and the Responder sends an error with
supported cipher suites.  After a successful run of EDHOC, the
Initiator MAY remember the selected cipher suite to use in future
EDHOC sessions.  Note that if the Initiator or Responder is updated
with new cipher suite policies, any cached information may be
outdated.
Paragraph (version B):
If the Initiator intends to contact the Responder in the future, the
Initiator SHOULD remember which selected cipher suite to use until
the next message_1 has been sent, otherwise the Initiator and
Responder will likely run into an infinite loop where the Initiator
selects its most preferred cipher suite and the Responder sends an
error with supported cipher suites.  After a successful run of EDHOC,
the Initiator MAY remember the selected cipher suite to use in future
EDHOC sessions.  Note that if the Initiator or Responder is updated
with new cipher suite policies, any cached information may be
outdated.
Paragraph (version A):
Implementations MAY support padding of plaintext when sending
messages.  Implementations MUST support padding of plaintext when
receiving messages, i.e., MUST be able to parse padded messages.
Paragraph (version B):
Implementations MUST support EAD.
Paragraph (version B):
Implementations MUST support cipher suite 2 and 3.  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) only differ in the size of the MAC length, so
supporting one or both of these is no essential difference.
Implementations only need to implement the algorithms needed for
their supported methods.
Paragraph (version A):
As described in SIGMA, different levels of identity protection are
provided to the Initiator and the Responder.  EDHOC provides identity
protection of the Initiator against active attacks and identity
protection of the Responder against passive attacks.  An active
attacker can get the credential identifier of the Responder by
eavesdropping on the destination address used for transporting
message_1 and send its own message_1 to the same address.  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 provides identity
protection of the Initiator against active attacks and identity
protection of the Responder against passive attacks.  An active
attacker can get the credential identifier of the Responder by
eavesdropping on the destination address used for transporting
message_1 and then sending its own message_1 to the same address.
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):
EDHOC messages might change in transit due to a noisy channel or
through modification by an attacker.  Changes in message_1 and
message_2 (except Signature_or_MAC_2 when the signature scheme is not
strongly unforgeable) are detected when verifying Signature_or_MAC_2.
Changes to not strongly unforgeable Signature_or_MAC_2, and message_3
are detected when verifying CIPHERTEXT_3.  Changes to message_4 are
detected when verifying CIPHERTEXT_4.
Paragraph (version A):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  EDHOC therefore only supports methods with
ephemeral Diffie-Hellman and provides a key update function (see
keyupdate) for lightweight application protocol rekeying.  Either of
these provide forward secrecy, in the sense that compromise of the
private authentication keys does not compromise past session keys
(PRK_out), and compromise of a session key does not compromise past
session keys.  Frequently re-running EDHOC with ephemeral Diffie-
Hellman forces attackers to perform dynamic key exfiltration where
the attacker must have continuous interactions with the collaborator,
which is a significant complication.
Paragraph (version B):
As required by RFC7258, IETF protocols need to mitigate pervasive
monitoring when possible.  EDHOC therefore only supports methods with
ephemeral Diffie-Hellman and provides a key update function (see
keyupdate) for lightweight application protocol rekeying.  Either of
these provides forward secrecy, in the sense that compromise of the
private authentication keys does not compromise past session keys
(PRK_out), and compromise of a session key does not compromise past
session keys.  Frequently re-running EDHOC with ephemeral Diffie-
Hellman forces attackers to perform dynamic key exfiltration where
the attacker must have continuous interactions with the collaborator,
which is a significant complication.
Paragraph (version B):
To limit the effect of breaches, it is important to limit the use of
symmetric group keys for bootstrapping.  EDHOC therefore strives to
make the additional cost of using raw public keys and self-signed
certificates as small as possible.  Raw public keys and self-signed
certificates are not a replacement for a public key infrastructure
but SHOULD be used instead of symmetric group keys for bootstrapping.
Paragraph (version A):
As the EDHOC protocol is terminated when verification fails, the
security against online attacks is given by the sum of the strength
of the verified signatures and MACs (including MAC in AEAD).  As an
example, if EDHOC is used with method 3, cipher suite 2, and
message_4, the Responder is authenticated with 128-bit security
against online attacks (the sum of the 64-bit MACs in message_2 and
message_4).  The same principle applies for MACs in an application
protocol keyed by EDHOC as long as EDHOC is rerun when verification
of the first MACs in the application protocol fail.  As an example,
if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of
I-D.ietf-core-oscore-edhoc, 128-bit mutual authentication against
online attacks can be achieved after completion of the first OSCORE
request and response.
Paragraph (version B):
As the EDHOC protocol is terminated when verification fails, the
security against online attacks is given by the sum of the strength
of the verified signatures and MACs (including MAC in AEAD).  As an
example, if EDHOC is used with method 3, cipher suite 2, and
message_4, the Responder is authenticated with 128-bit security
against online attacks (the sum of the 64-bit MACs in message_2 and
message_4).  The same principle applies for MACs in an application
protocol keyed by EDHOC as long as EDHOC is rerun when verification
of the first MACs in the application protocol fails.  As an example,
if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of
I-D.ietf-core-oscore-edhoc, 128-bit mutual authentication against
online attacks can be achieved after completion of the first OSCORE
request and response.
Paragraph (version A):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_out.  While the Initiator
can securely send protected application data, the Initiator SHOULD
NOT persistently store the keying material PRK_out until the
Initiator has verified an OSCORE message or message_4 from the
Responder.  After verifying message_3, the Responder is assured that
an honest Initiator has computed the key PRK_out.  The Responder can
securely derive and store the keying material PRK_out, and send
protected application data.
Paragraph (version B):
After sending message_3, the Initiator is assured that no other party
than the Responder can compute the key PRK_out.  While the Initiator
can securely send protected application data, the Initiator SHOULD
NOT persistently store the keying material PRK_out until the
Initiator has verified message_4 or a message protected with a
derived application key, such as an OSCORE message, from the
Responder.  After verifying message_3, the Responder is assured that
an honest Initiator has computed the key PRK_out.  The Responder can
securely derive and store the keying material PRK_out, and send
protected application data.
Paragraph (version A):
Two earlier versions of EDHOC have been formally analyzed Norrman20
Bruni18 and the specification has been updated based on the analysis.
Paragraph (version A):
The property that a completed EDHOC exchange implies that another
identity has been active is upheld as long as the Initiator does not
have its own identity in the set of Responder identities it is
allowed to communicate with.  In Trust on first use (TOFU) use cases,
see tofu, the Initiator should verify that the Responder's identity
is not equal to its own.  Any future EHDOC methods using e.g., pre-
shared keys might need to mitigate this in other ways.  However, an
active attacker can gain information about the set of identities an
Initiator is willing to communicate with.  If the Initiator is
willing to communicate with all identities except its own an attacker
can determine that a guessed Initiator identity is correct.  To not
leak any long-term identifiers, it is recommended to use a freshly
generated authentication key as identity in each initial TOFU
exchange.
Paragraph (version B):
The property that a completed EDHOC exchange implies that another
identity has been active is upheld as long as the Initiator does not
have its own identity in the set of Responder identities it is
allowed to communicate with.  In Trust on first use (TOFU) use cases,
see tofu, the Initiator should verify that the Responder's identity
is not equal to its own.  Any future EDHOC methods using e.g., pre-
shared keys might need to mitigate this in other ways.  However, an
active attacker can gain information about the set of identities an
Initiator is willing to communicate with.  If the Initiator is
willing to communicate with all identities except its own an attacker
can determine that a guessed Initiator identity is correct.  To not
leak any long-term identifiers, it is recommended to use a freshly
generated authentication key as identity in each initial TOFU
exchange.
Paragraph (version A):
When using private cipher suite or registering new cipher suites, the
choice of key length used in the different algorithms needs to be
harmonized, so that a sufficient security level is maintained for
certificates, EDHOC, and the protection of application data.  The
Initiator and the Responder should enforce a minimum security level.
Paragraph (version A):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.  As EDHOC integrity protects
the whole authentication credential, the choice of hash algorithm in
x5t and c5t does not affect security and it is RECOMMENDED to use the
same hash algorithm as in the cipher suite but with as much
truncation as possible, i.e., when the EDHOC hash algorithm is
SHA-256 it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The
EDHOC MAC length MUST be at least 8 bytes and the tag length of the
EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1
is only defined for use with ECDSA and not for ECDH.  Note that some
COSE algorithms are marked as not recommended in the COSE IANA
registry.
Paragraph (version B):
When using private cipher suite or registering new cipher suites, the
choice of key length used in the different algorithms needs to be
harmonized, so that a sufficient security level is maintained for
authentication credentials, the EDHOC protocol, and the protection of
application data.  The Initiator and the Responder should enforce a
minimum security level.
Paragraph (version B):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.  As EDHOC integrity protects
the whole authentication credentials, the choice of hash algorithm in
x5t and c5t does not affect security and it is RECOMMENDED to use the
same hash algorithm as in the cipher suite but with as much
truncation as possible, i.e., when the EDHOC hash algorithm is
SHA-256 it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The
EDHOC MAC length MUST be at least 8 bytes and the tag length of the
EDHOC AEAD algorithm MUST be at least 64-bits.  Note that secp256k1
is only defined for use with ECDSA and not for ECDH.  Note that some
COSE algorithms are marked as not recommended in the COSE IANA
registry.
Paragraph (version A):
An attacker observing network traffic may use connection identifiers
sent in clear in EDHOC or the subsequent application protocol to
correlate packets sent on different paths or at different times.  The
attacker may use this information for traffic flow analysis or to
track an endpoint.  Application protocols using connection
identifiers from EDHOC SHOULD provide mechanisms to update the
connection identifier and MAY provide mechanisms to issue several
simultaneously active connection identifiers.  See RFC9000 for a non-
constrained example of such mechanisms.  Connection identifiers can
e.g., be chosen randomly among the set of unused 1-byte connection
identifiers.  Connection identity privacy mechanisms are only useful
when there are not fixed identifiers such as IP address or MAC
address in the lower layers.
Paragraph (version B):
An attacker observing network traffic may use connection identifiers
sent in clear in EDHOC or the subsequent application protocol to
correlate packets sent on different paths or at different times.  The
attacker may use this information for traffic flow analysis or to
track an endpoint.  Application protocols using connection
identifiers from EDHOC SHOULD provide mechanisms to update the
connection identifiers and MAY provide mechanisms to issue several
simultaneously active connection identifiers.  See RFC9000 for a non-
constrained example of such mechanisms.  Connection identifiers can
e.g., be chosen randomly among the set of unused 1-byte connection
identifiers.  Connection identity privacy mechanisms are only useful
when there are not fixed identifiers such as IP address or MAC
address in the lower layers.
Paragraph (version A):
The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have
variable length and information regarding the length may leak to an
attacker.  An passive attacker may e.g., be able to differentiating
endpoints using identifiers of different length.  To mitigate this
information leakage an implementation may ensure that the fields have
fixed length or use padding.  An implementation may e.g., only use
fix length identifiers like 'kid' of length 1.  Alternatively padding
may be used to hide the true length of e.g., certificates by value in
'x5chain' or 'c5c'.
Paragraph (version B):
The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have
variable length, and information regarding the length may leak to an
attacker.  A passive attacker may, e.g., be able to differentiate
endpoints using identifiers of different length.  To mitigate this
information leakage an implementation may ensure that the fields have
fixed length or use padding.  An implementation may, e.g., only use
fixed length identifiers like 'kid' of length 1.  Alternatively,
padding may be used (see padding) to hide the true length of, e.g.,
certificates by value in 'x5chain' or 'c5c'.
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
RFC9175 which forces the CoAP client to demonstrate reachability at
its apparent network address.  To avoid an additional roundtrip the
Initiator can reduce the amplification factor by padding message_1,
see padding.
Paragraph (version B):
Implementations might consider deriving secret and non-secret
randomness from different PRNG/PRF/KDF instances to limit the damage
if the PRNG/PRF/KDF turns out to be fundamentally broken.  NIST
generally forbids deriving secret and non-secret randomness from the
same KDF instance, but this decision has been criticized by Krawczyk
HKDFpaper and doing so is common practice.  In addition to IVs, other
examples are the challenge in EAP-TTLS, the RAND in 3GPP AKAs, and
the Session-Id in EAP-TLS 1.3.  Note that part of KEYSTREAM_2 is also
non-secret randomness as it is known or predictable to an attacker.
As explained by Krawczyk, if any attack is mitigated by the NIST
requirement it would mean that the KDF is fully broken and would have
to be replaced anyway.
Paragraph (version A):
The Initiator and the Responder are allowed to select its connection
identifiers C_I and C_R, respectively, for the other party to use in
the ongoing EDHOC protocol as well as in a subsequent application
protocol (e.g., OSCORE RFC8613).  The choice of connection identifier
is not security critical in EDHOC but intended to simplify the
retrieval of the right security context in combination with using
short identifiers.  If the wrong connection identifier of the other
party is used in a protocol message it will result in the receiving
party not being able to retrieve a security context (which will
terminate the protocol) or retrieve the wrong security context (which
also terminates the protocol as the message cannot be verified).
Paragraph (version B):
The Initiator and the Responder are allowed to select the connection
identifier C_I and C_R, respectively, for the other party to use in
the ongoing EDHOC protocol as well as in a subsequent application
protocol (e.g., OSCORE RFC8613).  The choice of connection identifier
is not security critical in EDHOC but intended to simplify the
retrieval of the right security context in combination with using
short identifiers.  If the wrong connection identifier of the other
party is used in a protocol message it will result in the receiving
party not being able to retrieve a security context (which will
terminate the protocol) or retrieve the wrong security context (which
also terminates the protocol as the message cannot be verified).
Paragraph (version B):
If two nodes unintentionally initiate two simultaneous EDHOC message
exchanges with each other even if they only want to complete a single
EDHOC message exchange, they MAY terminate the exchange with the
lexicographically smallest G_X.  Note that in cases where several
EDHOC exchanges with different parameter sets (method, COSE headers,
etc.) are used, an attacker can affect which parameter set will be
used by blocking some of the parameter sets.
Paragraph (version A):
The sequence of transcript hashes in EHDOC (TH_2, TH_3, TH_4) do not
make use of a so called running hash, this is a design choice as
running hashes are often not supported on constrained platforms.
Paragraph (version B):
The sequence of transcript hashes in EDHOC (TH_2, TH_3, TH_4) does
not make use of a so called running hash.  This is a design choice as
running hashes are often not supported on constrained platforms.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC Method Type" under
the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The
registration procedure is "Specification Required".  The columns of
the registry are Value, Initiator Authentication Key, and Responder
Authentication Key, where Value is an integer and the other columns
are text strings describing the authentication keys.  The initial
contents of the registry are shown in fig-method-types.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC Error Codes" under
the new group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".  The
registration procedure is "Expert Review".  The columns of the
registry are ERR_CODE, ERR_INFO Type and Description, where ERR_CODE
is an integer, ERR_INFO is a CDDL defined type, and Description is a
text string.  The initial contents of the registry are shown in fig-
error-codes.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC External
Authorization Data" under the new group name "Ephemeral Diffie-
Hellman Over COSE (EDHOC)".  The registration procedure is
"Specification Required".  The columns of the registry are Label,
Description, and Reference, where Label is a positive integer and the
other columns are text strings.
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 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 B):
IANA has created a new registry entitled "EDHOC Method Type" under
the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)".
The registration procedure is "Specification Required" RFC8126.  The
columns of the registry are Value, Initiator Authentication Key, and
Responder Authentication Key, where Value is an integer and the other
columns are text strings describing the authentication keys.  The
initial contents of the registry are shown in fig-method-types.
Paragraph (version B):
IANA has created a new registry entitled "EDHOC Error Codes" under
the new registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)".
The registration procedure is "Expert Review" RFC8126.  The columns
of the registry are ERR_CODE, ERR_INFO Type and Description, where
ERR_CODE is an integer, ERR_INFO is a CDDL defined type, and
Description is a text string.  The initial contents of the registry
are shown in fig-error-codes.
Paragraph (version B):
IANA has created a new registry entitled "EDHOC External
Authorization Data" under the new registry group "Ephemeral Diffie-
Hellman Over COSE (EDHOC)".  The registration procedure is
"Specification Required" RFC8126.  The columns of the registry are
Label, Description, and Reference, where Label is a positive integer
and the other columns are text strings.
Paragraph (version B):
IANA has registered the following entries in the "COSE Header
Parameters" registry under the registry group "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):
IANA has added the well-known URI "edhoc" to the "Well-Known URIs"
registry under the group name "Well-Known URIs".
Paragraph (version B):
IANA has added the well-known URI "edhoc" to the "Well-Known URIs"
registry.
Paragraph (version A):
IANA has added the media types "application/edhoc+cbor-seq" and
"application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats"
registry under the group name "Constrained RESTful Environments
(CoRE) Parameters".
Paragraph (version A):
IANA has added the resource type "core.edhoc" to the "Resource Type
(rt=) Link Target Attribute Values" registry under the group name
"Constrained RESTful Environments (CoRE) Parameters".
Paragraph (version B):
IANA has added the media types "application/edhoc+cbor-seq" and
"application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats"
registry under the registry group "Constrained RESTful Environments
(CoRE) Parameters".
Paragraph (version B):
IANA has added the resource type "core.edhoc" to the "Resource Type
(rt=) Link Target Attribute Values" registry under the registry group
"Constrained RESTful Environments (CoRE) Parameters".
Paragraph (version A):
Clarity and correctness of registrations.  Experts are expected to
check the clarity of purpose and use of the requested entries.
Expert needs to make sure the values of algorithms are taken from
the right registry, when that is required.  Expert should consider
requesting an opinion on the correctness of registered parameters
from relevant IETF working groups.  Encodings that do not meet
these objective of clarity and completeness should not be
registered.
Paragraph (version B):
Clarity and correctness of registrations.  Experts are expected to
check the clarity of purpose and use of the requested entries.
Expert needs to make sure the values of algorithms are taken from
the right registry, when that is required.  Experts should
consider requesting an opinion on the correctness of registered
parameters from relevant IETF working groups.  Encodings that do
not meet these objective of clarity and completeness should not be
registered.