Change:
Merging this to allow comments on it with -18.
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

Discussion:
If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, <del> the EDHOC protocol MUST be discontinued.  A non-critical EAD item can be ignored. </del> <ins> then the endpoint MUST send an EDHOC error message back as defined in error, and the protocol MUST be discontinued.  The EAD specification must define the error processing.  A non-critical EAD item can be ignored. </ins> The EAD fields of EDHOC must not be used for generic application data.  Examples of the use of EAD are provided in ead-appendix.

If the processing fails for some reason then, typically, an error message is sent, the protocol is discontinued, and the protocol state <del> erased.  Further details are provided in the following subsections </del> <ins> erased.  After having successfully processed the last message (message_3 or message_4 depending on application profile) the protocol is completed, after which no error messages are sent and EDHOC session output MAY be maintained even if error messages are received.  Further details are provided in the following subsections </ins> and in error. Different instances of the same message MUST NOT be processed in one

If EAD_1 is present then make it available to the application for EAD processing. <del> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </del> <ins> If any processing step fails, then the Responder MUST send an EDHOC error message back as defined in error, and the protocol MUST be </ins> discontinued. 5.3.

asym-msg2-proc.  Make the result of the verification available to the application. <del> If any processing step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </del> <ins> If any processing step fails, then the Initiator MUST send an EDHOC error message back as defined in error, and the protocol MUST be </ins> discontinued. 5.4.

see exporter, persistently store the keying material, and send protected application data. <del> If any processing step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </del> <ins> If any processing step fails, then the Responder MUST send an EDHOC error message back as defined in error, and the protocol MUST be </ins> discontinued. 5.5.

Make (if present) EAD_4 available to the application for EAD processing. <del> If any processing step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in error, and the session MUST be </del> <ins> If any processing step fails, then the Initiator MUST send an EDHOC error message back as defined in error, and the protocol MUST be </ins> discontinued. After verifying message_4, the Initiator is assured that the

RFC8613) typically only breaks the security of the data in the forged packet. <del> As the EDHOC protocol is terminated when verification fails, the </del> <ins> As the EDHOC protocol is discontinued when verification fails, the </ins> security against online attacks is given by the sum of the strength of the verified signatures and MACs (including MAC in AEAD).  As an example, if EDHOC is used with method 3, cipher suite 2, and

An attacker can also send faked message_2, message_3, message_4, or error in an attempt to trick the receiving party to send an error <del> message and discontinue the session.  EDHOC implementations MAY </del> <ins> message and discontinue the protocol.  EDHOC implementations MAY </ins> evaluate if a received message is likely to have been forged by an attacker and ignore it without sending an error message or <del> discontinuing the session. </del> <ins> discontinuing the protocol. </ins> 8.8.

short identifiers.  If the wrong connection identifier of the other party is used in a protocol message it will result in the receiving party not being able to retrieve a security context (which will <del> terminate the protocol) or retrieve the wrong security context (which also terminates the protocol as the message cannot be verified). </del> <ins> discontinue the protocol) or retrieve the wrong security context (which also discontinues the protocol as the message cannot be verified). </ins> If two nodes unintentionally initiate two simultaneous EDHOC message exchanges with each other even if they only want to complete a single <del> EDHOC message exchange, they MAY terminate the exchange with the </del> <ins> EDHOC message exchange, they MAY discontinue the exchange with the </ins> lexicographically smallest G_X.  Note that in cases where several EDHOC exchanges with different parameter sets (method, COSE headers, etc.) are used, an attacker can affect which parameter set will be

not make use of a so called running hash.  This is a design choice as running hashes are often not supported on constrained platforms. <del> When parsing a received EDHOC message, implementations MUST terminate the protocol if the message does not comply with the CDDL for that message.  It is RECOMMENDED to terminate the protocol if the received EDHOC message is not deterministic CBOR. </del> <ins> When parsing a received EDHOC message, implementations MUST discontinue the protocol if the message does not comply with the CDDL for that message.  It is RECOMMENDED to discontinue the protocol if the received EDHOC message is not deterministic CBOR. </ins> 9.