jiebi/TextFlow huggingface dataset:
Original text:
Choose a connection identifier C_R and store it for the length of the protocol. <del> Compute the transcript hash TH_2 = H(message_1, data_2) where H() is the hash function in the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del>  Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted, otherwise C_R is not omitted. <del> Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3) where H() is the hash function in the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del>  Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in

Reviewer comments:
This addresses . I don't think we need to include names for the intermediary hashes.

Revised text:
Choose a connection identifier C_R and store it for the length of the protocol.  <ins> Compute the transcript hash TH_2 = H( H(message_1), data_2 ) where H() is the hash function in the selected cipher suite.  The transcript hash TH_2 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(message_1) can be computed and cached alredy in the processing of message_1. </ins> Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted, otherwise C_R is not omitted.  <ins> Compute the transcript hash TH_3 = H( H(TH_2, CIPHERTEXT_2), data_3 ) where H() is the hash function in the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) can be computed and cached alredy in the processing of message_2. </ins> Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in
Original text:
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>  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-

Reviewer comments:
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.

Revised text:
where  <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-
Original text:
An implementation may support only a single method.  None of the methods are mandatory-to-implement.  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>  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>  For many constrained IoT devices it is problematic to support more than one cipher suite.  Existing devices can be expected to support

Reviewer comments:
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.

Revised text:
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.  <ins> Implementations MAY support message_4.  Error codes 1 and 2 MUST be </ins> supported.  <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
Original text:
8.6.  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>  The availability of a secure random number generator is essential for the security of EDHOC.  If no true random number generator is

Reviewer comments:
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.

Revised text:
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.  <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
Original text:
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>  4.1.

Reviewer comments:
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.

Revised text:
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-  <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.
Original text:
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>  Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as

Reviewer comments:
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.

Revised text:
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  <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
Original text:
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>  8.6.

Reviewer comments:
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.

Revised text:
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-  <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.
Original text:
Verification of the selected cipher suite. <del> Method types and error handling. </del>  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>  The Initiator can derive symmetric application keys after creating EDHOC message_3, see exporter.  Protected application data can

Reviewer comments:
There are now two different media types defined. Padding was missing from the list that EDHOC adds.

Revised text:
Verification of the selected cipher suite.  <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  <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
Original text:
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>  An attacker observing network traffic may use connection identifiers sent in clear in EDHOC or the subsequent application protocol to

Reviewer comments:
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.

Revised text:
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  <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
Original text:
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>  To simplify for implementors, the use of CBOR and COSE in EDHOC is summarized in CBORandCOSE.  Test vectors including CBOR diagnostic

Reviewer comments:
Based on side comment in about "all symmetric keys are derived using as much previous information as possible"

Revised text:
Transport of external authorization data. EDHOC is designed to encrypt and integrity protect as much  <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
Original text:
..., 23 is just copied directly into the message, a byte string which doesn't is encoded as a CBOR bstr during transport.  3.3.3. For OSCORE, the choice of connection identifier results in the

Reviewer comments:
. 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

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

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

Revised text:
Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the  <ins> input to the hash function is a CBOR Sequence.  Note that TH_3 can be computed and cached already in the processing of message_2. </ins> Compute MAC_3 as in expand, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >> Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_4 is a CBOR encoded bstr and the  <ins> input to the hash function is a CBOR Sequence.  Note that TH_4 can be computed and cached already in the processing of message_3. </ins> Calculate PRK_out as defined in fig-edhoc-kdf.  The Initiator can now derive application keys using the EDHOC-Exporter interface,
Original text:
keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and 7.2 of RFC9053, but only including the 'x' parameter in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact representation MAY be <del> used also in the COSE_Key.  If the COSE implementation requires a 'y' parameter, the value y = false SHALL be used.  COSE always use compact output for Elliptic Curve Keys of type EC2. </del>  3.8.

Reviewer comments:
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.

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