The parties exchanging messages are called Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared <del> secret key PRK_out, and derive symmetric application keys used to protect application data. </del>  G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively. in the selected cipher suite to derive keys used in message processing.  This section defines Extract (extract) and Expand (expand), and how to use them to derive PRK_out (prkout) which is the <del> shared secret key resulting from a successful EDHOC exchange. </del>  Extract is used to derive fixed-length uniformly pseudorandom keys (PRK) from ECDH shared secrets.  Expand is used to define EDHOC-KDF 4.1.3. The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is <del> the output of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  For the purpose of using EDHOC- Exporter, an application only needs to store PRK_out or PRK_exporter. (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </del>  4.2. ephemeral Diffie-Hellman and provides a key update function (see keyupdate) for lightweight application protocol rekeying.  Either of these provide forward secrecy, in the sense that compromise of the <del> private authentication keys does not compromise past session keys, and compromise of a session key does not compromise past session keys.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, </del>  which is a significant complication. To limit the effect of breaches, it is important to limit the use of with other parties but does not let the attacker impersonate other parties in EDHOC exchanges with the compromised party.  Compromise of the long-term keys does not enable a passive attacker to compromise <del> future session keys.  Compromise of the HDKF input parameters (ECDH shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC-Exporter. </del>  Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force

Issue
Minor comment, but reading through all the security claims, they multiple times refer to the term (for instance in ), which is not per say completely defined. I am not even sure there is any ambiguity, but is it still worth adding somewhere that this relates to ?
Yes, I assume session key most often refer to PRK_out. Could maybe refer to the exported application keys in some sentence. Let's go through all instances and make it clear what it refers to.

The parties exchanging messages are called Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared  <ins> secret session key PRK_out, and derive symmetric application keys used to protect application data. </ins> G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively. in the selected cipher suite to derive keys used in message processing.  This section defines Extract (extract) and Expand (expand), and how to use them to derive PRK_out (prkout) which is the  <ins> shared secret session key resulting from a successful EDHOC exchange. </ins> Extract is used to derive fixed-length uniformly pseudorandom keys (PRK) from ECDH shared secrets.  Expand is used to define EDHOC-KDF 4.1.3. The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is  <ins> the output session key of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  For the purpose of using EDHOC-Exporter, an application only needs to store PRK_out or PRK_exporter.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </ins> 4.2. ephemeral Diffie-Hellman and provides a key update function (see keyupdate) for lightweight application protocol rekeying.  Either of these provide forward secrecy, in the sense that compromise of the  <ins> private authentication keys does not compromise past session keys (PRK_out), and compromise of a session key does not compromise past session keys.  Frequently re-running EDHOC with ephemeral Diffie- Hellman forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, </ins> which is a significant complication. To limit the effect of breaches, it is important to limit the use of with other parties but does not let the attacker impersonate other parties in EDHOC exchanges with the compromised party.  Compromise of the long-term keys does not enable a passive attacker to compromise  <ins> future session keys (PRK_out).  Compromise of the HDKF input parameters (ECDH shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC-Exporter. </ins> Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force


Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the <del> input to the hash function is a CBOR Sequence.  Note that H(TH_2, PLAINTEXT_2) can be computed and cached already in the processing of message_2. </del>  Compute MAC_3 as in expand, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_4 is a CBOR encoded bstr and the <del> input to the hash function is a CBOR Sequence. </del>  Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can now derive application keys using the EDHOC-Exporter interface,

This note needs to be updated. The sentence is a remnant since TH3 was defined as H(TH2, PLAINTEXT_2)

Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the  <ins> input to the hash function is a CBOR Sequence.  Note that TH_3 can be computed and cached already in the processing of message_2. </ins> Compute MAC_3 as in expand, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_4 is a CBOR encoded bstr and the  <ins> input to the hash function is a CBOR Sequence.  Note that TH_4 can be computed and cached already in the processing of message_3. </ins> Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can now derive application keys using the EDHOC-Exporter interface,


EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and <del> message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2 and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </del>  Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as

-
URL Hi all, Following our previous analysis of the draft 12 and 14, we have now updated our models w.r.t. draft 17, making a full pass over both the protocol changes as well as the security considerations mentioned through out the draft. Overall, there is a last security claim that is slightly wrong from a theoretical point of view, but in practice does not bear consequences. We detail it bellow. Otherwise, our automated analysis was not able to find any other weakness, so we hope that with respect to state of the art analysis techniques, the protocol is in a pretty good shape. It concerns the following point, page 42: "Changes in message1 and message2 (except PAD2) are detected when verifying SignatureorMAC2. " This claim in fact dependson the security level of the signature scheme used. Assume that we have a signature scheme such that given "Sign(m,sk)", the signature of message m with secret key sk, there exists a constant "c" such that "Sign(m,sk) XOR c" is also a valid signature for the same message m under sk. This is nota violation of the classical assumption over signatures (EUFCMA), and with such a signature scheme, an attacker could then change the content of message_2, by xoring the signature part with the constant c, and this change would not be detectedafter verifying the signature, and would only be caught on a message 4 or key confirmation. This is only a theoretical attack, relying on the difference between the classical cryptographic assumption EUF-CMA, a signature authenticates only the underlying message, while underthe stronger SUF-CMAassumption, a signature authenticates both the underlying message and the signature itself.Noneof the concrete signature scheme currently standardized appears to bemalleable under xor. We report it for thoroughness, but are uncertain whether the sentence should be changedor not. Best, Charlie Jacomme, Elise Klein,Steve KremerandMaïwenn Racouchot.
I think this would be caught when verifying CIPHERTEXT_3
The PR looks fine to me! When mentioning message 4 or key confirmation, I was specifying when the change would be detected on the initiator side, but the responder would indeed detect it when verifying CIPHERTEXT_3. Hi all, Following our previous analysis of the draft 12 and 14, we have now updated our models w.r.t. draft 17, making a full pass over both the protocol changes as well as the security considerations mentioned through out the draft. Overall, there is a last security claim that is slightly wrong from a theoretical point of view, but in practice does not bear consequences. We detail it bellow. Otherwise, our automated analysis was not able to find any other weakness, so we hope that with respect to state of the art analysis techniques, the protocol is in a pretty good shape. It concerns the following point, page 42: "Changes in message1 and message2 (except PAD2) are detected when verifying SignatureorMAC2. " This claim in fact dependson the security level of the signature scheme used. Assume that we have a signature scheme such that given "Sign(m,sk)", the signature of message m with secret key sk, there exists a constant "c" such that "Sign(m,sk) XOR c" is also a valid signature for the same message m under sk. This is nota violation of the classical assumption over signatures (EUFCMA), and with such a signature scheme, an attacker could then change the content of message_2, by xoring the signature part with the constant c, and this change would not be detectedafter verifying the signature, and would only be caught on a message 4 or key confirmation. This is only a theoretical attack, relying on the difference between the classical cryptographic assumption EUF-CMA, a signature authenticates only the underlying message, while underthe stronger SUF-CMAassumption, a signature authenticates both the underlying message and the signature itself.Noneof the concrete signature scheme currently standardized appears to bemalleable under xor. We report it for thoroughness, but are uncertain whether the sentence should be changedor not. Best, Charlie Jacomme, Elise Klein,Steve KremerandMaïwenn Racouchot.

EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and  <ins> message_2 (except PAD_2 and Signature_or_MAC_2 when the signature scheme is not strongly unforgeable) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2, not strongly unforgeable Signature_or_MAC_2, and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as


keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and 7.2 of RFC9053, but only including the 'x' parameter in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact representation MAY be <del> used also in the COSE_Key.  If the COSE implementation requires a 'y' parameter, the value y = false SHALL be used.  COSE always use compact output for Elliptic Curve Keys of type EC2. </del>  3.8.

First take on explaining how to calculate a Y value for old APIs not supporting the full {{SECG}} format.
Given e.g. the Julia programming language the calculations aretrivial For more constrained platforms maybe we should have some link to a paper explaining how to do this type of calculations on constrained platforms. URL URL file:///Users/emanjon/Downloads/applsci-10-URL
If a y-coordinate is required then the value ~yp SHALL be set to zero This leads to unnecesary extra code if a y value is calculated. I suggest that we reformulate this
Erik Thormarker wrote me that RFC 6090 Appendix C is a good high level reference for this.
LGTM
NAME and others: is the new text sufficient to support implementers which has to use a library requiring the y-coordinate?
Merged PR to master that addresses this
Here some comments after going through the PR.

keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and 7.2 of RFC9053, but only including the 'x' parameter in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact representation MAY be  <ins> used also in the COSE_Key.  COSE always uses compact output for Elliptic Curve Keys of type EC2.  If the COSE implementation requires a 'y' parameter, the value y = false or a calculated y-coordinate can be used, see comrep. </ins> 3.8.


EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma. <del> The parties exchanging messages are called Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared secret session key PRK_out, and derive symmetric application keys used to protect application data. </del>  G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively. identifying a connection for which keys are agreed. Connection identifiers may be used to correlate EDHOC messages and <del> facilitate the retrieval of protocol state during EDHOC execution </del>  (see transport), or may be used in applications of EDHOC, e.g., in OSCORE (see ci-oscore).  The connection identifiers do not have any cryptographic purpose in EDHOC except facilitating the retrieval of The transport needs to support the correlation between EDHOC messages and facilitate the retrieval of protocol state and security context <del> during EDHOC protocol execution, including an indication of a message being message_1.  The correlation may reuse existing mechanisms in the transport protocol.  For example, the CoAP Token may be used to </del>  correlate EDHOC messages in a CoAP response and an associated CoAP request. Connection identifiers may be used to correlate EDHOC messages and <del> facilitate the retrieval of protocol state/security context during EDHOC protocol execution.  Transports that do not inherently provide correlation across all EDHOC messages of an exchange can send connection identifiers along with EDHOC messages to gain that required capability, e.g., by prepending the appropriate connection identifier (when available from the EDHOC protocol) to the EDHOC message.  Transport of EDHOC in CoAP payloads is described in coap, which also shows how to use connection identifiers and message_1 indication with CoAP. </del>  3.5. does not include negotiation of cipher suites, but it enables the Responder to verify that the selected cipher suite is the most preferred cipher suite by the Initiator which is supported by both <del> the Initiator and the Responder. </del>  As required by RFC7258, IETF protocols need to mitigate pervasive monitoring when possible.  EDHOC therefore only supports methods with

Triggered by one of Marco's comments [Section 8.1] "A single session of EDHOC does not include negotiation of cipher suites" Perhaps do you mean "a single exchange of two EDHOC messages" ? See
URL
Changes in , here are detailed responses, except: regarding changes in EAD for which there is parallel work in the comment on section 5.1 which we make into a separate thread. NAME Please look through these responses and see if you have any comments. [Section 2] "... using keys derived from the shared secret." This should be the ECDH shared secret derived from GX and GY. It has not been introduced before, and it appears a little later for the first time. Hence, here it can be confused with the "shared secret key PRKout" mentioned before, in the first paragraph after Figure 2. GS: Rephrased as NEW "- crypto algorithms applied with keys derived from one or more shared secrets calculated during the protocol" [Section 3.3] s/certain byte string identifiers/certain identifiers GS: DONE [Section 3.3.2] A lot of text in this section takes CBOR byte strings as a starting point. However, as mentioned in Section 3.3.0, "Connection identifiers in EDHOC are intrinsically byte strings." I read this as "raw byte strings", rather than "CBOR byte strings". One may still choose to generate and store the identifiers precisely as CBOR byte strings, but they are still raw byte strings at their core. Then, I think the following editorial changes would make the text in this section simpler and less prone to confusion. Remove the sentence: "This correspondence between integers and byte strings is a natural mapping between the byte strings with CBOR diagnostic notation h'00', h'01', ..., h'37' (except h'18', h'19', ..., h'1F') and integers which are CBOR encoded as one byte." GS: DONE s/are encoded as normal CBOR byte strings/are simply encoded as CBOR byte strings GS: DONE The text "h'21' is represented by 0x21 (CBOR encoding of the integer -2), not by 0x4121." becomes: "0x21 is represented by 0x21 (CBOR encoding of the integer -2), not by the CBOR encoding 0x4121." The text "h'0D' is represented by 0x0D (CBOR encoding of the integer 13), not by 0x410D." becomes: "0x0D is represented by 0x0D (CBOR encoding of the integer 13), not by the CBOR encoding 0x410D." The text "h'18' is represented by 0x4118." becomes: "0x18 is represented by 0x4118 (CBOR encoding of the byte string 0x18)." The text "h'38' is represented by 0x4138." becomes: "0x38 is represented by 0x4138 (CBOR encoding of the byte string 0x38)." The text "h'ABCD' is represented by 0x42ABCD." becomes: "0xABCD is represented by 0x42ABCD (CBOR encoding of the byte string 0xABCD)." GS: Did something similar: NEW 0x21 is represented by 0x21 (CBOR encoding of the integer -2), not by 0x4121 (CBOR encoding of the byte string 0x21). 0x0D is represented by 0x0D (CBOR encoding of the integer 13), not by 0x410D (CBOR encoding of the byte string 0x0D). 0x18 is represented by 0x4118 (CBOR encoding of the byte string 0x18). 0x38 is represented by 0x4138 (CBOR encoding of the byte string 0x38). 0xABCD is represented by 0x42ABCD (CBOR encoding of the byte string 0xABCD). The text "A byte string which parses as a CBOR int in the range -24,..., 23 is just copied directly into the message" becomes: "A byte string which parses as the 1-byte CBOR encoding of an integer in the range -24, ..., 23 is just copied directly into the message". GS: Did something similar: NEW A byte string which parses as the one-byte CBOR encoding of an integer (i.e. integer in the interval -24, ..., 23) is just copied directly into the message The text "produces a byte string or an integer depending on its value." becomes: "produces a CBOR byte string or a CBOR integer depending on the value of the byte string identifier." GS: DONE [Section 3.4] s/fragmentation/fragmentation and reassembly GS: DONE [Section 3.5.1] "The authentication key algorithm needs to be compatible with the method and the cipher suite" This should be specifically the selected cipher suite, right? GS: DONE [Section 3.5.2] s/on a specific encoding of the credential/on the specific encoding of the credentials GS: DONE "When the authentication credential is a COSEKey in a CWT, CREDx SHALL be the untagged CWT." This should be: "When the authentication credential is a CWT including a COSEKey, then CREDx SHALL be the untagged CWT." GS: DONE "When the authentication credential is a COSEKey but not in a CWT, CREDx SHALL be an untagged CCS." This should be: "When the authentication credential includes a COSEKey but it is not a CWT, then CREDx SHALL be an untagged CCS." GS: NEW "When the authentication credential includes a COSEKey but is not a CWT, then CREDx SHALL be an untagged CCS." [Section 3.5.3] s/the sender's credential/the message sender's credential GS: DONE "the integer representation of byte string identifiers in Section MUST be applied." I think it would be clearer to say: "the same representation used for EDHOC connection identifiers and defined in Section 3.3.2 MUST be applied." GS: DONE [Section 3.6] s/The MAC length MUST be/The EDHOC MAC length MUST be GS: DONE s/independently of the cipher suite/independently of the selected cipher suite GS: DONE "Note that AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with the IEEE CCM mode." This should be: "Note that AES-CCM-16-64-128 and AES-CCM-16-128-128 are compatible with the IEEE CCM mode." GS: DONE [Section 3.8] "If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued." Must an EDHOC error message also be sent before discontinuing the protocol? Is it something that must be specified by the application/specification that defines the EAD item and its processing when used as critical? See also later comments about Section 5.x on sending an EDHOC error message if any processing step fails. GS: NOT DONE - pending merging PR about EAD padding [Section 3.9] "For some parameters, ... the receiver is able to verify compliance with the application profile" It's better to explicitly say "the receiver of an EDHOC message". Later on in the same section, it occurs again in "the receiver need to be able to determine ..." GS: DONE "Other conditions may be part of the application profile, such as target application or use (if there is more than one application/use) to the extent that EDHOC can distinguish between them." Proposed rephrasing: "Other conditions may be part of the application profile, such as the different target application or use (if there is more than one application/use), in which case EDHOC needs to be able to distinguish between them." GS: I did not do the change in second part since that is removing an important remark (that EDHOC may not be able to distinguish different uses) and since the proposed new formulation is duplicating the content of the following sentence. NEW Other conditions may be part of the application profile, such as what is the target application or use (if there is more than one application/use) to the extent that EDHOC can distinguish between them. "for example based on URI or external authorization data type." What URI? I guess this means the URI pointing to an EDHOC resource where an EDHOC message is sent. In that case, an application profile is associated with one or more EDHOC resources, identified by the corresponding URIs and targeted by the EDHOC messages sent to that node. GS: Changed "URI" to "URI to which the EDHOC message is sent" [Section 4.1.2] In the bullet list above Figure 7, the description of "keylength" and of "ivlength" should also conclude with "of the selected cipher suite", just like for "hashlength". GS: DONE [Section 5.1] Let's say that we have: the Initiator acting as CoAP client and not supporting EDHOC message4; and the Responder that instead supports EDHOC message4. Eventually, the Initiator sends EDHOC message3. Since the Initiator does not support EDHOC message4, it moves to a protocol state where the only expected, next EDHOC message is an EDHOC error message. Then, the Responder sends back EDHOC message4 as a response. This is not wrong to do per se. In fact, an application profile can say that message4 shall be sent, but it cannot really say that it shall not be sent. Besides, the Initiator might generally not be aware of the application profile. This is actually only a specific example of something more general. That is, what should the Initiator do after having sent EDHOC message3, if it receives as a reply something not expected as per its current protocol state? This is still a processing failure (see second from last paragraph of Section 5.1). However, should the Initiator still send an EDHOC error message and thus discontinue EDHOC even in this case where the protocol is basically complete? I believe the answer is "no, it should be fine with that, unless there is a very strong reason to do otherwise." In that spirit, I propose to extend the second from last paragraph of Section 5.1 with some text along these lines: "After having sent EDHOC message3, the Initiator remains ready to possibly receive as following EDHOC messages: i) EDHOC message4 or an EDHOC error message, if the Initiator supports EDHOC message4; or ii) an EDHOC error message, if the Initiator does not support EDHOC message4. If, after having sent EDHOC message3, the Initiator receives an EDHOC message that does not match with what it expects or that results in a processing failure, then the Initiator SHOULD NOT send an EDHOC error message and SHOULD NOT discontinue the EDHOC protocol. An exception applies in case the Initiator supports EDHOC message4 and is aware of the application profile that states that EDHOC message4 shall be sent. After having sent EDHOC message4, the Responder remains ready to possibly receive a following EDHOC error message. If, after having sent EDHOC message4, the Responder receives an EDHOC message that does not match with what it expects or that results in a processing failure, then the Responder MUST NOT send an EDHOC error message and MUST NOT discontinue the EDHOC protocol." GS: I'll make this a separate thread. [Section 5.2.3] "If any processing step fails, the Responder MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD1 available to the application? GS: TBD pending merging PR about EAD padding [Section 5.3.2] "The transcript hash TH2 is a CBOR encoded bstr ..." Well, TH2 as output of H() is simply raw bytes, i.e, not a CBOR item. Only later on is a CBOR-encoded TH2 used, e.g., when building context2. Then it should be ok to simply remove the quoted text. GS: DONE "Compute KEYSTREAM2 as in ..." Here it's good to give a pointer to Appendix I "Long PLAINTEXT2". GS: DONE "Verify SignatureorMAC2 using ..." It's worth mentioning that, after this step, the Initiator might have to get back to processing some EAD items from EAD2, that were previously made available to the application but not (entirely) processed yet. This is the case, e.g., if their processing requires to first achieve proof-of-possession of the Responder's private key, which happens after having successfully verified SignatureorMAC2. GS: DONE "If any processing step fails, the Initiator MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD2 available to the application? GS: Yes, processing also covers EAD processing GS: TBD pending merging PR about EAD padding [Section 5.4.2] "The transcript hash TH3 is a CBOR encoded bstr ..." Like in a comment above, TH3 as output of H() is simply raw bytes, i.e., not a CBOR item. Only later on is a CBOR-encoded TH3 used, e.g., when building context3. Then it should be ok to simply remove the quoted text. GS: DONE "The transcript hash TH4 is a CBOR encoded bstr ..." Like in the comment above, TH4 as output of H() is simply raw bytes, i.e, not a CBOR item. Only later on is a CBOR-encoded TH4 used, e.g., as input to EDHOC-KDF. Then it should be ok to simply remove the quoted text. GS: DONE [Section 5.4.3] "Verify SignatureorMAC3 using ..." It's worth mentioning that, after this step, the Responder might have to get back to processing some EAD items from EAD3, that were previously made available to the application but not (entirely) processed yet. This is the case, e.g., if their processing requires to first achieve proof-of-possession of the Initiator's private key, which happens after having successfully verified SignatureorMAC3. GS: DONE "If any processing step fails, the Responder MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD3 available to the application? GS: TBD pending merging PR about EAD padding [Section 5.5.3] "If any processing step fails, the Initiator MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD4 available to the application? GS: TBD pending merging PR about EAD padding [Section 6.3] "ERRINFO is in this case denoted SUITESR" This should be, e.g., "In this case, ERRINFO specifies SUITESR" GS: I didn’t understand why “specifies” is more clear than “is denoted”. Proposal: NEW In this case, ERRINFO = SUITESR "SUITESR MAY include a single cipher suite, i.e., be encoded as an int." This should be "SUITESR MAY include a single cipher suite, in which case it is encoded as an int." GS: DONE "selects its most preferred and the Responder sends an error with supported cipher suites." This should be "selects its most preferred cipher suites and the Responder sends an error with its supported cipher suites." GS: DONE [Section 8.1] "A single session of EDHOC does not include negotiation of cipher suites" Perhaps do you mean "a single exchange of two EDHOC messages" ? GS: I think “session” is the right term here. We use that to describe a specific execution of the EDHOC protocol. The negotiation of cipher suites requires the discontinuation of one session and the start of a new, so it is not a single session of EDHOC. "... until the Initiator has verified an OSCORE message or message4 from the Responder. Like in Section 5.4.2, this should be: "... until the Initiator has verified message4 or a message protected with a derived application key, such as an OSCORE message, from the Responder." GS: DONE [Section 8.3] "... so that a sufficient security level is maintained for certificates, EDHOC, and the protection of application data." Does "certificates" actually mean "authentication credentials"? Does "EDHOC" actually mean "EDHOC executions" or "EDHOC messages"? GS: Done, expanding “EDHOC” to “the EDHOC protocol” [Section 8.8] "Note that part of KEYSTREAM2 is also non-secret randomness as it is known or predictable to an attacker." Proposed rephrasing: "Note that part of KEYSTREAM2 does not enjoy non-secret randomness either, as it is known or predictable to an attacker." GS: Not done, what is the issue with the current formulation? "enjoy randomness" seems not being a common phrasing. [Section 9] Throughout the whole section: s/group name/registry groupWhen mentioning a registration procedure, refer to RFC 8126 (to be added as normative reference). GS: DONE [Section 9.7] You can remove "under the group name "Well-Known URIs"". GS: DONE [Appendix A] s/when OSCORE is used with EDHOC/when EDHOC is used to key OSCORE GS: DONE [Appendix A.2] "with response codes analogously to message2" This should be: "with response codes analogous to those of the response to message2". "In case of an error message in response to message4, it is sent analogously to errors in response to message2." This should be: "In case of an error message sent as reply to message4, it is sent analogously to an error message sent as reply to message2." GS: DONE s/See Figure 13/See Figure 13 for an example GS: DONE s/See Figure 14/See Figure 14 for an example GS: DONE s/to these messages/to the CoAP messages that transport an EDHOC message prepended by a connection identifier GS: DONE in singular [Appendix A.2.1] "When using EDHOC over CoAP for establishing an OSCORE Security Context, EDHOC error messages ..." The following text about error responses and response code applies also in case EDHOC is used for keying something different than OSCORE. Hence the sentence can be shortened as: "When using EDHOC over CoAP, EDHOC error messages ..." GS: DONE (in commit labelled A.1) [Appendix J] "The change of PRKout causes a change to PRKexporter and keys derived using EDHOC-Exporter." This refers specifically to EDHOC-KeyUpdate, which certainly causes a change to PRKexporter, but not directly to existing keys previously derived using EDHOC-Exporter. I would expect that existing application keys derived from the old PRKexporter remain unchanged, at least at the end of EDHOC-KeyUpdate. At the same time, the final goal of an application triggering EDHOC-KeyUpdate is practically to update application keys. So perhaps the quoted sentence can be rephrased to say that: i) the newly derived PRKexporter is used from then on in order to derive new application keys with EDHOC-Exporter; and ii) current, existing application keys previously derived with EDHOC-Exporter can be re-derived using the new PRK_exporter. The newly derived applications keys supersed e the old ones. When to delete the old application keys and how to verify that they are not needed is up to the application. GS: DONE in paragraphs before and after pseudocode. [Nits] Section 1.1: --- s/criteria/criterion --- s/prohibitive/prohibitively large GS: DONE Section 2: --- s/Like (D)TLS/Like in (D)TLS --- s/the application, EDHOC/the application. EDHOC GS: DONE Section 3.2: --- s/indicate protocol/indicate the protocol GS: DONE Section 3.3: --- s/or in subsequent/or may be used in subsequent GS: Did “or may be used in” --- s/CBOR ints/CBOR integers GS: DONE and other similar --- s/associated to the/associated with the GS: DONE and other similar Section 3.3.2: --- s/encoding: A byte/encoding: a byte --- s/message, a byte string which doesn't/message; a byte string which does not --- s/representation it can/representation, it can GS: DONE Section 3.3.3: --- s/results in same/results in the same GS: DONE Section 3.4: --- s/In addition to transport/In addition to the transport GS: DONE Section 3.5.1: --- s/Note that for most signature/Note that, for most signature GS: Not done. There are multiple occurrences of this, but it is consequently without comma. Either we change none or all, and I’m currently inclined to do none. --- s/keys are denoted I/keys are denoted as I GS: DONE Section 3.5.3: --- s/within EDHOC, for example/within EDHOC. For example GS: DONE Section 3.6: --- s/follows from COSE/follow from COSE GS: DONE Section 3.7: --- s/In COSE compact/In COSE, compact GS: DONE Section 3.8: --- s/registers their own/registers its own --- s/non-critical, determined by/non-critical, as determined by GS: Not done yet - pending merge of EAD-padding PR Section 3.9: --- s/because of wrong/because of a wrong GS: Not done, I think the current formulation is fine --- s/uses public/uses a public GS: DONE Section 4.1.2: --- s/is used is specified/is used are specified GS: DONE Section 5.1 --- s/associated to an/associated with an GS: DONE Section 5.4.2: --- s/for acknowledgement/for an acknowledgement GS: DONE Section 5.5: --- s/of such deployments:/of such deployments are: GS: DONE Section 6: --- s/Errors messages in EDHOC/Error messages in EDHOC --- s/associated to the/associated with the GS: DONE Section 6.3.2: --- s/so therefore selects/therefore it selects GS: Not done, I think the current formulation is fine --- s/The initiator prepends/The Initiator prepends GS: DONE and other similar Section 7 --- s/differ in size of/differ in the size of GS: DONE --- s/is no essential difference/is of no essential difference GS: Not done, I think the current formulation is fine Section 8.1 --- s/and send its own/and then sending its own GS: DONE --- s/Either of these provide/Both of them provide GS: I want it to be clear that either one or the other of these methods, independently of each other, provides this property. “both of them” is less clear and may be confused with that both are needed to provide the property. I only fixed the grammar. --- s/in the application protocol fail/in the application protocol fails GS: Done in separate commit Section 8.2 --- s/future EHDOC methods/future EDHOC methods GS: DONE and other similar Section 8.3 --- s/whole authentication credential/whole authentication credentials GS: DONE Section 8.5 --- s/update the connection identifier/update the connection identifiers GS: DONE Section 8.6 --- s/An passive attacker/A passive attacker GS: DONE Section 8.8 --- s/PNRG/PRNG (2 occurrences) GS: DONE --- s/to select its connection identifiers/to select the connection identifier GS: DONE --- s/ongoing EDHOC protocol/ongoing EDHOC protocol execution GS: Not done, I think the current formulation is fine --- s/sets that will be/sets will be OLD which of the parameter sets that will be used NEW which parameter set that will be used --- s/do not make use/does not make use GS: DONE --- s/hash, this/hash. This GS: DONE Section 9.11 --- s/Expert should consider/Experts should consider GS: DONE Appendix A.2.1 --- s/EDHOC and OSCORE protocols/the EDHOC and OSCORE protocols GS: DONE Appendix C --- s/to simplify for implementors/to help implementors GS: DONE Appendix C.1 --- s/occurrance/occurrence GS: DONE in other commit Appendix D.2 --- s/associated to the/associated with the GS: DONE Appendix E --- s/external authorization related data/related external authorization data GS: DONE Appendix F --- s/with value empty/with value the empty GS: DONE Appendix G --- s/acknowledgement on CoAP messaging layer/acknowledgement on the CoAP messaging layer GS: DONE --- s/processing on CoAP messaging layer/processing on the CoAP messaging layer GS: DONE --- s/differences which compromises/differences which compromise GS: DONE Appendix I --- s/algorithm the length/algorithm, the length GS: DONE
Thanks, it looks good! Please see my replies on two specific points in the separate comments below. I understand that what is still open includes: Handling critical failure of EAD processing (Sections 3.8, 5.2.3, 5.3.3, 5.4.3 and 5.3.3). Exceptions to discontinuing the protocol after having sent message_3 (Section 5.1).
So far, I've always seen an "EDHOC execution" as consisting of "message exchanges" and "message processing", during which an associated "session" is built and referred to. If "session" has to be intended as a specific "EDHOC execution" as a whole (and not just an incrementally built environment associated with it), maybe it's better to give an early definition of "session".
Trimming the original sentence, I can't parse "part of KEYSTREAM2 is non-secret randomness". I think my problem here is seeing the verb "is": while KEYSTREAM2 is a "thing", randomness is a possible property of that thing. Perhaps you mean "does not have secret randomness" (better suggestion than "enjoy"), or "is not secretly random".
[Section 8.8] The term may be confusing, but it is used in the literature, e.g. in Krawczyk's paper on The HKDF Scheme (URL): Also in this case, "non-secret randomness" is referring to a "thing", namely an IV. Since the text in the draft is related to the discussion in the literature it is favorable if we can use the same terminology.
Thanks, I agree. With that context in mind, "KEYSTREAM_2 is also non-secret randomness" is just fine then.
[Section 8.1] Yes, multiple terms are used. There was a change from "protocol instance" to "session", and that has also been used in the security analysis. The terms are "EDHOC exchange" and "protocol execution" also makes sense to keep in certain instances. I added session early in the text and also made some related changes in a separate PR Does this address your comment?
Yes, that looks good. Thanks!
[Section 5.1] I agree with the general aim of this comment. Let's see what if any needs to be rephrased. If the Initiator successfully completed its part of the message exchange there is no protocol to discontinue and therefore no reason to send error. Is this what needs to be clarified? EDHOC requires certain parameters to be agreed upon between Initiator and Responder, including if message_4 shall be sent/expected. So from that point of view the Initiator should know if it has completed the protocol or not. (If need to describe a change after message exchange is completed then "terminate session" is probably better terminology than "discontinue protocol".)
I made two more commits on PR . In the interest of harmonizing the terminology I went for "discontinue protocol" which is frequently used. I tried to capture Marco's comment on 5.1. NAME NAME Please review
Closing this as is merged Hi all, I think that this document is in a very good shape! Please see below some detailed comments. Best, /Marco [Section 2] "... using keys derived from the shared secret." This should be the ECDH shared secret derived from GX and GY. It has not been introduced before, and it appears a little later for the first time. Hence, here it can be confused with the "shared secret key PRKout" mentioned before, in the first paragraph after Figure 2. [Section 3.3] s/certain byte string identifiers/certain identifiers [Section 3.3.2] A lot of text in this section takes CBOR byte strings as a starting point. However, as mentioned in Section 3.3.0, "Connection identifiers in EDHOC are intrinsically byte strings." I read this as "raw byte strings", rather than "CBOR byte strings". One may still choose to generate and store the identifiers precisely as CBOR byte strings, but they are still raw byte strings at their core. Then, I think the following editorial changes would make the text in this section simpler and less prone to confusion. Remove the sentence: "This correspondence between integers and byte strings is a natural mapping between the byte strings with CBOR diagnostic notation h'00', h'01', ..., h'37' (except h'18', h'19', ..., h'1F') and integers which are CBOR encoded as one byte." s/are encoded as normal CBOR byte strings/are simply encoded as CBOR byte strings The text "h'21' is represented by 0x21 (CBOR encoding of the integer -2), not by 0x4121." becomes: "0x21 is represented by 0x21 (CBOR encoding of the integer -2), not by the CBOR encoding 0x4121." The text "h'0D' is represented by 0x0D (CBOR encoding of the integer 13), not by 0x410D." becomes: "0x0D is represented by 0x0D (CBOR encoding of the integer 13), not by the CBOR encoding 0x410D." The text "h'18' is represented by 0x4118." becomes: "0x18 is represented by 0x4118 (CBOR encoding of the byte string 0x18)." The text "h'38' is represented by 0x4138." becomes: "0x38 is represented by 0x4138 (CBOR encoding of the byte string 0x38)." The text "h'ABCD' is represented by 0x42ABCD." becomes: "0xABCD is represented by 0x42ABCD (CBOR encoding of the byte string 0xABCD)." The text "A byte string which parses as a CBOR int in the range -24,..., 23 is just copied directly into the message" becomes: "A byte string which parses as the 1-byte CBOR encoding of an integer in the range -24, ..., 23 is just copied directly into the message". The text "produces a byte string or an integer depending on its value." becomes: "produces a CBOR byte string or a CBOR integer depending on the value of the byte string identifier." [Section 3.4] s/fragmentation/fragmentation and reassembly [Section 3.5.1] "The authentication key algorithm needs to be compatible with the method and the cipher suite" This should be specifically the selected cipher suite, right? [Section 3.5.2] s/on a specific encoding of the credential/on the specific encoding of the credentials "When the authentication credential is a COSEKey in a CWT, CREDx SHALL be the untagged CWT." This should be: "When the authentication credential is a CWT including a COSEKey, then CREDx SHALL be the untagged CWT." "When the authentication credential is a COSEKey but not in a CWT, CREDx SHALL be an untagged CCS." This should be: "When the authentication credential includes a COSEKey but it is not a CWT, then CREDx SHALL be an untagged CCS." [Section 3.5.3] s/the sender's credential/the message sender's credential "the integer representation of byte string identifiers in Section MUST be applied." I think it would be clearer to say: "the same representation used for EDHOC connection identifiers and defined in Section 3.3.2 MUST be applied." [Section 3.6] s/The MAC length MUST be/The EDHOC MAC length MUST be s/independently of the cipher suite/independently of the selected cipher suite "Note that AES-CCM-16-64-128 and AES-CCM-16-64-128 are compatible with the IEEE CCM mode." This should be: "Note that AES-CCM-16-64-128 and AES-CCM-16-128-128 are compatible with the IEEE CCM mode." [Section 3.8] "If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued." Must an EDHOC error message also be sent before discontinuing the protocol? Is it something that must be specified by the application/specification that defines the EAD item and its processing when used as critical? See also later comments about Section 5.x on sending an EDHOC error message if any processing step fails. [Section 3.9] "For some parameters, ... the receiver is able to verify compliance with the application profile" It's better to explicitly say "the receiver of an EDHOC message". Later on in the same section, it occurs again in "the receiver need to be able to determine ..." "Other conditions may be part of the application profile, such as target application or use (if there is more than one application/use) to the extent that EDHOC can distinguish between them." Proposed rephrasing: "Other conditions may be part of the application profile, such as the different target application or use (if there is more than one application/use), in which case EDHOC needs to be able to distinguish between them." "for example based on URI or external authorization data type." What URI? I guess this means the URI pointing to an EDHOC resource where an EDHOC message is sent. In that case, an application profile is associated with one or more EDHOC resources, identified by the corresponding URIs and targeted by the EDHOC messages sent to that node. [Section 4.1.2] In the bullet list above Figure 7, the description of "keylength" and of "ivlength" should also conclude with "of the selected cipher suite", just like for "hashlength". [Section 5.1] Let's say that we have: the Initiator acting as CoAP client and not supporting EDHOC message4; and the Responder that instead supports EDHOC message4. Eventually, the Initiator sends EDHOC message3. Since the Initiator does not support EDHOC message4, it moves to a protocol state where the only expected, next EDHOC message is an EDHOC error message. Then, the Responder sends back EDHOC message4 as a response. This is not wrong to do per se. In fact, an application profile can say that message4 shall be sent, but it cannot really say that it shall not be sent. Besides, the Initiator might generally not be aware of the application profile. This is actually only a specific example of something more general. That is, what should the Initiator do after having sent EDHOC message3, if it receives as a reply something not expected as per its current protocol state? This is still a processing failure (see second from last paragraph of Section 5.1). However, should the Initiator still send an EDHOC error message and thus discontinue EDHOC even in this case where the protocol is basically complete? I believe the answer is "no, it should be fine with that, unless there is a very strong reason to do otherwise." In that spirit, I propose to extend the second from last paragraph of Section 5.1 with some text along these lines: "After having sent EDHOC message3, the Initiator remains ready to possibly receive as following EDHOC messages: i) EDHOC message4 or an EDHOC error message, if the Initiator supports EDHOC message4; or ii) an EDHOC error message, if the Initiator does not support EDHOC message4. If, after having sent EDHOC message3, the Initiator receives an EDHOC message that does not match with what it expects or that results in a processing failure, then the Initiator SHOULD NOT send an EDHOC error message and SHOULD NOT discontinue the EDHOC protocol. An exception applies in case the Initiator supports EDHOC message4 and is aware of the application profile that states that EDHOC message4 shall be sent. After having sent EDHOC message4, the Responder remains ready to possibly receive a following EDHOC error message. If, after having sent EDHOC message4, the Responder receives an EDHOC message that does not match with what it expects or that results in a processing failure, then the Responder MUST NOT send an EDHOC error message and MUST NOT discontinue the EDHOC protocol." [Section 5.2.3] "If any processing step fails, the Responder MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD1 available to the application? [Section 5.3.2] "The transcript hash TH2 is a CBOR encoded bstr ..." Well, TH2 as output of H() is simply raw bytes, i.e, not a CBOR item. Only later on is a CBOR-encoded TH2 used, e.g., when building context2. Then it should be ok to simply remove the quoted text. "Compute KEYSTREAM2 as in ..." Here it's good to give a pointer to Appendix I "Long PLAINTEXT2". "Verify SignatureorMAC2 using ..." It's worth mentioning that, after this step, the Initiator might have to get back to processing some EAD items from EAD2, that were previously made available to the application but not (entirely) processed yet. This is the case, e.g., if their processing requires to first achieve proof-of-possession of the Responder's private key, which happens after having successfully verified SignatureorMAC2. "If any processing step fails, the Initiator MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD2 available to the application? [Section 5.4.2] "The transcript hash TH3 is a CBOR encoded bstr ..." Like in a comment above, TH3 as output of H() is simply raw bytes, i.e., not a CBOR item. Only later on is a CBOR-encoded TH3 used, e.g., when building context3. Then it should be ok to simply remove the quoted text. "The transcript hash TH4 is a CBOR encoded bstr ..." Like in the comment above, TH4 as output of H() is simply raw bytes, i.e, not a CBOR item. Only later on is a CBOR-encoded TH4 used, e.g., as input to EDHOC-KDF. Then it should be ok to simply remove the quoted text. [Section 5.4.3] "Verify SignatureorMAC3 using ..." It's worth mentioning that, after this step, the Responder might have to get back to processing some EAD items from EAD3, that were previously made available to the application but not (entirely) processed yet. This is the case, e.g., if their processing requires to first achieve proof-of-possession of the Initiator's private key, which happens after having successfully verified SignatureorMAC3. "If any processing step fails, the Responder MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD3 available to the application? [Section 5.5.3] "If any processing step fails, the Initiator MUST send an EDHOC error message back ..." Does "processing" cover also the actual EAD processing, or only the act of making EAD4 available to the application? [Section 6.3] "ERRINFO is in this case denoted SUITESR" This should be, e.g., "In this case, ERRINFO specifies SUITESR" "SUITESR MAY include a single cipher suite, i.e., be encoded as an int." This should be "SUITESR MAY include a single cipher suite, in which case it is encoded as an int." "selects its most preferred and the Responder sends an error with supported cipher suites." This should be "selects its most preferred cipher suites and the Responder sends an error with its supported cipher suites." [Section 8.1] "A single session of EDHOC does not include negotiation of cipher suites" Perhaps do you mean "a single exchange of two EDHOC messages" ? "... until the Initiator has verified an OSCORE message or message4 from the Responder. Like in Section 5.4.2, this should be: "... until the Initiator has verified message4 or a message protected with a derived application key, such as an OSCORE message, from the Responder." [Section 8.3] "... so that a sufficient security level is maintained for certificates, EDHOC, and the protection of application data." Does "certificates" actually mean "authentication credentials"? Does "EDHOC" actually mean "EDHOC executions" or "EDHOC messages"? [Section 8.8] "Note that part of KEYSTREAM2 is also non-secret randomness as it is known or predictable to an attacker." Proposed rephrasing: "Note that part of KEYSTREAM2 does not enjoy non-secret randomness either, as it is known or predictable to an attacker." [Section 9] Throughout the whole section: s/group name/registry group When mentioning a registration procedure, refer to RFC 8126 (to be added as normative reference). [Section 9.7] You can remove "under the group name "Well-Known URIs"". [Appendix A] s/when OSCORE is used with EDHOC/when EDHOC is used to key OSCORE [Appendix A.2] "with response codes analogously to message2" This should be: "with response codes analogous to those of the response to message2". "In case of an error message in response to message4, it is sent analogously to errors in response to message2." This should be: "In case of an error message sent as reply to message4, it is sent analogously to an error message sent as reply to message2." s/See Figure 13/See Figure 13 for an example s/See Figure 14/See Figure 14 for an example s/to these messages/to the CoAP messages that transport an EDHOC message prepended by a connection identifier [Appendix A.2.1] "When using EDHOC over CoAP for establishing an OSCORE Security Context, EDHOC error messages ..." The following text about error responses and response code applies also in case EDHOC is used for keying something different than OSCORE. Hence the sentence can be shortened as: "When using EDHOC over CoAP, EDHOC error messages ..." [Appendix J] "The change of PRKout causes a change to PRKexporter and keys derived using EDHOC-Exporter." This refers specifically to EDHOC-KeyUpdate, which certainly causes a change to PRKexporter, but not directly to existing keys previously derived using EDHOC-Exporter. I would expect that existing application keys derived from the old PRKexporter remain unchanged, at least at the end of EDHOC-KeyUpdate. At the same time, the final goal of an application triggering EDHOC-KeyUpdate is practically to update application keys. So perhaps the quoted sentence can be rephrased to say that: i) the newly derived PRKexporter is used from then on in order to derive new application keys with EDHOC-Exporter; and ii) current, existing application keys previously derived with EDHOC-Exporter can be re-derived using the new PRK_exporter. The newly derived applications keys supersede the old ones. When to delete the old application keys and how to verify that they are not needed is up to the application. [Nits] Section 1.1: --- s/criteria/criterion --- s/prohibitive/prohibitively large Section 2: --- s/Like (D)TLS/Like in (D)TLS --- s/the application, EDHOC/the application. EDHOC Section 3.2: --- s/indicate protocol/indicate the protocol Section 3.3: --- s/or in subsequent/or may be used in subsequent --- s/CBOR ints/CBOR integers --- s/associated to the/associated with the Section 3.3.2: --- s/encoding: A byte/encoding: a byte --- s/message, a byte string which doesn't/message; a byte string which does not --- s/representation it can/representation, it can Section 3.3.3: --- s/results in same/results in the same Section 3.4: --- s/In addition to transport/In addition to the transport Section 3.5.1: --- s/Note that for most signature/Note that, for most signature --- s/keys are denoted I/keys are denoted as I Section 3.5.3: --- s/within EDHOC, for example/within EDHOC. For example Section 3.6: --- s/follows from COSE/follow from COSE Section 3.7: --- s/In COSE compact/In COSE, compact Section 3.8: --- s/registers their own/registers its own --- s/non-critical, determined by/non-critical, as determined by Section 3.9: --- s/because of wrong/because of a wrong --- s/uses public/uses a public Section 4.1.2: --- s/is used is specified/is used are specified Section 5.1 --- s/associated to an/associated with an Section 5.4.2: --- s/for acknowledgement/for an acknowledgement Section 5.5: --- s/of such deployments:/of such deployments are: Section 6: --- s/Errors messages in EDHOC/Error messages in EDHOC --- s/associated to the/associated with the Section 6.3.2: --- s/so therefore selects/therefore it selects --- s/The initiator prepends/The Initiator prepends Section 7 --- s/differ in size of/differ in the size of --- s/is no essential difference/is of no essential difference Section 8.1 --- s/and send its own/and then sending its own --- s/Either of these provide/Both of them provide --- s/in the application protocol fail/in the application protocol fails Section 8.2 --- s/future EHDOC methods/future EDHOC methods Section 8.3 --- s/whole authentication credential/whole authentication credentials Section 8.5 --- s/update the connection identifier/update the connection identifiers Section 8.6 --- s/An passive attacker/A passive attacker Section 8.8 --- s/PNRG/PRNG (2 occurrences) --- s/to select its connection identifiers/to select the connection identifier --- s/ongoing EDHOC protocol/ongoing EDHOC protocol execution --- s/sets that will be/sets will be --- s/do not make use/does not make use --- s/hash, this/hash. This Section 9.11 --- s/Expert should consider/Experts should consider Appendix A.2.1 --- s/EDHOC and OSCORE protocols/the EDHOC and OSCORE protocols Appendix C --- s/to simplify for implementors/to help implementors Appendix C.1 --- s/occurrance/occurrence Appendix D.2 --- s/associated to the/associated with the Appendix E --- s/external authorization related data/related external authorization data Appendix F --- s/with value empty/with value the empty Appendix G --- s/acknowledgement on CoAP messaging layer/acknowledgement on the CoAP messaging layer --- s/processing on CoAP messaging layer/processing on the CoAP messaging layer --- s/differences which compromises/differences which compromise Appendix I --- s/algorithm the length/algorithm, the length Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity URL

EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma.  <ins> The parties exchanging messages in an EDHOC session are called Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared secret session key PRK_out, and derive symmetric application keys used to protect application data. </ins> G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively. identifying a connection for which keys are agreed. Connection identifiers may be used to correlate EDHOC messages and  <ins> facilitate the retrieval of protocol state during an EDHOC session </ins> (see transport), or may be used in applications of EDHOC, e.g., in OSCORE (see ci-oscore).  The connection identifiers do not have any cryptographic purpose in EDHOC except facilitating the retrieval of The transport needs to support the correlation between EDHOC messages and facilitate the retrieval of protocol state and security context  <ins> during an EDHOC session, including an indication of a message being message_1.  The correlation may reuse existing mechanisms in the transport protocol.  For example, the CoAP Token may be used to </ins> correlate EDHOC messages in a CoAP response and an associated CoAP request. Connection identifiers may be used to correlate EDHOC messages and  <ins> facilitate the retrieval of protocol state/security context during an EDHOC session.  Transports that do not inherently provide correlation across all messages of an EDHOC session can send connection identifiers along with EDHOC messages to gain that required capability, e.g., by prepending the appropriate connection identifier (when available from the EDHOC protocol) to the EDHOC message. Transport of EDHOC in CoAP payloads is described in coap, which also shows how to use connection identifiers and message_1 indication with CoAP. </ins> 3.5. does not include negotiation of cipher suites, but it enables the Responder to verify that the selected cipher suite is the most preferred cipher suite by the Initiator which is supported by both  <ins> the Initiator and the Responder, and to discontinue the session if not. </ins> As required by RFC7258, IETF protocols need to mitigate pervasive monitoring when possible.  EDHOC therefore only supports methods with


IoT. EDHOC is designed for highly constrained settings making it <del> especially suitable for low-power wide area networks RFC8376 such as Cellular IoT, 6TiSCH, and LoRaWAN.  A main objective for EDHOC is to be a lightweight authenticated key exchange for OSCORE, i.e., to provide authentication and session key establishment for IoT use cases such as those built on CoAP RFC7252 involving 'things' with embedded microcontrollers, sensors, and actuators.  By reusing the same lightweight primitives as OSCORE (CBOR, COSE, CoAP) the additional code size can be kept very low.  Note that while CBOR and COSE primitives are built into the protocol messages, EDHOC is not bound to a particular transport. </del>  A typical setting is when one of the endpoints is constrained or in a constrained network, and the other endpoint is a node on the Internet C_I and C_R are chosen by I and R, respectively.  The Initiator selects C_I and sends it in message_1 for the Responder to use as a <del> reference to the connection in communications with the Initiator. The Responder selects C_R and sends it in message_2 for the Initiator to use as a reference to the connection in communications with the </del>  Responder. If connection identifiers are used by an application protocol for

URL Hi all, I am sending below a couple of points and nits I found when reading the draft top to bottom. Generally, I find the draft in a good shape to proceed with publication. One point I would like to discuss is whether it would be useful to specify a protocol state machine in this draft. Different steps related to message and error processing are scattered throughout the Section 5, but it would be very useful from the implementor’s point of view to have the valid states summarized and illustrated through a figure. I guess something similar to Appendix A of RFC 8446 would be nice. Another point that introduced confusion for me when implementing this draft is whether the transcript hashes should be CBOR wrapped. For example, in Section 5.3.2. TH2 is first defined as the output of the hash function TH2 = H( GY, CR, H(message1) ), only to be followed by the sentence saying "The transcript hash TH2 is a CBOR encoded bstr”. I find confusing here whether the definition of TH2 includes the CBOR byte string wrapping or not, which is important for further uses of transcript hashes in the derivation of the keying material. Same applies for TH3 and TH4. It is worthwhile to note here that we interop’d using raw values of transcript hashes without CBOR byte string wrapping. If this is the way the transcript hashes were intended to be defined, then I do not understand the purpose of the quoted sentence. I also noted a couple of remnants that seem to be already signaled in github, remnant in issue on transcript hash, and the inconsistent use of session key terminology (PRKout vs session key) signaled by Charlie Jacomme. Minor nits to be fixed (possibly already signaled by others): “Section 1.1: EDHOC is designed for highly constrained settings making it especially suitable for low-power wide area networks [RFC8376] such as Cellular IoT, 6TiSCH, and LoRaWAN. “ Note that 6TiSCH is not a wide area network. Removing “wide area” from the quoted sentence, i.e. saying “low-power networks” would work. Section 3.3.1: s/communications/communication Section 3.7: s/COSE always use/COSE always uses Section 3.8: s/need to register/needs to register Section 6: s/Errors messages in EDHOC/Error messages in EDHOC Section 8.2: s/EHDOC/EDHOC That would be it, congrats to the author team for getting the specification to this shape. Finally, apologies for sending this review a morning after the deadline! Mališa

One point I would like to discuss is whether it would be useful to specify a protocol state machine in >this draft. Different steps related to message and error processing are scattered throughout the >Section 5, but it would be very useful from the implementor’s point of view to have the valid states >summarized and illustrated through a figure. I guess something similar to Appendix A of RFC 8446 >would be nice. This was discussed before and decided to not do as EDHOC does not really have the kind of states that TLS 1.3 does. I don't think RFC 8446 is a good example. Not against making a figure but the figure would likely be quite simple and trivial, but maybe that is good to show.
NAME I agree that the TLS 1.3 state machine is much more complex but I think it'd still be good to have this common for the implementations, in order for them not to have to reinvent it themselves. There is at least the negotiation step which makes it not straightforward (in a literal sense). Let's discuss at IETF 115.
Discussion at IETF 115 (URL): MV: I volunteer to provide a first sketch of state machine for an appendix. DN: Maybe too optimistic. If the state machine in the figure is not perfectly aligned with the specification, this will create problem. GS: Can we give it a try with a sketch in an appendix, before deciding to keep it or not? SF: Yes, and we can have a quick check on the mailing list about keeping it.
Clarified in (in 1cec57b)
I think those are fixed but please check.
Some of the comments are already fixed in other updates, the remaining should be in .
Just as an update on this, the current version of the state machine is at: URL It’d be great to get comments on that.
Closing this as state machine now has its own issue Hi all, I am sending below a couple of points and nits I found when reading the draft top to bottom. Generally, I find the draft in a good shape to proceed with publication. One point I would like to discuss is whether it would be useful to specify a protocol state machine in this draft. Different steps related to message and error processing are scattered throughout the Section 5, but it would be very useful from the implementor’s point of view to have the valid states summarized and illustrated through a figure. I guess something similar to Appendix A of RFC 8446 would be nice. Another point that introduced confusion for me when implementing this draft is whether the transcript hashes should be CBOR wrapped. For example, in Section 5.3.2. TH2 is first defined as the output of the hash function TH2 = H( GY, CR, H(message1) ), only to be followed by the sentence saying "The transcript hash TH2 is a CBOR encoded bstr”. I find confusing here whether the definition of TH2 includes the CBOR byte string wrapping or not, which is important for further uses of transcript hashes in the derivation of the keying material. Same applies for TH3 and TH4. It is worthwhile to note here that we interop’d using raw values of transcript hashes without CBOR byte string wrapping. If this is the way the transcript hashes were intended to be defined, then I do not understand the purpose of the quoted sentence. I also noted a couple of remnants that seem to be already signaled in github, remnant in issue on transcript hash, and the inconsistent use of session key terminology (PRKout vs session key) signaled by Charlie Jacomme. Minor nits to be fixed (possibly already signaled by others): “Section 1.1: EDHOC is designed for highly constrained settings making it especially suitable for low-power wide area networks [RFC8376] such as Cellular IoT, 6TiSCH, and LoRaWAN. “ Note that 6TiSCH is not a wide area network. Removing “wide area” from the quoted sentence, i.e. saying “low-power networks” would work. Section 3.3.1: s/communications/communication Section 3.7: s/COSE always use/COSE always uses Section 3.8: s/need to register/needs to register Section 6: s/Errors messages in EDHOC/Error messages in EDHOC Section 8.2: s/EHDOC/EDHOC That would be it, congrats to the author team for getting the specification to this shape. Finally, apologies for sending this review a morning after the deadline! Mališa

IoT. EDHOC is designed for highly constrained settings making it  <ins> especially suitable for low-power networks RFC8376 such as Cellular IoT, 6TiSCH, and LoRaWAN.  A main objective for EDHOC is to be a lightweight authenticated key exchange for OSCORE, i.e., to provide authentication and session key establishment for IoT use cases such as those built on CoAP RFC7252 involving 'things' with embedded microcontrollers, sensors, and actuators.  By reusing the same lightweight primitives as OSCORE (CBOR, COSE, CoAP) the additional code size can be kept very low.  Note that while CBOR and COSE primitives are built into the protocol messages, EDHOC is not bound to a particular transport. </ins> A typical setting is when one of the endpoints is constrained or in a constrained network, and the other endpoint is a node on the Internet C_I and C_R are chosen by I and R, respectively.  The Initiator selects C_I and sends it in message_1 for the Responder to use as a  <ins> reference to the connection in communication with the Initiator.  The Responder selects C_R and sends it in message_2 for the Initiator to use as a reference to the connection in communications with the </ins> Responder. If connection identifiers are used by an application protocol for


where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in Sections oscore.  4. 4.1.

Should be discussed in LAKE if this is the right approch Should be discussed what the best way is to calculate the hash chain The nonce is included to make sure that the hash chain does not have short cycles. It should be discussed if the nonce is provided by the application (OSCORE) or by EDHOC itself. If provided by OSCOREbis it could be a random string or a counter. If the nonce is provided by EDHOC it has to be a deterministic. E.g. a counter (or theoretically a LFSR....)

where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in Sections oscore. <ins> To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the function EDHOC-Exporter-FS.  When EHDOC-Exporter-FS is called the old PRK_4x3m is deleted and the new PRk_4x3m is calculated as a "hash" of the old key using the Extract function as illustrated by the following pseudocode: </ins> 4. 4.1.