jiebi/CodeConvo huggingface dataset:
Change:
payloads and packet numbers MUST be free from side-channels that would reveal the packet number or its encoded size. <del> 9.5. </del> <ins> 9.4. </ins> In using TLS, the central key schedule of TLS is used.  As a result of the TLS handshake messages being integrated into the calculation

Discussion:
Issue observes that this text mentions HTTP/2, which isn't necessary. In reviewing it, I noticed that this talks about messages that do nothing, but not really about messages that do little (or that can be reversed to have net zero effect). So I expanded the text a little.
Thanks for improving the section's clarity. As a follow up question, when implementations decide that excessive packets is an attack, is there a recommended actionable (eg. sending reset, dropping the connection, do nothing) or would that be up for implementer's discretion?
Maybe this needs to be stated explicitly, but there is no point in continuing discussion with an attacker. So while it might be considered polite to send a connection error, it is also acceptable to just drop any further incoming packets. I'll add that here.
Under the section Peer Denial of Service of TLS draft, a referenced was made to HTTP/2. URL I was wonder if this is in fact referring to HTTP/3 or HTTP/2. Also curious why the section is labelled
That mention of h2 was a mistake. I've made a few changes after reviewing this. (The thing is a joke.)
Change:
A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and <del> receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </del> <ins> receiving some sort of response".  Similarly, an imputed definition of "resolution" might be "the response received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake

Discussion:
Thanks the authors for their work in making this draft. I'm going through and I noticed that the term "answer" (45 occurrences) and "response" (47 occurrences) are used interchangeably in the text. I am OK with that, but they should be explicitly defined IMHO, to avoid confusion. E.g.: if I: ` Is the response the entire DNS-layer packet(s), with all the RRs in it? (including flags,etc) Is an answer each line in both ANSWER and AUTHORITY section? Maybe this is clear to many ppl, but it would be nice to write it down. thanks
I do not believe that we have used these terms "interchangeably", since they're not. Some responses are answers and all answers are responses. Some answers contain an Answer Section and some (negative answers, for instance) do not. If that isn't clear, we perhaps ought to add text similar to that, though I thought we had some discussion of this. I didn't see it while looking on my phone just now, however. A
I have opened PR to fix the places where I think we are really talking about responses, not answers.
I think given how late this is in the draft, I'd like to suggest just adding a new bit of text rather than changing the terms, because the WG has been over this ground some. I think it'll be easier to get WG agreement on some text describing the differences without trying to pick each case. Dunno where to put it -- probably intro or something like that -- but here's a suggestion: This document is sometimes unclear on the terms "response" and "answer". The lack of clarity is partly because the DNS specifications themselves use the terms ambiguously. In general, a response is any DNS message with the QR bit set (see [forward reference here]). An answer is any response that attempts actually to answer the question posed in the corresponding query message. Not all answers are authoritative (see [forward reference here]). Some answers contain an Answer Section (see [xref?]), but not all do (such as a negative answer, [forward reference]). Some other responses are not an answer at all, such as an error response. Sorry not to submit this in the usual and proper githubby way, but I'm on vacation and jamming this in.
Closed with , but might be reopened during IESG review if needed.
Change:
the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-02"). <del> 10.2. </del> <ins> 10.3. </ins> An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names.  Because the security of such

Discussion:
Server side request forgery (SSRF) is possible through ACME when using http-01 because an attacker can use HTTP 3xx redirects to make the ACME verifier server perform an HTTP GET of any URL. Additionally, Boulder helpfully includes (part) of the HTTP body in the detail field of Unauthorized errors. In theory, an HTTP GET of any URL is idempotent and won't actually affect anything. But, if the ACME server returns any part of the HTTP body in error messages (like Boulder does), an attacker could potentially read sensitive data from internal servers. Typical targets for SSRF would be metadata services (like 169.254.169.254 in AWS or OpenStack), any not publicly exposed HTTP interface of the server's stack (like the HTTP API of the RabbitMQ management plugin), or any other internal HTTP server on the server's private network. Perhaps the IETF ACME protocol spec should acknowledge SSRF in its Security Considerations? One recommendation could be to not allow connections to internal network addresses. However, if someone wanted to use ACME for a private intranet CA, correct firewalling like that is much harder. The spec could also discourage including the HTTP body in an Unauthorized error's detail field. Or at least don't include the HTTP body if a redirect was followed. Also, this is mostly mitigated by the actual implementation of Let's Encrypt and Boulder. Notably, only 128 characters (maxResponseSize) of the HTTP body are . And it doesn't seem possible to get Let's Encrypt to access HTTP servers on any port other than 80 or 443, even with a port number specified in the redirect URL, which limits what an attacker could access. (I reported this privately to EMAIL before creating this GitHub issue. This is not an issue for Let's Encrypt.)
Thanks for reporting! Can you post this to the EMAIL mailing list for further discusion? Not everyone who participates in the WG follows the GitHub repo.
Change:
name (i.e. the name that was in the RDATA of the CNAME RR) as also being the QNAME. <del> This creates a kind of confusion, however, because the answer to a query that results in CNAME processing contains in the echoed </del> <ins> This creates a kind of confusion, however, because the response to a query that results in CNAME processing contains in the echoed </ins> Question Section one QNAME (the name in the original query), and a second QNAME that is in the data field of the last CNAME.  The confusion comes from the iterative/recursive mode of resolution,

Discussion:
Thanks the authors for their work in making this draft. I'm going through and I noticed that the term "answer" (45 occurrences) and "response" (47 occurrences) are used interchangeably in the text. I am OK with that, but they should be explicitly defined IMHO, to avoid confusion. E.g.: if I: ` Is the response the entire DNS-layer packet(s), with all the RRs in it? (including flags,etc) Is an answer each line in both ANSWER and AUTHORITY section? Maybe this is clear to many ppl, but it would be nice to write it down. thanks
I do not believe that we have used these terms "interchangeably", since they're not. Some responses are answers and all answers are responses. Some answers contain an Answer Section and some (negative answers, for instance) do not. If that isn't clear, we perhaps ought to add text similar to that, though I thought we had some discussion of this. I didn't see it while looking on my phone just now, however. A
I have opened PR to fix the places where I think we are really talking about responses, not answers.
I think given how late this is in the draft, I'd like to suggest just adding a new bit of text rather than changing the terms, because the WG has been over this ground some. I think it'll be easier to get WG agreement on some text describing the differences without trying to pick each case. Dunno where to put it -- probably intro or something like that -- but here's a suggestion: This document is sometimes unclear on the terms "response" and "answer". The lack of clarity is partly because the DNS specifications themselves use the terms ambiguously. In general, a response is any DNS message with the QR bit set (see [forward reference here]). An answer is any response that attempts actually to answer the question posed in the corresponding query message. Not all answers are authoritative (see [forward reference here]). Some answers contain an Answer Section (see [xref?]), but not all do (such as a negative answer, [forward reference]). Some other responses are not an answer at all, such as an error response. Sorry not to submit this in the usual and proper githubby way, but I'm on vacation and jamming this in.
Closed with , but might be reopened during IESG review if needed.
Change:
be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, <del> credentials, etc.  By provisioning a URI using which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </del> <ins> credentials, etc.  By handing out a URI which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </ins>

Discussion:
Forgot to make PR. This is the "good" one, should be abandoned...
Nope -- I think it is still TBD - we've asked / strongly suggested 114 in the IANA section, but I think it would feel presumptive to state that it is... W
I believe this should be changed to 114, or IANA-TBD.
Yikes, good catch. I changed it to TBD, and also added a sentence to the Abstract noting that it has changed from 160 to TBD (it seemed important enough). Thank you! W
NAME have changed or will change? I can't see this in the current version(s) of the draft here.
I swear I'd done this, and event sent a PR, but I cannot find it.... so, just made a new one...
I had created the branch, and made the edits, but apparently forgot to make the PR.... and then, because I couldn't find it, I made a new branch, change and PR (), and then realized the original was better, so I removed PR and created ... Oy vey, W
Done, had forgotten to close...
Should the TBDs be 114? Either that, or the list of changes should be TBD as well?
Change:
JSEP gathers ICE candidates as needed by the application.  Collection of ICE candidates is referred to as a gathering phase, and this is <del> triggered either by the addition of a new or recycled m= line to the local session description, or new ICE credentials in the description, indicating an ICE restart.  Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. </del> <ins> triggered either by the addition of a new or recycled m= section to the local session description, or new ICE credentials in the description, indicating an ICE restart.  Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the browser in response to changes in the ICE configuration. </ins> When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set.  When this bit is

Discussion:
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST
Change:
Authorization for subscriptions is managed using "subscription" and "push" capability URLs (see CAP-URI).  A capability URL grants access <del> to a resource based solely on knowledge of the URL.  Capability URLs are used for their "easy onward sharing" and "easy client API" properties.  These make it possible to avoid relying on relationships between push services and application servers, with the protocols necessary to build and support those relationships. </del> <ins> to a resource based solely on knowledge of the URL. Capability URLs are used for their "easy onward sharing" and "easy client API" properties.  These make it possible to avoid relying on relationships between push services and application servers, with the protocols necessary to build and support those relationships. </ins> <del> A "subscription" or "push" URI therefore acts as a bearer token. Knowledge of the "subscription" URI implies authorization to either receive push messages or delete the subscription.  Knowledge of the "push" URI implies authorization to send push messages. </del> <ins> A "subscription", "push" or push message URI therefore acts as a bearer token.  Knowledge of a "subscription" URI implies authorization to either receive push messages or delete the subscription.  Knowledge of a "push" URI implies authorization to send push messages.  Knowledge of a push message URI allows for reading that specific message. </ins> Encoding a large amount of random entropy (at least 120 bits) in the path component ensures that it is difficult to successfully guess a <del> valid "subscription" or "push" URI. </del> <ins> valid capability URL. </ins> 7.4.

Discussion:
I realized that I hadn't done due diligence in adding the message URL. This should address that (I have hooks in here for acknowledgment too).
Change:
The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which <del> depends on using a secure clock synchronization mechanism. </del> <ins> depends on using a secure clock synchronization mechanism.  As a result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. </ins> The Verifier can check whether the Evidence is fresh when appraising it at time(RG) by checking "time(RG) - time(EG) < Threshold", where

Discussion:
Per offline discussion between Henk and Dave, trying this annotation to see if it helps Also try combining VG and AA into VC since nothing in doc uses AA, and any example could use either VG or AA, so combining makes any example work for both. Signed-off-by: Dave Thaler
Change:
permanent. All registrations in this document are assigned a permanent status <del> and list as contact the IETF (quic@ietf.org). </del> <ins> and list a change controller of the IETF and a contact of the QUIC working group (quic@ietf.org). </ins> 22.2.

Discussion:
At NAME suggestion this adds a "change controller" field to registries and splits between a change controller (IETF) and contact (QUIC WG). Not really sure if this is worth a design label...
Section 22.1.1: It is quite common that one may want to separate who has the change control over an registration entry vs who is the contact. Change control can often be assigned to an organization rather than an individual while a contact information may be an individual or a specific contact address for the organization. Contact information has a tendency to get stale, and in many case the contact if a person may no longer represent the organization that made the registration. Thus, my suggestion would be to add a separation between contact and change controller. In fact just for the registration in the Transport doc it makes sense to make the change controller "IETF" and have the contact be "QUIC WG".
This also applies to permanent registrations in Section 22.1.4
NAME does the PR address your issue?
Change looks good and implements what I proposed.
Labeling as "editorial" based on
Change:
that is not advertised as being supported in the signature_algorithms extension. <del> Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not </del> <ins> Note: TLS 1.3 servers might receive TLS 1.2 ClientHellos which do not </ins> contain this extension.  If those servers are willing to negotiate TLS 1.2, they MUST behave in accordance with the requirements of RFC5246 when negotiating that version.

Discussion:
When talking about handling downlevel clients, the spec variously says a server "MAY" receive such messages, or "may" receive such messages. Since this is discussing a possibility (not a permitted behavior), the normative language isn't correct; lower-case versions of the RFC2119 terms have the potential to confuse readers. Suggest changing all of these to "might" to denote a possible occurrence server implementers will need to handle.
Yes, this looks like an improvement.
LGTM
Change:
An off-path attacker cannot: <del> Modify any part of a packet </del> <ins> Modify packets sent by endpoints </ins> Delay packets

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.
Change:
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

Discussion:
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.
Change:
The number of reports included in the batch. <ins> The smallest interval of time that contains the timestamps of all reports included in the batch, such that the interval's start and duration are both multiples of the task's "time_precision" parameter.  Note that in the case of a "time_interval" type query (see query), this interval can be smaller than the one in the corresponding "CollectionReq.query". </ins> The vector of encrypted aggregate shares.  They MUST appear in the same order as the aggregator endpoints list of the task parameters.

Discussion:
The Leader now informs the Collector of what time interval is spanned by the reports aggregated into a collection, regardless of the query type. This is particularly useful for fixed size tasks as otherwise a Collector can only guess at the report times based on the timing of collection requests, but also useful in time interval tasks since the aggregated reports could span a smaller interval that what was requested (e.g., if the collector requested a one hour time interval, but reports only arrived during minutes 30-40 of that hour).
, the results of an aggregation are presented to the collector as: where is the encrypted form of . In the case of a time interval task, the collector will have explicitly requested collection over some interval of time, but in the case of a fixed size task, that aggregate result will have been compiled from a set of reports chosen by the leader. So the collector can only infer that the reports are from no later than when the collect request came in and no sooner than when the collector got the previous batch. DAP should explicitly tell the collector what time interval is covered by a collected batch.
One way to do this would be to amend . , it is defined as: We could add an to the case. However that is awkward because is also used in , so we have to make sure that there's something cogent the leader could put there. Another, simpler choice is to simply add an field to , but the downside there is that this information isn't useful in the time interval case, because the collector already knows what time interval it queried over.
I'm cool with adding an with the minimum and maximum timestamp of all reports in the batch. I think overloading is not the right approach, however, since this is meant to "partially determine" a batch of reports, where as the interval in our case is strictly informational. Unrelated follow question: if we define to be "the minimum and maximum timestamp of reports in the batch" then it's possible that . I think this is OK, and might even be useful.
+1 to not including an in ; instead, I think it should be placed directly in .
Chris' point that the interval in could be tighter than what was in is compelling. I also now think we should put the in (or, well, ). I'll draft this change and circulate it to the WG this week, as I would like to include it in draft-04, which already includes a bunch of message definition changes.
Change:
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human- readable, using whitespace for message formatting leads to parsing <del> complexity and motivates tolerance of variant behavior.  Because each connection can transfer only a single HTTP request or response at a time in each direction, multiple parallel TCP connections are often used, reducing the ability of the congestion controller to effectively manage traffic between endpoints. </del> <ins> complexity and motivates tolerance of variant behavior.  Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </ins> HTTP/2 HTTP2 introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer.  However,

Discussion:
NAME raised the point that the following text might be misleading, since HTTP/1.1 allows pipelining: "HTTP/1.1 [HTTP11] is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages. While these exchanges are human-readable, using whitespace for message formatting leads to parsing complexity and motivates tolerance of variant behavior. Because each connection can transfer only a single HTTP request or response at a time in each direction, multiple parallel TCP connections are often used, reducing the ability of the congestion controller to effectively manage traffic between endpoints." NAME suggested the following text instead: "Because of limitations in how HTTP exchanges are mapped onto TCP connections in HTTP/1.1, multiple parallel connections are often used..." NAME suggested the following text instead: "Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel. However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections."
Roy's works for me.
Change:
For example: indicates that a resource with the relation type <del> "https://example.org/rel/user" can be found by interpolating the </del> <ins> "https://example.org/rel/user" can be found by expanding the </ins> "username" variable into the template given. The target for the link (as defined in WEB-LINKING) is the result of

Discussion:
"interpolate" feels very odd. Other choices would be "expanding" or "substituting". I am not picky about the exact choice, but the current terminology seems odd.
The URI Template RFC uses 'expand', so that seems most appropriate.