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

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

Section 3.3.1: s/communications/communication Section 3.7: s/COSE always use/COSE always uses Section 3.8: s/need to register/needs to register Section 6: s/Errors messages in EDHOC/Error messages in EDHOC Section 8.2: s/EHDOC/EDHOC That would be it, congrats to the author team for getting the specification to this shape. Finally, apologies for sending this review a morning after the deadline! Mališa

One point I would like to discuss is whether it would be useful to specify a protocol state machine in >this draft. Different steps related to message and error processing are scattered throughout the >Section 5, but it would be very useful from the implementor’s point of view to have the valid states >summarized and illustrated through a figure. I guess something similar to Appendix A of RFC 8446 >would be nice. This was discussed before and decided to not do as EDHOC does not really have the kind of states that TLS 1.3 does. I don't think RFC 8446 is a good example. Not against making a figure but the figure would likely be quite simple and trivial, but maybe that is good to show.
NAME I agree that the TLS 1.3 state machine is much more complex but I think it'd still be good to have this common for the implementations, in order for them not to have to reinvent it themselves. There is at least the negotiation step which makes it not straightforward (in a literal sense). Let's discuss at IETF 115.
Discussion at IETF 115 (URL): MV: I volunteer to provide a first sketch of state machine for an appendix. DN: Maybe too optimistic. If the state machine in the figure is not perfectly aligned with the specification, this will create problem. GS: Can we give it a try with a sketch in an appendix, before deciding to keep it or not? SF: Yes, and we can have a quick check on the mailing list about keeping it.
Clarified in (in 1cec57b)
I think those are fixed but please check.
Some of the comments are already fixed in other updates, the remaining should be in .

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

Section 3.3.1: s/communications/communication Section 3.7: s/COSE always use/COSE always uses Section 3.8: s/need to register/needs to register Section 6: s/Errors messages in EDHOC/Error messages in EDHOC Section 8.2: s/EHDOC/EDHOC That would be it, congrats to the author team for getting the specification to this shape. Finally, apologies for sending this review a morning after the deadline! Mališa