Draft: draft-ietf-lake-edhoc

Commentary: Reading through those changes now will note things arising here , first one is below . If an EAD item can occur more than once , do all occurrences of a given ead_label in one message or one session need to have the same criticality ? Presumably if any are marked critical then all could be , and vice - versa , so not sure if mixing is needed , and it might lead to unexpected outcomes maybe ? 
 Actually that 's my only comment on these changes - otherwise they look good . 
 Please check 
 Stephen 's pre - last - call comments : non - nits : 1 ) 3.5.2 , 2nd para : on what basis is rfc5280 a normative ref whilst [ I - D.ietf - cose - cbor - encoded - cert ] is informative ? They seem to be equally required for implementation based on this text . Given [ I - D.ietf - cose - x509 ] is normative , perhaps it would n't add delay if both were ? 2 ) 3.5.2 : I forget if use of the full DER - encoded X.509 cert was discussed on the list or not ? If not , the alternative would have been to use the SPKI which has some slightly different properties that can sometimes be beneficial ( potentially easier use of different CAs on each side ) . I 'm not asking for a change here btw , just to check was this discussed on the list . ( I see appendix D.2 talks a bit about this . ) 3 ) 5.2.3 : what happens if the decode of message1 fails ? ( Say due to an unknown suite . ) Does EAD1 get provided to the application ? I hope not ! Maybe the text after the bullets needs to specify this explicitly ? Same for other sections wrt providing EAD to the application ( esp EAD1 and EAD2 ) . 4 ) 9.4 : As the method field is how we handle breaking changes , do we really want that registry to be specification required ? The alternative might be standards action , if we prefer the IESG to be involved in such changes . nits : section 1.3 : this only mentions appendix A - is there a good reason for that or is it just text that 's not changed in ages ? Probably omitting or including mention of all appendices is better . section 2 , p8 bullet says " Verification of the selected cipher suite . " - that puzzled me a bit as I 'd have assumed that the transcript hashes provide / cover that validation ? If that 's the case maybe this bullet could be deleted , if not , be interested in what 's meant . reference to [ I - D.ietf - lake - traces ] : not really a comment on edhoc , but we should probably ask the WG if we want to hold publication of edhoc as an RFC until the traces work is also done ( i.e. create a small cluster for those two in the RFC editor queue ) . 3.4.1 , 2nd last para : the " MUST " statements here seem a bit bogus in 2119 interop terms . If those are only for emphasis , then s / MUST / must / might be better to avoid other people commenting on this later . 3.5.3 : the two example definitions for IDCREDX seem to be introducing a notation " { 4 : kidx } ... " before that notation is defined / referenced . Maybe add at least a forward pointer to 1.3 about such notations ? Or , if 1.4 is considered to cover this , then that 's fine . ( I did n't read all the referred things from 1.4:- ) 3.8 : I bet a beer EAD item criticality wo n't work as planned:- ) 3.8 : since zero is used for padding it 's not true to say " non - negative " means non - critical . 3.8 : Am I getting this right ? If I define a new EAD item " foo " with a codepoint of 17 then sending 17 means non - critical but sending -17 means " treat as critical " ? The text is n't quite clear ( here ) as to whether + x and -x mean the same EAD type , just with different criticality , or , whether + x and -x correspond to independent EAD item types . 3.8.1 : This leaves the reader wondering what is an " appropriate length " of padding ? I 'm also left wondering what is the point of padding in EAD1 which is not encrypted ? ( Is it only useful if there 's also some lower layer confidentiality ? ) 3.9 : " incompliance " - that 's a very uncommon word , maybe that 'd be better rephrased e.g. s / incompliance / lack of compliance/ ? 3.9 : it correctly says here 1 transport may be used , but earlier ( last para of 3.4 before 3.4.1 ) it said I and R " need to have agreed on a transport " ( note the singular ) . I 'd change or delete the text in 3.4 rather than that in 9 probably . 4.1.1 refers to Figure 8 but that 's a few pages ahead and the names of the keys ( e.g. PRK3e2 m ) are n't intuitive . It 'd be good to somehow introduce those names earlier , maybe just by moving Figure 8 earlier , but at least by pointing out the naming scheme ( that PRK2 refers to message 2 and how etc . ) . In any case , it 'd be good to do an editorial pass with the goal of making understanding the key derivation easier for a new reader . ( Requiring readers to reverse engineer that seems sub - optimal:- ) 4.1.1/4.1.2 maybe " Extract ( ) " and " Expand ( ) " are n't the best function names ? Those probably exist already in lots of libraries . Perhaps " EDHOCExpand ( ) " etc . would make it easier to map implementations to the spec ? Or whatever names are used in current implementations . ( I 'd also s / EDHOC - KDF / EDHOCKDF / g to get a name that works for compilers and same for EDHOC - Exporter . ) Figure 8 looks more like a table than a figure:-)4.1.3 : TEE is used without expansion.4.2.1 : just checking - there 's a lowercase " must " there - is that intentional ? ( It could be correct as it says " must be unique " which is always tricky:- ) section 5 : As a non - implementer , I did n't understand the " MAY contain parameters " sentence there . 5.1 : What 's a " session " ? I think that 's a nit , but wonder a bit if someone 's tested / analysed in case there 's any odd state that can be reached if a node has forgotten state but receives a message assuming the state is known / stored . It 's probably ok though . 5.1 : is " SHALL be processed " right ? Maybe just " are processed " is ok ? ( Just trying to avoid others asking this again , I do n't really care myself:- ) 5.3.2 : " the length of the protocol " seems to mean " for that session " but neither is that well defined - could this be made more precise ? 5.3.2 : The " < < ... " notation was n't described so far . ( See earlier comment wrt 1.4 ) 6.3.2 , figure 11 : Should n't GX in the 2nd message1 be GX ' or something to indicate a different DH public value ? Is the same  meant to be sent in both  's or not ? Appendix A.2 : This has an RFC2119 SHOULD . If the intent was that none of the appendices had such terms , that 'd be wrong , but I 'm not sure if that was the intent of the WG . ( There are more examples of 2119 terms in appendices . ) Might be good to say ( e.g. in 1.4 ) whether or not such 2119 terms are important for implementers who might otherwise ignore 'em . Appendix C.1 ends with a table ( with no label / caption ) that does n't seem to have text describing it anywhere ? Appendix I : This seems to describe an optional to implement thing that has two internal options . I do n't see that the text tells me which I ought implement , if I choose to try support long plaintexts . The problem is indicated by the paras beginning " A potential work - around ... " and the following one starting " Another solution ... " I read those as two different ways to handle long plaintexts . ) Appendix J : If you do s / EDHOC - KDF / EDHOCKDF/ then I guess you 'll also do s / EDHOC - KeyUpdate / EDHOCKeyUpdate/ maybe . Acks : Sad to say it , and I 'm not sure which is best , but maybe consider s /   / the late Jim Schaad/ ? Hard to know how to phrase that well though:- ( 
 nits : section 1.3 : this only mentions appendix A - is there a good reason for that or is it just text that 's not changed in ages ? Probably omitting or including mention of all appendices is better . Included all sections before security considerations . section 2 , p8 bullet says " Verification of the selected cipher suite . " - that puzzled me a bit as I 'd have assumed that the transcript hashes provide / cover that validation ? If that 's the case maybe this bullet could be deleted , if not , be interested in what 's meant . change to " negotiation of ciphersuite " , with clarification reference to [ I - D.ietf - lake - traces ] : not really a comment on edhoc , but we should probably ask the WG if we want to hold publication of edhoc as an RFC until the traces work is also done ( i.e. create a small cluster for those two in the RFC editor queue ) . OK , let 's keep that in mind :-) 3.4.1 , 2nd last para : the " MUST " statements here seem a bit bogus in 2119 interop terms . If those are only for emphasis , then s / MUST / must / might be better to avoid other people commenting on this later . Did n't find any MUSTs in 3.4.1 , did you mean 3.5.0 ? The interaction between EDHOC and application is kinda critical on this point , but perhaps is not a compliance requirement ? 3.5.3 : the two example definitions for IDCREDX seem to be introducing a notation " { 4 : kidx } ... " before that notation is defined / referenced . Maybe add at least a forward pointer to 1.3 about such notations ? Or , if 1.4 is considered to cover this , then that 's fine . ( I did n't read all the referred things from 1.4:- ) Check updated text and see if it reads better . 3.8 : I bet a beer EAD item criticality wo n't work as planned:- ) So I obviously had to rewrite stuff to not lose the beer :-) Check updated text and see if it reads better . 3.8 : since zero is used for padding it 's not true to say " non - negative " means non - critical . 3.8 : Am I getting this right ? If I define a new EAD item " foo " with a codepoint of 17 then sending 17 means non - critical but sending -17 means " treat as critical " ? The text is n't quite clear ( here ) as to whether + x and -x mean the same EAD type , just with different criticality , or , whether + x and -x correspond to independent EAD item types . Check updated text and see if it reads better . 3.8.1 : This leaves the reader wondering what is an " appropriate length " of padding ? I 'm also left wondering what is the point of padding in EAD1 which is not encrypted ? ( Is it only useful if there 's also some lower layer confidentiality ? ) I reasons for padding . Check updated text and see if it reads better . 3.9 : " incompliance " - that 's a very uncommon word , maybe that 'd be better rephrased e.g. s / incompliance / lack of compliance/ ? Done . 3.9 : it correctly says here 1 transport may be used , but earlier ( last para of 3.4 before 3.4.1 ) it said I and R " need to have agreed on a transport " ( note the singular ) . I 'd change or delete the text in 3.4 rather than that in 3.9 probably . Check updated text and see if it reads better . 4.1.1 refers to Figure 8 but that 's a few pages ahead and the names of the keys ( e.g. PRK3e2 m ) are n't intuitive . It 'd be good to somehow introduce those names earlier , maybe just by moving Figure 8 earlier , but at least by pointing out the naming scheme ( that PRK2 refers to message 2 and how etc . ) . In any case , it 'd be good to do an editorial pass with the goal of making understanding the key derivation easier for a new reader . ( Requiring readers to reverse engineer that seems sub - optimal:- ) I did an editorial pass . Check updated text and see if it reads better . 4.1.1/4.1.2 maybe " Extract ( ) " and " Expand ( ) " are n't the best function names ? Those probably exist already in lots of libraries . Perhaps " EDHOCExpand ( ) " etc . would make it easier to map implementations to the spec ? Or whatever names are used in current implementations . ( I 'd also s / EDHOC - KDF / EDHOCKDF / g to get a name that works for compilers and same for EDHOC - Exporter . ) Done . This was discussed before , and changed in the opposite direction , but I think your argument makes sense . Figure 8 looks more like a table than a figure:- ) Noted . That applies to many of the " figures " . Not done :-) 4.1.3 : TEE is used without expansion . Done . 4.2.1 : just checking - there 's a lowercase " must " there - is that intentional ? ( It could be correct as it says " must be unique " which is always tricky:- ) Yes , that is intentional . The MUST comes in the following sentence . section 5 : As a non - implementer , I did n't understand the " MAY contain parameters " sentence there . Good question . It is a correct statement in terms of COSE formats , but I 'm not convinced it is relevant . I make a separate issue of that . 5.1 : What 's a " session " ? I think that 's a nit , but wonder a bit if someone 's tested / analysed in case there 's any odd state that can be reached if a node has forgotten state but receives a message assuming the state is known / stored . It 's probably ok though . EDHOC session is used throughout the document . Check updated text and see if it reads better . 5.1 : is " SHALL be processed " right ? Maybe just " are processed " is ok ? ( Just trying to avoid others asking this again , I do n't really care  ) This is actually an important statement . If e.g. message2 is received it shall not be processed unless the protocol state indicates that it is waiting for message2 as it might e.g. be a replay . Can we state this more clearly ? 5.3.2 : " the length of the protocol " seems to mean " for that session " but neither is that well defined - could this be made more precise ? Changed to " EDHOC session " . 5.3.2 : The " < < ... " notation was n't described so far . ( See earlier comment wrt 1.4 ) Check updated text and see if it reads better . 6.3.2 , figure 11 : Should n't GX in the 2nd message1 be GX ' or something to indicate a different DH public value ? Is the same  meant to be sent in both  's or not ? Good catch , thanks ! Appendix A.2 : This has an RFC2119 SHOULD . If the intent was that none of the appendices had such terms , that 'd be wrong , but I 'm not sure if that was the intent of the WG . ( There are more examples of 2119 terms in appendices . ) Might be good to say ( e.g. in 1.4 ) whether or not such 2119 terms are important for implementers who might otherwise ignore 'em . Check updated text in 1.4 and see if it reads better . Appendix C.1 ends with a table ( with no label / caption ) that does n't seem to have text describing it anywhere ? Check updated text and see if it reads better . Appendix I : This seems to describe an optional to implement thing that has two internal options . I do n't see that the text tells me which I ought implement , if I choose to try support long plaintexts . The problem is indicated by the paras beginning " A potential work - around ... " and the following one starting " Another solution ... " I read those as two different ways to handle long plaintexts . ) Check updated text and see if it reads better . Appendix J : If you do s / EDHOC - KDF / EDHOCKDF/ then I guess you 'll also do s / EDHOC - KeyUpdate / EDHOC_KeyUpdate/ maybe . Done . Acks : Sad to say it , and I 'm not sure which is best , but maybe consider s /   / the late Jim Schaad/ ? Hard to know how to phrase that well though:- ( Check updated text and see if it reads better . 
 Nits merged . Question sent to WG . Closing now . 
 As part of my shepherding write - up , I had a closer look at the IANA considerations section . Section 9.5 : EDHOC External Authorization Data Registry is not properly initialized and the text in the draft seems inconsistent . Section 9.5 requests the label be registered as a positive integer while section 3.8 mentions non - negative values for non - critical usage , and negative values of label for critical usage . eadlabel of 0 for padding is not registered . Further , in the text of Section 3.8 , the draft states : Please remove the notion of positive eadlabel here , as it is expanded further down in the text . Just to confirm , the for usage with EDHOC - KDF is an internal parameter and therefore does not need its own registry . Correct ? 
 One commit intended to clarify . Yes , info_label is only used within EDHOC . 
 Further update of this text in . Please have a look if this is fixed . 
 Closing this as no objection received .
Mailing list commentary: Hiya , While warming up to hit the pub - req button for edhoc I gave draft-18 a full read - through . I have a few non - nit comments ( some just questions ) and a bunch of nits , all of which are fine to process as part of IETF last call . ( IOW , I do n't see a need to hold up hitting the pub - req button to handle any of these . ) To be clear ; these are comments made whilst wearing no hat at all - I 'll chat with my co - chair shortly about hitting that pub - req button:- ) Lastly - for a 100 page document , this seems entirely credible for implementations that interoperate . That 's really quite an achievement , so well done all ! ,     : 1 ) 3.5.2 , 2nd para : on what basis is rfc5280 a normative ref whilst [ I - D.ietf - cose - cbor - encoded - cert ] is informative ? They seem to be equally required for implementation based on this text . Given [ I - D.ietf - cose - x509 ] is normative , perhaps it would n't add delay if both were ? 2 ) 3.5.2 : I forget if use of the full DER - encoded X.509 cert was discussed on the list or not ? If not , the alternative would have been to use the SPKI which has some slightly different properties that can sometimes be beneficial ( potentially easier use of different CAs on each side ) . I ' m not asking for a change here btw , just to check was this discussed on the list . ( I see appendix D.2 talks a bit about this . ) 3 ) 5.2.3 : what happens if the decode of message1 fails ? ( Say due to an unknown suite . ) Does EAD1 get provided to the application ? I hope not ! Maybe the text after the bullets needs to specify this explicitly ? Same for other sections wrt providing EAD to the application ( esp EAD1 and EAD2 ) . 4 ) 9.4 : As the method field is how we handle breaking changes , do we really want that registry to be specification required ? The alternative might be standards action , if we prefer the IESG to be involved in such changes . nits : section 1.3 : this only mentions appendix A - is there a good reason for that or is it just text that 's not changed in ages ? Probably omitting or including mention of all appendices is better . section 2 , p8 bullet says " Verification of the selected cipher suite . " - that puzzled me a bit as I 'd have assumed that the transcript hashes provide / cover that validation ? If that 's the case maybe this bullet could be deleted , if not , be interested in what 's meant . reference to [ I - D.ietf - lake - traces ] : not really a comment on edhoc , but we should probably ask the WG if we want to hold publication of edhoc as an RFC until the traces work is also done ( i.e. create a small cluster for those two in the RFC editor queue ) . 3.4.1 , 2nd last para : the " MUST " statements here seem a bit bogus in 2119 interop terms . If those are only for emphasis , then s / MUST / must / might be better to avoid other people commenting on this later . 3.5.3 : the two example definitions for IDCREDX seem to be introducing a notation " { 4 : kidx } ... " before that notation is defined / referenced . Maybe add at least a forward pointer to 1.3 about such notations ? Or , if 1.4 is considered to cover this , then that 's fine . ( I did n't read all the referred things from 1.4:- ) 3.8 : I bet a beer EAD item criticality wo n't work as planned:- ) 3.8 : since zero is used for padding it 's not true to say " non - negative " means non - critical . 3.8 : Am I getting this right ? If I define a new EAD item " foo " with a codepoint of 17 then sending 17 means non - critical but sending -17 means " treat as critical " ? The text is n't quite clear ( here ) as to whether + x and -x mean the same EAD type , just with different criticality , or , whether + x and -x correspond to independent EAD item types . 3.8.1 : This leaves the reader wondering what is an " appropriate length " of padding ? I ' m also left wondering what is the point of padding in EAD1 which is not encrypted ? ( Is it only useful if there 's also some lower layer confidentiality ? ) 3.9 : " incompliance " - that 's a very uncommon word , maybe that 'd be better rephrased e.g. s / incompliance / lack of compliance/ ? 3.9 : it correctly says here > 1 transport may be used , but earlier ( last para of 3.4 before 3.4.1 ) it said I and R " need to have agreed on a transport " ( note the singular ) . I 'd change or delete the text in 3.4 rather than that in 3.9 probably . 4.1.1 refers to Figure 8 but that 's a few pages ahead and the names of the keys ( e.g. PRK3e2 m ) are n't intuitive . It 'd be good to somehow introduce those names earlier , maybe just by moving Figure 8 earlier , but at least by pointing out the naming scheme ( that PRK2 refers to message 2 and how etc . ) . In any case , it 'd be good to do an editorial pass with the goal of making understanding the key derivation easier for a new reader . ( Requiring readers to reverse engineer that seems sub - optimal:- ) 4.1.1/4.1.2 maybe " Extract ( ) " and " Expand ( ) " are n't the best function names ? Those probably exist already in lots of libraries . Perhaps " EDHOCExpand ( ) " etc . would make it easier to map implementations to the spec ? Or whatever names are used in current implementations . ( I 'd also s / EDHOC - KDF / EDHOCKDF / g to get a name that works for compilers and same for EDHOC - Exporter . ) Figure 8 looks more like a table than a figure:- ) 4.1.3 : TEE is used without expansion .4.2.1 : just checking - there 's a lowercase " must " there - is that intentional ? ( It could be correct as it says " must be unique " which is always tricky:- ) section 5 : As a non - implementer , I did n't understand the " MAY contain parameters " sentence there . 5.1 : What 's a " session " ? I think that 's a nit , but wonder a bit if someone 's tested / analysed in case there 's any odd state that can be reached if a node has forgotten state but receives a message assuming the state is known / stored . It 's probably ok though . 5.1 : is " SHALL be processed " right ? Maybe just " are processed " is ok ? ( Just trying to avoid others asking this again , I do n't really care ) 5.3.2 : " the length of the protocol " seems to mean " for that session " but neither is that well defined - could this be made more precise ? 5.3.2 : The " > " notation was n't described so far . ( See earlier comment wrt 1.4 ) 6.3.2 , figure 11 : Should n't GX in the 2nd message1 be GX ' or something to indicate a different DH public value ? Is the same  meant to be sent in both  's or not ? Appendix A.2 : This has an RFC2119 SHOULD . If the intent was that none of the appendices had such terms , that 'd be wrong , but I ' m not sure if that was the intent of the WG . ( There are more examples of 2119 terms in appendices . ) Might be good to say ( e.g. in 1.4 ) whether or not such 2119 terms are important for implementers who might otherwise ignore 'em . Appendix C.1 ends with a table ( with no label / caption ) that does n't seem to have text describing it anywhere ? Appendix I : This seems to describe an optional to implement thing that has two internal options . I do n't see that the text tells me which I ought implement , if I choose to try support long plaintexts . The problem is indicated by the paras beginning " A potential work - around ... " and the following one starting " Another solution ... " I read those as two different ways to handle long plaintexts . ) Appendix J : If you do s / EDHOC - KDF / EDHOCKDF/ then I guess you 'll also do s / EDHOC - KeyUpdate / EDHOC_KeyUpdate/ maybe . Acks : Sad to say it , and I ' m not sure which is best , but maybe consider s / / the late Jim Schaad/ ? Hard to know how to phrase that well though:- (
Paragraph (version A):
The remainder of the document is organized as follows: background
outlines EDHOC authenticated with signature keys, overview describes
the protocol elements of EDHOC, including formatting of the ephemeral
public keys, key-der specifies the key derivation, asym specifies
message processing for EDHOC authenticated with signature keys or
static Diffie-Hellman keys, error describes the error messages, and
transfer shows how to transfer EDHOC with CoAP and establish an
OSCORE security context.
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version B):
The remainder of the document is organized as follows: background
outlines EDHOC authenticated with signature keys, overview describes
the protocol elements of EDHOC, including formatting of the ephemeral
public keys, key-der specifies the key derivation, asym specifies
message processing for EDHOC authenticated with signature keys or
static Diffie-Hellman keys, error describes the error messages, and
mti lists compliance requirements.  Note that normative text is also
used in appendices, in particular transfer.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.
Paragraph (version A):
Verification of the selected cipher suite.
Paragraph (version B):
Secure negotiation of cipher suite.
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 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 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):
The Initiator and the Responder need to have agreed on a transport to
be used for EDHOC, see applicability.
Paragraph (version B):
The use of transport is specified in the application profile
applicability.
Paragraph (version A):
ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more
COSE header parameters.  ID_CRED_I and ID_CRED_R MAY contain
different header parameters.  The header parameters typically provide
some information about the format of the credential.
Paragraph (version B):
ID_CRED_I and ID_CRED_R are of type COSE header_map, as defined in
Section 3 of RFC9052, and contains one or more COSE header
parameters.  ID_CRED_I and ID_CRED_R MAY contain different header
parameters.  The header parameters typically provide some information
about the format of the credential.
Paragraph (version A):
Each application may register EAD label(s), see iana-ead, 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 A):
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 IANA registry defines only the non-negative ead_label,
the same ead_value applies independent of sign of ead_label.  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 A):
If an endpoint receives a critical EAD item it does not recognize or
a critical EAD item that contains information that it cannot process,
then the endpoint MUST send an EDHOC error message back as defined in
error, and the protocol MUST be discontinued.  The EAD specification
must define the error processing.  A non-critical EAD item can be
ignored.
Paragraph (version B):
A security application may register one or more EAD labels, see iana-
ead, and specify the associated processing and security
considerations.  The IANA registry contains the absolute value of the
ead_label, |ead_label|; the same ead_value applies independently of
sign of ead_label.
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 EAD field.
A negative value indicates that the EAD item is critical and a non-
negative value indicates that the EAD item is non-critical.
Paragraph (version B):
If an endpoint receives a critical EAD item it does not recognize, or
a critical EAD item that contains information that it cannot process,
then the endpoint MUST send an EDHOC error message back as defined in
error, and the protocol MUST be discontinued.  The EAD item
specification defines the error processing.  A non-critical EAD item
can be ignored.
Paragraph (version B):
The security application registering a new EAD item 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):
The security application may define multiple uses of certain EAD
items, e.g., the same EAD item may be used in different EDHOC
messages.  Multiple occurrences of an EAD item in one EAD field may
also be specified, but the criticality of the repeated EAD item is
expected to be the same.
Paragraph (version B):
EDHOC message_1 and the plaintext of message_2, message_3 and
message_4 can be padded with the use of the corresponding EAD_x
field, for x = 1, 2, 3, 4.  Padding in EAD_1 mitigates amplification
attacks (see dos), and padding in EAD_2, EAD_3, and EAD_4 hides the
true length of the plaintext (see internet-threat).  Padding is
intended to be discarded by the receiving application.
Paragraph (version B):
Note that padding is non-critical because the intended behaviour when
receiving is to ignore it.
Paragraph (version A):
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 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
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 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 lack of
compliance, 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 lack of
compliance 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):
EDHOC uses Extract-and-Expand RFC5869 with the EDHOC hash algorithm
in the selected cipher suite to derive keys used in message
processing.  This section defines Extract (extract) and Expand
(expand), and how to use them to derive PRK_out (prkout) which is the
shared secret session key resulting from a successful EDHOC exchange.
Paragraph (version A):
Extract is used to derive fixed-length uniformly pseudorandom keys
(PRK) from ECDH shared secrets.  Expand is used to define EDHOC-KDF
for generating MACs and for deriving output keying material (OKM)
from PRKs.
Paragraph (version A):
In EDHOC a specific message is protected with a certain pseudorandom
key, but how the key is derived depends on the method as detailed in
asym.
Paragraph (version A):
The rest of the section defines the pseudorandom keys PRK_2e,
PRK_3e2m and PRK_4e3m; their use is shown in fig-edhoc-kdf.
Paragraph (version B):
EDHOC uses Extract-and-Expand RFC5869 with the EDHOC hash algorithm
in the selected cipher suite to derive keys used in message
processing.  This section defines EDHOC_Extract (extract) and
EDHOC_Expand (expand), and how to use them to derive PRK_out (prkout)
which is the shared secret session key resulting from a successful
EDHOC exchange.
Paragraph (version B):
EDHOC_Extract is used to derive fixed-length uniformly pseudorandom
keys (PRK) from ECDH shared secrets.  EDHOC_Expand is used to define
EDHOC_KDF for generating MACs and for deriving output keying material
(OKM) from PRKs.
Paragraph (version B):
In EDHOC a specific message is protected with a certain pseudorandom
key, but how the key is derived depends on the authentication method
(method) as detailed in asym.
Paragraph (version B):
The rest of the section defines the pseudorandom keys PRK_2e,
PRK_3e2m and PRK_4e3m; their use is shown in fig-edhoc-kdf.  The
index of a PRK indicates its use or in what message protection
operation it is involved.  For example, PRK_3e2m is involved in the
encryption of message 3 and in calculating the MAC of message 2.
Paragraph (version A):
When EDHOC-KDF is used to derive OKM for EDHOC message processing,
then context includes one of the transcript hashes TH_2, TH_3, or
TH_4 defined in Sections asym-msg2-proc and asym-msg3-proc.
Paragraph (version B):
When EDHOC_KDF is used to derive OKM for EDHOC message processing,
then context includes one of the transcript hashes TH_2, TH_3, or
TH_4 defined in Sections asym-msg2-proc and asym-msg3-proc.
Paragraph (version A):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is
the output session key of a successful EDHOC exchange.  Keys for
applications are derived from PRK_out, see exporter.  For the purpose
of using EDHOC-Exporter, an application only needs to store PRK_out
or PRK_exporter.  (Note that the word "store" used here does not
imply that the application has access to the plaintext PRK_out since
that may be reserved for code within a TEE, see impl-cons).
Paragraph (version A):
This section defines EDHOC-Exporter in terms of EDHOC-KDF and
PRK_out.  A key update function is defined in keyupdate.
Paragraph (version B):
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is
the output session key of a successful EDHOC exchange.
Paragraph (version B):
Keys for applications are derived using EDHOC_Exporter from
PRK_exporter (see exporter) which in turn is derived from PRK_out.
For the purpose of generating application keys, it is sufficient to
store PRK_out or PRK_exporter.  (Note that the word "store" used here
does not imply that the application has access to the plaintext
PRK_out since that may be reserved for code within a Trusted
Execution Environment, see impl-cons).
Paragraph (version B):
This section defines EDHOC_Exporter in terms of EDHOC_KDF and
PRK_out.  A key update function is defined in keyupdate.
Paragraph (version A):
The (exporter_label, context) pair used in EDHOC-Exporter must be
unique, i.e., an (exporter_label, context) MUST NOT be used for two
different purposes.  However an application can re-derive the same
key several times as long as it is done in a secure way.  For
example, in most encryption algorithms the same key can be reused
with different nonces.  The context can for example be the empty CBOR
byte string.
Paragraph (version B):
The (exporter_label, context) pair used in EDHOC_Exporter must be
unique, i.e., an (exporter_label, context) MUST NOT be used for two
different purposes.  However an application can re-derive the same
key several times as long as it is done in a secure way.  For
example, in most encryption algorithms the same key can be reused
with different nonces.  The context can for example be the empty CBOR
byte string.
Paragraph (version A):
Examples of use of the EDHOC-Exporter are given in transfer.
Paragraph (version B):
Examples of use of the EDHOC_Exporter are given in transfer.
Paragraph (version A):
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
structures, only a subset of the parameters is included in the EDHOC
messages, see COSE.  The unprotected COSE header in COSE_Sign1, and
COSE_Encrypt0 (not included in the EDHOC message) MAY contain
parameters (e.g., 'alg').
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 with an application
profile (applicability) which provides the context for how messages
are transported, identified, and processed.
Paragraph (version B):
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
structures, only a subset of the parameters is included in the EDHOC
messages, see COSE.  In order to recreate the COSE object, the
recipient endpoint may need to add parameters to the COSE headers not
included in the EDHOC message, for example the parameter 'alg' to
COSE_Sign1 or COSE_Encrypt0.
Paragraph (version B):
For each new/ongoing EDHOC 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 A):
Choose a connection identifier C_I and store it for the length of
the protocol.
Paragraph (version B):
Choose a connection identifier C_I and store it during the EDHOC
session.
Paragraph (version A):
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 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):
Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can
now derive application keys using the EDHOC-Exporter interface,
see exporter.
Paragraph (version B):
Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can
now derive application keys using the EDHOC_Exporter interface,
see exporter.
Paragraph (version A):
After verifying message_3, the Responder can compute PRK_out, see
prkout, derive application keys using the EDHOC-Exporter interface,
see exporter, persistently store the keying material, and send
protected application data.
Paragraph (version B):
After verifying message_3, the Responder can compute PRK_out, see
prkout, derive application keys using the EDHOC_Exporter interface,
see exporter, persistently store the keying material, and send
protected application data.
Paragraph (version B):
Note that the content of the fields of message_1 may be different
when sent the second time, in particular the ephemeral key MUST be
different.
Paragraph (version A):
Implementations MUST support the EDHOC-Exporter.
Paragraph (version B):
Implementations MUST support the EDHOC_Exporter.
Paragraph (version A):
EDHOC-Exporter.
Paragraph (version B):
EDHOC_Exporter.
Paragraph (version B):
Earlier versions of EDHOC have been formally analyzed Bruni18
Norrman20 CottierPointcheval22 Jacomme23 GuentherIlunga22 and the
specification has been updated based on the analysis.
Paragraph (version A):
As discussed in SIGMA, the encryption of message_2 does only need to
protect against passive attacker as active attackers can always get
the Responder's identity by sending their own message_1.  EDHOC uses
the Expand function (typically HKDF-Expand) as a binary additive
stream cipher which is proven secure as long as the expand function
is a PRF.  HKDF-Expand is not often used as a stream cipher as it is
slow on long messages, and most applications require both IND-CCA
confidentiality as well as integrity protection.  For the encryption
of message_2, any speed difference is negligible, IND-CCA does not
increase security, and integrity is provided by the inner MAC (and
signature depending on method).
Paragraph (version B):
As discussed in SIGMA, the encryption of message_2 does only need to
protect against passive attacker as active attackers can always get
the Responder's identity by sending their own message_1.  EDHOC uses
the EDHOC_Expand function (typically HKDF-Expand) as a binary
additive stream cipher which is proven secure as long as the expand
function is a PRF.  HKDF-Expand is not often used as a stream cipher
as it is slow on long messages, and most applications require both
IND-CCA confidentiality as well as integrity protection.  For the
encryption of message_2, any speed difference is negligible, IND-CCA
does not increase security, and integrity is provided by the inner
MAC (and signature depending on method).
Paragraph (version A):
see padding.
Paragraph (version B):
i.e., using EAD_1, see padding.
Paragraph (version A):
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
Name, Label, Description, and Reference, where Label is a non-
negative integer and the other columns are text strings.