register public keys without proving knowledge of the private key, SIGMA SIGMA enforces a MAC to be calculated over the "identity". EDHOC follows SIGMA by calculating a MAC over the whole credential, <del> which in case of a X.509 or C509 certificate includes the "subject" </del>  and "subjectAltName" fields, and in the case of CWT or CCS includes the "sub" claim.  While the SIGMA paper only focuses on the identity, the same principle is true for other information such as policies Hellman key.  The authentication key algorithm needs to be compatible with the method and the cipher suite.  The authentication key algorithm needs to be compatible with the EDHOC key exchange <del> algorithm when static Diffie-Hellman authentication is used and </del>  compatible with the EDHOC signature algorithm when signature authentication is used. order of their deterministic encodings as specified in Section 4.2.1 of RFC8949. <del> When the authentication credential is a X.509 certificate, CRED_x SHALL be the end-entity DER encoded certificate wrapped in a bstr </del>  I-D.ietf-cose-x509. When the authentication credential is a C509 certificate, CRED_x 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.  Algorithms need to be specified with enough <del> parameters to make them completely determined.  EDHOC is only specified for use with key exchange algorithms of type ECDH curves. Use with other types of key exchange algorithms would likely require a specification updating EDHOC.  Note that for most signature algorithms, the signature is determined by the signature algorithm and the authentication key algorithm together, see auth-keys.  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. </del>  EDHOC AEAD algorithm -21. The following CCM cipher suites are for constrained IoT where message <del> overhead is a very important factor.  Cipher suites 1 and 3 use a larger tag length (128-bit) in EDHOC than in the Application AEAD algorithm (64-bit): </del>  The following ChaCha20 cipher suites are for less constrained applications and only use 128-bit tag lengths. 8.4.  The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information.  This also applies for encrypted data sent to an unauthenticated party.  In unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages. <del> 8.5. </del>  EDHOC itself does not provide countermeasures against Denial-of- Service attacks.  By sending a number of new or replayed message_1 an attacker and ignore it without sending an error message or discontinuing the session. <del> 8.6. </del>  The availability of a secure random number generator is essential for the security of EDHOC.  If no true random number generator is

This PR addresses and as well as parts of and . I also thought is was good to point out that AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with the IEEE CCM* mode.I also corrected the sentence "wrapped in a bstr" that Carsten pointed out during the interim.
Looks ready to merge
Duplicated text in 3.5.2. and 3.6: "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."
Is it relevant to have post-quantum cipher suites see URL
EDHOC already supports PQC signatures in the form of LMS. Any PQC signatures added to COSE will also be supported by EDHOC. For Key Exchange it is a bit more complex. Supporting KEMs will likely require some changes. The conslusion in the requirement document was that: "PAKE, post-quantum and "hybrid" (simultaneously more than one) key exchange is out of scope, but may be supported in a later version."
We also looked into if EDHOC with ECC should be moved to KEMs to be able to (more or less) automatically support PQC Kems, but the resulting protocol would have been more heavy as some properties of ECC could not be used in a strict KEM design. I think both PAKEs and KEMs would require new methods. Each PAKE might require its own method while all KEMs could likely be supported together. Unclear if 3x PQX KEM is better than 1 PQC KEM and 2 PQC Signatures, that requires some analysis.
Maybe we looked a bit to much on the Static DH mode when KEM was discussed last. Mehtod 0 will automatically work with PQC KEMs. GX is the public key and GY is an key encapsulation / ciphertext. We should likely describe that in the text. Good that you brought this up again NAME This would not be a technical change at all for method 0. The other methods would not work for general KEMs.
Although I'm not convinced all aspects of "PQ" can be solved in EDHOC timeframe, I still think it makes sense to put this in the document already.
My current plan would be to point out that the Key Exchange in method 0 is already following the KEM interface and can be replaced by any KEM including PQC KEMs. Might also be good to point out that method works with any signature algorithm including the PQC signature algorithm LMS that COSE has already specified.
NAME that for raising the issue earlier in NAME and NAME please review the new PR Method 0 is well-prepared for PQC algorithms, you can just replace the current KEM and Signature algorithms with PQC algorithms. Many of the PQC algorithms are very fast. Note that using PQC algorithms significantly increases the message sizes. Signatures, public keys, and encapsulations would be around 800 bytes instead of the current 32-64 bytes.
Does it make sense to specify a suite?
Regarding increased size, it does not meet the charter objective/fragmentation limit of 6TiSCH, but it still fits the MTU 6lowpan and may be a price to pay to reach PQC. Can the OSCORE re-keying proposals also meet PQC requirements? If so, and a "relatively expensive" key-exchange can be done very infrequently - the overhead is less of an issue.
Not right now I think. I think EDHOC needs to wait until COSE has registered PQC Key exchange algorithms. Which will probable happen after NIST standards. I don't think combining LMS signatures with ECC key exchange makes sense. NIST stated that round 3 will end close to the end of 2021. Draft standards will be available 2022-2023 and final standards hopefully 2024. NSA has stated that will update their CNSA suite at the end of NIST round 3. I think that makes a lot of sense for US TOP SECRET that requires protection for maybe 50-100 years. For many other use cases I think the quantum threat might bw a bit exagerated. It is unclear if CRQC will ever be built. If the number of qubits double every 18 months like transistor based chips did it will take 25-30 years.

Regarding increased size, it does not meet the charter objective/fragmentation limit of 6TiSCH, but it still fits the MTU 6lowpan and may be a price to pay to reach PQC. COSE/EDHOC will definitly have PQC algorithms in a few years. A big US company asked for a CNSA compliant suite which was added. CNSA will be updated to PQC is just a few months, but I think EDHOC should wait for COSE when it comes to PQC. >Can the OSCORE re-keying proposals also meet PQC requirements? If so, and a "relatively expensive" key-exchange can be done very infrequently - the overhead is less of an issue. Basically any symmetric construction will be PQC. The current It is unclear if CRQC breaking RSA will ever be built. If such CRQC are ever built, it would take millions of such CRQC hundreds of years to break AES-128. SHA-256 is more quantum resistant then AES-128 and HMAC-SHA-256 is more resistant than SHA-256. NIST currently draft documents label AES-128 and SHA-256 as quantum resistant which make a lot of sense to me. The EDHOC Key-Update use HMAC-SHA-256 and the OSOCRE key update use HKDF-SHA-256. They would both be highly resistant to quantum computers.
is now merged into master. Any further comments?
It looks good to me, and i appreciate the progress moving forward.
All good from my side too. Thanks!
Several things in the document is not specification but rather clarification of how COSE works. The additon of this and the integration in the main body was requested by several implementors. It should be more clearly marked that these parts just explain COSE and does not define anything. If soemthing would be wrong. The COSE specification apply. E.g.
The explanations of COSE are moved to C.3 in PR .
The IANA section currectly specified that CWT can be sent tagged or untagged while UCCS can only be sent untagged. That is probably not how it should be.
Only untagged: Untagged or tagged: Only tagged
Tagged add bytes that are not required. The COSE header parameter alredady gives this information. Except that I don't have a strong opinion between allowing both and only allowing untagged. Note that this is mostly a COSE question, rather than LAKE
The UCCS tag numer has not been assigned yet. URL
If I understand correctly, there is no need to integrity-protect also the possible CBOR tags. Then, I'd propose to generally admit both tagged and untagged objects. However, possible CBOR tags must be stripped away when building CRED_X --- Relates to URL
If I understand correctly, there is no need to integrity-protect also the possible CBOR tags. There is no need, but if used in the protected header as in EDHOC they will be integrity protected. That however not a problem as the protected header_map is sent on the wire, so both parties will have the same formatting.
Thanks Marco. My understandanding of the the current suggestion from Marco is: COSE: The COSE header parameters for CWT and ECCS allow bot tagged and untagged and do not enforce any specific order in the map. EDHOC: When CWT and UCCS is used in EDHOC, then CRED_x is the untagged CWT or UCCS sorted in lexigraphical order as defined by deterministic CBOR. That works for me.
Do CWT and UCCS need several header parameter each similar to x5u x5t x5chain x5bag?
New name (kcwt/kccs) and description: 4910a42f
NAME commented in the interim on "wrapped in a bstr" needs to be clarified.
NAME Is this following minor change (in ) sufficient, or do we need to provide more details? OLD When the authentication credential is a X.509 certificate, CREDx SHALL be the end-entity DER encoded certificate wrapped in a bstr {{I-D.ietf-cose-x509}}. NEW When the authentication credential is an X.509 certificate, CREDx SHALL be the end-entity DER encoded certificate, encoded as a bstr {{I-D.ietf-cose-x509}}.
Do you have a nested encoding step or is this just a byte string with the encoded X.509 certificate?
As this is referring to the end-entity certificate I would say the latter. NAME
Or in other words, we need to make sure we don't use terminology that implies nested encoding steps in cases where we simply have a plain data item in the CBOR. In CBOR diagnostic, if 'foo' is the encoded foreign data: 'foo' Inside the overall encoded data item: > Inside the overall encoded data item:
As I read it "end-entity DER encoded certificate, encoded as a bstr" indicates a "plain" CBOR encoding of the non-CBOR X.509 certificate data. Any objection / disagreement to this definition / interpretation?

register public keys without proving knowledge of the private key, SIGMA SIGMA enforces a MAC to be calculated over the "identity". EDHOC follows SIGMA by calculating a MAC over the whole credential,  <ins> which in case of an X.509 or C509 certificate includes the "subject" </ins> and "subjectAltName" fields, and in the case of CWT or CCS includes the "sub" claim.  While the SIGMA paper only focuses on the identity, the same principle is true for other information such as policies Hellman key.  The authentication key algorithm needs to be compatible with the method and the cipher suite.  The authentication key algorithm needs to be compatible with the EDHOC key exchange  <ins> algorithm when static Diffie-Hellman authentication is used, and </ins> compatible with the EDHOC signature algorithm when signature authentication is used. order of their deterministic encodings as specified in Section 4.2.1 of RFC8949.  <ins> When the authentication credential is an X.509 certificate, CRED_x SHALL be the end-entity DER encoded certificate, encoded as a bstr </ins> I-D.ietf-cose-x509. When the authentication credential is a C509 certificate, CRED_x 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.  Algorithms need to be specified with enough  <ins> parameters to make them completely determined.  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. EDHOC supports all signature algorithms defined by COSE, including PQC signature algorithms such as HSS-LMS.  Just like in TLS 1.3 RFC8446 and IKEv2 RFC7296, a signature in COSE is determined by the signature algorithm and the authentication key algorithm together, see auth-keys.  The exact details of the authentication key algorithm depend on the type of authentication credential.  COSE supports different formats for storing the public authentication keys including COSE_Key and X.509, which have different names and ways to represent the authentication key and the authentication key algorithm. An EDHOC cipher suite consists of the following parameters: </ins> EDHOC AEAD algorithm -21. The following CCM cipher suites are for constrained IoT where message  <ins> 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.  Cipher suites 1 and 3 use a larger tag length (128-bit) in EDHOC than in the Application AEAD algorithm (64-bit): </ins> The following ChaCha20 cipher suites are for less constrained applications and only use 128-bit tag lengths. 8.4. <ins> As of the publication of this specification, it is unclear when or even if a quantum computer of sufficient size and power to exploit public key cryptography will exist.  Deployments that need to consider risks decades into the future should transition to Post- Quantum Cryptography (PQC) in the not-too-distant future.  Many other systems should take a slower wait-and-see approach where PQC is phased in when the quantum threat is more imminent.  Current PQC algorithms have limitations compared to Elliptic Curve Cryptography (ECC) and the data sizes would be problematic in many constrained IoT systems. Symmetric algorithms used in EDHOC such as SHA-256 and AES-CCM- 16-64-128 are practically secure against even large quantum computers.  EDHOC supports all signature algorithms defined by COSE, including PQC signature algorithms such as HSS-LMS.  EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including PQC KEMs, can be used in method 0.  While the key exchange in method 0 is specified with terms of the Diffie-Hellman protocol, the key exchange adheres to a KEM interface: G_X is then the public key of the Initiator, G_Y is the encapsulation, and G_XY is the shared secret. Use of PQC KEMs to replace static DH authentication would likely require a specification updating EDHOC with new methods. 8.5. </ins> The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information.  This also applies for encrypted data sent to an unauthenticated party.  In unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages.  <ins> 8.6. </ins> EDHOC itself does not provide countermeasures against Denial-of- Service attacks.  By sending a number of new or replayed message_1 an attacker and ignore it without sending an error message or discontinuing the session.  <ins> 8.7. </ins> The availability of a secure random number generator is essential for the security of EDHOC.  If no true random number generator is


Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R do not have any cryptographic purpose in EDHOC since EDHOC integrity protects the authentication credential.  EDHOC relies on COSE for <del> identification of authentication credentials and supports all COSE header parameters used to identify authentication credentials </del>  including X.509, C509, CWT and CCS. ID_CRED_R is intended to facilitate for the Initiator to retrieve header parameters.  The header parameters typically provide some information about the format of authentication credential.  Example: X.509 certificates can be identified by a hash value using the 'x5t' parameter:

Ready to merge I think.
Fine by me, but I find this unesthetical: " IDCREDR is intended to facilitate for the Initiator to retrieve the Responder's authentication key." then a few lines later: "parameters in IDCREDR are used to identify the Responder's public key" same for IDCREDI. Seems redundant to have two slightly different formulations like this.
Let's merge this anyway - need to prepare for submission.
For a bit unclear reasons. COSE specifies different x5t header parameters for SS-ECDH sender and recipient, e.g., x5t and x5t-sender. When kid is used for SS-ECDH, the same header parameter is used for both sender and recipient... Unless this is changed in COSE. EDHOC need to add some additional specification or clarification. When used in EDHOC all header parameters always refer to sender. x5t-sender is not used etc. x5t is not used etc.
For EDHOC, the header parameter is either transported in IDCREDI or IDCREDR. So it is clear whether the header parameter refers to I or R, i.e. always to the sender. If we want to allow x5t-sender etc, then we need to provide an interpretation of the listing of algorithms associated to x5t-sender (but not x5t) in relation to the EDHOC cipher suite. Does this list limit the EDHOC cipher suite or can it be ignored? In the former case, the list may need to be updated when new EDHOC cipher suites are defined. This seems like an unnecessary complication when the objective of the header parameter in EDHOC is just to identify the credential and for that purpose x5t etc. seems sufficient. I propose we state: header parameter in IDCREDx refers to x (i.e. sender) x5-sender MUST NOT be used

For EDHOC, the header parameter is either transported in IDCREDI or IDCREDR. So it is clear whether the header parameter refers to I or R, i.e. always to the sender. I think the same could be said for COSE where the recipient structure makes the separation clear. >If we want to allow x5t-sender etc, then we need to provide an interpretation of the listing of algorithms associated to x5t-sender (but not x5t) in relation to the EDHOC cipher suite. Does this list limit the EDHOC cipher suite or can it be ignored? In the former case, the list may need to be updated when new EDHOC cipher suites are defined. This seems like an unnecessary complication when the objective of the header parameter in EDHOC is just to identify the credential and for that purpose x5t etc. seems sufficient. I don't undestand this part. EDHOC does not use COSE header parameters to detemine algorithms. >I propose we state: That sounds great.
From the joint effort in the recent COSE interim, to the best of our knowledge, we think this is all about making distinctions between certificates for different endpoints, although it was stated that this is probably not strictly necessary, so, e.g. two instances of x5t would do the job. There may perhaps be situations where this is not the case, maybe Jim was aware of one. All I'm saying is that at least in EDHOC it is possible to make the distinction.
Exactly. So what is the significance of the algorithms in table 2 if these COSE header parameters would be used in EDHOC? I'm trying to argue that it may be confusing to use in EDHOC a COSE header parameter which has associated algorithms if those algorithms are not relevant in EDHOC.
In the recent PR I did instead: header parameter in IDCREDx refers to x (i.e. sender) x5-sender SHOULD NOT be used I think there is a value in allowing applications to apply any COSE header parameter with IDCREDx as long as they can identify the credential. But at the same time discourage the use "-sender" for those who don't see any use for it.
I read John's original issue, and I couldn't understand the issue. I don't think we need x5-sender ever.
The problem is that COSE says the following about x5t, x5u, x5chain, x5bag: "The header parameters defined in the previous section are used to identify the recipient certificates for the ECDH key agreement" EDHOC needs to state that this is not the case when they are used in EDHOC.
Resolved in , now merged.

Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R do not have any cryptographic purpose in EDHOC since EDHOC integrity protects the authentication credential.  EDHOC relies on COSE for  <ins> identification of authentication credentials and supports all types of COSE header parameters used to identify authentication credentials </ins> including X.509, C509, CWT and CCS. ID_CRED_R is intended to facilitate for the Initiator to retrieve header parameters.  The header parameters typically provide some information about the format of authentication credential. <ins> COSE header parameters in EDHOC are used to identify the sender's public key credential, i.e., parameters in ID_CRED_R are used to identify the Responder's public key and parameters in ID_CRED_I are used to identify the Initiator's public key.  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. </ins> Example: X.509 certificates can be identified by a hash value using the 'x5t' parameter:


CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher. <del> plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ? EAD_2 ) </del>  If ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4 : kid_R }, then only the byte string or integer kid_R is conveyed in the plaintext encoded accordingly as bstr or int.  Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length of the plaintext. by the transport (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see coap). <del> Decrypt CIPHERTEXT_2, see asym-msg2-proc. </del>  Pass EAD_2 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm <del> P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? EAD_3 ) </del>  If ID_CRED_I contains a single 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or integer kid_I is conveyed in the plaintext encoded accordingly as bstr or int.  CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. Encode message_3 as a CBOR data item as specified in asym- Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg3-proc. </del>  Pass EAD_3 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm <del> P = ( ? EAD_4 ) </del>  <del> EAD_4 - protected external authorization data, see AD. </del>  CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0. Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg4-proc. </del>  Pass EAD_4 to the security application. Implementations MAY support EAD.  For many constrained IoT devices it is problematic to support several crypto primitives.  Existing devices can be expected to support either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256, for tracking, see Section 2.7 of I-D.arkko-arch-internet-threat- model-guidance.  8.7. EDHOC itself does not provide countermeasures against Denial-of-

NAME NAME Can we merge this?
Yes, the latest updates look good.
The confidentiality protection in EDHOC does not conceal the length of the identifiers IDCREDI and IDCREDR. We should maybe add OPTIONAL padding for deployments wanting to give eavesdroppers less information regarding the length of these identifiers. This could quite easily be achieved by allowign 0 or more simple values (e.g. true) in the beginning of the plaintexts.
Having optional padding is getting quite common. It was part of ESP (but not IKEv2 as far as I know) where it is called traffic flow confidentiality. It is part of the TLS 1.3 record layer. I recently wrote a paper about identity padding URL Based on this work I commented on HPKE which then added guidance on padding.
ESP can pad out to 254 bytes, but not more. IKEv2 has the same format for the encrypted payload, and can do the same, but can also pad within using empty blocks. Nobody does that, AFAIK.
I made a PR. URL The document definitly need to information on that the length of identities can be leaked and that this can be mitigated by e.g., chosing fixed length identifier for all the Initiators. I think OPTIONAL padding should be added for use cases like certificates. I am not sure it will be used very much, but if feels like a feature a security protocol is expected to have.
Based on Carsten's comment in COSE about failure from kid with int, My initial proposal was to make padding support for both sending and receiving optional. Marco commented on the PR and wanted mandatory support on the receiving side. Marco commented during the interim that he also wanted mandatory support on the sending side. Before I update the PR, I think this should be discussed a bit more. There has earlier been comments from NAME and NAME to not increase code size. I agree with Marco that mandatory to support for receiver makes sense. I am not sure about mandatory support for sender. My understanding that code for adding and removing padding would be different pieces of code.
I proposed: For the receiver, mandatory to support, since a padded message might legitimately come at any time. For the sender, optional to use, on a per-message basis. If the sender is surely never going to pad an outgoing message, no need for it to support padding as a sender at all, of course.

For the sender, optional to use I think the important question is if it is mandatory to implement.
Currently the spec says "Padding is OPTIONAL to support." We proposed in the interim ”OPTIONAL to support when sending MANDATORY to support when received" What is the preferred text?
NAME The optional to use per message is already in the PR I think as "may be used". Reading "For the sender, optional to use, on a per-message basis. If the sender is surely never going to pad an outgoing message, no need for it to support padding as a sender at all, of course." It seem like you agree with the suggestion proposed at the interim. We understood it as you proposed changes. The "may be used" could be changes to "optional...." if that is better.
I updated the PR based on the suggestion from Marco and Göran. I also align the text with the other text in the section. New suggested text is As discussed with kid of type int, I don't think mandatory support when recieving is strictly necesary, but might be a good approach anyway.
tl;dr : Thanks, the commit at URL looks good :-) Yes and that's fine, but that's when describing the message processing from the point of view of the sender. The comment referred to Section 7 "Mandatory-to-Implement Compliance Requirements", for which the new text in PR used to say "OPTIONAL to support". The proposed change was to limit that to the sender side (consistent with the above), but mandatory to the recipient side, to ensure it's able to parse the padding if that was included. I think that "may be used" is also fine in those sections about message processing from the point-of-view of the sender.
Seems like we agree on the high level stuff. Me and Göran spotted that "remove" and "discard" might be the wrong words. The requirement should be on being able to parse. Göran will improve the text. After that we are likely ready to merge
I made another commit: 4ee9fc02 MTI section now says: Also some editorials. A difficulty to express what length is hidden since "plaintext" is defined as plain text + padding. This lead to the wording "unpadded plaintext": I kept "discard" in the other parts because I didn't find any good word to substitute for. I didn't like "ignore" or similar as that action seemed to indicate "do nothing". So now it says:
This has been merged. Closing

CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher.  <ins> plaintext = ( ? PAD, ID_CRED_R / bstr / int, Signature_or_MAC_2, ? EAD_2 ) </ins> If ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4 : kid_R }, then only the byte string or integer kid_R is conveyed in the plaintext encoded accordingly as bstr or int. <ins> PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext </ins> Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length of the plaintext. by the transport (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see coap).  <ins> Decrypt CIPHERTEXT_2, see asym-msg2-proc, and discard padding, if present. </ins> Pass EAD_2 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm  <ins> P = ( ? PAD, ID_CRED_I / bstr / int, Signature_or_MAC_3, ? EAD_3 ) </ins> If ID_CRED_I contains a single 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or integer kid_I is conveyed in the plaintext encoded accordingly as bstr or int. <ins> PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext </ins> CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. Encode message_3 as a CBOR data item as specified in asym- Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined  <ins> in asym-msg3-proc.  Discard padding, if present. </ins> Pass EAD_3 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm  <ins> P = ( ? PAD, ? EAD_4 ) </ins>  <ins> EAD_4 - protected external authorization data, see AD.  PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext. </ins> CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0. Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined  <ins> in asym-msg4-proc.  Discard padding, if present. </ins> Pass EAD_4 to the security application. Implementations MAY support EAD. <ins> 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. </ins> For many constrained IoT devices it is problematic to support several crypto primitives.  Existing devices can be expected to support either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256, for tracking, see Section 2.7 of I-D.arkko-arch-internet-threat- model-guidance. <ins> Information regarding the lengths of ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 are leaked to an passive attacker.  Many COSE header parameters have variable length.  To mitigate an attacker from differentiating endpoints with identifiers of different length, and implementation may e.g., only use fix length identifiers like 'kid' of length 1 for the Responders.  Alternatively padding may be used to hide the length of e.g., certificates by value in 'x5chain' or 'c5c'. </ins> 8.7. EDHOC itself does not provide countermeasures against Denial-of-


available, a truly random seed MUST be provided from an external source and used with a cryptographically secure pseudorandom number generator.  As each pseudorandom number must only be used once, an <del> implementation needs to get a new truly random seed after reboot, or continuously store state in nonvolatile memory, see (RFC8613, Appendix B.1.1) for issues and solution approaches for writing to nonvolatile memory.  Intentionally or unintentionally weak or </del>  predictable pseudorandom number generators can be abused or exploited for malicious purposes.  RFC8937 describes a way for security protocol implementations to augment their (pseudo)random number

Randomness can be limited in constrained devices, and that can affect EDHOC. Cryptographic Considerations does talk about the necessity of randomness, but it did not become apparent to me from reading that alone that without a new fresh key I not only lose liveness and open up to interleaving, but also run into loss of all security properties when deriving an OSCORE secret from it and neither party has any randomness to put in. If one of the involved parties of EDHOC is just scraping together a few bits of entropy (which is as good as having none), is there a direction in which EDHOC can be used with limited loss of properties? (Gut feeling says no because an attacker can replay a previous EDHOC exchange with them). It may be helpful to also outline how a monotonous counter (similar to that of OSCORE B.1.1) can be used together with a private secret to obtain sufficient randomness. (That may follow from RFC 8937 already, not sure).
Now having read a more recent version of the draft: Looking further into the B.1.1 applicability, one way that'd to me gut-feeling-sounds like it might be OK is that the initiator only saves-to-disk its counter between receiving M2 and before sending M3. Thus, an initiator might use the same ephemeral key twice, but before it completes the exchange, it ensures it will "never" use the same ephemeral key again. The reason this would be useful is that it'd defer the point where the B.1.1 process performs a kind-of-destructive operation (writing to flash that has a finite number of duty cycles) to a point in time when it has good reason to believe that there is actually a peer that makes it worth it. (The response could still be replayed from an adversary that intercepted message1 in an earlier iteration of this, stopped message2 from reaching the device and then injected it now -- but that only gives the attacker one flash write for one time the attacker intercepts messages, and doesn't put the attacker in any better a position than other replays do).
NAME What remains of this issue? Is there anything you want to add to the text?
This part is not explicitly covered and may be worth mentioning or referencing other source. In B.1.1. write to flash is done every k, or when cache is lost. Why write a counter to flash happen every time EDHOC is run?
NAME NAME Check out . There is a section on mixing.
NAME NAME Thanks for good input here and during the interim! I did not do a good job in explaining what I think remains to do about this issue. Let me try again. Assume for the sake of the argument that there is no randomness contribution at all to the device during operation. The only source of randomness is an initial seed, denoted "private secret" above, which we require to have a good amount of randomness, generated or provisioned during manufacture. We also assume that the device can keep state by writing to non-volatile memory, but this write operation has a cost. In particular the number of write operations are limited. We can now generate pseudo random numbers using the private secret and, say a counter, but we must ensure that each counter value is different and we can't afford storing the counter each time. Section B.1.1 in RFC 8613 describes a procedure with write to flash every K:th step of the counter, where K is set by the application. If the device reboots, it sets counter to K + the value read from flash. More details in the section. Now for potential updates of the draft. Section 8.6 outlines the above. Should we also (in an appendix) give an example (like in RFC 8613 B.1.1.) how to generate random numbers using a secure PRF, the private secret, and sequence numbers, including a procedure for how to read/write from/to flash? Or is that obvious from the references? Section 8.6 says "A good amount of randomness is important for the key generation, to provide liveness, and to protect against interleavin attacks." Should we add something like "and to guard against deriving the same keys twice"? NAME also mentions another optimization whereby the write to flash operation by I is deferred to after R is authenticated. The purpose being to reduce potential write operations. This optimization is contradicting "the ephemeral keys MUST NOT be used in more than one EHDOC message", but could potentially be made secure by aborting after message 2 if the ephemeral key is not fresh. I think we should do 1, neutral about 2, and hesitant to 3. It is not clear to me that not making this optimization will cause a lot of write to flash.
The text above speaks about section 8.6 (Implementation Considerations) which in -12 to corresponds to section 8.7.
Comparing the randomness considerations in section 8.7 and the example use of non-volatile memory in B.1.1 of RFC 8613, I don't think we need make a separate appendix as suggested in item 1 above. It should be sufficient to add some more hints to section 8.7, a proposal in .
The new text looks good to me. It does not give permission to do the very special case I wanted to do (allow reusing a G_X if and only if the initializer commits to not ever using it again as soon as it has acted on a message 2), but from earlier discussion I conclude that opening up for that would be excessive in this document, and anyone who chooses to not go with what is described best practice will need to make very good own security analyses anyway.
Closing this as is now merged.

available, a truly random seed MUST be provided from an external source and used with a cryptographically secure pseudorandom number generator.  As each pseudorandom number must only be used once, an  <ins> implementation needs to generate unique input to the pseudorandom number generator after reboot, by using a new truly random seed, or by continuously storing unique state in nonvolatile memory, such as strictly increasing sequence numbers.  Appendix B.1.1 in RFC8613 describes issues and solution approaches for writing sequence numbers to nonvolatile memory.  Intentionally or unintentionally weak or </ins> predictable pseudorandom number generators can be abused or exploited for malicious purposes.  RFC8937 describes a way for security protocol implementations to augment their (pseudo)random number


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

Added references to revocation according to final comment.
Separate issue from Stefan's review : "Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2." The difference between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. the used algorithms are the same. -> I will suggest changing to "URL 0/1 or cipher suite 2/3" or similar.
Relates to . I think this is a good idea.
A proposal in PR
This makes sense to me
I propose we merge this once we converge on
and are very independant. I think 1 and 3 should probably be recommended for transports that can handle 53 byte payloads without significant performance degradation.
There was discussion during the meeting regarding endpoint / device. The current draft use both as a well as implementation. I think device is useful when we talk about "constrained devices" but not otherwise. The endpoint does in general not need to be a "device". It might be software in the cloud or some chip where EDHOC is used on the internal bus.
URL Outline "IDCREDI and IDCREDR are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively." I will replace this definition with something like: IDCREDI and IDCREDR are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively. EAD Is EAD data generated by the application or data that is pre-provisioned or obtained from somewhere. If the former is true I would like to suggest that the specification allows for implementations where all inputs and output that are generated at run time by the application are provided in non-encoded form to the EDHOC implementation. In this way, the interface to the application will be simpler and CBOR encoding and decoding can be completely hidden from the application developer. This applies especially for EAD, see issue . The general question is who is supposed to encode/decode EAD? The application or the EDHOC implementation? As far I understand the specification now only the application knows how to encode and decode EAD. "If the most preferred cipher suite is selected then SUITESI is encoded as that cipher suite, i.e., as an int." Am I understanding that correctly: If other suites are supported in addition they are not sent, e.g., if the initiator supports suites 1,2,3, where 1 is preferred and selected, 1 is sent as int and 2,3 are not sent? If so I will suggest making this sentence more clear. 6 Error Handling What is the use case for a success error code? Probably it is good to give some example or reference why it is useful to log successes using a predefined error code and encoding. Is logging the only use case for the success error code? For example, my implementation logs many things for debugging purposes. However, I never needed a success error code. The spec says that success error code must not be sent, therefore the sentence "Error code 0 MAY be used internally.." needs to be "Error code 0 MAY be used only internally.."? "ERRINFO can contain any type of CBOR item", see figure 7. Who decides what is the type of the CBOR item? Is this the EDHOC implementation developer? 7 Mandatory-to-Implement Compliance Requirements "Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2." The difference between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. the used algorithms are the same. -> I will suggest changing to "URL 0/1 or cipher suite 2/3" or similar. Error messages with which error codes are mandatory to implement? Is only an error message with ERRCODE 2 mandatory to implement? Implementation consideration "The selection of trusted CAs should be done very carefully and certificate revocation should be supported." Is OCSP (RFC6960) what should be used for certificate revocation checking? How revocation can be accomplished with C509? How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP stapling with EAD? Additionally, to verify a certificate the device should be aware of the time, which is often problematic on constrained devices, i.e. when certificates are used the device must have a Real-Time Clock (RTC).
opened to address this review.
Looks good to me. I have just read the PR, not checked how the PR corresponds to the review. Hi all, please find below my review of draft-ietf-lake-edhoc-12. Best regards, Stefan Outline "IDCREDI and IDCREDR are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively." I will replace this definition with something like: IDCREDI and IDCREDR are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively. EAD Is EAD data generated by the application or data that is pre-provisioned or obtained from somewhere. If the former is true I would like to suggest that the specification allows for implementations where all inputs and output that are generated at run time by the application are provided in non-encoded form to the EDHOC implementation. In this way, the interface to the application will be simpler and CBOR encoding and decoding can be completely hidden from the application developer. This applies especially for EAD, see issue . The general question is who is supposed to encode/decode EAD? The application or the EDHOC implementation? As far I understand the specification now only the application knows how to encode and decode EAD. "If the most preferred cipher suite is selected then SUITESI is encoded as that cipher suite, i.e., as an int." Am I understanding that correctly: If other suites are supported in addition they are not sent, e.g., if the initiator supports suites 1,2,3, where 1 is preferred and selected, 1 is sent as int and 2,3 are not sent? If so I will suggest making this sentence more clear. 6 Error Handling What is the use case for a success error code? Probably it is good to give some example or reference why it is useful to log successes using a predefined error code and encoding. Is logging the only use case for the success error code? For example, my implementation logs many things for debugging purposes. However, I never needed a success error code. The spec says that success error code must not be sent, therefore the sentence "Error code 0 MAY be used internally.." needs to be "Error code 0 MAY be used only internally.."? "ERRINFO can contain any type of CBOR item", see figure 7. Who decides what is the type of the CBOR item? Is this the EDHOC implementation developer? 7 Mandatory-to-Implement Compliance Requirements "Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2." The difference between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. the used algorithms are the same. -> I will suggest changing to "URL 0/1 or cipher suite 2/3" or similar. Error messages with which error codes are mandatory to implement? Is only an error message with ERR_CODE 2 mandatory to implement? Implementation consideration "The selection of trusted CAs should be done very carefully and certificate revocation should be supported." Is OCSP (RFC6960) what should be used for certificate revocation checking? How revocation can be accomplished with C509? How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP stapling with EAD? Additionally, to verify a certificate the device should be aware of the time, which is often problematic on constrained devices, i.e. when certificates are used the device must have a Real-Time Clock (RTC). Stefan Hristozov Department Hardware Security Fraunhofer Institute for Applied and Integrated Security AISEC Lichtenbergstraße 11, 85748 Garching near Munich, Germany Tel. +49 89 32299 86 157 EMAIL URL URL

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


"EDHOC_IV_4", respectively.  IVs are only used if the EDHOC AEAD algorithm uses IVs.  4.4. To provide forward secrecy in an even more efficient way than re-

Merging this as announced on the mailing list.
I've started to work on the update of -traces, see c936328e. What is missing is: Trace 2: SUITESI = [6, 2] instead of 2. Trace 2: Add bytes for raw x.509 (in addition to the CBOR encoded, see c936328e) In total two new entries: CREDI (Raw Value) and CRED_R (Raw Value) Trace 2: Pretty print of all byte strings the analogue of URL for p256 16 bytes per row space between bytes Marek's address NAME could you help out here? There is also TODO on version and reference which we need to fix, but that's just an editorial.
Hi Sorry i was super loaded at work last few days. I will have a look on this and also your email tomorrow or the. Best M
NAME Submission deadline Monday in 10 days :-)
Done here: URL Please review and sorry for the delay
NAME Thanks for the update. Started to update trace 2, ran into this: How is this CBOR encoding made? I would have expected to be encoded as and as
Hi There was an incompatibility in the generator function for identifiers. This has been fixed here: URL and updated test vectors are here: URL
Thanks, I'll take a look later today.
New test vector included in trace 2.
We are still missing update of label/remove of "Master" in trace 1, per . NAME NAME Could anyone of you help? (Replace "OSCOREMasterSecret/Salt" with "OSCORE_Secret/Salt" and re-generate test vector for EdDSA in URL)
For the first trace using EdDSA, with the new labels "OSCORESecret" and "OSCORESalt", I derive: OSCORE Master Secret (Raw Value) (16 bytes) 9565355973280280d64a3ce8d7fa0a93 OSCORE Master Salt (Raw Value) (8 bytes) 37478eddb09e5d7a OSCORE Master Secret after KeyUpdate (Raw Value) (16 bytes) ad4870dc7aca505bf80868785bd40d1b OSCORE Master Salt after KeyUpdate (Raw Value) (8 bytes) 7138715cb50303a2 Can anyone confirm?
These updates are now completed in -traces.
PR , which is merged with master, changed Exporter labels for OSCORE: URL The test vectors need to be updated accordingly, to be able to submit a new version of -traces matching the next version of -edhoc. (Att: NAME NAME
PR done.
Thanks, merged.
RFC 8446 states: "Note: With common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit." 12 is specific for TLS, but even if the number is slighty higher for EDHOC the following labels might currently require an extra iteration. Label: OSCOREMasterSecret Label: OSCOREMasterSalt I would suggest we calculate the exact length for EDHOC. Add that length as a consideration in the draft. And shorted down any long labels to not be longer.
I think removal of master is it's own issue. While we can update the terminology in an update, the labels are frozen and cannot be changed.
Appreciated, as these are strings lugged around in every firmware update.
Closing since is merged.
Updating my implementation, I noticed that these are in a CBOR structure anyway (and not concatenated into strings). So as these are all registered, why not go all the way and make them integers?
label : tstr What do you want to make integers?
The labels -- given they are coming from a registry anyway. (Why go "OSCOREmastersecret" to "OSCORE_secret" when we could go to 23 as well. (I realize it's little savings, like 60 bytes of firmware size; might not be worth much, but if there's a time for it, it's now)
That makes sense to me
Right, we could use something else instead of unique text strings. The current construct is: EDHOC-Exporter(label, context, length) = EDHOC-KDF(PRK4x3m, TH4, label, context, length) If not label, then context (bstr) can be unique for this use of PRK4x3m and TH4. Is the proposal to register unique byte strings, or to change the definition of the function?
Reopening this issue, since there is new input.
Still not clear to me what to register instead of labels and how to use in Exporter. There are multiple options. (I assume this only applies to Exporter, not "KEYSTREAM_2" etc.) But perhaps first ask more people. NAME NAME others: Is replacing exporter labels with e.g. integers a good change?
The proposal is to replace all inputs that ever go into the "label" argument -- anything else would be adding complexity. For a concrete proposal, we would change to and define, in order of occurrence in the document: with all occurrences of with etc. The exporter registry would then grow a n int field, and look like this: (It doesn't matter here that there is overlap in the values -- just as it was never ruled out that "K3" could become a label in the string based EDHOC Exporter Label Registry. That has and still is OK because it's used with different PRKs and transcript hashes. At any rate it's good that all these stay under 23 even with some room for other users, so implementers can store things preencoded if they so desire.) As for the security analyses, the numbers have the same properties as the strings -- they are self-delimited, and relative uniqueness properties should be the same no matter whether it's strings or numbers (at least when dealing in absolutes; if someone picked an unregistered number at random they're more likely to pick an assigned one than with strings, but that was already "maybe broken"). Length of input is reduced, but that is part of the point, and removing the "_Master" was fine already.
Based also on further discussions with NAME If the change is made to have integer labels, this should happen to all the labels involved. That is, not only to the labels provided as input to EDHOC-Exporter(), but also to the labels "KEYSTREAM2" etc. that are a direct input to EDHOC-KDF(). This avoids having an implementation of EDHOC-KDF() to handle both types as possible input. The labels to actually register should still be only those intended as input to EDHOC-Exporter(), i.e., there is no need to register integer labels that are a direct input to EDHOC-KDF() (corresponding to the current "KEYSTREAM2" etc.). In fact, same integer values would not be a problem in practice, since PRK4x3m clearly points to the exporter labels when used as first argument in EDHOC-KDF(). What can be useful is to make clear, as much as now for the tstr version, that potential labels defined in the future as part of EDHOC extensions and to directly use with EDHOC-KDF() have to be different from those already defined in that space, i.e., "KEYSTREAM2" etc.
Changing label to integers seems fine with me.I don't see why the Label below would stay in the specification. This would just be a variable name in the implementation, or?I assume that there is no benefit with int here as the uint is not sent on the wire. 0-255 would be stored as a single byte in the program and then converted to cbor when used.
Note that somebody suggested that this is good to to as late as possible just to break compability.
Based on the input from the formal verification, we will likely have 3 more internal EDHOC labels. Likley something like the following: Derived from PRK2e LABELKEYSTREAM2 LABELSALT2e Derived from PRK3e2m LABELMAC2 LABELK3 LABELIV3 LABELSALT3e2m Derived from PRK3m LABELMAC3 LABELPRK_OUT
Resolve in PR . Close this when that is merged.

"EDHOC_IV_4", respectively.  IVs are only used if the EDHOC AEAD algorithm uses IVs. <ins> With SHA-256, no context, and OKM length smaller than 24, any label longer than 20 characters requires an additional iteration of the hash function to compute.  The labels in this specification have all been chosen to fit within this limit. </ins> 4.4. To provide forward secrecy in an even more efficient way than re-


of one or more (ead_label, ead_value) pairs as defined below: Applications using external authorization data need to specify <del> format, processing, and security considerations and register the (ead_label, ead_value) pair, see iana-ead.  The CDDL type of ead_value is determined by the int ead_label and MUST be specified. </del>  The EAD fields of EDHOC are not intended for generic application data.  Since data carried in EAD_1 and EAD_2 fields may not be 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 "Expert <del> Review".  The columns of the registry are Label, Description, Value Type, and Reference, where Label is an integer and the other columns are text strings. </del>  9.6.

Looking at how EAD is used ace-ake-authz, I am not sure that the where eadlabel identifies a single eadvalue is optimal. The structure above enables reuse of eadlabel between protocols but give no information about the context that eadvalue should be used in like ace-ake-authz. From an random order of data elements it might be hard to figure out what to do with the data. Alternatives would be Where eadlabel a specific message of ace-ake-authz or just identifies ace-ake-authz (the message number is known anyway). As far as I know there several protocols planning to use EAD. I think we need to look at how these protocols use EAD and if any reuse between different protocols seem likely. If reuse does not seem to be likely, the second structure with the same eadlabel being used in all of the ace-ake-authz messages seems to be the most simple solution. Using a single int saves some bytes, and using a single int for a protocol like ace-ake-authz will likely use less of the code points. Another question is the EAD API. For larger object like CWT, the EDHOC EAD API needs to accept a encoded form. It should not reencode the CWT. This opens up the problem of what happens if somebody inputs wrongly encoded CBOR. This was identified as a problem in the EDHOC-KDF. It is less of a problem here but still not nice. This would point to a byte string as input being the way to go. This would make the API simple, make sure that everything is correcly encoded CBOR, but likely increase the message size (compared to a CBOR sequence). However applications like ace-ake-authz might then be able to do internal optimizations inside the byte string. (Note that the internal encoding of EAD does not affect anything else in EDHOC, it is more a topic for the protocols wanting to use EAD)
How is that now done e.g. in test vector 10 URL
Right now in the test vectors, "183ba1f646000102030405" is an encoding of a CBOR sequence following the structure The actual content is just made up data to show the formating. The actual data has no meaning. Nobody has registered any ead_label values.
An alternative is to keep the current high structure but change any to bytes What ead_label is supposed to identify is not described in the EDHOC document. It would be good with some guidance to protocols wanting to use EAD. For example that they should register a single int for the protocol.
I think the question is: should the EAD be consumed by the EDHOC implementation always encoded or sometimes encoded and how to differentiate that?

I think the question is: should the EAD be consumed by the EDHOC implementation always encoded or sometimes encoded and how to differentiate that? Based on your comments on API and that we likely want to ensure that ead is correct CBOR, the answer is likely that the input to the API should always be non-CBOR int and byte strings. The input byte string does then not need to be CBOR.

of one or more (ead_label, ead_value) pairs as defined below: Applications using external authorization data need to specify  <ins> ead_value format, processing, and security considerations and register the ead_label, see iana-ead. </ins> The EAD fields of EDHOC are not intended for generic application data.  Since data carried in EAD_1 and EAD_2 fields may not be 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 "Expert  <ins> Review".  The columns of the registry are Label, Description, and Reference, where Label is an integer and the other columns are text strings. </ins> 9.6.


8.6.  As CoAP provides Denial-of-Service protection in the form of the Echo option I-D.ietf-core-echo-request-tag, EDHOC itself does not provide countermeasures against Denial-of-Service attacks.  By sending a attacker and ignore it without sending an error message or discontinuing the session. <del> 8.7. </del>  The availability of a secure random number generator is essential for the security of EDHOC.  If no true random number generator is

IAB has started a program to look into updates of the Internet Threat Model. Looks like the outcome might be a guidance document. One new threat is centralised data collection where the other endpoint might not be acting in the interest of the users. URL URL There is not reason to change the protocol, but I think it would be good with some privacy considerations. Using the same credentail with several other endpoints enables tracking. I will make a PR soon with a reference to draft-arkko-arch-internet-threat-model-guidance
This has been merged for a while without any comments. Was discussed at the interim. Closing.
Looks good, I made some editorials.

8.6. <ins> Since the publication of RFC3552 there has been an increased awareness of the need to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users I-D.arkko-arch-internet-threat-model-guidance. RFC7624 describes an updated threat model for Internet confidentiality, see sec-prop.  I-D.arkko-arch-internet-threat-model- guidance further expands the threat model.  Implementations and users SHOULD consider these threat models.  In particular, even data sent protected to the other endpoint such as ID_CRED and EAD can be used for tracking, see Section 2.7 of I-D.arkko-arch-internet-threat- model-guidance. 8.7. </ins> As CoAP provides Denial-of-Service protection in the form of the Echo option I-D.ietf-core-echo-request-tag, EDHOC itself does not provide countermeasures against Denial-of-Service attacks.  By sending a attacker and ignore it without sending an error message or discontinuing the session.  <ins> 8.8. </ins> The availability of a secure random number generator is essential for the security of EDHOC.  If no true random number generator is


An EDHOC cipher suite consists of an ordered set of algorithms from the "COSE Algorithms" and "COSE Elliptic Curves" registries as well <del> as the EDHOC MAC length.  Algorithms need to be specified with enough parameters to make them completely determined.  The MAC length MUST be at least 8 bytes.  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. </del>  EDHOC supports all signature algorithms defined by COSE, including PQC signature algorithms such as HSS-LMS.  Just like in TLS 1.3

Ed25519 instead of EdDSA
Comment from Loïc: URL >
let's just be careful that we are aligned with RFC 8152 definitions here.
What [1] says it not particulary important. We only care the standadized versions which often are not equal to the original academic papers. In this case we want to follow firstly COSE RFC 8152 and secondly RFC 8032. COSE calls the signature algorithm "EdDSA" so I think 9.2 is correct. All uses of "EdDSA" in the EDHOC draft refer to the generalized signature system EdDSA, so also according to [1], I do not see a problem either. 9.2 talks about the generalized signature system EdDSA used with the curves Ed25519 and Ed448 (following RFC 8152). Do we need some more references to COSE. Some of the other reviewers asked about references to LMS. Should be clear in the EDHOC draft that basicaaly everything concerning algorithms and IDCREDx follows from COSE and than any details or futher references can be found there.
I think the EDHOC document needs to be clearer that all terminology follows COSE and that all definitions is found in COSE. JOSE has strange naming that COSE has borrowed. And maybe COSE added some strange names on it own. The curve registry list X25519, X448, Ed25519, Ed448, as curves (the CFRG names are edwards25519 and Curve25519 etc.,) AES-128 is often called A128 ECDSA with SHA-256 is called ES256 RSASSA-PSS with SHA-256 is called PS256 RSASSA-PKCS1-v15 using SHA-256 is called RS256 RSASSA-PKCS1-v15 using SHA-1 is called RS1 HKDF-AES-128 ............ I genuinly hate a lot of these names. I get many questions from people internally at my company from people asking about these weird names. They cause a lot of confusion and extra work for no apperent benefit. However, I think EDHOC needs to follow COSE. We should just explain that better.
Note that "EdDSA" in Section 9.2 is not even "Ed25519". The choice between Ed25519 and Ed448 depends on the authentication key as specified by COSE.
Closing this since is now merged. Hello LAKE, Sorry for this very late remark. But it seems that "EdDSA" is not the proper wording to use in the draft (at least in Section 9.2). I quote the original paper by Bernstein, Duif, Lange, Schwabe and Yang [1]: " This section specifies the signature system used in this paper, and a generalized signature system EdDSA that can be used with other choices of elliptic curves." " Our recommended curve for EdDSA is a twisted Edwards curve birationally equivalent to the curve Curve25519 [...] We use the name Ed25519 for EdDSA with this particular choice of curve." Therefore "Ed25519" should be used in place of "EdDSA" (at least in Section 9.2). What do you reckon? Best regards [1] High-speed high-security signature, Bernstein, Duif, Lange, Schwabe and Yang, 2011. URL Loïc Ferreira Orange Labs – Applied Cryptography Group +33 (0)2 31 15 91 24 EMAIL Orange Restricted -----Message d'origine----- De : Lake De la part de Sean Turner Envoyé : mercredi 15 décembre 2021 07:35 À : LAKE List Objet : [Lake] spt review of echoc-12 Like others I agreed to review the edhoc I-D at the last meeting. I did not have a chance to make sure that I am not repeating comments from others. To save the WG some time, I tried to categorize these along the lines of questions/nits where discuss might need some f2f time and nits, I believe, can be dealt with by the authors as they see fit. Disclaimers: 0) I am not a cryptographer or security researcher. 1) It is entirely possible I am entirely missing the plot/point. Apologies: I ran out of time to submit these as Issues/PRs. I can do so after the interim, including those that got rejected at the 12/15 interim for posterity sake. s1.2 (nit): If s1.2 is supposed to be an applicability statement in the context of RFC 2026, can we call it that. i.e., r/Use of EDHOC/Applicability Statement. revised: And then, I see section 3.9. Maybe instead of renaming s1.2, a forward pointer to s3.9 is all that is needed to say that an applicability statement is required? s2, 2nd para (nit): refer to both because it’s (D)TLS and not just TLS? I.e., s/(D)TLS 1.3 [RFC8446]/(D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13] s2, 2nd para (nit): I think you can safely drop the 2nd reference to IKEv2 s/like IKEv2 [RFC7296],/like IKEv2, s3.2/s3.5.2 (question): Smarter people than I have devised plans to allow mixing of different METHODs. How does this impact the key usage extension present in certificates? In other words, are METHODS 1 and 2 suggesting that a DS and DH key be used together and does that violate any kind of restrictions on the key usage settings for certificates? s3.4 (nit): Is transport of error messages, as noted by s6 (2nd para), needed in the list. s3.5 para after the bullets (nit): I think you are trying to say the credentials have to be the same type, i.e., you can’t have PGP one one side and x.509 on the other. I am not sure that the following is the best wording: s/Identical authentication credentials need to be established in both endpoints to be able to verify integrity./The same type of authentication credentials are needed baby the endpoints to be able to verify integrity. s3.5.1, 1st para (nit): At first I thought for sure this had to be a MUST, but it says or application so I am not sure: The EDHOC implementation or the application must enforce information about the intended endpoint … s3.5.1 (nit): expand on first use NAI & EUI s3.5.1, 1st bullet (nit): Often we refer to this a Proof-of-Possession so maybe you could say that: s/EDHOC provides proof that the other party possesses the private authentication key corresponding to the public authentication key in its certificate./EDHOC provides proof that the other party possesses the private authentication key corresponding to the public authentication key in its certificate, which is also known as proof-of-possesion. s3.5.1, 1st bullet (question): This seems like the “mixing” discussed in s3.2, relies on the identity provide in the certificate? The certification path provides proof that the subject of the certificate owns the public key in the certificate. s3.5.2 (question): related to comment on s3.2. s3.5.3, 2nd para (nit): Could point to RFC 3279/5480 for some key usages for ECDSA and RFC 8410 for x25519/x448. In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement" [RFC3279][RFC8410]. s3.6 (nit): refer to both?: s/TLS 1.3 [RFC8446]/ (D)TLS 1.3 [RFC8446] [I-D.ietf-tls-dtls13] s3.5.3 (question): EDHOC seems to assume you only provide the reference for the initiator's/responder’s. Was there any thought it to providing references for the rest of the certification path up to but not including the Root CA’s certificate? I mean technically they can also be in there certificate provided so not necessarily needed. s3.6, CNSA ref (nit): I made a similar comment against the ZRTP spec when they said their alg suites were compliant with Suite B … probably best to say Suite 24 and 25 use algorithms in CNSA and leave the word “compatible” for “them” to say. s3.8 (comment): Wow .. so you can send in the CSR in EAD, if it works then you can use the cert in the later messages (e.g., kind of like EAP)? Sure hope there’s no kind of CSR-related error. And, you know that the CA gets to decide the name right. Sorry just trying to digest it all. s4.3 (nit): s/kan/can s4.4/s5.1 (question): Do you need to provide advice on when to delete the old PRK4x3m? I.e., does the peer that sent this need to wait for some kind of confirmation before deleting it? s5.1 (question): Is a state diagram needed? One thing people clamored for from TLS was a state machine. Maybe a diagram isn’t needed because there are so few states? s5.1 (comment, no action required): Cute. Deduplication is how to deal with message reply ;) s5.2.1, s.5.3.1, s5.4.1, s5.5.1 (nit): is the “,” before the closing bracket right? e.g., OLD: ? EAD1 : ead, } NEW: ? EAD1 : ead } s5.2.2 (question): If this this initiator processing section, how does the initiator know to truncate? …, truncated after the cipher suite selected for this session. s5.2.3, s5.3.3, s5.4.3, s5.5.3, last sentence (question - probably being pedantic): If there is an error but an error message is not sent, is the session discontinued? How does the peer know it was discontinued if an error is not sent? s5.2.3, s5.3.3, s5.4.3, s5.5.3 (nit, which I am sure the RFC editor fix better than I could, but I couldn’t help myself): Instead of the e.g., in middle of the MAY sentence maybe: OLD: Sending error messages is essential for debugging but MAY e.g., be skipped if a session cannot be found or due to denial-of-service reasons, see Section 8.6. NEW: 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 Section 8.6. s6.1 (nit): To stop loops, should any peer that receives an ERRCODE=0 discontinue the session? I.e., is that worth stating in the I-D? s6.2 (nit): It’s really more “Freeform” than unspecified right? I mean the string is required so it’s definitely not unspecified per se. s6.3.2, 2nd to last para (nit): s/shall/SHALL s6.3.2/s5.2.1 (nit): Might be worth noting earlier that SUITESR is not important. Also, s5.2.1, mentioned SUITESI, but s5.2.2 does not mention SUITESR. s7, last para (nit): s/To enable as much interoperability as we can reasonably achieve,/To enable as much interoperability as possible, s8 (question): Isn’t some kind of consideration needed to address the use of PSKs shared by more than two? See RFC 8773 for some considerations wrt to group key sharing and that sharing impact on authentication. s8.3 (nit): You can informatively refer to RFC 6194 to slam the door on SHA-1. s9 and onwaard (apologies): I ran out of steam. s? (question): Is a peer supposed to check status information for its peer’s certificate/key? I-D Nit complaints (not all of them because the DOWNREFs (mostly) looked intentional): == Missing Reference: 'RFC9052' is mentioned on line 2411, but not defined Cheers, spt Lake mailing list EMAIL URL Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

An EDHOC cipher suite consists of an ordered set of algorithms from the "COSE Algorithms" and "COSE Elliptic Curves" registries as well  <ins> as the EDHOC MAC length.  All algorithm names and definitions follows from COSE I-D.ietf-cose-rfc8152bis-algs.  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.  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. </ins> EDHOC supports all signature algorithms defined by COSE, including PQC signature algorithms such as HSS-LMS.  Just like in TLS 1.3


This section defines Extract, Expand and other key derivation functions based on these: Expand is used to define EDHOC-KDF and in turn EDHOC-Exporter, whereas Extract is used to define EDHOC- <del> KeyUpdate. </del>  4.1.

From Sean's review: s5.1 (question): Is a state diagram needed? One thing people clamored for from TLS was a state machine. Maybe a diagram isn’t needed because there are so few states?
Not sure it is needed in EDHOC. TLS has three distict states (early data, handshake, post handshake) and the key to use depend on the state irrespective of message type. EDHOC has none of that. A key derivation figure would maybe make more sense if we are to add anything.
Suggestion by Goran to add a reference to an academic paper that has a figure with the key derivation
Perhaps sufficient to refer to figure 2?
I don't have a strong preference, but fig 3 is used for message_4.
But message_4 will likely not be used in most deployments, so maybe Fig 2 is enough.
I think this can be closed after interim today, unless there are any more comments.

This section defines Extract, Expand and other key derivation functions based on these: Expand is used to define EDHOC-KDF and in turn EDHOC-Exporter, whereas Extract is used to define EDHOC-  <ins> KeyUpdate.  In EDHOC a specific message always use the same key, but how the key is derived depends on the method.  A diagram of the EDHOC key schedule can be found in Figure 2 of Vucinic22. </ins> 4.1.


Pass EAD_1 to the security application. <del> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error, and the session MUST be discontinued.  Sending error messages is essential for debugging but MAY be skipped due to, for example, denial-of-service reasons, see dos.  If an error message is sent, the session MUST be </del>  discontinued. 5.3. cipher suite.  The verification process depends on the method, see asym-msg2-proc. <del> If any processing step fails, the Initiator SHOULD send an EDHOC error message back, formatted as defined in error.  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.  If an error message is sent, the session MUST be </del>  discontinued. 5.4. application.  The application can now derive application keys using the EDHOC-Exporter interface. <del> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error.  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.  If an error message is sent, the session MUST be </del>  discontinued. After verifying message_3, the Responder is assured that the Pass EAD_4 to the security application. <del> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error.  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.  If an error message is sent, the session MUST be </del>  discontinued. 6. processing associated to the currently defined error codes. Additional error codes may be registered, see error-code-reg.  An EDHOC error message can be sent by either endpoint as a reply to any non-error EDHOC message.  How errors at the EDHOC layer are transported depends on lower layers, which need to enable error messages to be sent and processed as intended. <del> Errors in EDHOC are 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. </del> error SHALL be a CBOR Sequence (see CBOR) as defined below where:

I think this is ready to merge. This addresses Marcos and Seans comments. Remaining discussions should be handled by separate PRs.
From Marco's review: [Section 5.2.3] "If an error message is sent, the session MUST be discontinued." Is this sentence actually required? Regardless sending an error message or not, the session is discontinued if any processing step fails, which is the reason for possibly sending an error message. Or are there situations where an error message is sent even if no processing step fails?
This sentence does not talk about failed processing, it is a general implication stating the necessity of discontinuing the session if an error message is sent (for whatever reason), in contrast to the converse statement in the preceding sentence which states that there is no necessity of sending an error message if the session is discontinued. But it is not explained why you would send an error unless processing has failed. Do we have any example?
I don't see the problem here at all. In general in security protocols there is no connection between some processing step failing, sending an alert, and terminationg the connection. Error => processing fails is not true. It is not defined when an error is sent. Close?
When to send an error is left for the implementation. Does that need to explained better?
Related comment from Sean Let's go over and make sure the document answer When is the protocol discontinued? When is an error sent? How does the other party get information about discontinue and the type of error? My understanding Up to the implementation/application when to discontinue the protocol. My feeling is that this is broader than "processing step fails" When the protocol is discontinued, an error MUST be sent, expect if that cannot be done due to DoS. The error tels the other party that the protocol has been discontinued and why it has been discontinued. A party receiving an error knows that the other party discontinues or that an attacker sent the error. In DoS situation the other party gets no information.
I will make a suggested PR for this in the upcoming weeks.
I made a PR to try to address the two comments from Marco and Sean which where quite different but both involve error. As in HTTP and CoAP the intention is that error can be both "client errors" and "server errors". I removed duplicate text from the processing sections and expanded the text in the error section. The PR likely needs some further update but is hopefully a good start for discussion.
EDHOC is not following the standard client error server error design of HTTP and CoAP. Is this intentional? This is the highest level grouping in HTTP and CoAP. As far as I can remember that was not even discussed. Instead of 1 Unspecified Should we not have something like 1 Unspecified Initiator error 2 Unspecified Responder error or 1 Unspecified Sender error 2 Unspecified Reciever error Also is "Unspecified" a good name? The intention is that it is specified in the tstr.
URL While working on this I noticed than one cause for Marcos comment might be that EDHOC only talkes about what HTTP and CoAP calls "client error", i.e., there was something wrong in the received message. HTTP and CoAP defines errrors into two classes "client error" (there is something wrong with you) and "server error" (there is something wrong with me). EDHOC does currently not follow this design and only has a single error 1 Unspecified Should EDHOC instead have have something like? 1 Unspecified Initiator error 2 Unspecified Responder error or 1 Unspecified Sender error 2 Unspecified Reciever error The choice would likely be whatever is easiest for an implementation. I think we should discuss this. This type of high level classes was not discussed before. We only discussed what kind of detailed errors we should standardized and agreed on none. Also is "Unspecified" a good name? The intention is that it is specified in the tstr.
Marco wrote: URL I think it's good to have something like in your second proposal and without "Unspecified" (as you say, the error is specified in the text string), that is: 1 Sender error 2 Receiver error Without bothering about which among client and server exactly has the Initiator or Responder role in the EDHOC session, the above can be read as: 1 --> "something wrong done by the sender of the message that resulted in this error message" 2 --> "something locally wrong happened at the receiver of the message that resulted in this error message" The mapping with high-level classes from CoAP/HTTP would be limited to responses only, and for CoAP it was basically sketched in Appendix A.3.1: "In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g., due to a malformed EDHOC message), or 5.00 (Internal Server Error) in case of server error (e.g., due to failure in deriving EDHOC key material)." This can be expanded to highlight the use of 4.00 responses for ERRCODE 1 (Sender error) and the use of 5.00 responses for ERRCODE 2 (Receiver error).
URL Or would the right choice be to differentiate between errors where the message might be retried and errors where the message may be retried later? 1 Do not automatically retry error 2 May retry later error Most be not client errors should not be retried while most but not all server errors might be retried. Carsten had the opinion that different EDHOC errors should lead to different automatic processing. But I think nothing like the above was ever discussed.
I can't even understand the sentence. These are passive constructions, so I don't know who is acting on the fact that "an error message was sent" (and how that is detected), and I don't know who is acting when performing the mandate "the protocol is discontinued". (I hope that doesn't mean that we need a new standard because the old EDHOC was discontinued. Is this about the protocol run?) Sorry to be pedantic, but I really don't know what this all means.
The current plan is to merge the current PR which addresses Marco's and Sean's review comments. Additional things has be discussed more and handles with other PRs More EDHOC errors (client, server) or (retry, do not retry) or (unsuported X) Use of CoAP error codes, current recommendation is to use 4.00 and 5.00 and always use diagnistic payload. Seemed during the design meeting that implementatins do other stuff, should discuss and maybe update specification. Any new error with negotiation should probably not be done. To do that in a safe way would require significant changes. An implementation could assign ciphersuite1+application profile1 and ciphersuite+application profile2 to the private ciphersuite numbers to get secure negotiation of application profiles. Maybe that should be discussed.
Apart from the error code / progress hints as mentioned in the previous comment, we have now resolved the remaining comments from Marco and Sean of this issue in PR (which is now merged). NAME NAME - let us know if you disagree with the resolution.
Looks good to me. Hi John, I think it's good to have something like in your second proposal and without "Unspecified" (as you say, the error is specified in the text string), that is: 1 Sender error 2 Receiver error Without bothering about which among client and server exactly has the Initiator or Responder role in the EDHOC session, the above can be read as: 1 --> "something wrong done by the sender of the message that resulted in this error message" 2 --> "something locally wrong happened at the receiver of the message that resulted in this error message" The mapping with high-level classes from CoAP/HTTP would be limited to responses only, and for CoAP it was basically sketched in Appendix A.3.1: "In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g., due to a malformed EDHOC message), or 5.00 (Internal Server Error) in case of server error (e.g., due to failure in deriving EDHOC key material)." This can be expanded to highlight the use of 4.00 responses for ERRCODE 1 (Sender error) and the use of 5.00 responses for ERRCODE 2 (Receiver error). Best, /Marco Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden URL Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)

Hi, Issue was opened based on two different review comments from Marco and Sean on different aspects of error messages. I have tried to address Marco's and Sean's comments in PR URL While working on this I noticed than one cause for Marcos comment might be that EDHOC only talkes about what HTTP and CoAP calls "client error", i.e., there was something wrong in the received message. HTTP and CoAP defines errrors into two classes "client error" (there is something wrong with you) and "server error" (there is something wrong with me). EDHOC does currently not follow this design and only has a single error 1 Unspecified Should EDHOC instead have have something like? 1 Unspecified Initiator error 2 Unspecified Responder error or 1 Unspecified Sender error 2 Unspecified Reciever error The choice would likely be whatever is easiest for an implementation. I think we should discuss this. This type of high level classes was not discussed before. We only discussed what kind of detailed errors we should standardized and agreed on none. Also is "Unspecified" a good name? The intention is that it is specified in the tstr. Cheers, John

Pass EAD_1 to the security application.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. 5.3. cipher suite.  The verification process depends on the method, see asym-msg2-proc.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. 5.4. application.  The application can now derive application keys using the EDHOC-Exporter interface.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. After verifying message_3, the Responder is assured that the Pass EAD_4 to the security application.  <ins> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </ins> discontinued. 6. processing associated to the currently defined error codes. Additional error codes may be registered, see error-code-reg. <ins> 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 recieving 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. </ins> An EDHOC error message can be sent by either endpoint as a reply to any non-error EDHOC message.  How errors at the EDHOC layer are transported depends on lower layers, which need to enable error messages to be sent and processed as intended.  error SHALL be a CBOR Sequence (see CBOR) as defined below where: