jiebi/TextFlow huggingface dataset:
Original text:
where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in Sections oscore.  4. 4.1.

Reviewer comments:
Should be discussed in LAKE if this is the right approch Should be discussed what the best way is to calculate the hash chain The nonce is included to make sure that the hash chain does not have short cycles. It should be discussed if the nonce is provided by the application (OSCORE) or by EDHOC itself. If provided by OSCOREbis it could be a random string or a counter. If the nonce is provided by EDHOC it has to be a deterministic. E.g. a counter (or theoretically a LFSR....)

Revised text:
where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in Sections oscore. <ins> To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the function EDHOC-Exporter-FS.  When EHDOC-Exporter-FS is called the old PRK_4x3m is deleted and the new PRk_4x3m is calculated as a "hash" of the old key using the Extract function as illustrated by the following pseudocode: </ins> 4. 4.1.
Original text:
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.

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

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

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

Revised text:
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
Original text:
Pass AD_1 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC </del>  error message back, formatted as defined in error, and the protocol MUST be discontinued.  If the Responder does not support the selected cipher suite, then SUITES_R MUST include one or more supported cipher

Reviewer comments:
When the responder is processing message 1, section 4.4.3 reads: If any verification step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in Section 5, and the protocol MUST be discontinued. I think this should be: If any verification step fails, the MUST send an EDHOC error message back, formatted as defined in Section 5, and the protocol MUST be discontinued. PR: URL

Revised text:
Pass AD_1 to the security application.  <ins> If any verification step fails, the Responder MUST send an EDHOC </ins> error message back, formatted as defined in error, and the protocol MUST be discontinued.  If the Responder does not support the selected cipher suite, then SUITES_R MUST include one or more supported cipher
Original text:
TODO  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", PSKs, primarily for the purposes of supporting TLS connections with fast open (0-RTT data).  Internet of Things (IoT) and devices with limited computational capabilities.  RFC7925 defines TLS and DTLS profiles for resource- constrained devices and suggests the use of PSK ciphersuites for <del> compliant devices. </del>  Use of PSK ciphersuites are optional when securing RADIUS RFC2865 with TLS as specified in RFC6614. Secrets may be baked into or hardware or software device components, such as secure enclaves.  6.2. PSK provisioning systems are often constrained in application-

Reviewer comments:
Notes: Certificateless server-to-server communication is definitively used for OTT communications e.g. URL

Revised text:
TODO <ins> 1.1. The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.rescorla- tls-ctls. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", PSKs, primarily for the purposes of supporting TLS connections with fast open (0-RTT data). <ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs, primarily for the purposes of establishing TLS connections without requiring the overhead of provisioning and managing PKI certificates. </ins> Internet of Things (IoT) and devices with limited computational capabilities.  RFC7925 defines TLS and DTLS profiles for resource- constrained devices and suggests the use of PSK ciphersuites for  <ins> compliant devices.  The Open Mobile Alliance Lightweight Machine to Machine Technical Specification LwM2M states that LwM2M servers MUST support the PSK mode of DTLS. </ins> Use of PSK ciphersuites are optional when securing RADIUS RFC2865 with TLS as specified in RFC6614. Secrets may be baked into or hardware or software device components, such as secure enclaves. <ins> Where secrets are baked into hardware at manufacturing time, the secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import into a server. </ins> 6.2. PSK provisioning systems are often constrained in application-
Original text:
In addition to these, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as <del> detailed below. </del>  Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows:

Reviewer comments:
The Selfie paper points out that if each party uses the SNI extension and terminates a connection on mismatch, rerouting attacks like Selfie aren't possible. I added this note to the explanation of such attacks.

Revised text:
In addition to these, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as  <ins> detailed below.  (Note that this class of attack is not possible if each member uses the SNI extension RFC6066 and terminates the connection on mismatch.  See Selfie for details.) </ins> Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows:
Original text:
handshake, ostensibly with "B". The attacker redirects the "Finished" message to "C".  "C" has <del> completed the handshake, ostensibly with "A". </del>  This attack violates the peer authentication property, and if "C" supports a weaker set of cipher suites than "B", this attack also

Reviewer comments:
Since "C", from its perspective, completes the handshake with "A" (without mistaking it for some other endpoint or something), I removed "ostensibly" from the description of the completion of the handshake.

Revised text:
handshake, ostensibly with "B". The attacker redirects the "Finished" message to "C".  "C" has  <ins> completed the handshake with "A". </ins> This attack violates the peer authentication property, and if "C" supports a weaker set of cipher suites than "B", this attack also
Original text:
identities.  Identities may sometimes need to be routable, as is currently under discussion for EAP-TLS.  4. Against a passive attacker AdvP or active attacker AdvA, desired

Reviewer comments:
First cut at . cc NAME
Thanks a lot. This looks good to start with. I think we should also discuss what kind of matching is done on the PSK identity. For example, RFC 7925 says: "For use with this profile, the PSK identities SHOULD NOT assume a structured format (such as domain names, distinguished names, or IP addresses), and a byte-by-byte comparison operation MUST be used by the server for any operation related to the PSK identity." Similarly, RFC 4279 in Section 5.1 describes the UTF-8 encoding of identities to improve interoperability for those cases where the identity is configured by a human using some management interface. If in TLS 1.3, the identity is only used as a hint for looking up the correct PSK in the database, then this would be a significant departure from what was the norm previously. Highlighting this in our document would make sense. The current text also says 'These callbacks must provide the PSK identity (as a character string)'. But the openssl sserver and sclient seem to work without providing PSK identities and use the default character string 'Clientidentity' as the pskidentity.
Merging and moving ^^ to an issue!
Applications configure callbacks that are invoked to select PSKs. These callbacks must provide the PSK identity () and key (char *`). URL mbedTLS also treats PSKs as arbitrary byte arrays and character strings. ... from URL URL URL Applications specify a "username" (as the PSK identity) and a raw PSK. URL URL Callback style (with identical key and identity types) similar to OpenSSL. There is no minimum length enforced for the PSK. URL URL
Fixed in .

Revised text:
identities.  Identities may sometimes need to be routable, as is currently under discussion for EAP-TLS. <ins> 3.3. Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing is below. OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. These callbacks must provide the PSK identity (as a character string) and key (as a byte string).  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. Servers must implement callbacks similar to that of OpenSSL.  PSK lengths are validate to be between [1, 16] bytes. gnuTLS: Applications configure PSK values, either as raw byte strings or hexadecimal strings, and identities as "usernames". The PSK size is not validated. wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL. </ins> 4. Against a passive attacker AdvP or active attacker AdvA, desired
Original text:
federation. Deployments should take care that the length of the PSK identity <del> is sufficient to avoid obvious collisions. </del>  7.1.2.

Reviewer comments:
I'm not sure what makes a collision obvious versus non-obvious, so let's remove the word "obvious."

Revised text:
federation. Deployments should take care that the length of the PSK identity  <ins> is sufficient to avoid collisions. </ins> 7.1.2.
Original text:
Intra-data-center communication.  Machine-to-machine communication within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections <del> with fast open (0-RTT data). </del>  Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,

Reviewer comments:
Since the term 'fast open' isn't used in RFC 8446, replace 'fast open' with the term that RFC 8446 uses for '0-RTT data'--namely, 'early data.'

Revised text:
Intra-data-center communication.  Machine-to-machine communication within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections  <ins> with early data. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,
Original text:
See the Security Considerations in I-D.ietf-tls-external-psk- importer for more information. <del> Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated.  This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself. </del>  7.1.

Reviewer comments:
s7 includes the following and in light of 8446bis we should probable replace "master": Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated. This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself.

Revised text:
See the Security Considerations in I-D.ietf-tls-external-psk- importer for more information.  <ins> Where possible the main PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated. This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the main key and then re-run the importer itself. </ins> 7.1.
Original text:
identity collision occurs, the application's external PSK usage will typically take precedence over the internal session resumption path.  7. PSK privacy properties are orthogonal to security properties

Reviewer comments:
cc NAME
Looks good to me.
So the draft talks about collisions between PSK identities, with some assumptions baked in: external and resumption PSK identities are trivial to keep distinct (it takes a single bit), but the draft assumes that this step is not taken it might be necessary to generate PSK identities without any sort of centralized coordination, which means that you might need to worry about collisions, but that's another unstated assumption That first one is pretty poor.
It seems to me that we need to warn implementers about the situation if external and resumption PSKs are not kept distinct. We could include advice to keep them separate.
I suggest the addition of a paragraph at the end of the Section on "PSK Identity Collisions". Since resumption PSK identity is assigned by the TLS stack implementation, it is RECOMMENDED that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether.

Revised text:
identity collision occurs, the application's external PSK usage will typically take precedence over the internal session resumption path. <ins> Since resumption PSK identities are assigned by the TLS stack implementation, it is RECOMMENDED that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether. </ins> 7. PSK privacy properties are orthogonal to security properties
Original text:
Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a <del> problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </del>  For AMR/AMR-WB, packets can contain copies or lower-quality encodings of multiple prior audio frames.  See RFC4867, Section 3.7.1 for

Reviewer comments:
I believe this came from a WG mailing list post (possibly my own), rather than an external document that could be linked to. Suggestions? Unfortunately, that was the best RFC reference I could find.

Revised text:
Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a  <ins> problem on wireless networks.  See RFC6716, Section 2.1.7, and OpusFEC for more details. </ins> For AMR/AMR-WB, packets can contain copies or lower-quality encodings of multiple prior audio frames.  See RFC4867, Section 3.7.1 for
Original text:
[[ See issue #105 [78] ]] <del> When used to bind to an access token, the </del>  8.1.

Reviewer comments:
This fixes up a dangling statement from the design team draft that somehow never got completed. It's technically a new normative statement but it was clearly intended by the context so this is not a functional or substantive change. Other changes are small formatting issues.

Revised text:
[[ See issue #105 [78] ]]  <ins> When used to bind to an access token, the access token MUST be covered by the signature method. </ins> 8.1.
Original text:
1. This protocol allows a piece of software, the resource client, to <del> request delegated authorization to resource servers and direct information.  This delegation is facilitated by an authorization server usually on behalf of a resource owner.  The requesting party operating the software may interact with the authorization server to authenticate, provide consent, and authorize the request. </del>  The process by which the delegation happens is known as a grant, and the GNAP protocol allows for the negotiation of the grant process calling an RS, all steps involving the RS below do not apply. In some circumstances, the information needed at a given stage is <del> communicated out-of-band or is pre-configured between the components </del>  or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow. oauth-signed-http-request section 4, with the following additional requirements: <del> The at (access token) field MUST be omitted unless this method is being used in conjunction with an access token as in use-access- token.  [[ See issue #112 [86] ]] </del>  <del> The b (body hash) field MUST be calculated and supplied, unless </del>  there is no entity body (such as a GET, OPTIONS, or DELETE request).

Reviewer comments:
iss-sub was renamed to iss_sub in draft -06 of secevent identifiers drop unnecessary hyphenation the initial introduction sentence still might need some more significant rewording

Revised text:
1. This protocol allows a piece of software, the resource client, to  <ins> request delegated authorization to resource servers and to request direct information.  This delegation is facilitated by an authorization server usually on behalf of a resource owner.  The requesting party operating the software may interact with the authorization server to authenticate, provide consent, and authorize the request. </ins> The process by which the delegation happens is known as a grant, and the GNAP protocol allows for the negotiation of the grant process calling an RS, all steps involving the RS below do not apply. In some circumstances, the information needed at a given stage is  <ins> communicated out of band or is preconfigured between the components </ins> or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow. oauth-signed-http-request section 4, with the following additional requirements:  <ins> The "at" (access token) field MUST be omitted unless this method is being used in conjunction with an access token as in use- access-token.  [[ See issue #112 [86] ]] </ins>  <ins> The "b" (body hash) field MUST be calculated and supplied, unless </ins> there is no entity body (such as a GET, OPTIONS, or DELETE request).