jiebi/CodeConvo huggingface dataset:
Change:
protection for the unprotected requests and responses, plus protections for traffic analysis; see ta. <ins> An oblivious request resource needs to have a plan for replacing keys.  This might include regular replacement of keys, which can be assigned new key identifiers.  If an oblivious request resource receives a request that contains a key identifier that it does not understand or that corresponds to a key that has been replaced, the server can respond with an HTTP 422 (Unprocessable Content) status code. A server can also use a 422 status code if the server has a key that corresponds to the key identifier, but the encapsulated request cannot be successfully decrypted using the key. </ins> 8. Words...

Discussion:
If the key identifier isn't known to the oblivious request resource, or the message can't be decrypted, it probably wants to send a clear signal. The signal is definitely not encapsulated at that point, so clients have limited options available to them. As a first-order suggestion, a 4xx status code generally indicates to the client that it might want to review the information it used. However, more specific error codes might help in specific cases that we deem important or common. Top of the list: when the identified key has been decommissioned.
How does sound in terms of saying "the content was unusable". We could go further and recommend the use of if you think more detail is needed.
Change:
Further, if UDP traffic is desired to be throttled, it is recommended to block individual QUIC flows entirely rather than dropping packets <del> randomly.  When the handshake is blocked, QUIC-capable applications may failover to TCP However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but the connections will suffer from severe packet loss (see also sec-filtering).  Therefore UDP throttling should be realized by per-flow policing as opposed to per- packet policing.  Note that this per-flow policing should be stateless to avoid problems with stateful treatment of QUIC flows (see sec-stateful), for example blocking a portion of the space of values of a hash function over the addresses and ports in the UDP </del> <ins> indiscriminately.  When the handshake is blocked, QUIC-capable applications may failover to TCP However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but resulting in connections then suffering severe packet loss (see also sec-filtering). Therefore UDP throttling should be realized by per-flow policing, as opposed to per-packet policing.  Note that this per-flow policing should be stateless to avoid problems with stateful treatment of QUIC flows (see sec-stateful), for example blocking a portion of the space of values of a hash function over the addresses and ports in the UDP </ins> datagram.  While QUIC endpoints are often able to survive address changes, e.g. by NAT rebindings, blocking a portion of the traffic based on 5-tuple hashing increases the risk of black-holing an active

Discussion:
NiT Fix 365 - The randomness described was a result of indiscriminate drops.
Change:
The exporter value is computed as: <del> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  The early_exporter_secret is define for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. </del> <ins> Where Secret is either the early_exporter_master_secret or the exporter_master_secret.  Implementations MUST use the exporter_master_secret unless explicitly specified by the application.  The early_exporter_master_secret is define for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. </ins> If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as

Discussion:
Make the variable names of various secrets correspond to the labels used for Derive-Secret(). This is not a wire format change, but just a change in the internal variable names.
NAME NAME you see any misses here?
The legends for the message flows still say "trafficsecretN" for the "[]" parts. Also, "Updating Traffic Keys and IVs" still uses "trafficsecretN" in the formula and text prior to it.
In the key schedule
Change:
ClientHellos. Note: it is not always possible to distinguish which association a <del> given packet is from.  For instance, if the client performs a </del> <ins> given record is from.  For instance, if the client performs a </ins> handshake, abandons the connection, and then immediately starts a new handshake, it may not be possible to tell which connection a given protected record is for.  In these cases, trial decryption MAY be

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
the values are referred to as "main" secrets.  This mismatch is a result of renaming the values while retaining compatibility. <del> [[OPEN ISSUE: Replace the strings with hex value?]] </del> The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore

Discussion:
Change "should" -> "SHOULD" around user_canceled Replicate the 8773 language to another place where external PSKs is discussed. Remove an OPEN ISSUE marker
Change:
7. <del> There are few types of identifier in the world for which there is a </del> <ins> There are few types of identifiers in the world for which there is a </ins> standardized mechanism to prove possession of a given identifier.  In all practical cases, CAs rely on a variety of means to test whether an entity applying for a certificate with a given identifier actually

Discussion:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME
Change:
field has value 6, the IP Address field SHALL have a length of 128 bits. <del> Length of the IP Prefix assigned, in bits.  MUST be lesser or equal to the length of the IP Address field, in bits. </del> <ins> The number of bits in the IP Address that are used to define the prefix that is being assigned.  This MUST be less than or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, the endpoint is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the endpoint is allowed to send packets from any source address that falls within the prefix. </ins> 3.2.2.

Discussion:
NAME NAME Does this PR also ?
NAME not quite--it's a step, but there's more to do
I think the field description needs updates. The IP adress is after all an prefix that is masked by the specified number of bits. That is not quite clear yet. However, I think the question if this range should support excluding one or more sub-ranges needs to be sorted out also.
The specification of the field currently states . Is that unclear? If so, can you help provide text to help make it clearer? Agreed, that's discussed in
Editorial clarification that the prefix in the advertisement applies to the address in the advertisement, which is a remote prefix that the client is allowed to send to.
Change:
controller and RTT estimate, as described in migration-cc. The new path might not have the same ECN capability.  Therefore, the <del> endpoint verifies ECN capability as described in ecn. </del> <ins> endpoint validates ECN capability as described in ecn. </ins> 9.3.

Discussion:
URL verified. Consistency in terms helps.
mentions /verification/ of ECN but defines /validation/ of ECN.: In section 9.2: the term /verify/ is used 3 times, but not explained: /verifies ECN capability/ and /verifies ECN support/ should these both be /validates ECN support/ ? … ALSO is there a difference between ECN support and ECN capability? - I didn’t expect a subtle difference, can we use one set of words instead? (and sorry if I compounded any confusion in the terms...)
Change:
7. <del> 7.1. </del> <ins> The receiver that observes the peer's address or port update MUST stop sending any buffered application data, or limit the data sent to the unvalidated address to the anti-amplification limit. </ins> <del> Note: This algorithm does not take the off-path scenario into account. </del> <ins> It then initiates the return routability check that proceeds as described either in enhanced or regular, depending on whether the off-path attacker scenario described in off-path is to be taken into account or not. </ins> <del> The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </del> <ins> (The decision on what strategy to choose depends mainly on the threat model, but may also be influenced by other considerations.  Examples of impacting factors include: the need to minimise implementation complexity, privacy concerns, the need to reduce the time it takes to switch path.  The choice may be offered as a configuration option to the user.) After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. 7.1. </ins> The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the

Discussion:
factor out common text remove the spurious "address confirmation failure": path validation only fails on timeout provide further rationale for choosing between basic and enhanced
We probably need to tell implementers why/when they should choose the basic algorithm vs the enhanced. For example, avoid enhanced if: you need to minimise implementation complexity you have privacy concerns -- i.e., to avoid providing a clear correlation signal off-path attackers are not in your threat model and/or you want to reduce the time it takes to switch path
In the path validation algorithm (both base and enhanced) we say "[...] or the address confirmation fails [...]", but we don't say precisely what we mean by that. If it refers to failure in validating the received Cookie value, than there's a potential out-of-sync with the requirement: "[...] the initiator MUST silently discard any invalid path_response it receives." If not, we should say what we mean by "address confirmation failure."
Change:
CONTRIBUTING file. In addition to Working Group policies, notices on repositories MUST <del> include citations for the IETF Note Well [8]. </del> <ins> include citations for the IETF Note Well [5]. </ins> 3.

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
Endpoints communicate in QUIC by exchanging QUIC packets.  Most packets contain frames, which carry control information and <del> application data between endpoints.  QUIC authenticates all packets and encrypts as much as is practical.  QUIC packets are carried in UDP datagrams (UDP) to better facilitate deployment in existing systems and networks. </del> <ins> application data between endpoints.  QUIC authenticates the entirety of each packet and encrypts as much of each packet as is practical. QUIC packets are carried in UDP datagrams (UDP) to better facilitate deployment in existing systems and networks. </ins> Application protocols exchange information over a QUIC connection via streams, which are ordered sequences of bytes.  Two types of stream

Discussion:
Éric Vyncke said:
This is deliberate. Everything is authenticated (absent some unused fields in Retry packets and Version Negotiation, which has a big TBD on it). As much as possible is encrypted. I'm going to propose no action here.
Well, it's not deliberate that he has trouble parsing it, so I don't think that's the right way to justify a no-action. This is an editorial comment. Something like "QUIC authenticates all packets; as much of each packet as practical is also encrypted." would make the same statement with less possibility of misunderstanding. As a native speaker, I don't find the current text confusing, but I also realize that our audience includes those from different backgrounds; I'm not opposed to making an editorial change here.
Change:
error since the client instance will be unable to complete the request without authorization. <del> The AS SHOULD handle any interact request as a one-time-use mechanism and SHOULD apply suitable timeouts to any interaction mechanisms provided, including user codes and redirection URIs.  The client instance SHOULD apply suitable timeouts to any callback URIs. </del> 2.5.1. This specification defines the following interaction start modes as

Discussion:
Allows interaction responses from the AS to have an explicit timeout, with instructions on how the client instance can recover (do a modification).
To edit notification comments on pull requests, go to your .
When an AS creates a set of of interaction artifacts, like a user code or interaction URI, these artifacts aren't likely to be available perpetually. The AS will likely want to purge these after some time. It might be useful for the AS to indicate to the client a timeout for the "interact" return block so that the client has some idea of how much time it has to use the interaction methods.
Change:
denoted skI and pkI, respectively, used to produce tokens.  Each key pair MUST be generated as follows: <del> The key identifier for this specific key pair, denoted "key_id", is computed as follows: </del> <ins> The key identifier for this specific key pair, denoted "token_key_id", is computed as follows: Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide with other truncated key IDs in rotation. </ins> 6.

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del> <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name

Discussion:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)
Change:
suites 5, 6 or 7.  To illustrate the negotiation mechanics we let the Initiator first make a guess that the Responder supports suite 6 but not suite 5.  Since the Responder supports neither 5 nor 6, it <del> responds with an error and SUITES_R, after which the Initiator selects its most preferred supported suite.  The order of cipher suites in SUITES_R does not matter.  (If the Responder had supported suite 5, it would include it in SUITES_R of the response, and it would in that case have become the selected suite in the second message_1.) </del> <ins> responds with SUITES_R containing the supported suites, after which the Initiator selects its most preferred supported suite.  The order of cipher suites in SUITES_R does not matter.  (If the Responder had supported suite 5, it would have included it in SUITES_R of the response, and it would in that case have become the selected suite in the second message_1.) </ins> Note that the Initiator's list of supported cipher suites and order of preference is fixed (see asym-msg1-form and init-proc-msg1).

Discussion:
Addressing
NAME Please check if your comments are addressed.
Yes, especially in [1]. Thanks! [1] URL
-08 contained a definition of CREDx including an example when kid is used. -09 removed that example and replaces it with a RPK by value example. Now it seems like the most important use case is not well specified. This is the use case that leads to message2 being 45 bytes.
In addition the TOFU use case should likely also have a kid. Otherwise the UCCS has to be sent by value every time.
This is solved by just adding a 'kid' in the COSE_Key map
The document should say someting more about COSEKey. If IDCREDx = { 4 : keyidx } identifies a raw COSEKey, is that an error or is CREDx then the COSEKey wrapped in a UCCS without any parameters like sub?
SUITES_R is a name. The type needs to be defined and the table changed. This can be done in PR
The current definition of SUITESI is that the Initiator can chose any truncation of the list of supported cipher suites as long as the selected cipher suite is included. This works and allows the Initiator to give the Responder information about the full list. This is however a bit complex and has led to misunderstandings of the test vectors where several people thought the test vectors were wrong. i.e. the following are all valid I think we should simplify SUITESI by mandating that the last suite in the list is the selected. This makes SUITESI much easier to understand and lowers message size when an array is used. Giving the Responder info is not so important. CDDL
Maybe a recommendation that SUITES_R SHOULD contain all cipher suites that R supports.
Currently SUITESR : [ supported : 2 suite ] / suite We may keep that, or remove "supported" SUITESR : [ 2 suite ] / suite Alternatively, we may define SUITES_I : [ supported : 2* suite ] / suite Any preference?
They should be the same: or And then
This needs to be defined as a CDDL type. suites = [ 2* suite ] / suite See
Change:
ALTSVC frame (ALTSVC), using the ALPN token defined in connection- establishment. <del> For example, an origin could indicate in an HTTP/1.1 or HTTP/2 response that HTTP/3 was available on UDP port 50781 at the same hostname by including the following header field in any response: </del> <ins> For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the following header field: </ins> On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and

Discussion:
HTTP response headers are common across HTTP/1.1, HTTP/2 and HTTP/3. There seems no need to be so precise on what version of the protocol returns the example header.
Change:
in ABNF as "%x2318". The terminology of RFC8259 applies except where clarified below.  The <del> terms "Primitive" and "Structured" are used to group the types as in RFC8259; JSON Objects and Arrays are structured, all other types are primitive.  Definitions for "Object", "Array", "Number", and "String" remain unchanged.  Importantly "object" and "array" in particular do not take on a generic meaning, such as they would in a general programming context. </del> <ins> terms "Primitive" and "Structured" are used to group different kinds of values as in RFC8259; JSON Objects and Arrays are structured, all other values are primitive.  Definitions for "Object", "Array", "Number", and "String" remain unchanged.  Importantly "object" and "array" in particular do not take on a generic meaning, such as they would in a general programming context. </ins> Additional terms used in this specification are defined below.

Discussion:
JSON types are not used much in the JSON spec. It is debatable whether there really is a boolean type or simply the values and . Also, the JSONPath spec doesn't really benefit from this term.
I think this reads well without breaking any semantics.
Change:
An application server can voluntarily identify itself to a push service using the described technique.  This identification information can be used by the push service to attribute requests <del> that are made by the same application server to a single entity, and reduce the need for endpoint secrecy by being able to associate subscriptions with an application server.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </del> <ins> that are made by the same application server to a single entity. This can used to reduce the secrecy for push subscription URLs by being able to restrict subscriptions to a specific application server.  An application server is further able include additional information the operator of a push service can use to contact the operator of the application server. </ins> 1.

Discussion:
As discussed on the mailing list. NAME NAME can you review this? You can see a nicely formatted version .
This looks good, thanks! +NAME to take a look from the server-side perspective (notably, we'd have to parse and extract a value from header on the server).
Updated.
I think that the confusion here between 401 and 403 were not helped by the fact that they were completely inconsistent. Here are the revised rules: MUST send 401 if you absolutely require credentials and there are none MAY send 403 if the credentials are bad
403 "forbidden" should not be sent if credentials are bad - would only happen if credentials are good ( we verified that the caller is who he claims to be ), but he is forbidden to send, because the subscribe request specified a different sender is allowed. 401 is for missing or bad credentials - if there was no JWT token but the server expects one, of if the JWT provided is bad, doesn't matches the signature. , Martin Thomson EMAIL wrote:
URL , Costin Manolache EMAIL wrote:
NAME I believe that the text is correct. "bad" was perhaps too terse, maybe I should have said "403 MAY be sent if the credentials are present but insufficient to authorize the request"
Thanks. Sorry for being too picky, but I've seen some nasty bugs caused by 401/403 confusion. 403 and "bad" or "invalid" credentials can be interpreted as "invalidate current password and ask user" - in webpush it shouldn't be a huge problem, since the JWT tokens will almost never be invalid (unlike a regular account on password change or revoked token ). , Martin Thomson EMAIL wrote: