jiebi/CodeConvo huggingface dataset:
Change:
Looks good. One inconsistency is that there is no cipher suite with AES-GCM and NIST curves, like (A128GCM, SHA-256, P-256, ES256, A128GCM, SHA-256). This could be a new cipher suite 5. Then all non-CNSA suites would come in pairs.
That is very intentional. The GCM cipher suite uses X25519 for key exchange and ECDSA for authentication. This seems to be the dominant choice for HTTPS on the Web. Unless you are constrained you typically use X25519 for key exchange for speed and ECDSA for authentication as that is what the CAs support. For an IoT device you probably want to have a single curve implemented. Also it might be much easier to switch to EdDSA as you might not have to rely on Global CAs and all other HTTPS nodes to support EdDSA. You can just deploy you own CWT server and make sure the nodes in you new IoT deployment support EdDSA. I have not heard any IoT people very interested in GCM. People seems far more interested in ChaCha20.
Ready to merge?
Is it worth having 4 diiference CCM based ciphser suites. And are they the correct 4?EDHOC should probably have a ChaCha20-Poly1305 cipher suite from start. Probably with SHA-256. X25519 and EdDSA.The CNSA cipher suite does not really need a 1 byte value. Could live with 2 byte value.
-Agreement during interim is that the 4 different CCM are all needed and that they are the correct ones. -ChaCha20 should be combined with both P-256 and X25519 -CNSA suite can have two bytes.
I think we should specify a X448/SHAKE256 suite to complement the CNSA suite.
The GCM suite is chosen to match what is currently used on the web which is X25519 combined with P-256 ECDSA. Not sure we need to specify anything else here. IoT community seems more interested in ChaCha20 than GCM. ~~
URL
Resolved with .

Discussion:
suites can be identified with any of the four values -24, -23, -22, -21. <del> The following cipher suites are for constrained IoT where message overhead is a very important factor: The following cipher suite is for general non-constrained applications.  It uses very high performance algorithms that also are widely supported: The following cipher suite is for high security application such as government use and financial applications.  It is compatible with the CNSA suite CNSA. </del> <ins> The following CCM cipher suites are for constrained IoT where message overhead is a very important factor.  Cipher suites 1 and 3 use a larger tag length (128-bit) in the EDHOC AEAD algorithm than the Application AEAD algorithm (64-bit): The following ChaCha20 cipher suites are for less constrained applications and only use 128-bit tag lengths. The following GCM cipher suite is for general non-constrained applications.  It uses high performance algorithms that are widely supported: The following two cipher suites are for high security application such as government use and financial applications.  The two cipher suites do not share any algorithms.  The first of the two cipher suites is compatible with the CNSA suite CNSA. </ins> The different methods use the same cipher suites, but some algorithms are not used in some methods.  The EDHOC signature algorithm is not
Change:
This simplify things. The selected cipher suite also covers more than just the aead algorithm. I think the "suite = int" definition can be removed. It does not add much in the current version. In older versions suite was a more advances construction.
The selected cipher suite covers the aead and more.
selectedsuite is always included in transcripthash and could be removed. I.e. an equally secure info would be info = ( transcript_hash : bstr, label : tstr, context : bstr, length : uint, )
Agree, we can close this.
This has been merged to master.

Discussion:
where <del> edhoc_aead_id is an int or tstr containing the algorithm identifier of the EDHOC AEAD algorithm in the selected cipher suite encoded as defined in I-D.ietf-cose-rfc8152bis-algs.  Note that a single fixed edhoc_aead_id is used in all invocations of EDHOC-KDF, including the derivation of KEYSTREAM_2 and invocations of the EDHOC-Exporter (see exporter). </del> <ins> selected_suite is an int containing the selected cipher suite. </ins> transcript_hash is a bstr set to one of the transcript hashes TH_2, TH_3, or TH_4 as defined in Sections asym-msg2-form, asym-
Change:
Suggestion base the discussion during the October interim. There was no strong opinions. This PR updates the MTI for header parameters and credential types to align with the choices made for method (none is MTI). EAD is explicitly optional to support. It is used in specific cases and requires additional mechanics for each use case.
The things that are Mandatory or optional to support or now spread out in various places.
This does not need to be a new section (like the MTI section in TLS 1.3) but it definitly needs to be clear what in the draft is mandatory to implement or not. Could be as simple as stating. Everything is mandatory Nothing is mandatory Something in between Currently is is undefined which is not good I think
I started making an MTI section inspired by RFC 8446. I think this makes things clearer. I added some editorial notes in the section that needs to be discussed.
MTI section now in place and no editor's notes left.

Discussion:
An implementation may support only a single method.  None of the methods are mandatory-to-implement. <ins> Implementations MUST support 'kid' parameters of type int.  None of the other COSE header parameters are mandatory-to-implement. An implementation may support only a single credential type (CCS, CWT, X.509, C509).  None of the credential types are mandatory-to- implement. </ins> Implementations MUST support the EDHOC-Exporter.  Implementations SHOULD support EDHOC-KeyUpdate. <del> Implementaions MAY support message_4.  Error codes 1 and 2 MUST be </del> <ins> Implementations MAY support message_4.  Error codes 1 and 2 MUST be </ins> supported. <del> Implementations MUST support 'kid' parameters of type int. Editor's note: Is any COSE header parameters (kid, kcwt, kccs, x5t, c5c, etc. ) MTI? Editor's note: Is any credential type (CCS, CWT, X.509, C509) MTI? Editor's note: Is support of EAD MTI? </del> <ins> Implementations MAY support EAD. </ins> For many constrained IoT devices it is problematic to support more than one cipher suite.  Existing devices can be expected to support
Change:
IAB has started a program to look into updates of the Internet Threat Model. Looks like the outcome might be a guidance document. One new threat is centralised data collection where the other endpoint might not be acting in the interest of the users. URL URL There is not reason to change the protocol, but I think it would be good with some privacy considerations. Using the same credentail with several other endpoints enables tracking. I will make a PR soon with a reference to draft-arkko-arch-internet-threat-model-guidance
This has been merged for a while without any comments. Was discussed at the interim. Closing.
Looks good, I made some editorials.

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

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

Discussion:
This section defines Extract, Expand and other key derivation functions based on these: Expand is used to define EDHOC-KDF and in turn EDHOC-Exporter, whereas Extract is used to define EDHOC- <del> KeyUpdate. </del> <ins> KeyUpdate.  In EDHOC a specific message always use the same key, but how the key is derived depends on the method.  A diagram of the EDHOC key schedule can be found in Figure 2 of Vucinic22. </ins> 4.1.
Change:
Good to describe that the known attack on Sigma is that the attacker create a new message_1, no attack is known where an active attacker modifies the ongoing connection (even if the lack of such attacks is likely not proven).
This seems ready to merge
Current draft says: "EDHOC protects the credential identifier of the Initiator against active attacks and the credential identifier of the Responder against passive attacks." Should probably point out that active attack would be a new message1 to the lower layer address as the other message1.

Discussion:
As described in SIGMA, different levels of identity protection are provided to the Initiator and the Responder.  EDHOC protects the credential identifier of the Initiator against active attacks and the <del> credential identifier of the Responder against passive attacks.  The roles should be assigned to protect the most sensitive identity/ identifier, typically that which is not possible to infer from routing information in the lower layers. </del> <ins> credential identifier of the Responder against passive attacks.  An active attacker can get the credential identifier of the Responder by eavesdropping on the destination address used for transporting message_1 and send its own message_1 to the same address.  The roles should be assigned to protect the most sensitive identity/identifier, typically that which is not possible to infer from routing information in the lower layers. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as
Change:
Some additional text on connection id privacy New connections identifiers needs to be unpredictable to provide improved privacy QUIC requirement to not use the same identifier in a connection seems like nonsense that lowers privacy compared to random selection and increases implementation complexity. Christian Amsuss pointed out in a discussion in CORE that connection id privacy often does not make sense in many deployments as there are fixed identifier in lower layers
LGTM
If connection identifiers are predictable (e.g., a sequence) they might be used by an attacker to determine that the two EDHOC sessions came from the same device. We should add a sentence on this. In practice it does not matter unless IP address, MAC address, etc are randomized as well.
Isn´t it covered by sec 8.5?: Essentially, any of the additional data (EADs and CI/CR) can be used to attack privacy, whether anonymity or unlinkability. A side remark is that even with padding, if any of the EADs is a counter, the length of messagex can allow to distinguish high intensity traffic vs low intensity traffic.
Yes, it does. The text is more general then I thought. Should probablt have some guidance on non-predictable connection identifiers. If a device is using a sequence like 0x3489f2, 0x3489f3, 0x3489f4, 0x3489f5 updating the connection identifier is quite useless.

Discussion:
identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non- <del> constrained example of such mechanisms. </del> <ins> constrained example of such mechanisms.  Connection identifiers SHOULD be unpredictable.  Using the same identifier several times is not a problem as long as it is chosen randomly.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </ins> 8.6.
Change:
There are now two different media types defined. Padding was missing from the list that EDHOC adds.

Discussion:
Verification of the selected cipher suite. <del> Method types and error handling. </del> <ins> Method types, error handling, and padding. </ins> Selection of connection identifiers C_I and C_R which may be used in EDHOC to identify protocol state.

Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the application can make use of the established connection identifiers <del> C_I and C_R (see ci).  EDHOC may be used with the media type application/edhoc+cbor-seq defined in media-type. </del> <ins> C_I and C_R (see ci).  Media types that may be used for EDHOC are defined in media-type. </ins> The Initiator can derive symmetric application keys after creating EDHOC message_3, see exporter.  Protected application data can
Change:
The current text just says that: "The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information. This also applies for encrypted data sent to an unauthenticated party. In particular, it applies to EAD1, IDCREDR, EAD2, and error messages. " The eadvalue is expected to sometimes/often be encrypted outside of EDHOC. The text should be augmented with text that eadlabel leaks information even if ead_value is encrypted outside of EDHOC.

Discussion:
applies for encrypted data sent to an unauthenticated party.  In particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error messages.  Using the same EAD_1 in several EDHOC sessions allows <del> passive eavesdroppers to correlate the different sessions.  Another consideration is that the list of supported cipher suites may potentially be used to identify the application.  The Initiator and the Responder must also make sure that unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages. </del> <ins> passive eavesdroppers to correlate the different sessions.  Note that even if ead_value is encrypted outside of EDHOC, the ead_label in EAD_1 is revealed to passive attackers and the ead_label in EAD_2 is revealed to active attackers.  Another consideration is that the list of supported cipher suites may potentially be used to identify the application.  The Initiator and the Responder must also make sure that unauthenticated data does not trigger any harmful actions.  In particular, this applies to EAD_1 and error messages. </ins> An attacker observing network traffic may use connection identifiers sent in clear in EDHOC or the subsequent application protocol to
Change:
Based on side comment in about "all symmetric keys are derived using as much previous information as possible"

Discussion:
Transport of external authorization data. EDHOC is designed to encrypt and integrity protect as much <del> information as possible, and all symmetric keys are derived using as much previous information as possible.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of- possession of the private authentication key. </del> <ins> information as possible.  Symmetric keys and random material derived using EDHOC-KDF are derived with as much previous information as possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of-possession of the private authentication key. </ins> To simplify for implementors, the use of CBOR and COSE in EDHOC is summarized in CBORandCOSE.  Test vectors including CBOR diagnostic
Change:
. First text based on initial draft by Christian.
On request. Some people have already implemented this and may want to comment on the Implementation Note in PR .
Merged

Discussion:
..., 23 is just copied directly into the message, a byte string which doesn't is encoded as a CBOR bstr during transport. <ins> Implementation Note: When implementing the byte string identifier representation it can in some programming languages help to define a new type, or other data structure, which (in its user facing API) behaves like a byte string, but when serializing to CBOR produces a byte string or an integer depending on its value. </ins> 3.3.3. For OSCORE, the choice of connection identifier results in the
Change:
NAME Do you or David have any comment on the formulation?
NAME We needed to merge this PR to prepare for -17, but we are of course still interested in your comments :-)
No comment to do ;). It's good.
This is the outcome of the work by Baptiste Cottier and David Pointcheval related to The conclusions form Baptiste and David is that after receiving message4 the Initiator has authenticated the Responder with a strength of the combined MACs in message2 and message4. I.e. if both MACs are 64 bits, they work together as a 128 bit MAC. The same thing apply to application messages such as OSCORE used as message 4,5,6,..... but this comes with the additional requirement that the security association has to be terminated and EDHOC redone in the case that verification of the OSCORE MAC fails. The same apply to the draft-ietf-core-oscore-edhoc where 2 MACs are sent in flight 3 URL The same priciple should apply to modes with signatures where a signature in message2 combined with a MAC in message_4 gives the strenght of the signature and the MAC combined. Baptiste and David have not investigated this formally.
Good. Terminology comment: You use first "authenticated with 128-bit security" and then "128-bit mutual authentication". I assume that means the same in security terms (although one is unilateral and the other mutual). No mentioning of online attacks here. Is it clear how that relates to "64-bit security against online brute force attacks" which is stated in another security consideration? "can be achieved after verification of the first OSCORE Response". This is correct in its brevity, but the use of "verification" gives the impression that it is the verification of OSCORE Response is what makes this achieved, rather than it is the completion of the processing of the OSCORE request and OSCORE response that are the moments in time when, with the appropriate measures, security can be achieved. Perhaps replace "verification" with "completion".

Discussion:
RFC8613) typically only breaks the security of the data in the forged packet. <ins> As the EDHOC protocol is terminated when verification fails, the security against online attacks is given by the sum of the strength of the verified signatures, MACs (including MAC in AEAD).  As an example, if EDHOC is used with method 3, cipher suite 2, and message_4, the Responder is authenticated with 128-bit security against online attacks (the sum of the 64-bit MACs in message_2 and message_4).  The same principle applies for MACs in an application protocol keyed by EDHOC as long as EDHOC is rerun when verification of the first MACs in the application protocol fail.  As an example, if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of I-D.ietf-core-oscore-edhoc, 128-bit mutual authentication against online attacks can be achieved after completion of the first OSCORE request and response. </ins> After sending message_3, the Initiator is assured that no other party than the Responder can compute the key PRK_out.  While the Initiator can securely send protected application data, the Initiator SHOULD
Change:
This note needs to be updated. The sentence is a remnant since TH3 was defined as H(TH2, PLAINTEXT_2)

Discussion:
Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the <del> input to the hash function is a CBOR Sequence.  Note that H(TH_2, PLAINTEXT_2) can be computed and cached already in the processing of message_2. </del> <ins> input to the hash function is a CBOR Sequence.  Note that TH_3 can be computed and cached already in the processing of message_2. </ins> Compute MAC_3 as in expand, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>

Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_4 is a CBOR encoded bstr and the <del> input to the hash function is a CBOR Sequence. </del> <ins> input to the hash function is a CBOR Sequence.  Note that TH_4 can be computed and cached already in the processing of message_3. </ins> Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can now derive application keys using the EDHOC-Exporter interface,
Change:
First take on explaining how to calculate a Y value for old APIs not supporting the full {{SECG}} format.
Given e.g. the Julia programming language the calculations aretrivial For more constrained platforms maybe we should have some link to a paper explaining how to do this type of calculations on constrained platforms. URL URL file:///Users/emanjon/Downloads/applsci-10-URL
If a y-coordinate is required then the value ~yp SHALL be set to zero This leads to unnecesary extra code if a y value is calculated. I suggest that we reformulate this
Erik Thormarker wrote me that RFC 6090 Appendix C is a good high level reference for this.
LGTM
NAME and others: is the new text sufficient to support implementers which has to use a library requiring the y-coordinate?
Merged PR to master that addresses this
Here some comments after going through the PR.

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