jiebi/CodeConvo huggingface dataset:
Change:
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....)

Discussion:
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.
Change:
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)

Discussion:
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> <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.
Change:
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."

Discussion:
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> <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
Change:
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

Discussion:
Pass AD_1 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC </del> <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
Change:
Notes: Certificateless server-to-server communication is definitively used for OTT communications e.g. URL

Discussion:
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 <del> compliant devices. </del> <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-
Change:
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.

Discussion:
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> <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:
Change:
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.

Discussion:
handshake, ostensibly with "B". The attacker redirects the "Finished" message to "C".  "C" has <del> completed the handshake, ostensibly with "A". </del> <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
Change:
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 .

Discussion:
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
Change:
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.'

Discussion:
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> <ins> with early data. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
[[ See issue #105 [78] ]] <del> When used to bind to an access token, the </del> <ins> When used to bind to an access token, the access token MUST be covered by the signature method. </ins> 8.1.
Change:
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

Discussion:
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> <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 <del> communicated out-of-band or is pre-configured between the components </del> <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: <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> <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> <del> The b (body hash) field MUST be calculated and supplied, unless </del> <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).
Change:
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fd1d0f88ac7d2a9ad6f43bb6d959a2aa84558f2b https://deploy-preview-179--gnap-core-protocol-editors-URL
One small change needed (marked) but otherwise good!

Discussion:
those privileges to an end-user.  This process is refered to as privilege delegation. <del> protected API (Application Programming Interface) served by a RS </del> <ins> protected API (Application Programming Interface) served by an RS </ins> and that can be accessed by a client, if and only if a valid access token is provided.  Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource. ability given to a subject to perform a given operation on a <del> resource under the control of a RS. </del> <ins> resource under the control of an RS. </ins> person, organization or device.

parameters for the incoming request match those that it is expecting from the session created in (1).  The client instance also needs to be prepared for the end-user never being returned to <del> the client instance and handle time outs appropriately. </del> <ins> the client instance and handle timeouts appropriately. </ins> The client instance loads the continuation information from (3) and sends the interaction reference from (7) in a request to

Claims about the RO as known and declared by the AS. <del> An identifier this client instance instance can use to identify itself when making future requests. </del> <ins> An identifier this client instance can use to identify itself when making future requests. </ins> <del> An identifier this client instance instance can use to identify its current end-user when making future requests. </del> <ins> An identifier this client instance can use to identify its current end-user when making future requests. </ins> An error code indicating that something has gone wrong.
Change:
Suggested changes for URL They could be also simplified to something like
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 0569eb3db265511e06d7fb19b2320081d4626430 https://deploy-preview-183--gnap-core-protocol-editors-URL
Sections "9 Discovery" states that It makes sense to specify that this URL should be using HTTPS. I also don't think you want to allow using the fragment component in it, as well as query parameters. The query parameters could be arguable though...
This definition should be beyond just the discovery portion -- this endpoint is fundamental to the protocol and it does need to be protected. We can at least mention that it starts with HTTPS here. Prohibiting fragments makes sense, but prohibiting query parameters or any other URL portion does not make sense, though, as that could be important to an AS's deployment. However, the client instance always takes this string as-is and doesn't add or modify anything, and it always makes a POST to it.
URL
I've reused the definition of . That is a very precise one IMO.

Discussion:
endpoint to retrieve the server's discovery information.  The AS MUST respond with a JSON document containing the following information: <del> REQUIRED.  The full URL of the AS's grant request endpoint.  This MUST match the URL the client instance used to make the discovery request. </del> <ins> REQUIRED.  The location of the AS's grant request endpoint.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST match the URL the client instance used to make the discovery request. </ins> OPTIONAL.  A list of the AS's capabilities.  The values of this result MAY be used by the client instance in the request-