jiebi/CodeConvo huggingface dataset:
Change:
acknowledgement is received that establishes loss or delivery of packets. <del> 6.7. </del> <ins> 6.8. </ins> When an ACK frame is received that establishes loss of all in-flight packets sent over a long enough period of time, the network is

Discussion:
Clarifies a few points and moves the initial window recommendation from the pseudocode to the text. I could take this a bit farther, but I'd like suggestions on what's currently missing in this PR.
LGTM
It starts like this: The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section. On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be? An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.
The intent is that the text is complete without reading the referenced RFCs or pseudocode, so I think this section needs more text and possibly some inlined pseudo-code.
Hi NAME I wrote which fixes some obvious errors I found, but I think more could be done. Can you take a look and tell me what other points you'd like added or moved up from the pseudocode?
Looks good! Thanks!
Change:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <ins> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </ins> 7. Versioning in QUIC may change the protocol's behavior completely,

Discussion:
Add a section about being careful with timing with respect to CID migration if you actually care about linkability.
Linkability across CID changes is in the common case so trivial that protocol features to defeat linkability through other means risk being useless. "Find CID y where delay < d between last packet for CID x and first packet for CID y on 2-tuple {a,p}, given {x,a,p}" is an operation which requires zero additional state and a simple O(kn log n) search for any large on-path (passive surveillance) device that's halfway smart about keeping per-flow state -- i.e., it's basically a free operation, and its utility is baked into the physics of CIDs -- after all, this is what CIDs are for. The ease of this analysis can only be mitigated by increasing the size of the anonymity set: ensuring that for any given delay window d, a minimum number of CIDs x transition on any given {a,p}. This seems like good operational advice for servers with enough traffic to build such anonymity sets (should they have interest in preventing client linkability, of course) -- small servers are probably out of luck though. Applicability should call this out as a problem, manageability should suggest a solution space.
-quic-transport section 6.11.5. begins to address this now, but aside from the following... URL still seems to pretend that coordinated CID migration is sufficient to fix linkability. So I still think we need something in -applicability. Will throw together a PR today.
addressed in
Change:
For example, the pledge may only be aware of its IDevID Subject which includes a manufacturer serial number, but must include a specific fully qualified domain name in the CSR in order to complete domain <del> ownership proofs required by the CA.  As another example, the registrar may deem the manufacturer serial number in an IDevID as personally identifiable information, and may want to specify a new random opaque identifier that the pledge should use in its CSR. </del> <ins> ownership proofs required by the CA. As another example, the registrar may deem the manufacturer serial number in an IDevID as personally identifiable information, and may want to specify a new random opaque identifier that the pledge should use in its CSR. </ins> 3.

Discussion:
This should be a do-nothing change to the content, which just starts every sentence on fresh line. This aids greatly in reading diffs. One paragraph break added, and one period changed to a dot. And I seem to have included the IEEE reference fix by mistake.
Change:
All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). <del> source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec- loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long packet headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. </del> <ins> source and destination connection ID: short and long headers carry a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. </ins> In version 1 of QUIC, the following additional information is exposed:

Discussion:
The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...
Change:
The PTO value MUST be set to at least kGranularity, to avoid the timer expiring immediately. <del> A sender computes its PTO timer every time an ack-eliciting packet is sent.  When ack-eliciting packets are in-flight in multiple packet number spaces, the timer MUST be set for the packet number space with the earliest timeout, except for ApplicationData, which MUST be ignored until the handshake completes; see Section 4.1.1 of QUIC-TLS. Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement. </del> <ins> A sender recomputes and may need to reset its PTO timer every time an ack-eliciting packet is sent.  When ack-eliciting packets are in- flight in multiple packet number spaces, the timer MUST be set for the packet number space with the earliest timeout, except for ApplicationData, which MUST be ignored until the handshake completes; see Section 4.1.1 of QUIC-TLS.  Not arming the PTO for ApplicationData prevents a client from retransmitting a 0-RTT packet on a PTO expiration before confirming that the server is able to decrypt 0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO expiration before it has the keys to process an acknowledgement. </ins> When a PTO timer expires, the PTO period MUST be set to twice its current value.  This exponential reduction in the sender's rate is

Discussion:
When writing , I found some of the text organization to be odd, so this moves it some.
Change:
CompressedCertificate message might misbehave and drop connections that adopt certificate compression. <del> However this is not a problem when using TLS version 1.3 [draft-ietf- tls-tls13] and higher, due to the fact that the Certificate (and thus </del> <ins> However this is not a problem when using TLS version 1.3 I-D.ietf- tls-tls13 and higher, due to the fact that the Certificate (and thus </ins> the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it.

Discussion:
This allows for stateless parsers to easily understand the contents of the message without having to keep track of the handshake state. This also decouples client and server compression parameters, allowing compression being negotiated in only one direction.
LGTM, added just a couple of small nits.
Looks good to me.
Change:
of certificate_request_context in that message.  Otherwise, in the case of server authentication this field SHALL be zero length. <del> This is a sequence (chain) of certificates.  The sender's certificate MUST come first in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> This is a sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.  The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. A set of extension values for the CertificateEntry.  The "Extension" format is defined in hello-extensions.  Valid extensions include OCSP Status extensions (RFC6066 and RFC6961) and SignedCertificateTimestamps (RFC6962).  Any extension presented in a Certificate message must only be presented if the corresponding ClientHello extension was presented in the initial handshake.  If an extension applies the the entire chain, it SHOULD be included in the first CertificateEntry. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it, however some

Discussion:
This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?
Change:
CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher over the following plaintext: <del> PLAINTEXT_2 = ( ? PAD, ID_CRED_R / bstr / -24..23, </del> <ins> PLAINTEXT_2 = ( ? PAD_2, ID_CRED_R / bstr / -24..23, </ins> Signature_or_MAC_2, ? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e.,

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
answerer, who first calls setRemoteDescription(sdp [offer]) and then later setLocalDescription(sdp [answer]). <ins> During the offer/answer exchange, the outstanding offer is considered to be "pending" at the offerer and the answerer, as it may either be accepted or rejected.  If this is a re-offer, each side will also have "current" local and remote descriptions, which reflect the result of the last offer/answer exchange.  Sections sec.pendingLocalDescription, sec.pendingRemoteDescription, sec.currentLocalDescription, and sec.currentRemoteDescription, provide more detail on pending and current descriptions. </ins> JSEP also allows for an answer to be treated as provisional by the application.  Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order

Discussion:
NAME PTAL
The concept of a "pending local description" is used in sections 3.5.1, , and 4.1.7 but isn't really explained until much later in the document. Please provide forward references, or move a description of what a pending description is earlier in the document.
Yah, this does seem like it needs a fix. Probably something about this in S 3.2.
The second paragraph of section 5.4 is confusing. A slight restructuring of the sentences would remove much of the potential confusion, I think. I suggest replacing the first sentence (which is very complex) with this: "After calling setLocalDescription, the application MAY modify the SDP to reduce the capabilities in the offer before sending it to the far side, as long as it remains a valid SDP offer and specifies a subset of what was in the original offer. Likewise, an application that has received an offer from a peer MAY modify the received SDP, subject to those same constraints, before calling setRemoteDescription."
LGTMLG with nits
Change:
7. <del> The client's first flight SHOULD be sent using the version that the server is most likely to support (in the absence of other information, this will often be the oldest version the client supports). </del> <ins> The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client selects the version it believes to be best supported from the versions that are compatible with the client's most preferred version.  Without additional information this could mean selecting the oldest version that the client supports. </ins> 8.

Discussion:
Though it might be the oldest version that is compatible with the most-preferred version, it isn't just "oldest".
Change:
and the EncryptedExtensions messages during the handshake.  Endpoints MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the <del> quic_transport_parameters extension MUST terminate the TLS handshake with a fatal missing_extension alert (an error of 0x16d). </del> <ins> quic_transport_parameters extension MUST close the connection with an error of type 0x16d (equivalent to a fatal TLS missing_extension alert, see tls-errors). </ins> While the transport parameters are technically available prior to the completion of the handshake, they cannot be fully trusted until the

Discussion:
Of the TLS doc says: A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This also prevents QUIC from sending 0-RTT data. However, this doesn't explicitly say that it prevents QUIC from receiving 0-RTT data. I suspect this is implied, but it might be worth clarifying. I could imagine a server rejecting 0-RTT data, but attempting to ACK the client's 0-RTT packets in order to deliver a congestion signal to the client. I think this would be a rather terrible idea, so it would be nice to explicitly prohibit it.
Throughout transport, there is the idea that you MUST not acknowledge packets you can't fully process, so this should be against the spec. But it may be worth noting explicitly, probably in transport.
Doing it in transport would make sense. Or perhaps in TLS by noting that if 0-RTT is rejected, 0-RTT keys must not be generated.
NAME I just added text about that to my PR that's targeting .
SG NAME If so, can you update the CL description to indicate what issues it closes?
I'm going so recommend that this be triaged as a design issue, even if it might seem trivial. The prohibition in is the right response.
The spec says RFC 8446 says about rejecting 0-RTT: This doesn't really apply to QUIC, since we don't need a connection that requires us to read the bytes in order. The QUIC equivalent would be to drop all packets of packet type 0-RTT.
It is my understanding the existence of early_data extension in the EncryptedExtensions message indicates if the server has accepted 0-RTT (or not). Merely dropping the packets is not sufficient. This is because the parameters of a connection depends on if 0-RTT has been received; for example, in case of HTTP/3, until the client receives a SETTINGS frame, the settings of previous connection is applied when 0-RTT is accepted, whereas the default settings defined by the specification is applied when 0-RTT is rejected.
PS. What I think we need to clarify is that "use and acceptance" of 0-RTT is communicated the same way as TLS 1.3, by using the earlydata extension.

That includes earlydata extension sent in ClientHello, EncryptedExtensions, NewSessionTicket.
Thanks NAME That confirms my interpretation of how accepting and rejecting is supposed to work. I’ll prepare a PR later.
Change:
is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. <del> 7.6. </del> <ins> 7.7. </ins> This document does not specify a pacer, but it is RECOMMENDED that a sender pace sending of all in-flight packets based on input from the

Discussion:
Ignore the loss of Handshake, 0-RTT, and 1-RTT packets if the peer doesn't have the keys to process them. Also unifies the text on discarding keys and no longer implies that 0-RTT has it's own packet number space. Replaces
merging this one as well to get this in -18.
A few comments, editorial.
Change:
The signature algorithm used to verify DelegatedCredential.signature. <del> The signature over the credential with the end-entity certificate's public key, using the scheme. </del> <ins> The delegation, a signature that binds the credential to the end- entity certificate's public key as specified below.  The signature scheme is specified by DelegatedCredential.algorithm. </ins> The signature of the DelegatedCredential is computed over the concatenation of:

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
the application traffic key.  This message creates a pre-shared key (PSK) binding between the resumption master secret and the ticket label.  The client MAY use this PSK for future handshakes by <del> including it in the pre_shared_key extension in its ClientHello (pre- shared-key-extension) and supplying a suitable PSK cipher suite. </del> <ins> including it in the "pre_shared_key" extension in its ClientHello (pre-shared-key-extension) and supplying a suitable PSK cipher suite. </ins> %%% Ticket Establishment struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } NewSessionTicket;

Discussion:
Some fixes for things I didn't catch when I checked for typos in the big patch last time. Of note, you're missing a closing brace for the select in "PreSharedKeyExtension" and a semicolon after "KnownConfigurationExtension". I also corrected things to match the existing (admittedly unusual) indentation style of the document and put quotes around the extension IDs you missed. (some had them; some didn't)
Ok, spaces between cases reverted. I also added a similar bit of whitespace in another new extension.