jiebi/CodeConvo huggingface dataset:
Change:
binding or other state entry will be expired after just thirty seconds of inactivity. <ins> By using a Connection ID, QUIC is designed to be robust to NAT address rebinding after a timeout.  However, some QUIC connections may not be robust to rebinding because the routing infrastructure (in particular, load balancers) uses the address/port four-tuple to direct traffic.  Furthermore, middleboxes with functions other than address translation may still affect the path.  In particular, firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. </ins> A QUIC application has three strategies to deal with this issue: Ignore it, if the application-layer protocol consists only of <del> interactions with no or very short idle periods. </del> <ins> interactions with no or very short idle periods, or the protocol's resistance to NAT rebinding is sufficient. </ins> Ensure there are no long idle periods.

Discussion:
Intended to , ,
The draft says section 8 of quic-transport; it's section 13.
It is odd that this section doesn't mention QUIC's robustness to NAT rebinding at all. While this won't work behind 4-tuple load balancers, middlebox timers may be irrelevant depending on the conesequences of the timeout.
While TFO has some 0RTT-like properties, it does not fully replace it, not only because the SYN or option gets scrubbed, but also because you're limited to one packet payload. Also, this ought to mention TLS stacks that offer replay protection. I would think a modern QUIC interface would offer a signal to separate 0RTT from 1RTT data, so that both senders and receivers can manage their application data appropriately.
will be
This is editorial, but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group. This will not age well, and the intro should be worded as if it were already a published RFC. The intro still talks about "HTTP/2 over QUIC" when it's now HTTP/3.
Change:
17.2.5.3. <del> The next Initial packet from the client uses the connection ID and token values from the Retry packet; see negotiating-connection-ids. Aside from this, the Initial packet sent by the client is subject to the same restrictions as the first Initial packet.  A client MUST use the same cryptographic handshake message it included in this packet. A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it. </del> <ins> Subsequent Initial packets from the client include the connection ID and token values from the Retry packet.  The client copies the Source Connection ID field from the Retry packet to the Destination Connection ID field and uses this value until an Initial packet with an updated value is received; see negotiating-connection-ids.  The value of the Token field is copied to all subsequent Initial packets; see validate-retry. Other than updating the Destination Connection ID and Token fields, the Initial packet sent by the client is subject to the same restrictions as the first Initial packet.  A client MUST use the same cryptographic handshake message it included in this packet.  A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it. </ins> A client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT packets to the connection ID provided by the server.  A client

Discussion:
See the issue for the sorry history of this mistake.
This issue has a long and storied history. We were originally of the view that only one packet needed to include a token (which you can see in the discussion of ). However, the resolution of that issue in was very clear: every Initial packet needs to include a token. That introduced a regression as it grouped the token with the connection ID, and we caught that in . However, the fix to that in reverted the token changes along with the connection ID changes. Since then, this error has gone unnoticed. Most people will have seen the stronger normative requirement : To my knowledge, every implementation includes the token in every Initial packet, changing only when a Retry is received. We should reconcile the text.
FWIW, that's what the interop runner tests for in the Retry test case.
NAME : Yes, that's what sent us off on this chase :-)
Change:
The legacy_record_version field is always 0x0303.  TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns <del> where other values might be received.  Implementations MAY verify that the legacy_record_version field is 0x0303 and abort the connection if it is not.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </del> <ins> where other values might be received.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </ins> The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of

Discussion:
Previous PR plus some cleanup.
Looks good to me, for what it's worth :)
ekr: please merge this so we can get a new version out for the IESG.
NAME can you be more precise about the appendix D text? is the issue that we say "ignored" but then use it as additional_data?
NAME : PTAL
Change:
For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see <del> identifier-authorization).  For final orders (in the "valid" or "invalid" state), the authorizations that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </del> <ins> identifier-authorization).  The authorizations required are dictated by server policy and there may not be a 1:1 relationship between the order identifiers and the authorizations required. For final orders (in the "valid" or "invalid" state), the authorizations that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </ins> A URL that a CSR must be POSTed to once all of the order's authorizations are satisfied to finalize the order.  The result of

Discussion:
This PR clarifies that a client SHOULD NOT assume that the "identifiers", "authorizations" or "challenges" arrays returned in various server response objects are sorted. This PR also clarifies that while some have a 1:1 relationship between order identifiers and order authorizations this isn't a universal truth. This resolves URL
NAME Is 6 days without any feedback on-list sufficient to merge?
On the reuqest, there are two arrays returned, one for the and one for the . However, there is no order specified in ACMEv2. As two arrays are returned (and no hash), this might imply that the order of matches the order of . This is not specified right now. Having this specified would allow clients to know in advance for which identity they are requesting the authorization challenge before requesting the URL, e.g. for better error reporting. Also ok would be to just explicitly specify that the order is not guaranteed or the number of entries is not guaranteed to match in order to make it more clear to developers. cf. URL
From the outcome of the linked conversation, we should just specify that no specific order is guaranteed.
:+1: - URL I will start a mailing list thread since this is a new SHOULD NOT.
Looks good to me; let's wait a little bit for feedback on-list.
Change:
cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <del> The "profile_id" field allows the client and server to agree on which compression profile should be used for this session (see template- based-specialization).  This field MUST be set to zero if and only if no compression profile is used.  Non-zero values are negotiated out of band between the client and server, as part of the specification of the compression profile. </del> [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use.  For a ServerHello this field is not required.  Should we make this field optional?]]

Discussion:
For cTLS/TCP, the CTLSCiphertext headers could easily all be the same size (1 byte type/flags, 2 byte length). For cTLS/UDP, the header sizes could be made more predictable. Suggestions: Always suppress sequence numbers and disallow connection IDs in cTLS/TCP, and after the first record in a datagram in cTLS/UDP. Move into the cTLS ClientHello struct.
Moving the profile_id into the ClientHello sounds good to me. Here is the PR: URL
Suppressing sequence numbers in cTLS/TCP sounds good to me as well. Here is the PR: URL
NAME closing as I think we addressed.
Change:
becomes blocked.  In particular, implementations should consider that remote peers may wish to exercise reserved stream behavior (stream- grease) with some of the unidirectional streams they are permitted to <del> use.  To avoid blocking, the transport parameters sent by both clients and servers MUST allow the peer to create at least one unidirectional stream for the HTTP control stream plus the number of unidirectional streams required by mandatory extensions (three being the minimum number required for the base HTTP/3 protocol and QPACK), and SHOULD provide at least 1,024 bytes of flow-control credit to each stream. </del> <ins> use. Each endpoint needs to create at least one unidirectional stream for the HTTP control stream.  QPACK requires two additional unidirectional streams, and other extensions might require further streams.  Therefore, the transport parameters sent by both clients and servers MUST allow the peer to create at least three unidirectional streams.  These transport parameters SHOULD also provide at least 1,024 bytes of flow-control credit to each unidirectional stream. </ins> Note that an endpoint is not required to grant additional credits to create more unidirectional streams if its peer consumes all the

Discussion:
This PR covers questions asked during Auth48 which aren't pure copyediting, but seem to have a straightforward single-location fix. Individual commits, so it's easy to pull one out if someone disagrees.
In , the RFC Editor asks:
Either A or B is better, but I have no preference.
Fixed in , but GitHub won't automatically close until it hits .
Change:
provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. <del> 12.4. </del> <ins> 12.3. </ins> As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion

Discussion:
insert text suggested by Roman about how deep down the security properties
[github said: URL] ==[ snip ]== We need to acknowledge that there is a deep hole (not infinitely deep, but not trivial) where we need to look at integrity of all of the different platforms. The way that the compositions are composed is a bit tricky, and the results are sometimes different than other people would naively assume. Are there references here to other papers that we should include? ==[ snip ]== I completely agree, that's why I mentioned it. Composition is hard and can alter the security assumptions of the individual components and introduce emergent risk. I don't think it can be solved generically. However, we do need cautionary text here. Perhaps: NEW (roughly) The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still holds despite the lack of separation, and that emergent risk is not introduced. The specifics of this evaluation will depend on the implementation and use case is out of scope for this document.
Change:
for the initiator and responder roles, broken down per protocol phase. <del> 7.1. </del> <ins> 7.3. </ins> The initiator MAY send multiple "return_routability_check" messages of type "path_challenge" to cater for packet loss on the

Discussion:
Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.
Change:
For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same. <del> If any RtpTransceiver has been stopped, the port MUST be set to zero and all "a=msid" lines MUST be removed. If any RtpTransceiver has been added, and there exists a m= section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating a m= section for the added RtpTransceiver as if the m= section were being added to session description, except that instead of adding it, the generated m= section replaces the m= section with a zero port.  The new m= section MUST contain a new MID. </del> If the initial offer was applied using setLocalDescription, and an answer from the remote side has been applied using setRemoteDescription, meaning the PeerConnection is in the "remote-

Discussion:
BLOCKER: The second bullet on page 43 ("If an RtpTranceiver has been stopped and is associated..." is normative and redundant with (and slightly contradictory to) the bullet on page 44 starting "If any RtpTranceiver has been slopped...") which is also normative. Remove one.
Looks like an editorial oversight. I'm inclined to remove the second instance. NAME as FYI
BLOCKER: The bullet at the bottom of of page 42 ("If any RtpTranceiver has been added...") is normative and redundant with the bullet in the middle of page 44 ("If any RtpTranceiver has been added..."), which is also normative. Remove one.
Agreed. Let's remove the second one. NAME as FYI
Change:
6. The following is an example of a handshake with lost packets and <del> retransmissions. </del> <ins> retransmissions.  Note that the client sends an empty ACK message because it can only acknowledge Record 1 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, which are needed to encrypt to decrypt messages found in Record 1. ack-msg provides the necessary background details for this interaction. </ins> 6.1.

Discussion:
Based on review from Ben: Section 6 Figure 11 seems to show that the initial ServerHello has messageseq=1, but §5.2 says that "[t]he first message each side transmits in each association always has messageseq = 0". Which one is it? (A change here would affect all the server's messages except the final ACK.)
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed
Change:
sets the Destination Connection ID it sends to match the value of the Source Connection ID that they receive. <del> When an Initial packet is sent by a client which has not previously received a Retry packet from the server, it populates the Destination Connection ID field with an unpredictable value.  This MUST be at least 8 bytes in length.  Until a packet is received from the server, the client MUST use the same value unless it abandons the connection attempt and starts a new one.  The initial Destination Connection ID is used to determine packet protection keys for Initial packets. </del> <ins> When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, it populates the Destination Connection ID field with an unpredictable value.  This MUST be at least 8 bytes in length.  Until a packet is received from the server, the client MUST use the same value unless it abandons the connection attempt and starts a new one.  The initial Destination Connection ID is used to determine packet protection keys for Initial packets. </ins> The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCIL field to indicate the length. The first flight of 0-RTT packets use the same Destination and Source </del> <ins> its choosing and sets the SCIL field to indicate the length.  The first flight of 0-RTT packets use the same Destination and Source </ins> Connection ID values as the client's first Initial. <del> The Destination Connection ID field in the server's Initial packet contains a connection ID that is chosen by the recipient of the packet (i.e., the client); the Source Connection ID includes the connection ID that the sender of the packet wishes to use (see connection-id).  The server MUST use consistent Source Connection IDs during the handshake. On first receiving an Initial or Retry packet from the server, the </del> <ins> Upon first receiving an Initial or Retry packet from the server, the </ins> client uses the Source Connection ID supplied by the server as the Destination Connection ID for subsequent packets, including any subsequent 0-RTT packets.  That means that a client might change the

Discussion:
Qualifies a MUST with an 'otherwise', since otherwise it would appear to directly contradict previous normative text.
Change:
TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). <del> A zero-length context (indicated by "") is used in the TLS exporter interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is appended to the label strings.  Other TLS based EAP methods can use exporters in a similar fashion by replacing the EAP-TLS Type-Code with their own Type-Code (encoded as a hexadecimal string). </del> <ins> Other TLS based EAP methods can use exporters in a similar fashion by replacing the EAP-TLS Type-Code with their own Type-Code (encoded as a hexadecimal string). </ins> RFC5247 deprecates the use of IV.  Thus, RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3.  As noted in RFC5247, lower layers

Discussion:
Appending things to labels are not agreeing with the IANA registry for labels. Registering labels for each TLS based EAP type would explode the registry.
For the historic record, could you also record where this feedback originated from?
This was discussed during EMU WG IETF 110 and the WG consensus was to go back to using context. URL For the reasons metioned in the first comment, this seemed like the best solution. This is also what has been interoptested (but implementors stated they they could change if needed.) URL The consunsus during the meeting was. Change back to using context If 1. is not approved by IESG, then registed a larger number of labels with the type code in the label.
I think we still need to come to consensus on where the EAP-Type goes Label Context If the consensus is label then we need to determine how to incorporate IANA considerations as either a fixed string or reserve a prefix string
I thought we had consensus during IETF 110 to use type-code in the context. I had closed and merged PR
OK good, I hadn't seen the issue close and didn't realize there was a PR associated with it. Closing this as resolved by PR
Change:
4.1. <del> Implementations can distinguish the two header formats by examining the first byte: </del> <ins> DTLS 1.3 uses a variable length record format and hence the demultiplexing process is more complex since more header formats need to be distinguished.  Implementations can demultiplex DTLS 1.3 records by examining the first byte as follows: </ins> If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record.

Discussion:
I have re-drawn the figure to take Ekr's comments into account. I hope the new figure is better.
LGTM
Change:
applies to the entire chain, it SHOULD be included in the first CertificateEntry. <ins> If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not used or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate.  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. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility.  Servers sometimes

Discussion:
Explicitly define RFC 7250 certificate support.
Seems reasonable. (I did not try to audit the rest of the text to see if there are other places that need updating.)
This captures what we talked about in Chicago.
Shucks, this hasn't landed yet, so I'll have to remember to update my editorial changes pull request that puts the numbers for these into the enumerated type definition for extensions.
Change:
6.3.2. When a PTO timer expires, the sender MUST send one ack-eliciting <del> packet as a probe.  A sender MAY send up to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single packet loss. </del> <ins> packet as a probe, unless there is nothing to send.  A sender MAY send up to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single packet loss. </ins> Consecutive PTO periods increase exponentially, and as a result, connection recovery latency increases exponentially as packets

Discussion:
Editorial fix for This seems like the minimal fix for the existing text, though I wonder if it's the correct one.
I think this fix is fine, but it's inadequate. I'll take this in since it's useful.
Can you clarify why it's inadequate on the still open issue?
NAME primarily because it does not correct the pseudocode, but I've also made some textual adjustments in
As discussed with NAME 6.2.2.2 is awkward, because in the first paragraph it says And then the very last paragraph changes that by saying What is super unclear is that the final paragraph apparently means to imply that when there is no new or unACKed data to send, nothing should be send, i.e., it invalidates the SHOULD in the first paragraph. Related to that, the pseudo code still uses , which is also inaccurate, since it's really "at least one (unless you don't have new or unACKed data) but can also send two". Good luck finding a good name for that function :-)
The pseudocode now uses SendOneOrTwoPackets(), but the last paragraph pretty clearly violates the previous MUST, which is very bad. The simplest fix would be to change the MUST to a "SHOULD unless otherwise specified", but I'm increasingly thinking we should stick with the MUST and if you get into a situation you have nothing to send, require sending something ack-eliciting to ensure in-flight packets are removed from flight. Thoughts?