jiebi/CodeConvo huggingface dataset:
Change:
does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. <del> 8. </del> <ins> 7. </ins> The Key Importer security goals can be roughly stated as follows: avoid PSK re-use across KDFs while properly authenticating endpoints.

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
to be interpreted as in URI. The terms "presentation", "stream", "YAML document", "representation <del> graph", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </del> <ins> graph", "tag", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </ins> 1.2.

Discussion:
in YAML and JSON, explicits that you need to use only information that is stored in the representation graph, not other. See
mention presentation and serialization details they cannot be used to interoperably convey information comments, ordering and anchor names fall in the above categories.
Change:
QUIC's loss detection algorithm determines that the quoted packet has actually been lost. <del> 14.2. </del> <ins> 14.3. </ins> Datagram Packetization Layer PMTU Discovery (DPLPMTUD; DPLPMTUD) relies on tracking loss or acknowledgment of QUIC packets that are

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)
Change:
ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. <ins> Using the mechanisms described in seqno-replay-state reveals when a device goes through a reboot.  This can be mitigated by the device storing the precise state of sender sequence number and recipient replay window on a clean shutdown. </ins> 12. Note to RFC Editor: Please replace all occurrences of "[[this

Discussion:
Not a grave issue, but it's a leak of information that can be reduced to leaking unexpected reboots vs. leaking any reboot by being aware of it.
Thanks NAME , I am just confused by the term "clean shutdown" here. What do you mean by that? If I understand correctly the rest of your text, you are suggesting that to avoid leaking information about accidental reboots, the device keeps track of the node's state constantly, so that when an accidental reboot happens, the node can re-instate the right seq. When does clean shutdown come into the picture?
Typical devices can not tolerate the flash wear of writing the sequence number state on any package transmission (that's why there's the "Seq + K" part in 6.3.1), and that limitation won't go away just because it has privacy consequences. Accidental reboots will thus be leaked, but deliberate ones can be hidden by storing the fine-grained seqno state on flash. For example: Initial boot, everything is 0 Before sending package 1, write "seqno=1000" Send 999 more packages w/o writing Before sending package 1001, write "seqno=2000" Send some more packages w/o writing Zap, reboot! Before sending seqno 2001, write "seqno=3000" (this is a hard to prevent leak) Send 49 more packages Shutdown requested, write "seqno=2050" Reboot Before sending seqno=2051, write "seqno=3050" (no reboot leaked)
Change:
Integer labels in the range of 0 to 8 SHOULD be omitted. <del> Integer labels in the range -1 to -255 can be omitted as they </del> <ins> Integer labels in the range -1 to -128 can be omitted as they </ins> are algorithm dependent.  If an application can correctly process an algorithm, it can be assumed that it will correctly process all of the common parameters associated with that <del> algorithm.  (The algorithm range is -1 to -65536; the higher end is for more optional algorithm specific items.) </del> <ins> algorithm.  Integer labels in the range -129 to -65536 SHOULD be included as these would be less common parameters that might not be generally supported. </ins> Labels for parameters required for an application MAY be omitted.  Applications should have a statement if the label can

Discussion:
Some more edits in response to the review. Does not include one item that was proposed for clarification
Change:
10.1.1. An endpoint that sends packets close to the effective timeout risks <del> having them be discarded at the peer, since the peer might enter its draining state before these packets arrive. </del> <ins> having them be discarded at the peer, since the idle timeout period might have expired at the peer before these packets arrive. </ins> An endpoint can send a PING or another ack-eliciting frame to test the connection for liveness if the peer could time out soon, such as

Discussion:
Idle timeout doesn't enter the draining period. Sending PING will reset both idle timeouts for both endpoints.
if it is expecting response data, but does not have or is unable to send application data. However, you can't necessarily reset your own idle_timeout that way because it only is reset when you haven't already sent an ack-eliciting packet after the last received packet. If this is about resetting the peer, then maybe editorial. If it is about resetting yourself, then this may be design.
This is both idle timeouts. The idea behind the rules regarding the local reset of the idle timer is that if you send an ack-eliciting packet, you will get an acknowledgment. You are required to send probes until you do. So you only reset the timeout on the first.
says that after the idle timeout expires, "the connection is silently closed and its state is discarded." However, 10.2.1 says that the peer "might enter its draining state." Based on 10.2, I would not expect there to be a draining state; the connection is simply gone, and you would get a stateless reset. Is the draining state used after the endpoints time out, or not?
I need to find the issue, but we explicitly decided to not drain after idle timeout.
resolved this.
Couple of nits, but LGTM.
Change:
5. <del> To make a DNS API query, a DNS API client sends an HTTP request to the URI of the DNS API. The URI scheme MUST be https. A client can be configured with a DNS API URI, or it can discover the URI.  This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI.  (See iana for the registration of this in the well-known URI registry.) DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. A DNS API Client encodes a single DNS query into the HTTP request using either the HTTP GET or POST methods. </del> <ins> To make a DNS API query a DNS API client encodes a single DNS query into an HTTP request using either the HTTP GET or POST method and the other requirements of this section.  The DNS API server defines the URI used by the request.  Configuration and discovery of the URI is done out of band from this protocol. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header

Discussion:
and
The draft says: But it probably needs to describe at least one way to perform that automated discovery. It's probably not a good idea to have people attempt to guess.
fwiw the .wk is used here so that that when a request/response pair is pushed the client understands this to be DoH. Its probably also helpful to have a well-known path here for the normal so that defaults of https://, 443, and the default path can be used in configuration systems that might only be capable of a hostname. (e.g. my DoH server is at URL).. I'll work on text.
I think I can future proof for the context I want using a response header instead of a well known.. imo that's kind of ignoring the point of the path - but whatever. Maybe I'll propose x-well-known :)
Change:
9.1. If the client instance calls an RS without an access token, or with <del> an invalid access token, the RS MAY respond to the client instance with an authentication header indicating that GNAP needs to be used to access the resource.  The address of the GNAP endpoint MUST be sent in the "as_uri" parameter.  The RS MAY additionally return a resource reference that the client instance MAY use in its access </del> <ins> an invalid access token, the RS SHOULD respond to the client instance with a WWW-Authenticate header field indicating that GNAP needs to be used to access the resource.  The address of the GNAP endpoint MUST be sent in the "as_uri" parameter.  The RS MAY additionally return a resource reference that the client instance SHOULD use in its access </ins> token request.  This resource reference MUST be sufficient for at least the action the client instance was attempting to take at the RS and MAY be more powerful.  The means for the RS to determine the

Discussion:
To edit notification comments on pull requests, go to your .
Yaron: "Speculative" access ("Requesting a Resources With Insufficient Access") is not useful if the response is only a MAY. Why would the RC try it if it is unlikely to provide useful information? Justin: I think the MAY is not quite the right normative application here. It’s a MUST if you’re doing it to do it in this way, but it’s not a MUST for all RS’s everywhere to respond in this fashion. If the RC tries calling an RS that doesn’t respond with this, the RC simply doesn’t know, from any programmatic or automated way, what to do to make the request actually work. Yaron: Sounds like a SHOULD to me - then an RC can assume with reasonable confidence that a random RS will implement it.
Change:
7. <ins> This section discusses considerations for some deployment scenarios not implied by the specification above. 7.1. </ins> Some network architectures may have multiple tiers of low-state load balancers, where a first tier of devices makes a routing decision to the next tier, and so on until packets reach the server.  Although

Discussion:
Intended to
Some text on how a server cluster might support moving of connections from one server instance to another would be useful. The current design might permit portability under certain conditions, but there are things that might need to be considered, such as the way in stateless resets are generated.
Are you referring to load balancing already existing connections to a new server? Are you envisioning the first server issuing new CIDs (that point to the new server) and setting Retire Prior To to retire the old CIDs so that future traffic redirect to the new server? How do you imagine the rest of the connection state would get moved?
This applies to cases where clusters are rebalanced, where instances go down and others are expected to pick up the slack, and all similar cases. In some cases this requires an unspecified mechanism for transferring state between instances. In others, the instance might remain constant but the identifiers used might need to rotate. This is likely addressed by using Retire Prior To as you say. Text on that would help.
Good idea, it wouldn't hurt to have a short non-normative section on this.
Seems fine.
Change:
of a value and make that available for further processing in the filter expression: <del> Its only argument is a value (possibly taken from a singular path as in the example above).  The result also is a value, an unsigned integer. </del> <ins> Its only argument is an optional value (possibly taken from a singular path as in the example above).  The result also is an optional value, an unsigned integer. </ins> If the argument value is a string, the result is the number of Unicode scalar values in the string.

Discussion:
Fixes URL
NAME I pushed cb1cf124ab to clarify optional arguments.
NAME raised this in a PR review.
I think the answer is "yes" because that allows the function to be used on a Singular Path rather than on just a literal.
Yes. I would expect any function that can take a path must allow any value.
That should be enough to remove this double-take.
Change:
ensured, a client may erroneously associate the wrong response to a request.  The wrong response may be an old response for the same resource or a response for a completely different resource (see e.g. <del> Section 2.3 of I-D.mattsson-core-coap-actuators).  For example, a </del> <ins> Section 2.3 of I-D.mattsson-core-coap-attacks).  For example, a </ins> request for the alarm status "GET /status" may be associated to a prior response "on", instead of the correct response "off".

Discussion:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.
Change:
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

Discussion:
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."
Change:
%%% Record Layer <del> The cleartext of TLSPlaintext.fragment. </del> <ins> The byte encoding of a handshake or an alert message, or the the raw bytes of the application's data to send. </ins> The content type of the record.

Discussion:
This is how NSS behaves as well. This seems like a reasonable argument.
added the changes previously discussed.
I did not verify that the moved text is only move and no edits, but the other chunks seem okay.
NAME are you OK with this SHOULD?
Sounds reasonable. Mostly I just don't want to encourage servers to enforce anything about this.
Change:
Authentication credential: set of information associated with an entity, including that entity's public key and parameters associated with the public key.  Examples of authentication <del> credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) </del> <ins> credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets </ins> RFC8392, X.509 certificates RFC7925 and C509 certificates I- D.ietf-cose-cbor-encoded-cert.  Further details about authentication credentials are provided in sec-pub-key-format.

Discussion:
So far, it was used 1x in abbreviated form, and 2x as "CWT Claims Sets (CCS)". The abbreviation was problematic the way it was used while being a reference into RFC8392, it was not defined there. I'm not 100% happy with dropping the term "CCS" because it having an abbreviation is a good pointer for users to see that this is an established, good and compact thing to use (right?), but I'd rather spare readers the confusion of clicking through to 8392 and not finding the letters "CCS". I'd be happy with any better handling of the possible confusion, this is just the best I'm coming up with.
Change:
This document describes the issuance protocol for Privacy Pass built on HTTP.  It specifies two variants: one that is privately verifiable <del> based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. </del> <ins> using the issuance private key based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable using the issuance public key based on the blind RSA signature scheme BLINDRSA. </ins> This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks.

Discussion:
Hexadecimal constants are used as strings without specifying the length or byte order. For example, "0x0001" might be interpreted in a couple of ways. Usually the correct interpretation is clear in context, but I'm not sure it always is.
[ ] Overall: The document is inconsistent about capitalization after colon (":"). [ ] Abstract: I'm not sure the distinction between public/private verifiability is common knowledge. It might be helpful to say plainly who is doing the verifying. E.g.: "one [variant] providing tokens whose validity can be verified by the issuer only; and another for which token validity can be verified by any party with the issuer public key." [ ] 2 Terminology: "We assume that all protocol messages are encoded into raw byte formatt before being sent across the wire" This doesn't need to be mentioned, in my opinion. [ ] 5.1 Client-To-Issuer Request: The psedocode for computing "client_context" hard-codes a particular OPRF suite (0x0004). Is this the only suite that is permitted/recommended by the document? I don't think this is clear until the token types are defined in Section 8.1. [ ] 5.3 Finalization: Constants hardcoded instructs don't a semi-colon after the constant. (See "Token" in this section, for example.) Is this intentional? It looks a bit odd, and I'm wondering if this is "syntactically" correct. [ ] 5.4 Token Verification: I think it's worth pointing out here that creating the server context requires the Issuer Private Key, which is why VOPRF is not publicly verifiable. [ ] 7 Security Considerations: "All security considerations described in the VOPRF document also apply in the Privacy Pass use-case." What about security considerations for BLINDRSA? It might be a bit cleaner to write something like this: "Each protocol described here inherits the security considerations of its base document: For Section 5, this is [VOPRF]; ... " [ ] Acknowledgements: Sofi is acknowledged, but is also a co-author.
I think I caught all of these. Addressed in . Yes, this is much better! Addressed in .

This is addressed by . We explain the constant in the sentence immediately following the pseudocode, so I don't think further clarification is needed. The semi-colon was missing, but we updated this to match what's done in RFC8446. Addressed in . Addressed in . Good catch. This has already been fixed on the editor's branch to say "All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use-case."
Change:
specific "a=imageattr" attributes MUST be inserted for each payload type. <del> As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </del> <ins> As an example, consider a system with a multiformat video decoder, which is capable of decoding any resolution from 48x48 to 720p, and where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this </ins> attribute: <del> a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] </del> <ins> a=imageattr:* recv [x=[48:640],y=[48:360],q=1.0] </ins> This declaration indicates that the receiver is capable of decoding <del> any image resolution from 16x16 up to 640x360 pixels. </del> <ins> any image resolution from 48x48 up to 640x360 pixels. </ins> 3.6.2.

Discussion:
This is from the Windows HW offload framework, and spells things out more specifically in the surrounding text.
Change:
The server's preferred address is used to effect a change in server address at the end of the handshake, as described in <del> preferred-address.  The format of this transport parameter is shown in fig-preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are </del> <ins> preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are </ins> encoded in network byte order. <ins> The preferred_address transport parameter contains an address and port for both IP version 4 and 6.  The four-byte IPv4 Address field is followed by the associated two-byte IPv4 Port field. This is followed by a 16-byte IPv6 Address field and two-byte IPv6 Port field.  After address and port pairs, a Connection ID Length field describes the length of the following Connection ID field. Finally, a 16-byte Stateless Reset Token field includes the stateless reset token associated with the connection ID.  The format of this transport parameter is shown in fig-preferred- address. </ins> The Connection ID field and the Stateless Reset Token field contain an alternative connection ID that has a sequence number of 1; see issue-cid.  Having these values bundled with the preferred

Discussion:
In section 18.2, the definition of preferred_address says: In section 1.3, we say: The prose does not define the sequence of fields in this transport parameter.
Thanks for catching that I was looking at the wrong TP definition and knowing what I meant. Eyes glaze over indeed!