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>  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>  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>  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>  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>  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>  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>  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>  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>  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>  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>  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>  9.

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

If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process,  <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  <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.  <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.  <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.  <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.  <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.  <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  <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  <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  <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  <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.  <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.


ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R. <del> The value of a COSE 'kid' parameter is a CBOR byte string.  For a more compact encoding, the CBOR map is replaced by a byte string, see the definitions of plaintext in asym-msg2-proc and asym-msg3-proc. To allow one-byte encodings of ID_CRED_x with key identifiers 'kid', the same representation used for EDHOC connection identifiers defined in bstr-repr MUST be applied. Examples: The CBOR map { 4 : h'FF' } is not encoded as 0xA10441FF but as the CBOR byte string h'FF', i.e., 0x41FF. The CBOR map { 4 : h'21' } is neither encoded as 0xA1044121, nor as the CBOR byte string h'21', i.e., 0x4121, but as the CBOR integer 0x21. </del> As stated in Section 3.1 of RFC9052, applications MUST NOT assume that 'kid' values are unique and several keys associated with a 'kid' may need to be checked before the correct one is found.  Applications See COSE for more examples.  3.6. An EDHOC cipher suite consists of an ordered set of algorithms from ? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e., <del> ID_CRED_R = { 4 : kid_R }, then only the byte string is included in the plaintext, represented as described in bstr- repr, see examples in id_cred. </del>  Compute KEYSTREAM_2 as in expand, where plaintext_length is the length of PLAINTEXT_2.  For the case of plaintext_length ? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e., <del> ID_CRED_I = { 4 : kid_I }, then only the byte string is included in the plaintext, represented as described in bstr- repr, see examples in id_cred. </del>  CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.

Clarification of the optimization of ID_CRED for 'kid',
Merging to include in -18
In , there is I would have expected this to be as per or have I missed something? There is a degree of ambiguity in ` is this refers to the byte string, not necessarily the subset integer equivalent, but the lake-traces would still appear to be wrong.
NAME That looks like a bug. As you can see further down in the same section: ( ? PAD2, IDCREDR / bstr / -24..23, SignatureorMAC2, ? EAD2 ) 32 48 d0 d1 a5 94 79 7d 0a af which is IDCREDR followed by 9 bytes CBOR encoding of SignatureorMAC2. We should also clarify to avoid the ambiguity. Thanks!
I removed the label so we don't forget to also clarify in the spec.
I was too quick making a change in -traces which I had to revert. The implementation is right (of course). So I made a clarification in -edhoc instead, see . Please review.
NAME PR is now merged. Let us know if you have any further comments.
Thanks for the update. When I have some spare time, I am doing a libcoap port. I have now got as far as doing Message_2 as per the traces.
Cool, keep us updated on the progress and if you are interested in interop-testing. Closing this issue then.

ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R.  As stated in Section 3.1 of RFC9052, applications MUST NOT assume that 'kid' values are unique and several keys associated with a 'kid' may need to be checked before the correct one is found.  Applications See COSE for more examples. <ins> 3.5.3.1. To comply with the LAKE message size requirements, see I-D.ietf-lake- reqs, two optimizations are made for the case when ID_CRED_x contains a single 'kid' parameter. The CBOR map { 4 : kid_x } is replaced by the byte string kid_x. The representation of identifiers specified in bstr-repr is applied to kid_x. These optimizations MUST be applied if and only if ID_CRED_x = { 4 : kid_x } and ID_CRED_x in PLAINTEXT_y of message_y, y = 2 or 3, see asym-msg2-proc and asym-msg3-proc.  Note that these optimizations are not applied to instances of ID_CRED_x which have no impact on message size, e.g., context_y, or the COSE protected header. For ID_CRED_x = { 4 : h'FF' }, the encoding in PLAINTEXT_y is not the CBOR map 0xA10441FF but the CBOR byte string h'FF', i.e., 0x41FF. For ID_CRED_x = { 4 : h'21' }, the encoding in PLAINTEXT_y is neither the CBOR map 0xA1044121, nor the CBOR byte string h'21', i.e., 0x4121, but the CBOR integer 0x21. </ins> 3.6. An EDHOC cipher suite consists of an ordered set of algorithms from ? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e.,  <ins> ID_CRED_R = { 4 : kid_R }, then the compact encoding is applied, see compact-kid. </ins> Compute KEYSTREAM_2 as in expand, where plaintext_length is the length of PLAINTEXT_2.  For the case of plaintext_length ? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e.,  <ins> ID_CRED_I = { 4 : kid_I }, then the compact encoding is applied, see compact-kid. </ins> CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.


With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol. <del> Earlier versions of EDHOC have been formally analyzed Jacomme23 Norrman20 Bruni18 and the specification has been updated based on the analysis. </del>  8.2.

Adding two further analyses that contributed to EDHOC (): Cottier, Pointcheval: "Security Analysis of the EDHOC protocol". Sep 2022. URL Günther, Ilunga: "Careful with MAc-then-SIGn: A Computational Analysis of the EDHOC Lightweight Authenticated Key Exchange Protocol". Dec 2022. URL
Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? URL
Seems like a good idea to me
Related to
This was discussed on the IETF 116 LAKE WG meeting, and in absence of volunteers to draft such an appendix we decided to start with adding references. We may want to go somewhere in between a whole appendix and a sentence, and expand with a paragraph about each reference. We still need someone to draft that paragraph for the different references and would like to conclude on this fairly soon. We start by merging now.
Closing since is merged. Hi all, While we do not have any explicit comments on the document, we thought it is maybe still worthwhile to share the following analysis confirmation. We updated our computational analysis of the SIG-SIG mode, of which Marc presented an earlier version at IETF 114, to draft 17. We could confirm that with some of the later cryptographic suggestions (PR , ) included, EDHOC SIG-SIG achieves key exchange security (key secrecy and explicit authentication) in a strong model capturing potentially colliding credential identifiers, assuming, among others, an "exclusive ownership" property of the signature scheme (established for Ed25519, conjectured for the way ECDSA is used in EDHOC SIG-SIG). Our updated analysis is not publicly available yet at this point. Let us know if a public reference would be helpful for the draft RFC; we can also share the document individually upon request. The last point actually maybe does lead to a comment on the document: Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? Kind regards, Felix Günther (with Marc Ilunga)

With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol.  <ins> Earlier versions of EDHOC have been formally analyzed Bruni18 Norrman20 CottierPointcheval22 Jacomme23 GuentherIlunga22 and the specification has been updated based on the analysis. </ins> 8.2.


5.2.3. <del> The Responder SHALL process message_1 as follows: </del>  Decode message_1 (see CBOR). <del> Verify that the selected cipher suite is supported and that no prior cipher suite in SUITES_I is supported. </del>  <del> If EAD_1 is present then make it available to the application for EAD processing. </del>  If any processing step fails, then the Responder MUST send an EDHOC error message back as defined in error, and the protocol MUST be 5.3.3. <del> The Initiator SHALL process message_2 as follows: </del>  Decode message_2 (see CBOR). Decrypt CIPHERTEXT_2, see asym-msg2-proc. <del> Make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing. </del>  Obtain the authentication credential (CRED_R) and the authentication key of R from the application (or by other means). 5.4.3. <del> The Responder SHALL process message_3 as follows: </del>  Decode message_3 (see CBOR). and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined in asym-msg3-proc. <del> Make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing. </del>  Obtain the authentication credential (CRED_I) and the authentication key of I from the application (or by other means).

This PR is the same as , but rebased on the current master. PR consisted of 4 commits, two already merged and the two in this PR
Merging this now to have an updated master to work on for and
Make a normative statement in relevant section
Resolved with indicated commit.
From non-nits: 3.5.2, 2nd para: on what basis is rfc5280 a normative ref whilst [I-D.ietf-cose-cbor-encoded-cert] is informative? They seem to be equally required for implementation based on this text. Given [I-D.ietf-cose-x509] is normative, perhaps it wouldn't add delay if both were? I made RFC 5820 informative. 3.5.2: I forget if use of the full DER-encoded X.509 cert was discussed on the list or not? If not, the alternative would have been to use the SPKI which has some slightly different properties that can sometimes be beneficial (potentially easier use of different CAs on each side). I'm not asking for a change here btw, just to check was this discussed on the list. (I see appendix D.2 talks a bit about this.) The use of (full DER-encoded) X.509 is described and planned to be used in deployments. I think Marek mentioned that in his presentation at IETF 113. Should be known. I don't think SPKI has been discussed. Any action you propose? 5.2.3: what happens if the decode of message1 fails? (Say due to an unknown suite.) Does EAD1 get provided to the application? I hope not! Maybe the text after the bullets needs to specify this explicitly? Same for other sections wrt providing EAD to the application (esp EAD1 and EAD2). The current text says: The intent here and all other message processing is that you carry out the processing in steps and if any step fail then you don't carry out the subsequent steps. Is that clear enough? Then that would cover the case of unknown suite. But perhaps it doesn't cover other errors occuring at reception of message_1. Does the state machine make this more clear (though just an example)? Should we move some of that text here? 9.4: As the method field is how we handle breaking changes, do we really want that registry to be specification required? The alternative might be standards action, if we prefer the IESG to be involved in such changes. This has been discussed. One option is to require standards action for low method numbers. Anyone else has an opinion?
Hmm - is that the right plan? If they're all informative references that'd imply that the CRED_I/R handling code (whether x.509, cbor or whatever) wasn't really part of an edhoc implementation. Is/should one of 'em be mandatory to implement (and hence normative)?
Only action I'm proposing is checking we're ok with that as I don't recall it being discussed on the list. On the basis that it's been in the draft for >1 year and implementers haven't complained and it's been raised on the list (in my recent review), I think we're good as-is (unless someone yells). Edit [GS]: OK, I wait for further input or else done.
I'm not sure it's clear enough - esp wrt passing on EAD which can have side-effects that could be bad (e.g. if some identifier were stored even though message processing had failed for some reason). I think the EAD stuff is the only way that kind of thing might happen - if so, then maybe saying that EAD should only be passed to applications after all processing steps have succeeded might be right? Edit [GS]: Proposal in
To be clear - I'm fine with it as-is, but just wanted to check. As it's been raised on the list, people there can express their opinions as they wish so I don't see a need to specifically survey opinions further. Edit [GS]: OK, I wait for further input or else done.
Hmm - certs and RPK are quite different cases. It is not clear why mandate one if some only use the other. If something must to be mandated, I would say it is the use of CCS identified with a kid, i.e. RPK, not certs. Should we mandate this?
To be honest, I'd have to re-read the draft to be sure, but I thought raw public keys were in practice mandatory:-) If all the implementations do support those (which I guess is the case), then it'd probably be no harm to explicitly say that's mandatory to implement maybe, if that's not already there somewhere.
No credential or identification of credential is mandatory currently.
ok so I guess if they're all optional to implement then yes having them be informative references is defensible - it might come up in later reviews I guess but can be dealt with then if needed. Might be no harm if you can summarise that as the response to that comment on the list (though maybe wait a bit to see if someone else chimes in here) Edit: Mail sent to the list
The use of (full DER-encoded) X.509 has been included since -00. Actually even draft-selander-lake-edhoc-00. I think the use of 'x5t' (which is full DER-encoded X.509) has been discussed quite a lot. Full DER-encoded X.509 is also part of the test vectors and the traces document. If anybody wants SPKI in EDHOC/COSE they just need to define a COSE header parameter at a later stage.
I would personally prefer that...
PR is merged. Separate issue opened for the remaining comment. Closing this.

5.2.3.  <ins> The Responder SHALL process message_1 in the following order: </ins> Decode message_1 (see CBOR).  <ins> Process message_1, in particular verify that the selected cipher suite is supported and that no prior cipher suite in SUITES_I is supported. </ins>  <ins> If all processing completed successfully, and if EAD_1 is present, then make it available to the application for EAD processing. </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 5.3.3.  <ins> The Initiator SHALL process message_2 in the following order: </ins> Decode message_2 (see CBOR). Decrypt CIPHERTEXT_2, see asym-msg2-proc.  <ins> If all processing completed successfully, then make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing. </ins> Obtain the authentication credential (CRED_R) and the authentication key of R from the application (or by other means). 5.4.3.  <ins> The Responder SHALL process message_3 in the following order: </ins> Decode message_3 (see CBOR). and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined in asym-msg3-proc.  <ins> If all processing completed successfully, then make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing. </ins> Obtain the authentication credential (CRED_I) and the authentication key of I from the application (or by other means).


SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3 RFC9147, EDHOC authenticated with signature keys is built on a <del> variant of the SIGMA protocol which provides identity protection of the Initiator (SIGMA-I) against active attackers, and like IKEv2, EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma. </del>  The parties exchanging messages in an EDHOC session are called <del> 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. 3.1. The EDHOC protocol consists of three mandatory messages (message_1, <del> message_2, message_3) between an Initiator and a Responder, an optional fourth message (message_4), and an error message.  The roles have slightly different security properties which should be considered when the roles are assigned, see sec-prop.  All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </del>  Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the

Addresses
Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. URL
Yes, we will add that
Closing this as PR is merged. Reviewer: Christer Holmberg Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lake-edhoc-18 Reviewer: Christer Holmberg Review Date: 2022-12-20 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and easy to read. I do have one minor issue that I would like the authors to address. Major issues: N/A Minor issues: Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. Nits/editorial comments: N/A

SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3 RFC9147, EDHOC authenticated with signature keys is built on a  <ins> variant of the SIGMA protocol, SIGMA-I, which provides identity protection against active attacks on the party initiating the protocol.  Also like IKEv2, 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  <ins> Initiator (I) and Responder (R), where the Initiator sends message_1 (see overview).  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. 3.1. The EDHOC protocol consists of three mandatory messages (message_1,  <ins> message_2, message_3), an optional fourth message (message_4), and an error message, between an Initiator (I) and a Responder (R).  The odd messages are sent by I, the even by R.  Both I and R can send error messages.  The roles have slightly different security properties which should be considered when the roles are assigned, see sec-prop. All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </ins> Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the


message duplication,  fragmentation and reassembly, demultiplex EDHOC messages from other types of messages, denial-of-service protection, <del> message correlation. </del>  <del> The use of transport is specified in the application profile </del>  applicability. 3.4.1. <del> The transport needs to support the correlation between EDHOC messages and facilitate the retrieval of protocol state and security context 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 correlate EDHOC messages in a CoAP response and an associated CoAP request. Connection identifiers may be used to correlate EDHOC messages and 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. </del>  3.5. Detect that an EDHOC message has been received, for example by means of port number, URI, or media type (applicability). <del> Retrieve the protocol state according to the message correlation provided by the transport, see transport.  If there is no protocol state, in the case of message_1, a new protocol state is created. The Responder endpoint needs to make use of available Denial-of- Service mitigation (dos). </del>  If the message received is an error message, then process it according to error, else process it as the expected next message Decode message_2 (see CBOR). <del> Retrieve the protocol state using the message correlation provided by the transport (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see coap). </del>  Decrypt CIPHERTEXT_2, see asym-msg2-proc. Decode message_3 (see CBOR). <del> Retrieve the protocol state using the message correlation provided by the transport (e.g., the CoAP Token, the 5-tuple, or the prepended C_R, see coap). </del>  Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected Decode message_4 (see CBOR). <del> Retrieve the protocol state using the message correlation provided by the transport (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see coap). </del>  Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected

Addressing
Opening a PR with one commit as placeholder, more updates to follow.
I tried to clarify normative text in Appendix A, which led to a refactoring of section A.2. Please comment on if this is going in the right direction.
Editor's note: Remains to write about flow control.
NAME NAME NAME Are you happy with the latest changes? (Plan to merge soon)
Looks good to me, thanks!
NAME provided some comments based on PR . The specification was already before quite open for various means to provide correlation. This may lead to interoperability problems even in the case of using EDHOC over CoAP (it did in one of the recent interop tests, where one party was not using prepended identifiers). If we are now reworking this text we should try to fix this. Correlation may be provided without the use of transport (which was the reason why prepended identifiers was not used). This should be mentioned. So on the one hand, the specification is limiting the description to the case when transport provides correlation, on the other hand is it a bit loose on how to achieve correlation even over CoAP, leading to interoperability problems. It is proposed to use a formulation like "Unless correlation is provided by other means" then SHOULD use . The only candidate for well-defined way is prepended identifiers. Formulations like this: “Prepended identifiers MAY be omitted in case the transport provides such correlation.” should be omitted since it could be a problem in case of proxying between TCP and UDP. Text referring to “the integer representation” should be rephrased, since it is a representation of identifiers which sometimes may be represented as integers. A sanity check of the processing steps in the new forward / reverse message flow sections showed one missing case when error message can be sent. When working with the changes I realized some other quirks: Throughout the draft, references about correlation are made to appendix A.2 (EDHOC over CoAP) instead of section 3.4.1 which contains the general description. I think it is better to reference the section in the body (which includes a reference to the appendix) Section 3.4.1 is not only about connection identifiers so the title is misleading. Change from "Use of Connection Identifiers for EDHOC Message Correlation" to "EDHOC Message Correlation" After making these updates, the text in Appendix H becomes essentially redundant and can be removed and the remnants distributed over 3.4.1 and A.2.
A proposal included in PR : 1c4ebe7f
Closing this as is merged.
URL Nits in Section 3.4: The wording "In addition to the transport of messages including errors" does not explain whether (bit) errors in messages need to be handled in the underlying transport. If the protocol assumes error-free transport of messages, a better wording would be "In addition to reliable transport of messages without errors", or the like. "Flow control" is not listed as requirement in Section 3.4. That could be a bug or a feature. Yet, as the protocol targets devices with low memory that may run out of buffer space, it may make sense to be explicit whether flow control is needed to deal with scarce memory. If not, it would make sense to explain how an implementation running out of send/receive buffer space would deal with that. While the document stresses in various places that the message sizes are small, and example values are also included, neither a required minimum nor a worst-case maximum is mentioned. As the underlying transport has to support fragmentation, a definition may not be required. Yet, if min/max numbers can be derived, it could be useful to better explain them in Section 3.4 in order to illustrate the requirements on the underlying transport. If min/max numbers cannot be derived, a corresponding heads-up could be added instead to emphasize that the transport protocol needs to support arbitrarily large messages. Nits in Appendix A: It is not fully clear whether the content of Appendix A, or subsets thereof, are normative requirements for an implementation. This in particular applies to the RFC2119/RFC8174 language. The relationship between Appendix A and draft-ietf-core-oscore-edhoc is quite hard to understand.
error-free. EDHOC does not require error free. EDHOC will detect errors but it might be detected later in the message flow. We will add some considerations.We will think about what to write about flow controlA min number can be derived. We will add min numbers and some considerations on large messages.We agree with the Nits. We will improve this. Reviewer: Michael Scharf Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This document basically specifies an application protocol that is by-and-large independent of an underlying reliable transport protocol. As such, there are no apparent transport issues in the protocol design itself. Transport protocol issues are in particular discussed in Section 3.4 and Appendix A. In both there are some small nits. Nits in Section 3.4: The wording "In addition to the transport of messages including errors" does not explain whether (bit) errors in messages need to be handled in the underlying transport. If the protocol assumes error-free transport of messages, a better wording would be "In addition to reliable transport of messages without errors", or the like. "Flow control" is not listed as requirement in Section 3.4. That could be a bug or a feature. Yet, as the protocol targets devices with low memory that may run out of buffer space, it may make sense to be explicit whether flow control is needed to deal with scarce memory. If not, it would make sense to explain how an implementation running out of send/receive buffer space would deal with that. While the document stresses in various places that the message sizes are small, and example values are also included, neither a required minimum nor a worst-case maximum is mentioned. As the underlying transport has to support fragmentation, a definition may not be required. Yet, if min/max numbers can be derived, it could be useful to better explain them in Section 3.4 in order to illustrate the requirements on the underlying transport. If min/max numbers cannot be derived, a corresponding heads-up could be added instead to emphasize that the transport protocol needs to support arbitrarily large messages. Nits in Appendix A: It is not fully clear whether the content of Appendix A, or subsets thereof, are normative requirements for an implementation. This in particular applies to the RFC2119/RFC8174 language. The relationship between Appendix A and draft-ietf-core-oscore-edhoc is quite hard to understand.

message duplication, <ins> flow control, </ins> fragmentation and reassembly, demultiplex EDHOC messages from other types of messages, denial-of-service protection,  <ins> message correlation, see ci-edhoc. EDHOC does not require error free transport since a change in message content is detected through the transcript hashes in a subsequent integrity verification, see asym. EDHOC is designed to enable an authenticated key exchange with small messages, where the minimum message sizes are of the order illustrated in the first column of fig-sizes.  There is no maximum message size specified by the protocol; this is for example dependent on the size of authentication credentials (if they are transported, see auth-key-id). </ins>  <ins> The use of transport is specified in the application profile, which in particular may specify limitations in message sizes, see </ins> applicability. 3.4.1.  <ins> Correlation between EDHOC messages is needed to facilitate the retrieval of protocol state and security context during an EDHOC session.  It is also helpful for the Responder to get an indication that a received EDHOC message is the beginning of a new session, such that no existing protocol state or security context needs to be retrieved. Correlation may be based on existing mechanisms in the transport protocol, for example, the CoAP Token may be used to correlate EDHOC messages in a CoAP response and in an associated CoAP request.  The connection identifiers may also be used to correlate EDHOC messages. If correlation between consecutive messages is not provided by other means then the transport binding SHOULD mandate prepending of an appropriate connection identifier (when available from the EDHOC protocol) to the EDHOC message.  If message_1 indication is not provided by other means, then the transport binding SHOULD mandate prepending of message_1 with the CBOR simple value "true" (0xf5), as a unique dummy identifier. Transport of EDHOC in CoAP payloads is described in coap, including how to use connection identifiers and message_1 indication with CoAP. A similar construction is possible for other client-server protocols. Protocols that do not provide any correlation at all can prescribe prepending of the peer's connection identifier to all messages. Note that correlation between EDHOC messages may be obtained without transport support or connection identifiers, for example if the endpoints only accept a single instance of the protocol at a time, and execute conditionally on a correct sequence of messages. </ins> 3.5. Detect that an EDHOC message has been received, for example by means of port number, URI, or media type (applicability).  <ins> Retrieve the protocol state according to the message correlation, see ci-edhoc.  If there is no protocol state, in the case of message_1, a new protocol state is created.  The Responder endpoint needs to make use of available Denial-of-Service mitigation (dos). </ins> If the message received is an error message, then process it according to error, else process it as the expected next message Decode message_2 (see CBOR).  <ins> Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see ci- edhoc). </ins> Decrypt CIPHERTEXT_2, see asym-msg2-proc. Decode message_3 (see CBOR).  <ins> Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or the prepended C_R, see ci- edhoc). </ins> Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected Decode message_4 (see CBOR).  <ins> Retrieve the protocol state using available message correlation (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see ci- edhoc). </ins> Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected


and cipher suite negotiation.  Authentication can be based on raw public keys (RPK) or public key certificates and requires the application to provide input on how to verify that endpoints are <del> trusted.  This specification emphasizes the possibility of referencing rather than to transport credentials in order to reduce message overhead, but the latter is also supported.  EDHOC does not currently support pre-shared key (PSK) authentication as authentication with static Diffie-Hellman public keys by reference produces equally small message sizes but with much simpler key distribution and identity protection. EDHOC makes use of known protocol constructions, such as SIGMA SIGMA and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and identification of credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set (CCS), X.509, and CBOR encoded X.509 (C509) certificates, see auth-cred).  COSE provides crypto agility and enables the use of future algorithms and credential types targeting IoT. </del>  EDHOC is designed for highly constrained settings making it especially suitable for low-power networks RFC8376 such as Cellular 2. <del> EDHOC specifies different authentication methods of the ephemeral Diffie-Hellman key exchange: signature keys and static Diffie-Hellman keys.  This section outlines the signature key based method.  Further details of protocol elements and other authentication methods are provided in the remainder of this document. </del>  SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3 variant of the SIGMA protocol, SIGMA-I, which provides identity protection against active attacks on the party initiating the protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign <del> variant of the SIGMA-I protocol shown in fig-sigma. </del>  The parties exchanging messages in an EDHOC session are called Initiator (I) and Responder (R), where the Initiator sends message_1 using a static Diffie-Hellman key the authentication is provided by a Message Authentication Code (MAC) computed from an ephemeral-static ECDH shared secret which enables significant reductions in message <del> sizes. </del>  The Initiator and the Responder need to have agreed on a single method to be used for EDHOC, see applicability. 8.1. <del> EDHOC inherits its security properties from the theoretical SIGMA-I protocol SIGMA.  Using the terminology from SIGMA, EDHOC provides forward secrecy, mutual authentication with aliveness, consistency, and peer awareness.  As described in SIGMA, message_3 provides peer awareness to the Responder while message_4 provides peer awareness to the Initiator.  By including the authentication credentials in the </del>  transcript hash, EDHOC protects against Duplicate Signature Key Selection (DSKS)-like identity mis-binding attack that the MAC-then- Sign variant of SIGMA-I is otherwise vulnerable to.

Merging this as no new comments appeared.
From: Radia Perlman Date: Tuesday, 24 January 2023 at 03:49 To: EMAIL , The IESG , EMAIL Subject: Secdir review of draft-ietf-lake-edhoc-18 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. There are a family of "lightweight" protocols designed for us in "constrained" environments (think IoT) that replace other IETF protocols that would be otherwise be used. The constraints may include lack of CPU power, lack of bandwidth, lack of non-volatile memory, and running over a non-IP network. EDHOC (Ephemeral Diffie-Hellman over COSE) specifies a protocol for establishing session keys for use with OSCORE that specifies how to cryptographically protect a session. So you can think of EDHOC as corresponding to IKE while OSCORE corresponds to ESP, or you can think of the pair EDHOC/OSCORE as corresponding to TLS. As you would expect, the protocol is functionally quite similar to both TLS and IKE, and the interesting security discussions would be around the justifications for the differences. The name EDHOC is misleading, since EDHOC supports four authentication variants, only one of which is Ephemeral Diffie-Hellman. The other three are where one of both endpoints use a static Diffie-Hellman key. TLS 1.3 decided to abandon all such variants because they do not provide forward secrecy, but I suppose it reasonable to revisit that decision in the context of a constrained environment. But I can think of no justification for the misleading name. The working group name (Lightweight Authenticated Key Exchange - LAKE) would be a more accurately descriptive name. The authors may be confused about the definition of forward secrecy, since in Security Considerations they say this protocol provides forward secrecy and in Appendix J they refer to a key refresh technique that has some nice security properties but does not provide what is generally regarded as forward secrecy. Other differences: They simplify the protocol compared to TLS by not including the variations allowing restart of a security context based on cached information. While this makes the code to implement the protocol simpler, it hurts performance. The negotiation of cryptographic algorithms is based on suites (as early versions of TLS did) rather than a more ala carte approach that TLS has evolved towards. Further, while TLS has a system of initiator proposes and responder chooses cryptographic algorithms, in EDHOC's system the responder is constrained to choose the most preferred of the initiator's suites that it supports. Further, the initiator must guess the suite the responder will choose and the protocol may be very "chatty" the first time the protocol is run (or every time if the initiator does not cache the preferred suite of the responder). There would be an extra pair of messages for each suite the initiator prefers over the first one the responder accepts. Whether authentication is going to be based on Ephemeral or Static Diffie-Hellman keys is not negotiated. The initiator is expected to know (or the protocol gets more chatty). Finally, rather than negotiating a symmetric encryption algorithm for use within EDHOC itself, EDHOC generates an extended PRF output which it XORs into messages to encrypt them. In practice, this strikes me as a clever hack to greatly simpify the specification while not substantially hurting performance. But others may disagree. There was a reference to an analysis of the security of the protocol (which is based on SIGMA). I didn't read it, but the design of the protocol looks sound to me. Nits: From Section 1.1: "This specification emphasizes the possibility to reference rather than to transport credentials in order to reduce message overhead, but the latter is also supported." -> "This specification supports the referencing of credentials in order to reduce message overhead, but credentials may alternatively be embedded." In Section 3.9: "incompliance" -> "non-compliance" Radia
Addressed in
Comment from Loïc: I am wondering if the computational independence of the intermediary secret keys has been discussed. I looked among the different issues on the Github repository but did not find any reference to that point. Indeed in his on SIGMA, Krawczyk stresses that the (intermediary) authentication keys, encryption keys and the session key must be computationally independent: (§5.1, p. 17) “It is essential for the protocol security that the keys Km [MAC key] and Ks [session key] be “computationally independent” (namely no information on Ks can be learned from Km and vice-versa).” (§5.2, p. 19) “Ke [intermediary encryption key] must be computationally independent from the authentication key Km and the session key Ks” It happens that this is not always true in EDHOC depending on the authentication mode. The most demonstrative example is with the Sig-Sig mode. PRK2e is used to compute the authentication tag MAC2. If this key is disclosed, all the intermediary secret parameters (tags, keys, IVs) and the session key PRKout can be computed. Using a static DH key to authenticate adds more independence. For example, with the Sig-Stat mode, the disclosure of PRK4e3m = PRK3e2m used to compute MAC3 does not allow computing the session key PRKout unless TH4 = H(TH3, PLAINTEXT3, CREDI) is revealed (and PLAINTEXT3, IDCREDI are encrypted, as well as PLAINTEXT2, IDCREDR where TH3 = H(TH2, PLAINTEXT3, CREDR)). In addition, this shows that the computational independence does not rely only on the function used to compute the intermediary keys but also on the encryption schemes used to protect PLAINTEXT2, IDCREDR and PLAINTEXT3, IDCRED_I. So I wanted to know if this has already been discussed (and possibly discarded since one way to leverage this lack of independence is to get one these intermediary keys, which may not be trivial in practice).
This issue was discussed and actually concluded in an email exchange before Christmas but we forgot to update the issue. The conditions on SIGMA listed in this issue does not apply to EDHOC. This is one example of a difference with SIGMA. The security analysis papers of EDHOC listed in Section 8.1 show that the relevant security properties still apply. The clarifications of security properties in PR cover also this issue.
Closing this, as is merged.

and cipher suite negotiation.  Authentication can be based on raw public keys (RPK) or public key certificates and requires the application to provide input on how to verify that endpoints are  <ins> trusted.  This specification supports the referencing of credentials in order to reduce message overhead, but credentials may alternatively be embedded in the messages.  EDHOC does not currently support pre-shared key (PSK) authentication as authentication with static Diffie-Hellman public keys by reference produces equally small message sizes but with much simpler key distribution and identity protection. EDHOC makes use of known protocol constructions, such as SIGMA SIGMA, the Noise XX pattern Noise, and Extract-and-Expand RFC5869.  EDHOC uses COSE for cryptography and identification of credentials (including COSE_Key, CBOR Web Token (CWT), CWT Claims Set (CCS), X.509, and CBOR encoded X.509 (C509) certificates, see auth-cred). COSE provides crypto agility and enables the use of future algorithms and credential types targeting IoT. </ins> EDHOC is designed for highly constrained settings making it especially suitable for low-power networks RFC8376 such as Cellular 2.  <ins> EDHOC specifies different authentication methods of the ephemeral- ephemeral Diffie-Hellman key exchange: signature keys and static Diffie-Hellman keys.  This section outlines the signature key based method.  Further details of protocol elements and other authentication methods are provided in the remainder of this document. </ins> SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3 variant of the SIGMA protocol, SIGMA-I, which provides identity protection against active attacks on the party initiating the protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign  <ins> variant of the SIGMA-I protocol.  The message flow (excluding an optional fourth message) is shown in fig-sigma. </ins> The parties exchanging messages in an EDHOC session are called Initiator (I) and Responder (R), where the Initiator sends message_1 using a static Diffie-Hellman key the authentication is provided by a Message Authentication Code (MAC) computed from an ephemeral-static ECDH shared secret which enables significant reductions in message  <ins> sizes.  Note that also in the static Diffie-Hellman based authentication methods there is an ephemeral-ephemeral Diffie-Hellman key exchange. </ins> The Initiator and the Responder need to have agreed on a single method to be used for EDHOC, see applicability. 8.1.  <ins> EDHOC has similar security properties as can be expected from the theoretical SIGMA-I protocol SIGMA and the Noise XX pattern Noise, which are similar to methods 0 and 3, respectively.  Proven security properties are detailed in the security analysis publications referenced at the end of this section. Using the terminology from SIGMA, EDHOC provides forward secrecy, mutual authentication with aliveness, consistency, and peer awareness.  As described in SIGMA, message_3 provides peer awareness to the Responder while message_4 provides peer awareness to the Initiator.  By including the authentication credentials in the </ins> transcript hash, EDHOC protects against Duplicate Signature Key Selection (DSKS)-like identity mis-binding attack that the MAC-then- Sign variant of SIGMA-I is otherwise vulnerable to.


of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. <del> As noted in Section 12 of RFC9052 the use of a single key for multiple algorithms is strongly discouraged unless proven secure by a dedicated cryptographic analysis.  In particular this recommendation applies to using the same private key for static Diffie-Hellman authentication and digital signature authentication.  A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of secure shared signature and ECDH key usage in Degabriele11 and Thormarker21. </del>  The property that a completed EDHOC exchange implies that another identity has been active is upheld as long as the Initiator does not

using the same key for Initiator and Responder
The document need to say something about this. It seems very uncontroversial to state that it MAY be used for both. I think this can be merged and the issue closed.
Proposal: OLD "The same authentication key MAY be used for both the Initiator and Responder roles." NEW "The same authentication credential MAY be used for both the Initiator and Responder roles."

of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done.  <ins> The same authentication credential MAY be used for both the Initiator and Responder roles.  As noted in Section 12 of RFC9052 the use of a single key for multiple algorithms is strongly discouraged unless proven secure by a dedicated cryptographic analysis.  In particular this recommendation applies to using the same private key for static Diffie-Hellman authentication and digital signature authentication. A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of secure shared signature and ECDH key usage in Degabriele11 and Thormarker21. </ins> The property that a completed EDHOC exchange implies that another identity has been active is upheld as long as the Initiator does not